The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
RFC 4945

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    pki4ipsec mailing list <pki4ipsec@icsalabs.com>, 
    pki4ipsec chair <pki4ipsec-chairs@tools.ietf.org>
Subject: Protocol Action: 'The Internet IP Security PKI Profile 
         of IKEv1/ISAKMP, IKEv2, and PKIX' to Proposed Standard 

The IESG has approved the following document:

- 'The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX '
   <draft-ietf-pki4ipsec-ikecert-profile-13.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 Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pki4ipsec-ikecert-profile-13.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: