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