By the time we re-spin RFC 4945, and I'm not saying that we will, it will look silly specifying stuff for IKEv1, so that section will probably be omitted.
On Sep 17, 2009, at 11:48 PM, David Wierbowski wrote: Yoav (and also Raj), Thanks for the clarification. The text in 4301 makes sense. What I do not agree with is the text in 4945 that requires implementations MUST be able to perform matching based on a bitwise comparison of the entire DN in ID to its entry in the SPD. I can agree with saying that implementations MUST be able to perform matching of the entire DN in ID to its entry in the SPD. It's the "based on a bitwise comparison" that I do not agree with. It should be up to the implementation to decide if it wants to do a bitwise match or use normal x.500 DN matching rules. It's certainly not an interoperability issue if I decide to use x.500 DN matching rules to do the lookup. Anything that's a binary match will be a match using x.500 DN matching rules. There's no security issue using x500 matching rules. Since we aren't doing a revision of RFC 4945 it's a moot point. If we ever do re-spin 4945 then it's a requirement that I think could be relaxed. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 <graycol.gif>Yoav Nir ---09/17/2009 02:50:34 AM---On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote: > Section 3.1.5 of RFC 4945 states that when ge <ecblank.gif> From: <ecblank.gif> Yoav Nir <y...@checkpoint.com<mailto:y...@checkpoint.com>> <ecblank.gif> To: <ecblank.gif> David Wierbowski/Endicott/i...@ibmus <ecblank.gif> Cc: <ecblank.gif> "ipsec@ietf.org<mailto:ipsec@ietf.org>" <ipsec@ietf.org<mailto:ipsec@ietf.org>> <ecblank.gif> Date: <ecblank.gif> 09/17/2009 02:50 AM <ecblank.gif> Subject: <ecblank.gif> Re: [IPsec] Populating ID_DER_ASN1_DN <ecblank.gif> Sent by: <ecblank.gif> ipsec-boun...@ietf.org<mailto:ipsec-boun...@ietf.org> ________________________________ On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote: > Section 3.1.5 of RFC 4945 states that when generating an ID type of > ID_DER_ASN1_DN that "implementations MUST populate the contents of > ID with the Subject field from the end-entity certificate, and MUST > do so such that a binary comparison of the two will succeed." > Section 3.1.5 is specific to IKEv1. There is no such requirement > listed in Section 4 which is applicable to IKEv2. > > What is the purpose of this requirement and why is it only > applicable to IKEv1? > > I believe in the past it has been said that the requirement exists > because smaller devices may not be capable of performing DN > matching. If that's the case it seems the issue would be applicable > to IKEv2 as well. > > Section Section 3.1.5 also states, "Regarding SPD matching, > implementations MUST be able to perform matching based on a bitwise > comparison of the entire DN in ID to its entry in the SPD. However, > operational experience has shown that using the entire DN in local > configuration is difficult, especially in large-scale deployments. > Therefore, implementations also MUST be able to perform SPD matches > of any combination of one or more of the C, CN, O, OU attributes > within Subject DN in the ID to the same in the SPD." > > What is the purpose of requiring the ability to match on a bitwise > comparison of the entire DN if it is also acceptable to match any > combination of one or more of the C, CN, O, OU attributes? It seems > that only implementing the second MUST would be sufficient. If the > ID matches a bitwise comparison of the entire DN it will also match > a combination of one or more of the C, CN, O, OU attributes. > > > Dave Wierbowski > > Hi Dave. The difference here is not between IKEv1 and IKEv2, but with the difference between the two versions of IPsec, as in RFC 2401 vs 4301. RFC 4301 did a far better job of specifying the relationship between PAD entries and the IKE IDs, so it was not necessary for RFC 4945 to specify this. Section 4.4.3 discusses this thoroughly, especially this paragraph from 4.4.3.2: This document does not require that the IKE ID asserted by a peer be syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. However, it often will be appropriate to impose such a requirement, e.g., when a single entry represents a set of peers each of whom may have a distinct SPD entry. Thus, implementations MUST provide a means for an administrator to require a match between an asserted IKE ID and the subject name or subject alt name in a certificate. The former is applicable to IKE IDs expressed as distinguished names; the latter is appropriate for DNS names, RFC 822 e-mail addresses, and IP addresses. So it looks like RFC 4301 has pretty much said this already. _______________________________________________ IPsec mailing list IPsec@ietf.org<mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org<mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
