< draft-ietf-pki4ipsec-ikecert-profile-09.txt   draft-ietf-pki4ipsec-ikecert-profile-10.txt >
pki4ipsec B. Korver pki4ipsec B. Korver
Internet-Draft Network Resonance, Inc. Internet-Draft Network Resonance, Inc.
Expires: August 25, 2006 February 21, 2006 Expires: October 14, 2006 April 12, 2006
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-09 draft-ietf-pki4ipsec-ikecert-profile-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 August 25, 2006. This Internet-Draft will expire on October 14, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
IKE and PKIX both provide frameworks that must be profiled for use in IKE and PKIX certificate profile both provide frameworks that must be
a given application. This document provides a profile of IKE and profiled for use in a given application. This document provides a
PKIX that defines the requirements for using PKI technology in the profile of IKE and PKIX that defines the requirements for using PKI
context of IKE/IPsec. The document complements protocol technology in the context of IKE/IPsec. The document complements
specifications such as IKEv1 and IKEv2, which assume the existence of protocol specifications such as IKEv1 and IKEv2, which assume the
public key certificates and related keying materials, but which do existence of public key certificates and related keying materials,
not address PKI issues explicitly. This document addresses those but which do not address PKI issues explicitly. This document
issues. addresses those issues.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4
3. Profile of IKEv1/ISAKMP and IKEv2 . . . . . . . . . . . . . . 5 3. Profile of IKEv1/ISAKMP and IKEv2 . . . . . . . . . . . . . . 5
3.1. Identification Payload . . . . . . . . . . . . . . . . . . 5 3.1. Identification Payload . . . . . . . . . . . . . . . . . . 5
3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . . . 7 3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . . . 7
3.1.2. ID_FQDN . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. ID_FQDN . . . . . . . . . . . . . . . . . . . . . . . 9
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. Subject for DN Only . . . . . . . . . . . . . . . . . 12
3.1.10. Binding Identity to Policy . . . . . . . . . . . . . . 13 3.1.10. Binding Identity to Policy . . . . . . . . . . . . . . 12
3.2. Certificate Request Payload . . . . . . . . . . . . . . . 14 3.2. Certificate Request Payload . . . . . . . . . . . . . . . 13
3.2.1. Certificate Type . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . 16 3.2.6. Location of Certificate Payloads . . . . . . . . . . . 15
3.2.7. Presence or Absence of Certificate Request Payloads . 16 3.2.7. Presence or Absence of Certificate Request Payloads . 15
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 . . . . . . . . . . . . . . . . . . . 20 3.3. Certificate Payload . . . . . . . . . . . . . . . . . . . 19
3.3.1. Certificate Type . . . . . . . . . . . . . . . . . . . 20 3.3.1. Certificate Type . . . . . . . . . . . . . . . . . . . 20
3.3.2. X.509 Certificate - Signature . . . . . . . . . . . . 21 3.3.2. X.509 Certificate - Signature . . . . . . . . . . . . 20
3.3.3. Revocation Lists (CRL and ARL) . . . . . . . . . . . . 21 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 . . . . . . . . . . . 22 3.3.6. Location of Certificate Payloads . . . . . . . . . . . 21
3.3.7. Certificate Payloads Not Mandatory . . . . . . . . . . 22 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 . . . . . . . . . . . 23 3.3.10. Multiple End-Entity Certificates . . . . . . . . . . . 22
3.3.11. Robustness . . . . . . . . . . . . . . . . . . . . . . 23 3.3.11. Robustness . . . . . . . . . . . . . . . . . . . . . . 23
3.3.12. Optimizations . . . . . . . . . . . . . . . . . . . . 24 3.3.12. Optimizations . . . . . . . . . . . . . . . . . . . . 24
4. Profile of PKIX . . . . . . . . . . . . . . . . . . . . . . . 25 4. Certificate Profile . . . . . . . . . . . . . . . . . . . . . 24
4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 25 4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 24
4.1.1. Versions . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.1. Versions . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2. SubjectName . . . . . . . . . . . . . . . . . . . . . 25 4.1.2. Subject . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3. X.509 Certificate Extensions . . . . . . . . . . . . . 26 4.1.3. X.509 Certificate Extensions . . . . . . . . . . . . . 26
4.2. X.509 Certificate Revocation Lists . . . . . . . . . . . . 32 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 . . . . . . . . . . . . . . . . . . . . . 32 Information . . . . . . . . . . . . . . . . . . . . . 32
4.2.2. X.509 Certificate Revocation List Extensions . . . . . 32 4.2.2. X.509 Certificate Revocation List Extensions . . . . . 32
4.3. Strength of Signature Hashing Algorithms . . . . . . . . . 34 4.3. Strength of Signature Hashing Algorithms . . . . . . . . . 33
5. Configuration Data Exchange Conventions . . . . . . . . . . . 35 5. Configuration Data Exchange Conventions . . . . . . . . . . . 34
5.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 35 5.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. CRLs and ARLs . . . . . . . . . . . . . . . . . . . . . . 35 5.2. CRLs and ARLs . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 35 5.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 35
5.4. PKCS#10 Certificate Signing Requests . . . . . . . . . . . 35 5.4. PKCS#10 Certificate Signing Requests . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
6.1. Certificate Request Payload . . . . . . . . . . . . . . . 36 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35
6.2. IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 36 7.1. Certificate Request Payload . . . . . . . . . . . . . . . 36
6.3. Disabling Certificate Checks . . . . . . . . . . . . . . . 36 7.2. IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 36
7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 36 7.3. Disabling Certificate Checks . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.1. Normative References . . . . . . . . . . . . . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . . . . . . 36
9.2. Informative References . . . . . . . . . . . . . . . . . . 37 9.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 38 Appendix A. The Possible Dangers of Delta CRLs . . . . . . . . . 38
Appendix B. The Possible Dangers of Delta CRLs . . . . . . . . . 46 Appendix B. More on Empty CERTREQs . . . . . . . . . . . . . . . 38
Appendix C. More on Empty CERTREQs . . . . . . . . . . . . . . . 46 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 40
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 48 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . . . . . 52
Intellectual Property and Copyright Statements . . . . . . . . . . 51
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.
ISAKMP references PKIX but in many cases merely specifies the ISAKMP references the PKIX certificate profile, but in many cases
contents of various messages without specifying their syntax or merely specifies the contents of various messages without specifying
semantics. Meanwhile, PKIX provides a large set of certificate their syntax or semantics. Meanwhile, the PKIX certificate profile
mechanisms which are generally applicable for Internet protocols, but provides a large set of certificate mechanisms which are generally
little specific guidance for IPsec. Given the numerous applicable for Internet protocols, but little specific guidance for
underspecified choices, interoperability is hampered if all IPsec. Given the numerous underspecified choices, interoperability
implementers do not make similar choices, or at least fail to account is hampered if all implementers do not make similar choices, or at
for implementations which have chosen differently. least fail to account for implementations which have chosen
differently.
This profile of the IKE and PKIX frameworks is intended to provide an This profile of the IKE and PKIX frameworks is intended to provide an
agreed-upon standard for using PKI technology in the context of IPsec agreed-upon standard for using PKI technology in the context of IPsec
by profiling the PKIX framework for use with IKE and IPsec, and by by profiling the PKIX framework for use with IKE and IPsec, and by
documenting the contents of the relevant IKE payloads and further documenting the contents of the relevant IKE payloads and further
specifying their semantics. specifying their semantics.
In addition to providing a profile of IKE and PKIX, this document In addition to providing a profile of IKE and PKIX, this document
attempts to incorporate lessons learned from recent experience with attempts to incorporate lessons learned from recent experience with
both implementation and deployment, as well as the current state of both implementation and deployment, as well as the current state of
skipping to change at page 4, line 45 skipping to change at page 4, line 46
readers of this document are assumed to have read and understood readers of this document are assumed to have read and understood
those documents. The requirements and security aspects of those those documents. The requirements and security aspects of those
documents are fully relevant to this document as well. documents are fully relevant to this document as well.
This document is organized as follows. Section 2 defines special This document is organized as follows. Section 2 defines special
terminology used in the rest of this document, Section 3 provides the terminology used in the rest of this document, Section 3 provides the
profile of IKEv1/ISAKMP and IKEv2, and Section 4 provides the profile profile of IKEv1/ISAKMP and IKEv2, and Section 4 provides the profile
of PKIX. Section 5 covers conventions for the out-of-band exchange of PKIX. Section 5 covers conventions for the out-of-band exchange
of keying materials for configuration purposes. of keying materials for configuration purposes.
This document is being discussed on the pki4ipsec@icsalabs.com
mailing list.
2. Terms and Definitions 2. Terms and Definitions
Except for those terms which are defined immediately below, all terms Except for those terms which are defined immediately below, all terms
used in this document are defined in either the PKIX [5], ISAKMP [2], used in this document are defined in either the PKIX [5], ISAKMP [2],
IKEv1 [1], IKEv2 [3], or DOI [6] documents. IKEv1 [1], IKEv2 [3], or DOI [6] documents.
o Peer source address: The source address in packets from a peer. o Peer source address: The source address in packets from a peer.
This address may be different from any addresses asserted as the This address may be different from any addresses asserted as the
"identity" of the peer. "identity" of the peer.
o FQDN: Fully qualified domain name. o FQDN: Fully qualified domain name.
skipping to change at page 5, line 21 skipping to change at page 5, line 20
are referred to as ID_USER_FQDN in this document. are referred to as ID_USER_FQDN in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [7]. document are to be interpreted as described in RFC-2119 [7].
3. Profile of IKEv1/ISAKMP and IKEv2 3. Profile of IKEv1/ISAKMP and IKEv2
3.1. Identification Payload 3.1. Identification Payload
The Identification (ID) Payload is used to indicate the identity that The Identification (ID) Payload indicates the identity claimed by the
the sender claims to be speaking for. The recipient can then use the sender. The recipient can then use the ID as a lookup key for policy
ID as a lookup key for policy and for certificate lookup in whatever and for certificate lookup in whatever certificate store or directory
certificate store or directory that it has available. Our primary that it has available. Our primary concern in this section is to
concern in this section is to profile the ID payload so that it can profile the ID payload so that it can be safely used to generate or
be safely used to generate or lookup policy. IKE mandates the use of lookup policy. IKE mandates the use of the ID payload in Phase 1.
the ID payload in Phase 1.
The DOI [6] defines the 11 types of Identification Data that can be The DOI [6] defines the 11 types of Identification Data that can be
used and specifies the syntax for these types. These are discussed used and specifies the syntax for these types. These are discussed
below in detail. below in detail.
The ID payload requirements in this document cover only the portion The ID payload requirements in this document cover only the portion
of the explicit policy checks that deal with the Identification of the explicit policy checks that deal with the Identification
Payload specifically. For instance, in the case where ID does not Payload specifically. For instance, in the case where ID does not
contain an IP address, checks such as verifying that the peer source contain an IP address, checks such as verifying that the peer source
address is permitted by the relevant policy are not addressed here as address is permitted by the relevant policy are not addressed here as
skipping to change at page 6, line 29 skipping to change at page 6, line 27
| | | | | | | |
IP*_ADDR | MUST [a] | SubjAltName | MUST [b] | [c], [d] IP*_ADDR | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | iPAddress | | | | iPAddress | |
| | | | | | | |
FQDN | MUST [a] | SubjAltName | MUST [b] | [c], [d] FQDN | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | dNSName | | | | dNSName | |
| | | | | | | |
USER_FQDN| MUST [a] | SubjAltName | MUST [b] | [c], [d] USER_FQDN| MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | rfc822Name | | | | rfc822Name | |
| | | | | | | |
IP range | MUST NOT | n/a | n/a | n/a
| | | |
DN | MUST [a] | Entire | MUST [b] | MUST support lookup DN | MUST [a] | Entire | MUST [b] | MUST support lookup
| | Subject, | | on any combination | | Subject, | | on any combination
| | bitwise | | of C, CN, O, or OU | | bitwise | | of C, CN, O, or OU
| | compare | | | | compare | |
| | | | | | | |
IP range | MUST NOT | n/a | n/a | n/a GN | MUST NOT | n/a | n/a | n/a
| | | |
| | | | | | | |
KEY_ID | MUST NOT | n/a | n/a | n/a KEY_ID | MUST NOT | n/a | n/a | n/a
| | | | | | | |
[a] = Implementation MUST have the configuration option to send this [a] = 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.
[b] = The ID in the ID payload MUST match the contents of the [b] = 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. See 2401bis [10], section 4.4.3.2 for required to be used for this. See RFC 4301 [10], section 4.4.3.2 for
more details. more details.
[c] = At a minimum, Implementation MUST be capable of being [c] = 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.
[d] = In addition, the implementation MAY also be configurable to [d] = 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,
implementations MUST be able to be configured to send the same string implementations MUST be able to be configured to send the same string
as appears in the corresponding SubjectAltName attribute. This as appears in the corresponding SubjectAltName extension. This
document RECOMMENDS that deployers use this configuration option. document RECOMMENDS that deployers use this configuration option.
All these ID types are treated the same: as strings that can be All these ID types are treated the same: as strings that can be
compared easily and quickly to a corresponding string in an explicit compared easily and quickly to a corresponding string in an explicit
attribute in the certificate. Of these types, FQDN and USER_FQDN are value in the certificate. Of these types, FQDN and USER_FQDN are
RECOMMENDED over IP addresses (see discussion in Section 3.1.1). RECOMMENDED over IP addresses (see discussion in Section 3.1.1).
When sending a DN as ID, implementations MUST send the entire DN in When sending a DN as ID, implementations MUST send the entire DN in
ID. Also, implementations MUST support at least the C, CN, O, and OU ID. Also, implementations MUST support at least the C, CN, O, and OU
attributes for SPD matching. See Section 3.1.5 for more details attributes for SPD matching. See Section 3.1.5 for more details
about DN, including SPD matching. about DN, including SPD matching.
Recipients MUST be able to perform SPD matching on the exact contents Recipients MUST be able to perform SPD matching on the exact contents
of the ID, and this SHOULD be the default setting. In addition, of the ID, and this SHOULD be the default setting. In addition,
implementations MAY use substrings or wildcards in local policy implementations MAY use substrings or wildcards in local policy
skipping to change at page 8, line 10 skipping to change at page 8, line 6
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 [11]. 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: all of 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
o the administrator intends the implementation to verify that the o the administrator intends the implementation to verify that the
peer source address matches the IP address in the ID received, and peer source address matches the IP address in the ID received, and
that in the iPAddress field in the peer certificate's that in the iPAddress field in the peer certificate's
SubjectAltName extension. SubjectAltName extension.
Implementations MUST be capable of verifying that the IP address Implementations MUST be capable of verifying that the IP address
presented in ID matches via bitwise comparison the IP address present presented in ID matches via bitwise comparison the IP address present
skipping to change at page 9, line 47 skipping to change at page 9, line 43
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 [12] were that mapping is known to be secure, for example if DNSSEC [12] were
employed. employed for that FQDN.
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. Note
Substring, wildcard, or regular expression matching MUST NOT be that caseless string comparison works on internationalized domain
performed for this comparison. If this default is enabled, then a names (IDNs) as well (See IDN [13]). Substring, wildcard, or regular
mismatch MUST be treated as an error and security association setup expression matching MUST NOT be performed for this comparison. If
MUST be aborted. This event SHOULD be auditable. Implementations this default is enabled, then a mismatch MUST be treated as an error
MAY provide a configuration option to (i.e. local policy and security association setup MUST be aborted. This event SHOULD be
configuration can enable) skip that verification step, but that auditable. Implementations MAY provide a configuration option to
option MUST be off by default. We include the "option-to-skip- (i.e. local policy configuration can enable) skip that verification
validation" in order to permit better interoperability, as today step, but that option MUST be off by default. We include the
implementations vary greatly in how they behave on this topic. "option-to-skip-validation" in order to permit better
interoperability, as today implementations vary greatly in how they
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 [12] unless that mapping is known to be secure, for example if DNSSEC [12]
were employed. were employed for that FQDN.
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. Note that caseless
or regular expression matching MUST NOT be performed for this string comparison works on internationalized domain names (IDNs) as
comparison. If this default is enabled, then a mismatch MUST be well (See IDN [13]). Substring, wildcard, or regular expression
treated as an error and security association setup MUST be aborted. matching MUST NOT be performed for this comparison. If this default
This event SHOULD be auditable. Implementations MAY provide a is enabled, then a mismatch MUST be treated as an error and security
configuration option to (i.e. local policy configuration can enable) association setup MUST be aborted. This event SHOULD be auditable.
skip that verification step, but that option MUST be off by default. Implementations MAY provide a configuration option to (i.e. local
We include the "option-to-skip-validation" in order to permit better policy configuration can enable) skip that verification step, but
interoperability, as today implementations vary greatly in how they that option MUST be off by default. We include the "option-to-skip-
behave on this topic. validation" in order to permit better interoperability, as today
implementations vary greatly in how they 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 Note that RFC 3779 [14] defines blocks of addresses using the
or range identity information into certificates, nor are there any certificate extension identified by:
implementations known to support these ID types. Therefore, use of
these ID types is currently undefined. Implementations MUST NOT
generate these ID types.
Note that work in SBGP [13] for defining blocks of addresses using
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. although use of this extension in IKE is considered 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 Subject field from the end-
certificate, and MUST do so such that a binary comparison of the two entity certificate, and MUST do so such that a binary comparison of
will succeed. If there is not a match, this MUST be treated as an the two will succeed. If there is not a match, this MUST be treated
error and security association setup MUST be aborted. This event as an error and security association setup MUST be aborted. This
SHOULD be auditable. Note, if the certificate was erroneously event 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 Subject 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 re- populate the ID payload: in other words, implementations MUST NOT re-
encode the DN for the purposes of making it DER if it does not appear encode the DN for the purposes of making it DER if it does not 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 Subject from the end-
end-entity certificate if it is empty, even though an empty entity certificate if it is empty, even though an empty certificate
certificate SubjectName is explicitly allowed in the "Subject" Subject is explicitly allowed in the "Subject" section of the PKIX
section of PKIX. certificate profile.
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
in large scale deployments. Therefore, implementations also MUST be in large scale deployments. Therefore, implementations also MUST be
able to perform SPD matches of any combination of one or more of the able to perform SPD matches of any combination of one or more of the
C, CN, O, OU attributes within Subject DN in the ID to the same in C, CN, O, OU attributes within Subject DN in the ID to the same in
the SPD. Implementations MAY support matching using additional DN the SPD. Implementations MAY support matching using additional DN
attributes in any combination, although interoperability is far from attributes in any combination, although interoperability is far from
skipping to change at page 12, line 28 skipping to change at page 12, line 21
Implementations MUST NOT generate this type. Implementations MUST NOT generate this type.
3.1.7. ID_KEY_ID 3.1.7. ID_KEY_ID
The ID_KEY_ID type used to specify pre-shared keys and thus is out of The ID_KEY_ID type used to specify pre-shared keys and thus is out of
scope. scope.
3.1.8. Selecting an Identity from a Certificate 3.1.8. Selecting an Identity from a Certificate
Implementations MUST support certificates that contain more than a Implementations MUST support certificates that contain more than a
single identity, such as when SubjectName and the SubjectAltName single identity, such as when the Subject field and the
extension are both populated, or the SubjectAltName extension SubjectAltName extension are both populated, or the SubjectAltName
contains multiple identities irrespective of whether SubjectName is extension contains multiple identities irrespective of whether the
empty or not. In many cases a certificate will contain an identity Subject is empty or not. In many cases a certificate will contain an
such as an IP address in the SubjectAltName extension in addition to identity such as an IP address in the SubjectAltName extension in
a non-empty SubjectName. addition to a non-empty Subject.
Implementations SHOULD populate ID with whichever identity is likely Implementations SHOULD populate ID with whichever identity is likely
to be named in the peer's policy. In practice, this generally means to be named in the peer's policy. In practice, this generally means
FQDN, or USER_FQDN, but this information may also be available to the FQDN, or USER_FQDN, but this information may also be available to the
administrator through some out-of-band means. In the absence of such administrator through some out-of-band means. In the absence of such
out-of-band configuration information, the identity with which an out-of-band configuration information, the identity with which an
implementation chooses to populate the ID payload is a local matter. implementation chooses to populate the ID payload is a local matter.
3.1.9. SubjectName for DN Only 3.1.9. Subject for DN Only
If an FQDN is intended to be processed as an identity for the If an FQDN is intended to be processed as an identity for the
purposes ID matching, it MUST be placed in the dNSName field of the purposes ID matching, it MUST be placed in the dNSName field of the
SubjectAltName extension. Implementations MUST NOT populate SubjectAltName extension. Implementations MUST NOT populate the
SubjectName with an FQDN in place of populating the dNSName field of Subject with an FQDN in place of populating the dNSName field of the
the SubjectAltName extension. SubjectAltName extension.
While nothing prevents an FQDN, USER_FQDN, or IP address information While nothing prevents an FQDN, USER_FQDN, or IP address information
from appearing somewhere in the SubjectName contents, such entries from appearing somewhere in the Subject contents, such entries MUST
MUST NOT be interpreted as identity information for the purposes of NOT be interpreted as identity information for the purposes of
matching with ID or for policy lookup. matching with ID or for policy lookup.
3.1.10. Binding Identity to Policy 3.1.10. Binding Identity to Policy
In the presence of certificates that contain multiple identities, In the presence of certificates that contain multiple identities,
implementations MUST select the most appropriate identity from the implementations MUST select the most appropriate identity from the
certificate and populate the ID with that. The recipient MUST use certificate and populate the ID with that. The recipient MUST use
the identity sent as a first key when selecting the policy. The the identity sent as a first key when selecting the policy. The
recipient MUST also use the most specific policy from that database recipient MUST also use the most specific policy from that database
if there are overlapping policies caused by wildcards (or the if there are overlapping policies caused by wildcards (or the
implementation can de-correlate the policy database so there will not implementation can de-correlate the policy database so there will not
be overlapping entries, or it can also forbid creation of overlapping be overlapping entries, or it can also forbid creation of overlapping
policies and leave the de-correlation process to the administrator, policies and leave the de-correlation process to the administrator,
but as this moves the problem to the administrator it is NOT but as this moves the problem to the administrator it is NOT
RECOMMENDED). RECOMMENDED).
For example, imagine that a implementation is configured with a For example, imagine that an implementation is configured with a
certificate that contains both a non-empty SubjectName and a dNSName. certificate that contains both a non-empty Subject and a dNSName.
The sender's policy may specify which of those to use, and it The sender's policy may specify which of those to use, and it
indicates the policy to the other end by sending that ID. If the indicates the policy to the other end by sending that ID. If the
recipient has both a specific policy for the dNSName for this host recipient has both a specific policy for the dNSName for this host
and generic wildcard rule for some attributes present in the and generic wildcard rule for some attributes present in the Subject
SubjectName, it will match a different policy depending which ID is field, it will match a different policy depending which ID is sent.
sent. As the sender knows why it wanted to connect the peer, it also As the sender knows why it wanted to connect the peer, it also knows
knows what identity it should use to match the policy it needs to the what identity it should use to match the policy it needs to the
operation it tries to perform; it is the only party who can select operation it tries to perform; it is the only party who can select
the ID adequately. the ID adequately.
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 Subject field, a dNSName and
iPAddress. If an iPAddress is sent in ID but no specific entry an 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 Subject or the dNSName
contained in the certificate. contained in the certificate.
The Peer Authorization Database (PAD) as described in 2401bis [10] The Peer Authorization Database (PAD) as described in RFC 4301 [10]
provides a more formal model for the binding of identity to policy in provides a more formal model for the binding of identity to policy in
addition to providing services that deal more specifically with the addition to providing services that deal more specifically with the
details of policy enforcement, which are generally out of scope of details of policy enforcement, which are generally out of scope of
this document. The PAD is intended to provide a link between the SPD this document. The PAD is intended to provide a link between the SPD
and the security association management in protocols such as IKE. and the security association management in protocols such as IKE.
See 2401bis [10], section 4.4.3 for more details. See RFC 4301 [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 (CRLs). It is not clear from ISAKMP exactly how
should be specified or how the peer should respond. We describe the that set should be specified or how the peer should respond. We
semantics on both sides. describe the semantics on both sides.
3.2.1. Certificate Type 3.2.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 desired. ISAKMP defines 10 certificate keying materials that are desired. ISAKMP defines 10
types of Certificate Data that can be requested and specifies the types of Certificate Data that can be requested and specifies the
syntax for these types, and IKEv2 specifies 3 additional types. For syntax for these types, and IKEv2 specifies 3 additional types. For
the purposes of this document, only the following types are relevant: the purposes of this document, only the following types are relevant:
o X.509 Certificate - Signature o X.509 Certificate - Signature
o Revocation Lists (CRL and ARL) o Revocation Lists (CRL and ARL)
o PKCS #7 wrapped X.509 certificate o PKCS #7 wrapped X.509 certificate
o IKEv2's Hash and URL of X.509 certificate o IKEv2's Hash and URL of X.509 certificate
The use of the other types: The use of the other types are out of the scope of this document:
o X.509 Certificate - Key Exchange o X.509 Certificate - Key Exchange
o PGP Certificate o PGP Certificate
o DNS Signed Key o DNS Signed Key
o Kerberos Tokens o Kerberos Tokens
o SPKI Certificate o SPKI Certificate
o X.509 Certificate Attribute o X.509 Certificate Attribute
o IKEv2's Raw RSA Key o IKEv2's Raw RSA Key
o IKEv2's Hash and URL of X.509 bundle o IKEv2's Hash and URL of X.509 bundle
are out of the scope of this document.
3.2.2. X.509 Certificate - Signature 3.2.2. X.509 Certificate - Signature
This type requests that the end-entity certificate be a certificate This type requests that the end-entity certificate be a certificate
used for signing. used for signing.
3.2.3. Revocation Lists (CRL and ARL) 3.2.3. Revocation Lists (CRL and ARL)
ISAKMP and IKEv2 do not support Certificate Payload sizes over ISAKMP and IKEv2 do not support Certificate Payload sizes over
approximately 64K, which is too small for many CRLs. Therefore, the approximately 64K, which is too small for many CRLs. Therefore, the
acquisition of revocation material is to be dealt with out-of-band of acquisition of revocation material is to be dealt with out-of-band of
skipping to change at page 15, line 35 skipping to change at page 15, line 25
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 its X.509 certificate, instead of the actual certificate itself.
is a particularly useful mechanism when the peer is a device with This is a particularly useful mechanism when the peer is a device
little memory and lower bandwidth, e.g. a mobile handset or consumer with little memory and lower bandwidth, e.g. a mobile handset or
electronics device. consumer 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_CERT_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 of HTTP_CERT_LOOKUP_SUPPORTED.
3.2.6. Location of Certificate Payloads 3.2.6. Location of Certificate Payloads
In IKEv1 Main Mode, the CERTREQ payload MUST be in messages 4 and 5. In IKEv1 Main Mode, 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 in IKEv2, it is possible to have one side authenticating with
certificates while the other side authenticates with preshared keys. certificates while the other side authenticates with preshared keys.
3.2.7. Presence or Absence of Certificate Request Payloads 3.2.7. Presence or Absence of Certificate Request Payloads
skipping to change at page 16, line 28 skipping to change at page 16, line 16
payloads. payloads.
3.2.8. Certificate Requests 3.2.8. Certificate Requests
3.2.8.1. Specifying Certification Authorities 3.2.8.1. Specifying Certification Authorities
When requesting in-band exchange of keying materials, implementations When requesting in-band exchange of keying materials, implementations
SHOULD generate CERTREQs for every peer trust anchor that local SHOULD generate CERTREQs for every peer trust anchor that local
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 Subject field of the trust anchor, populated such that
comparison of the SubjectName and the Certification Authority will binary comparison of the Subject 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 out- configuration specifies that keying materials must be exchanged out-
of-band. Implementations MAY send certificates other than the end- of-band. Implementations MAY send certificates other than the end-
entity certificate (see Section 3.3 for discussion). entity certificate (see Section 3.3 for discussion).
skipping to change at page 16, line 52 skipping to change at page 16, line 40
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
is "X.509 Certificate - Signature" and where a the Certification is "X.509 Certificate - Signature" and where a the Certification
Authority field is not empty. However, implementations MAY generate Authority field is not empty. However, implementations MAY generate
CERTREQs with an empty Certification Authority field under special CERTREQs with an empty Certification Authority field under special
conditions. Although PKIX prohibits certificates with empty conditions. Although PKIX prohibits certificates with an empty
IssuerName fields, there does exist a use case where doing so is Issuer field, there does exist a use case where doing so is
appropriate, and carries special meaning in the IKE context. This appropriate, and carries special meaning in the IKE context. This
has become a convention within the IKE interoperability tests and has become a convention within the IKE interoperability tests and
usage space, and so its use is specified, explained here for the sake usage space, and so its use is specified, explained here for the sake
of interoperability. of interoperability.
USE CASE: Consider the rare case where you have a gateway with USE CASE: Consider the rare case where you have a gateway with
multiple policies for a large number of IKE peers: some of these multiple policies for a large number of IKE peers: some of these
peers are business partners, some are remote access employees, some peers are business partners, some are remote access employees, some
are teleworkers, some are branch offices, and/or the gateway may be are teleworkers, some are branch offices, and/or the gateway may be
simultaneously serving many customers (e.g. Virtual Routers). The simultaneously serving many customers (e.g. Virtual Routers). The
skipping to change at page 17, line 37 skipping to change at page 17, line 26
Sending all possible Certification Authorities will cause significant Sending all possible Certification Authorities will cause significant
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 CAs 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 18, line 25 skipping to change at page 18, line 14
Instead of sending a empty CERTREQ, the responder implementation MAY Instead of sending a empty CERTREQ, the responder implementation MAY
be configured to terminate the negotiation on the grounds of a be configured to terminate the negotiation on the grounds of a
conflict with locally configured security policy. conflict with locally configured security policy.
The decision of which to configure is a matter of local security The decision of which to configure is a matter of local security
policy, this document RECOMMENDS that both options be presented to policy, this document RECOMMENDS that both options be presented to
administrators. administrators.
More examples, and explanation on this issue are included in "More on More examples, and explanation on this issue are included in "More on
Empty CERTREQs" (Appendix C). Empty CERTREQs" (Appendix B).
3.2.9. Robustness 3.2.9. Robustness
3.2.9.1. Unrecognized or Unsupported Certificate Types 3.2.9.1. Unrecognized or Unsupported Certificate Types
Implementations MUST be able to deal with receiving CERTREQs with Implementations MUST be able to deal with receiving CERTREQs with
unsupported Certificate Types. Absent any recognized and supported unsupported Certificate Types. Absent any recognized and supported
CERTREQ types, implementations MAY treat them as if they are of a CERTREQ types, implementations MAY treat them as if they are of a
supported type with the Certification Authority field left empty, supported type with the Certification Authority field left empty,
depending on local policy. ISAKMP [2] Section 5.10 "Certificate depending on local policy. ISAKMP [2] Section 5.10 "Certificate
skipping to change at page 19, line 4 skipping to change at page 18, line 39
Implementations MUST be able to deal with receiving CERTREQs with Implementations MUST be able to deal with receiving CERTREQs with
undecodable Certification Authority fields. Implementations MAY undecodable Certification Authority fields. Implementations MAY
ignore such payloads, depending on local policy. ISAKMP specifies ignore such payloads, depending on local policy. ISAKMP specifies
other actions which may be taken. other actions which may be taken.
3.2.9.3. Ordering of Certificate Request Payloads 3.2.9.3. Ordering of Certificate Request Payloads
Implementations MUST NOT assume that CERTREQs are ordered in any way. Implementations MUST NOT assume that CERTREQs are ordered in any way.
3.2.10. Optimizations 3.2.10. Optimizations
3.2.10.1. Duplicate Certificate Request Payloads 3.2.10.1. Duplicate Certificate Request Payloads
Implementations SHOULD NOT send duplicate CERTREQs during an Implementations SHOULD NOT send duplicate CERTREQs during an
exchange. exchange.
3.2.10.2. Name Lowest 'Common' Certification Authorities 3.2.10.2. Name Lowest 'Common' Certification Authorities
When a peer's certificate keying materials have been cached, an When a peer's certificate keying material has been cached, an
implementation can send a hint to the peer to elide some of the implementation can send a hint to the peer to elide some of the
certificates the peer would normally respond with. In addition to certificates the peer would normally include in the response. In
the normal set of CERTREQs that are sent specifying the trust addition to the normal set of CERTREQs that are sent specifying the
anchors, an implementation MAY send CERTREQs specifying the relevant trust anchors, an implementation MAY send CERTREQs specifying the
cached end-entity certificates. When sending these hints, it is relevant cached end-entity certificates. When sending these hints,
still necessary to send the normal set of trust anchor CERTREQs it is still necessary to send the normal set of trust anchor CERTREQs
because the hints do not sufficiently convey all of the information because the hints do not sufficiently convey all of the information
required by the peer. Specifically, either the peer may not support required by the peer. Specifically, either the peer may not support
this optimization or there may be additional chains that could be this optimization or there may be additional chains that could be
used in this context but will not be if only the end-entity used in this context but will not be if only the end-entity
certificate is specified. certificate is specified.
No special processing is required on the part of the recipient of No special processing is required on the part of the recipient of
such a CERTREQ, and the end-entity certificates will still be sent. such a CERTREQ, and the end-entity certificates will still be sent.
On the other hand, the recipient MAY elect to elide certificates On the other hand, the recipient MAY elect to elide certificates
based on receipt of such hints. based on receipt of such hints.
skipping to change at page 19, line 47 skipping to change at page 19, line 34
this optimization MUST recognize when the end-entity certificate has this optimization MUST recognize when the end-entity certificate has
changed and respond to it by not performing this optimization if the changed and respond to it by not performing this optimization if the
exchange must be retried so that any missing keying materials will be exchange must be retried so that any missing keying materials will be
sent during retry. sent during retry.
3.2.10.3. Example 3.2.10.3. Example
Imagine that an IKEv1 implementation has previously received and Imagine that an IKEv1 implementation has previously received and
cached the peer certificate chain TA->CA1->CA2->EE. If during a cached the peer certificate chain TA->CA1->CA2->EE. If during a
subsequent exchange this implementation sends a CERTREQ containing subsequent exchange this implementation sends a CERTREQ containing
the SubjectName in certificate TA, this implementation is requesting the Subject field in certificate TA, this implementation is
that the peer send at least 3 certificates: CA1, CA2, and EE. On the requesting that the peer send at least 3 certificates: CA1, CA2, and
other hand, if this implementation also sends a CERTREQ containing EE. On the other hand, if this implementation also sends a CERTREQ
the SubjectName of CA2, the implementation is providing a hint that containing the Subject field of CA2, the implementation is providing
only 1 certificate needs to be sent: EE. Note that in this example, a hint that only 1 certificate needs to be sent: EE. Note that in
the fact that TA is a trust anchor should not be construed to imply this example, the fact that TA is a trust anchor should not be
that TA is a self-signed certificate. construed to imply that TA is a self-signed certificate.
3.3. Certificate Payload 3.3. Certificate Payload
The Certificate (CERT) Payload allows the peer to transmit a single The Certificate (CERT) Payload allows the peer to transmit a single
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. Exchanging trust anchors and
ARLs in IKE is to: especially CRLs and ARLs in IKE would increase the liklihood of UDP
fragmentation, make the IKE exchange more complex, and consume
o decrease UDP fragmentation additional network bandwidth.
o simplify the IKE exchange
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 intermediate 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 the PKIX
in the context of IPsec. The issue of how to represent IKE- certificate profile make sense in the context of IPsec. The issue of
meaningful name-forms in a certificate is especially problematic. how to represent IKE-meaningful name-forms in a certificate is
This document provides a profile for a subset of PKIX that makes especially problematic. This document provides a profile for a
sense for IKEv1/ISAKMP and IKEv2. subset of the PKIX certificate profile that makes 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:
o X.509 Certificate - Signature o X.509 Certificate - Signature
o Revocation Lists (CRL and ARL) o Revocation Lists (CRL and ARL)
o PKCS #7 wrapped X.509 certificate o PKCS #7 wrapped X.509 certificate
o IKEv2's Hash and URL of X.509 certificate o IKEv2's Hash and URL of X.509 certificate
The use of the other types: The use of the other types are out of the scope of this document:
o X.509 Certificate - Key Exchange o X.509 Certificate - Key Exchange
o PGP Certificate o PGP Certificate
o DNS Signed Key o DNS Signed Key
o Kerberos Tokens o Kerberos Tokens
o SPKI Certificate o SPKI Certificate
o X.509 Certificate Attribute o X.509 Certificate Attribute
o IKEv2's Raw RSA Key o IKEv2's Raw RSA Key
o IKEv2's Hash and URL of X.509 bundle o IKEv2's Hash and URL of X.509 bundle
are out of the scope of this document.
3.3.2. X.509 Certificate - Signature 3.3.2. X.509 Certificate - Signature
This type specifies that Certificate Data contains a certificate used This type specifies that Certificate Data contains a certificate used
for signing. for signing.
3.3.3. Revocation Lists (CRL and ARL) 3.3.3. Revocation Lists (CRL and ARL)
These types specify that Certificate Data contains an X.509 CRL or These types specify that Certificate Data contains an X.509 CRL or
ARL. These types SHOULD NOT be sent in IKE. See Section 3.2.3 for ARL. These types SHOULD NOT be sent in IKE. See Section 3.2.3 for
discussion. discussion.
3.3.4. IKEv2's Hash and URL of X.509 Certificate 3.3.4. IKEv2's Hash and URL of X.509 Certificate
This type specifies that Certificate Data contains a hash and the URL This type specifies that Certificate Data contains a hash and the URL
to a repository where an X.509 certificate can be retrieved. to a repository where an X.509 certificate can be retrieved.
An implementation that sends a HTTP_LOOKUP_SUPPORTED notification An implementation that sends a HTTP_CERT_LOOKUP_SUPPORTED
MUST support the http scheme and MAY support the ftp scheme, and MUST notification MUST support the http scheme and MAY support the ftp
NOT require any specific form of the url-path and it SHOULD support scheme, and MUST NOT require any specific form of the url-path and it
having user-name, password and port parts in the URL. The following SHOULD support having user-name, password and port parts in the URL.
are examples of mandatory forms: The following are examples of mandatory forms:
o http://certs.example.com/certificate.crt o http://certs.example.com/certificate.cer
o http://certs.example.com/certs/cert.pl?u=foo;a=pw;valid-to=+86400 o http://certs.example.com/certs/cert.pl?u=foo;a=pw;valid-to=+86400
o http://certs.example.com/%0a/../foo/bar/zappa o http://certs.example.com/%0a/../foo/bar/zappa
while the following is an example of a form that SHOULD be supported: while the following is an example of a form that SHOULD be supported:
o http://user:password@certs.example.com:8888/certificate.crt o http://user:password@certs.example.com:8888/certificate.cer
The following is an example of the ftp scheme that MAY be supported: The following is an example of the ftp scheme that MAY be supported:
o ftp://ftp.example.com/pub/certificate.crt o ftp://ftp.example.com/pub/certificate.cer
3.3.5. PKCS #7 wrapped X.509 certificate 3.3.5. PKCS #7 wrapped X.509 certificate
This type defines a particular encoding, not a particular certificate This type defines a particular encoding, not a particular certificate
type. Implementations SHOULD NOT generate CERTs that contain this type. Implementations SHOULD NOT generate CERTs that contain this
Certificate Type. Implementations SHOULD accept CERTs that contain Certificate Type. Implementations SHOULD accept CERTs that contain
this Certificate Type because several implementations are known to this Certificate Type because several implementations are known to
generate them. Note that those implementations sometimes include generate them. Note that those implementations sometimes include
entire certificate hierarchies inside a single CERT PKCS #7 payload, entire certificate hierarchies inside a single CERT PKCS #7 payload,
which violates the requirement specified in ISAKMP that this payload which violates the requirement specified in ISAKMP that this payload
contain a single certificate. contain a single certificate.
3.3.6. Location of Certificate Payloads 3.3.6. Location of Certificate Payloads
In IKEv1 Main Mode, the CERT payload MUST be in messages 5 and 6. In In IKEv1 Main Mode, the CERT payload MUST be in messages 5 and 6. In
IKEv2, the CERT payload must be in messages 3 and 4. Note that in IKEv2, the CERT payload MUST be in messages 3 and 4. Note that in
IKEv2, it is possible to have one side authenticating with IKEv2, it is possible to have one side authenticating with
certificates while the other side authenticates with preshared keys. certificates while the other side authenticates with preshared keys.
3.3.7. Certificate Payloads Not Mandatory 3.3.7. Certificate Payloads Not Mandatory
An implementation which does not receive any CERTREQs during an An implementation which does not receive any CERTREQs during an
exchange SHOULD NOT send any CERT payloads, except when explicitly exchange SHOULD NOT send any CERT payloads, except when explicitly
configured to proactively send CERT payloads in order to interoperate configured to proactively send CERT payloads in order to interoperate
with non-compliant implementations which fail to send CERTREQs even with non-compliant implementations which fail to send CERTREQs even
when certificates are desired. In this case, an implementation MAY when certificates are desired. In this case, an implementation MAY
send the certificate chain (not including the trust anchor) send the certificate chain (not including the trust anchor)
associated with the end-entity certificate. This MUST NOT be the associated with the end-entity certificate. This MUST NOT be the
default behavior of implementations. default behavior of implementations.
Implementations whose local security policy configuration expects Implementations whose local security policy configuration expects
that a peer must receive certificates through out-of-band means that a peer must receive certificates through out-of-band means
SHOULD ignore any CERTREQ messages that are received. SHOULD ignore any CERTREQ messages that are received. Such a
condition has been known to occur due to non-compliant or buggy
implementations.
Implementations that receive CERTREQs from a peer which contain only Implementations that receive CERTREQs from a peer which contain only
unrecognized Certification Authorities SHOULD NOT continue the unrecognized Certification Authorities SHOULD NOT continue the
exchange, in order to avoid unnecessary and potentially expensive exchange, in order to avoid unnecessary and potentially expensive
cryptographic processing, denial of service (resource starvation) cryptographic processing, denial-of-service (resource starvation)
attacks. attacks.
3.3.8. Response to Multiple Certification Authority Proposals 3.3.8. Response to Multiple Certification Authority Proposals
In response to multiple CERTREQs which contain different In response to multiple CERTREQs which contain different
Certification Authority identities, implementations MAY respond using Certification Authority identities, implementations MAY respond using
an end-entity certificate which chains to a CA that matches any of an end-entity certificate which chains to a CA that matches any of
the identities provided by the peer. the identities provided by the peer.
3.3.9. Using Local Keying Materials 3.3.9. Using Local Keying Materials
skipping to change at page 25, line 6 skipping to change at page 24, line 42
IKEv1 specifies the optional use of the Hash Payload to carry a IKEv1 specifies the optional use of the Hash Payload to carry a
pointer to a certificate in either of the Phase 1 public key pointer to a certificate in either of the Phase 1 public key
encryption modes. This pointer is used by an implementation to encryption modes. This pointer is used by an implementation to
locate the end-entity certificate that contains the public key that a locate the end-entity certificate that contains the public key that a
peer should use for encrypting payloads during the exchange. peer should use for encrypting payloads during the exchange.
Implementations SHOULD include this payload whenever the public Implementations SHOULD include this payload whenever the public
portion of the keypair has been placed in a certificate. portion of the keypair has been placed in a certificate.
4. Profile of PKIX 4. Certificate Profile
Except where specifically stated in this document, implementations Except where specifically stated in this document, implementations
MUST conform to the requirements of PKIX [5]. MUST conform to the requirements of the PKIX [5] certificate profile.
4.1. X.509 Certificates 4.1. X.509 Certificates
Users deploying IKE and IPsec with certificates have often had little Users deploying IKE and IPsec with certificates have often had little
control over the capabilities of CAs available to them. control over the capabilities of CAs available to them.
Implementations of this specification may include configuration knobs Implementations of this specification may include configuration knobs
to disable checks required by this specification in order to permit to disable checks required by this specification in order to permit
use with inflexible and/or noncompliant CAs. However, all checks on use with inflexible and/or noncompliant CAs. However, all checks on
certificates exist for a specific reason involving the security of certificates exist for a specific reason involving the security of
the entire system. Therefore, all checks MUST be enabled by default. the entire system. Therefore, all checks MUST be enabled by default.
Administrators and users ought to understand the security purpose for Administrators and users ought to understand the security purpose for
the various checks, and be clear on what security will be lost by the various checks, and be clear on what security will be lost by
disabling the check. disabling the check.
4.1.1. Versions 4.1.1. Versions
Although PKIX states that "implementations SHOULD be prepared to Although PKIX states that "implementations SHOULD be prepared to
accept any version certificate", in practice this profile requires accept any version certificate", in practice this profile requires
certain extensions that necessitate the use of Version 3 certificates certain extensions that necessitate the use of Version 3 certificates
for all but self-signed certificates used as trust anchors. for all but self-signed certificates used as trust anchors.
Implementations that conform to this document MAY therefore reject Implementations that conform to this document MAY therefore reject
Version 1 and Version 2 certificates in all other cases. Version 1 and Version 2 certificates in all other cases.
4.1.2. SubjectName 4.1.2. Subject
Certification Authority implementations MUST be able to create Certification Authority implementations MUST be able to create
certificates with SubjectName fields with at least the following four certificates with Subject fields with at least the following four
attributes: CN, C, O, OU. Implementations MAY support other attributes: CN, C, O, OU. Implementations MAY support other Subject
SubjectName attributes as well. The contents of these attributes attributes as well. The contents of these attributes SHOULD be
SHOULD be configurable on a certificate by certificate basis, as configurable on a certificate by certificate basis, as these fields
these fields will likely be used by IKE implementations to match SPD will likely be used by IKE implementations to match SPD policy.
policy.
See Section 3.1.5 for details on how IKE implementations need to be See Section 3.1.5 for details on how IKE implementations need to be
able to process SubjectName field attributes for SPD policy lookup. able to process Subject field attributes for SPD policy lookup.
4.1.2.1. Empty SubjectName 4.1.2.1. Empty Subject Name
IKE Implementations MUST accept certificates which contain an empty IKE Implementations MUST accept certificates which contain an empty
SubjectName field, as specified in PKIX. Identity information in Subject field, as specified in the PKIX certificate profile.
such certificates will be contained entirely in the SubjectAltName Identity information in such certificates will be contained entirely
extension. in the SubjectAltName extension.
4.1.2.2. Specifying Hosts and not FQDN in SubjectName 4.1.2.2. Specifying Hosts and not FQDN in the Subject Name
Implementations which desire to place host names that are not Implementations which desire to place host names that are not
intended to be processed by recipients as FQDNs (for instance intended to be processed by recipients as FQDNs (for instance
"Gateway Router") in the SubjectName MUST use the commonName "Gateway Router") in the Subject MUST use the commonName attribute.
attribute.
4.1.2.3. EmailAddress 4.1.2.3. EmailAddress
As specified in PKIX, implementations MUST NOT populate As specified in the PKIX certificate profile, implementations MUST
DistinguishedNames with the emailAddress attribute. NOT populate X.500 distinguished names with the emailAddress
attribute.
4.1.3. X.509 Certificate Extensions 4.1.3. X.509 Certificate Extensions
Conforming IKE implementations MUST recognize extensions which must Conforming IKE implementations MUST recognize extensions which must
or may be marked critical according to this specification. These or may be marked critical according to this specification. These
extensions are: KeyUsage, SubjectAltName, and BasicConstraints. extensions are: KeyUsage, SubjectAltName, and BasicConstraints.
Certification Authority implementations SHOULD generate certificates Certification Authority implementations SHOULD generate certificates
such that the extension criticality bits are set in accordance with such that the extension criticality bits are set in accordance with
PKIX and this document. With respect to PKIX compliance, IKE the PKIX certifiate profile and this document. With respect to
implementations processing certificates MAY ignore the value of the compliance with the PKIX certificate profile, IKE implementations
criticality bit for extensions that are supported by that processing certificates MAY ignore the value of the criticality bit
implementation, but MUST support the criticality bit for extensions for extensions that are supported by that implementation, but MUST
that are not supported by that implementation. That is, a relying support the criticality bit for extensions that are not supported by
party processes all the extensions it is aware of whether the bit is that implementation. That is, a peer processes all the extensions it
true or false -- the bit says what happens when a relying party is aware of whether the bit is true or false -- the bit says what
cannot process an extension. happens when a peer cannot process an extension.
implements bit in cert PKIX mandate behavior implements bit in cert PKIX mandate behavior
------------------------------------------------------ ------------------------------------------------------
yes true true ok yes true true ok
yes true false ok or reject yes true false ok or reject
yes false true ok or reject yes false true ok or reject
yes false false ok yes false false ok
no true true reject no true true reject
no true false reject no true false reject
no false true reject no false true reject
skipping to change at page 27, line 16 skipping to change at page 26, line 49
absence of these extensions, such as those that require possibly absence of these extensions, such as those that require possibly
verifying a signature against a large number of similarly named CA verifying a signature against a large number of similarly named CA
certificates in order to find the CA certificate which contains the certificates in order to find the CA certificate which contains the
key that was used to generate the signature. key that was used to generate the signature.
4.1.3.2. KeyUsage 4.1.3.2. KeyUsage
IKE uses an end-entity certificate in the authentication process. IKE uses an end-entity certificate in the authentication process.
The end-entity certificate may be used for multiple applications. As The end-entity certificate may be used for multiple applications. As
such, the CA can impose some constraints on the manner that a public such, the CA can impose some constraints on the manner that a public
key ought to be used. The KeyUsage and ExtendedKeyUsage extensions key ought to be used. The KeyUsage (KU) and ExtendedKeyUsage (EKU)
apply in this situation. extensions apply in this situation.
Since we are talking about using the public key to validate a Since we are talking about using the public key to validate a
signature, if the KeyUsage extension is present, then at least one of signature, if the KeyUsage extension is present, then at least one of
the digitalSignature or the nonRepudiation bits in the KeyUsage the digitalSignature or the nonRepudiation bits in the KeyUsage
extension MUST be set (both can be set as well). It is also fine if extension MUST be set (both can be set as well). It is also fine if
other KeyUsage bits are set. other KeyUsage bits are set.
A summary of the logic flow for peer cert validation follows: A summary of the logic flow for peer cert validation follows:
o If no KU extension, continue. o If no KU extension, continue.
o If KU present and doesn't mention digitalSignature or o If KU present and doesn't mention digitalSignature or
nonRepudiation (both, in addition to other KUs, is also fine), nonRepudiation (both, in addition to other KUs, is also fine),
reject cert. reject cert.
o If none of the above, continue. o If none of the above, continue.
4.1.3.3. PrivateKeyUsagePeriod 4.1.3.3. PrivateKeyUsagePeriod
PKIX recommends against the use of this extension. The The PKIX certificate profile recommends against the use of this
PrivateKeyUsageExtension is intended to be used when signatures will extension. The PrivateKeyUsageExtension is intended to be used when
need to be verified long past the time when signatures using the signatures will need to be verified long past the time when
private keypair may be generated. Since IKE SAs are short-lived signatures using the private keypair may be generated. Since IKE SAs
relative to the intended use of this extension in addition to the are short-lived relative to the intended use of this extension in
fact that each signature is validated only a single time, the addition to the fact that each signature is validated only a single
usefulness of this extension in the context of IKE is unclear. time, the usefulness of this extension in the context of IKE is
Therefore, Certification Authority implementations MUST NOT generate unclear. Therefore, Certification Authority implementations MUST NOT
certificates that contain the PrivateKeyUsagePeriod extension. If an generate certificates that contain the PrivateKeyUsagePeriod
IKE implementation receives a certificate with this set, it SHOULD extension. If an IKE implementation receives a certificate with this
ignore it. set, it SHOULD ignore it.
4.1.3.4. CertificatePolicies 4.1.3.4. CertificatePolicies
Many IKE implementations do not currently provide support for the Many IKE implementations do not currently provide support for the
CertificatePolicies extension. Therefore, Certification Authority CertificatePolicies extension. Therefore, Certification Authority
implementations that generate certificates which contain this implementations that generate certificates which contain this
extension SHOULD NOT mark the extension as critical. extension SHOULD NOT mark the extension as critical.
4.1.3.5. PolicyMappings 4.1.3.5. PolicyMappings
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 FQDN, USER_FQDN, IPV4_ADDR,
IPV4_ADDR or IPV6_ADDR MUST issue certificates with the corresponding 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 IKEv1/ISAKMP/ SubjectAltName extension, as these choices map to legal IKEv1/ISAKMP/
IKEv2 Identification Payload types: rfc822Name, dNSName, or IKEv2 Identification Payload types: rfc822Name, dNSName, or
iPAddress. Although it is possible to specify any GeneralName choice iPAddress. Although it is possible to specify any GeneralName choice
in the Identification Payload by using the ID_DER_ASN1_GN ID type, in the Identification Payload by using the ID_DER_ASN1_GN ID type,
implementations SHOULD NOT assume support for such functionality, and implementations SHOULD NOT assume support for such 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
skipping to change at page 28, line 42 skipping to change at page 28, line 27
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 [14] MUST match its contents. Note that although PKIX permits CIDR [15]
notation in the "Name Constraints" extension, PKIX explicitly notation in the "Name Constraints" extension, the PKIX certificate
prohibits using CIDR notation for conveying identity information. In profile explicitly prohibits using CIDR notation for conveying
other words, the CIDR notation MUST NOT be used in the SubjectAltName identity information. In other words, the CIDR notation MUST NOT be
extension. used in the SubjectAltName 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
contains a valid email address, unless this is known by way of some contains a valid email address, unless this is known by way of some
out-of-band mechanism. Such a mechanism is out of the scope of this out-of-band mechanism. Such a mechanism is out of the scope of this
document. document.
skipping to change at page 29, line 20 skipping to change at page 29, line 5
Certification Authority implementations SHOULD NOT assume that other Certification Authority implementations SHOULD NOT assume that other
implementations support the IssuerAltName extension, and especially implementations support the IssuerAltName extension, and especially
should not assume that information contained in this extension will should not assume that information contained in this extension will
be displayed to end users. be displayed to end users.
4.1.3.8. SubjectDirectoryAttributes 4.1.3.8. SubjectDirectoryAttributes
The SubjectDirectoryAttributes extension is intended to convey The SubjectDirectoryAttributes extension is intended to convey
identification attributes of the subject. IKE implementations MAY identification attributes of the subject. IKE implementations MAY
ignore this extension when it is marked non-critical, as PKIX ignore this extension when it is marked non-critical, as the PKIX
mandates. certificate profile mandates.
4.1.3.9. BasicConstraints 4.1.3.9. BasicConstraints
PKIX mandates that CA certificates contain this extension and that it The PKIX certificate profile mandates that CA certificates contain
be marked critical. IKE implementations SHOULD reject CA this extension and that it be marked critical. IKE implementations
certificates that do not contain this extension. For backwards SHOULD reject CA certificates that do not contain this extension.
compatibility, implementations may accept such certificates if For backwards compatibility, implementations may accept such
explicitly configured to do so, but the default for this setting MUST certificates if explicitly configured to do so, but the default for
be to reject such certificates. this setting MUST be to reject such certificates.
4.1.3.10. NameConstraints 4.1.3.10. NameConstraints
Many IKE implementations do not support the NameConstraints Many IKE implementations do not support the NameConstraints
extension. Since PKIX mandates that this extension be marked extension. Since the PKIX certificate profile mandates that this
critical when present, Certification Authority implementations which extension be marked critical when present, Certification Authority
are interested in maximal interoperability for IKE SHOULD NOT implementations which are interested in maximal interoperability for
generate certificates which contain this extension. IKE SHOULD NOT generate certificates which contain this extension.
4.1.3.11. PolicyConstraints 4.1.3.11. PolicyConstraints
Many IKE implementations do not support the PolicyConstraints Many IKE implementations do not support the PolicyConstraints
extension. Since PKIX mandates that this extension be marked extension. Since the PKIX certificate profile mandates that this
critical when present, Certification Authority implementations which extension be marked critical when present, Certification Authority
are interested in maximal interoperability for IKE SHOULD NOT implementations which are interested in maximal interoperability for
generate certificates which contain this extension. IKE SHOULD NOT generate certificates which contain this extension.
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
skipping to change at page 30, line 45 skipping to change at page 30, line 33
o If no EKU extension, continue. o If no EKU extension, continue.
o If EKU present AND contains either id-kp-ipsecIKE or o If EKU present AND contains either id-kp-ipsecIKE or
anyExtendedKeyUsage, continue. anyExtendedKeyUsage, continue.
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 [15]). The IPsec peer either needs to have a Status Protocol - OCSP [16]). 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 CRLDistributionPoints/ Failure to validate the CRLDistributionPoints/
IssuingDistributionPoint pair can result in CRL substitution where an IssuingDistributionPoint pair can result in CRL substitution where an
entity knowingly substitutes a known good CRL from a different entity knowingly substitutes a known good CRL from a different
distribution point for the CRL which is supposed to be used which distribution point for the CRL which is supposed to be used which
would show the entity as revoked. IKE implementations MUST support would show the entity as revoked. IKE implementations MUST support
validating that the contents of CRLDistributionPoints match those of validating that the contents of CRLDistributionPoints match those of
the IssuingDistributionPoint to prevent CRL substitution when the the IssuingDistributionPoint to prevent CRL substitution when the
issuing CA is using them. At least one CA is known to default to issuing CA is using them. At least one CA is known to default to
this type of CRL use. See Section 4.2.2.5 for more information. this type of CRL use. See Section 4.2.2.5 for 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 the IETF IPR web page for CRLDistributionPoints intellectual
(IPR) information. Note that both the CRLDistributionPoints and property rights (IPR) information. Note that both the
IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED CRLDistributionPoints and IssuingDistributionPoint extensions are
by PKIX, so there is no requirement to license any IPR. RECOMMENDED but not REQUIRED by the PKIX certificate profile, so
there is no requirement to license any IPR.
4.1.3.14. InhibitAnyPolicy 4.1.3.14. InhibitAnyPolicy
Many IKE implementations do not support the InhibitAnyPolicy Many IKE implementations do not support the InhibitAnyPolicy
extension. Since PKIX mandates that this extension be marked extension. Since the PKIX certificate profile mandates that this
critical when present, Certification Authority implementations which extension be marked critical when present, Certification Authority
are interested in maximal interoperability for IKE SHOULD NOT implementations which are interested in maximal interoperability for
generate certificates which contain this extension. IKE SHOULD NOT generate certificates which contain this extension.
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 The PKIX certificate profile defines the AuthorityInfoAccess
indicate "how to access CA information and services for the issuer of extension, which is used to indicate "how to access CA information
the certificate in which the extension appears." Because this and services for the issuer of the certificate in which the extension
document deprecates the sending of CRLs in band, the use of appears." Because this document deprecates the sending of CRLs in-
AuthorityInfoAccess (AIA) becomes very important if OCSP [15] is to band, the use of AuthorityInfoAccess (AIA) becomes very important if
be used for revocation checking (as opposed to CRLs). The IPsec peer OCSP [16] is to be used for revocation checking (as opposed to CRLs).
either needs to have a URI for the OCSP query written into its local The IPsec peer either needs to have a URI for the OCSP query written
configuration, or it needs to learn it from AIA. Therefore, into its local configuration, or it needs to learn it from AIA.
implementations SHOULD support this extension, especially if OCSP Therefore, implementations SHOULD support this extension, especially
will be used. if OCSP will be used.
4.1.3.17. SubjectInfoAccess 4.1.3.17. SubjectInfoAccess
PKIX defines the SubjectInfoAccess certificate extension, which is The PKIX certificate profile defines the SubjectInfoAccess
used to indicate "how to access information and services for the certificate extension, which is used to indicate "how to access
subject of the certificate in which the extension appears." This information and services for the subject of the certificate in which
extension has no known use in the context of IPsec. Conformant IKE the extension appears." This extension has no known use in the
implementations SHOULD ignore this extension when present. context of IPsec. Conformant IKE 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
SHOULD populate the CRLDistributionPoints extension. Therefore SHOULD populate the CRLDistributionPoints extension. Therefore
Certification Authority implementations MUST support issuing Certification Authority implementations MUST support issuing
certificates with this field populated according to administrator's certificates with this field populated. IKE implementations MAY
needs. IKE implementations MAY provide a configuration option to provide a configuration option to disable use of certain types of
disable use of certain types of revocation information, but that revocation information, but that option MUST be off by default. Such
option MUST be off by default. Such an option is often valuable in an option is often valuable in lab testing environments.
lab testing environments.
4.2.1. Multiple Sources of Certificate Revocation Information 4.2.1. Multiple Sources of Certificate Revocation Information
IKE implementations which support multiple sources of obtaining IKE implementations which support multiple sources of obtaining
certificate revocation information MUST act conservatively when the certificate revocation information MUST act conservatively when the
information provided by these sources is inconsistent: when a information provided by these sources is inconsistent: when a
certificate is reported as revoked by one trusted source, the certificate is reported as revoked by one trusted source, the
certificate MUST be considered revoked. certificate MUST be considered revoked.
4.2.2. X.509 Certificate Revocation List Extensions 4.2.2. X.509 Certificate Revocation List Extensions
skipping to change at page 33, line 8 skipping to change at page 32, line 41
4.2.2.2. IssuerAltName 4.2.2.2. IssuerAltName
Certification Authority implementations SHOULD NOT assume that IKE Certification Authority implementations SHOULD NOT assume that IKE
implementations support the IssuerAltName extension, and especially implementations support the IssuerAltName extension, and especially
should not assume that information contained in this extension will should not assume that information contained in this extension will
be displayed to end users. be displayed to end users.
4.2.2.3. CRLNumber 4.2.2.3. CRLNumber
As stated in PKIX, all issuers conforming to PKIX MUST include this As stated in the PKIX certificate profile, all issuers MUST include
extension in all CRLs. this extension in all CRLs.
4.2.2.4. DeltaCRLIndicator 4.2.2.4. DeltaCRLIndicator
4.2.2.4.1. If Delta CRLs Are Unsupported 4.2.2.4.1. If Delta CRLs Are Unsupported
IKE implementations that do not support delta CRLs MUST reject CRLs IKE implementations that do not support delta CRLs MUST reject CRLs
which contain the DeltaCRLIndicator (which MUST be marked critical which contain the DeltaCRLIndicator (which MUST be marked critical
according to PKIX) and MUST make use of a base CRL if it is according to the PKIX certficate profile) and MUST make use of a base
available. Such implementations MUST ensure that a delta CRL does CRL if it is available. Such implementations MUST ensure that a
not "overwrite" a base CRL, for instance in the keying material delta CRL does not "overwrite" a base CRL, for instance in the keying
database. material database.
4.2.2.4.2. Delta CRL Recommendations 4.2.2.4.2. Delta CRL Recommendations
Since some IKE implementations that do not support delta CRLs may Since some IKE implementations that do not support delta CRLs may
behave incorrectly or insecurely when presented with delta CRLs, behave incorrectly or insecurely when presented with delta CRLs,
administrators and deployers should consider whether issuing delta administrators and deployers should consider whether issuing delta
CRLs increases security before issuing such CRLs. And, if all the CRLs increases security before issuing such CRLs. And, if all the
elements in the VPN and PKI systems do not adequately support Delta elements in the VPN and PKI systems do not adequately support Delta
CRLs, then their use should be questioned. CRLs, then their use should be questioned.
The editors are aware of several implementations which behave in an The editors are aware of several implementations which behave in an
incorrect or insecure manner when presented with delta CRLs. See incorrect or insecure manner when presented with delta CRLs. See
Appendix B for a description of the issue. Therefore, this Appendix A for a description of the issue. Therefore, this
specification RECOMMENDS NOT issuing delta CRLs at this time. On the specification RECOMMENDS NOT issuing delta CRLs at this time. On the
other hand, failure to issue delta CRLs may expose a larger window of other hand, failure to issue delta CRLs may expose a larger window of
vulnerability if a full CRL is not issued as often as delta CRLs vulnerability if a full CRL is not issued as often as delta CRLs
would be. See the Security Considerations section of PKIX [5] for would be. See the Security Considerations section of the PKIX [5]
additional discussion. Implementors as well as administrators are certificate profile for additional discussion. Implementors as well
encouraged to consider these issues. as administrators are encouraged to consider these issues.
4.2.2.5. IssuingDistributionPoint 4.2.2.5. IssuingDistributionPoint
A CA that is using CRLDistributionPoints may do so to provide many A CA that is using CRLDistributionPoints may do so to provide many
"small" CRLs, each only valid for a particular set of certificates "small" CRLs, each only valid for a particular set of certificates
issued by that CA. To associate a CRL with a certificate, the CA issued by that CA. To associate a CRL with a certificate, the CA
places the CRLDistributionPoints extension in the certificate, and places the CRLDistributionPoints extension in the certificate, and
places the IssuingDistributionPoint in the CRL. The places the IssuingDistributionPoint in the CRL. The
distributionPointName field in the CRLDistributionPoints extension distributionPointName field in the CRLDistributionPoints extension
MUST be identical to the distributionPoint field in the MUST be identical to the distributionPoint field in the
skipping to change at page 34, line 21 skipping to change at page 34, line 6
extension, which is used to obtain delta CRLs. extension, which is used to obtain delta CRLs.
4.3. Strength of Signature Hashing Algorithms 4.3. Strength of Signature Hashing Algorithms
At the time that this document is being written, popular At the time that this document is being written, popular
certification authorities and CA software issue certificates using certification authorities and CA software issue certificates using
the RSA-with-SHA1 and RSA-with-MD5 signature algorithms. the RSA-with-SHA1 and RSA-with-MD5 signature algorithms.
Implementations MUST be able to validate certificates with either of Implementations MUST be able to validate certificates with either of
those algorithms. those algorithms.
As described in [16], both the MD5 and SHA-1 hash algorithms are As described in [17], both the MD5 and SHA-1 hash algorithms are
weaker than originally expected with respect to hash collisions. weaker than originally expected with respect to hash collisions.
Certificates that use these hash algorithms as part of their Certificates that use these hash algorithms as part of their
signature algorithms could conceivably be subject to an attack where signature algorithms could conceivably be subject to an attack where
a CA issues a certificate with a particular identity, and the a CA issues a certificate with a particular identity, and the
recipient of that certificate can create a different valid recipient of that certificate can create a different valid
certificate with a different identity. So far, such an attack is certificate with a different identity. So far, such an attack is
only theoretical, even with the weaknesses found in the hash only theoretical, even with the weaknesses found in the hash
algorithms. algorithms.
Because of the recent attacks, there has been a heightened interest Because of the recent attacks, there has been a heightened interest
in having widespread deployment of additional signature algorithms. in having widespread deployment of additional signature algorithms.
The algorithm that has been mentioned most often is RSA-with-SHA256, The algorithm that has been mentioned most often is RSA-with-SHA256,
two types of which are described in detail in [17]. It is widely two types of which are described in detail in [18]. It is widely
expected that this signature algorithm will be much more resilient to expected that this signature algorithm will be much more resilient to
collision-based attacks than the current RSA-with-SHA1 and RSA-with- collision-based attacks than the current RSA-with-SHA1 and RSA-with-
MD5, although no proof of that has been shown. There is active MD5, although no proof of that has been shown. There is active
discussion in the cryptographic community of better hash functions discussion in the cryptographic community of better hash functions
that could be used in signature algorithms. that could be used in signature algorithms.
In order to interoperate, all implementations need to be able to In order to interoperate, all implementations need to be able to
validate signatures for all algorithms that the implementations will validate signatures for all algorithms that the implementations will
encounter. Therefore, implementations SHOULD be able to use encounter. Therefore, implementations SHOULD be able to use
signatures that use the sha256WithRSAEncryption signature algorithm signatures that use the sha256WithRSAEncryption signature algorithm
(PKCS#1 version 1.5) as soon as possible. At the time that this (PKCS#1 version 1.5) as soon as possible. At the time that this
document is being written, there are no common implementations that document is being written, there is at least one CA that supports
issue certificates with this algorithm, but it is expected that there generating certificates with sha256WithRSAEncryption signature
will be significant deployment of this algorithm by the end of 2007. algorithm and it is expected that there will be significant
deployment of this algorithm by the end of 2007.
5. Configuration Data Exchange Conventions 5. Configuration Data Exchange Conventions
Below we present a common format for exchanging configuration data. Below we present a common format for exchanging configuration data.
Implementations MUST support these formats, MUST support receiving Implementations MUST support these formats, MUST support receiving
arbitrary whitespace at the beginning and end of any line, MUST arbitrary whitespace at the beginning and end of any line, MUST
support receiving arbitrary line lengths although they SHOULD support receiving arbitrary line lengths although they SHOULD
generate lines less than 76 characters, and MUST support receiving generate lines less than 76 characters, and MUST support receiving
the following three line-termination disciplines: LF (US-ASCII 10), the following three line-termination disciplines: LF (US-ASCII 10),
CR (US-ASCII 13), and CRLF. CR (US-ASCII 13), and CRLF.
5.1. Certificates 5.1. Certificates
Certificates MUST be Base64 encoded and appear between the following Certificates MUST be Base64 [19] encoded and appear between the
delimiters: following delimiters:
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
-----END CERTIFICATE----- -----END CERTIFICATE-----
5.2. CRLs and ARLs 5.2. CRLs and ARLs
CRLs and ARLs MUST be Base64 encoded and appear between the following CRLs and ARLs MUST be Base64 encoded and appear between the following
delimiters: delimiters:
-----BEGIN CRL----- -----BEGIN CRL-----
-----END CRL----- -----END CRL-----
5.3. Public Keys 5.3. Public Keys
IKE implementations MUST support two forms of public keys: IKE implementations MUST support two forms of public keys:
certificates and so-called "raw" keys. Certificates should be certificates and so-called "raw" keys. Certificates should be
transferred in the same form as above. A raw key is only the transferred in the same form as Section 5.1. A raw key is only the
SubjectPublicKeyInfo portion of the certificate, and MUST be Base64 SubjectPublicKeyInfo portion of the certificate, and MUST be Base64
encoded and appear between the following delimiters: encoded and appear between the following delimiters:
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
5.4. PKCS#10 Certificate Signing Requests 5.4. PKCS#10 Certificate Signing Requests
A PKCS#10 [9] Certificate Signing Request MUST be Base64 encoded and A PKCS#10 [9] Certificate Signing Request MUST be Base64 encoded and
appear between the following delimiters: appear between the following delimiters:
-----BEGIN CERTIFICATE REQUEST----- -----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST----- -----END CERTIFICATE REQUEST-----
6. Security Considerations 6. Acknowledgements
6.1. Certificate Request Payload The authors would like to acknowledge the expired draft-ietf-ipsec-
pki-req-05.txt for providing valuable materials for this document.
The authors would like to especially thank Eric Rescorla, one of its
original authors, in addition to Greg Carter, Steve Hanna, Russ
Housley, Charlie Kaufman, Tero Kivinen, Pekka Savola, Paul Hoffman,
and Gregory Lebovitz for their valuable comments, some of which have
been incorporated verbatim into this document. Paul Knight performed
the arduous tasks of coverting the text to XML format.
7. Security Considerations
7.1. Certificate Request Payload
The Contents of CERTREQ are not encrypted in IKE. In some The Contents of CERTREQ are not encrypted in IKE. In some
environments this may leak private information. Administrators in environments this may leak private information. Administrators in
some environments may wish to use the empty Certification Authority some environments may wish to use the empty Certification Authority
option to prevent such information from leaking, at the cost of option to prevent such information from leaking, at the cost of
performance. performance.
6.2. IKEv1 Main Mode 7.2. IKEv1 Main Mode
Certificates may be included in any message, and therefore Certificates may be included in any message, and therefore
implementations may wish to respond with CERTs in a message that implementations may wish to respond with CERTs in a message that
offers privacy protection, in Main Mode messages 5 and 6. offers privacy protection, in Main Mode messages 5 and 6.
Implementations may not wish to respond with CERTs in the second Implementations may not wish to respond with CERTs in the second
message, thereby violating the identity protection feature of Main message, thereby violating the identity protection feature of Main
Mode in IKEv1. Mode in IKEv1.
6.3. Disabling Certificate Checks 7.3. Disabling Certificate Checks
It is important to note that anywhere this document suggests It is important to note that anywhere this document suggests
implementors provide users with the configuration option to simplify, implementors provide users with the configuration option to simplify,
modify, or disable a feature or verification step, there may be modify, or disable a feature or verification step, there may be
security consequences for doing so. Deployment experience has shown security consequences for doing so. Deployment experience has shown
that such flexibility may be required in some environments, but that such flexibility may be required in some environments, but
making use of such flexibility can be inappropriate in others. Such making use of such flexibility can be inappropriate in others. Such
configuration options MUST default to "enabled" and it is appropriate configuration options MUST default to "enabled" and it is appropriate
to provide warnings to users when disabling such features. to provide warnings to users when disabling such features.
7. Intellectual Property Rights
No new intellectual property rights are introduced by this document.
8. IANA Considerations 8. IANA Considerations
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", RFC 4306,
draft-ietf-ipsec-ikev2-15 (work in progress), August 2004. December 2005.
[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.
skipping to change at page 37, line 33 skipping to change at page 37, line 26
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] Kent, S. and K. Seo, "Security Architecture for the Internet [10] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), Protocol", RFC 4301, December 2005.
March 2005.
[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 1883, December 1995. Specification", RFC 2460, December 1998.
[12] Eastlake, D., "Domain Name System Security Extensions", [12] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[13] Lynn, C., "X.509 Extensions for IP Addresses and AS [13] Faltstrom, P., Hoffman, P., and A. Costello,
Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in "Internationalizing Domain Names in Applications (IDNA)",
progress), September 2003. RFC 3490, March 2003.
[14] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- [14] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[15] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC 1519, September 1993. Strategy", RFC 1519, September 1993.
[15] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, [16] 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.
[16] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes [17] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes
in Internet Protocols", RFC 4270, November 2005. in Internet Protocols", RFC 4270, November 2005.
[17] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms [18] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055, June 2005. Revocation List (CRL) Profile", RFC 4055, June 2005.
[18] Arsenault, A. and S. Turner, "Internet X.509 Public Key [19] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
Infrastructure: Roadmap", draft-ietf-pkix-roadmap-09 (work in RFC 3548, July 2003.
progress), July 2002.
Appendix A. Change History [20] Y Lim and D. Singer, "MIME Type Registration for MPEG-4",
RFC 4337, March 2006.
Appendix A. The Possible Dangers of Delta CRLs
The problem is that the CRL processing algorithm is sometimes written
incorrectly with the assumption that all CRLs are base CRLs and it is
assumed that CRLs will pass content validity tests. Specifically,
such implementations fail to check the certificate against all
possible CRLs: if the first CRL that is obtained from the keying
material database fails to decode, no further revocation checks are
performed for the relevant certificate. This problem is compounded
by the fact that implementations which do not understand delta CRLs
may fail to decode such CRLs due to the critical DeltaCRLIndicator
extension. The algorithm that is implemented in this case is
approximately:
o fetch newest CRL
o check validity of CRL signature
o if CRL signature is valid then
o if CRL does not contain unrecognized critical extensions and
certificate is on CRL then set certificate status to revoked
The authors note that a number of PKI toolkits do not even provide a
method for obtaining anything but the newest CRL, which in the
presence of delta CRLs may in fact be a delta CRL, not a base CRL.
Note that the above algorithm is dangerous in many ways. See the
PKIX [5] certificate profile for the correct algorithm.
Appendix B. More on Empty CERTREQs
Sending empty certificate requests is commonly used in
implementations, and in the IPsec interop meetings, vendors have
generally agreed that it means that send all/any end-entity
certificates you have (if multiple end-entity certificates are sent,
they must have same public key, as otherwise the other end does not
know which key was used). For 99% of cases the client have exactly
one certificate and public key, so it really doesn't matter, but the
server might have multiple, thus it simply needs to say to the
client, use any certificate you have. If we are talking about
corporate vpns etc, even if the client have multiple certificates or
keys, all of them would be usable when authenticating to the server,
so client can simply pick one.
If there is some real difference on which certificate to use (like
ones giving different permissions), then the client must be
configured anyways, or it might even ask the user which one to use
(the user is the only one who knows whether he needs admin
privileges, thus needs to use admin cert, or is the normal email
privileges ok, thus using email only cert).
99% of the cases the client have exactly one certificate, so it will
send it. In 90% of the rest of the cases, any of the certificates is
ok, as they are simply different certificates from same CA, or
different CAs for the same corporate VPN, thus any of them is ok.
Sending empty certificate requests has been agreed there to mean
"give me your cert; any cert".
Justification:
o Responder first does all it can to send a CERTREQ with a CA, check
for IP match in SPD, have a default set of CAs to use in ambiguous
cases, etc.
o sending empty CERTREQs is fairly common in implementations today,
and is generally accepted to mean "send me a certificate, any
certificate that works for you"
o saves responder sending potentially 100's of certs, the
fragmentation problems that follow, etc.
o in +90% of use cases, Initiators have exactly 1 certificate
o in +90% of the remaining use cases, the multiple certificates it
has are issued by the same CA
o in the remaining use case(s) -- if not all the others above -- the
Initiator will be configured explicitly with which certificate to
send, so responding to an empty CERTREQ is easy.
The following example shows why initiators need to have sufficient
policy definition to know which certificate to use for a given
connection it initiates.
EXAMPLE: Your client (initiator) is configured with VPN policies for
gateways A and B (representing perhaps corporate partners).
The policies for the two gateways look something like:
Acme Company policy (gateway A)
Engineering can access 10.1.1.0
Trusted CA: CA-A, Trusted Users: OU=Engineering
Partners can access 20.1.1.0
Trusted CA: CA-B, Trusted Users: OU=AcmePartners
Bizco Company policy (gateway B)
Sales can access 30.1.1.0
Trusted CA: CA-C, Trusted Users: OU=Sales
Partners can access 40.1.1.0
Trusted CA: CA-B, Trusted Users: OU=BizcoPartners
You are an employee of Acme and you are issued the following
certificates:
o From CA-A: CN=JoeUser,OU=Engineering
o From CA-B: CN=JoePartner,OU=BizcoPartners
The client MUST be configured locally to know which CA to use when
connecting to either gateway. If your client is not configured to
know the local credential to use for the remote gateway, this
scenario will not work either. If you attempt to connect to Bizco,
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
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.
As the initiator, you will be presented with certificate requests
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
know which certificate it should present? It must have sufficiently
clear local policy specifying which one credential to present for the
connection it initiates.
Appendix C. Change History
[RFC Editor, please remove Change History prior to publication as an
RFC]
April 2006 (-10)
* Many places - s/PKIX/the PKIX certificate profile/ (Russ
Housley, AD Review)
* 1 - removed text describing discussion of the document on
pki4ipsec@icsalabs.com mailing list (Russ Housley, AD Review)
* 3.1 - Better wording: "The Identification (ID) Payload
indicates the identity claimed by the sender." (Russ Housley,
AD Review)
* Many places - s/2401bis/RFC 4301/ (Russ Housley, AD Review)
* 3.1 - s/attribute/extension/ when talking about SubjectAltName
(Russ Housley, AD Review)
* 3.1 - s/attribute/value/ when talking about strings in
certificates (Russ Housley, AD Review)
* 3.1.2/3.1.3 - IDN is ok caseless comparison (Russ Housley, AD
Review)
* 3.1.4 - Change ref from SBGP to RFC 3779 (Russ Housley, AD
Review)
* Many places - s/SubjectName/Subject/ (Russ Housley, AD Review)
* 3.2 - add "(CRLs)" (Russ Housley, AD Review)
* 3.2.1 - improved wording (Russ Housley, AD Review)
* 3.2.8.2 - s/empty IssuerName fields/an empty Issuer field/
(Russ Housley, AD Review)
* 3.2.10.2 - s/keying materials have been/keying material has
been/ (Russ Housley, AD Review)
* 3.2.10.2 - s/respond with/include in the response/ (Russ
Housley, AD Review)
* 3.2.10.3 - s/SubjectName of CA2/CA2's Subject name/ (Russ
Housley, AD Review)
* 3.3 - improved wording (Russ Housley, AD Review)
* 3.3.4 - changed ".crt" extension to ".cer" (for alignment with
RFC 2585) (Russ Housley, AD Review)
* 3.3.6 - made inconsitent musts both MUST (Russ Housley, AD
Review)
* 3.3.7 - s/denial of service/denial-of-service/ (Russ Housley,
AD Review)
* 4.1.2.3 - s/DistinguishedNames/X.500 distinguished names/ (Russ
Housley, AD Review)
* 4.1.3 - s/PKIX compliance/the PKIX certificate profile
compliance/ (Russ Housley, AD Review)
* 4.1.3 - s/PKIX and/the PKIX certificate profile and/ (Russ
Housley, AD Review)
* 4.1.3 - "Perhaps "peer" instead of "relyong party" should be
used to match the rest of the document." (Russ Housley, AD
Review)
* 4.1.3.13 - s/PKIX docs/the IETF IPR web page/ (Russ Housley, AD
Review)
* 4.2 - removed ambiguous "according to administrator's needs"
(Russ Housley, AD Review)
* 4.2.2.3 - s/conforming to PKIX// (Russ Housley, AD Review)
* 4.3 - at least 1 CA issues sha256WithRSAEncryption (Russ
Housley, AD Review)
* 5.1 - added reference for base64 (RFC3548) (Russ Housley, AD
Review)
* s/[3]/[RFC 4306]/ (Russ Housley, AD Review)
* s/[10]/[RFC 4301]/ (Russ Housley, AD Review)
* s/[13]/[RFC 3779]/ (Russ Housley, AD Review)
* Moved CHANGE HISTORY to the end of the document (Russ Housley,
AD Review)
* 3.3.7 - point out strange case has been known to occur due to
bugs (March 26, 2006 pki4ipsec from Pekka Savola)
* 3.1.2/3.1.3 - make the example clearer that DNSSEC must be used
for the dereference (March 26, 2006 pki4ipsec from Pekka
Savola)
* 3.2.5 - point out that going to IKE doc is for discussion of
HTTP_CERT_LOOKUP_SUPPORTED (March 26, 2006 pki4ipsec from Pekka
Savola)
* 3.1 - added GN type to table (MUST NOT) (March 26, 2006
pki4ipsec from Pekka Savola)
* 3.1 - reordered table to match section order (March 26, 2006
pki4ipsec from Pekka Savola)
* Fixed HTTP_LOOKUP_SUPPORTED to be HTTP_CERT_LOOKUP_SUPPORTED
(March 26, 2006 pki4ipsec from Pekka Savola)
February 2006 (-09) February 2006 (-09)
* 3.2.6/3.3.6 - clarified text, that it applies to Main Mode only * 3.2.6/3.3.6 - clarified text, that it applies to Main Mode only
(text was updated in -08 3.3.6, not 3.2.6, but needed to be (text was updated in -08 3.3.6, not 3.2.6, but needed to be
fixed in both places) but not here) fixed in both places) but not here)
* Moved text from security considerations regarding SHA-256 * Moved text from security considerations regarding SHA-256
February 2006 (-08) February 2006 (-08)
skipping to change at page 38, line 38 skipping to change at page 43, line 4
* 3.2.6 - clarified text, that it applies to Main Mode only * 3.2.6 - clarified text, that it applies to Main Mode only
* Added text to security considerations regarding SHA-256 (30 Jan * Added text to security considerations regarding SHA-256 (30 Jan
2005 pki4ipsec email from Paul Hoffman) 2005 pki4ipsec email from Paul Hoffman)
November 2005 (-07) November 2005 (-07)
* 3.1 - renumbered table notes to avoid confusion with references * 3.1 - renumbered table notes to avoid confusion with references
(9 Nov 2005 pki4ipsec email from Jim Schaad) (9 Nov 2005 pki4ipsec email from Jim Schaad)
* 3.2.2 - changed "signing certificate" to "a certificate used * 3.2.2 - changed "signing certificate" to "a certificate used
for signing" (9 Nov 2005 pki4ipsec email from Jim Schaad) for signing" (9 Nov 2005 pki4ipsec email from Jim Schaad)
* 4.1 - added text re: implications of disabling checks ("escape * 4.1 - added text re: implications of disabling checks ("escape
clause") (8 Nov 2005 pki4ipsec email from Bill Sommerfeld, 10 clause") (8 Nov 2005 pki4ipsec email from Bill Sommerfeld, 10
Nov 2005 pki4ipsec email from Gregory M Lebovitz) Nov 2005 pki4ipsec email from Gregory M Lebovitz)
* 4.1.3.2 - removed text from pseudocode: "If told (by * 4.1.3.2 - removed text from pseudocode: "If told (by
configuration) to ignore KeyUsage (KU), accept cert regardless configuration) to ignore KeyUsage (KU), accept certificate
of its markings." regardless of its markings."
* 4.1.3.12 - replaced text with clearer text (8 Nov 2005 * 4.1.3.12 - replaced text with clearer text (8 Nov 2005
pki4ipsec email from Bill Sommerfeld) pki4ipsec email from Bill Sommerfeld)
* 4.1.3.12 - removed text from pseudocode: "If told (by * 4.1.3.12 - removed text from pseudocode: "If told (by
configuration) to ignore ExtendedKeyUsage (EKU), accept cert configuration) to ignore ExtendedKeyUsage (EKU), accept cert
regardless of the presence or absence of the extension." regardless of the presence or absence of the extension."
* 4.1.3.17 - removed gratuitous "private" modifier from * 4.1.3.17 - removed gratuitous "private" modifier from
SubjectInfoAccess section (9 Nov 2005 pki4ipsec email from Jim SubjectInfoAccess section (9 Nov 2005 pki4ipsec email from Jim
Schaad) Schaad)
* 4.2.2.4.2 - clarified delta CRL text so that it no longer could * 4.2.2.4.2 - clarified delta CRL text so that it no longer could
be read as implying that full CRLs can't be issued at the time be read as implying that full CRLs can't be issued at the time
a certificate is revoked. (9 Nov 2005 pki4ipsec email from Jim a certificate is revoked. (9 Nov 2005 pki4ipsec email from Jim
Schaad) Schaad)
* Security Considerations - added "Disabling Certificate Checks" * Security Considerations - added "Disabling Certificate Checks"
section section
October 2005 (-06) October 2005 (-06)
* 4.1.3.12 - added text re: id-kp-ipsecIKE * 4.1.3.12 - added text re: id-kp-ipsecIKE
July 2005 (-05) July 2005 (-05)
* 3.1 - added "See 2401bis [10], section 4.4.3.2 for more * 3.1 - added "See 2401bis, section 4.4.3.2 for more details." to
details." to resolve issue #561. resolve issue #561.
* 3.1.10 - added text pointing to PAD in 2401bis [10] to * 3.1.10 - added text pointing to PAD in 2401bis to discussion of
discussion of binding identity to policy. binding identity to policy.
December 2004 (-04) 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)
skipping to change at page 46, line 4 skipping to change at page 50, line 15
February 2003 (-02) February 2003 (-02)
* Word choice: move from use of "root" to "trust anchor", in * Word choice: move from use of "root" to "trust anchor", in
accordance with PKIX accordance with PKIX
* SBGP note and reference for placing address subnet and range * SBGP note and reference for placing address subnet and range
information into certificates information into certificates
* Clarification of text regarding placing names of hosts into the * Clarification of text regarding placing names of hosts into the
Name commonName attribute of SubjectName Name commonName attribute of SubjectName
* Added table to clarify text regarding processing of the * Added table to clarify text regarding processing of the
certificate extension criticality bit certificate extension criticality bit
* Added text underscoring processing requirements for * Added text underscoring processing requirements for
CRLDistributionPoints and IssuingDistributionPoint CRLDistributionPoints and IssuingDistributionPoint
October 2002, Reorganization (-01) October 2002, Reorganization (-01)
June 2002, Initial Draft (-00) June 2002, Initial Draft (-00)
Appendix B. The Possible Dangers of Delta CRLs
The problem is that the CRL processing algorithm is sometimes written
incorrectly with the assumption that all CRLs are base CRLs and it is
assumed that CRLs will pass content validity tests. Specifically,
such implementations fail to check the certificate against all
possible CRLs: if the first CRL that is obtained from the keying
material database fails to decode, no further revocation checks are
performed for the relevant certificate. This problem is compounded
by the fact that implementations which do not understand delta CRLs
may fail to decode such CRLs due to the critical DeltaCRLIndicator
extension. The algorithm that is implemented in this case is
approximately:
o fetch newest CRL
o check validity of CRL signature
o if CRL signature is valid then
o if CRL does not contain unrecognized critical extensions
o and certificate is on CRL then
o set certificate status to revoked
The authors note that a number of PKI toolkits do not even provide a
method for obtaining anything but the newest CRL, which in the
presence of delta CRLs may in fact be a delta CRL, not a base CRL.
Note that the above algorithm is dangerous in many ways. See PKIX
[5] for the correct algorithm.
Appendix C. More on Empty CERTREQs
Sending empty certificate requests is commonly used in
implementations, and in the IPsec interop meetings, vendors have
generally agreed that it means that send all/any end-entity
certificates you have (if multiple end-entity certificates are sent,
they must have same public key, as otherwise the other end does not
know which key was used). For 99% of cases the client have exactly
one certificate and public key, so it really doesn't matter, but the
server might have multiple, thus it simply needs to say to the
client, use any certificate you have. If we are talking about
corporate vpns etc, even if the client have multiple certificates or
keys, all of them would be usable when authenticating to the server,
so client can simply pick one.
If there is some real difference on which cert to use (like ones
giving different permissions), then the client must be configured
anyways, or it might even ask the user which one to use (the user is
the only one who knows whether he needs admin privileges, thus needs
to use admin cert, or is the normal email privileges ok, thus using
email only cert).
99% of the cases the client have exactly one certificate, so it will
send it. In 90% of the rest of the cases, any of the certificates is
ok, as they are simply different certificates from same CA, or
different CAs for the same corporate VPN, thus any of them is ok.
Sending empty certificate requests has been agreed there to mean
"give me your cert; any cert".
Justification:
o Responder first does all it can to send a certreq with a CA, check
for IP match in SPD, have a default set of CAs to use in ambiguous
cases, etc.
o sending empty certreq's is fairly common in implementations today,
and is generally accepted to mean "send me a cert, any cert that
works for you"
o saves responder sending potentially 100's of certs, the
fragmentation problems that follow, etc.
o in +90% of use cases, Initiators have exactly 1 cert
o in +90% of the remaining use cases, the multiple certs it has are
issued by the same CA
o in the remaining use case(s) -- if not all the others above -- the
Initiator will be configured explicitly with which cert to send,
so responding to an empty certreq is easy.
The following example shows why initiators need to have sufficient
policy definition to know which certificate to use for a given
connection it initiates.
EXAMPLE: Your client (initiator) is configured with VPN policies for
gateways A and B (representing perhaps corporate partners).
The policies for the two gateways look something like:
Acme Company policy (gateway A)
Engineering can access 10.1.1.0
Trusted CA: CA-A, Trusted Users: OU=Engineering
Partners can access 20.1.1.0
Trusted CA: CA-B, Trusted Users: OU=AcmePartners
Bizco Company policy (gateway B)
sales can access 30.1.1.0
Trusted CA: CA-C, Trusted Users: OU=Sales
Partners can access 40.1.1.0
Trusted CA: CA-B, Trusted Users: OU=BizcoPartners
You are an employee of Acme and you are issued the following
certificates:
o From CA-A: CN=JoeUser,OU=Engineering
o From CA-B: CN=JoePartner,OU=BizcoPartners
The client MUST be configured locally to know which CA to use when
connecting to either gateway. If your client is not configured to
know the local credential to use for the remote gateway, this
scenario will not work either. If you attempt to connect to Bizco,
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
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.
As the initiator, you will be presented with certificate requests
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
know which certificate it should present? It must have sufficiently
clear local policy specifying which one credential to present for the
connection it initiates.
Appendix D. Acknowledgements
The authors would like to acknowledge the expired draft-ietf-ipsec-
pki-req-05.txt for providing valuable materials for this document.
The authors would like to especially thank Eric Rescorla, one of its
original authors, in addition to Greg Carter, Steve Hanna, Russ
Housley, Charlie Kaufman, Tero Kivinen, and Gregory Lebovitz for
their valuable comments, some of which have been incorporated
verbatim into this document. Paul Knight performed the arduous tasks
of coverting the text to XML format.
Author's Address Author's Address
Brian Korver Brian Korver
Network Resonance, Inc. Network Resonance, Inc.
2483 E. Bayshore Rd. 2483 E. Bayshore Rd.
Palo Alto, CA 94303 Palo Alto, CA 94303
US US
Phone: +1 650 812 7705 Phone: +1 650 812 7705
Email: briank@networkresonance.com Email: briank@networkresonance.com
 End of changes. 125 change blocks. 
454 lines changed or deleted 523 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/