idnits 2.17.00 (12 Aug 2021) /tmp/idnits29199/draft-ietf-pki4ipsec-ikecert-profile-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2340. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 36 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1192 has weird spacing: '...lements bit...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * Sect 3.1.1 - editorial changes to aid in clarification. Added text on when deployers might consider using IP addr, but strongly encouraged not to. * Sect 3.1.8 removed IP address from list of practically used ID types. * 3.1.9 overhauled (per Kivinen, July 18) * 3.2 - added IKEv2's Hash and URL of x.509 to list of those profiled and gave it its own section, now 3.2.5 * added note in CRL/ARL section about revocation occurring OOB of IKE * deleted ARL as its own section and collapsed it into Revocation Lists (CRL and ARL) for consciseness. Renumbered accordingly. * Sect 3.2.7.2 - Changed from MUST not send empty certreqs to SHOULD send CERTREQs which contain CA fields with direction on how, but MAY send empty CERTREQs in certain case. Use case added, and specifics of both initiator and responder behavior listed. * APPENDIX C added to fill out the explanation (mostly discussion from list). * 3.3 - clarified that sending CRLs and chaining certs is deprecated. * added IKEv2's Hash and URL of x.509 to list of those profiled and gave it its own section. Condensed ARL into CRL and renumbered accordingly. * duplicate section was removed, renumbered accordingly * 3.3.10.2 - title changed. sending chaining becomes SHOULD NOT. * 4.1.2 added text to explicity call out support for CN, C, O, OU * collapsed 4.1.2.3 into 4.1.2.2 and renumbered accordingly. * Collapsed 4.1.3.2 into 4.1.3.1 and renumbered accordingly * Edited 4.1.3.2 Key Usage and 4.1.3.12 ExtKey Usage according to Hoffman, July18 * 4.1.3.3 if receive cert w/ PKUP, ignore it. * 4.1.3.13 - CDP changed text to represent SHOULD issue, and how important CDP becomes when we do not send CRLs in-band. Added SHOULD for CDPs actually being resolvable (reilly email). * Reordered 6.4 for better clarity. * Added Rescorla to Acknowledgements section, as he is no longer listed as an editor, since -00. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 12, 2006) is 5882 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'IKEv2' on line 2140 -- Looks like a reference, but probably isn't: 'IDr' on line 2230 == Unused Reference: '20' is defined on line 1748, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2409 (ref. '1') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '2') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4306 (ref. '3') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 2401 (ref. '4') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3280 (ref. '5') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2407 (ref. '6') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2314 (ref. '9') (Obsoleted by RFC 2986) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '11') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '12') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. '13') (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. '15') (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. '16') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3548 (ref. '19') (Obsoleted by RFC 4648) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pki4ipsec B. Korver 3 Internet-Draft Network Resonance, Inc. 4 Expires: October 14, 2006 April 12, 2006 6 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX 7 draft-ietf-pki4ipsec-ikecert-profile-10 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 14, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 IKE and PKIX certificate profile both provide frameworks that must be 41 profiled for use in a given application. This document provides a 42 profile of IKE and PKIX that defines the requirements for using PKI 43 technology in the context of IKE/IPsec. The document complements 44 protocol specifications such as IKEv1 and IKEv2, which assume the 45 existence of public key certificates and related keying materials, 46 but which do not address PKI issues explicitly. This document 47 addresses those issues. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 53 3. Profile of IKEv1/ISAKMP and IKEv2 . . . . . . . . . . . . . . 5 54 3.1. Identification Payload . . . . . . . . . . . . . . . . . . 5 55 3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . . . 7 56 3.1.2. ID_FQDN . . . . . . . . . . . . . . . . . . . . . . . 9 57 3.1.3. ID_USER_FQDN . . . . . . . . . . . . . . . . . . . . . 10 58 3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, 59 ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE . . . . . . . . 11 60 3.1.5. ID_DER_ASN1_DN . . . . . . . . . . . . . . . . . . . . 11 61 3.1.6. ID_DER_ASN1_GN . . . . . . . . . . . . . . . . . . . . 12 62 3.1.7. ID_KEY_ID . . . . . . . . . . . . . . . . . . . . . . 12 63 3.1.8. Selecting an Identity from a Certificate . . . . . . . 12 64 3.1.9. Subject for DN Only . . . . . . . . . . . . . . . . . 12 65 3.1.10. Binding Identity to Policy . . . . . . . . . . . . . . 12 66 3.2. Certificate Request Payload . . . . . . . . . . . . . . . 13 67 3.2.1. Certificate Type . . . . . . . . . . . . . . . . . . . 14 68 3.2.2. X.509 Certificate - Signature . . . . . . . . . . . . 14 69 3.2.3. Revocation Lists (CRL and ARL) . . . . . . . . . . . . 14 70 3.2.4. PKCS #7 wrapped X.509 certificate . . . . . . . . . . 15 71 3.2.5. IKEv2's Hash and URL of X.509 certificate . . . . . . 15 72 3.2.6. Location of Certificate Payloads . . . . . . . . . . . 15 73 3.2.7. Presence or Absence of Certificate Request Payloads . 15 74 3.2.8. Certificate Requests . . . . . . . . . . . . . . . . . 16 75 3.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 18 76 3.2.10. Optimizations . . . . . . . . . . . . . . . . . . . . 18 77 3.3. Certificate Payload . . . . . . . . . . . . . . . . . . . 19 78 3.3.1. Certificate Type . . . . . . . . . . . . . . . . . . . 20 79 3.3.2. X.509 Certificate - Signature . . . . . . . . . . . . 20 80 3.3.3. Revocation Lists (CRL and ARL) . . . . . . . . . . . . 21 81 3.3.4. IKEv2's Hash and URL of X.509 Certificate . . . . . . 21 82 3.3.5. PKCS #7 wrapped X.509 certificate . . . . . . . . . . 21 83 3.3.6. Location of Certificate Payloads . . . . . . . . . . . 21 84 3.3.7. Certificate Payloads Not Mandatory . . . . . . . . . . 22 85 3.3.8. Response to Multiple Certification Authority 86 Proposals . . . . . . . . . . . . . . . . . . . . . . 22 87 3.3.9. Using Local Keying Materials . . . . . . . . . . . . . 22 88 3.3.10. Multiple End-Entity Certificates . . . . . . . . . . . 22 89 3.3.11. Robustness . . . . . . . . . . . . . . . . . . . . . . 23 90 3.3.12. Optimizations . . . . . . . . . . . . . . . . . . . . 24 91 4. Certificate Profile . . . . . . . . . . . . . . . . . . . . . 24 92 4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 24 93 4.1.1. Versions . . . . . . . . . . . . . . . . . . . . . . . 25 94 4.1.2. Subject . . . . . . . . . . . . . . . . . . . . . . . 25 95 4.1.3. X.509 Certificate Extensions . . . . . . . . . . . . . 26 96 4.2. X.509 Certificate Revocation Lists . . . . . . . . . . . . 31 97 4.2.1. Multiple Sources of Certificate Revocation 98 Information . . . . . . . . . . . . . . . . . . . . . 32 99 4.2.2. X.509 Certificate Revocation List Extensions . . . . . 32 100 4.3. Strength of Signature Hashing Algorithms . . . . . . . . . 33 101 5. Configuration Data Exchange Conventions . . . . . . . . . . . 34 102 5.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 34 103 5.2. CRLs and ARLs . . . . . . . . . . . . . . . . . . . . . . 35 104 5.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 35 105 5.4. PKCS#10 Certificate Signing Requests . . . . . . . . . . . 35 106 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 108 7.1. Certificate Request Payload . . . . . . . . . . . . . . . 36 109 7.2. IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 36 110 7.3. Disabling Certificate Checks . . . . . . . . . . . . . . . 36 111 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 112 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 113 9.1. Normative References . . . . . . . . . . . . . . . . . . . 36 114 9.2. Informative References . . . . . . . . . . . . . . . . . . 37 115 Appendix A. The Possible Dangers of Delta CRLs . . . . . . . . . 38 116 Appendix B. More on Empty CERTREQs . . . . . . . . . . . . . . . 38 117 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 40 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51 119 Intellectual Property and Copyright Statements . . . . . . . . . . 52 121 1. Introduction 123 IKE [1], ISAKMP [2] and IKEv2 [3] provide a secure key exchange 124 mechanism for use with IPsec [4]. In many cases the peers 125 authenticate using digital certificates as specified in PKIX [5]. 126 Unfortunately, the combination of these standards leads to an 127 underspecified set of requirements for the use of certificates in the 128 context of IPsec. 130 ISAKMP references the PKIX certificate profile, but in many cases 131 merely specifies the contents of various messages without specifying 132 their syntax or semantics. Meanwhile, the PKIX certificate profile 133 provides a large set of certificate mechanisms which are generally 134 applicable for Internet protocols, but little specific guidance for 135 IPsec. Given the numerous underspecified choices, interoperability 136 is hampered if all implementers do not make similar choices, or at 137 least fail to account for implementations which have chosen 138 differently. 140 This profile of the IKE and PKIX frameworks is intended to provide an 141 agreed-upon standard for using PKI technology in the context of IPsec 142 by profiling the PKIX framework for use with IKE and IPsec, and by 143 documenting the contents of the relevant IKE payloads and further 144 specifying their semantics. 146 In addition to providing a profile of IKE and PKIX, this document 147 attempts to incorporate lessons learned from recent experience with 148 both implementation and deployment, as well as the current state of 149 related protocols and technologies. 151 Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and 152 readers of this document are assumed to have read and understood 153 those documents. The requirements and security aspects of those 154 documents are fully relevant to this document as well. 156 This document is organized as follows. Section 2 defines special 157 terminology used in the rest of this document, Section 3 provides the 158 profile of IKEv1/ISAKMP and IKEv2, and Section 4 provides the profile 159 of PKIX. Section 5 covers conventions for the out-of-band exchange 160 of keying materials for configuration purposes. 162 2. Terms and Definitions 164 Except for those terms which are defined immediately below, all terms 165 used in this document are defined in either the PKIX [5], ISAKMP [2], 166 IKEv1 [1], IKEv2 [3], or DOI [6] documents. 168 o Peer source address: The source address in packets from a peer. 169 This address may be different from any addresses asserted as the 170 "identity" of the peer. 171 o FQDN: Fully qualified domain name. 172 o ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both 173 are referred to as ID_USER_FQDN in this document. 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC-2119 [7]. 179 3. Profile of IKEv1/ISAKMP and IKEv2 181 3.1. Identification Payload 183 The Identification (ID) Payload indicates the identity claimed by the 184 sender. The recipient can then use the ID as a lookup key for policy 185 and for certificate lookup in whatever certificate store or directory 186 that it has available. Our primary concern in this section is to 187 profile the ID payload so that it can be safely used to generate or 188 lookup policy. IKE mandates the use of the ID payload in Phase 1. 190 The DOI [6] defines the 11 types of Identification Data that can be 191 used and specifies the syntax for these types. These are discussed 192 below in detail. 194 The ID payload requirements in this document cover only the portion 195 of the explicit policy checks that deal with the Identification 196 Payload specifically. For instance, in the case where ID does not 197 contain an IP address, checks such as verifying that the peer source 198 address is permitted by the relevant policy are not addressed here as 199 they are out of the scope of this document. 201 Implementations SHOULD populate ID with identity information that is 202 contained within the end-entity certificate (This SHOULD does not 203 contradict text in IKEv2 [3] Section 3.5 that implies a looser 204 binding between these two). Populating ID with identity information 205 from the end-entity certificate enables recipients to use ID as a 206 lookup key to find the peer end-entity certificate. The only case 207 where implementations MAY populate ID with information that is not 208 contained in the end-entity certificate is when ID contains the peer 209 source address (a single address, not a subnet or range). 211 Because implementations may use ID as a lookup key to determine which 212 policy to use, all implementations MUST be especially careful to 213 verify the truthfulness of the contents by verifying that they 214 correspond to some keying material demonstrably held by the peer. 216 Failure to do so may result in the use of an inappropriate or 217 insecure policy. The following sections describe the methods for 218 performing this binding. 220 The following table summarizes the binding of the Identification 221 Payload to the contents of end-entity certificates and of identity 222 information to policy. Each ID type is covered more thoroughly in 223 the following sections. 225 ID type | Support | Correspond | Cert | SPD lookup 226 | for send | PKIX Attrib | matching | rules 227 ------------------------------------------------------------------- 228 | | | | 229 IP*_ADDR | MUST [a] | SubjAltName | MUST [b] | [c], [d] 230 | | iPAddress | | 231 | | | | 232 FQDN | MUST [a] | SubjAltName | MUST [b] | [c], [d] 233 | | dNSName | | 234 | | | | 235 USER_FQDN| MUST [a] | SubjAltName | MUST [b] | [c], [d] 236 | | rfc822Name | | 237 | | | | 238 IP range | MUST NOT | n/a | n/a | n/a 239 | | | | 240 DN | MUST [a] | Entire | MUST [b] | MUST support lookup 241 | | Subject, | | on any combination 242 | | bitwise | | of C, CN, O, or OU 243 | | compare | | 244 | | | | 245 GN | MUST NOT | n/a | n/a | n/a 246 | | | | 247 KEY_ID | MUST NOT | n/a | n/a | n/a 248 | | | | 250 [a] = Implementation MUST have the configuration option to send this 251 ID type in the ID payload. Whether or not the ID type is used is a 252 matter of local configuration. 254 [b] = The ID in the ID payload MUST match the contents of the 255 corresponding field (listed) in the certificate exactly, with no 256 other lookup. The matched ID MAY be used for SPD lookup, but is not 257 required to be used for this. See RFC 4301 [10], section 4.4.3.2 for 258 more details. 260 [c] = At a minimum, Implementation MUST be capable of being 261 configured to perform exact matching of the ID payload contents to an 262 entry in the local SPD. 264 [d] = In addition, the implementation MAY also be configurable to 265 perform substring or wildcard matches of ID payload contents to 266 entries in the local SPD. (More on this in Section 3.1.5). 268 When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, 269 implementations MUST be able to be configured to send the same string 270 as appears in the corresponding SubjectAltName extension. This 271 document RECOMMENDS that deployers use this configuration option. 272 All these ID types are treated the same: as strings that can be 273 compared easily and quickly to a corresponding string in an explicit 274 value in the certificate. Of these types, FQDN and USER_FQDN are 275 RECOMMENDED over IP addresses (see discussion in Section 3.1.1). 277 When sending a DN as ID, implementations MUST send the entire DN in 278 ID. Also, implementations MUST support at least the C, CN, O, and OU 279 attributes for SPD matching. See Section 3.1.5 for more details 280 about DN, including SPD matching. 282 Recipients MUST be able to perform SPD matching on the exact contents 283 of the ID, and this SHOULD be the default setting. In addition, 284 implementations MAY use substrings or wildcards in local policy 285 configuration to do the SPD matching against the ID contents. In 286 other words, implementations MUST be able to do exact matches of ID 287 to SPD, but MAY also be configurable to do substring or wildcard 288 matches of ID to SPD. 290 IKEv2 adds an optional IDr payload in the second exchange that the 291 initiator may send to the responder in order to specify which of the 292 responder's multiple identities should be used. The responder MAY 293 choose to send an IDr in the 3rd exchange that differs in type or 294 content from the initiator-generated IDr. The initiator MUST be able 295 to receive a responder-generated IDr that is a different type from 296 the one the initiator generated. 298 3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR 300 Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR 301 ID type, depending on whether the implementation supports IPv4, IPv6 302 or both. These addresses MUST be encoded in "network byte order," as 303 specified in IP [8]: The least significant bit (LSB) of each octet is 304 the LSB of the corresponding byte in the network address. For the 305 ID_IPV4_ADDR type, the payload MUST contain exactly four octets [8]. 306 For the ID_IPV6_ADDR type, the payload MUST contain exactly sixteen 307 octets [11]. 309 Implementations SHOULD NOT populate ID payload with IP addresses due 310 to interoperability issues such as problems with NAT traversal, and 311 problems with IP verification behavior. 313 Deployments may only want to consider using the IP address as ID if 314 all of the following are true: 316 o the peer's IP address is static, not dynamically changing 317 o the peer is NOT behind a NAT'ing device 318 o the administrator intends the implementation to verify that the 319 peer source address matches the IP address in the ID received, and 320 that in the iPAddress field in the peer certificate's 321 SubjectAltName extension. 323 Implementations MUST be capable of verifying that the IP address 324 presented in ID matches via bitwise comparison the IP address present 325 in the certificate's iPAddress field of the SubjectAltName extension. 326 Implementations MUST perform this verification by default. When 327 comparing the contents of ID with the iPAddress field in the 328 SubjectAltName extension for equality, binary comparison MUST be 329 performed. Note that certificates may contain multiple address 330 identity types in which case at least one must match the source IP. 331 If the default is enabled, then a mismatch between the two addresses 332 MUST be treated as an error and security association setup MUST be 333 aborted. This event SHOULD be auditable. Implementations MAY 334 provide a configuration option to (i.e. local policy configuration 335 can enable) skip that verification step, but that option MUST be off 336 by default. We include the "option-to-skip-validation" in order to 337 permit better interoperability, as today implementations vary greatly 338 in how they behave on this topic. 340 In addition, implementations MUST be capable of verifying that the 341 address contained in the ID is the same as the peer source address, 342 contained in the outer most IP header. If ID is one of the IP 343 address types, then implementations MUST perform this verification by 344 default. If this default is enabled, then a mismatch MUST be treated 345 as an error and security association setup MUST be aborted. This 346 event SHOULD be auditable. Implementations MAY provide a 347 configuration option to (i.e. local policy configuration can enable) 348 skip that verification step, but that option MUST be off by default. 349 We include the "option-to-skip-validation" in order to permit better 350 interoperability, as today implementations vary greatly in how they 351 behave on the topic of verification of source IP. 353 If the default for both the verifications above are enabled, then, by 354 transitive property, the implementation will also be verifying that 355 the peer source IP address matches via a bitwise comparison the 356 contents of the iPAddress field in the SubjectAltName extension in 357 the certificate. In addition, implementations MAY allow 358 administrators to configure a local policy that explicitly requires 359 that the peer source IP address match via a bitwise comparison the 360 contents of the iPAddress field in the SubjectAltName extension in 361 the certificate. Implementations SHOULD allow administrators to 362 configure a local policy that skips this validation check. 364 Implementations MAY support substring, wildcard, or regular 365 expression matching of the contents of ID to lookup policy in the 366 SPD, and such would be a matter of local security policy 367 configuration. 369 Implementations MAY use the IP address found in the header of packets 370 received from the peer to lookup the policy, but such implementations 371 MUST still perform verification of the ID payload. Although packet 372 IP addresses are inherently untrustworthy and must therefore be 373 independently verified, it is often useful to use the apparent IP 374 address of the peer to locate a general class of policies that will 375 be used until the mandatory identity-based policy lookup can be 376 performed. 378 For instance, if the IP address of the peer is unrecognized, a VPN 379 gateway device might load a general "road warrior" policy that 380 specifies a particular CA that is trusted to issue certificates which 381 contain a valid rfc822Name which can be used by that implementation 382 to perform authorization based on access control lists (ACLs) after 383 the peer's certificate has been validated. The rfc822Name can then 384 be used to determine the policy that provides specific authorization 385 to access resources (such as IP addresses, ports, and so forth). 387 As another example, if the IP address of the peer is recognized to be 388 a known peer VPN endpoint, policy may be determined using that 389 address, but until the identity (address) is validated by validating 390 the peer certificate, the policy MUST NOT be used to authorize any 391 IPsec traffic. 393 3.1.2. ID_FQDN 395 Implementations MUST support the ID_FQDN ID type, generally to 396 support host-based access control lists for hosts without fixed IP 397 addresses. However, implementations SHOULD NOT use the DNS to map 398 the FQDN to IP addresses for input into any policy decisions, unless 399 that mapping is known to be secure, for example if DNSSEC [12] were 400 employed for that FQDN. 402 If ID contains an ID_FQDN, implementations MUST be capable of 403 verifying that the identity contained in the ID payload matches 404 identity information contained in the peer end-entity certificate, in 405 the dNSName field in the SubjectAltName extension. Implementations 406 MUST perform this verification by default. When comparing the 407 contents of ID with the dNSName field in the SubjectAltName extension 408 for equality, caseless string comparison MUST be performed. Note 409 that caseless string comparison works on internationalized domain 410 names (IDNs) as well (See IDN [13]). Substring, wildcard, or regular 411 expression matching MUST NOT be performed for this comparison. If 412 this default is enabled, then a mismatch MUST be treated as an error 413 and security association setup MUST be aborted. This event SHOULD be 414 auditable. Implementations MAY provide a configuration option to 415 (i.e. local policy configuration can enable) skip that verification 416 step, but that option MUST be off by default. We include the 417 "option-to-skip-validation" in order to permit better 418 interoperability, as today implementations vary greatly in how they 419 behave on this topic. 421 Implementations MAY support substring, wildcard, or regular 422 expression matching of the contents of ID to lookup policy in the 423 SPD, and such would be a matter of local security policy 424 configuration. 426 3.1.3. ID_USER_FQDN 428 Implementations MUST support the ID_USER_FQDN ID type, generally to 429 support user-based access control lists for users without fixed IP 430 addresses. However, implementations SHOULD NOT use the DNS to map 431 the FQDN portion to IP addresses for input into any policy decisions, 432 unless that mapping is known to be secure, for example if DNSSEC [12] 433 were employed for that FQDN. 435 Implementations MUST be capable of verifying that the identity 436 contained in the ID payload matches identity information contained in 437 the peer end-entity certificate, in the rfc822Name field in the 438 SubjectAltName extension. Implementations MUST perform this 439 verification by default. When comparing the contents of ID with the 440 rfc822Name field in the SubjectAltName extension for equality, 441 caseless string comparison MUST be performed. Note that caseless 442 string comparison works on internationalized domain names (IDNs) as 443 well (See IDN [13]). Substring, wildcard, or regular expression 444 matching MUST NOT be performed for this comparison. If this default 445 is enabled, then a mismatch MUST be treated as an error and security 446 association setup MUST be aborted. This event SHOULD be auditable. 447 Implementations MAY provide a configuration option to (i.e. local 448 policy configuration can enable) skip that verification step, but 449 that option MUST be off by default. We include the "option-to-skip- 450 validation" in order to permit better interoperability, as today 451 implementations vary greatly in how they behave on this topic. 453 Implementations MAY support substring, wildcard, or regular 454 expression matching of the contents of ID to lookup policy in the 455 SPD, and such would be a matter of local security policy 456 configuration. 458 3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, 459 ID_IPV6_ADDR_RANGE 461 Note that RFC 3779 [14] defines blocks of addresses using the 462 certificate extension identified by: 464 id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } 466 although use of this extension in IKE is considered experimental at 467 this time. 469 3.1.5. ID_DER_ASN1_DN 471 Implementations MUST support receiving the ID_DER_ASN1_DN ID type. 472 Implementations MUST be capable of generating this type, and the 473 decision to do so will be a matter of local security policy 474 configuration. When generating this type, implementations MUST 475 populate the contents of ID with the Subject field from the end- 476 entity certificate, and MUST do so such that a binary comparison of 477 the two will succeed. If there is not a match, this MUST be treated 478 as an error and security association setup MUST be aborted. This 479 event SHOULD be auditable. Note, if the certificate was erroneously 480 created such that the encoding of the Subject DN varies from the 481 constraints set by DER, that non-conformant DN MUST be used to 482 populate the ID payload: in other words, implementations MUST NOT re- 483 encode the DN for the purposes of making it DER if it does not appear 484 in the certificate as DER. 486 Implementations MUST NOT populate ID with the Subject from the end- 487 entity certificate if it is empty, even though an empty certificate 488 Subject is explicitly allowed in the "Subject" section of the PKIX 489 certificate profile. 491 Regarding SPD matching, implementations MUST be able to perform 492 matching based on a bitwise comparison of the entire DN in ID to its 493 entry in the SPD. However, operational experience has shown that 494 using the entire DN in local configuration is difficult, especially 495 in large scale deployments. Therefore, implementations also MUST be 496 able to perform SPD matches of any combination of one or more of the 497 C, CN, O, OU attributes within Subject DN in the ID to the same in 498 the SPD. Implementations MAY support matching using additional DN 499 attributes in any combination, although interoperability is far from 500 certain and dubious. Implementations MAY also support performing 501 substring, wildcard, or regular expression matches for any of its 502 supported DN attributes from ID, in any combination, to the SPD. 503 Such flexibility allows deployers to create one SPD entry on the 504 gateway for an entire department of a company (e.g. O=Foobar Inc., 505 OU=Engineering) while still allowing them to draw out other details 506 from the DN (e.g. CN=John Doe) for auditing purposes. All the above 507 is a matter of local implementation and local policy definition and 508 enforcement capability, not bits on the wire, but will have a great 509 impact on interoperability. 511 3.1.6. ID_DER_ASN1_GN 513 Implementations MUST NOT generate this type. 515 3.1.7. ID_KEY_ID 517 The ID_KEY_ID type used to specify pre-shared keys and thus is out of 518 scope. 520 3.1.8. Selecting an Identity from a Certificate 522 Implementations MUST support certificates that contain more than a 523 single identity, such as when the Subject field and the 524 SubjectAltName extension are both populated, or the SubjectAltName 525 extension contains multiple identities irrespective of whether the 526 Subject is empty or not. In many cases a certificate will contain an 527 identity such as an IP address in the SubjectAltName extension in 528 addition to a non-empty Subject. 530 Implementations SHOULD populate ID with whichever identity is likely 531 to be named in the peer's policy. In practice, this generally means 532 FQDN, or USER_FQDN, but this information may also be available to the 533 administrator through some out-of-band means. In the absence of such 534 out-of-band configuration information, the identity with which an 535 implementation chooses to populate the ID payload is a local matter. 537 3.1.9. Subject for DN Only 539 If an FQDN is intended to be processed as an identity for the 540 purposes ID matching, it MUST be placed in the dNSName field of the 541 SubjectAltName extension. Implementations MUST NOT populate the 542 Subject with an FQDN in place of populating the dNSName field of the 543 SubjectAltName extension. 545 While nothing prevents an FQDN, USER_FQDN, or IP address information 546 from appearing somewhere in the Subject contents, such entries MUST 547 NOT be interpreted as identity information for the purposes of 548 matching with ID or for policy lookup. 550 3.1.10. Binding Identity to Policy 552 In the presence of certificates that contain multiple identities, 553 implementations MUST select the most appropriate identity from the 554 certificate and populate the ID with that. The recipient MUST use 555 the identity sent as a first key when selecting the policy. The 556 recipient MUST also use the most specific policy from that database 557 if there are overlapping policies caused by wildcards (or the 558 implementation can de-correlate the policy database so there will not 559 be overlapping entries, or it can also forbid creation of overlapping 560 policies and leave the de-correlation process to the administrator, 561 but as this moves the problem to the administrator it is NOT 562 RECOMMENDED). 564 For example, imagine that an implementation is configured with a 565 certificate that contains both a non-empty Subject and a dNSName. 566 The sender's policy may specify which of those to use, and it 567 indicates the policy to the other end by sending that ID. If the 568 recipient has both a specific policy for the dNSName for this host 569 and generic wildcard rule for some attributes present in the Subject 570 field, it will match a different policy depending which ID is sent. 571 As the sender knows why it wanted to connect the peer, it also knows 572 what identity it should use to match the policy it needs to the 573 operation it tries to perform; it is the only party who can select 574 the ID adequately. 576 In the event the policy cannot be found in the recipient's SPD using 577 the ID sent, then the recipient MAY use the other identities in the 578 certificate when attempting to match a suitable policy. For example, 579 say the certificate contains non-empty Subject field, a dNSName and 580 an iPAddress. If an iPAddress is sent in ID but no specific entry 581 exists for the address in the policy database, the recipient MAY 582 search in the policy database based on the Subject or the dNSName 583 contained in the certificate. 585 The Peer Authorization Database (PAD) as described in RFC 4301 [10] 586 provides a more formal model for the binding of identity to policy in 587 addition to providing services that deal more specifically with the 588 details of policy enforcement, which are generally out of scope of 589 this document. The PAD is intended to provide a link between the SPD 590 and the security association management in protocols such as IKE. 591 See RFC 4301 [10], section 4.4.3 for more details. 593 3.2. Certificate Request Payload 595 The Certificate Request (CERTREQ) Payload allows an implementation to 596 request that a peer provide some set of certificates or certificate 597 revocation lists (CRLs). It is not clear from ISAKMP exactly how 598 that set should be specified or how the peer should respond. We 599 describe the semantics on both sides. 601 3.2.1. Certificate Type 603 The Certificate Type field identifies to the peer the type of 604 certificate keying materials that are desired. ISAKMP defines 10 605 types of Certificate Data that can be requested and specifies the 606 syntax for these types, and IKEv2 specifies 3 additional types. For 607 the purposes of this document, only the following types are relevant: 609 o X.509 Certificate - Signature 610 o Revocation Lists (CRL and ARL) 611 o PKCS #7 wrapped X.509 certificate 612 o IKEv2's Hash and URL of X.509 certificate 614 The use of the other types are out of the scope of this document: 616 o X.509 Certificate - Key Exchange 617 o PGP Certificate 618 o DNS Signed Key 619 o Kerberos Tokens 620 o SPKI Certificate 621 o X.509 Certificate Attribute 622 o IKEv2's Raw RSA Key 623 o IKEv2's Hash and URL of X.509 bundle 625 3.2.2. X.509 Certificate - Signature 627 This type requests that the end-entity certificate be a certificate 628 used for signing. 630 3.2.3. Revocation Lists (CRL and ARL) 632 ISAKMP and IKEv2 do not support Certificate Payload sizes over 633 approximately 64K, which is too small for many CRLs. Therefore, the 634 acquisition of revocation material is to be dealt with out-of-band of 635 IKE. For this and other reasons, implementations SHOULD NOT generate 636 CERTREQs where the Certificate Type is "Certificate Revocation List 637 (CRL)" or "Authority Revocation List (ARL)". Implementations that do 638 generate such CERTREQs MUST NOT require the recipient to respond with 639 a CRL or ARL, and MUST NOT fail when not receiving any. Upon receipt 640 of such a CERTREQ, implementations MAY ignore the request. 642 In lieu of exchanging revocation lists in-band, a pointer to 643 revocation checking SHOULD be listed in either the 644 CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA) 645 certificate extensions (see Section 4 for details). Unless other 646 methods for obtaining revocation information are available, 647 implementations SHOULD be able to process these attributes, and from 648 them be able to identify cached revocation material, or retrieve the 649 relevant revocation material from a URL, for validation processing. 650 In addition, implementations MUST have the ability to configure 651 validation checking information for each certification authority. 652 Regardless of the method (CDP, AIA, or static configuration), the 653 acquisition of revocation material SHOULD occur out-of-band of IKE. 655 3.2.4. PKCS #7 wrapped X.509 certificate 657 This ID type defines a particular encoding (not a particular 658 certificate type), some current implementations may ignore CERTREQs 659 they receive which contain this ID type, and the editors are unaware 660 of any implementations that generate such CERTREQ messages. 661 Therefore, the use of this type is deprecated. Implementations 662 SHOULD NOT require CERTREQs that contain this Certificate Type. 663 Implementations which receive CERTREQs which contain this ID type MAY 664 treat such payloads as synonymous with "X.509 Certificate - 665 Signature". 667 3.2.5. IKEv2's Hash and URL of X.509 certificate 669 This ID type defines a request for the peer to send a hash and URL of 670 its X.509 certificate, instead of the actual certificate itself. 671 This is a particularly useful mechanism when the peer is a device 672 with little memory and lower bandwidth, e.g. a mobile handset or 673 consumer electronics device. 675 If the IKEv2 implementation supports URL lookups, and prefers such a 676 URL to receiving actual certificates, then the implementation will 677 want to send a notify of type HTTP_CERT_LOOKUP_SUPPORTED. From IKEv2 678 [3], section 3.10.1, "This notification MAY be included in any 679 message that can include a CERTREQ payload and indicates that the 680 sender is capable of looking up certificates based on an HTTP-based 681 URL (and hence presumably would prefer to receive certificate 682 specifications in that format)." If an HTTP_CERT_LOOKUP_SUPPORTED 683 notification is sent the sender MUST support the http scheme. See 684 Section 3.3.4 for more discussion of HTTP_CERT_LOOKUP_SUPPORTED. 686 3.2.6. Location of Certificate Payloads 688 In IKEv1 Main Mode, the CERTREQ payload MUST be in messages 4 and 5. 689 In IKEv2, the CERTREQ payload must be in messages 2 and 3. Note that 690 in IKEv2, it is possible to have one side authenticating with 691 certificates while the other side authenticates with preshared keys. 693 3.2.7. Presence or Absence of Certificate Request Payloads 695 When in-band exchange of certificate keying materials is desired, 696 implementations MUST inform the peer of this by sending at least one 697 CERTREQ. In other words, an implementation which does not send any 698 CERTREQs during an exchange SHOULD NOT expect to receive any CERT 699 payloads. 701 3.2.8. Certificate Requests 703 3.2.8.1. Specifying Certification Authorities 705 When requesting in-band exchange of keying materials, implementations 706 SHOULD generate CERTREQs for every peer trust anchor that local 707 policy explicitly deems trusted during a given exchange. For IKEv1, 708 implementations SHOULD populate the Certification Authority field 709 with the Subject field of the trust anchor, populated such that 710 binary comparison of the Subject and the Certification Authority will 711 succeed. For IKEv2, implementations MUST populate the Certification 712 Authority field as specified in IKEv2 [3]. 714 Upon receipt of a CERTREQ, implementations MUST respond by sending at 715 least the end-entity certificate corresponding to the Certification 716 Authority listed in the CERTREQ unless local security policy 717 configuration specifies that keying materials must be exchanged out- 718 of-band. Implementations MAY send certificates other than the end- 719 entity certificate (see Section 3.3 for discussion). 721 Note, in the case where multiple end-entity certificates may be 722 available which chain to different trust anchors, implementations 723 SHOULD resort to local heuristics to determine which trust anchor is 724 most appropriate to use for generating the CERTREQ. Such heuristics 725 are out of the scope of this document. 727 3.2.8.2. Empty Certification Authority Field 729 Implementations SHOULD generate CERTREQs where the Certificate Type 730 is "X.509 Certificate - Signature" and where a the Certification 731 Authority field is not empty. However, implementations MAY generate 732 CERTREQs with an empty Certification Authority field under special 733 conditions. Although PKIX prohibits certificates with an empty 734 Issuer field, there does exist a use case where doing so is 735 appropriate, and carries special meaning in the IKE context. This 736 has become a convention within the IKE interoperability tests and 737 usage space, and so its use is specified, explained here for the sake 738 of interoperability. 740 USE CASE: Consider the rare case where you have a gateway with 741 multiple policies for a large number of IKE peers: some of these 742 peers are business partners, some are remote access employees, some 743 are teleworkers, some are branch offices, and/or the gateway may be 744 simultaneously serving many customers (e.g. Virtual Routers). The 745 total number of certificates, and corresponding trust anchors, is 746 very high, say hundreds. Each of these policies is configured with 747 one or more acceptable trust anchors, so that in total, the gateway 748 has one hundred (100) trust anchors that could possibly used to 749 authenticate an incoming connection. Assume that many of those 750 connections originate from hosts/gateways with dynamically assigned 751 IP addresses, so that the source IP of the IKE initiator is not known 752 to the gateway, nor is the identity of the initiator (until it is 753 revealed in Main Mode message 5). In IKE main mode message 4, the 754 responder gateway will need to send a CERTREQ to the initiator. 755 Given this example, the gateway will have no idea which of the 756 hundred possible Certification Authorities to send in the CERTREQ. 757 Sending all possible Certification Authorities will cause significant 758 processing delays, bandwidth consumption, and UDP fragmentation, so 759 this tactic is ruled out. 761 In such a deployment, the responder gateway implementation should be 762 able to do all it can to indicate a Certification Authority in the 763 CERTREQ. This means the responder SHOULD first check SPD to see if 764 it can match the source IP, and find some indication of which CA is 765 associated with that IP. If this fails (because the source IP is not 766 familiar, as in the case above), then the responder SHOULD have a 767 configuration option specifying which CAs are the default CAs to 768 indicate in CERTREQ during such ambiguous connections (e.g. send 769 CERTREQ with these N CAs if there is an unknown source IP). If such 770 a fall-back is not configured or impractical in a certain deployment 771 scenario, then the responder implementation SHOULD have both of the 772 following configuration options: 774 o send a CERTREQ payload with an empty Certification Authority 775 field, or 776 o terminate the negotiation with an appropriate error message and 777 audit log entry. 779 Receiving a CERTREQ payload with an empty Certification Authority 780 field indicates that the recipient should send all/any end-entity 781 certificates it has, regardless of the trust anchor. The initiator 782 should be aware of what policy and which identity it will use, as it 783 initiated the connection on a matched policy to begin with, and can 784 thus respond with the appropriate certificate. 786 If, after sending an empty CERTREQ in Main Mode message 4, a 787 responder receives a certificate in message 5 that chains to a trust 788 anchor that the responder either (a) does NOT support, or (b) was not 789 configured for the policy (that policy was now able to be matched due 790 to having the initiator's certificate present), this MUST be treated 791 as an error and security association setup MUST be aborted. This 792 event SHOULD be auditable. 794 Instead of sending a empty CERTREQ, the responder implementation MAY 795 be configured to terminate the negotiation on the grounds of a 796 conflict with locally configured security policy. 798 The decision of which to configure is a matter of local security 799 policy, this document RECOMMENDS that both options be presented to 800 administrators. 802 More examples, and explanation on this issue are included in "More on 803 Empty CERTREQs" (Appendix B). 805 3.2.9. Robustness 807 3.2.9.1. Unrecognized or Unsupported Certificate Types 809 Implementations MUST be able to deal with receiving CERTREQs with 810 unsupported Certificate Types. Absent any recognized and supported 811 CERTREQ types, implementations MAY treat them as if they are of a 812 supported type with the Certification Authority field left empty, 813 depending on local policy. ISAKMP [2] Section 5.10 "Certificate 814 Request Payload Processing" specifies additional processing. 816 3.2.9.2. Undecodable Certification Authority Fields 818 Implementations MUST be able to deal with receiving CERTREQs with 819 undecodable Certification Authority fields. Implementations MAY 820 ignore such payloads, depending on local policy. ISAKMP specifies 821 other actions which may be taken. 823 3.2.9.3. Ordering of Certificate Request Payloads 825 Implementations MUST NOT assume that CERTREQs are ordered in any way. 827 3.2.10. Optimizations 829 3.2.10.1. Duplicate Certificate Request Payloads 831 Implementations SHOULD NOT send duplicate CERTREQs during an 832 exchange. 834 3.2.10.2. Name Lowest 'Common' Certification Authorities 836 When a peer's certificate keying material has been cached, an 837 implementation can send a hint to the peer to elide some of the 838 certificates the peer would normally include in the response. In 839 addition to the normal set of CERTREQs that are sent specifying the 840 trust anchors, an implementation MAY send CERTREQs specifying the 841 relevant cached end-entity certificates. When sending these hints, 842 it is still necessary to send the normal set of trust anchor CERTREQs 843 because the hints do not sufficiently convey all of the information 844 required by the peer. Specifically, either the peer may not support 845 this optimization or there may be additional chains that could be 846 used in this context but will not be if only the end-entity 847 certificate is specified. 849 No special processing is required on the part of the recipient of 850 such a CERTREQ, and the end-entity certificates will still be sent. 851 On the other hand, the recipient MAY elect to elide certificates 852 based on receipt of such hints. 854 CERTREQs must contain information that identifies a Certification 855 Authority certificate, which results in the peer always sending at 856 least the end-entity certificate. Always sending the end-entity 857 certificate allows implementations to determine unambiguously when a 858 new certificate is being used by a peer (perhaps because the previous 859 certificate has just expired), which may result in a failure because 860 a new intermediate CA certificate might not be available to validate 861 the new end-entity certificate). Implementations which implement 862 this optimization MUST recognize when the end-entity certificate has 863 changed and respond to it by not performing this optimization if the 864 exchange must be retried so that any missing keying materials will be 865 sent during retry. 867 3.2.10.3. Example 869 Imagine that an IKEv1 implementation has previously received and 870 cached the peer certificate chain TA->CA1->CA2->EE. If during a 871 subsequent exchange this implementation sends a CERTREQ containing 872 the Subject field in certificate TA, this implementation is 873 requesting that the peer send at least 3 certificates: CA1, CA2, and 874 EE. On the other hand, if this implementation also sends a CERTREQ 875 containing the Subject field of CA2, the implementation is providing 876 a hint that only 1 certificate needs to be sent: EE. Note that in 877 this example, the fact that TA is a trust anchor should not be 878 construed to imply that TA is a self-signed certificate. 880 3.3. Certificate Payload 882 The Certificate (CERT) Payload allows the peer to transmit a single 883 certificate or CRL. Multiple certificates should be transmitted in 884 multiple payloads. For backwards compatibility reasons, 885 implementations MAY send intermediate CA certificates in addition to 886 the appropriate end-entity certificate(s), but SHOULD NOT send any 887 CRLs, ARLs, or trust anchors. Exchanging trust anchors and 888 especially CRLs and ARLs in IKE would increase the liklihood of UDP 889 fragmentation, make the IKE exchange more complex, and consume 890 additional network bandwidth. 892 Note, however, that while the sender of the CERT payloads SHOULD NOT 893 send any trust anchors, it's possible that the recipient may consider 894 any given intermediate CA certificate to be a trust anchor. For 895 instance, imagine the sender has the certificate chain TA1->CA1->EE1 896 while the recipient has the certificate chain TA2->EE2 where TA2=CA1. 897 The sender is merely including an intermediate CA certificate, while 898 the recipient receives a trust anchor. 900 However, not all certificate forms that are legal in the PKIX 901 certificate profile make sense in the context of IPsec. The issue of 902 how to represent IKE-meaningful name-forms in a certificate is 903 especially problematic. This document provides a profile for a 904 subset of the PKIX certificate profile that makes sense for IKEv1/ 905 ISAKMP and IKEv2. 907 3.3.1. Certificate Type 909 The Certificate Type field identifies to the peer the type of 910 certificate keying materials that are included. ISAKMP defines 10 911 types of Certificate Data that can be sent and specifies the syntax 912 for these types, and IKEv2 specifies 3 additional types. For the 913 purposes of this document, only the following types are relevant: 915 o X.509 Certificate - Signature 916 o Revocation Lists (CRL and ARL) 917 o PKCS #7 wrapped X.509 certificate 918 o IKEv2's Hash and URL of X.509 certificate 920 The use of the other types are out of the scope of this document: 922 o X.509 Certificate - Key Exchange 923 o PGP Certificate 924 o DNS Signed Key 925 o Kerberos Tokens 926 o SPKI Certificate 927 o X.509 Certificate Attribute 928 o IKEv2's Raw RSA Key 929 o IKEv2's Hash and URL of X.509 bundle 931 3.3.2. X.509 Certificate - Signature 933 This type specifies that Certificate Data contains a certificate used 934 for signing. 936 3.3.3. Revocation Lists (CRL and ARL) 938 These types specify that Certificate Data contains an X.509 CRL or 939 ARL. These types SHOULD NOT be sent in IKE. See Section 3.2.3 for 940 discussion. 942 3.3.4. IKEv2's Hash and URL of X.509 Certificate 944 This type specifies that Certificate Data contains a hash and the URL 945 to a repository where an X.509 certificate can be retrieved. 947 An implementation that sends a HTTP_CERT_LOOKUP_SUPPORTED 948 notification MUST support the http scheme and MAY support the ftp 949 scheme, and MUST NOT require any specific form of the url-path and it 950 SHOULD support having user-name, password and port parts in the URL. 951 The following are examples of mandatory forms: 953 o http://certs.example.com/certificate.cer 954 o http://certs.example.com/certs/cert.pl?u=foo;a=pw;valid-to=+86400 955 o http://certs.example.com/%0a/../foo/bar/zappa 957 while the following is an example of a form that SHOULD be supported: 959 o http://user:password@certs.example.com:8888/certificate.cer 961 The following is an example of the ftp scheme that MAY be supported: 963 o ftp://ftp.example.com/pub/certificate.cer 965 3.3.5. PKCS #7 wrapped X.509 certificate 967 This type defines a particular encoding, not a particular certificate 968 type. Implementations SHOULD NOT generate CERTs that contain this 969 Certificate Type. Implementations SHOULD accept CERTs that contain 970 this Certificate Type because several implementations are known to 971 generate them. Note that those implementations sometimes include 972 entire certificate hierarchies inside a single CERT PKCS #7 payload, 973 which violates the requirement specified in ISAKMP that this payload 974 contain a single certificate. 976 3.3.6. Location of Certificate Payloads 978 In IKEv1 Main Mode, the CERT payload MUST be in messages 5 and 6. In 979 IKEv2, the CERT payload MUST be in messages 3 and 4. Note that in 980 IKEv2, it is possible to have one side authenticating with 981 certificates while the other side authenticates with preshared keys. 983 3.3.7. Certificate Payloads Not Mandatory 985 An implementation which does not receive any CERTREQs during an 986 exchange SHOULD NOT send any CERT payloads, except when explicitly 987 configured to proactively send CERT payloads in order to interoperate 988 with non-compliant implementations which fail to send CERTREQs even 989 when certificates are desired. In this case, an implementation MAY 990 send the certificate chain (not including the trust anchor) 991 associated with the end-entity certificate. This MUST NOT be the 992 default behavior of implementations. 994 Implementations whose local security policy configuration expects 995 that a peer must receive certificates through out-of-band means 996 SHOULD ignore any CERTREQ messages that are received. Such a 997 condition has been known to occur due to non-compliant or buggy 998 implementations. 1000 Implementations that receive CERTREQs from a peer which contain only 1001 unrecognized Certification Authorities SHOULD NOT continue the 1002 exchange, in order to avoid unnecessary and potentially expensive 1003 cryptographic processing, denial-of-service (resource starvation) 1004 attacks. 1006 3.3.8. Response to Multiple Certification Authority Proposals 1008 In response to multiple CERTREQs which contain different 1009 Certification Authority identities, implementations MAY respond using 1010 an end-entity certificate which chains to a CA that matches any of 1011 the identities provided by the peer. 1013 3.3.9. Using Local Keying Materials 1015 Implementations MAY elect to skip parsing or otherwise decoding a 1016 given set of CERTs if equivalent keying materials are available via 1017 some preferable means, such as the case where certificates from a 1018 previous exchange have been cached. 1020 3.3.10. Multiple End-Entity Certificates 1022 Implementations SHOULD NOT send multiple end-entity certificates and 1023 recipients SHOULD NOT be expected to iterate over multiple end-entity 1024 certificates. 1026 If multiple end-entity certificates are sent, they MUST have the same 1027 public key, otherwise the responder does not know which key was used 1028 in the Main Mode message 5. 1030 3.3.11. Robustness 1032 3.3.11.1. Unrecognized or Unsupported Certificate Types 1034 Implementations MUST be able to deal with receiving CERTs with 1035 unrecognized or unsupported Certificate Types. Implementations MAY 1036 discard such payloads, depending on local policy. ISAKMP [2] Section 1037 5.10 "Certificate Request Payload Processing" specifies additional 1038 processing. 1040 3.3.11.2. Undecodable Certificate Data Fields 1042 Implementations MUST be able to deal with receiving CERTs with 1043 undecodable Certificate Data fields. Implementations MAY discard 1044 such payloads, depending on local policy. ISAKMP specifies other 1045 actions which may be taken. 1047 3.3.11.3. Ordering of Certificate Payloads 1049 For IKEv1, implementations MUST NOT assume that CERTs are ordered in 1050 any way. For IKEv2, implementations MUST NOT assume that any except 1051 the first CERT is ordered in any way. IKEv2 specifies that the first 1052 CERT contain an end-entity certificate which can be used to 1053 authenticate the peer. 1055 3.3.11.4. Duplicate Certificate Payloads 1057 Implementations MUST support receiving multiple identical CERTs 1058 during an exchange. 1060 3.3.11.5. Irrelevant Certificates 1062 Implementations MUST be prepared to receive certificates and CRLs 1063 which are not relevant to the current exchange. Implementations MAY 1064 discard such extraneous certificates and CRLs. 1066 Implementations MAY send certificates which are irrelevant to an 1067 exchange. One reason for including certificates which are irrelevant 1068 to an exchange is to minimize the threat of leaking identifying 1069 information in exchanges where CERT is not encrypted. It should be 1070 noted, however, that this probably provides rather poor protection 1071 against leaking the identity. 1073 Another reason for including certificates that seem irrelevant to an 1074 exchange is that there may be two chains from the Certification 1075 Authority to the end entity, each of which is only valid with certain 1076 validation parameters (such as acceptable policies). Since the end- 1077 entity doesn't know which parameters the relying party is using, it 1078 should send the certificates needed for both chains (even if there's 1079 only one CERTREQ). 1081 Implementations SHOULD NOT send multiple end-entity certificates and 1082 recipients SHOULD NOT be expected to iterate over multiple end-entity 1083 certificates. 1085 3.3.12. Optimizations 1087 3.3.12.1. Duplicate Certificate Payloads 1089 Implementations SHOULD NOT send duplicate CERTs during an exchange. 1090 Such payloads should be suppressed. 1092 3.3.12.2. Send Lowest 'Common' Certificates 1094 When multiple CERTREQs are received which specify certificate 1095 authorities within the end-entity certificate chain, implementations 1096 MAY send the shortest chain possible. However, implementations 1097 SHOULD always send the end-entity certificate. See Section 3.2.10.2 1098 for more discussion of this optimization. 1100 3.3.12.3. Ignore Duplicate Certificate Payloads 1102 Implementations MAY employ local means to recognize CERTs that have 1103 already been received and SHOULD discard these duplicate CERTs. 1105 3.3.12.4. Hash Payload 1107 IKEv1 specifies the optional use of the Hash Payload to carry a 1108 pointer to a certificate in either of the Phase 1 public key 1109 encryption modes. This pointer is used by an implementation to 1110 locate the end-entity certificate that contains the public key that a 1111 peer should use for encrypting payloads during the exchange. 1113 Implementations SHOULD include this payload whenever the public 1114 portion of the keypair has been placed in a certificate. 1116 4. Certificate Profile 1118 Except where specifically stated in this document, implementations 1119 MUST conform to the requirements of the PKIX [5] certificate profile. 1121 4.1. X.509 Certificates 1123 Users deploying IKE and IPsec with certificates have often had little 1124 control over the capabilities of CAs available to them. 1126 Implementations of this specification may include configuration knobs 1127 to disable checks required by this specification in order to permit 1128 use with inflexible and/or noncompliant CAs. However, all checks on 1129 certificates exist for a specific reason involving the security of 1130 the entire system. Therefore, all checks MUST be enabled by default. 1131 Administrators and users ought to understand the security purpose for 1132 the various checks, and be clear on what security will be lost by 1133 disabling the check. 1135 4.1.1. Versions 1137 Although PKIX states that "implementations SHOULD be prepared to 1138 accept any version certificate", in practice this profile requires 1139 certain extensions that necessitate the use of Version 3 certificates 1140 for all but self-signed certificates used as trust anchors. 1141 Implementations that conform to this document MAY therefore reject 1142 Version 1 and Version 2 certificates in all other cases. 1144 4.1.2. Subject 1146 Certification Authority implementations MUST be able to create 1147 certificates with Subject fields with at least the following four 1148 attributes: CN, C, O, OU. Implementations MAY support other Subject 1149 attributes as well. The contents of these attributes SHOULD be 1150 configurable on a certificate by certificate basis, as these fields 1151 will likely be used by IKE implementations to match SPD policy. 1153 See Section 3.1.5 for details on how IKE implementations need to be 1154 able to process Subject field attributes for SPD policy lookup. 1156 4.1.2.1. Empty Subject Name 1158 IKE Implementations MUST accept certificates which contain an empty 1159 Subject field, as specified in the PKIX certificate profile. 1160 Identity information in such certificates will be contained entirely 1161 in the SubjectAltName extension. 1163 4.1.2.2. Specifying Hosts and not FQDN in the Subject Name 1165 Implementations which desire to place host names that are not 1166 intended to be processed by recipients as FQDNs (for instance 1167 "Gateway Router") in the Subject MUST use the commonName attribute. 1169 4.1.2.3. EmailAddress 1171 As specified in the PKIX certificate profile, implementations MUST 1172 NOT populate X.500 distinguished names with the emailAddress 1173 attribute. 1175 4.1.3. X.509 Certificate Extensions 1177 Conforming IKE implementations MUST recognize extensions which must 1178 or may be marked critical according to this specification. These 1179 extensions are: KeyUsage, SubjectAltName, and BasicConstraints. 1181 Certification Authority implementations SHOULD generate certificates 1182 such that the extension criticality bits are set in accordance with 1183 the PKIX certifiate profile and this document. With respect to 1184 compliance with the PKIX certificate profile, IKE implementations 1185 processing certificates MAY ignore the value of the criticality bit 1186 for extensions that are supported by that implementation, but MUST 1187 support the criticality bit for extensions that are not supported by 1188 that implementation. That is, a peer processes all the extensions it 1189 is aware of whether the bit is true or false -- the bit says what 1190 happens when a peer cannot process an extension. 1192 implements bit in cert PKIX mandate behavior 1193 ------------------------------------------------------ 1194 yes true true ok 1195 yes true false ok or reject 1196 yes false true ok or reject 1197 yes false false ok 1198 no true true reject 1199 no true false reject 1200 no false true reject 1201 no false false ok 1203 4.1.3.1. AuthorityKeyIdentifier and SubjectKeyIdentifier 1205 Implementations SHOULD NOT assume support for the 1206 AuthorityKeyIdentifier or SubjectKeyIdentifier extensions, and thus 1207 Certification Authority implementations SHOULD NOT generate 1208 certificate hierarchies which are overly complex to process in the 1209 absence of these extensions, such as those that require possibly 1210 verifying a signature against a large number of similarly named CA 1211 certificates in order to find the CA certificate which contains the 1212 key that was used to generate the signature. 1214 4.1.3.2. KeyUsage 1216 IKE uses an end-entity certificate in the authentication process. 1217 The end-entity certificate may be used for multiple applications. As 1218 such, the CA can impose some constraints on the manner that a public 1219 key ought to be used. The KeyUsage (KU) and ExtendedKeyUsage (EKU) 1220 extensions apply in this situation. 1222 Since we are talking about using the public key to validate a 1223 signature, if the KeyUsage extension is present, then at least one of 1224 the digitalSignature or the nonRepudiation bits in the KeyUsage 1225 extension MUST be set (both can be set as well). It is also fine if 1226 other KeyUsage bits are set. 1228 A summary of the logic flow for peer cert validation follows: 1230 o If no KU extension, continue. 1231 o If KU present and doesn't mention digitalSignature or 1232 nonRepudiation (both, in addition to other KUs, is also fine), 1233 reject cert. 1234 o If none of the above, continue. 1236 4.1.3.3. PrivateKeyUsagePeriod 1238 The PKIX certificate profile recommends against the use of this 1239 extension. The PrivateKeyUsageExtension is intended to be used when 1240 signatures will need to be verified long past the time when 1241 signatures using the private keypair may be generated. Since IKE SAs 1242 are short-lived relative to the intended use of this extension in 1243 addition to the fact that each signature is validated only a single 1244 time, the usefulness of this extension in the context of IKE is 1245 unclear. Therefore, Certification Authority implementations MUST NOT 1246 generate certificates that contain the PrivateKeyUsagePeriod 1247 extension. If an IKE implementation receives a certificate with this 1248 set, it SHOULD ignore it. 1250 4.1.3.4. CertificatePolicies 1252 Many IKE implementations do not currently provide support for the 1253 CertificatePolicies extension. Therefore, Certification Authority 1254 implementations that generate certificates which contain this 1255 extension SHOULD NOT mark the extension as critical. 1257 4.1.3.5. PolicyMappings 1259 Many IKE implementations do not support the PolicyMappings extension. 1260 Therefore, implementations that generate certificates which contain 1261 this extension SHOULD NOT mark the extension as critical. 1263 4.1.3.6. SubjectAltName 1265 Deployments that intend to use an ID of FQDN, USER_FQDN, IPV4_ADDR, 1266 or IPV6_ADDR MUST issue certificates with the corresponding 1267 SubjectAltName fields populated with the same data. Implementations 1268 SHOULD generate only the following GeneralName choices in the 1269 SubjectAltName extension, as these choices map to legal IKEv1/ISAKMP/ 1270 IKEv2 Identification Payload types: rfc822Name, dNSName, or 1271 iPAddress. Although it is possible to specify any GeneralName choice 1272 in the Identification Payload by using the ID_DER_ASN1_GN ID type, 1273 implementations SHOULD NOT assume support for such functionality, and 1274 SHOULD NOT generate certificates that do so. 1276 4.1.3.6.1. dNSName 1278 This field MUST contain a fully qualified domain name. If the IKE ID 1279 type is FQDN then the dNSName field MUST match its contents. 1280 Implementations MUST NOT generate names that contain wildcards. 1281 Implementations MAY treat certificates that contain wildcards in this 1282 field as syntactically invalid. 1284 Although this field is in the form of an FQDN, IKE implementations 1285 SHOULD NOT assume that this field contains an FQDN that will resolve 1286 via the DNS, unless this is known by way of some out-of-band 1287 mechanism. Such a mechanism is out of the scope of this document. 1288 Implementations SHOULD NOT treat the failure to resolve as an error. 1290 4.1.3.6.2. iPAddress 1292 If the IKE ID type is IPV4_ADDR or IPV6_ADDR then the iPAddress field 1293 MUST match its contents. Note that although PKIX permits CIDR [15] 1294 notation in the "Name Constraints" extension, the PKIX certificate 1295 profile explicitly prohibits using CIDR notation for conveying 1296 identity information. In other words, the CIDR notation MUST NOT be 1297 used in the SubjectAltName extension. 1299 4.1.3.6.3. rfc822Name 1301 If the IKE ID type is USER_FQDN then the rfc822Name field MUST match 1302 its contents. Although this field is in the form of an Internet mail 1303 address, IKE implementations SHOULD NOT assume that this field 1304 contains a valid email address, unless this is known by way of some 1305 out-of-band mechanism. Such a mechanism is out of the scope of this 1306 document. 1308 4.1.3.7. IssuerAltName 1310 Certification Authority implementations SHOULD NOT assume that other 1311 implementations support the IssuerAltName extension, and especially 1312 should not assume that information contained in this extension will 1313 be displayed to end users. 1315 4.1.3.8. SubjectDirectoryAttributes 1317 The SubjectDirectoryAttributes extension is intended to convey 1318 identification attributes of the subject. IKE implementations MAY 1319 ignore this extension when it is marked non-critical, as the PKIX 1320 certificate profile mandates. 1322 4.1.3.9. BasicConstraints 1324 The PKIX certificate profile mandates that CA certificates contain 1325 this extension and that it be marked critical. IKE implementations 1326 SHOULD reject CA certificates that do not contain this extension. 1327 For backwards compatibility, implementations may accept such 1328 certificates if explicitly configured to do so, but the default for 1329 this setting MUST be to reject such certificates. 1331 4.1.3.10. NameConstraints 1333 Many IKE implementations do not support the NameConstraints 1334 extension. Since the PKIX certificate profile mandates that this 1335 extension be marked critical when present, Certification Authority 1336 implementations which are interested in maximal interoperability for 1337 IKE SHOULD NOT generate certificates which contain this extension. 1339 4.1.3.11. PolicyConstraints 1341 Many IKE implementations do not support the PolicyConstraints 1342 extension. Since the PKIX certificate profile mandates that this 1343 extension be marked critical when present, Certification Authority 1344 implementations which are interested in maximal interoperability for 1345 IKE SHOULD NOT generate certificates which contain this extension. 1347 4.1.3.12. ExtendedKeyUsage 1349 The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in 1350 certificates for use with IKE. Note that there were three IPsec 1351 related object identifiers in EKU that were assigned in 1999. The 1352 semantics of these values were never clearly defined. The use of 1353 these three EKU values in IKE/IPsec is obsolete and explicitly 1354 deprecated by this specification. CAs SHOULD NOT issue certificates 1355 for use in IKE with them. (For historical reference only, those 1356 values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp- 1357 ipsecUser.) 1359 The CA SHOULD NOT mark the EKU extension in certificates for use with 1360 IKE and one or more other applications. Nevertheless, this document 1361 defines an ExtendedKeyUsage keyPurposeID that MAY be used to limit a 1362 certificate's use: 1364 id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 } 1366 where id-kp is defined in RFC-3280 [5]. If a certificate is intended 1367 to be used with both IKE and other applications, and one of the other 1368 applications requires use of an EKU value, then such certificates 1369 MUST contain either the keyPurposeID id-kp-ipsecIKE or 1370 anyExtendedKeyUsage [5] as well as the keyPurposeID values associated 1371 with the other applications. Similarly, if a CA issues multiple 1372 otherwise-similar certificates for multiple applications including 1373 IKE, and it is intended that the IKE certificate NOT be used with 1374 another application, the IKE certificate MAY contain an EKU extension 1375 listing a keyPurposeID of id-kp-ipsecIKE to discourage its use with 1376 the other application. Recall however, EKU extensions in 1377 certificates meant for use in IKE are NOT RECOMMENDED. 1379 A summary of the logic flow for peer certificate validation regarding 1380 the EKU extension follows: 1382 o If no EKU extension, continue. 1383 o If EKU present AND contains either id-kp-ipsecIKE or 1384 anyExtendedKeyUsage, continue. 1385 o Otherwise, reject cert. 1387 4.1.3.13. CRLDistributionPoints 1389 Because this document deprecates the sending of CRLs in-band, the use 1390 of CRLDistributionPoints (CDP) becomes very important if CRLs are 1391 used for revocation checking (as opposed to say Online Certificate 1392 Status Protocol - OCSP [16]). The IPsec peer either needs to have a 1393 URL for a CRL written into its local configuration, or it needs to 1394 learn it from CDP. Therefore, Certification Authority 1395 implementations SHOULD issue certificates with a populated CDP. 1397 Failure to validate the CRLDistributionPoints/ 1398 IssuingDistributionPoint pair can result in CRL substitution where an 1399 entity knowingly substitutes a known good CRL from a different 1400 distribution point for the CRL which is supposed to be used which 1401 would show the entity as revoked. IKE implementations MUST support 1402 validating that the contents of CRLDistributionPoints match those of 1403 the IssuingDistributionPoint to prevent CRL substitution when the 1404 issuing CA is using them. At least one CA is known to default to 1405 this type of CRL use. See Section 4.2.2.5 for more information. 1407 CDPs SHOULD be "resolvable". Several non-compliant Certification 1408 Authority implementations are well known for including unresolvable 1409 CDPs like http://localhost/path_to_CRL and http:///path_to_CRL which 1410 are equivalent to failing to include the CDP extension in the 1411 certificate. 1413 See the IETF IPR web page for CRLDistributionPoints intellectual 1414 property rights (IPR) information. Note that both the 1415 CRLDistributionPoints and IssuingDistributionPoint extensions are 1416 RECOMMENDED but not REQUIRED by the PKIX certificate profile, so 1417 there is no requirement to license any IPR. 1419 4.1.3.14. InhibitAnyPolicy 1421 Many IKE implementations do not support the InhibitAnyPolicy 1422 extension. Since the PKIX certificate profile mandates that this 1423 extension be marked critical when present, Certification Authority 1424 implementations which are interested in maximal interoperability for 1425 IKE SHOULD NOT generate certificates which contain this extension. 1427 4.1.3.15. FreshestCRL 1429 IKE implementations MUST NOT assume that the FreshestCRL extension 1430 will exist in peer certificates. Note that most IKE implementations 1431 do not support delta CRLs. 1433 4.1.3.16. AuthorityInfoAccess 1435 The PKIX certificate profile defines the AuthorityInfoAccess 1436 extension, which is used to indicate "how to access CA information 1437 and services for the issuer of the certificate in which the extension 1438 appears." Because this document deprecates the sending of CRLs in- 1439 band, the use of AuthorityInfoAccess (AIA) becomes very important if 1440 OCSP [16] is to be used for revocation checking (as opposed to CRLs). 1441 The IPsec peer either needs to have a URI for the OCSP query written 1442 into its local configuration, or it needs to learn it from AIA. 1443 Therefore, implementations SHOULD support this extension, especially 1444 if OCSP will be used. 1446 4.1.3.17. SubjectInfoAccess 1448 The PKIX certificate profile defines the SubjectInfoAccess 1449 certificate extension, which is used to indicate "how to access 1450 information and services for the subject of the certificate in which 1451 the extension appears." This extension has no known use in the 1452 context of IPsec. Conformant IKE implementations SHOULD ignore this 1453 extension when present. 1455 4.2. X.509 Certificate Revocation Lists 1457 When validating certificates, IKE implementations MUST make use of 1458 certificate revocation information, and SHOULD support such 1459 revocation information in the form of CRLs, unless non-CRL revocation 1460 information is known to be the only method for transmitting this 1461 information. Deployments that intend to use CRLs for revocation 1462 SHOULD populate the CRLDistributionPoints extension. Therefore 1463 Certification Authority implementations MUST support issuing 1464 certificates with this field populated. IKE implementations MAY 1465 provide a configuration option to disable use of certain types of 1466 revocation information, but that option MUST be off by default. Such 1467 an option is often valuable in lab testing environments. 1469 4.2.1. Multiple Sources of Certificate Revocation Information 1471 IKE implementations which support multiple sources of obtaining 1472 certificate revocation information MUST act conservatively when the 1473 information provided by these sources is inconsistent: when a 1474 certificate is reported as revoked by one trusted source, the 1475 certificate MUST be considered revoked. 1477 4.2.2. X.509 Certificate Revocation List Extensions 1479 4.2.2.1. AuthorityKeyIdentifier 1481 Certification Authority implementations SHOULD NOT assume that IKE 1482 implementations support the AuthorityKeyIdentifier extension, and 1483 thus SHOULD NOT generate certificate hierarchies which are overly 1484 complex to process in the absence of this extension, such as those 1485 that require possibly verifying a signature against a large number of 1486 similarly named CA certificates in order to find the CA certificate 1487 which contains the key that was used to generate the signature. 1489 4.2.2.2. IssuerAltName 1491 Certification Authority implementations SHOULD NOT assume that IKE 1492 implementations support the IssuerAltName extension, and especially 1493 should not assume that information contained in this extension will 1494 be displayed to end users. 1496 4.2.2.3. CRLNumber 1498 As stated in the PKIX certificate profile, all issuers MUST include 1499 this extension in all CRLs. 1501 4.2.2.4. DeltaCRLIndicator 1503 4.2.2.4.1. If Delta CRLs Are Unsupported 1505 IKE implementations that do not support delta CRLs MUST reject CRLs 1506 which contain the DeltaCRLIndicator (which MUST be marked critical 1507 according to the PKIX certficate profile) and MUST make use of a base 1508 CRL if it is available. Such implementations MUST ensure that a 1509 delta CRL does not "overwrite" a base CRL, for instance in the keying 1510 material database. 1512 4.2.2.4.2. Delta CRL Recommendations 1514 Since some IKE implementations that do not support delta CRLs may 1515 behave incorrectly or insecurely when presented with delta CRLs, 1516 administrators and deployers should consider whether issuing delta 1517 CRLs increases security before issuing such CRLs. And, if all the 1518 elements in the VPN and PKI systems do not adequately support Delta 1519 CRLs, then their use should be questioned. 1521 The editors are aware of several implementations which behave in an 1522 incorrect or insecure manner when presented with delta CRLs. See 1523 Appendix A for a description of the issue. Therefore, this 1524 specification RECOMMENDS NOT issuing delta CRLs at this time. On the 1525 other hand, failure to issue delta CRLs may expose a larger window of 1526 vulnerability if a full CRL is not issued as often as delta CRLs 1527 would be. See the Security Considerations section of the PKIX [5] 1528 certificate profile for additional discussion. Implementors as well 1529 as administrators are encouraged to consider these issues. 1531 4.2.2.5. IssuingDistributionPoint 1533 A CA that is using CRLDistributionPoints may do so to provide many 1534 "small" CRLs, each only valid for a particular set of certificates 1535 issued by that CA. To associate a CRL with a certificate, the CA 1536 places the CRLDistributionPoints extension in the certificate, and 1537 places the IssuingDistributionPoint in the CRL. The 1538 distributionPointName field in the CRLDistributionPoints extension 1539 MUST be identical to the distributionPoint field in the 1540 IssuingDistributionPoint extension. At least one CA is known to 1541 default to this type of CRL use. See Section 4.1.3.13 for more 1542 information. 1544 4.2.2.6. FreshestCRL 1546 Given the recommendations against Certification Authority 1547 implementations generating delta CRLs, this specification RECOMMENDS 1548 that implementations do not populate CRLs with the FreshestCRL 1549 extension, which is used to obtain delta CRLs. 1551 4.3. Strength of Signature Hashing Algorithms 1553 At the time that this document is being written, popular 1554 certification authorities and CA software issue certificates using 1555 the RSA-with-SHA1 and RSA-with-MD5 signature algorithms. 1556 Implementations MUST be able to validate certificates with either of 1557 those algorithms. 1559 As described in [17], both the MD5 and SHA-1 hash algorithms are 1560 weaker than originally expected with respect to hash collisions. 1561 Certificates that use these hash algorithms as part of their 1562 signature algorithms could conceivably be subject to an attack where 1563 a CA issues a certificate with a particular identity, and the 1564 recipient of that certificate can create a different valid 1565 certificate with a different identity. So far, such an attack is 1566 only theoretical, even with the weaknesses found in the hash 1567 algorithms. 1569 Because of the recent attacks, there has been a heightened interest 1570 in having widespread deployment of additional signature algorithms. 1571 The algorithm that has been mentioned most often is RSA-with-SHA256, 1572 two types of which are described in detail in [18]. It is widely 1573 expected that this signature algorithm will be much more resilient to 1574 collision-based attacks than the current RSA-with-SHA1 and RSA-with- 1575 MD5, although no proof of that has been shown. There is active 1576 discussion in the cryptographic community of better hash functions 1577 that could be used in signature algorithms. 1579 In order to interoperate, all implementations need to be able to 1580 validate signatures for all algorithms that the implementations will 1581 encounter. Therefore, implementations SHOULD be able to use 1582 signatures that use the sha256WithRSAEncryption signature algorithm 1583 (PKCS#1 version 1.5) as soon as possible. At the time that this 1584 document is being written, there is at least one CA that supports 1585 generating certificates with sha256WithRSAEncryption signature 1586 algorithm and it is expected that there will be significant 1587 deployment of this algorithm by the end of 2007. 1589 5. Configuration Data Exchange Conventions 1591 Below we present a common format for exchanging configuration data. 1592 Implementations MUST support these formats, MUST support receiving 1593 arbitrary whitespace at the beginning and end of any line, MUST 1594 support receiving arbitrary line lengths although they SHOULD 1595 generate lines less than 76 characters, and MUST support receiving 1596 the following three line-termination disciplines: LF (US-ASCII 10), 1597 CR (US-ASCII 13), and CRLF. 1599 5.1. Certificates 1601 Certificates MUST be Base64 [19] encoded and appear between the 1602 following delimiters: 1604 -----BEGIN CERTIFICATE----- 1605 -----END CERTIFICATE----- 1607 5.2. CRLs and ARLs 1609 CRLs and ARLs MUST be Base64 encoded and appear between the following 1610 delimiters: 1612 -----BEGIN CRL----- 1613 -----END CRL----- 1615 5.3. Public Keys 1617 IKE implementations MUST support two forms of public keys: 1618 certificates and so-called "raw" keys. Certificates should be 1619 transferred in the same form as Section 5.1. A raw key is only the 1620 SubjectPublicKeyInfo portion of the certificate, and MUST be Base64 1621 encoded and appear between the following delimiters: 1623 -----BEGIN PUBLIC KEY----- 1624 -----END PUBLIC KEY----- 1626 5.4. PKCS#10 Certificate Signing Requests 1628 A PKCS#10 [9] Certificate Signing Request MUST be Base64 encoded and 1629 appear between the following delimiters: 1631 -----BEGIN CERTIFICATE REQUEST----- 1632 -----END CERTIFICATE REQUEST----- 1634 6. Acknowledgements 1636 The authors would like to acknowledge the expired draft-ietf-ipsec- 1637 pki-req-05.txt for providing valuable materials for this document. 1639 The authors would like to especially thank Eric Rescorla, one of its 1640 original authors, in addition to Greg Carter, Steve Hanna, Russ 1641 Housley, Charlie Kaufman, Tero Kivinen, Pekka Savola, Paul Hoffman, 1642 and Gregory Lebovitz for their valuable comments, some of which have 1643 been incorporated verbatim into this document. Paul Knight performed 1644 the arduous tasks of coverting the text to XML format. 1646 7. Security Considerations 1647 7.1. Certificate Request Payload 1649 The Contents of CERTREQ are not encrypted in IKE. In some 1650 environments this may leak private information. Administrators in 1651 some environments may wish to use the empty Certification Authority 1652 option to prevent such information from leaking, at the cost of 1653 performance. 1655 7.2. IKEv1 Main Mode 1657 Certificates may be included in any message, and therefore 1658 implementations may wish to respond with CERTs in a message that 1659 offers privacy protection, in Main Mode messages 5 and 6. 1660 Implementations may not wish to respond with CERTs in the second 1661 message, thereby violating the identity protection feature of Main 1662 Mode in IKEv1. 1664 7.3. Disabling Certificate Checks 1666 It is important to note that anywhere this document suggests 1667 implementors provide users with the configuration option to simplify, 1668 modify, or disable a feature or verification step, there may be 1669 security consequences for doing so. Deployment experience has shown 1670 that such flexibility may be required in some environments, but 1671 making use of such flexibility can be inappropriate in others. Such 1672 configuration options MUST default to "enabled" and it is appropriate 1673 to provide warnings to users when disabling such features. 1675 8. IANA Considerations 1677 There are no known numbers which IANA will need to manage. 1679 9. References 1681 9.1. Normative References 1683 [1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1684 RFC 2409, November 1998. 1686 [2] Maughan, D., Schneider, M., and M. Schertler, "Internet Security 1687 Association and Key Management Protocol (ISAKMP)", RFC 2408, 1688 November 1998. 1690 [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 1691 December 2005. 1693 [4] Kent, S. and R. Atkinson, "Security Architecture for the 1694 Internet Protocol", RFC 2401, November 1998. 1696 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1697 Public Key Infrastructure Certificate and Certificate Revocation 1698 List (CRL) Profile", RFC 3280, April 2002. 1700 [6] Piper, D., "The Internet IP Security Domain of Interpretation 1701 for ISAKMP", RFC 2407, November 1998. 1703 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1704 Levels", BCP 14, RFC 2119, March 1997. 1706 [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 1708 [9] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1709 1.5", RFC 2314, March 1998. 1711 9.2. Informative References 1713 [10] Kent, S. and K. Seo, "Security Architecture for the Internet 1714 Protocol", RFC 4301, December 2005. 1716 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1717 Specification", RFC 2460, December 1998. 1719 [12] Eastlake, D., "Domain Name System Security Extensions", 1720 RFC 2535, March 1999. 1722 [13] Faltstrom, P., Hoffman, P., and A. Costello, 1723 "Internationalizing Domain Names in Applications (IDNA)", 1724 RFC 3490, March 2003. 1726 [14] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1727 Addresses and AS Identifiers", RFC 3779, June 2004. 1729 [15] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- 1730 Domain Routing (CIDR): an Address Assignment and Aggregation 1731 Strategy", RFC 1519, September 1993. 1733 [16] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, 1734 "X.509 Internet Public Key Infrastructure Online Certificate 1735 Status Protocol - OCSP", RFC 2560, June 1999. 1737 [17] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes 1738 in Internet Protocols", RFC 4270, November 2005. 1740 [18] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms 1741 and Identifiers for RSA Cryptography for use in the Internet 1742 X.509 Public Key Infrastructure Certificate and Certificate 1743 Revocation List (CRL) Profile", RFC 4055, June 2005. 1745 [19] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 1746 RFC 3548, July 2003. 1748 [20] Y Lim and D. Singer, "MIME Type Registration for MPEG-4", 1749 RFC 4337, March 2006. 1751 Appendix A. The Possible Dangers of Delta CRLs 1753 The problem is that the CRL processing algorithm is sometimes written 1754 incorrectly with the assumption that all CRLs are base CRLs and it is 1755 assumed that CRLs will pass content validity tests. Specifically, 1756 such implementations fail to check the certificate against all 1757 possible CRLs: if the first CRL that is obtained from the keying 1758 material database fails to decode, no further revocation checks are 1759 performed for the relevant certificate. This problem is compounded 1760 by the fact that implementations which do not understand delta CRLs 1761 may fail to decode such CRLs due to the critical DeltaCRLIndicator 1762 extension. The algorithm that is implemented in this case is 1763 approximately: 1765 o fetch newest CRL 1766 o check validity of CRL signature 1767 o if CRL signature is valid then 1768 o if CRL does not contain unrecognized critical extensions and 1769 certificate is on CRL then set certificate status to revoked 1771 The authors note that a number of PKI toolkits do not even provide a 1772 method for obtaining anything but the newest CRL, which in the 1773 presence of delta CRLs may in fact be a delta CRL, not a base CRL. 1775 Note that the above algorithm is dangerous in many ways. See the 1776 PKIX [5] certificate profile for the correct algorithm. 1778 Appendix B. More on Empty CERTREQs 1780 Sending empty certificate requests is commonly used in 1781 implementations, and in the IPsec interop meetings, vendors have 1782 generally agreed that it means that send all/any end-entity 1783 certificates you have (if multiple end-entity certificates are sent, 1784 they must have same public key, as otherwise the other end does not 1785 know which key was used). For 99% of cases the client have exactly 1786 one certificate and public key, so it really doesn't matter, but the 1787 server might have multiple, thus it simply needs to say to the 1788 client, use any certificate you have. If we are talking about 1789 corporate vpns etc, even if the client have multiple certificates or 1790 keys, all of them would be usable when authenticating to the server, 1791 so client can simply pick one. 1793 If there is some real difference on which certificate to use (like 1794 ones giving different permissions), then the client must be 1795 configured anyways, or it might even ask the user which one to use 1796 (the user is the only one who knows whether he needs admin 1797 privileges, thus needs to use admin cert, or is the normal email 1798 privileges ok, thus using email only cert). 1800 99% of the cases the client have exactly one certificate, so it will 1801 send it. In 90% of the rest of the cases, any of the certificates is 1802 ok, as they are simply different certificates from same CA, or 1803 different CAs for the same corporate VPN, thus any of them is ok. 1805 Sending empty certificate requests has been agreed there to mean 1806 "give me your cert; any cert". 1808 Justification: 1810 o Responder first does all it can to send a CERTREQ with a CA, check 1811 for IP match in SPD, have a default set of CAs to use in ambiguous 1812 cases, etc. 1813 o sending empty CERTREQs is fairly common in implementations today, 1814 and is generally accepted to mean "send me a certificate, any 1815 certificate that works for you" 1816 o saves responder sending potentially 100's of certs, the 1817 fragmentation problems that follow, etc. 1818 o in +90% of use cases, Initiators have exactly 1 certificate 1819 o in +90% of the remaining use cases, the multiple certificates it 1820 has are issued by the same CA 1821 o in the remaining use case(s) -- if not all the others above -- the 1822 Initiator will be configured explicitly with which certificate to 1823 send, so responding to an empty CERTREQ is easy. 1825 The following example shows why initiators need to have sufficient 1826 policy definition to know which certificate to use for a given 1827 connection it initiates. 1829 EXAMPLE: Your client (initiator) is configured with VPN policies for 1830 gateways A and B (representing perhaps corporate partners). 1832 The policies for the two gateways look something like: 1834 Acme Company policy (gateway A) 1835 Engineering can access 10.1.1.0 1836 Trusted CA: CA-A, Trusted Users: OU=Engineering 1837 Partners can access 20.1.1.0 1838 Trusted CA: CA-B, Trusted Users: OU=AcmePartners 1840 Bizco Company policy (gateway B) 1841 Sales can access 30.1.1.0 1842 Trusted CA: CA-C, Trusted Users: OU=Sales 1843 Partners can access 40.1.1.0 1844 Trusted CA: CA-B, Trusted Users: OU=BizcoPartners 1846 You are an employee of Acme and you are issued the following 1847 certificates: 1849 o From CA-A: CN=JoeUser,OU=Engineering 1850 o From CA-B: CN=JoePartner,OU=BizcoPartners 1852 The client MUST be configured locally to know which CA to use when 1853 connecting to either gateway. If your client is not configured to 1854 know the local credential to use for the remote gateway, this 1855 scenario will not work either. If you attempt to connect to Bizco, 1856 everything will work... as you are presented with responding with a 1857 certificate signed by CA-B or CA-C... as you only have a certificate 1858 from CA-B you are OK. If you attempt to connect to Acme, you have an 1859 issue because you are presented with an ambiguous policy selection. 1860 As the initiator, you will be presented with certificate requests 1861 from both CA A and CA B. You have certificates issued by both CAs, 1862 but only one of the certificates will be usable. How does the client 1863 know which certificate it should present? It must have sufficiently 1864 clear local policy specifying which one credential to present for the 1865 connection it initiates. 1867 Appendix C. Change History 1869 [RFC Editor, please remove Change History prior to publication as an 1870 RFC] 1872 April 2006 (-10) 1873 * Many places - s/PKIX/the PKIX certificate profile/ (Russ 1874 Housley, AD Review) 1875 * 1 - removed text describing discussion of the document on 1876 pki4ipsec@icsalabs.com mailing list (Russ Housley, AD Review) 1877 * 3.1 - Better wording: "The Identification (ID) Payload 1878 indicates the identity claimed by the sender." (Russ Housley, 1879 AD Review) 1880 * Many places - s/2401bis/RFC 4301/ (Russ Housley, AD Review) 1881 * 3.1 - s/attribute/extension/ when talking about SubjectAltName 1882 (Russ Housley, AD Review) 1883 * 3.1 - s/attribute/value/ when talking about strings in 1884 certificates (Russ Housley, AD Review) 1885 * 3.1.2/3.1.3 - IDN is ok caseless comparison (Russ Housley, AD 1886 Review) 1887 * 3.1.4 - Change ref from SBGP to RFC 3779 (Russ Housley, AD 1888 Review) 1889 * Many places - s/SubjectName/Subject/ (Russ Housley, AD Review) 1890 * 3.2 - add "(CRLs)" (Russ Housley, AD Review) 1891 * 3.2.1 - improved wording (Russ Housley, AD Review) 1892 * 3.2.8.2 - s/empty IssuerName fields/an empty Issuer field/ 1893 (Russ Housley, AD Review) 1894 * 3.2.10.2 - s/keying materials have been/keying material has 1895 been/ (Russ Housley, AD Review) 1896 * 3.2.10.2 - s/respond with/include in the response/ (Russ 1897 Housley, AD Review) 1898 * 3.2.10.3 - s/SubjectName of CA2/CA2's Subject name/ (Russ 1899 Housley, AD Review) 1900 * 3.3 - improved wording (Russ Housley, AD Review) 1901 * 3.3.4 - changed ".crt" extension to ".cer" (for alignment with 1902 RFC 2585) (Russ Housley, AD Review) 1903 * 3.3.6 - made inconsitent musts both MUST (Russ Housley, AD 1904 Review) 1905 * 3.3.7 - s/denial of service/denial-of-service/ (Russ Housley, 1906 AD Review) 1907 * 4.1.2.3 - s/DistinguishedNames/X.500 distinguished names/ (Russ 1908 Housley, AD Review) 1909 * 4.1.3 - s/PKIX compliance/the PKIX certificate profile 1910 compliance/ (Russ Housley, AD Review) 1911 * 4.1.3 - s/PKIX and/the PKIX certificate profile and/ (Russ 1912 Housley, AD Review) 1913 * 4.1.3 - "Perhaps "peer" instead of "relyong party" should be 1914 used to match the rest of the document." (Russ Housley, AD 1915 Review) 1916 * 4.1.3.13 - s/PKIX docs/the IETF IPR web page/ (Russ Housley, AD 1917 Review) 1918 * 4.2 - removed ambiguous "according to administrator's needs" 1919 (Russ Housley, AD Review) 1921 * 4.2.2.3 - s/conforming to PKIX// (Russ Housley, AD Review) 1922 * 4.3 - at least 1 CA issues sha256WithRSAEncryption (Russ 1923 Housley, AD Review) 1924 * 5.1 - added reference for base64 (RFC3548) (Russ Housley, AD 1925 Review) 1926 * s/[3]/[RFC 4306]/ (Russ Housley, AD Review) 1927 * s/[10]/[RFC 4301]/ (Russ Housley, AD Review) 1928 * s/[13]/[RFC 3779]/ (Russ Housley, AD Review) 1929 * Moved CHANGE HISTORY to the end of the document (Russ Housley, 1930 AD Review) 1931 * 3.3.7 - point out strange case has been known to occur due to 1932 bugs (March 26, 2006 pki4ipsec from Pekka Savola) 1933 * 3.1.2/3.1.3 - make the example clearer that DNSSEC must be used 1934 for the dereference (March 26, 2006 pki4ipsec from Pekka 1935 Savola) 1936 * 3.2.5 - point out that going to IKE doc is for discussion of 1937 HTTP_CERT_LOOKUP_SUPPORTED (March 26, 2006 pki4ipsec from Pekka 1938 Savola) 1939 * 3.1 - added GN type to table (MUST NOT) (March 26, 2006 1940 pki4ipsec from Pekka Savola) 1941 * 3.1 - reordered table to match section order (March 26, 2006 1942 pki4ipsec from Pekka Savola) 1943 * Fixed HTTP_LOOKUP_SUPPORTED to be HTTP_CERT_LOOKUP_SUPPORTED 1944 (March 26, 2006 pki4ipsec from Pekka Savola) 1946 February 2006 (-09) 1948 * 3.2.6/3.3.6 - clarified text, that it applies to Main Mode only 1949 (text was updated in -08 3.3.6, not 3.2.6, but needed to be 1950 fixed in both places) but not here) 1951 * Moved text from security considerations regarding SHA-256 1953 February 2006 (-08) 1955 * 3.2.6 - clarified text, that it applies to Main Mode only 1956 * Added text to security considerations regarding SHA-256 (30 Jan 1957 2005 pki4ipsec email from Paul Hoffman) 1959 November 2005 (-07) 1961 * 3.1 - renumbered table notes to avoid confusion with references 1962 (9 Nov 2005 pki4ipsec email from Jim Schaad) 1963 * 3.2.2 - changed "signing certificate" to "a certificate used 1964 for signing" (9 Nov 2005 pki4ipsec email from Jim Schaad) 1966 * 4.1 - added text re: implications of disabling checks ("escape 1967 clause") (8 Nov 2005 pki4ipsec email from Bill Sommerfeld, 10 1968 Nov 2005 pki4ipsec email from Gregory M Lebovitz) 1969 * 4.1.3.2 - removed text from pseudocode: "If told (by 1970 configuration) to ignore KeyUsage (KU), accept certificate 1971 regardless of its markings." 1972 * 4.1.3.12 - replaced text with clearer text (8 Nov 2005 1973 pki4ipsec email from Bill Sommerfeld) 1974 * 4.1.3.12 - removed text from pseudocode: "If told (by 1975 configuration) to ignore ExtendedKeyUsage (EKU), accept cert 1976 regardless of the presence or absence of the extension." 1977 * 4.1.3.17 - removed gratuitous "private" modifier from 1978 SubjectInfoAccess section (9 Nov 2005 pki4ipsec email from Jim 1979 Schaad) 1980 * 4.2.2.4.2 - clarified delta CRL text so that it no longer could 1981 be read as implying that full CRLs can't be issued at the time 1982 a certificate is revoked. (9 Nov 2005 pki4ipsec email from Jim 1983 Schaad) 1984 * Security Considerations - added "Disabling Certificate Checks" 1985 section 1987 October 2005 (-06) 1989 * 4.1.3.12 - added text re: id-kp-ipsecIKE 1991 July 2005 (-05) 1993 * 3.1 - added "See 2401bis, section 4.4.3.2 for more details." to 1994 resolve issue #561. 1995 * 3.1.10 - added text pointing to PAD in 2401bis to discussion of 1996 binding identity to policy. 1998 December 2004 (-04) 2000 * Added Paul Hoffman's text from issue #708 2001 * Added text explaining that it's possible for a recipient to 2002 receive CERT payloads containing certs that the recipient 2003 considers a trust anchor (15 Nov 2004 pki4ipsec email from 2004 Peter Williams) 2005 * Replaced text in 4.1.3 with Kent's text (issue #655) (22 Nov 2006 2004 pki4ipsec email from Stephen Kent, Paul Hoffman) 2008 September 2004 (-03) 2010 * Minor editorial changes in abstract and introduction clarifing 2011 when something is from IPsec, IKE, etc 2012 * Minor editorial changes throughout 2013 * Fixed "Certification Authority" instead of "Certificate 2014 Authority" 2015 * Cleaned up initiator/responder when really referred to sender/ 2016 recipient 2017 * Fixed inconsistancy in text by making sure that all text on the 2018 topic of sending CERTREQs follow Gregory Lebovitz's proposal 2019 for CERT payloads: "should deal with all the CRL, Intermediat 2020 Certs, Trust Anchors, etc OOB of IKE; MUST be able to send and 2021 receive EE cert payload; only real exception is Intermediate 2022 Cets which MAY be sent and SHOULD be able to be receivable (but 2023 in reality there are very few hierarchies in operation, so 2024 really it's a corner case); SHOULD NOT send the other stuff 2025 (CRL, Trust Anchors, etc) in cert payloads in IKE; SHOULD be 2026 able to accept the other stuff if by chance it gets sent, 2027 though we hope they don't get sent" 2028 * 3.1 - removed text suggesting that it would be reasonable to 2029 terminate IKEv2 processing if the initiator were to receive a 2030 responder-generated IDr 2031 * 3.1.1 - noted that certificates may contain multiple IP 2032 addresses 2033 * 3.1.9 - removed (temporarily?) confusing text stating that 2034 overlapping policies was prohibited, text which was 2035 inconsistent with text right above it 2036 * 3.2.7.2 - SHOULD changed to MUST terminate if peer's 2037 certificate chain violates local policy 2038 * 3.3 - removed text implying that pausing in the middle of an 2039 IKE exchange in order to obtain revocation status information 2040 via http or OCSP would reduce latency in IKE 2041 * 4.2 - allow deployments that don't wish to populate CDP (for 2042 instance if a source of revocation information is configured 2043 via some other means) to skip populating CDP, making consistent 2044 with 4.1.3.13 and the issues IPR spelled out in PKIX 2045 * Somehow a CRL out-of-band configuration format had been 2046 omitted. 2047 * #555: Kent-1.0 Introduction - document now references IKEv2 2048 * #559: Kent-Profile Document 3.1.0 - use sender/recipient 2049 instead of agent 2050 * #564: Kent-Profile Document 3.1.1 - specified that support for 2051 ID_IPV4_ADDR and/or ID_IPV6_ADDR are contingent on device 2052 support for IPv4 and/or IPv6 2053 * #568: Kent-Profile document 3.1.4 - specified that there wasn't 2054 a standard and besides no one has implemented it 2056 * #571: Kent-Profile document 3.1.8 - tried to be even more 2057 clearer than was asked for by spelling things out in detail 2058 * #572: Kent-Profile document 3.1.8 Formerly issue #18 - now 2059 specifies that it's only a local matter if that information is 2060 not coordinated with other administrators 2061 * #573: Kent-Profile document 3.2.3/Myers - revocation 2062 information no longer exchanged in-band, plus Mike Myers has 2063 submitted an OCSP w/IKE draft, which is references by this 2064 document. 2065 * #578 Kent-Profile document 4.0.0 - went through entire PKIX 2066 profile section and prefaced "implementation" with "IKE" or 2067 "Certification Authority" wherever it was sure to be one or the 2068 other 2069 * #581: Kent-Profile document 4.1.3.9 - replaced description with 2070 text from RFC 2459 2071 * #584: Maillist-Lebovitz PKI Life Cycle-Revocation - fixed 2072 * #586: Maillist-Allison Empty CertReq - there is now lots of 2073 text dealing with when empty certreqs are permitted 2074 * 3.2.7.1 - CERTREQ only mandatory if in-band exchange of keymat 2075 is desired (28 Jul 2004 pki4ipsec email from jknowles@ 2076 SonicWALL.com) 2077 * 3.3.6 - clarified that "non-compliant" means not sending a 2078 CERTREQ (28 Jul 2004 pki4ipsec email from jknowles@ 2079 SonicWALL.com) 2080 * 3.2.7.1 - fixed contradition: mandatory to respond to CERTREQ 2081 UNLESS configured not to (28 Jul 2004 pki4ipsec email from 2082 jknowles@SonicWALL.com) 2083 * 3.2.9.2 and 3.2.9.3 - CERTREQ contains an issuer name only for 2084 IKEv2 (19 Sep 2004 email from Charlie Kaufman) 2085 * Answered 'Section 3.1.9 para 2: "The initiator MUST know by 2086 policy..." is a difficult to interpret requirement. It could 2087 mean that it must be possible to configure in policy which ID 2088 is to be sent. Did you mean "the initiator must decide...", 2089 where the decision might be wired into a particular 2090 implementation?' by changing it to be merely descriptive, and 2091 to refer to policy configuration (19 Sep 2004 email from 2092 Charlie Kaufman) 2093 * IPSEC -> IPsec (19 Sep 2004 email from Charlie Kaufman) 2094 * 3.1.1 para 1: "MUST be stored" changed to "MUST be encoded" (19 2095 Sep 2004 email from Charlie Kaufman) 2096 * 3.1.5 para 2 - made it clear that empty SubjectNames are 2097 permitted by PKIX in certificates, but this document doesn't 2098 permit them in ID (19 Sep 2004 email from Charlie Kaufman) 2099 * 3.2.7.1 - clarified by specifying that it's a trust anchor 2100 that's being chosen, not end-entity certificate (19 Sep 2004 2101 email from Charlie Kaufman) 2103 * 3.3.9.5 - fixed confusing last paragraph (19 Sep 2004 email 2104 from Charlie Kaufman) 2105 * 3.3.10.3 - made it more clear that this section is really 2106 talking about duplicate certificate payloads (19 Sep 2004 email 2107 from Charlie Kaufman) 2108 * 4.1.2.2 para 2 and 3 - moved to 3.1.x section where is belongs 2109 (19 Sep 2004 email from Charlie Kaufman) 2110 * 4.1.3.5 - the last sentence of 4.1.3.4 copied here (19 Sep 2004 2111 email from Charlie Kaufman) 2112 * 4.2.2.4.2 - SHOULD -> should (19 Sep 2004 email from Charlie 2113 Kaufman) 2114 * 3.2.5 and 3.3.4 - added description of URL scheme support (16 2115 Aug 2004 pki4ipsec email from Tero Kivinen) 2116 * Removed 6.1 and 6.3 because they were either incorrect or 2117 didn't add any new security considerations above and beyond the 2118 IKE documents. 2119 August 2004 (-02) (Edited by Gregory Lebovitz, with XML formatting 2120 and cross-referencing by Paul Knight) 2122 * 3.1.1 the text between the **s was added to paragraph, per the 2123 question that arose in IETF60 WG session: Implementations MUST 2124 be capable of verifying that the address contained in the ID is 2125 the same as the peer source address **contained in the outer 2126 most IP header**. 2127 * 3.2.7 - added HTTP_CERT_LOOKUP_SUPPORTED to this section and 2128 described its use - #38 2129 * 3.3 - changed back sending of intermediate CA certificates from 2130 SHOULD NOT to MAY (for backward compatibility). Added text to 2131 explain further why we want to stay away from actually doing it 2132 though. 2133 * 3.3.8 - changed text per Knowles/Korver 2004.07.28. 2134 * 3.3.9.5 - Change discard of Irrelevant Certificates from may to 2135 SHOULD - #23(Kent 2004.04.26) 2136 * 4.1.3.2 KU - re-worked to reflect discussion on list and in 2137 IETF60 - #36 2138 * 4.1.3.12 EKU - re-worked to reflect discussion on list and in 2139 IETF60 - #36 2140 * [IKEv2] update the reference to the -14 draft of May 29, 2004 2142 July 2004 (-01) (Edited by Gregory Lebovitz) 2144 * Changed ISAKMP references in Abstract and Intro to IKE. 2145 * Editorial changes to make the text conform with the summary 2146 table in 3.1, especially in the text following the table in 2147 3.1. Particular note should be paid to changes in section 2148 3.5.1. 2150 * Sect 3.1.1 - editorial changes to aid in clarification. Added 2151 text on when deployers might consider using IP addr, but 2152 strongly encouraged not to. 2153 * Sect 3.1.8 removed IP address from list of practically used ID 2154 types. 2155 * 3.1.9 overhauled (per Kivinen, July 18) 2156 * 3.2 - added IKEv2's Hash and URL of x.509 to list of those 2157 profiled and gave it its own section, now 3.2.5 2158 * added note in CRL/ARL section about revocation occurring OOB of 2159 IKE 2160 * deleted ARL as its own section and collapsed it into Revocation 2161 Lists (CRL and ARL) for consciseness. Renumbered accordingly. 2162 * Sect 3.2.7.2 - Changed from MUST not send empty certreqs to 2163 SHOULD send CERTREQs which contain CA fields with direction on 2164 how, but MAY send empty CERTREQs in certain case. Use case 2165 added, and specifics of both initiator and responder behavior 2166 listed. 2167 * APPENDIX C added to fill out the explanation (mostly discussion 2168 from list). 2169 * 3.3 - clarified that sending CRLs and chaining certs is 2170 deprecated. 2171 * added IKEv2's Hash and URL of x.509 to list of those profiled 2172 and gave it its own section. Condensed ARL into CRL and 2173 renumbered accordingly. 2174 * duplicate section was removed, renumbered accordingly 2175 * 3.3.10.2 - title changed. sending chaining becomes SHOULD NOT. 2176 * 4.1.2 added text to explicity call out support for CN, C, O, OU 2177 * collapsed 4.1.2.3 into 4.1.2.2 and renumbered accordingly. 2178 * Collapsed 4.1.3.2 into 4.1.3.1 and renumbered accordingly 2179 * Edited 4.1.3.2 Key Usage and 4.1.3.12 ExtKey Usage according to 2180 Hoffman, July18 2181 * 4.1.3.3 if receive cert w/ PKUP, ignore it. 2182 * 4.1.3.13 - CDP changed text to represent SHOULD issue, and how 2183 important CDP becomes when we do not send CRLs in-band. Added 2184 SHOULD for CDPs actually being resolvable (reilly email). 2185 * Reordered 6.4 for better clarity. 2186 * Added Rescorla to Acknowledgements section, as he is no longer 2187 listed as an editor, since -00. 2189 May 2004 (renamed draft-ietf-pki4ipsec-ikecert-profile-00.txt) 2190 (edited by Brian Korver) 2192 * Made it clearer that the format of the ID_IPV4_ADDR payload 2193 comes from RFC791 and is nothing new. (Tero Kivinen Feb 29) 2194 * Permit implementations to skip verifying that the peer source 2195 address matches the contents of ID_IPV{4,6}_ADDR. (Tero 2196 Kivinen Feb 29, Gregory Lebovitz Feb 29) 2198 * Removed paragraph suggesting that implementations favor 2199 unauthenticated peer source addresses over an unauthenticated 2200 ID for initial policy lookup. (Tero Kivinen Feb 29, Gregory 2201 Lebovitz Feb 29) 2202 * Removed some text implying RSA encryption mode was in scope. 2203 (Tero Kivinen Feb 29) 2204 * Relaxed deprecation of PKCS#7 CERT payloads. (Tero Kivinen Feb 2205 29) 2206 * Made it clearer that out-of-scope local heuristics should be 2207 used for picking an EE cert to use when generating CERTREQ, not 2208 when receiving CERTREQ. (Tero Kivinen Feb 29) 2209 * Made it clearer that CERT processing can be skipped when the 2210 contents of a CERT are already known. (Tero Kivinen Feb 29) 2211 * Implementations SHOULD generate BASE64 lines less than 76 2212 characters. (Tero Kivinen Feb 29) 2213 * Added "Except where specifically stated in this document, 2214 implementations MUST conform to the requirements of PKIX" 2215 (Steve Hanna Oct 7, 2003) 2216 * RECOMMENDS against populating the ID payload with IP addresses 2217 due to interoperability issues such as problem with NAT 2218 traversal. (Gregory Lebovitz May 14) 2219 * Changed "as revoked by one source" to "as revoked by one 2220 trusted source". (Michael Myers, May 15) 2221 * Specifying Certificate Authorities section needed to be 2222 regularized with Gregory Lebovitz's CERT proposal from -04. 2223 (Tylor Allison, May 15) 2224 * Added text specifying how recipients SHOULD NOT be expected to 2225 iterate over multiple end-entity certs. (Tylor Allison, May 2226 15) 2227 * Modified text to refer to IKEv2 as well as IKEv1/ISAKMP where 2228 relevant. 2229 * IKEv2: Explained that IDr sent by responder doesn't have to 2230 match the [IDr] sent initiator in second exchange. 2231 * IKEv2: Noted that "The identity ... does not necessarily have 2232 to match anything in the CERT payload" (S3.5) is not 2233 contradicted by SHOULD in this document. 2234 * IKEv2: Noted that ID_USER_FQDN renamed to ID_RFC822_ADDR, and 2235 ID_USER_FQDN would be used exclusively in this document. 2236 * IKEv2: Declared that 3 new CERTREQ and CERT types are not 2237 profiled in this document (well, at least not yet, pending WG 2238 discussion of what to do -- note that they are only SHOULDs in 2239 IKEv2). 2240 * IKEv2: Noted that CERTREQ payload changed from DN to SHA-1 of 2241 SubjectPublicKeyInfo. 2242 * IKEv2: Noted new requirement that specifies that the first 2243 certificate sent MUST be the EE cert (section 3.6). 2245 February 2004 (-04) 2247 * Minor editorial changes to clean up language 2248 * Deprecate in-band exchange of CRLs 2249 * Incorporated Gregory Lebovitz's proposal for CERT payloads: 2250 "should deal with all the CRL, Intermediat Certs, Trust 2251 Anchors, etc OOB of IKE; MUST be able to send and receive EE 2252 cert payload; only real exception is Intermediate Cets which 2253 MAY be sent and SHOULD be able to be receivable (but in reality 2254 there are very few hierarchies in operation, so really it's a 2255 corner case); SHOULD NOT send the other stuff (CRL, Trust 2256 Anchors, etc) in cert payloads in IKE; SHOULD be able to accept 2257 the other stuff if by chance it gets sent, though we hope they 2258 don't get sent" 2259 * Incorporated comments contained in Oct 7, 2003 email from 2260 steve.hanna@sun.com to ipsec@lists.tislabs.com 2261 * Moved text from "Profile of ISAKMP" Background section to each 2262 payload section (removing duplication of these sections) 2263 * Removed "Certificate-Related Playloads in ISAKMP" section since 2264 it was not specific to IKE. 2265 * Incorporated Gregory Lebovitz's table in the "Identification 2266 Payload" section 2267 * Moved text from "binding identity to policy" sections to each 2268 payload section 2269 * Moved text from "IKE" section into now-combined "IKE/ISAKMP" 2270 section 2271 * ID_USER_FQDN and ID_FQDN promoted to MUST from MAY 2272 * Promoted sending ID_DER_ASN1_DN to MAY from SHOULD NOT, and 2273 receiving from MUST from MAY 2274 * Demoted ID_DER_ASN1_GN to MUST NOT 2275 * Demoted populating SubjectName in place of populating the 2276 dNSName from SHOULD NOT to MUST NOT and removed the text 2277 regarding domainComponent 2278 * Revocation information checking MAY now be disabled, although 2279 not by default 2280 * Aggressive Mode removed from this profile 2282 June 2003 (-03) 2284 * Minor editorial changes to clean up language 2285 * Minor additional clarifying text 2286 * Removed hyphenation 2287 * Added requirement that implementations support configuration 2288 data exchange having arbitrary line lengths 2290 February 2003 (-02) 2292 * Word choice: move from use of "root" to "trust anchor", in 2293 accordance with PKIX 2294 * SBGP note and reference for placing address subnet and range 2295 information into certificates 2296 * Clarification of text regarding placing names of hosts into the 2297 Name commonName attribute of SubjectName 2298 * Added table to clarify text regarding processing of the 2299 certificate extension criticality bit 2300 * Added text underscoring processing requirements for 2301 CRLDistributionPoints and IssuingDistributionPoint 2303 October 2002, Reorganization (-01) 2305 June 2002, Initial Draft (-00) 2307 Author's Address 2309 Brian Korver 2310 Network Resonance, Inc. 2311 2483 E. Bayshore Rd. 2312 Palo Alto, CA 94303 2313 US 2315 Phone: +1 650 812 7705 2316 Email: briank@networkresonance.com 2318 Intellectual Property Statement 2320 The IETF takes no position regarding the validity or scope of any 2321 Intellectual Property Rights or other rights that might be claimed to 2322 pertain to the implementation or use of the technology described in 2323 this document or the extent to which any license under such rights 2324 might or might not be available; nor does it represent that it has 2325 made any independent effort to identify any such rights. Information 2326 on the procedures with respect to rights in RFC documents can be 2327 found in BCP 78 and BCP 79. 2329 Copies of IPR disclosures made to the IETF Secretariat and any 2330 assurances of licenses to be made available, or the result of an 2331 attempt made to obtain a general license or permission for the use of 2332 such proprietary rights by implementers or users of this 2333 specification can be obtained from the IETF on-line IPR repository at 2334 http://www.ietf.org/ipr. 2336 The IETF invites any interested party to bring to its attention any 2337 copyrights, patents or patent applications, or other proprietary 2338 rights that may cover technology that may be required to implement 2339 this standard. Please address the information to the IETF at 2340 ietf-ipr@ietf.org. 2342 Disclaimer of Validity 2344 This document and the information contained herein are provided on an 2345 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2346 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2347 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2348 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2349 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2350 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2352 Copyright Statement 2354 Copyright (C) The Internet Society (2006). This document is subject 2355 to the rights, licenses and restrictions contained in BCP 78, and 2356 except as set forth therein, the authors retain all their rights. 2358 Acknowledgment 2360 Funding for the RFC Editor function is currently provided by the 2361 Internet Society.