Hi David, On Thu, Sep 17, 2009 at 8:03 AM, David Wierbowski <wierb...@us.ibm.com>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. > > > The entire match is required for tighter security and one certificate not being used by many users (if they have exportable private keys). Normally, CN contains info which is specific to the certificate users. If we match only O, OU that will be same for whole organization. In this case User A who has exportable private key can share it's certificate with User B and authentication will be successful. This is just one of case. > Dave Wierbowski > > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Thanks, Raj
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
