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: Labelled IPsec
On Fri, Dec 04, 2009 at 12:09:50PM -0600, Joy Latten wrote: SNIP! 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] Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE
no hat 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 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
[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. ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-04.txt ___ 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
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: 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
