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