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

[IPsec] Populating ID_DER_ASN1_DN

From: David Wierbowski <wierbows_at_nospam>
Date: Thu Sep 17 2009 - 02:33:14 GMT
To: ipsec@ietf.org

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



IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec