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: