Re: [IPsec] Proposed work item: Labelled IPsec
On Fri, Dec 04, 2009 at 10:46:02PM +0200, Yaron Sheffer wrote: > Please remember that it is up to the WG to define the work item. The > I-D is just a possible starting point, so if there's strong interest > in this area, you may wish to reach consensus on a charter item - and > to convince the rest of us that enough people are interested. Yes, but that's not how the original message in this thread was worded: | Please reply to the list: | | - If this proposal is accepted as a WG work item, are you committing to | review multiple versions of the draft? | - Are you willing to contribute text to the draft? | - Would you like to co-author it? | | Please also reply to the list if: | | - You believe this is NOT a reasonable activity for the WG to spend | time on. True, you might interpret "the draft" to mean "the WG draft" as opposed to "the starting point" I-D given in that e-mail, but it wasn't sufficiently clear. Now that you've clarified, my answers are: - I am willing to review multiple versions of a WG I-D on labelled IPsec, and to contribute text. - I am not willing to co-author. - I do believe that labelled IPsec via IKE extensions is a reasonable activity for the WG. However, I do not believe the the proposed starting point is appropriate as is. I believe that an appropriate labelled-IPsec-via- IKE-extensions work item should address interoperability, which means at a minimum that for explicit labelling in IKE we should have a DOI agreement sub-protocol (i.e., both peers must understand that they have a common DOI or that they don't). I'm also interested in proposals that do CERT-based implicit labelling, but such proposals are probably more appropriately pursued elsewhere (e.g., PKIX WG). Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Labelled IPsec
Please remember that it is up to the WG to define the work item. The I-D is just a possible starting point, so if there's strong interest in this area, you may wish to reach consensus on a charter item - and to convince the rest of us that enough people are interested. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Nicolas Williams > Sent: Friday, December 04, 2009 20:46 > To: Dan McDonald > Cc: ipsec@ietf.org; Joy Latten > Subject: Re: [IPsec] Proposed work item: Labelled IPsec > > On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote: > > The bigger point being missed by this thread, I think, is that it > > seems that any work in multi-level security needs to deal with > > successful interoperability. If it doesn't, there's little point in > > documenting a single-platform solution as part of a working group's > > output. > > +1. > > The proposed work item is, at first glance anyways, too SELinux- > specific. > > Note that SMACK encodes its labels as CIPSO labels, so a scheme that > uses CIPSO can possibly be used in SMACK and non-SMACK environments, and > possibly even be mixed. > > In any case, there have been lengthy threads elsewhere (saag, IIRC) > about MAC interoperability. > > Some options to consider: > > - implicit labeling > - derived from CERTs > - derived from IDs > - derived from network addresses > - negotiated labeling > - requires a DOI negotiation of some sort > - each node asserts one, or more, or a range of labels (SMACK, for > example, doesn't support the notion of label ranges) and the peers > evaluate and narrow the assertion according to policy and produce > > All I see in the proposed work item is single label assertions. That > strikes me as insufficient. > > Nico > -- > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
Hi Michael, On Thu, December 3, 2009 7:18 pm, Michael Richardson wrote: > Dan Harkins wrote: >> 2. solves the specific problem it is aimed at poorly-- doubling of >> the number of messages, requiring writing and testing of new >> state EAP state machines that are, otherwise, unnecessary; and, > > Does it double, or does it really just "n+1", which is doubling if the > rest of the protocol has "n=1"? I also wonder if this is really a > sufficiently compelling reason to have two sets of code. For the proposed EAP methods, EAP-EKE and EAP-PWD, it really is double. I don't think it's possible to do the kind of exchange that's required-- mutual authentication, key generation-- in n=1 messages. If you look at the SPSK draft, it is doing essentially the same exchange as EAP-PWD and doing it in 6 messages total. If you do EAP-only plus EAP-PWD (or EAP-only plus EAP-EKE, doesn't matter) it's 12 messages total. >> 3. is insecure (unless something used nowhere today is employed: >> EAP >> channel bindings). > > We can, and must solve this. We can and we must. That's the easy part :-) The hard part is coming up with a way to do it. One of the big problems with EAP is that it is a completely underspecified shim. That's why every EAP method needs to roll-its-own identity exchange (the identity obtained by EAP is not suitable for authentication purposes) and roll-its-own fragmentation/reassembly code. So the obvious, and in my opinion wrong, solution for channel bindings is to just have each EAP method roll-its-own security capabilities negotiation plus definition of TLV message exchange and a cryptographic protection of that TLV message exchange as a way to solve channel bindings. Another option is to have it done generally as some sort of extension to EAP that every EAP method can "inherit". But mention that and people who wear hats start saying what can and cannot be done and what's in a charter and blah blah blah. Keep in mind, though, that however channel bindings gets solved, it is only going to further increase the number of messages necessary to get what you can get in SPSK in 6, and only 6, messages :-) Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D ACTION:draft-ietf-ipsecme-aes-ctr-ikev2-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Author(s) : S. Shen, Y. Mao, S. murthy Filename: draft-ietf-ipsecme-aes-ctr-ikev2-04.txt Pages : 16 Date: 2009-12-4 This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit initialization vector, by IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Labelled IPsec
On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote: > The bigger point being missed by this thread, I think, is that it > seems that any work in multi-level security needs to deal with > successful interoperability. If it doesn't, there's little point in > documenting a single-platform solution as part of a working group's > output. +1. The proposed work item is, at first glance anyways, too SELinux- specific. Note that SMACK encodes its labels as CIPSO labels, so a scheme that uses CIPSO can possibly be used in SMACK and non-SMACK environments, and possibly even be mixed. In any case, there have been lengthy threads elsewhere (saag, IIRC) about MAC interoperability. Some options to consider: - implicit labeling - derived from CERTs - derived from IDs - derived from network addresses - negotiated labeling - requires a DOI negotiation of some sort - each node asserts one, or more, or a range of labels (SMACK, for example, doesn't support the notion of label ranges) and the peers evaluate and narrow the assertion according to policy and produce All I see in the proposed work item is single label assertions. That strikes me as insufficient. Nico -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE
At 12:35 PM +0200 12/4/09, Tero Kivinen wrote: >I would say as we are talking here about the obsoleted IKEv1 protocol, >and these problems have already been solved in the IKEv2, there is no >need to do anything for IKEv1 registries. Agree. >There is no need to get AES-XCBC PRF to work when protecting IKEv1 >SAs. Agree. > > Proposed change to Roadmap doc: >> >> Add text to Section 5.5 - Pseudo-Random Functions (PRFs): >> >> For each IKEv2 SA, the peers negotiate both a PRF algorithm and an >> integrity-protection algorithm; the former is used to generate keying >> material and other values, and the latter is used to provide protection >> to the IKE SA's traffic. >> >> IKEv1's approach is more complicated. IKEv1 [RFC2409] does not specify >> any PRF algorithms. For each IKEv1 SA, the peers agree on an unkeyed >> hash function (e.g., SHA-1). IKEv1 uses the HMAC version of this function >> to generate keying material and to provide integrity protection for the >> IKE SA. > >Up to this it is fine. > >> If the peers want to use a PRF that is not an HMAC variant (e.g., >> AES-XCBC-PRF-128), they must negotiate both a PRF and a hash function. > >But I would remove all of these, and simply say that: > > Currently there is no PRF functions defined for IKEv1, thus only > PRFs which can be used are the HMAC versions of the unkeyed hash > functions. AES-XCBC-PRF-128 could be defined also in IKEv1, but as > there is no IANA number allocated for it, currently it cannot be > used in IKEv1. Partially agree. I would remove the proposed sentence and add nothing. There is no reason to go into detail about what we don't intend to do. > > If AES-XCBC-PRF-128 is the negotiated PRF, then IKEv1 would use > > AES-XCBC-PRF-128 (not truncated) as a PRF and AES-XCBC-MAC-96 (truncated) > > for integrity-protection. The negotiated hash algorithm would be used > > for example when generating the NAT-D [RFC3947] payloads. If an IKEv1 > > proposal includes a PRF algorithm but not a hash, it must be rejected, > > as specified in [RFC2409]. > >This text above, is something that should be in the RFC specifying the >PRF, not in this document, as it mostly seems to be clarification to >the RFC2409. I do not think this document can add this kind of almost >normative text for any other documents.. Very strongly agree. And the fact that it has not been asked for before now says that even thinking about it is unnecessary. > > NOTE: This solution would require adding an IANA value to the >> iana-ipsec-registry for AES-XCBC-PRF-128 > >If nobody has cared about using AES-XCBC-PRF-128 in protecting the >IKEv1 SA for 6 (or 11) years, I do not think people will start using >it now, thus I suggest we just say it cannot be used. A sentence that says "Therefore PRFs that are not HMACs cannot currently be used" sums up the current state of affairs succinctly --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Labelled IPsec
On Fri, Dec 04, 2009 at 12:09:50PM -0600, Joy Latten wrote: > I believe they are becoming more mainstream. For example, SELinux and > Simplified Mandatory Access Control (SMACK) in Linux Operating System > and Mandatory Integrity Control in Windows Vista. You forgot OpenSolaris Trusted Extensions (and their brand-new IPsec support): http://hub.opensolaris.org/bin/view/Project+txipsec/ The page needs an update, because the bits are now available for use. The bigger point being missed by this thread, I think, is that it seems that any work in multi-level security needs to deal with successful interoperability. If it doesn't, there's little point in documenting a single-platform solution as part of a working group's output. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Labelled IPsec
On Sun, 2009-11-29 at 19:59 -0500, Stephen Kent wrote: > I think that there has been insufficient discussion of whether those > who wish to make use of IPsec to enforce mandatory access controls > require the facilities described by the folks who have proposed this. > At the WG meeting 2 weeks ago I made two observations: > > - possible use of CIPSO for carrying labels had not been > fully discussed > - use of tunnel mode to protect such labels in the inner > header did not appear to have been considered The drafts do mention IPSO/CIPSO. They also acknowledge that FIPS-188 describe the use of free form tags that would allow additional security attributes. However, there is nothing protecting the data and heading, including the security context. Nor is anything preserving or protecting the bindings between the data and security context. Only IPSO is a standard and it was designed to support security labels used by DoD. Yes, I agree, tunnel mode could be used to protect the data, header, security context and thus bindings. However, it seem useful that, if you are going to deploy IPsec in a MAC environment, it included a mechanism to handle labels too. The method described in the labeled ipsec drafts was originally designed using ikev1. Perhaps thru further discussion this method could be refined and improved upon for ikev2. > I think it is incumbent on those who wish to pursue this work to > provide more persuasive arguments. It also seems appropriate to have > a discussion of whether mandatory, label-based controls are > sufficiently mainstream to warrant bringing them back into IPsec at > this time, or whether this is more of a research topic. > I believe they are becoming more mainstream. For example, SELinux and Simplified Mandatory Access Control (SMACK) in Linux Operating System and Mandatory Integrity Control in Windows Vista. However, I am also inclined to agree that at this time it could be argued to be more a research topic. regards, Joy ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Resolving Roadmap Issue #114
At 11:29 AM +0200 12/4/09, Tero Kivinen wrote: >Perhaps we should add some kind of advertisement here by changing the >last sentence to: > >"All of those problems and security issues have been solved in the >IKEv2, thus use of these non-standardized IKEv1 solutions is not >recommended." > >I.e. provide the a solution to the problem (use IKEv2) in addition to >just saying that "do not use them". Yes, that is an appropriate advertisement in the right place in the doc. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: WESP extensibility
I am interested in WESP Extension and would like to co-author it. Our interest in WESP extensions are to ease IPsec deployment within Intranet security AND Middle Boxes. We expect WESP would be able to provide Network administrators information related on IPsec and Middleboxes interactions. Regards, Daniel > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE
Frankel, Sheila E. writes: > This is an initial attempt to resolve Issue #113. We would > appreciate comments/suggestions/alternate approaches. > > #113: Use of AES-XCBC in IKE > > Currently, the Req levels are SHOULD for IKEv1 (based on RFC4109) > and optional for IKEv2. The Req levels for AES-XCBC-PRF are SHOULD > (based on RFC4109) and SHOULD+ for IKEv2 (RFC4307) > > This leaves us with 2 questions: > 1) If there is no IANA value for AES-XCBC in IKEv1, how can RFC4109 > recommend (SHOULD) its use? > 2) If AES-XCBC and AES-XCBC-PRF can be used in IKEv1, what should > be proposed? What should you propose if you want AES-XCBC for both > a PRF and an integrity-protection algorithm in IKEv1? I would say as we are talking here about the obsoleted IKEv1 protocol, and these problems have already been solved in the IKEv2, there is no need to do anything for IKEv1 registries. As nobody has yet to noticed that there is no number of AES-XCBC PRF for IKEv1, I assume nobody has implemented it. If it has not been implemented, then I do not think vendors will add implementation of it to the obsoleted IKEv1 protocol, thus there will never be implementations for it. Usually the hash/mac functions used to protect IKEv1 SA do not matter that much to users, they only care what algorithms are used in the IPsec SAs. Currently AES-XCBC-MAC-96 can be used in those contexts fine both in IKEv1 and IKEv2, thus there is no problem there. There is no need to get AES-XCBC PRF to work when protecting IKEv1 SAs. > Proposed change to Roadmap doc: > > Add text to Section 5.5 - Pseudo-Random Functions (PRFs): > > For each IKEv2 SA, the peers negotiate both a PRF algorithm and an > integrity-protection algorithm; the former is used to generate keying > material and other values, and the latter is used to provide protection > to the IKE SA's traffic. > > IKEv1's approach is more complicated. IKEv1 [RFC2409] does not specify > any PRF algorithms. For each IKEv1 SA, the peers agree on an unkeyed > hash function (e.g., SHA-1). IKEv1 uses the HMAC version of this function > to generate keying material and to provide integrity protection for the > IKE SA. Up to this it is fine. > If the peers want to use a PRF that is not an HMAC variant (e.g., > AES-XCBC-PRF-128), they must negotiate both a PRF and a hash function. But I would remove all of these, and simply say that: Currently there is no PRF functions defined for IKEv1, thus only PRFs which can be used are the HMAC versions of the unkeyed hash functions. AES-XCBC-PRF-128 could be defined also in IKEv1, but as there is no IANA number allocated for it, currently it cannot be used in IKEv1. > If AES-XCBC-PRF-128 is the negotiated PRF, then IKEv1 would use > AES-XCBC-PRF-128 (not truncated) as a PRF and AES-XCBC-MAC-96 (truncated) > for integrity-protection. The negotiated hash algorithm would be used > for example when generating the NAT-D [RFC3947] payloads. If an IKEv1 > proposal includes a PRF algorithm but not a hash, it must be rejected, > as specified in [RFC2409]. This text above, is something that should be in the RFC specifying the PRF, not in this document, as it mostly seems to be clarification to the RFC2409. I do not think this document can add this kind of almost normative text for any other documents.. > NOTE: This solution would require adding an IANA value to the > iana-ipsec-registry for AES-XCBC-PRF-128 If nobody has cared about using AES-XCBC-PRF-128 in protecting the IKEv1 SA for 6 (or 11) years, I do not think people will start using it now, thus I suggest we just say it cannot be used. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Resolving Roadmap Issue #114
Frankel, Sheila E. writes: > Issue #114: Expired drafts, especially BEET ... > Several Internet Drafts were written to address these problems: > Extended Authentication withn IKE (XAUTH) (draft-beaulieu-ike-xauth and > its predecessor draft-ietf-ipsra-isakmp-xauth) and The ISAKMP Configuration > Method (draft-dukes-ike-mode-cfg and its predecessor draft-ietf-ipsec-isakmp- > mode-cfg). These drafts did not progress to RFC status due to security > flaws and other problems related to these solutions. However, many current > IKEv1 implementations incorporate aspects of these solutions to facilitate > remote user access to corporate VPNs. These solutions were not standardized, > and different implementations implemented different versions. Thus, there > is no assurance that the implementations adhere fully to the suggested > solutions, or that one implementation can interoperate with others that > claim to incorporate the same features. Furthermore, these solutions have > known security issues. Thus, use of these solutions is not recommended. Perhaps we should add some kind of advertisement here by changing the last sentence to: "All of those problems and security issues have been solved in the IKEv2, thus use of these non-standardized IKEv1 solutions is not recommended." I.e. provide the a solution to the problem (use IKEv2) in addition to just saying that "do not use them". -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
