ipsec September 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] Populating ID_DER_ASN1_DN

Re: [IPsec] Populating ID_DER_ASN1_DN

From: Yoav Nir <ynir_at_nospam>
Date: Thu Sep 17 2009 - 06:50:09 GMT
To: David Wierbowski <wierbows@us.ibm.com>

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

    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