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
https://www.ietf.org/mailman/listinfo/ipsec
