< draft-ietf-pki4ipsec-ikecert-profile-11.txt   draft-ietf-pki4ipsec-ikecert-profile-12.txt >
pki4ipsec B. Korver pki4ipsec B. Korver
Internet-Draft Network Resonance, Inc. Internet-Draft Network Resonance, Inc.
Intended status: Informational September 25, 2006 Expires: August 25, 2007 February 21, 2007
Expires: March 29, 2007
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-11 draft-ietf-pki4ipsec-ikecert-profile-12
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 34 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 March 29, 2007. This Internet-Draft will expire on August 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
IKE and PKIX certificate profile both provide frameworks that must be IKE and PKIX certificate profile both provide frameworks that must be
profiled for use in a given application. This document provides a profiled for use in a given application. This document provides a
profile of IKE and PKIX that defines the requirements for using PKI profile of IKE and PKIX that defines the requirements for using PKI
technology in the context of IKE/IPsec. The document complements technology in the context of IKE/IPsec. The document complements
protocol specifications such as IKEv1 and IKEv2, which assume the protocol specifications such as IKEv1 and IKEv2, which assume the
existence of public key certificates and related keying materials, existence of public key certificates and related keying materials,
but which do not address PKI issues explicitly. This document but which do not address PKI issues explicitly. This document
addresses those issues. The intended audience is implementors of PKI addresses those issues. The intended audience is implementors of PKI
for IPsec. for IPsec.
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. Use of Certificates in RFC 2401 and IKEv1/ISAKMP . . . . . . . 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 . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . 11
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. Subject 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 . . . . . . . . . . . . . . . 13 3.2. Certificate Request Payload . . . . . . . . . . . . . . . 13
3.2.1. Certificate Type . . . . . . . . . . . . . . . . . . . 14 3.2.1. Certificate Type . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . 14
3.2.5. IKEv2's Hash and URL of X.509 certificate . . . . . . 15 3.2.5. Location of Certificate Request Payloads . . . . . . . 15
3.2.6. Location of Certificate Payloads . . . . . . . . . . . 15 3.2.6. Presence or Absence of Certificate Request Payloads . 15
3.2.7. Presence or Absence of Certificate Request Payloads . 16 3.2.7. Certificate Requests . . . . . . . . . . . . . . . . . 15
3.2.8. Certificate Requests . . . . . . . . . . . . . . . . . 16 3.2.8. Robustness . . . . . . . . . . . . . . . . . . . . . . 17
3.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 18 3.2.9. Optimizations . . . . . . . . . . . . . . . . . . . . 17
3.2.10. Optimizations . . . . . . . . . . . . . . . . . . . . 18 3.3. Certificate Payload . . . . . . . . . . . . . . . . . . . 19
3.3. Certificate Payload . . . . . . . . . . . . . . . . . . . 20 3.3.1. Certificate Type . . . . . . . . . . . . . . . . . . . 19
3.3.1. Certificate Type . . . . . . . . . . . . . . . . . . . 20 3.3.2. X.509 Certificate - Signature . . . . . . . . . . . . 20
3.3.2. X.509 Certificate - Signature . . . . . . . . . . . . 21 3.3.3. Revocation Lists (CRL and ARL) . . . . . . . . . . . . 20
3.3.3. Revocation Lists (CRL and ARL) . . . . . . . . . . . . 21 3.3.4. PKCS #7 wrapped X.509 certificate . . . . . . . . . . 20
3.3.4. IKEv2's Hash and URL of X.509 Certificate . . . . . . 21 3.3.5. Location of Certificate Payloads . . . . . . . . . . . 20
3.3.5. PKCS #7 wrapped X.509 certificate . . . . . . . . . . 21 3.3.6. Certificate Payloads Not Mandatory . . . . . . . . . . 20
3.3.6. Location of Certificate Payloads . . . . . . . . . . . 22 3.3.7. Response to Multiple Certification Authority
3.3.7. Certificate Payloads Not Mandatory . . . . . . . . . . 22 Proposals . . . . . . . . . . . . . . . . . . . . . . 21
3.3.8. Response to Multiple Certification Authority 3.3.8. Using Local Keying Materials . . . . . . . . . . . . . 21
Proposals . . . . . . . . . . . . . . . . . . . . . . 22 3.3.9. Multiple End-Entity Certificates . . . . . . . . . . . 21
3.3.9. Using Local Keying Materials . . . . . . . . . . . . . 22 3.3.10. Robustness . . . . . . . . . . . . . . . . . . . . . . 21
3.3.10. Multiple End-Entity Certificates . . . . . . . . . . . 23 3.3.11. Optimizations . . . . . . . . . . . . . . . . . . . . 22
3.3.11. Robustness . . . . . . . . . . . . . . . . . . . . . . 23 4. Use of Certificates in RFC4301 and IKEv2 . . . . . . . . . . . 23
3.3.12. Optimizations . . . . . . . . . . . . . . . . . . . . 24 4.1. Identification Payload . . . . . . . . . . . . . . . . . . 23
4. Certificate Profile . . . . . . . . . . . . . . . . . . . . . 25 4.2. Certificate Request Payload . . . . . . . . . . . . . . . 23
4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 25 4.2.1. Revocation Lists (CRL and ARL) . . . . . . . . . . . . 23
4.1.1. Versions . . . . . . . . . . . . . . . . . . . . . . . 25 4.3. Certificate Payload . . . . . . . . . . . . . . . . . . . 24
4.1.2. Subject . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.1. IKEv2's Hash and URL of X.509 Certificate . . . . . . 24
4.1.3. X.509 Certificate Extensions . . . . . . . . . . . . . 26 4.3.2. Location of Certificate Payloads . . . . . . . . . . . 25
4.2. X.509 Certificate Revocation Lists . . . . . . . . . . . . 32 4.3.3. Ordering of Certificate Payloads . . . . . . . . . . . 25
4.2.1. Multiple Sources of Certificate Revocation
5. Certificate Profile for IKEv1/ISAKMP and IKEv2 . . . . . . . . 25
5.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 25
5.1.1. Versions . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.2. Subject . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.3. X.509 Certificate Extensions . . . . . . . . . . . . . 26
5.2. X.509 Certificate Revocation Lists . . . . . . . . . . . . 32
5.2.1. Multiple Sources of Certificate Revocation
Information . . . . . . . . . . . . . . . . . . . . . 32 Information . . . . . . . . . . . . . . . . . . . . . 32
4.2.2. X.509 Certificate Revocation List Extensions . . . . . 32 5.2.2. X.509 Certificate Revocation List Extensions . . . . . 33
4.3. Strength of Signature Hashing Algorithms . . . . . . . . . 34 5.3. Strength of Signature Hashing Algorithms . . . . . . . . . 34
5. Configuration Data Exchange Conventions . . . . . . . . . . . 35 6. Configuration Data Exchange Conventions . . . . . . . . . . . 35
5.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 35 6.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 35
5.2. CRLs and ARLs . . . . . . . . . . . . . . . . . . . . . . 35 6.2. CRLs and ARLs . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 35 6.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 36
5.4. PKCS#10 Certificate Signing Requests . . . . . . . . . . . 35 6.4. PKCS#10 Certificate Signing Requests . . . . . . . . . . . 36
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
7.1. Certificate Request Payload . . . . . . . . . . . . . . . 36 8.1. Certificate Request Payload . . . . . . . . . . . . . . . 36
7.2. IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 36 8.2. IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 36
7.3. Disabling Certificate Checks . . . . . . . . . . . . . . . 36 8.3. Disabling Certificate Checks . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . . 37 10.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. The Possible Dangers of Delta CRLs . . . . . . . . . 38 Appendix A. The Possible Dangers of Delta CRLs . . . . . . . . . 38
Appendix B. More on Empty CERTREQs . . . . . . . . . . . . . . . 39 Appendix B. More on Empty CERTREQs . . . . . . . . . . . . . . . 39
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 40 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 51 Intellectual Property and Copyright Statements . . . . . . . . . . 52
1. Introduction 1. Introduction
IKE [1], ISAKMP [2] and IKEv2 [3] provide a secure key exchange IKE [1], ISAKMP [2] and IKEv2 [3] provide a secure key exchange
mechanism for use with IPsec [4]. In many cases the peers mechanism for use with IPsec [4]. In many cases the peers
authenticate using digital certificates as specified in PKIX [5]. authenticate using digital certificates as specified in PKIX [5].
Unfortunately, the combination of these standards leads to an Unfortunately, the combination of these standards leads to an
underspecified set of requirements for the use of certificates in the underspecified set of requirements for the use of certificates in the
context of IPsec. context of IPsec.
skipping to change at page 4, line 42 skipping to change at page 4, line 42
both implementation and deployment, as well as the current state of both implementation and deployment, as well as the current state of
related protocols and technologies. related protocols and technologies.
Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and
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, Section 4 provides a profile of IKEv2, and
of PKIX. Section 5 covers conventions for the out-of-band exchange Section 5 provides the profile of PKIX. Section 6 covers conventions
of keying materials for configuration purposes. for the out-of-band exchange of keying materials for configuration
purposes.
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.
o ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both o ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both
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. Use of Certificates in RFC 2401 and IKEv1/ISAKMP
3.1. Identification Payload 3.1. Identification Payload
The Identification (ID) Payload indicates the identity claimed by the The Identification (ID) Payload indicates the identity claimed by the
sender. The recipient can then use the ID as a lookup key for policy sender. The recipient can then use the ID as a lookup key for policy
and for certificate lookup in whatever certificate store or directory and for certificate lookup in whatever certificate store or directory
that it has available. Our primary concern in this section is to that it has available. Our primary concern in this section is to
profile the ID payload so that it can be safely used to generate or profile the ID payload so that it can be safely used to generate or
lookup policy. IKE mandates the use of the ID payload in Phase 1. lookup policy. IKE mandates the use of the ID payload in Phase 1.
skipping to change at page 5, line 39 skipping to change at page 5, line 39
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
they are out of the scope of this document. they are out of the scope of this document.
Implementations SHOULD populate ID with identity information that is Implementations SHOULD populate ID with identity information that is
contained within the end-entity certificate (This SHOULD does not contained within the end-entity certificate. Populating ID with
contradict text in IKEv2 [3] Section 3.5 that implies a looser identity information from the end-entity certificate enables
binding between these two). Populating ID with identity information recipients to use ID as a lookup key to find the peer end-entity
from the end-entity certificate enables recipients to use ID as a certificate. The only case where implementations may populate ID
lookup key to find the peer end-entity certificate. The only case with information that is not contained in the end-entity certificate
where implementations may populate ID with information that is not is when ID contains the peer source address (a single address, not a
contained in the end-entity certificate is when ID contains the peer subnet or range).
source address (a single address, not a subnet or range).
Because implementations may use ID as a lookup key to determine which Because implementations may use ID as a lookup key to determine which
policy to use, all implementations MUST be especially careful to policy to use, all implementations MUST be especially careful to
verify the truthfulness of the contents by verifying that they verify the truthfulness of the contents by verifying that they
correspond to some keying material demonstrably held by the peer. correspond to some keying material demonstrably held by the peer.
Failure to do so may result in the use of an inappropriate or Failure to do so may result in the use of an inappropriate or
insecure policy. The following sections describe the methods for insecure policy. The following sections describe the methods for
performing this binding. performing this binding.
The following table summarizes the binding of the Identification The following table summarizes the binding of the Identification
Payload to the contents of end-entity certificates and of identity Payload to the contents of end-entity certificates and of identity
information to policy. Each ID type is covered more thoroughly in information to policy. Each ID type is covered more thoroughly in
the following sections. the following sections.
ID type | Support | Correspond | Cert | SPD lookup ID type | Support | Correspond | Cert | SPD lookup
skipping to change at page 6, line 46 skipping to change at page 6, line 44
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 RFC 4301 [10], section 4.4.3.2 for required to be used for this.
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,
skipping to change at page 7, line 31 skipping to change at page 7, line 29
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
configuration to do the SPD matching against the ID contents. In configuration to do the SPD matching against the ID contents. In
other words, implementations MUST be able to do exact matches of ID other words, implementations MUST be able to do exact matches of ID
to SPD, but MAY also be configurable to do substring or wildcard to SPD, but MAY also be configurable to do substring or wildcard
matches of ID to SPD. matches of ID to SPD.
IKEv2 adds an optional IDr payload in the second exchange that the
initiator may send to the responder in order to specify which of the
responder's multiple identities should be used. The responder MAY
choose to send an IDr in the 3rd exchange that differs in type or
content from the initiator-generated IDr. The initiator MUST be able
to receive a responder-generated IDr that is a different type from
the one the initiator generated.
3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR 3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR
Implementations MUST support at least the ID_IPV4_ADDR or Implementations MUST support at least the ID_IPV4_ADDR or
ID_IPV6_ADDR ID type, depending on whether the implementation ID_IPV6_ADDR ID type, depending on whether the implementation
supports IPv4, IPv6 or both. These addresses MUST be encoded in supports IPv4, IPv6 or both. These addresses MUST be encoded in
"network byte order," as specified in IP [8]: The least significant "network byte order," as specified in IP [8]: The least significant
bit (LSB) of each octet is the LSB of the corresponding byte in the bit (LSB) of each octet is the LSB of the corresponding byte in the
network address. For the ID_IPV4_ADDR type, the payload MUST contain network address. For the ID_IPV4_ADDR type, the payload MUST contain
exactly four octets [8]. For the ID_IPV6_ADDR type, the payload MUST exactly four octets [8]. For the ID_IPV6_ADDR type, the payload MUST
contain exactly sixteen octets [11]. contain exactly sixteen octets [10].
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
all of 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
skipping to change at page 9, line 42 skipping to change at page 9, line 35
address, but until the identity (address) is validated by validating address, but until the identity (address) is validated by validating
the peer certificate, the policy MUST NOT be used to authorize any the peer certificate, the policy MUST NOT be used to authorize any
IPsec traffic. IPsec traffic.
3.1.2. ID_FQDN 3.1.2. ID_FQDN
Implementations MUST support the ID_FQDN ID type, generally to Implementations MUST support the ID_FQDN ID type, generally to
support host-based access control lists for hosts without fixed IP support host-based access control lists for hosts without fixed IP
addresses. However, implementations SHOULD NOT use the DNS to map addresses. However, implementations SHOULD NOT use the DNS to map
the FQDN to IP addresses for input into any policy decisions, unless the FQDN to IP addresses for input into any policy decisions, unless
that mapping is known to be secure, for example if DNSSEC [12] were that mapping is known to be secure, for example if DNSSEC [11] were
employed for that FQDN. 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, case-insensitive string comparison MUST be performed. for equality, case-insensitive string comparison MUST be performed.
Note that case-insensitive string comparison works on Note that case-insensitive string comparison works on
internationalized domain names (IDNs) as well (See IDN [13]). internationalized domain names (IDNs) as well (See IDN [12]).
Substring, wildcard, or regular expression matching MUST NOT be Substring, wildcard, or regular expression matching MUST NOT be
performed for this comparison. If this default is enabled, then a performed for this comparison. If this default is enabled, then a
mismatch MUST be treated as an error and security association setup mismatch MUST be treated as an error and security association setup
MUST be aborted. This event SHOULD be auditable. Implementations MUST be aborted. This event SHOULD be auditable. Implementations
MAY provide a configuration option to (i.e. local policy MAY provide a configuration option to (i.e. local policy
configuration can enable) skip that verification step, but that configuration can enable) skip that verification step, but that
option MUST be off by default. We include the "option-to-skip- option MUST be off by default. We include the "option-to-skip-
validation" in order to permit better interoperability, as today validation" in order to permit better interoperability, as today
implementations vary greatly in how they behave on this topic. implementations vary greatly in how they behave on this topic.
skipping to change at page 10, line 28 skipping to change at page 10, line 19
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 [11]
were employed for that FQDN. 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, case- rfc822Name field in the SubjectAltName extension for equality, case-
insensitive string comparison MUST be performed. Note that case- insensitive string comparison MUST be performed. Note that case-
insensitive string comparison works on internationalized domain names insensitive string comparison works on internationalized domain names
(IDNs) as well (See IDN [13]). Substring, wildcard, or regular (IDNs) as well (See IDN [12]). Substring, wildcard, or regular
expression matching MUST NOT be performed for this comparison. If expression matching MUST NOT be performed for this comparison. If
this default is enabled, then a mismatch MUST be treated as an error this default is enabled, then a mismatch MUST be treated as an error
and security association setup MUST be aborted. This event SHOULD be and security association setup MUST be aborted. This event SHOULD be
auditable. Implementations MAY provide a configuration option to auditable. Implementations MAY provide a configuration option to
(i.e. local policy configuration can enable) skip that verification (i.e. local policy configuration can enable) skip that verification
step, but that option MUST be off by default. We include the step, but that option MUST be off by default. We include the
"option-to-skip-validation" in order to permit better "option-to-skip-validation" in order to permit better
interoperability, as today implementations vary greatly in how they interoperability, as today implementations vary greatly in how they
behave on this topic. behave on this topic.
Implementations MAY support substring, wildcard, or regular Implementations MAY support substring, wildcard, or regular
expression matching of the contents of ID to lookup policy in the expression matching of the contents of ID to lookup policy in the
SPD, and such would be a matter of local security policy SPD, and such would be a matter of local security policy
configuration. configuration.
3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, 3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE,
ID_IPV6_ADDR_RANGE ID_IPV6_ADDR_RANGE
Note that RFC 3779 [14] defines blocks of addresses using the Note that RFC 3779 [13] defines blocks of addresses using the
certificate extension identified by: certificate extension identified by:
id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
although use of this extension in IKE is considered experimental at although use of this extension in IKE is considered experimental at
this time. 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 Subject field from the end- populate the contents of ID with the Subject field from the end-
entity certificate, and MUST do so such that a binary comparison of entity certificate, and MUST do so such that a binary comparison of
the two will succeed. If there is not a match, this MUST be treated the two will succeed. If there is not a match, this MUST be treated
as an error and security association setup MUST be aborted. This as an error and security association setup MUST be aborted. This
event SHOULD be auditable. Note, if the certificate was erroneously event SHOULD be auditable.
created such that the encoding of the Subject DN varies from the
constraints set by DER, that non-conformant DN MUST be used to
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
in the certificate as DER.
Implementations MUST NOT populate ID with the Subject from the end- Implementations MUST NOT populate ID with the Subject from the end-
entity certificate if it is empty, even though an empty certificate entity certificate if it is empty, even though an empty certificate
Subject is explicitly allowed in the "Subject" section of the PKIX Subject is explicitly allowed in the "Subject" section of the PKIX
certificate profile. 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
skipping to change at page 13, line 40 skipping to change at page 13, line 26
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 Subject field, a dNSName and say the certificate contains non-empty Subject field, a dNSName and
an 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 Subject 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 RFC 4301 [10]
provides a more formal model for the binding of identity to policy in
addition to providing services that deal more specifically with the
details of policy enforcement, which are generally out of scope of
this document. The PAD is intended to provide a link between the SPD
and the security association management in protocols such as IKE.
See 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 (CRLs). It is not clear from ISAKMP exactly how revocation lists (CRLs). It is not clear from ISAKMP exactly how
that set should be specified or how the peer should respond. We that set should be specified or how the peer should respond. We
describe the 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. For the purposes of this document, only the
the purposes of this document, only the following types are relevant: 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
The use of the other types are out of the scope of this document: 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 Hash and URL of X.509 bundle
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 does not support Certificate Payload sizes over approximately
approximately 64K, which is too small for many CRLs, and UDP 64K, which is too small for many CRLs, and UDP fragmentation is
fragmentation is likely to occur at sizes much smaller than that. likely to occur at sizes much smaller than that. Therefore, the
Therefore, the acquisition of revocation material is to be dealt with acquisition of revocation material is to be dealt with out-of-band of
out-of-band of IKE. For this and other reasons, implementations IKE. For this and other reasons, implementations SHOULD NOT generate
SHOULD NOT generate CERTREQs where the Certificate Type is CERTREQs where the Certificate Type is "Certificate Revocation List
"Certificate Revocation List (CRL)" or "Authority Revocation List (CRL)" or "Authority Revocation List (ARL)". Implementations that do
(ARL)". Implementations that do generate such CERTREQs MUST NOT generate such CERTREQs MUST NOT require the recipient to respond with
require the recipient to respond with a CRL or ARL, and MUST NOT fail a CRL or ARL, and MUST NOT fail when not receiving any. Upon receipt
when not receiving any. Upon receipt of such a CERTREQ, of such a CERTREQ, implementations MAY ignore the request.
implementations MAY ignore the request.
In lieu of exchanging revocation lists in-band, a pointer to In lieu of exchanging revocation lists in-band, a pointer to
revocation checking SHOULD be listed in either the revocation checking SHOULD be listed in either the
CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA) CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA)
certificate extensions (see Section 4 for details). Unless other certificate extensions (see Section 5 for details). Unless other
methods for obtaining revocation information are available, methods for obtaining revocation information are available,
implementations SHOULD be able to process these attributes, and from implementations SHOULD be able to process these attributes, and from
them be able to identify cached revocation material, or retrieve the them be able to identify cached revocation material, or retrieve the
relevant revocation material from a URL, for validation processing. relevant revocation material from a URL, for validation processing.
In addition, implementations MUST have the ability to configure In addition, implementations MUST have the ability to configure
validation checking information for each certification authority. validation checking information for each certification authority.
Regardless of the method (CDP, AIA, or static configuration), the Regardless of the method (CDP, AIA, or static configuration), the
acquisition of revocation material SHOULD occur out-of-band of IKE. acquisition of revocation material SHOULD occur out-of-band of IKE.
Note, however, that an inability to access revocation status data
through out-of-band means provides a potential security vulnerability
that could potentially be exploited by an attacker.
3.2.4. PKCS #7 wrapped X.509 certificate 3.2.4. PKCS #7 wrapped X.509 certificate
This ID type defines a particular encoding (not a particular This ID type defines a particular encoding (not a particular
certificate type), some current implementations may ignore CERTREQs certificate type), some current implementations may ignore CERTREQs
they receive which contain this ID type, and the editors are unaware they receive which contain this ID type, and the editors are unaware
of any implementations that generate such CERTREQ messages. of any implementations that generate such CERTREQ messages.
Therefore, the use of this type is deprecated. Implementations Therefore, the use of this type is deprecated. Implementations
SHOULD NOT require CERTREQs that contain this Certificate Type. SHOULD NOT require CERTREQs that contain this Certificate Type.
Implementations which receive CERTREQs which contain this ID type MAY Implementations which receive CERTREQs which contain this ID type MAY
treat such payloads as synonymous with "X.509 Certificate - treat such payloads as synonymous with "X.509 Certificate -
Signature". Signature".
3.2.5. IKEv2's Hash and URL of X.509 certificate 3.2.5. Location of Certificate Request Payloads
This ID type defines a request for the peer to send a hash and URL of
its X.509 certificate, instead of the actual certificate itself.
This is a particularly useful mechanism when the peer is a device
with little memory and lower bandwidth, e.g. a mobile handset or
consumer electronics device.
If the IKEv2 implementation supports URL lookups, and prefers such a
URL to receiving actual certificates, then the implementation will
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
message that can include a CERTREQ payload and indicates that the
sender is capable of looking up certificates based on an HTTP-based
URL (and hence presumably would prefer to receive certificate
specifications in that format)." If an HTTP_CERT_LOOKUP_SUPPORTED
notification is sent the sender MUST support the http scheme. See
Section 3.3.4 for more discussion of HTTP_CERT_LOOKUP_SUPPORTED.
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, it is possible to have one side authenticating with
certificates while the other side authenticates with preshared keys.
3.2.7. Presence or Absence of Certificate Request Payloads 3.2.6. Presence or Absence of Certificate Request Payloads
When in-band exchange of certificate keying materials is desired, When in-band exchange of certificate keying materials is desired,
implementations MUST inform the peer of this by sending at least one implementations MUST inform the peer of this by sending at least one
CERTREQ. In other words, an implementation which does not send any CERTREQ. In other words, an implementation which does not send any
CERTREQs during an exchange SHOULD NOT expect to receive any CERT CERTREQs during an exchange SHOULD NOT expect to receive any CERT
payloads. payloads.
3.2.8. Certificate Requests 3.2.7. Certificate Requests
3.2.8.1. Specifying Certification Authorities 3.2.7.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.
implementations SHOULD populate the Certification Authority field Implementations SHOULD populate the Certification Authority field
with the Subject field of the trust anchor, populated such that with the Subject field of the trust anchor, populated such that
binary comparison of the Subject and the Certification Authority will binary comparison of the Subject and the Certification Authority will
succeed. For IKEv2, implementations MUST populate the Certification succeed.
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).
Note, in the case where multiple end-entity certificates may be Note, in the case where multiple end-entity certificates may be
available which chain to different trust anchors, implementations available which chain to different trust anchors, implementations
SHOULD resort to local heuristics to determine which trust anchor is SHOULD resort to local heuristics to determine which trust anchor is
most appropriate to use for generating the CERTREQ. Such heuristics most appropriate to use for generating the CERTREQ. Such heuristics
are out of the scope of this document. are out of the scope of this document.
3.2.8.2. Empty Certification Authority Field 3.2.7.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 an empty conditions. Although PKIX prohibits certificates with an empty
Issuer field, 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
skipping to change at page 18, line 20 skipping to change at page 17, line 25
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 B). Empty CERTREQs" (Appendix B).
3.2.9. Robustness 3.2.8. Robustness
3.2.9.1. Unrecognized or Unsupported Certificate Types 3.2.8.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
Request Payload Processing" specifies additional processing. Request Payload Processing" specifies additional processing.
3.2.9.2. Undecodable Certification Authority Fields 3.2.8.2. Undecodable Certification Authority Fields
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.8.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.9. Optimizations
3.2.9.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.9.2. Name Lowest 'Common' Certification Authorities
When a peer's certificate keying material has 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 include in the response. In certificates the peer would normally include in the response. In
addition to the normal set of CERTREQs that are sent specifying the addition to the normal set of CERTREQs that are sent specifying the
trust anchors, an implementation MAY send CERTREQs specifying the trust anchors, an implementation MAY send CERTREQs specifying the
relevant cached end-entity certificates. When sending these hints, relevant cached end-entity certificates. When sending these hints,
it is 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
skipping to change at page 19, line 38 skipping to change at page 18, line 42
certificate allows implementations to determine unambiguously when a certificate allows implementations to determine unambiguously when a
new certificate is being used by a peer (perhaps because the previous new certificate is being used by a peer (perhaps because the previous
certificate has just expired), which may result in a failure because certificate has just expired), which may result in a failure because
a new intermediate CA certificate might not be available to validate a new intermediate CA certificate might not be available to validate
the new end-entity certificate). Implementations which implement the new end-entity certificate). Implementations which implement
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.9.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 Subject field in certificate TA, this implementation is the Subject field in certificate TA, this implementation is
requesting that the peer send at least 3 certificates: CA1, CA2, and requesting that the peer send at least 3 certificates: CA1, CA2, and
EE. On the other hand, if this implementation also sends a CERTREQ EE. On the other hand, if this implementation also sends a CERTREQ
containing the Subject field of CA2, the implementation is providing containing the Subject field of CA2, the implementation is providing
a hint that only 1 certificate needs to be sent: EE. Note that in a hint that only 1 certificate needs to be sent: EE. Note that in
this example, the fact that TA is a trust anchor should not be this example, the fact that TA is a trust anchor should not be
skipping to change at page 20, line 31 skipping to change at page 19, line 33
certificate chain TA1->CA1->EE1 while the recipient has the certificate chain TA1->CA1->EE1 while the recipient has the
certificate chain TA2->EE2 where TA2=CA1. The sender is merely certificate chain TA2->EE2 where TA2=CA1. The sender is merely
including an intermediate CA certificate, while the recipient including an intermediate CA certificate, while the recipient
receives a trust anchor. receives a trust anchor.
However, not all certificate forms that are legal in the PKIX However, not all certificate forms that are legal in the PKIX
certificate profile make sense in the context of IPsec. The issue of certificate profile make sense in the context of IPsec. The issue of
how to represent IKE-meaningful name-forms in a certificate is how to represent IKE-meaningful name-forms in a certificate is
especially problematic. This document provides a profile for a especially problematic. This document provides a profile for a
subset of the PKIX certificate profile that makes sense for IKEv1/ subset of the PKIX certificate profile that makes sense for IKEv1/
ISAKMP and IKEv2. ISAKMP.
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. For the purposes of this document, only the
purposes of this document, only the following types are relevant: 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
The use of the other types are out of the scope of this document: 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 Hash and URL of X.509 bundle
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. PKCS #7 wrapped X.509 certificate
This type specifies that Certificate Data contains a hash and the URL
to a repository where an X.509 certificate can be retrieved.
An implementation that sends a HTTP_CERT_LOOKUP_SUPPORTED
notification MUST support the http scheme and MAY support the ftp
scheme, and MUST NOT require any specific form of the url-path and it
SHOULD support having user-name, password and port parts in the URL.
The following are examples of mandatory forms:
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/%0a/../foo/bar/zappa
while the following is an example of a form that SHOULD be supported:
o http://user:password@certs.example.com:8888/certificate.cer
FTP MAY be supported, and if it is the following is an example of the
ftp scheme that MUST be supported:
o ftp://ftp.example.com/pub/certificate.cer
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.5. 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.
IKEv2, the CERT payload MUST be in messages 3 and 4. Note that in
IKEv2, it is possible to have one side authenticating with
certificates while the other side authenticates with preshared keys.
3.3.7. Certificate Payloads Not Mandatory 3.3.6. 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.
skipping to change at page 22, line 38 skipping to change at page 21, line 11
SHOULD ignore any CERTREQ messages that are received. Such a SHOULD ignore any CERTREQ messages that are received. Such a
condition has been known to occur due to non-compliant or buggy condition has been known to occur due to non-compliant or buggy
implementations. implementations.
Implementations that receive CERTREQs from a peer which contain only Implementations that receive CERTREQs from a peer which contain only
unrecognized Certification Authorities MAY elect to terminate the unrecognized Certification Authorities MAY elect to terminate 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.7. 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.8. Using Local Keying Materials
Implementations MAY elect to skip parsing or otherwise decoding a Implementations MAY elect to skip parsing or otherwise decoding a
given set of CERTs if those same keying materials are available via given set of CERTs if those same keying materials are available via
some preferable means, such as the case where certificates from a some preferable means, such as the case where certificates from a
previous exchange have been cached. previous exchange have been cached.
3.3.10. Multiple End-Entity Certificates 3.3.9. Multiple End-Entity Certificates
Implementations SHOULD NOT send multiple end-entity certificates and Implementations SHOULD NOT send multiple end-entity certificates and
recipients SHOULD NOT be expected to iterate over multiple end-entity recipients SHOULD NOT be expected to iterate over multiple end-entity
certificates. certificates.
If multiple end-entity certificates are sent, they MUST have the same If multiple end-entity certificates are sent, they MUST have the same
public key, otherwise the responder does not know which key was used public key, otherwise the responder does not know which key was used
in the Main Mode message 5. in the Main Mode message 5.
3.3.11. Robustness 3.3.10. Robustness
3.3.11.1. Unrecognized or Unsupported Certificate Types 3.3.10.1. Unrecognized or Unsupported Certificate Types
Implementations MUST be able to deal with receiving CERTs with Implementations MUST be able to deal with receiving CERTs with
unrecognized or unsupported Certificate Types. Implementations MAY unrecognized or unsupported Certificate Types. Implementations MAY
discard such payloads, depending on local policy. ISAKMP [2] Section discard such payloads, depending on local policy. ISAKMP [2] Section
5.10 "Certificate Request Payload Processing" specifies additional 5.10 "Certificate Request Payload Processing" specifies additional
processing. processing.
3.3.11.2. Undecodable Certificate Data Fields 3.3.10.2. Undecodable Certificate Data Fields
Implementations MUST be able to deal with receiving CERTs with Implementations MUST be able to deal with receiving CERTs with
undecodable Certificate Data fields. Implementations MAY discard undecodable Certificate Data fields. Implementations MAY discard
such payloads, depending on local policy. ISAKMP specifies other such payloads, depending on local policy. ISAKMP specifies other
actions which may be taken. actions which may be taken.
3.3.11.3. Ordering of Certificate Payloads 3.3.10.3. Ordering of Certificate Payloads
For IKEv1, implementations MUST NOT assume that CERTs are ordered in Implementations MUST NOT assume that CERTs are ordered in any way.
any way. For IKEv2, implementations MUST NOT assume that any except
the first CERT is ordered in any way. IKEv2 specifies that the first
CERT contain an end-entity certificate which can be used to
authenticate the peer.
3.3.11.4. Duplicate Certificate Payloads 3.3.10.4. Duplicate Certificate Payloads
Implementations MUST support receiving multiple identical CERTs Implementations MUST support receiving multiple identical CERTs
during an exchange. during an exchange.
3.3.11.5. Irrelevant Certificates 3.3.10.5. Irrelevant Certificates
Implementations MUST be prepared to receive certificates and CRLs Implementations MUST be prepared to receive certificates and CRLs
which are not relevant to the current exchange. Implementations MAY which are not relevant to the current exchange. Implementations MAY
discard such extraneous certificates and CRLs. discard such extraneous certificates and CRLs.
Implementations MAY send certificates which are irrelevant to an Implementations MAY send certificates which are irrelevant to an
exchange. One reason for including certificates which are irrelevant exchange. One reason for including certificates which are irrelevant
to an exchange is to minimize the threat of leaking identifying to an exchange is to minimize the threat of leaking identifying
information in exchanges where CERT is not encrypted in IKEv1. It information in exchanges where CERT is not encrypted in IKEv1. It
should be noted, however, that this probably provides rather poor should be noted, however, that this probably provides rather poor
skipping to change at page 24, line 21 skipping to change at page 22, line 39
Authority to the end entity, each of which is only valid with certain Authority to the end entity, each of which is only valid with certain
validation parameters (such as acceptable policies). Since the end- validation parameters (such as acceptable policies). Since the end-
entity doesn't know which parameters the relying party is using, it entity doesn't know which parameters the relying party is using, it
should send the certificates needed for both chains (even if there's should send the certificates needed for both chains (even if there's
only one CERTREQ). only one CERTREQ).
Implementations SHOULD NOT send multiple end-entity certificates and Implementations SHOULD NOT send multiple end-entity certificates and
recipients SHOULD NOT be expected to iterate over multiple end-entity recipients SHOULD NOT be expected to iterate over multiple end-entity
certificates. certificates.
3.3.12. Optimizations 3.3.11. Optimizations
3.3.12.1. Duplicate Certificate Payloads 3.3.11.1. Duplicate Certificate Payloads
Implementations SHOULD NOT send duplicate CERTs during an exchange. Implementations SHOULD NOT send duplicate CERTs during an exchange.
Such payloads should be suppressed. Such payloads should be suppressed.
3.3.12.2. Send Lowest 'Common' Certificates 3.3.11.2. Send Lowest 'Common' Certificates
When multiple CERTREQs are received which specify certification When multiple CERTREQs are received which specify certification
authorities within the end-entity certificate chain, implementations authorities within the end-entity certificate chain, implementations
MAY send the shortest chain possible. However, implementations MAY send the shortest chain possible. However, implementations
SHOULD always send the end-entity certificate. See Section 3.2.10.2 SHOULD always send the end-entity certificate. See Section 3.2.9.2
for more discussion of this optimization. for more discussion of this optimization.
3.3.12.3. Ignore Duplicate Certificate Payloads 3.3.11.3. Ignore Duplicate Certificate Payloads
Implementations MAY employ local means to recognize CERTs that have Implementations MAY employ local means to recognize CERTs that have
already been received and SHOULD discard these duplicate CERTs. already been received and SHOULD discard these duplicate CERTs.
3.3.12.4. Hash Payload 3.3.11.4. Hash Payload
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. Certificate Profile 4. Use of Certificates in RFC4301 and IKEv2
4.1. Identification Payload
The Peer Authorization Database (PAD) as described in RFC 4301 [14]
describes the use of the ID payload in IKEv2 and provides a formal
model for the binding of identity to policy in addition to providing
services that deal more specifically with the details of policy
enforcement, which are generally out of scope of this document. The
PAD is intended to provide a link between the SPD and the security
association management in protocols such as IKE. See RFC 4301 [14],
section 4.4.3 for more details.
Note that IKEv2 adds an optional IDr payload in the second exchange
that the initiator may send to the responder in order to specify
which of the responder's multiple identities should be used. The
responder MAY choose to send an IDr in the 3rd exchange that differs
in type or content from the initiator-generated IDr. The initiator
MUST be able to receive a responder-generated IDr that is a different
type from the one the initiator generated.
4.2. Certificate Request Payload
4.2.1. Revocation Lists (CRL and ARL)
IKEv2 does not support Certificate Payload sizes over approximately
64K. See Section 3.2.3 for the problems this can cause.
4.2.1.1. 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
its X.509 certificate, instead of the actual certificate itself.
This is a particularly useful mechanism when the peer is a device
with little memory and lower bandwidth, e.g. a mobile handset or
consumer electronics device.
If the IKEv2 implementation supports URL lookups, and prefers such a
URL to receiving actual certificates, then the implementation will
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
message that can include a CERTREQ payload and indicates that the
sender is capable of looking up certificates based on an HTTP-based
URL (and hence presumably would prefer to receive certificate
specifications in that format)." If an HTTP_CERT_LOOKUP_SUPPORTED
notification is sent the sender MUST support the http scheme. See
Section 4.3.1 for more discussion of HTTP_CERT_LOOKUP_SUPPORTED.
4.2.1.2. Location of Certificate Request Payloads
In IKEv2, the CERTREQ payload must be in messages 2 and 3. Note that
in IKEv2, it is possible to have one side authenticating with
certificates while the other side authenticates with preshared keys.
4.3. Certificate Payload
4.3.1. IKEv2's Hash and URL of X.509 Certificate
This type specifies that Certificate Data contains a hash and the URL
to a repository where an X.509 certificate can be retrieved.
An implementation that sends a HTTP_CERT_LOOKUP_SUPPORTED
notification MUST support the http scheme and MAY support the ftp
scheme, and MUST NOT require any specific form of the url-path and it
SHOULD support having user-name, password and port parts in the URL.
The following are examples of mandatory forms:
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/%0a/../foo/bar/zappa
while the following is an example of a form that SHOULD be supported:
o http://user:password@certs.example.com:8888/certificate.cer
FTP MAY be supported, and if it is the following is an example of the
ftp scheme that MUST be supported:
o ftp://ftp.example.com/pub/certificate.cer
4.3.2. Location of Certificate Payloads
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
certificates while the other side authenticates with preshared keys.
4.3.3. Ordering of Certificate Payloads
For IKEv2, implementations MUST NOT assume that any but the first
CERT is ordered in any way. IKEv2 specifies that the first CERT
contain an end-entity certificate which can be used to authenticate
the peer.
5. Certificate Profile for IKEv1/ISAKMP and IKEv2
Except where specifically stated in this document, implementations Except where specifically stated in this document, implementations
MUST conform to the requirements of the PKIX [5] certificate profile. MUST conform to the requirements of the PKIX [5] certificate profile.
4.1. X.509 Certificates 5.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 5.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. Subject 5.1.2. Subject
Certification Authority implementations MUST be able to create Certification Authority implementations MUST be able to create
certificates with Subject 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 Subject attributes: CN, C, O, OU. Implementations MAY support other Subject
attributes as well. The contents of these attributes SHOULD be attributes as well. The contents of these attributes SHOULD be
configurable on a certificate by certificate basis, as these fields configurable on a certificate by certificate basis, as these fields
will likely be used by IKE implementations to match SPD policy. will likely be used by IKE implementations to match SPD 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 Subject field attributes for SPD policy lookup. able to process Subject field attributes for SPD policy lookup.
4.1.2.1. Empty Subject Name 5.1.2.1. Empty Subject Name
IKE Implementations MUST accept certificates which contain an empty IKE Implementations MUST accept certificates which contain an empty
Subject field, as specified in the PKIX certificate profile. Subject field, as specified in the PKIX certificate profile.
Identity information in such certificates will be contained entirely Identity information in such certificates will be contained entirely
in the SubjectAltName extension. in the SubjectAltName extension.
4.1.2.2. Specifying Hosts and not FQDN in the Subject Name 5.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 Subject MUST use the commonName attribute. "Gateway Router") in the Subject MUST use the commonName attribute.
4.1.2.3. EmailAddress 5.1.2.3. EmailAddress
As specified in the PKIX certificate profile, implementations MUST As specified in the PKIX certificate profile, implementations MUST
NOT populate X.500 distinguished names with the emailAddress NOT populate X.500 distinguished names with the emailAddress
attribute. attribute.
4.1.3. X.509 Certificate Extensions 5.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
the PKIX certificate profile and this document. With respect to the PKIX certificate profile and this document. With respect to
compliance with the PKIX certificate profile, IKE implementations compliance with the PKIX certificate profile, IKE implementations
processing certificates MAY ignore the value of the criticality bit processing certificates MAY ignore the value of the criticality bit
for extensions that are supported by that implementation, but MUST for extensions that are supported by that implementation, but MUST
support the criticality bit for extensions that are not supported by support the criticality bit for extensions that are not supported by
that implementation. That is, a peer processes all the extensions it that implementation. That is, a relying party SHOULD processes all
is aware of whether the bit is true or false -- the bit says what the extensions it is aware of whether the bit is true or false -- the
happens when a peer cannot process an extension. bit says what happens when a relying party 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
no false false ok no false false ok
4.1.3.1. AuthorityKeyIdentifier and SubjectKeyIdentifier 5.1.3.1. AuthorityKeyIdentifier and SubjectKeyIdentifier
Implementations SHOULD NOT assume support for the Implementations SHOULD NOT assume support for the
AuthorityKeyIdentifier or SubjectKeyIdentifier extensions, and thus AuthorityKeyIdentifier or SubjectKeyIdentifier extensions, and thus
Certification Authority implementations should not generate Certification Authority implementations should not generate
certificate hierarchies which are overly complex to process in the certificate hierarchies which are overly complex to process in the
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 5.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 (KU) and ExtendedKeyUsage (EKU) key ought to be used. The KeyUsage (KU) and ExtendedKeyUsage (EKU)
extensions 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
skipping to change at page 27, line 31 skipping to change at page 28, line 5
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 5.1.3.3. PrivateKeyUsagePeriod
The PKIX certificate profile recommends against the use of this The PKIX certificate profile recommends against the use of this
extension. The PrivateKeyUsageExtension is intended to be used when extension. The PrivateKeyUsageExtension is intended to be used when
signatures will need to be verified long past the time when signatures will need to be verified long past the time when
signatures using the private keypair may be generated. Since IKE SAs signatures using the private keypair may be generated. Since IKE SAs
are short-lived relative to the intended use of this extension in are short-lived relative to the intended use of this extension in
addition to the fact that each signature is validated only a single addition to the fact that each signature is validated only a single
time, the usefulness of this extension in the context of IKE is time, the usefulness of this extension in the context of IKE is
unclear. Therefore, Certification Authority implementations MUST NOT unclear. Therefore, Certification Authority implementations MUST NOT
generate certificates that contain the PrivateKeyUsagePeriod generate certificates that contain the PrivateKeyUsagePeriod
extension. If an IKE implementation receives a certificate with this extension. If an IKE implementation receives a certificate with this
set, it SHOULD ignore it. set, it SHOULD ignore it.
4.1.3.4. CertificatePolicies 5.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. As is the case
with all certificate extensions, a relying party receiving this
extension but who can process the extension SHOULD NOT reject the
certificate because it contains the extension.
4.1.3.5. PolicyMappings 5.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 5.1.3.6. SubjectAltName
Deployments that intend to use an ID of FQDN, USER_FQDN, IPV4_ADDR, Deployments that intend to use an ID of FQDN, USER_FQDN, 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 5.1.3.6.1. dNSName
If the IKE ID type is FQDN, then this field MUST contain a fully If the IKE ID type is FQDN, then this field MUST contain a fully
qualified domain name. If the IKE ID type is FQDN then the dNSName qualified domain name. If the IKE ID type is FQDN then the dNSName
field MUST match its contents. Implementations MUST NOT generate field MUST match its contents. Implementations MUST NOT generate
names that contain wildcards. Implementations MAY treat certificates names that contain wildcards. Implementations MAY treat certificates
that contain wildcards in this field as syntactically invalid. that contain wildcards in this field as syntactically invalid.
Although this field is in the form of an FQDN, IKE implementations Although this field is in the form of an FQDN, IKE implementations
SHOULD NOT assume that this field contains an FQDN that will resolve SHOULD NOT assume that this field contains an FQDN that will resolve
via the DNS, unless this is known by way of some out-of-band via the DNS, unless this is known by way of some out-of-band
mechanism. Such a mechanism is out of the scope of this document. mechanism. Such a mechanism is out of the scope of this document.
Implementations SHOULD NOT treat the failure to resolve as an error. Implementations SHOULD NOT treat the failure to resolve as an error.
4.1.3.6.2. iPAddress 5.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 [15] MUST match its contents. Note that although PKIX permits CIDR [15]
notation in the "Name Constraints" extension, the PKIX certificate notation in the "Name Constraints" extension, the PKIX certificate
profile explicitly prohibits using CIDR notation for conveying profile explicitly prohibits using CIDR notation for conveying
identity information. In other words, the CIDR notation MUST NOT be identity information. In other words, the CIDR notation MUST NOT be
used in the SubjectAltName extension. used in the SubjectAltName extension.
4.1.3.6.3. rfc822Name 5.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.
4.1.3.7. IssuerAltName 5.1.3.7. IssuerAltName
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 5.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 the PKIX ignore this extension when it is marked non-critical, as the PKIX
certificate profile mandates. certificate profile mandates.
4.1.3.9. BasicConstraints 5.1.3.9. BasicConstraints
The PKIX certificate profile mandates that CA certificates contain The PKIX certificate profile mandates that CA certificates contain
this extension and that it be marked critical. IKE implementations this extension and that it be marked critical. IKE implementations
SHOULD reject CA certificates that do not contain this extension. SHOULD reject CA certificates that do not contain this extension.
For backwards compatibility, implementations may accept such For backwards compatibility, implementations may accept such
certificates if explicitly configured to do so, but the default for certificates if explicitly configured to do so, but the default for
this setting MUST be to reject such certificates. this setting MUST be to reject such certificates.
4.1.3.10. NameConstraints 5.1.3.10. NameConstraints
Many IKE implementations do not support the NameConstraints Many IKE implementations do not support the NameConstraints
extension. Since the PKIX certificate profile mandates that this extension. Since the PKIX certificate profile mandates that this
extension be marked critical when present, Certification Authority extension be marked critical when present, Certification Authority
implementations which are interested in maximal interoperability for implementations which are interested in maximal interoperability for
IKE SHOULD NOT generate certificates which contain this extension. IKE SHOULD NOT generate certificates which contain this extension.
4.1.3.11. PolicyConstraints 5.1.3.11. PolicyConstraints
Many IKE implementations do not support the PolicyConstraints Many IKE implementations do not support the PolicyConstraints
extension. Since the PKIX certificate profile mandates that this extension. Since the PKIX certificate profile mandates that this
extension be marked critical when present, Certification Authority extension be marked critical when present, Certification Authority
implementations which are interested in maximal interoperability for implementations which are interested in maximal interoperability for
IKE SHOULD NOT generate certificates which contain this extension. IKE SHOULD NOT generate certificates which contain this extension.
4.1.3.12. ExtendedKeyUsage 5.1.3.12. ExtendedKeyUsage
The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in
certificates for use with IKE. Note that there were three IPsec certificates for use with IKE. Note that there were three IPsec
related object identifiers in EKU that were assigned in 1999. The related object identifiers in EKU that were assigned in 1999. The
semantics of these values were never clearly defined. The use of semantics of these values were never clearly defined. The use of
these three EKU values in IKE/IPsec is obsolete and explicitly these three EKU values in IKE/IPsec is obsolete and explicitly
deprecated by this specification. CAs SHOULD NOT issue certificates deprecated by this specification. CAs SHOULD NOT issue certificates
for use in IKE with them. (For historical reference only, those for use in IKE with them. (For historical reference only, those
values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp- values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp-
ipsecUser.) ipsecUser.)
skipping to change at page 30, line 38 skipping to change at page 31, line 14
certificates meant for use in IKE are NOT RECOMMENDED. certificates meant for use in IKE are NOT RECOMMENDED.
A summary of the logic flow for peer certificate validation regarding A summary of the logic flow for peer certificate validation regarding
the EKU extension follows: the EKU extension follows:
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 5.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 [16]). 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 5.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 the IETF IPR web page for CRLDistributionPoints intellectual See the IETF IPR web page for CRLDistributionPoints intellectual
property rights (IPR) information. Note that both the property rights (IPR) information. Note that both the
CRLDistributionPoints and IssuingDistributionPoint extensions are CRLDistributionPoints and IssuingDistributionPoint extensions are
RECOMMENDED but not REQUIRED by the PKIX certificate profile, so RECOMMENDED but not REQUIRED by the PKIX certificate profile, so
there is no requirement to license any IPR. there is no requirement to license any IPR.
4.1.3.14. InhibitAnyPolicy 5.1.3.14. InhibitAnyPolicy
Many IKE implementations do not support the InhibitAnyPolicy Many IKE implementations do not support the InhibitAnyPolicy
extension. Since the PKIX certificate profile mandates that this extension. Since the PKIX certificate profile mandates that this
extension be marked critical when present, Certification Authority extension be marked critical when present, Certification Authority
implementations which are interested in maximal interoperability for implementations which are interested in maximal interoperability for
IKE SHOULD NOT generate certificates which contain this extension. IKE SHOULD NOT generate certificates which contain this extension.
4.1.3.15. FreshestCRL 5.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 5.1.3.16. AuthorityInfoAccess
The PKIX certificate profile defines the AuthorityInfoAccess The PKIX certificate profile defines the AuthorityInfoAccess
extension, which is used to indicate "how to access CA information extension, which is used to indicate "how to access CA information
and services for the issuer of the certificate in which the extension and services for the issuer of the certificate in which the extension
appears." Because this document deprecates the sending of CRLs in- appears." Because this document deprecates the sending of CRLs in-
band, the use of AuthorityInfoAccess (AIA) becomes very important if band, the use of AuthorityInfoAccess (AIA) becomes very important if
OCSP [16] is to be used for revocation checking (as opposed to CRLs). OCSP [16] is to be used for revocation checking (as opposed to CRLs).
The IPsec peer either needs to have a URI for the OCSP query written The IPsec peer either needs to have a URI for the OCSP query written
into its local configuration, or it needs to learn it from AIA. into its local configuration, or it needs to learn it from AIA.
Therefore, implementations SHOULD support this extension, especially Therefore, implementations SHOULD support this extension, especially
if OCSP will be used. if OCSP will be used.
4.1.3.17. SubjectInfoAccess 5.1.3.17. SubjectInfoAccess
The PKIX certificate profile defines the SubjectInfoAccess The PKIX certificate profile defines the SubjectInfoAccess
certificate extension, which is used to indicate "how to access certificate extension, which is used to indicate "how to access
information and services for the subject of the certificate in which information and services for the subject of the certificate in which
the extension appears." This extension has no known use in the the extension appears." This extension has no known use in the
context of IPsec. Conformant IKE implementations SHOULD ignore this context of IPsec. Conformant IKE implementations SHOULD ignore this
extension when present. extension when present.
4.2. X.509 Certificate Revocation Lists 5.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. IKE implementations MAY certificates with this field populated. IKE implementations MAY
provide a configuration option to disable use of certain types of provide a configuration option to disable use of certain types of
revocation information, but that option MUST be off by default. Such revocation information, but that option MUST be off by default. Such
an option is often valuable in lab testing environments. an option is often valuable in lab testing environments.
4.2.1. Multiple Sources of Certificate Revocation Information 5.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 5.2.2. X.509 Certificate Revocation List Extensions
4.2.2.1. AuthorityKeyIdentifier 5.2.2.1. AuthorityKeyIdentifier
Certification Authority implementations SHOULD NOT assume that IKE Certification Authority implementations SHOULD NOT assume that IKE
implementations support the AuthorityKeyIdentifier extension, and implementations support the AuthorityKeyIdentifier extension, and
thus should not generate certificate hierarchies which are overly thus should not generate certificate hierarchies which are overly
complex to process in the absence of this extension, such as those complex to process in the absence of this extension, such as those
that require possibly verifying a signature against a large number of that require possibly verifying a signature against a large number of
similarly named CA certificates in order to find the CA certificate similarly named CA certificates in order to find the CA certificate
which contains the key that was used to generate the signature. which contains the key that was used to generate the signature.
4.2.2.2. IssuerAltName 5.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 5.2.2.3. CRLNumber
As stated in the PKIX certificate profile, all issuers MUST include As stated in the PKIX certificate profile, all issuers MUST include
this extension in all CRLs. this extension in all CRLs.
4.2.2.4. DeltaCRLIndicator 5.2.2.4. DeltaCRLIndicator
4.2.2.4.1. If Delta CRLs Are Unsupported 5.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 the PKIX certificate profile) and MUST make use of a according to the PKIX certificate profile) and MUST make use of a
base CRL if it is available. Such implementations MUST ensure that a base CRL if it is available. Such implementations MUST ensure that a
delta CRL does not "overwrite" a base CRL, for instance in the keying delta CRL does not "overwrite" a base CRL, for instance in the keying
material database. material database.
4.2.2.4.2. Delta CRL Recommendations 5.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 A 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 the PKIX [5] would be. See the Security Considerations section of the PKIX [5]
certificate profile for additional discussion. Implementors as well certificate profile for additional discussion. Implementors as well
as administrators are encouraged to consider these issues. as administrators are encouraged to consider these issues.
4.2.2.5. IssuingDistributionPoint 5.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
IssuingDistributionPoint extension. At least one CA is known to IssuingDistributionPoint extension. At least one CA is known to
default to this type of CRL use. See Section 4.1.3.13 for more default to this type of CRL use. See Section 5.1.3.13 for more
information. information.
4.2.2.6. FreshestCRL 5.2.2.6. FreshestCRL
Given the recommendations against Certification Authority Given the recommendations against Certification Authority
implementations generating delta CRLs, this specification RECOMMENDS implementations generating delta CRLs, this specification RECOMMENDS
that implementations do not populate CRLs with the FreshestCRL that implementations do not populate CRLs with the FreshestCRL
extension, which is used to obtain delta CRLs. extension, which is used to obtain delta CRLs.
4.3. Strength of Signature Hashing Algorithms 5.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 [17], 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
skipping to change at page 35, line 5 skipping to change at page 35, line 25
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 is at least one CA that supports document is being written, there is at least one CA that supports
generating certificates with sha256WithRSAEncryption signature generating certificates with sha256WithRSAEncryption signature
algorithm and it is expected that there will be significant algorithm and it is expected that there will be significant
deployment of this algorithm by the end of 2007. deployment of this algorithm by the end of 2007.
5. Configuration Data Exchange Conventions 6. 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 6.1. Certificates
Certificates MUST be Base64 [19] encoded and appear between the Certificates MUST be Base64 [19] encoded and appear between the
following delimiters: following delimiters:
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
-----END CERTIFICATE----- -----END CERTIFICATE-----
5.2. CRLs and ARLs 6.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 6.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 Section 5.1. A raw key is only the transferred in the same form as Section 6.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 6.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. Acknowledgements 7. Acknowledgements
The authors would like to acknowledge the expired draft-ietf-ipsec- The authors would like to acknowledge the expired draft-ietf-ipsec-
pki-req-05.txt for providing valuable materials for this document. pki-req-05.txt for providing valuable materials for this document.
The authors would like to especially thank Eric Rescorla, one of its The authors would like to especially thank Eric Rescorla, one of its
original authors, in addition to Greg Carter, Steve Hanna, Russ original authors, in addition to Greg Carter, Steve Hanna, Russ
Housley, Charlie Kaufman, Tero Kivinen, Pekka Savola, Paul Hoffman, Housley, Charlie Kaufman, Tero Kivinen, Pekka Savola, Paul Hoffman,
and Gregory Lebovitz for their valuable comments, some of which have and Gregory Lebovitz for their valuable comments, some of which have
been incorporated verbatim into this document. Paul Knight performed been incorporated verbatim into this document. Paul Knight performed
the arduous tasks of coverting the text to XML format. the arduous tasks of coverting the text to XML format.
7. Security Considerations 8. Security Considerations
7.1. Certificate Request Payload 8.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.
7.2. IKEv1 Main Mode 8.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.
7.3. Disabling Certificate Checks 8.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.
8. IANA Considerations 9. 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 10. References
9.1. Normative References
[1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 10.1. Normative References
RFC 2409, November 1998.
[2] Maughan, D., Schneider, M., and M. Schertler, "Internet Security [1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
Association and Key Management Protocol (ISAKMP)", RFC 2408, RFC 2409, November 1998.
November 1998.
[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, [2] Maughan, D., Schneider, M., and M. Schertler, "Internet
December 2005. Security Association and Key Management Protocol (ISAKMP)",
RFC 2408, November 1998.
[4] Kent, S. and R. Atkinson, "Security Architecture for the [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Internet Protocol", RFC 2401, November 1998. RFC 4306, December 2005.
[5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 [4] Kent, S. and R. Atkinson, "Security Architecture for the
Public Key Infrastructure Certificate and Certificate Revocation Internet Protocol", RFC 2401, November 1998.
List (CRL) Profile", RFC 3280, April 2002.
[6] Piper, D., "The Internet IP Security Domain of Interpretation [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
for ISAKMP", RFC 2407, November 1998. Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Piper, D., "The Internet IP Security Domain of Interpretation
Levels", BCP 14, RFC 2119, March 1997. for ISAKMP", RFC 2407, November 1998.
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] Kaliski, B., "PKCS #10: Certification Request Syntax Version [8] Postel, J., "Internet Protocol", STD 5, RFC 791,
1.5", RFC 2314, March 1998. September 1981.
9.2. Informative References [9] Kaliski, B., "PKCS #10: Certification Request Syntax Version
1.5", RFC 2314, March 1998.
[10] Kent, S. and K. Seo, "Security Architecture for the Internet 10.2. Informative References
Protocol", RFC 4301, December 2005.
[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[12] Eastlake, D., "Domain Name System Security Extensions", [11] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[13] Faltstrom, P., Hoffman, P., and A. Costello, [12] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[14] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [13] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[14] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[15] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- [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.
[16] 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.
[17] 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.
skipping to change at page 51, line 7 skipping to change at page 52, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 149 change blocks. 
306 lines changed or deleted 327 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/