The IESG has approved the following document: - 'The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX ' <draft-ietf-pki4ipsec-ikecert-profile-12.txt> as a Proposed Standard This document is the product of the Profiling Use of PKI in IPSEC Working Group. The IESG contact persons are Russ Housley and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pki4ipsec-ikecert-profile-12.txt Technical Summary This document specifies a profile for the use of Certificates for identification in the IKEv1 and IKEv2 protocols. These protocols say very little about the certificates, and a fair amount of industry practice has built up around bake-offs and interop events over the last 8 years. This profile captures the best of those practices. It is targeted to two main audiences: implementors who are building interoperable products, and deployers who need to know how to configure the systems. The profile also provides guidance to the PKI community about the needs of the IPsec VPN application. Working Group Summary The initial draft came from IPsec WG, and was completed in the PKI4IPsec WG. An issue tracker was used to make sure that all issues were addressed. The PKI4IPsec WG has strong consensus that this document should be published as a Proposed Standard. Protocol Quality Every mid- to large-size IPsec implementation supports this profile, and at least four PKI vendors support this profile. This document was reviewed by Russ Housley for the IESG. Note to RFC Editor In section 3.1.1, please make the following change: OLD: In addition, implementations MUST be capable of verifying that the address contained in the ID is the same as the peer source address, contained in the outer most IP header. NEW: In addition, implementations MUST be capable of verifying that the address contained in the ID is the same as the address contained in the IP header. Implementations SHOULD be able to check the address in either the outermost or innermost IP header and MAY provide a configuration option for specifying which is to be checked. If there is no configuration option provided, an implementation SHOULD check the peer source address contained in the outermost header (as is the practice of most of today's implementations). In section 5.1.3.12, please make the following change: OLD: A summary of the logic flow for peer certificate validation regarding the EKU extension follows: NEW: Conforming IKE implementations are not required to support EKU. If a critical EKU extension appears in a certificate and EKU is not supported by the implementation, then RFC 3280 requires that the certificate be rejected. Implementations that do support EKU MUST support the following logic for certificate validation: _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
