| < 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/ | ||||