< draft-ietf-pki4ipsec-ikecert-profile-04.txt   draft-ietf-pki4ipsec-ikecert-profile-05.txt >
pki4ipsec B. Korver pki4ipsec B. Korver
Internet-Draft Xythos Software, Inc. Internet-Draft Network Resonance, Inc.
Expires: June 4, 2005 December 2004 Expires: January 28, 2006 July 27, 2005
The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
draft-ietf-pki4ipsec-ikecert-profile-04 draft-ietf-pki4ipsec-ikecert-profile-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 4, 2005. This Internet-Draft will expire on January 28, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
IKE and PKIX both provide frameworks that must be profiled for use in IKE and PKIX both provide frameworks that must be profiled for use in
a given application. This document provides a profile of IKE and a given application. This document provides a profile of IKE and
PKIX that defines the requirements for using PKI technology in the PKIX that defines the requirements for using PKI technology in the
context of IKE/IPsec. The document complements protocol context of IKE/IPsec. The document complements protocol
specifications such as IKEv1 and IKEv2, which assume the existence of specifications such as IKEv1 and IKEv2, which assume the existence of
public key certificates and related keying materials, but which do public key certificates and related keying materials, but which do
not address PKI issues explicitly. This document addresses those not address PKI issues explicitly. This document addresses those
skipping to change at page 2, line 24 skipping to change at page 2, line 23
3.1.3 ID_USER_FQDN . . . . . . . . . . . . . . . . . . . . . 10 3.1.3 ID_USER_FQDN . . . . . . . . . . . . . . . . . . . . . 10
3.1.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, 3.1.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET,
ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE . . . . . . . . 11 ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE . . . . . . . . 11
3.1.5 ID_DER_ASN1_DN . . . . . . . . . . . . . . . . . . . . 11 3.1.5 ID_DER_ASN1_DN . . . . . . . . . . . . . . . . . . . . 11
3.1.6 ID_DER_ASN1_GN . . . . . . . . . . . . . . . . . . . . 12 3.1.6 ID_DER_ASN1_GN . . . . . . . . . . . . . . . . . . . . 12
3.1.7 ID_KEY_ID . . . . . . . . . . . . . . . . . . . . . . 12 3.1.7 ID_KEY_ID . . . . . . . . . . . . . . . . . . . . . . 12
3.1.8 Selecting an Identity from a Certificate . . . . . . . 12 3.1.8 Selecting an Identity from a Certificate . . . . . . . 12
3.1.9 SubjectName for DN Only . . . . . . . . . . . . . . . 12 3.1.9 SubjectName for DN Only . . . . . . . . . . . . . . . 12
3.1.10 Binding Identity to Policy . . . . . . . . . . . . . 13 3.1.10 Binding Identity to Policy . . . . . . . . . . . . . 13
3.2 Certificate Request Payload . . . . . . . . . . . . . . . 13 3.2 Certificate Request Payload . . . . . . . . . . . . . . . 13
3.2.1 Certificate Type . . . . . . . . . . . . . . . . . . . 13 3.2.1 Certificate Type . . . . . . . . . . . . . . . . . . . 14
3.2.2 X.509 Certificate - Signature . . . . . . . . . . . . 14 3.2.2 X.509 Certificate - Signature . . . . . . . . . . . . 14
3.2.3 Revocation Lists (CRL and ARL) . . . . . . . . . . . . 14 3.2.3 Revocation Lists (CRL and ARL) . . . . . . . . . . . . 14
3.2.4 PKCS #7 wrapped X.509 certificate . . . . . . . . . . 15 3.2.4 PKCS #7 wrapped X.509 certificate . . . . . . . . . . 15
3.2.5 IKEv2's Hash and URL of X.509 certificate . . . . . . 15 3.2.5 IKEv2's Hash and URL of X.509 certificate . . . . . . 15
3.2.6 Location of Certificate Payloads . . . . . . . . . . . 15 3.2.6 Location of Certificate Payloads . . . . . . . . . . . 15
3.2.7 Presence or Absence of Certificate Request Payloads . 15 3.2.7 Presence or Absence of Certificate Request Payloads . 16
3.2.8 Certificate Requests . . . . . . . . . . . . . . . . . 16 3.2.8 Certificate Requests . . . . . . . . . . . . . . . . . 16
3.2.9 Robustness . . . . . . . . . . . . . . . . . . . . . . 18 3.2.9 Robustness . . . . . . . . . . . . . . . . . . . . . . 18
3.2.10 Optimizations . . . . . . . . . . . . . . . . . . . 18 3.2.10 Optimizations . . . . . . . . . . . . . . . . . . . 18
3.3 Certificate Payload . . . . . . . . . . . . . . . . . . . 19 3.3 Certificate Payload . . . . . . . . . . . . . . . . . . . 19
3.3.1 Certificate Type . . . . . . . . . . . . . . . . . . . 20 3.3.1 Certificate Type . . . . . . . . . . . . . . . . . . . 20
3.3.2 X.509 Certificate - Signature . . . . . . . . . . . . 20 3.3.2 X.509 Certificate - Signature . . . . . . . . . . . . 21
3.3.3 Revocation Lists (CRL and ARL) . . . . . . . . . . . . 20 3.3.3 Revocation Lists (CRL and ARL) . . . . . . . . . . . . 21
3.3.4 IKEv2's Hash and URL of X.509 Certificate . . . . . . 21 3.3.4 IKEv2's Hash and URL of X.509 Certificate . . . . . . 21
3.3.5 PKCS #7 wrapped X.509 certificate . . . . . . . . . . 21 3.3.5 PKCS #7 wrapped X.509 certificate . . . . . . . . . . 21
3.3.6 Location of Certificate Payloads . . . . . . . . . . . 21 3.3.6 Location of Certificate Payloads . . . . . . . . . . . 21
3.3.7 Certificate Payloads Not Mandatory . . . . . . . . . . 21 3.3.7 Certificate Payloads Not Mandatory . . . . . . . . . . 22
3.3.8 Response to Multiple Certification Authority 3.3.8 Response to Multiple Certification Authority
Proposals . . . . . . . . . . . . . . . . . . . . . . 22 Proposals . . . . . . . . . . . . . . . . . . . . . . 22
3.3.9 Using Local Keying Materials . . . . . . . . . . . . . 22 3.3.9 Using Local Keying Materials . . . . . . . . . . . . . 22
3.3.10 Multiple End-Entity Certificates . . . . . . . . . . 22 3.3.10 Multiple End-Entity Certificates . . . . . . . . . . 22
3.3.11 Robustness . . . . . . . . . . . . . . . . . . . . . 22 3.3.11 Robustness . . . . . . . . . . . . . . . . . . . . . 23
3.3.12 Optimizations . . . . . . . . . . . . . . . . . . . 24 3.3.12 Optimizations . . . . . . . . . . . . . . . . . . . 24
4. Profile of PKIX . . . . . . . . . . . . . . . . . . . . . . 24 4. Profile of PKIX . . . . . . . . . . . . . . . . . . . . . . 24
4.1 X.509 Certificates . . . . . . . . . . . . . . . . . . . . 24 4.1 X.509 Certificates . . . . . . . . . . . . . . . . . . . . 24
4.1.1 Versions . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.1 Versions . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2 SubjectName . . . . . . . . . . . . . . . . . . . . . 25 4.1.2 SubjectName . . . . . . . . . . . . . . . . . . . . . 25
4.1.3 X.509 Certificate Extensions . . . . . . . . . . . . . 25 4.1.3 X.509 Certificate Extensions . . . . . . . . . . . . . 25
4.2 X.509 Certificate Revocation Lists . . . . . . . . . . . . 31 4.2 X.509 Certificate Revocation Lists . . . . . . . . . . . . 31
4.2.1 Multiple Sources of Certificate Revocation 4.2.1 Multiple Sources of Certificate Revocation
Information . . . . . . . . . . . . . . . . . . . . . 31 Information . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 X.509 Certificate Revocation List Extensions . . . . . 32 4.2.2 X.509 Certificate Revocation List Extensions . . . . . 32
5. Configuration Data Exchange Conventions . . . . . . . . . . 33 5. Configuration Data Exchange Conventions . . . . . . . . . . 33
5.1 Certificates . . . . . . . . . . . . . . . . . . . . . . . 33 5.1 Certificates . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 CRLs and ARLs . . . . . . . . . . . . . . . . . . . . . . 33 5.2 CRLs and ARLs . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Public Keys . . . . . . . . . . . . . . . . . . . . . . . 34 5.3 Public Keys . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 PKCS#10 Certificate Signing Requests . . . . . . . . . . . 34 5.4 PKCS#10 Certificate Signing Requests . . . . . . . . . . . 34
6. Security Considerations . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . 34
6.1 Certificate Request Payload . . . . . . . . . . . . . . . 34 6.1 Certificate Request Payload . . . . . . . . . . . . . . . 34
6.2 IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 34 6.2 IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 34
7. Intellectual Property Rights . . . . . . . . . . . . . . . . 34 7. Intellectual Property Rights . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1 Normative References . . . . . . . . . . . . . . . . . . . 35 9.1 Normative References . . . . . . . . . . . . . . . . . . . 35
9.2 Informative References . . . . . . . . . . . . . . . . . . 35 9.2 Informative References . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . 36
A. Change History . . . . . . . . . . . . . . . . . . . . . . . 36 A. Change History . . . . . . . . . . . . . . . . . . . . . . . 36
B. The Possible Dangers of Delta CRLs . . . . . . . . . . . . . 43 B. The Possible Dangers of Delta CRLs . . . . . . . . . . . . . 43
C. More on Empty CERTREQs . . . . . . . . . . . . . . . . . . . 43 C. More on Empty CERTREQs . . . . . . . . . . . . . . . . . . . 44
D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . 47
1. Introduction 1. Introduction
IKE [1], ISAKMP [2] and IKEv2 [3] provide a secure key exchange IKE [1], ISAKMP [2] and IKEv2 [3] provide a secure key exchange
mechanism for use with IPsec [4]. In many cases the peers mechanism for use with IPsec [4]. In many cases the peers
authenticate using digital certificates as specified in PKIX [5]. authenticate using digital certificates as specified in PKIX [5].
Unfortunately, the combination of these standards leads to an Unfortunately, the combination of these standards leads to an
underspecified set of requirements for the use of certificates in the underspecified set of requirements for the use of certificates in the
context of IPsec. context of IPsec.
skipping to change at page 6, line 45 skipping to change at page 6, line 45
KEY_ID | MUST NOT | n/a | n/a | n/a KEY_ID | MUST NOT | n/a | n/a | n/a
| | | | | | | |
[1] = Implementation MUST have the configuration option to send this [1] = Implementation MUST have the configuration option to send this
ID type in the ID payload. Whether or not the ID type is used is a ID type in the ID payload. Whether or not the ID type is used is a
matter of local configuration. matter of local configuration.
[2] = The ID in the ID payload MUST match the contents of the [2] = The ID in the ID payload MUST match the contents of the
corresponding field (listed) in the certificate exactly, with no corresponding field (listed) in the certificate exactly, with no
other lookup. The matched ID MAY be used for SPD lookup, but is not other lookup. The matched ID MAY be used for SPD lookup, but is not
required to be used for this. required to be used for this. See 2401bis [10], section 4.4.3.2 for
more details.
[3] = At a minimum, Implementation MUST be capable of being [3] = At a minimum, Implementation MUST be capable of being
configured to perform exact matching of the ID payload contents to an configured to perform exact matching of the ID payload contents to an
entry in the local SPD. entry in the local SPD.
[4] = In addition, the implementation MAY also be configurable to [4] = In addition, the implementation MAY also be configurable to
perform substring or wildcard matches of ID payload contents to perform substring or wildcard matches of ID payload contents to
entries in the local SPD. (More on this in Section 3.1.5). entries in the local SPD. (More on this in Section 3.1.5).
When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN,
skipping to change at page 7, line 46 skipping to change at page 7, line 48
3.1.1 ID_IPV4_ADDR and ID_IPV6_ADDR 3.1.1 ID_IPV4_ADDR and ID_IPV6_ADDR
Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR
ID type, depending on whether the implementation supports IPv4, IPv6 ID type, depending on whether the implementation supports IPv4, IPv6
or both. These addresses MUST be encoded in "network byte order," as or both. These addresses MUST be encoded in "network byte order," as
specified in IP [8]: The least significant bit (LSB) of each octet is specified in IP [8]: The least significant bit (LSB) of each octet is
the LSB of the corresponding byte in the network address. For the the LSB of the corresponding byte in the network address. For the
ID_IPV4_ADDR type, the payload MUST contain exactly four octets [8]. ID_IPV4_ADDR type, the payload MUST contain exactly four octets [8].
For the ID_IPV6_ADDR type, the payload MUST contain exactly sixteen For the ID_IPV6_ADDR type, the payload MUST contain exactly sixteen
octets [10]. octets [11].
Implementations SHOULD NOT populate ID payload with IP addresses due Implementations SHOULD NOT populate ID payload with IP addresses due
to interoperability issues such as problems with NAT traversal, and to interoperability issues such as problems with NAT traversal, and
problems with IP verification behavior. problems with IP verification behavior.
Deployments may only want to consider using the IP address as ID if Deployments may only want to consider using the IP address as ID if
the following are true: the following are true:
o the peer's IP address is static, not dynamically changing o the peer's IP address is static, not dynamically changing
o the peer is NOT behind a NAT'ing device o the peer is NOT behind a NAT'ing device
skipping to change at page 8, line 26 skipping to change at page 8, line 26
presented in ID matches via bitwise comparison the IP address present presented in ID matches via bitwise comparison the IP address present
in the certificate's iPAddress field of the SubjectAltName extension. in the certificate's iPAddress field of the SubjectAltName extension.
Implementations MUST perform this verification by default. When Implementations MUST perform this verification by default. When
comparing the contents of ID with the iPAddress field in the comparing the contents of ID with the iPAddress field in the
SubjectAltName extension for equality, binary comparison MUST be SubjectAltName extension for equality, binary comparison MUST be
performed. Note that certificates may contain multiple address performed. Note that certificates may contain multiple address
identity types in which case at least one must match the source IP. identity types in which case at least one must match the source IP.
If the default is enabled, then a mismatch between the two addresses If the default is enabled, then a mismatch between the two addresses
MUST be treated as an error and security association setup MUST be MUST be treated as an error and security association setup MUST be
aborted. This event SHOULD be auditable. Implementations MAY aborted. This event SHOULD be auditable. Implementations MAY
provide a configuration option to (i.e. local policy configuration provide a configuration option to (i.e. local policy configuration
can enable) skip that verification step, but that option MUST be off can enable) skip that verification step, but that option MUST be off
by default. We include the "option-to-skip-validation" in order to by default. We include the "option-to-skip-validation" in order to
permit better interoperability, as today implementations vary greatly permit better interoperability, as today implementations vary greatly
in how they behave on this topic. in how they behave on this topic.
In addition, implementations MUST be capable of verifying that the In addition, implementations MUST be capable of verifying that the
address contained in the ID is the same as the peer source address, address contained in the ID is the same as the peer source address,
contained in the outer most IP header. If ID is one of the IP contained in the outer most IP header. If ID is one of the IP
address types, then implementations MUST perform this verification by address types, then implementations MUST perform this verification by
default. If this default is enabled, then a mismatch MUST be treated default. If this default is enabled, then a mismatch MUST be treated
as an error and security association setup MUST be aborted. This as an error and security association setup MUST be aborted. This
event SHOULD be auditable. Implementations MAY provide a event SHOULD be auditable. Implementations MAY provide a
configuration option to (i.e. local policy configuration can enable) configuration option to (i.e. local policy configuration can enable)
skip that verification step, but that option MUST be off by default. skip that verification step, but that option MUST be off by default.
We include the "option-to-skip-validation" in order to permit better We include the "option-to-skip-validation" in order to permit better
interoperability, as today implementations vary greatly in how they interoperability, as today implementations vary greatly in how they
behave on the topic of verification of source IP. behave on the topic of verification of source IP.
If the default for both the verifications above are enabled, then, by If the default for both the verifications above are enabled, then, by
transitive property, the implementation will also be verifying that transitive property, the implementation will also be verifying that
the peer source IP address matches via a bitwise comparison the the peer source IP address matches via a bitwise comparison the
contents of the iPAddress field in the SubjectAltName extension in contents of the iPAddress field in the SubjectAltName extension in
the certificate. In addition, implementations MAY allow the certificate. In addition, implementations MAY allow
skipping to change at page 9, line 42 skipping to change at page 9, line 42
address, but until the identity (address) is validated by validating address, but until the identity (address) is validated by validating
the peer certificate, the policy MUST NOT be used to authorize any the peer certificate, the policy MUST NOT be used to authorize any
IPsec traffic. IPsec traffic.
3.1.2 ID_FQDN 3.1.2 ID_FQDN
Implementations MUST support the ID_FQDN ID type, generally to Implementations MUST support the ID_FQDN ID type, generally to
support host-based access control lists for hosts without fixed IP support host-based access control lists for hosts without fixed IP
addresses. However, implementations SHOULD NOT use the DNS to map addresses. However, implementations SHOULD NOT use the DNS to map
the FQDN to IP addresses for input into any policy decisions, unless the FQDN to IP addresses for input into any policy decisions, unless
that mapping is known to be secure, for example if DNSSEC [11] were that mapping is known to be secure, for example if DNSSEC [12] were
employed. employed.
If ID contains an ID_FQDN, implementations MUST be capable of If ID contains an ID_FQDN, implementations MUST be capable of
verifying that the identity contained in the ID payload matches verifying that the identity contained in the ID payload matches
identity information contained in the peer end-entity certificate, in identity information contained in the peer end-entity certificate, in
the dNSName field in the SubjectAltName extension. Implementations the dNSName field in the SubjectAltName extension. Implementations
MUST perform this verification by default. When comparing the MUST perform this verification by default. When comparing the
contents of ID with the dNSName field in the SubjectAltName extension contents of ID with the dNSName field in the SubjectAltName extension
for equality, caseless string comparison MUST be performed. for equality, caseless string comparison MUST be performed.
Substring, wildcard, or regular expression matching MUST NOT be Substring, wildcard, or regular expression matching MUST NOT be
performed for this comparison. If this default is enabled, then a performed for this comparison. If this default is enabled, then a
mismatch MUST be treated as an error and security association setup mismatch MUST be treated as an error and security association setup
MUST be aborted. This event SHOULD be auditable. Implementations MUST be aborted. This event SHOULD be auditable. Implementations
MAY provide a configuration option to (i.e. local policy MAY provide a configuration option to (i.e. local policy
configuration can enable) skip that verification step, but that configuration can enable) skip that verification step, but that
option MUST be off by default. We include the option MUST be off by default. We include the "option-to-skip-
"option-to-skip-validation" in order to permit better validation" in order to permit better interoperability, as today
interoperability, as today implementations vary greatly in how they implementations vary greatly in how they behave on this topic.
behave on this topic.
Implementations MAY support substring, wildcard, or regular Implementations MAY support substring, wildcard, or regular
expression matching of the contents of ID to lookup policy in the expression matching of the contents of ID to lookup policy in the
SPD, and such would be a matter of local security policy SPD, and such would be a matter of local security policy
configuration. configuration.
3.1.3 ID_USER_FQDN 3.1.3 ID_USER_FQDN
Implementations MUST support the ID_USER_FQDN ID type, generally to Implementations MUST support the ID_USER_FQDN ID type, generally to
support user-based access control lists for users without fixed IP support user-based access control lists for users without fixed IP
addresses. However, implementations SHOULD NOT use the DNS to map addresses. However, implementations SHOULD NOT use the DNS to map
the FQDN portion to IP addresses for input into any policy decisions, the FQDN portion to IP addresses for input into any policy decisions,
unless that mapping is known to be secure, for example if DNSSEC [11] unless that mapping is known to be secure, for example if DNSSEC [12]
were employed. were employed.
Implementations MUST be capable of verifying that the identity Implementations MUST be capable of verifying that the identity
contained in the ID payload matches identity information contained in contained in the ID payload matches identity information contained in
the peer end-entity certificate, in the rfc822Name field in the the peer end-entity certificate, in the rfc822Name field in the
SubjectAltName extension. Implementations MUST perform this SubjectAltName extension. Implementations MUST perform this
verification by default. When comparing the contents of ID with the verification by default. When comparing the contents of ID with the
rfc822Name field in the SubjectAltName extension for equality, rfc822Name field in the SubjectAltName extension for equality,
caseless string comparison MUST be performed. Substring, wildcard, caseless string comparison MUST be performed. Substring, wildcard,
or regular expression matching MUST NOT be performed for this or regular expression matching MUST NOT be performed for this
comparison. If this default is enabled, then a mismatch MUST be comparison. If this default is enabled, then a mismatch MUST be
treated as an error and security association setup MUST be aborted. treated as an error and security association setup MUST be aborted.
This event SHOULD be auditable. Implementations MAY provide a This event SHOULD be auditable. Implementations MAY provide a
configuration option to (i.e. local policy configuration can enable) configuration option to (i.e. local policy configuration can enable)
skip that verification step, but that option MUST be off by default. skip that verification step, but that option MUST be off by default.
We include the "option-to-skip-validation" in order to permit better We include the "option-to-skip-validation" in order to permit better
interoperability, as today implementations vary greatly in how they interoperability, as today implementations vary greatly in how they
behave on this topic. behave on this topic.
Implementations MAY support substring, wildcard, or regular Implementations MAY support substring, wildcard, or regular
expression matching of the contents of ID to lookup policy in the expression matching of the contents of ID to lookup policy in the
SPD, and such would be a matter of local security policy SPD, and such would be a matter of local security policy
configuration. configuration.
3.1.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, 3.1.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE,
ID_IPV6_ADDR_RANGE ID_IPV6_ADDR_RANGE
Historically there was no standard method for putting address subnet Historically there was no standard method for putting address subnet
or range identity information into certificates, nor are there any or range identity information into certificates, nor are there any
implementations known to support these ID types. Therefore, use of implementations known to support these ID types. Therefore, use of
these ID types is currently undefined. Implementations MUST NOT these ID types is currently undefined. Implementations MUST NOT
generate these ID types. generate these ID types.
Note that work in SBGP [12] for defining blocks of addresses using Note that work in SBGP [13] for defining blocks of addresses using
the certificate extension identified by: the certificate extension identified by:
id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
is experimental at this time. is experimental at this time.
3.1.5 ID_DER_ASN1_DN 3.1.5 ID_DER_ASN1_DN
Implementations MUST support receiving the ID_DER_ASN1_DN ID type. Implementations MUST support receiving the ID_DER_ASN1_DN ID type.
Implementations MUST be capable of generating this type, and the Implementations MUST be capable of generating this type, and the
decision to do so will be a matter of local security policy decision to do so will be a matter of local security policy
configuration. When generating this type, implementations MUST configuration. When generating this type, implementations MUST
populate the contents of ID with the SubjectName from the end-entity populate the contents of ID with the SubjectName from the end-entity
certificate, and MUST do so such that a binary comparison of the two certificate, and MUST do so such that a binary comparison of the two
will succeed. If there is not a match, this MUST be treated as an will succeed. If there is not a match, this MUST be treated as an
error and security association setup MUST be aborted. This event error and security association setup MUST be aborted. This event
SHOULD be auditable. Note, if the certificate was erroneously SHOULD be auditable. Note, if the certificate was erroneously
created such that the encoding of the SubjectName DN varies from the created such that the encoding of the SubjectName DN varies from the
constraints set by DER, that non-conformant DN MUST be used to constraints set by DER, that non-conformant DN MUST be used to
populate the ID payload: in other words, implementations MUST NOT populate the ID payload: in other words, implementations MUST NOT re-
re-encode the DN for the purposes of making it DER if it does not encode the DN for the purposes of making it DER if it does not appear
appear in the certificate as DER. in the certificate as DER.
Implementations MUST NOT populate ID with the SubjectName from the Implementations MUST NOT populate ID with the SubjectName from the
end-entity certificate if it is empty, even though an empty end-entity certificate if it is empty, even though an empty
certificate SubjectName is explicitly allowed in the "Subject" certificate SubjectName is explicitly allowed in the "Subject"
section of PKIX. section of PKIX.
Regarding SPD matching, implementations MUST be able to perform Regarding SPD matching, implementations MUST be able to perform
matching based on a bitwise comparison of the entire DN in ID to its matching based on a bitwise comparison of the entire DN in ID to its
entry in the SPD. However, operational experience has shown that entry in the SPD. However, operational experience has shown that
using the entire DN in local configuration is difficult, especially using the entire DN in local configuration is difficult, especially
skipping to change at page 13, line 40 skipping to change at page 13, line 40
In the event the policy cannot be found in the recipient's SPD using In the event the policy cannot be found in the recipient's SPD using
the ID sent, then the recipient MAY use the other identities in the the ID sent, then the recipient MAY use the other identities in the
certificate when attempting to match a suitable policy. For example, certificate when attempting to match a suitable policy. For example,
say the certificate contains non-empty SubjectName, a dNSName and an say the certificate contains non-empty SubjectName, a dNSName and an
iPAddress. If an iPAddress is sent in ID but no specific entry iPAddress. If an iPAddress is sent in ID but no specific entry
exists for the address in the policy database, the recipient MAY exists for the address in the policy database, the recipient MAY
search in the policy database based on the SubjectName or the dNSName search in the policy database based on the SubjectName or the dNSName
contained in the certificate. contained in the certificate.
The Peer Authorization Database (PAD) as described in 2401bis [10]
provides a more formal model for the binding of identity to policy in
addition to providing services that deal more specifically with the
details of policy enforcement, which are generally out of scope of
this document. The PAD is intended to provide a link between the SPD
and the security association management in protocols such as IKE.
See 2401bis [10], section 4.4.3 for more details.
3.2 Certificate Request Payload 3.2 Certificate Request Payload
The Certificate Request (CERTREQ) Payload allows an implementation to The Certificate Request (CERTREQ) Payload allows an implementation to
request that a peer provide some set of certificates or certificate request that a peer provide some set of certificates or certificate
revocation lists. It is not clear from ISAKMP exactly how that set revocation lists. It is not clear from ISAKMP exactly how that set
should be specified or how the peer should respond. We describe the should be specified or how the peer should respond. We describe the
semantics on both sides. semantics on both sides.
3.2.1 Certificate Type 3.2.1 Certificate Type
skipping to change at page 15, line 4 skipping to change at page 15, line 12
In lieu of exchanging revocation lists in-band, a pointer to In lieu of exchanging revocation lists in-band, a pointer to
revocation checking SHOULD be listed in either the revocation checking SHOULD be listed in either the
CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA) CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA)
certificate extensions (see Section 4 for details). Unless other certificate extensions (see Section 4 for details). Unless other
methods for obtaining revocation information are available, methods for obtaining revocation information are available,
implementations SHOULD be able to process these attributes, and from implementations SHOULD be able to process these attributes, and from
them be able to identify cached revocation material, or retrieve the them be able to identify cached revocation material, or retrieve the
relevant revocation material from a URL, for validation processing. relevant revocation material from a URL, for validation processing.
In addition, implementations MUST have the ability to configure In addition, implementations MUST have the ability to configure
validation checking information for each certification authority. validation checking information for each certification authority.
Regardless of the method (CDP, AIA, or static configuration), the Regardless of the method (CDP, AIA, or static configuration), the
acquisition of revocation material SHOULD occur out-of-band of IKE. acquisition of revocation material SHOULD occur out-of-band of IKE.
3.2.4 PKCS #7 wrapped X.509 certificate 3.2.4 PKCS #7 wrapped X.509 certificate
This ID type defines a particular encoding (not a particular This ID type defines a particular encoding (not a particular
certificate type), some current implementations may ignore CERTREQs certificate type), some current implementations may ignore CERTREQs
they receive which contain this ID type, and the authors are unaware they receive which contain this ID type, and the authors are unaware
of any implementations that generate such CERTREQ messages. of any implementations that generate such CERTREQ messages.
Therefore, the use of this type is deprecated. Implementations Therefore, the use of this type is deprecated. Implementations
SHOULD NOT require CERTREQs that contain this Certificate Type. SHOULD NOT require CERTREQs that contain this Certificate Type.
Implementations which receive CERTREQs which contain this ID type MAY Implementations which receive CERTREQs which contain this ID type MAY
treat such payloads as synonymous with "X.509 Certificate - treat such payloads as synonymous with "X.509 Certificate -
Signature". Signature".
3.2.5 IKEv2's Hash and URL of X.509 certificate 3.2.5 IKEv2's Hash and URL of X.509 certificate
This ID type defines a request for the peer to send a hash and URL of This ID type defines a request for the peer to send a hash and URL of
it X.509 certificate, instead of the actual certificate itself. This it X.509 certificate, instead of the actual certificate itself. This
is a particularly useful mechanism when the peer is a device with is a particularly useful mechanism when the peer is a device with
little memory and lower bandwidth, e.g. a mobile handset or consumer little memory and lower bandwidth, e.g. a mobile handset or consumer
electronics device. electronics device.
If the IKEv2 implementation supports URL lookups, and prefers such a If the IKEv2 implementation supports URL lookups, and prefers such a
URL to receiving actual certificates, then the implementation will URL to receiving actual certificates, then the implementation will
want to send a notify of type HTTP_CERT_LOOKUP_SUPPORTED. From IKEv2 want to send a notify of type HTTP_CERT_LOOKUP_SUPPORTED. From IKEv2
[3], section 3.10.1, "This notification MAY be included in any [3], section 3.10.1, "This notification MAY be included in any
message that can include a CERTREQ payload and indicates that the message that can include a CERTREQ payload and indicates that the
sender is capable of looking up certificates based on an HTTP-based sender is capable of looking up certificates based on an HTTP-based
URL (and hence presumably would prefer to receive certificate URL (and hence presumably would prefer to receive certificate
specifications in that format)." If an HTTP_LOOKUP_SUPPORTED specifications in that format)." If an HTTP_LOOKUP_SUPPORTED
notification is sent the sender MUST support the http scheme. See notification is sent the sender MUST support the http scheme. See
Section 3.3.4 for more discussion. Section 3.3.4 for more discussion.
3.2.6 Location of Certificate Payloads 3.2.6 Location of Certificate Payloads
In IKEv1, the CERTREQ payload MUST be in messages 4 and 5. In IKEv2, In IKEv1, the CERTREQ payload MUST be in messages 4 and 5. In IKEv2,
the CERTREQ payload must be in messages 2 and 3. Note that in IKEv2, the CERTREQ payload must be in messages 2 and 3. Note that in IKEv2,
it is possible to have one side authenticating with certificates it is possible to have one side authenticating with certificates
while the other side authenticates with preshared keys. while the other side authenticates with preshared keys.
skipping to change at page 16, line 21 skipping to change at page 16, line 29
policy explicitly deems trusted during a given exchange. For IKEv1, policy explicitly deems trusted during a given exchange. For IKEv1,
implementations SHOULD populate the Certification Authority field implementations SHOULD populate the Certification Authority field
with the SubjectName of the trust anchor, populated such that binary with the SubjectName of the trust anchor, populated such that binary
comparison of the SubjectName and the Certification Authority will comparison of the SubjectName and the Certification Authority will
succeed. For IKEv2, implementations MUST populate the Certification succeed. For IKEv2, implementations MUST populate the Certification
Authority field as specified in IKEv2 [3]. Authority field as specified in IKEv2 [3].
Upon receipt of a CERTREQ, implementations MUST respond by sending at Upon receipt of a CERTREQ, implementations MUST respond by sending at
least the end-entity certificate corresponding to the Certification least the end-entity certificate corresponding to the Certification
Authority listed in the CERTREQ unless local security policy Authority listed in the CERTREQ unless local security policy
configuration specifies that keying materials must be exchanged configuration specifies that keying materials must be exchanged out-
out-of-band. Implementations MAY send certificates other than the of-band. Implementations MAY send certificates other than the end-
end-entity certificate (see Section 3.3 for discussion). entity certificate (see Section 3.3 for discussion).
Note, in the case where multiple end-entity certificates may be Note, in the case where multiple end-entity certificates may be
available which chain to different trust anchors, implementations available which chain to different trust anchors, implementations
SHOULD resort to local heuristics to determine which trust anchor is SHOULD resort to local heuristics to determine which trust anchor is
most appropriate to use for generating the CERTREQ. Such heuristics most appropriate to use for generating the CERTREQ. Such heuristics
are out of the scope of this document. are out of the scope of this document.
3.2.8.2 Empty Certification Authority Field 3.2.8.2 Empty Certification Authority Field
Implementations SHOULD generate CERTREQs where the Certificate Type Implementations SHOULD generate CERTREQs where the Certificate Type
skipping to change at page 17, line 23 skipping to change at page 17, line 31
processing delays, bandwidth consumption, and UDP fragmentation, so processing delays, bandwidth consumption, and UDP fragmentation, so
this tactic is ruled out. this tactic is ruled out.
In such a deployment, the responder gateway implementation should be In such a deployment, the responder gateway implementation should be
able to do all it can to indicate a Certification Authority in the able to do all it can to indicate a Certification Authority in the
CERTREQ. This means the responder SHOULD first check SPD to see if CERTREQ. This means the responder SHOULD first check SPD to see if
it can match the source IP, and find some indication of which CA is it can match the source IP, and find some indication of which CA is
associated with that IP. If this fails (because the source IP is not associated with that IP. If this fails (because the source IP is not
familiar, as in the case above), then the responder SHOULD have a familiar, as in the case above), then the responder SHOULD have a
configuration option specifying which CA's are the default CAs to configuration option specifying which CA's are the default CAs to
indicate in CERTREQ during such ambiguous connections (e.g. send indicate in CERTREQ during such ambiguous connections (e.g. send
CERTREQ with these N CAs if there is an unknown source IP). If such CERTREQ with these N CAs if there is an unknown source IP). If such
a fall-back is not configured or impractical in a certain deployment a fall-back is not configured or impractical in a certain deployment
scenario, then the responder implementation SHOULD have both of the scenario, then the responder implementation SHOULD have both of the
following configuration options: following configuration options:
o send a CERTREQ payload with an empty Certification Authority o send a CERTREQ payload with an empty Certification Authority
field, or field, or
o terminate the negotiation with an appropriate error message and o terminate the negotiation with an appropriate error message and
audit log entry. audit log entry.
skipping to change at page 20, line 4 skipping to change at page 20, line 12
certificate or CRL. Multiple certificates should be transmitted in certificate or CRL. Multiple certificates should be transmitted in
multiple payloads. For backwards compatibility reasons, multiple payloads. For backwards compatibility reasons,
implementations MAY send intermediate CA certificates in addition to implementations MAY send intermediate CA certificates in addition to
the appropriate end-entity certificate(s), but SHOULD NOT send any the appropriate end-entity certificate(s), but SHOULD NOT send any
CRLs, ARLs, or trust anchors. The reason for not exchanging CRLs or CRLs, ARLs, or trust anchors. The reason for not exchanging CRLs or
ARLs in IKE is to: ARLs in IKE is to:
o decrease UDP fragmentation o decrease UDP fragmentation
o simplify the IKE exchange o simplify the IKE exchange
o reduce bandwidth requirements for IKE exchanges o reduce bandwidth requirements for IKE exchanges
Note, however, that while the sender of the CERT payloads SHOULD NOT Note, however, that while the sender of the CERT payloads SHOULD NOT
send any trust anchors, it's possible that the recipient may consider send any trust anchors, it's possible that the recipient may consider
any given intermediate CA certificate to be a trust anchor. For any given intermediate CA certificate to be a trust anchor. For
instance, imagine the sender has the certificate chain TA1->CA1->EE1 instance, imagine the sender has the certificate chain TA1->CA1->EE1
while the recipient has the certificate chain TA2->EE2 where TA2=CA1. while the recipient has the certificate chain TA2->EE2 where TA2=CA1.
The sender is merely including an intermdiate CA certificate, while The sender is merely including an intermdiate CA certificate, while
the recipient receives a trust anchor. the recipient receives a trust anchor.
However, not all certificate forms that are legal in PKIX make sense However, not all certificate forms that are legal in PKIX make sense
in the context of IPsec. The issue of how to represent in the context of IPsec. The issue of how to represent IKE-
IKE-meaningful name-forms in a certificate is especially problematic. meaningful name-forms in a certificate is especially problematic.
This document provides a profile for a subset of PKIX that makes This document provides a profile for a subset of PKIX that makes
sense for IKEv1/ISAKMP and IKEv2. sense for IKEv1/ISAKMP and IKEv2.
3.3.1 Certificate Type 3.3.1 Certificate Type
The Certificate Type field identifies to the peer the type of The Certificate Type field identifies to the peer the type of
certificate keying materials that are included. ISAKMP defines 10 certificate keying materials that are included. ISAKMP defines 10
types of Certificate Data that can be sent and specifies the syntax types of Certificate Data that can be sent and specifies the syntax
for these types, and IKEv2 specifies 3 additional types. For the for these types, and IKEv2 specifies 3 additional types. For the
purposes of this document, only the following types are relevant: purposes of this document, only the following types are relevant:
skipping to change at page 23, line 43 skipping to change at page 23, line 51
Implementations MAY send certificates which are irrelevant to an Implementations MAY send certificates which are irrelevant to an
exchange. One reason for including certificates which are irrelevant exchange. One reason for including certificates which are irrelevant
to an exchange is to minimize the threat of leaking identifying to an exchange is to minimize the threat of leaking identifying
information in exchanges where CERT is not encrypted. It should be information in exchanges where CERT is not encrypted. It should be
noted, however, that this probably provides rather poor protection noted, however, that this probably provides rather poor protection
against leaking the identity. against leaking the identity.
Another reason for including certificates that seem irrelevant to an Another reason for including certificates that seem irrelevant to an
exchange is that there may be two chains from the Certification exchange is that there may be two chains from the Certification
Authority to the end entity, each of which is only valid with certain Authority to the end entity, each of which is only valid with certain
validation parameters (such as acceptable policies). Since the validation parameters (such as acceptable policies). Since the end-
end-entity doesn't know which parameters the relying party is using, entity doesn't know which parameters the relying party is using, it
it should send the certificates needed for both chains (even if should send the certificates needed for both chains (even if there's
there's only one CERTREQ). only one CERTREQ).
Implementations SHOULD NOT send multiple end-entity certificates and Implementations SHOULD NOT send multiple end-entity certificates and
recipients SHOULD NOT be expected to iterate over multiple end-entity recipients SHOULD NOT be expected to iterate over multiple end-entity
certificates. certificates.
3.3.12 Optimizations 3.3.12 Optimizations
3.3.12.1 Duplicate Certificate Payloads 3.3.12.1 Duplicate Certificate Payloads
Implementations SHOULD NOT send duplicate CERTs during an exchange. Implementations SHOULD NOT send duplicate CERTs during an exchange.
skipping to change at page 27, line 38 skipping to change at page 27, line 46
Many IKE implementations do not support the PolicyMappings extension. Many IKE implementations do not support the PolicyMappings extension.
Therefore, implementations that generate certificates which contain Therefore, implementations that generate certificates which contain
this extension SHOULD NOT mark the extension as critical. this extension SHOULD NOT mark the extension as critical.
4.1.3.6 SubjectAltName 4.1.3.6 SubjectAltName
Deployments that intend to use an ID of either FQDN, USER_FQDN, Deployments that intend to use an ID of either FQDN, USER_FQDN,
IPV4_ADDR or IPV6_ADDR MUST issue certificates with the corresponding IPV4_ADDR or IPV6_ADDR MUST issue certificates with the corresponding
SubjectAltName fields populated with the same data. Implementations SubjectAltName fields populated with the same data. Implementations
SHOULD generate only the following GeneralName choices in the SHOULD generate only the following GeneralName choices in the
SubjectAltName extension, as these choices map to legal SubjectAltName extension, as these choices map to legal IKEv1/ISAKMP/
IKEv1/ISAKMP/IKEv2 Identification Payload types: rfc822Name, dNSName, IKEv2 Identification Payload types: rfc822Name, dNSName, or
or iPAddress. Although it is possible to specify any GeneralName iPAddress. Although it is possible to specify any GeneralName choice
choice in the Identification Payload by using the ID_DER_ASN1_GN ID in the Identification Payload by using the ID_DER_ASN1_GN ID type,
type, implementations SHOULD NOT assume support for such implementations SHOULD NOT assume support for such functionality, and
functionality, and SHOULD NOT generate certificates that do so. SHOULD NOT generate certificates that do so.
4.1.3.6.1 dNSName 4.1.3.6.1 dNSName
This field MUST contain a fully qualified domain name. If the IKE ID This field MUST contain a fully qualified domain name. If the IKE ID
type is FQDN then the dNSName field MUST match its contents. type is FQDN then the dNSName field MUST match its contents.
Implementations MUST NOT generate names that contain wildcards. Implementations MUST NOT generate names that contain wildcards.
Implementations MAY treat certificates that contain wildcards in this Implementations MAY treat certificates that contain wildcards in this
field as syntactically invalid. field as syntactically invalid.
Although this field is in the form of an FQDN, IKE implementations Although this field is in the form of an FQDN, IKE implementations
SHOULD NOT assume that this field contains an FQDN that will resolve SHOULD NOT assume that this field contains an FQDN that will resolve
via the DNS, unless this is known by way of some out-of-band via the DNS, unless this is known by way of some out-of-band
mechanism. Such a mechanism is out of the scope of this document. mechanism. Such a mechanism is out of the scope of this document.
Implementations SHOULD NOT treat the failure to resolve as an error. Implementations SHOULD NOT treat the failure to resolve as an error.
4.1.3.6.2 iPAddress 4.1.3.6.2 iPAddress
If the IKE ID type is IPV4_ADDR or IPV6_ADDR then the iPAddress field If the IKE ID type is IPV4_ADDR or IPV6_ADDR then the iPAddress field
MUST match its contents. Note that although PKIX permits CIDR [13] MUST match its contents. Note that although PKIX permits CIDR [14]
notation in the "Name Constraints" extension, PKIX explicitly notation in the "Name Constraints" extension, PKIX explicitly
prohibits using CIDR notation for conveying identity information. In prohibits using CIDR notation for conveying identity information. In
other words, the CIDR notation MUST NOT be used in the SubjectAltName other words, the CIDR notation MUST NOT be used in the SubjectAltName
extension. extension.
4.1.3.6.3 rfc822Name 4.1.3.6.3 rfc822Name
If the IKE ID type is USER_FQDN then the rfc822Name field MUST match If the IKE ID type is USER_FQDN then the rfc822Name field MUST match
its contents. Although this field is in the form of an Internet mail its contents. Although this field is in the form of an Internet mail
address, IKE implementations SHOULD NOT assume that this field address, IKE implementations SHOULD NOT assume that this field
skipping to change at page 29, line 30 skipping to change at page 29, line 39
4.1.3.12 ExtendedKeyUsage 4.1.3.12 ExtendedKeyUsage
The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in
certificates for use with IKE. Note that there were three IPsec certificates for use with IKE. Note that there were three IPsec
related object identifiers in EKU that were assigned in 1999. The related object identifiers in EKU that were assigned in 1999. The
semantics of these values were never clearly defined. The use of semantics of these values were never clearly defined. The use of
these three EKU values in IKE/IPsec is obsolete and explicitly these three EKU values in IKE/IPsec is obsolete and explicitly
deprecated by this specification. CAs SHOULD NOT issue certificates deprecated by this specification. CAs SHOULD NOT issue certificates
for use in IKE with them. (For historical reference only, those for use in IKE with them. (For historical reference only, those
values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp-
id-kp-ipsecUser.) ipsecUser.)
PKIX [5] section 4.2.1.13 states, "If a CA includes extended key PKIX [5] section 4.2.1.13 states, "If a CA includes extended key
usages to satisfy such applications, but does not wish to restrict usages to satisfy such applications, but does not wish to restrict
usages of the key, the CA can include the special keyPurposeID usages of the key, the CA can include the special keyPurposeID
anyExtendedKeyUsage. If the anyExtendedKeyUsage keyPurposeID is anyExtendedKeyUsage. If the anyExtendedKeyUsage keyPurposeID is
present, the extension SHOULD NOT be critical." present, the extension SHOULD NOT be critical."
The CA SHOULD NOT mark the EKU extension in certificates for use with The CA SHOULD NOT mark the EKU extension in certificates for use with
IKE and one or more other applications. If the CA administrator IKE and one or more other applications. If the CA administrator
feels they must use an EKU for some other application, then such feels they must use an EKU for some other application, then such
skipping to change at page 30, line 14 skipping to change at page 30, line 23
extension. extension.
o If no EKU extension, accept cert. o If no EKU extension, accept cert.
o If EKU present AND anyExtendedKeyUsage is included, accept cert. o If EKU present AND anyExtendedKeyUsage is included, accept cert.
o Otherwise, reject cert. o Otherwise, reject cert.
4.1.3.13 CRLDistributionPoints 4.1.3.13 CRLDistributionPoints
Because this document deprecates the sending of CRLs in-band, the use Because this document deprecates the sending of CRLs in-band, the use
of CRLDistributionPoints (CDP) becomes very important if CRLs are of CRLDistributionPoints (CDP) becomes very important if CRLs are
used for revocation checking (as opposed to say Online Certificate used for revocation checking (as opposed to say Online Certificate
Status Protocol - OCSP [14]). The IPsec peer either needs to have a Status Protocol - OCSP [15]). The IPsec peer either needs to have a
URL for a CRL written into its local configuration, or it needs to URL for a CRL written into its local configuration, or it needs to
learn it from CDP. Therefore, Certification Authority learn it from CDP. Therefore, Certification Authority
implementations SHOULD issue certificates with a populated CDP. implementations SHOULD issue certificates with a populated CDP.
Failure to validate the Failure to validate the CRLDistributionPoints/
CRLDistributionPoints/IssuingDistributionPoint pair can result in CRL IssuingDistributionPoint pair can result in CRL substitution where an
substitution where an entity knowingly substitutes a known good CRL entity knowingly substitutes a known good CRL from a different
from a different distribution point for the CRL which is supposed to distribution point for the CRL which is supposed to be used which
be used which would show the entity as revoked. IKE implementations would show the entity as revoked. IKE implementations MUST support
MUST support validating that the contents of CRLDistributionPoints validating that the contents of CRLDistributionPoints match those of
match those of the IssuingDistributionPoint to prevent CRL the IssuingDistributionPoint to prevent CRL substitution when the
substitution when the issuing CA is using them. At least one CA is issuing CA is using them. At least one CA is known to default to
known to default to this type of CRL use. See Section 4.2.2.5 for this type of CRL use. See Section 4.2.2.5 for more information.
more information.
CDPs SHOULD be "resolvable". Several non-compliant Certification CDPs SHOULD be "resolvable". Several non-compliant Certification
Authority implementations are well known for including unresolvable Authority implementations are well known for including unresolvable
CDPs like http://localhost/path_to_CRL and http:///path_to_CRL which CDPs like http://localhost/path_to_CRL and http:///path_to_CRL which
are equivalent to failing to include the CDP extension in the are equivalent to failing to include the CDP extension in the
certificate. certificate.
See PKIX docs for CRLDistributionPoints intellectual property rights See PKIX docs for CRLDistributionPoints intellectual property rights
(IPR) information. Note that both the CRLDistributionPoints and (IPR) information. Note that both the CRLDistributionPoints and
IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED
skipping to change at page 31, line 11 skipping to change at page 31, line 19
4.1.3.15 FreshestCRL 4.1.3.15 FreshestCRL
IKE implementations MUST NOT assume that the FreshestCRL extension IKE implementations MUST NOT assume that the FreshestCRL extension
will exist in peer certificates. Note that most IKE implementations will exist in peer certificates. Note that most IKE implementations
do not support delta CRLs. do not support delta CRLs.
4.1.3.16 AuthorityInfoAccess 4.1.3.16 AuthorityInfoAccess
PKIX defines the AuthorityInfoAccess extension, which is used to PKIX defines the AuthorityInfoAccess extension, which is used to
indicate "how to access CA information and services for the issuer of indicate "how to access CA information and services for the issuer of
the certificate in which the extension appears." Because this the certificate in which the extension appears." Because this
document deprecates the sending of CRLs in band, the use of document deprecates the sending of CRLs in band, the use of
AuthorityInfoAccess (AIA) becomes very important if OCSP [14] is to AuthorityInfoAccess (AIA) becomes very important if OCSP [15] is to
be used for revocation checking (as opposed to CRLs). The IPsec peer be used for revocation checking (as opposed to CRLs). The IPsec peer
either needs to have a URI for the OCSP query written into its local either needs to have a URI for the OCSP query written into its local
configuration, or it needs to learn it from AIA. Therefore, configuration, or it needs to learn it from AIA. Therefore,
implementations SHOULD support this extension, especially if OCSP implementations SHOULD support this extension, especially if OCSP
will be used. will be used.
4.1.3.17 SubjectInfoAccess 4.1.3.17 SubjectInfoAccess
PKIX defines the SubjectInfoAccess private certificate extension, PKIX defines the SubjectInfoAccess private certificate extension,
which is used to indicate "how to access information and services for which is used to indicate "how to access information and services for
the subject of the certificate in which the extension appears." This the subject of the certificate in which the extension appears." This
extension has no known use in the context of IPsec. Conformant IKE extension has no known use in the context of IPsec. Conformant IKE
implementations SHOULD ignore this extension when present. implementations SHOULD ignore this extension when present.
4.2 X.509 Certificate Revocation Lists 4.2 X.509 Certificate Revocation Lists
When validating certificates, IKE implementations MUST make use of When validating certificates, IKE implementations MUST make use of
certificate revocation information, and SHOULD support such certificate revocation information, and SHOULD support such
revocation information in the form of CRLs, unless non-CRL revocation revocation information in the form of CRLs, unless non-CRL revocation
information is known to be the only method for transmitting this information is known to be the only method for transmitting this
information. Deployments that intend to use CRLs for revocation information. Deployments that intend to use CRLs for revocation
skipping to change at page 35, line 16 skipping to change at page 35, line 24
There are no known numbers which IANA will need to manage. There are no known numbers which IANA will need to manage.
9. References 9. References
9.1 Normative References 9.1 Normative References
[1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[2] Maughan, D., Schneider, M. and M. Schertler, "Internet Security [2] Maughan, D., Schneider, M., and M. Schertler, "Internet Security
Association and Key Management Protocol (ISAKMP)", RFC 2408, Association and Key Management Protocol (ISAKMP)", RFC 2408,
November 1998. November 1998.
[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Internet-Draft draft-ietf-ipsec-ikev2-15, August 2004. draft-ietf-ipsec-ikev2-15 (work in progress), August 2004.
[4] Kent, S. and R. Atkinson, "Security Architecture for the [4] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[5] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3280, April 2002. List (CRL) Profile", RFC 3280, April 2002.
[6] Piper, D., "The Internet IP Security Domain of Interpretation [6] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998. for ISAKMP", RFC 2407, November 1998.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[9] Kaliski, B., "PKCS #10: Certification Request Syntax Version [9] Kaliski, B., "PKCS #10: Certification Request Syntax Version
1.5", RFC 2314, March 1998. 1.5", RFC 2314, March 1998.
9.2 Informative References 9.2 Informative References
[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [10] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress),
March 2005.
[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 1883, December 1995. Specification", RFC 1883, December 1995.
[11] Eastlake, D., "Domain Name System Security Extensions", [12] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[12] Lynn, C., "X.509 Extensions for IP Addresses and AS [13] Lynn, C., "X.509 Extensions for IP Addresses and AS
Identifiers", Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in
Internet-Draft draft-ietf-pkix-x509-ipaddr-as-extn-03, progress), September 2003.
September 2003.
[13] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless [14] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Inter-Domain Routing (CIDR): an Address Assignment and Domain Routing (CIDR): an Address Assignment and Aggregation
Aggregation Strategy", RFC 1519, September 1993. Strategy", RFC 1519, September 1993.
[14] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, [15] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
"X.509 Internet Public Key Infrastructure Online Certificate "X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", RFC 2560, June 1999. Status Protocol - OCSP", RFC 2560, June 1999.
[15] Arsenault, A. and S. Turner, "Internet X.509 Public Key [16] Arsenault, A. and S. Turner, "Internet X.509 Public Key
Infrastructure: Roadmap", Infrastructure: Roadmap", draft-ietf-pkix-roadmap-09 (work in
Internet-Draft draft-ietf-pkix-roadmap-09, July 2002. progress), July 2002.
Author's Address Author's Address
Brian Korver Brian Korver
Xythos Software, Inc. Network Resonance, Inc.
One Bush Street, Suite 600 2483 E. Bayshore Rd.
San Francisco, CA 94104 Palo Alto, CA 94303
US US
Phone: +1 415 248 3800 Phone: +1 415 812 7700
Email: briank@xythos.com Email: briank@networkresonance.com
Appendix A. Change History Appendix A. Change History
September 2004 (-03) July 2005 (-05)
* 3.1 - added "See 2401bis [10], section 4.4.3.2 for more
details." to resolve issue #561.
* 3.1.10 - added text pointing to PAD in 2401bis [10] to
discussion of binding identity to policy.
December 2004 (-04)
* Added Paul Hoffman's text from issue #708 * Added Paul Hoffman's text from issue #708
* Added text explaining that it's possible for a recipient to * Added text explaining that it's possible for a recipient to
receive CERT payloads containing certs that the recipient receive CERT payloads containing certs that the recipient
considers a trust anchor (15 Nov 2004 pki4ipsec email from considers a trust anchor (15 Nov 2004 pki4ipsec email from
Peter Williams) Peter Williams)
* Replaced text in 4.1.3 with Kent's text (issue #655) (22 Nov * Replaced text in 4.1.3 with Kent's text (issue #655) (22 Nov
2004 pki4ipsec email from Stephen Kent, Paul Hoffman) 2004 pki4ipsec email from Stephen Kent, Paul Hoffman)
September 2004 (-03) September 2004 (-03)
* Minor editorial changes in abstract and introduction clarifing * Minor editorial changes in abstract and introduction clarifing
when something is from IPsec, IKE, etc when something is from IPsec, IKE, etc
* Minor editorial changes throughout * Minor editorial changes throughout
* Fixed "Certification Authority" instead of "Certificate * Fixed "Certification Authority" instead of "Certificate
Authority" Authority"
* Cleaned up initiator/responder when really referred to * Cleaned up initiator/responder when really referred to sender/
sender/recipient recipient
* Fixed inconsistancy in text by making sure that all text on the * Fixed inconsistancy in text by making sure that all text on the
topic of sending CERTREQs follow Gregory Lebovitz's proposal topic of sending CERTREQs follow Gregory Lebovitz's proposal
for CERT payloads: "should deal with all the CRL, Intermediat for CERT payloads: "should deal with all the CRL, Intermediat
Certs, Trust Anchors, etc OOB of IKE; MUST be able to send and Certs, Trust Anchors, etc OOB of IKE; MUST be able to send and
receive EE cert payload; only real exception is Intermediate receive EE cert payload; only real exception is Intermediate
Cets which MAY be sent and SHOULD be able to be receivable (but Cets which MAY be sent and SHOULD be able to be receivable (but
in reality there are very few hierarchies in operation, so in reality there are very few hierarchies in operation, so
really it's a corner case); SHOULD NOT send the other stuff really it's a corner case); SHOULD NOT send the other stuff
(CRL, Trust Anchors, etc) in cert payloads in IKE; SHOULD be (CRL, Trust Anchors, etc) in cert payloads in IKE; SHOULD be
able to accept the other stuff if by chance it gets sent, able to accept the other stuff if by chance it gets sent,
skipping to change at page 38, line 4 skipping to change at page 38, line 32
specifies that it's only a local matter if that information is specifies that it's only a local matter if that information is
not coordinated with other administrators not coordinated with other administrators
* #573: Kent-Profile document 3.2.3/Myers - revocation * #573: Kent-Profile document 3.2.3/Myers - revocation
information no longer exchanged in-band, plus Mike Myers has information no longer exchanged in-band, plus Mike Myers has
submitted an OCSP w/IKE draft, which is references by this submitted an OCSP w/IKE draft, which is references by this
document. document.
* #578 Kent-Profile document 4.0.0 - went through entire PKIX * #578 Kent-Profile document 4.0.0 - went through entire PKIX
profile section and prefaced "implementation" with "IKE" or profile section and prefaced "implementation" with "IKE" or
"Certification Authority" wherever it was sure to be one or the "Certification Authority" wherever it was sure to be one or the
other other
* #581: Kent-Profile document 4.1.3.9 - replaced description with * #581: Kent-Profile document 4.1.3.9 - replaced description with
text from RFC 2459 text from RFC 2459
* #584: Maillist-Lebovitz PKI Life Cycle-Revocation - fixed * #584: Maillist-Lebovitz PKI Life Cycle-Revocation - fixed
* #586: Maillist-Allison Empty CertReq - there is now lots of * #586: Maillist-Allison Empty CertReq - there is now lots of
text dealing with when empty certreqs are permitted text dealing with when empty certreqs are permitted
* 3.2.7.1 - CERTREQ only mandatory if in-band exchange of keymat * 3.2.7.1 - CERTREQ only mandatory if in-band exchange of keymat
is desired (28 Jul 2004 pki4ipsec email from is desired (28 Jul 2004 pki4ipsec email from jknowles@
jknowles@SonicWALL.com) SonicWALL.com)
* 3.3.6 - clarified that "non-compliant" means not sending a * 3.3.6 - clarified that "non-compliant" means not sending a
CERTREQ (28 Jul 2004 pki4ipsec email from CERTREQ (28 Jul 2004 pki4ipsec email from jknowles@
jknowles@SonicWALL.com) SonicWALL.com)
* 3.2.7.1 - fixed contradition: mandatory to respond to CERTREQ * 3.2.7.1 - fixed contradition: mandatory to respond to CERTREQ
UNLESS configured not to (28 Jul 2004 pki4ipsec email from UNLESS configured not to (28 Jul 2004 pki4ipsec email from
jknowles@SonicWALL.com) jknowles@SonicWALL.com)
* 3.2.9.2 and 3.2.9.3 - CERTREQ contains an issuer name only for * 3.2.9.2 and 3.2.9.3 - CERTREQ contains an issuer name only for
IKEv2 (19 Sep 2004 email from Charlie Kaufman) IKEv2 (19 Sep 2004 email from Charlie Kaufman)
* Answered 'Section 3.1.9 para 2: "The initiator MUST know by * Answered 'Section 3.1.9 para 2: "The initiator MUST know by
policy..." is a difficult to interpret requirement. It could policy..." is a difficult to interpret requirement. It could
mean that it must be possible to configure in policy which ID mean that it must be possible to configure in policy which ID
is to be sent. Did you mean "the initiator must decide...", is to be sent. Did you mean "the initiator must decide...",
where the decision might be wired into a particular where the decision might be wired into a particular
skipping to change at page 40, line 14 skipping to change at page 40, line 41
added, and specifics of both initiator and responder behavior added, and specifics of both initiator and responder behavior
listed. listed.
* APPENDIX C added to fill out the explanation (mostly discussion * APPENDIX C added to fill out the explanation (mostly discussion
from list). from list).
* 3.3 - clarified that sending CRLs and chaining certs is * 3.3 - clarified that sending CRLs and chaining certs is
deprecated. deprecated.
* added IKEv2's Hash and URL of x.509 to list of those profiled * added IKEv2's Hash and URL of x.509 to list of those profiled
and gave it its own section. Condensed ARL into CRL and and gave it its own section. Condensed ARL into CRL and
renumbered accordingly. renumbered accordingly.
* duplicate section was removed, renumbered accordingly * duplicate section was removed, renumbered accordingly
* 3.3.10.2 - title changed. sending chaining becomes SHOULD NOT. * 3.3.10.2 - title changed. sending chaining becomes SHOULD NOT.
* 4.1.2 added text to explicity call out support for CN, C, O, OU * 4.1.2 added text to explicity call out support for CN, C, O, OU
* collapsed 4.1.2.3 into 4.1.2.2 and renumbered accordingly. * collapsed 4.1.2.3 into 4.1.2.2 and renumbered accordingly.
* Collapsed 4.1.3.2 into 4.1.3.1 and renumbered accordingly * Collapsed 4.1.3.2 into 4.1.3.1 and renumbered accordingly
* Edited 4.1.3.2 Key Usage and 4.1.3.12 ExtKey Usage according to * Edited 4.1.3.2 Key Usage and 4.1.3.12 ExtKey Usage according to
Hoffman, July18 Hoffman, July18
* 4.1.3.3 if receive cert w/ PKUP, ignore it. * 4.1.3.3 if receive cert w/ PKUP, ignore it.
* 4.1.3.13 - CDP changed text to represent SHOULD issue, and how * 4.1.3.13 - CDP changed text to represent SHOULD issue, and how
important CDP becomes when we do not send CRLs in-band. Added important CDP becomes when we do not send CRLs in-band. Added
SHOULD for CDPs actually being resolvable (reilly email). SHOULD for CDPs actually being resolvable (reilly email).
* Reordered 6.4 for better clarity. * Reordered 6.4 for better clarity.
* Added Rescorla to Acknowledgements section, as he is no longer * Added Rescorla to Acknowledgements section, as he is no longer
listed as an editor, since -00. listed as an editor, since -00.
May 2004 (renamed draft-ietf-pki4ipsec-ikecert-profile-00.txt) May 2004 (renamed draft-ietf-pki4ipsec-ikecert-profile-00.txt)
(edited by Brian Korver) (edited by Brian Korver)
* Made it clearer that the format of the ID_IPV4_ADDR payload * Made it clearer that the format of the ID_IPV4_ADDR payload
comes from RFC791 and is nothing new. (Tero Kivinen Feb 29) comes from RFC791 and is nothing new. (Tero Kivinen Feb 29)
* Permit implementations to skip verifying that the peer source * Permit implementations to skip verifying that the peer source
skipping to change at page 41, line 4 skipping to change at page 41, line 30
Lebovitz Feb 29) Lebovitz Feb 29)
* Removed some text implying RSA encryption mode was in scope. * Removed some text implying RSA encryption mode was in scope.
(Tero Kivinen Feb 29) (Tero Kivinen Feb 29)
* Relaxed deprecation of PKCS#7 CERT payloads. (Tero Kivinen Feb * Relaxed deprecation of PKCS#7 CERT payloads. (Tero Kivinen Feb
29) 29)
* Made it clearer that out-of-scope local heuristics should be * Made it clearer that out-of-scope local heuristics should be
used for picking an EE cert to use when generating CERTREQ, not used for picking an EE cert to use when generating CERTREQ, not
when receiving CERTREQ. (Tero Kivinen Feb 29) when receiving CERTREQ. (Tero Kivinen Feb 29)
* Made it clearer that CERT processing can be skipped when the * Made it clearer that CERT processing can be skipped when the
contents of a CERT are already known. (Tero Kivinen Feb 29) contents of a CERT are already known. (Tero Kivinen Feb 29)
* Implementations SHOULD generate BASE64 lines less than 76 * Implementations SHOULD generate BASE64 lines less than 76
characters. (Tero Kivinen Feb 29) characters. (Tero Kivinen Feb 29)
* Added "Except where specifically stated in this document, * Added "Except where specifically stated in this document,
implementations MUST conform to the requirements of PKIX" implementations MUST conform to the requirements of PKIX"
(Steve Hanna Oct 7, 2003) (Steve Hanna Oct 7, 2003)
* RECOMMENDS against populating the ID payload with IP addresses * RECOMMENDS against populating the ID payload with IP addresses
due to interoperability issues such as problem with NAT due to interoperability issues such as problem with NAT
traversal. (Gregory Lebovitz May 14) traversal. (Gregory Lebovitz May 14)
* Changed "as revoked by one source" to "as revoked by one * Changed "as revoked by one source" to "as revoked by one
trusted source". (Michael Myers, May 15) trusted source". (Michael Myers, May 15)
* Specifying Certificate Authorities section needed to be * Specifying Certificate Authorities section needed to be
regularized with Gregory Lebovitz's CERT proposal from -04. regularized with Gregory Lebovitz's CERT proposal from -04.
(Tylor Allison, May 15) (Tylor Allison, May 15)
* Added text specifying how recipients SHOULD NOT be expected to * Added text specifying how recipients SHOULD NOT be expected to
iterate over multiple end-entity certs. (Tylor Allison, May iterate over multiple end-entity certs. (Tylor Allison, May
15) 15)
* Modified text to refer to IKEv2 as well as IKEv1/ISAKMP where * Modified text to refer to IKEv2 as well as IKEv1/ISAKMP where
relevant. relevant.
* IKEv2: Explained that IDr sent by responder doesn't have to * IKEv2: Explained that IDr sent by responder doesn't have to
match the [IDr] sent initiator in second exchange. match the [IDr] sent initiator in second exchange.
* IKEv2: Noted that "The identity ... does not necessarily have
* IKEv2: Noted that "The identity ... does not necessarily have
to match anything in the CERT payload" (S3.5) is not to match anything in the CERT payload" (S3.5) is not
contradicted by SHOULD in this document. contradicted by SHOULD in this document.
* IKEv2: Noted that ID_USER_FQDN renamed to ID_RFC822_ADDR, and * IKEv2: Noted that ID_USER_FQDN renamed to ID_RFC822_ADDR, and
ID_USER_FQDN would be used exclusively in this document. ID_USER_FQDN would be used exclusively in this document.
* IKEv2: Declared that 3 new CERTREQ and CERT types are not * IKEv2: Declared that 3 new CERTREQ and CERT types are not
profiled in this document (well, at least not yet, pending WG profiled in this document (well, at least not yet, pending WG
discussion of what to do -- note that they are only SHOULDs in discussion of what to do -- note that they are only SHOULDs in
IKEv2). IKEv2).
* IKEv2: Noted that CERTREQ payload changed from DN to SHA-1 of * IKEv2: Noted that CERTREQ payload changed from DN to SHA-1 of
SubjectPublicKeyInfo. SubjectPublicKeyInfo.
skipping to change at page 45, line 29 skipping to change at page 46, line 4
You are an employee of Acme and you are issued the following You are an employee of Acme and you are issued the following
certificates: certificates:
o From CA-A: CN=JoeUser,OU=Engineering o From CA-A: CN=JoeUser,OU=Engineering
o From CA-B: CN=JoePartner,OU=BizcoPartners o From CA-B: CN=JoePartner,OU=BizcoPartners
The client MUST be configured locally to know which CA to use when The client MUST be configured locally to know which CA to use when
connecting to either gateway. If your client is not configured to connecting to either gateway. If your client is not configured to
know the local credential to use for the remote gateway, this know the local credential to use for the remote gateway, this
scenario will not work either. If you attempt to connect to Bizco, scenario will not work either. If you attempt to connect to Bizco,
everything will work... as you are presented with responding with a everything will work... as you are presented with responding with a
certificate signed by CA-B or CA-C... as you only have a certificate certificate signed by CA-B or CA-C... as you only have a certificate
from CA-B you are OK. If you attempt to connect to Acme, you have an from CA-B you are OK. If you attempt to connect to Acme, you have an
issue because you are presented with an ambiguous policy selection. issue because you are presented with an ambiguous policy selection.
As the initiator, you will be presented with certificate requests As the initiator, you will be presented with certificate requests
from both CA A and CA B. You have certificates issued by both CAs, from both CA A and CA B. You have certificates issued by both CAs,
but only one of the certificates will be usable. How does the client but only one of the certificates will be usable. How does the client
know which certificate it should present? It must have sufficiently know which certificate it should present? It must have sufficiently
clear local policy specifying which one credential to present for the clear local policy specifying which one credential to present for the
connection it initiates. connection it initiates.
Appendix D. Acknowledgements Appendix D. Acknowledgements
The authors would like to acknowledge the expired draft-ietf-ipsec- The authors would like to acknowledge the expired draft-ietf-ipsec-
pki-req-05.txt for providing valuable materials for this document. pki-req-05.txt for providing valuable materials for this document.
The authors would like to especially thank Eric Rescorla, one of its The authors would like to especially thank Eric Rescorla, one of its
original authors, in addition to Greg Carter, Steve Hanna, Russ original authors, in addition to Greg Carter, Steve Hanna, Russ
skipping to change at page 47, line 41 skipping to change at page 47, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 70 change blocks. 
115 lines changed or deleted 132 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/