Valery Smyslov writes: > Yes, there is no obvious mapping between ID_KEY_ID and certificates and > thus ID_KEY_ID is out of scope for RFC4945.
As rfc5996 describes ID_KEY_ID as "An opaque octet stream that may be used to pass vendor-specific information necessary to do certain proprietary types of identification." I see no problem that it is not in the RFC4945. It is intended for the vendor-specific information so no standard mapping is provided, vendor will decide one for it. > And this not the only contradiction between RFC5996 and RFC4945 - > the latter requires ID_IPV*_ADDR to match source IP address of IKE > packet by default, while the former explicitely allows not to do it > in any case. RFC4945 requires that implementations "MUST be capable of verifying" the ID_IPV*_ADDR and IP-address of the packet. RFC5996 says that IKEv2 does not require such check. There is no contradiction there. All of that is mostly because in IKEv1 that check was always done, and people considered it important to be done. In IKEv2 we realized that kind of test does not really help, and can cause some problems in some scenarios, so that check was explictly said not to be required anymore. The RFC4945 parts are shared with IKEv1 and IKEv2, thus they set the same requirements for it, but IKEv2 implementation can be conformant with both of them, i.e provide option to disable that check, and make it so that by default the checks are done (to be conformant to RFC4945), but allow those test to be disabled (as is allowed in the RFC5996). > But I still believe that adding a few words about matching ID to > certificates, or point to RFC4945 (probably with some explanation > text) will still be useful for not so experienced RFC readers as the > members of this list. Yes adding reference to the RFC4945 might be useful, it was not done in the RFC4306 as the RFC4945 was not ready at that time. Most likely we should have added it when doing RFC5996 but we didn't. Perhaps adding reference to the RFC4945 at the end of section 3.5. Identification Payloads in the RFC5996bis? -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
