idnits 2.17.00 (12 Aug 2021) /tmp/idnits33507/draft-ietf-pki4ipsec-ikecert-profile-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2263. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 29 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 1198 has weird spacing: '...lements bit...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * Changed ISAKMP references in Abstract and Intro to IKE. * Editorial changes to make the text conform with the summary table in 3.1, especially in the text following the table in 3.1. Particular note should be paid to changes in section 3.5.1. * Sect 3.1.1 - editorial changes to aid in clarification. Added text on when deployers might consider using IP addr, but strongly encouraged not to. * Sect 3.1.8 removed IP address from list of practically used ID types. * 3.1.9 overhauled (per Kivinen, July 18) * 3.2 - added IKEv2's Hash and URL of x.509 to list of those profiled and gave it its own section, now 3.2.5 * added note in CRL/ARL section about revocation occurring OOB of IKE * deleted ARL as its own section and collapsed it into Revocation Lists (CRL and ARL) for consciseness. Renumbered accordingly. * Sect 3.2.7.2 - Changed from MUST not send empty certreqs to SHOULD send CERTREQs which contain CA fields with direction on how, but MAY send empty CERTREQs in certain case. Use case added, and specifics of both initiator and responder behavior listed. * APPENDIX C added to fill out the explanation (mostly discussion from list). * 3.3 - clarified that sending CRLs and chaining certs is deprecated. * added IKEv2's Hash and URL of x.509 to list of those profiled and gave it its own section. Condensed ARL into CRL and renumbered accordingly. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2006) is 5938 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'IKEv2' on line 1933 -- Looks like a reference, but probably isn't: 'IDr' on line 2023 == Unused Reference: '18' is defined on line 1740, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2409 (ref. '1') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '2') (Obsoleted by RFC 4306) == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 ** 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) == Outdated reference: draft-ietf-ipsec-rfc2401bis has been published as RFC 4301 -- Obsolete informational reference (is this intentional?): RFC 1883 (ref. '11') (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '12') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: draft-ietf-pkix-x509-ipaddr-as-extn has been published as RFC 3779 -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. '14') (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. '15') (Obsoleted by RFC 6960) Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pki4ipsec B. Korver 3 Internet-Draft Network Resonance, Inc. 4 Expires: August 19, 2006 February 15, 2006 6 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX 7 draft-ietf-pki4ipsec-ikecert-profile-08 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 19, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 IKE and PKIX both provide frameworks that must be profiled for use in 41 a given application. This document provides a profile of IKE and 42 PKIX that defines the requirements for using PKI technology in the 43 context of IKE/IPsec. The document complements protocol 44 specifications such as IKEv1 and IKEv2, which assume the existence of 45 public key certificates and related keying materials, but which do 46 not address PKI issues explicitly. This document addresses those 47 issues. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 53 3. Profile of IKEv1/ISAKMP and IKEv2 . . . . . . . . . . . . . . 5 54 3.1. Identification Payload . . . . . . . . . . . . . . . . . . 5 55 3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . . . 7 56 3.1.2. ID_FQDN . . . . . . . . . . . . . . . . . . . . . . . 9 57 3.1.3. ID_USER_FQDN . . . . . . . . . . . . . . . . . . . . . 10 58 3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, 59 ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE . . . . . . . . 11 60 3.1.5. ID_DER_ASN1_DN . . . . . . . . . . . . . . . . . . . . 11 61 3.1.6. ID_DER_ASN1_GN . . . . . . . . . . . . . . . . . . . . 12 62 3.1.7. ID_KEY_ID . . . . . . . . . . . . . . . . . . . . . . 12 63 3.1.8. Selecting an Identity from a Certificate . . . . . . . 12 64 3.1.9. SubjectName for DN Only . . . . . . . . . . . . . . . 12 65 3.1.10. Binding Identity to Policy . . . . . . . . . . . . . . 13 66 3.2. Certificate Request Payload . . . . . . . . . . . . . . . 14 67 3.2.1. Certificate Type . . . . . . . . . . . . . . . . . . . 14 68 3.2.2. X.509 Certificate - Signature . . . . . . . . . . . . 14 69 3.2.3. Revocation Lists (CRL and ARL) . . . . . . . . . . . . 14 70 3.2.4. PKCS #7 wrapped X.509 certificate . . . . . . . . . . 15 71 3.2.5. IKEv2's Hash and URL of X.509 certificate . . . . . . 15 72 3.2.6. Location of Certificate Payloads . . . . . . . . . . . 16 73 3.2.7. Presence or Absence of Certificate Request Payloads . 16 74 3.2.8. Certificate Requests . . . . . . . . . . . . . . . . . 16 75 3.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 18 76 3.2.10. Optimizations . . . . . . . . . . . . . . . . . . . . 18 77 3.3. Certificate Payload . . . . . . . . . . . . . . . . . . . 20 78 3.3.1. Certificate Type . . . . . . . . . . . . . . . . . . . 20 79 3.3.2. X.509 Certificate - Signature . . . . . . . . . . . . 21 80 3.3.3. Revocation Lists (CRL and ARL) . . . . . . . . . . . . 21 81 3.3.4. IKEv2's Hash and URL of X.509 Certificate . . . . . . 21 82 3.3.5. PKCS #7 wrapped X.509 certificate . . . . . . . . . . 21 83 3.3.6. Location of Certificate Payloads . . . . . . . . . . . 22 84 3.3.7. Certificate Payloads Not Mandatory . . . . . . . . . . 22 85 3.3.8. Response to Multiple Certification Authority 86 Proposals . . . . . . . . . . . . . . . . . . . . . . 22 87 3.3.9. Using Local Keying Materials . . . . . . . . . . . . . 22 88 3.3.10. Multiple End-Entity Certificates . . . . . . . . . . . 23 89 3.3.11. Robustness . . . . . . . . . . . . . . . . . . . . . . 23 90 3.3.12. Optimizations . . . . . . . . . . . . . . . . . . . . 24 91 4. Profile of PKIX . . . . . . . . . . . . . . . . . . . . . . . 25 92 4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 25 93 4.1.1. Versions . . . . . . . . . . . . . . . . . . . . . . . 25 94 4.1.2. SubjectName . . . . . . . . . . . . . . . . . . . . . 25 95 4.1.3. X.509 Certificate Extensions . . . . . . . . . . . . . 26 96 4.2. X.509 Certificate Revocation Lists . . . . . . . . . . . . 32 97 4.2.1. Multiple Sources of Certificate Revocation 98 Information . . . . . . . . . . . . . . . . . . . . . 32 99 4.2.2. X.509 Certificate Revocation List Extensions . . . . . 32 100 5. Configuration Data Exchange Conventions . . . . . . . . . . . 34 101 5.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 34 102 5.2. CRLs and ARLs . . . . . . . . . . . . . . . . . . . . . . 34 103 5.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 34 104 5.4. PKCS#10 Certificate Signing Requests . . . . . . . . . . . 35 105 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 106 6.1. Certificate Request Payload . . . . . . . . . . . . . . . 35 107 6.2. IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 35 108 6.3. Disabling Certificate Checks . . . . . . . . . . . . . . . 35 109 6.4. Strength of Signature Hashing Algorithms . . . . . . . . . 35 110 7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 36 111 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 112 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 113 9.1. Normative References . . . . . . . . . . . . . . . . . . . 36 114 9.2. Informative References . . . . . . . . . . . . . . . . . . 37 115 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 38 116 Appendix B. The Possible Dangers of Delta CRLs . . . . . . . . . 45 117 Appendix C. More on Empty CERTREQs . . . . . . . . . . . . . . . 46 118 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 48 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49 120 Intellectual Property and Copyright Statements . . . . . . . . . . 50 122 1. Introduction 124 IKE [1], ISAKMP [2] and IKEv2 [3] provide a secure key exchange 125 mechanism for use with IPsec [4]. In many cases the peers 126 authenticate using digital certificates as specified in PKIX [5]. 127 Unfortunately, the combination of these standards leads to an 128 underspecified set of requirements for the use of certificates in the 129 context of IPsec. 131 ISAKMP references PKIX but in many cases merely specifies the 132 contents of various messages without specifying their syntax or 133 semantics. Meanwhile, PKIX provides a large set of certificate 134 mechanisms which are generally applicable for Internet protocols, but 135 little specific guidance for IPsec. Given the numerous 136 underspecified choices, interoperability is hampered if all 137 implementers do not make similar choices, or at least fail to account 138 for implementations which have chosen differently. 140 This profile of the IKE and PKIX frameworks is intended to provide an 141 agreed-upon standard for using PKI technology in the context of IPsec 142 by profiling the PKIX framework for use with IKE and IPsec, and by 143 documenting the contents of the relevant IKE payloads and further 144 specifying their semantics. 146 In addition to providing a profile of IKE and PKIX, this document 147 attempts to incorporate lessons learned from recent experience with 148 both implementation and deployment, as well as the current state of 149 related protocols and technologies. 151 Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and 152 readers of this document are assumed to have read and understood 153 those documents. The requirements and security aspects of those 154 documents are fully relevant to this document as well. 156 This document is organized as follows. Section 2 defines special 157 terminology used in the rest of this document, Section 3 provides the 158 profile of IKEv1/ISAKMP and IKEv2, and Section 4 provides the profile 159 of PKIX. Section 5 covers conventions for the out-of-band exchange 160 of keying materials for configuration purposes. 162 This document is being discussed on the pki4ipsec@icsalabs.com 163 mailing list. 165 2. Terms and Definitions 167 Except for those terms which are defined immediately below, all terms 168 used in this document are defined in either the PKIX [5], ISAKMP [2], 169 IKEv1 [1], IKEv2 [3], or DOI [6] documents. 171 o Peer source address: The source address in packets from a peer. 172 This address may be different from any addresses asserted as the 173 "identity" of the peer. 174 o FQDN: Fully qualified domain name. 175 o ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both 176 are referred to as ID_USER_FQDN in this document. 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC-2119 [7]. 182 3. Profile of IKEv1/ISAKMP and IKEv2 184 3.1. Identification Payload 186 The Identification (ID) Payload is used to indicate the identity that 187 the sender claims to be speaking for. The recipient can then use the 188 ID as a lookup key for policy and for certificate lookup in whatever 189 certificate store or directory that it has available. Our primary 190 concern in this section is to profile the ID payload so that it can 191 be safely used to generate or lookup policy. IKE mandates the use of 192 the ID payload in Phase 1. 194 The DOI [6] defines the 11 types of Identification Data that can be 195 used and specifies the syntax for these types. These are discussed 196 below in detail. 198 The ID payload requirements in this document cover only the portion 199 of the explicit policy checks that deal with the Identification 200 Payload specifically. For instance, in the case where ID does not 201 contain an IP address, checks such as verifying that the peer source 202 address is permitted by the relevant policy are not addressed here as 203 they are out of the scope of this document. 205 Implementations SHOULD populate ID with identity information that is 206 contained within the end-entity certificate (This SHOULD does not 207 contradict text in IKEv2 [3] Section 3.5 that implies a looser 208 binding between these two). Populating ID with identity information 209 from the end-entity certificate enables recipients to use ID as a 210 lookup key to find the peer end-entity certificate. The only case 211 where implementations MAY populate ID with information that is not 212 contained in the end-entity certificate is when ID contains the peer 213 source address (a single address, not a subnet or range). 215 Because implementations may use ID as a lookup key to determine which 216 policy to use, all implementations MUST be especially careful to 217 verify the truthfulness of the contents by verifying that they 218 correspond to some keying material demonstrably held by the peer. 219 Failure to do so may result in the use of an inappropriate or 220 insecure policy. The following sections describe the methods for 221 performing this binding. 223 The following table summarizes the binding of the Identification 224 Payload to the contents of end-entity certificates and of identity 225 information to policy. Each ID type is covered more thoroughly in 226 the following sections. 228 ID type | Support | Correspond | Cert | SPD lookup 229 | for send | PKIX Attrib | matching | rules 230 ------------------------------------------------------------------- 231 | | | | 232 IP*_ADDR | MUST [a] | SubjAltName | MUST [b] | [c], [d] 233 | | iPAddress | | 234 | | | | 235 FQDN | MUST [a] | SubjAltName | MUST [b] | [c], [d] 236 | | dNSName | | 237 | | | | 238 USER_FQDN| MUST [a] | SubjAltName | MUST [b] | [c], [d] 239 | | rfc822Name | | 240 | | | | 241 DN | MUST [a] | Entire | MUST [b] | MUST support lookup 242 | | Subject, | | on any combination 243 | | bitwise | | of C, CN, O, or OU 244 | | compare | | 245 | | | | 246 IP range | MUST NOT | n/a | n/a | n/a 247 | | | | 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 2401bis [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 attribute. 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 attribute 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 either the ID_IPV4_ADDR or ID_IPV6_ADDR 303 ID type, depending on whether the implementation supports IPv4, IPv6 304 or both. These addresses MUST be encoded in "network byte order," as 305 specified in IP [8]: The least significant bit (LSB) of each octet is 306 the LSB of the corresponding byte in the network address. For the 307 ID_IPV4_ADDR type, the payload MUST contain exactly four octets [8]. 308 For the ID_IPV6_ADDR type, the payload MUST contain exactly sixteen 309 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 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. 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, caseless string comparison MUST be performed. 411 Substring, wildcard, or regular expression matching MUST NOT be 412 performed for this comparison. If this default is enabled, then a 413 mismatch MUST be treated as an error and security association setup 414 MUST be aborted. This event SHOULD be auditable. Implementations 415 MAY provide a configuration option to (i.e. local policy 416 configuration can enable) skip that verification step, but that 417 option MUST be off by default. We include the "option-to-skip- 418 validation" in order to permit better interoperability, as today 419 implementations vary greatly in how they behave on this topic. 421 Implementations MAY support substring, wildcard, or regular 422 expression matching of the contents of ID to lookup policy in the 423 SPD, and such would be a matter of local security policy 424 configuration. 426 3.1.3. ID_USER_FQDN 428 Implementations MUST support the ID_USER_FQDN ID type, generally to 429 support user-based access control lists for users without fixed IP 430 addresses. However, implementations SHOULD NOT use the DNS to map 431 the FQDN portion to IP addresses for input into any policy decisions, 432 unless that mapping is known to be secure, for example if DNSSEC [12] 433 were employed. 435 Implementations MUST be capable of verifying that the identity 436 contained in the ID payload matches identity information contained in 437 the peer end-entity certificate, in the rfc822Name field in the 438 SubjectAltName extension. Implementations MUST perform this 439 verification by default. When comparing the contents of ID with the 440 rfc822Name field in the SubjectAltName extension for equality, 441 caseless string comparison MUST be performed. Substring, wildcard, 442 or regular expression matching MUST NOT be performed for this 443 comparison. If this default is enabled, then a mismatch MUST be 444 treated as an error and security association setup MUST be aborted. 445 This event SHOULD be auditable. Implementations MAY provide a 446 configuration option to (i.e. local policy configuration can enable) 447 skip that verification step, but that option MUST be off by default. 448 We include the "option-to-skip-validation" in order to permit better 449 interoperability, as today implementations vary greatly in how they 450 behave on this topic. 452 Implementations MAY support substring, wildcard, or regular 453 expression matching of the contents of ID to lookup policy in the 454 SPD, and such would be a matter of local security policy 455 configuration. 457 3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, 458 ID_IPV6_ADDR_RANGE 460 Historically there was no standard method for putting address subnet 461 or range identity information into certificates, nor are there any 462 implementations known to support these ID types. Therefore, use of 463 these ID types is currently undefined. Implementations MUST NOT 464 generate these ID types. 466 Note that work in SBGP [13] for defining blocks of addresses using 467 the certificate extension identified by: 469 id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } 471 is experimental at 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 SubjectName from the end-entity 480 certificate, and MUST do so such that a binary comparison of the two 481 will succeed. If there is not a match, this MUST be treated as an 482 error and security association setup MUST be aborted. This event 483 SHOULD be auditable. Note, if the certificate was erroneously 484 created such that the encoding of the SubjectName 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 SubjectName from the 491 end-entity certificate if it is empty, even though an empty 492 certificate SubjectName is explicitly allowed in the "Subject" 493 section of PKIX. 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. 519 3.1.7. ID_KEY_ID 521 The ID_KEY_ID type used to specify pre-shared keys and thus is out of 522 scope. 524 3.1.8. Selecting an Identity from a Certificate 526 Implementations MUST support certificates that contain more than a 527 single identity, such as when SubjectName and the SubjectAltName 528 extension are both populated, or the SubjectAltName extension 529 contains multiple identities irrespective of whether SubjectName is 530 empty or not. In many cases a certificate will contain an identity 531 such as an IP address in the SubjectAltName extension in addition to 532 a non-empty SubjectName. 534 Implementations SHOULD populate ID with whichever identity is likely 535 to be named in the peer's policy. In practice, this generally means 536 FQDN, or USER_FQDN, but this information may also be available to the 537 administrator through some out-of-band means. In the absence of such 538 out-of-band configuration information, the identity with which an 539 implementation chooses to populate the ID payload is a local matter. 541 3.1.9. SubjectName for DN Only 543 If an FQDN is intended to be processed as an identity for the 544 purposes ID matching, it MUST be placed in the dNSName field of the 545 SubjectAltName extension. Implementations MUST NOT populate 546 SubjectName with an FQDN in place of populating the dNSName field of 547 the SubjectAltName extension. 549 While nothing prevents an FQDN, USER_FQDN, or IP address information 550 from appearing somewhere in the SubjectName contents, such entries 551 MUST NOT be interpreted as identity information for the purposes of 552 matching with ID or for policy lookup. 554 3.1.10. Binding Identity to Policy 556 In the presence of certificates that contain multiple identities, 557 implementations MUST select the most appropriate identity from the 558 certificate and populate the ID with that. The recipient MUST use 559 the identity sent as a first key when selecting the policy. The 560 recipient MUST also use the most specific policy from that database 561 if there are overlapping policies caused by wildcards (or the 562 implementation can de-correlate the policy database so there will not 563 be overlapping entries, or it can also forbid creation of overlapping 564 policies and leave the de-correlation process to the administrator, 565 but as this moves the problem to the administrator it is NOT 566 RECOMMENDED). 568 For example, imagine that a implementation is configured with a 569 certificate that contains both a non-empty SubjectName and a dNSName. 570 The sender's policy may specify which of those to use, and it 571 indicates the policy to the other end by sending that ID. If the 572 recipient has both a specific policy for the dNSName for this host 573 and generic wildcard rule for some attributes present in the 574 SubjectName, it will match a different policy depending which ID is 575 sent. As the sender knows why it wanted to connect the peer, it also 576 knows what identity it should use to match the policy it needs to the 577 operation it tries to perform; it is the only party who can select 578 the ID adequately. 580 In the event the policy cannot be found in the recipient's SPD using 581 the ID sent, then the recipient MAY use the other identities in the 582 certificate when attempting to match a suitable policy. For example, 583 say the certificate contains non-empty SubjectName, a dNSName and an 584 iPAddress. If an iPAddress is sent in ID but no specific entry 585 exists for the address in the policy database, the recipient MAY 586 search in the policy database based on the SubjectName or the dNSName 587 contained in the certificate. 589 The Peer Authorization Database (PAD) as described in 2401bis [10] 590 provides a more formal model for the binding of identity to policy in 591 addition to providing services that deal more specifically with the 592 details of policy enforcement, which are generally out of scope of 593 this document. The PAD is intended to provide a link between the SPD 594 and the security association management in protocols such as IKE. 595 See 2401bis [10], section 4.4.3 for more details. 597 3.2. Certificate Request Payload 599 The Certificate Request (CERTREQ) Payload allows an implementation to 600 request that a peer provide some set of certificates or certificate 601 revocation lists. It is not clear from ISAKMP exactly how that set 602 should be specified or how the peer should respond. We describe the 603 semantics on both sides. 605 3.2.1. Certificate Type 607 The Certificate Type field identifies to the peer the type of 608 certificate keying materials that are desired. ISAKMP defines 10 609 types of Certificate Data that can be requested and specifies the 610 syntax for these types, and IKEv2 specifies 3 additional types. For 611 the purposes of this document, only the following types are relevant: 613 o X.509 Certificate - Signature 614 o Revocation Lists (CRL and ARL) 615 o PKCS #7 wrapped X.509 certificate 616 o IKEv2's Hash and URL of X.509 certificate 618 The use of the other types: 620 o X.509 Certificate - Key Exchange 621 o PGP Certificate 622 o DNS Signed Key 623 o Kerberos Tokens 624 o SPKI Certificate 625 o X.509 Certificate Attribute 626 o IKEv2's Raw RSA Key 627 o IKEv2's Hash and URL of X.509 bundle 629 are out of the scope of this document. 631 3.2.2. X.509 Certificate - Signature 633 This type requests that the end-entity certificate be a certificate 634 used for signing. 636 3.2.3. Revocation Lists (CRL and ARL) 638 ISAKMP and IKEv2 do not support Certificate Payload sizes over 639 approximately 64K, which is too small for many CRLs. Therefore, the 640 acquisition of revocation material is to be dealt with out-of-band of 641 IKE. For this and other reasons, implementations SHOULD NOT generate 642 CERTREQs where the Certificate Type is "Certificate Revocation List 643 (CRL)" or "Authority Revocation List (ARL)". Implementations that do 644 generate such CERTREQs MUST NOT require the recipient to respond with 645 a CRL or ARL, and MUST NOT fail when not receiving any. Upon receipt 646 of such a CERTREQ, implementations MAY ignore the request. 648 In lieu of exchanging revocation lists in-band, a pointer to 649 revocation checking SHOULD be listed in either the 650 CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA) 651 certificate extensions (see Section 4 for details). Unless other 652 methods for obtaining revocation information are available, 653 implementations SHOULD be able to process these attributes, and from 654 them be able to identify cached revocation material, or retrieve the 655 relevant revocation material from a URL, for validation processing. 656 In addition, implementations MUST have the ability to configure 657 validation checking information for each certification authority. 658 Regardless of the method (CDP, AIA, or static configuration), the 659 acquisition of revocation material SHOULD occur out-of-band of IKE. 661 3.2.4. PKCS #7 wrapped X.509 certificate 663 This ID type defines a particular encoding (not a particular 664 certificate type), some current implementations may ignore CERTREQs 665 they receive which contain this ID type, and the editors are unaware 666 of any implementations that generate such CERTREQ messages. 667 Therefore, the use of this type is deprecated. Implementations 668 SHOULD NOT require CERTREQs that contain this Certificate Type. 669 Implementations which receive CERTREQs which contain this ID type MAY 670 treat such payloads as synonymous with "X.509 Certificate - 671 Signature". 673 3.2.5. IKEv2's Hash and URL of X.509 certificate 675 This ID type defines a request for the peer to send a hash and URL of 676 it X.509 certificate, instead of the actual certificate itself. This 677 is a particularly useful mechanism when the peer is a device with 678 little memory and lower bandwidth, e.g. a mobile handset or consumer 679 electronics device. 681 If the IKEv2 implementation supports URL lookups, and prefers such a 682 URL to receiving actual certificates, then the implementation will 683 want to send a notify of type HTTP_CERT_LOOKUP_SUPPORTED. From IKEv2 684 [3], section 3.10.1, "This notification MAY be included in any 685 message that can include a CERTREQ payload and indicates that the 686 sender is capable of looking up certificates based on an HTTP-based 687 URL (and hence presumably would prefer to receive certificate 688 specifications in that format)." If an HTTP_LOOKUP_SUPPORTED 689 notification is sent the sender MUST support the http scheme. See 690 Section 3.3.4 for more discussion. 692 3.2.6. Location of Certificate Payloads 694 In IKEv1, the CERTREQ payload MUST be in messages 4 and 5. In IKEv2, 695 the CERTREQ payload must be in messages 2 and 3. Note that in IKEv2, 696 it is possible to have one side authenticating with certificates 697 while the other side authenticates with preshared keys. 699 3.2.7. Presence or Absence of Certificate Request Payloads 701 When in-band exchange of certificate keying materials is desired, 702 implementations MUST inform the peer of this by sending at least one 703 CERTREQ. In other words, an implementation which does not send any 704 CERTREQs during an exchange SHOULD NOT expect to receive any CERT 705 payloads. 707 3.2.8. Certificate Requests 709 3.2.8.1. Specifying Certification Authorities 711 When requesting in-band exchange of keying materials, implementations 712 SHOULD generate CERTREQs for every peer trust anchor that local 713 policy explicitly deems trusted during a given exchange. For IKEv1, 714 implementations SHOULD populate the Certification Authority field 715 with the SubjectName of the trust anchor, populated such that binary 716 comparison of the SubjectName and the Certification Authority will 717 succeed. For IKEv2, implementations MUST populate the Certification 718 Authority field as specified in IKEv2 [3]. 720 Upon receipt of a CERTREQ, implementations MUST respond by sending at 721 least the end-entity certificate corresponding to the Certification 722 Authority listed in the CERTREQ unless local security policy 723 configuration specifies that keying materials must be exchanged out- 724 of-band. Implementations MAY send certificates other than the end- 725 entity certificate (see Section 3.3 for discussion). 727 Note, in the case where multiple end-entity certificates may be 728 available which chain to different trust anchors, implementations 729 SHOULD resort to local heuristics to determine which trust anchor is 730 most appropriate to use for generating the CERTREQ. Such heuristics 731 are out of the scope of this document. 733 3.2.8.2. Empty Certification Authority Field 735 Implementations SHOULD generate CERTREQs where the Certificate Type 736 is "X.509 Certificate - Signature" and where a the Certification 737 Authority field is not empty. However, implementations MAY generate 738 CERTREQs with an empty Certification Authority field under special 739 conditions. Although PKIX prohibits certificates with empty 740 IssuerName fields, there does exist a use case where doing so is 741 appropriate, and carries special meaning in the IKE context. This 742 has become a convention within the IKE interoperability tests and 743 usage space, and so its use is specified, explained here for the sake 744 of interoperability. 746 USE CASE: Consider the rare case where you have a gateway with 747 multiple policies for a large number of IKE peers: some of these 748 peers are business partners, some are remote access employees, some 749 are teleworkers, some are branch offices, and/or the gateway may be 750 simultaneously serving many customers (e.g. Virtual Routers). The 751 total number of certificates, and corresponding trust anchors, is 752 very high, say hundreds. Each of these policies is configured with 753 one or more acceptable trust anchors, so that in total, the gateway 754 has one hundred (100) trust anchors that could possibly used to 755 authenticate an incoming connection. Assume that many of those 756 connections originate from hosts/gateways with dynamically assigned 757 IP addresses, so that the source IP of the IKE initiator is not known 758 to the gateway, nor is the identity of the initiator (until it is 759 revealed in Main Mode message 5). In IKE main mode message 4, the 760 responder gateway will need to send a CERTREQ to the initiator. 761 Given this example, the gateway will have no idea which of the 762 hundred possible Certification Authorities to send in the CERTREQ. 763 Sending all possible Certification Authorities will cause significant 764 processing delays, bandwidth consumption, and UDP fragmentation, so 765 this tactic is ruled out. 767 In such a deployment, the responder gateway implementation should be 768 able to do all it can to indicate a Certification Authority in the 769 CERTREQ. This means the responder SHOULD first check SPD to see if 770 it can match the source IP, and find some indication of which CA is 771 associated with that IP. If this fails (because the source IP is not 772 familiar, as in the case above), then the responder SHOULD have a 773 configuration option specifying which CA's are the default CAs to 774 indicate in CERTREQ during such ambiguous connections (e.g. send 775 CERTREQ with these N CAs if there is an unknown source IP). If such 776 a fall-back is not configured or impractical in a certain deployment 777 scenario, then the responder implementation SHOULD have both of the 778 following configuration options: 780 o send a CERTREQ payload with an empty Certification Authority 781 field, or 782 o terminate the negotiation with an appropriate error message and 783 audit log entry. 785 Receiving a CERTREQ payload with an empty Certification Authority 786 field indicates that the recipient should send all/any end-entity 787 certificates it has, regardless of the trust anchor. The initiator 788 should be aware of what policy and which identity it will use, as it 789 initiated the connection on a matched policy to begin with, and can 790 thus respond with the appropriate certificate. 792 If, after sending an empty CERTREQ in Main Mode message 4, a 793 responder receives a certificate in message 5 that chains to a trust 794 anchor that the responder either (a) does NOT support, or (b) was not 795 configured for the policy (that policy was now able to be matched due 796 to having the initiator's certificate present), this MUST be treated 797 as an error and security association setup MUST be aborted. This 798 event SHOULD be auditable. 800 Instead of sending a empty CERTREQ, the responder implementation MAY 801 be configured to terminate the negotiation on the grounds of a 802 conflict with locally configured security policy. 804 The decision of which to configure is a matter of local security 805 policy, this document RECOMMENDS that both options be presented to 806 administrators. 808 More examples, and explanation on this issue are included in "More on 809 Empty CERTREQs" (Appendix C). 811 3.2.9. Robustness 813 3.2.9.1. Unrecognized or Unsupported Certificate Types 815 Implementations MUST be able to deal with receiving CERTREQs with 816 unsupported Certificate Types. Absent any recognized and supported 817 CERTREQ types, implementations MAY treat them as if they are of a 818 supported type with the Certification Authority field left empty, 819 depending on local policy. ISAKMP [2] Section 5.10 "Certificate 820 Request Payload Processing" specifies additional processing. 822 3.2.9.2. Undecodable Certification Authority Fields 824 Implementations MUST be able to deal with receiving CERTREQs with 825 undecodable Certification Authority fields. Implementations MAY 826 ignore such payloads, depending on local policy. ISAKMP specifies 827 other actions which may be taken. 829 3.2.9.3. Ordering of Certificate Request Payloads 831 Implementations MUST NOT assume that CERTREQs are ordered in any way. 833 3.2.10. Optimizations 834 3.2.10.1. Duplicate Certificate Request Payloads 836 Implementations SHOULD NOT send duplicate CERTREQs during an 837 exchange. 839 3.2.10.2. Name Lowest 'Common' Certification Authorities 841 When a peer's certificate keying materials have been cached, an 842 implementation can send a hint to the peer to elide some of the 843 certificates the peer would normally respond with. In addition to 844 the normal set of CERTREQs that are sent specifying the trust 845 anchors, an implementation MAY send CERTREQs specifying the relevant 846 cached end-entity certificates. When sending these hints, it is 847 still necessary to send the normal set of trust anchor CERTREQs 848 because the hints do not sufficiently convey all of the information 849 required by the peer. Specifically, either the peer may not support 850 this optimization or there may be additional chains that could be 851 used in this context but will not be if only the end-entity 852 certificate is specified. 854 No special processing is required on the part of the recipient of 855 such a CERTREQ, and the end-entity certificates will still be sent. 856 On the other hand, the recipient MAY elect to elide certificates 857 based on receipt of such hints. 859 CERTREQs must contain information that identifies a Certification 860 Authority certificate, which results in the peer always sending at 861 least the end-entity certificate. Always sending the end-entity 862 certificate allows implementations to determine unambiguously when a 863 new certificate is being used by a peer (perhaps because the previous 864 certificate has just expired), which may result in a failure because 865 a new intermediate CA certificate might not be available to validate 866 the new end-entity certificate). Implementations which implement 867 this optimization MUST recognize when the end-entity certificate has 868 changed and respond to it by not performing this optimization if the 869 exchange must be retried so that any missing keying materials will be 870 sent during retry. 872 3.2.10.3. Example 874 Imagine that an IKEv1 implementation has previously received and 875 cached the peer certificate chain TA->CA1->CA2->EE. If during a 876 subsequent exchange this implementation sends a CERTREQ containing 877 the SubjectName in certificate TA, this implementation is requesting 878 that the peer send at least 3 certificates: CA1, CA2, and EE. On the 879 other hand, if this implementation also sends a CERTREQ containing 880 the SubjectName of CA2, the implementation is providing a hint that 881 only 1 certificate needs to be sent: EE. Note that in this example, 882 the fact that TA is a trust anchor should not be construed to imply 883 that TA is a self-signed certificate. 885 3.3. Certificate Payload 887 The Certificate (CERT) Payload allows the peer to transmit a single 888 certificate or CRL. Multiple certificates should be transmitted in 889 multiple payloads. For backwards compatibility reasons, 890 implementations MAY send intermediate CA certificates in addition to 891 the appropriate end-entity certificate(s), but SHOULD NOT send any 892 CRLs, ARLs, or trust anchors. The reason for not exchanging CRLs or 893 ARLs in IKE is to: 895 o decrease UDP fragmentation 896 o simplify the IKE exchange 897 o reduce bandwidth requirements for IKE exchanges 899 Note, however, that while the sender of the CERT payloads SHOULD NOT 900 send any trust anchors, it's possible that the recipient may consider 901 any given intermediate CA certificate to be a trust anchor. For 902 instance, imagine the sender has the certificate chain TA1->CA1->EE1 903 while the recipient has the certificate chain TA2->EE2 where TA2=CA1. 904 The sender is merely including an intermdiate CA certificate, while 905 the recipient receives a trust anchor. 907 However, not all certificate forms that are legal in PKIX make sense 908 in the context of IPsec. The issue of how to represent IKE- 909 meaningful name-forms in a certificate is especially problematic. 910 This document provides a profile for a subset of PKIX that makes 911 sense for IKEv1/ISAKMP and IKEv2. 913 3.3.1. Certificate Type 915 The Certificate Type field identifies to the peer the type of 916 certificate keying materials that are included. ISAKMP defines 10 917 types of Certificate Data that can be sent and specifies the syntax 918 for these types, and IKEv2 specifies 3 additional types. For the 919 purposes of this document, only the following types are relevant: 921 o X.509 Certificate - Signature 922 o Revocation Lists (CRL and ARL) 923 o PKCS #7 wrapped X.509 certificate 924 o IKEv2's Hash and URL of X.509 certificate 926 The use of the other types: 928 o X.509 Certificate - Key Exchange 929 o PGP Certificate 930 o DNS Signed Key 931 o Kerberos Tokens 932 o SPKI Certificate 933 o X.509 Certificate Attribute 934 o IKEv2's Raw RSA Key 935 o IKEv2's Hash and URL of X.509 bundle 937 are out of the scope of this document. 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_LOOKUP_SUPPORTED notification 956 MUST support the http scheme and MAY support the ftp scheme, and MUST 957 NOT require any specific form of the url-path and it SHOULD support 958 having user-name, password and port parts in the URL. The following 959 are examples of mandatory forms: 961 o http://certs.example.com/certificate.crt 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.crt 969 The following is an example of the ftp scheme that MAY be supported: 971 o ftp://ftp.example.com/pub/certificate.crt 973 3.3.5. PKCS #7 wrapped X.509 certificate 975 This type defines a particular encoding, not a particular certificate 976 type. Implementations SHOULD NOT generate CERTs that contain this 977 Certificate Type. Implementations SHOULD accept CERTs that contain 978 this Certificate Type because several implementations are known to 979 generate them. Note that those implementations sometimes include 980 entire certificate hierarchies inside a single CERT PKCS #7 payload, 981 which violates the requirement specified in ISAKMP that this payload 982 contain a single certificate. 984 3.3.6. Location of Certificate Payloads 986 In IKEv1 Main Mode, the CERT payload MUST be in messages 5 and 6. In 987 IKEv2, the CERT payload must be in messages 3 and 4. Note that in 988 IKEv2, it is possible to have one side authenticating with 989 certificates while the other side authenticates with preshared keys. 991 3.3.7. Certificate Payloads Not Mandatory 993 An implementation which does not receive any CERTREQs during an 994 exchange SHOULD NOT send any CERT payloads, except when explicitly 995 configured to proactively send CERT payloads in order to interoperate 996 with non-compliant implementations which fail to send CERTREQs even 997 when certificates are desired. In this case, an implementation MAY 998 send the certificate chain (not including the trust anchor) 999 associated with the end-entity certificate. This MUST NOT be the 1000 default behavior of implementations. 1002 Implementations whose local security policy configuration expects 1003 that a peer must receive certificates through out-of-band means 1004 SHOULD ignore any CERTREQ messages that are received. 1006 Implementations that receive CERTREQs from a peer which contain only 1007 unrecognized Certification Authorities SHOULD NOT continue the 1008 exchange, in order to avoid unnecessary and potentially expensive 1009 cryptographic processing, denial of service (resource starvation) 1010 attacks. 1012 3.3.8. Response to Multiple Certification Authority Proposals 1014 In response to multiple CERTREQs which contain different 1015 Certification Authority identities, implementations MAY respond using 1016 an end-entity certificate which chains to a CA that matches any of 1017 the identities provided by the peer. 1019 3.3.9. Using Local Keying Materials 1021 Implementations MAY elect to skip parsing or otherwise decoding a 1022 given set of CERTs if equivalent keying materials are available via 1023 some preferable means, such as the case where certificates from a 1024 previous exchange have been cached. 1026 3.3.10. Multiple End-Entity Certificates 1028 Implementations SHOULD NOT send multiple end-entity certificates and 1029 recipients SHOULD NOT be expected to iterate over multiple end-entity 1030 certificates. 1032 If multiple end-entity certificates are sent, they MUST have the same 1033 public key, otherwise the responder does not know which key was used 1034 in the Main Mode message 5. 1036 3.3.11. Robustness 1038 3.3.11.1. Unrecognized or Unsupported Certificate Types 1040 Implementations MUST be able to deal with receiving CERTs with 1041 unrecognized or unsupported Certificate Types. Implementations MAY 1042 discard such payloads, depending on local policy. ISAKMP [2] Section 1043 5.10 "Certificate Request Payload Processing" specifies additional 1044 processing. 1046 3.3.11.2. Undecodable Certificate Data Fields 1048 Implementations MUST be able to deal with receiving CERTs with 1049 undecodable Certificate Data fields. Implementations MAY discard 1050 such payloads, depending on local policy. ISAKMP specifies other 1051 actions which may be taken. 1053 3.3.11.3. Ordering of Certificate Payloads 1055 For IKEv1, implementations MUST NOT assume that CERTs are ordered in 1056 any way. For IKEv2, implementations MUST NOT assume that any except 1057 the first CERT is ordered in any way. IKEv2 specifies that the first 1058 CERT contain an end-entity certificate which can be used to 1059 authenticate the peer. 1061 3.3.11.4. Duplicate Certificate Payloads 1063 Implementations MUST support receiving multiple identical CERTs 1064 during an exchange. 1066 3.3.11.5. Irrelevant Certificates 1068 Implementations MUST be prepared to receive certificates and CRLs 1069 which are not relevant to the current exchange. Implementations MAY 1070 discard such extraneous certificates and CRLs. 1072 Implementations MAY send certificates which are irrelevant to an 1073 exchange. One reason for including certificates which are irrelevant 1074 to an exchange is to minimize the threat of leaking identifying 1075 information in exchanges where CERT is not encrypted. It should be 1076 noted, however, that this probably provides rather poor protection 1077 against leaking the identity. 1079 Another reason for including certificates that seem irrelevant to an 1080 exchange is that there may be two chains from the Certification 1081 Authority to the end entity, each of which is only valid with certain 1082 validation parameters (such as acceptable policies). Since the end- 1083 entity doesn't know which parameters the relying party is using, it 1084 should send the certificates needed for both chains (even if there's 1085 only one CERTREQ). 1087 Implementations SHOULD NOT send multiple end-entity certificates and 1088 recipients SHOULD NOT be expected to iterate over multiple end-entity 1089 certificates. 1091 3.3.12. Optimizations 1093 3.3.12.1. Duplicate Certificate Payloads 1095 Implementations SHOULD NOT send duplicate CERTs during an exchange. 1096 Such payloads should be suppressed. 1098 3.3.12.2. Send Lowest 'Common' Certificates 1100 When multiple CERTREQs are received which specify certificate 1101 authorities within the end-entity certificate chain, implementations 1102 MAY send the shortest chain possible. However, implementations 1103 SHOULD always send the end-entity certificate. See Section 3.2.10.2 1104 for more discussion of this optimization. 1106 3.3.12.3. Ignore Duplicate Certificate Payloads 1108 Implementations MAY employ local means to recognize CERTs that have 1109 already been received and SHOULD discard these duplicate CERTs. 1111 3.3.12.4. Hash Payload 1113 IKEv1 specifies the optional use of the Hash Payload to carry a 1114 pointer to a certificate in either of the Phase 1 public key 1115 encryption modes. This pointer is used by an implementation to 1116 locate the end-entity certificate that contains the public key that a 1117 peer should use for encrypting payloads during the exchange. 1119 Implementations SHOULD include this payload whenever the public 1120 portion of the keypair has been placed in a certificate. 1122 4. Profile of PKIX 1124 Except where specifically stated in this document, implementations 1125 MUST conform to the requirements of PKIX [5]. 1127 4.1. X.509 Certificates 1129 Users deploying IKE and IPsec with certificates have often had little 1130 control over the capabilities of CAs available to them. 1131 Implementations of this specification may include configuration knobs 1132 to disable checks required by this specification in order to permit 1133 use with inflexible and/or noncompliant CAs. However, all checks on 1134 certificates exist for a specific reason involving the security of 1135 the entire system. Therefore, all checks MUST be enabled by default. 1136 Administrators and users ought to understand the security purpose for 1137 the various checks, and be clear on what security will be lost by 1138 disabling the check. 1140 4.1.1. Versions 1142 Although PKIX states that "implementations SHOULD be prepared to 1143 accept any version certificate", in practice this profile requires 1144 certain extensions that necessitate the use of Version 3 certificates 1145 for all but self-signed certificates used as trust anchors. 1146 Implementations that conform to this document MAY therefore reject 1147 Version 1 and Version 2 certificates in all other cases. 1149 4.1.2. SubjectName 1151 Certification Authority implementations MUST be able to create 1152 certificates with SubjectName fields with at least the following four 1153 attributes: CN, C, O, OU. Implementations MAY support other 1154 SubjectName attributes as well. The contents of these attributes 1155 SHOULD be configurable on a certificate by certificate basis, as 1156 these fields will likely be used by IKE implementations to match SPD 1157 policy. 1159 See Section 3.1.5 for details on how IKE implementations need to be 1160 able to process SubjectName field attributes for SPD policy lookup. 1162 4.1.2.1. Empty SubjectName 1164 IKE Implementations MUST accept certificates which contain an empty 1165 SubjectName field, as specified in PKIX. Identity information in 1166 such certificates will be contained entirely in the SubjectAltName 1167 extension. 1169 4.1.2.2. Specifying Hosts and not FQDN in SubjectName 1171 Implementations which desire to place host names that are not 1172 intended to be processed by recipients as FQDNs (for instance 1173 "Gateway Router") in the SubjectName MUST use the commonName 1174 attribute. 1176 4.1.2.3. EmailAddress 1178 As specified in PKIX, implementations MUST NOT populate 1179 DistinguishedNames with the emailAddress attribute. 1181 4.1.3. X.509 Certificate Extensions 1183 Conforming IKE implementations MUST recognize extensions which must 1184 or may be marked critical according to this specification. These 1185 extensions are: KeyUsage, SubjectAltName, and BasicConstraints. 1187 Certification Authority implementations SHOULD generate certificates 1188 such that the extension criticality bits are set in accordance with 1189 PKIX and this document. With respect to PKIX compliance, IKE 1190 implementations processing certificates MAY ignore the value of the 1191 criticality bit for extensions that are supported by that 1192 implementation, but MUST support the criticality bit for extensions 1193 that are not supported by that implementation. That is, a relying 1194 party processes all the extensions it is aware of whether the bit is 1195 true or false -- the bit says what happens when a relying party 1196 cannot process an extension. 1198 implements bit in cert PKIX mandate behavior 1199 ------------------------------------------------------ 1200 yes true true ok 1201 yes true false ok or reject 1202 yes false true ok or reject 1203 yes false false ok 1204 no true true reject 1205 no true false reject 1206 no false true reject 1207 no false false ok 1209 4.1.3.1. AuthorityKeyIdentifier and SubjectKeyIdentifier 1211 Implementations SHOULD NOT assume support for the 1212 AuthorityKeyIdentifier or SubjectKeyIdentifier extensions, and thus 1213 Certification Authority implementations SHOULD NOT generate 1214 certificate hierarchies which are overly complex to process in the 1215 absence of these extensions, such as those that require possibly 1216 verifying a signature against a large number of similarly named CA 1217 certificates in order to find the CA certificate which contains the 1218 key that was used to generate the signature. 1220 4.1.3.2. KeyUsage 1222 IKE uses an end-entity certificate in the authentication process. 1223 The end-entity certificate may be used for multiple applications. As 1224 such, the CA can impose some constraints on the manner that a public 1225 key ought to be used. The KeyUsage and ExtendedKeyUsage extensions 1226 apply in this situation. 1228 Since we are talking about using the public key to validate a 1229 signature, if the KeyUsage extension is present, then at least one of 1230 the digitalSignature or the nonRepudiation bits in the KeyUsage 1231 extension MUST be set (both can be set as well). It is also fine if 1232 other KeyUsage bits are set. 1234 A summary of the logic flow for peer cert validation follows: 1236 o If no KU extension, continue. 1237 o If KU present and doesn't mention digitalSignature or 1238 nonRepudiation (both, in addition to other KUs, is also fine), 1239 reject cert. 1240 o If none of the above, continue. 1242 4.1.3.3. PrivateKeyUsagePeriod 1244 PKIX recommends against the use of this extension. The 1245 PrivateKeyUsageExtension is intended to be used when signatures will 1246 need to be verified long past the time when signatures using the 1247 private keypair may be generated. Since IKE SAs are short-lived 1248 relative to the intended use of this extension in addition to the 1249 fact that each signature is validated only a single time, the 1250 usefulness of this extension in the context of IKE is unclear. 1251 Therefore, Certification Authority implementations MUST NOT generate 1252 certificates that contain the PrivateKeyUsagePeriod extension. If an 1253 IKE implementation receives a certificate with this set, it SHOULD 1254 ignore it. 1256 4.1.3.4. CertificatePolicies 1258 Many IKE implementations do not currently provide support for the 1259 CertificatePolicies extension. Therefore, Certification Authority 1260 implementations that generate certificates which contain this 1261 extension SHOULD NOT mark the extension as critical. 1263 4.1.3.5. PolicyMappings 1265 Many IKE implementations do not support the PolicyMappings extension. 1266 Therefore, implementations that generate certificates which contain 1267 this extension SHOULD NOT mark the extension as critical. 1269 4.1.3.6. SubjectAltName 1271 Deployments that intend to use an ID of either FQDN, USER_FQDN, 1272 IPV4_ADDR or IPV6_ADDR MUST issue certificates with the corresponding 1273 SubjectAltName fields populated with the same data. Implementations 1274 SHOULD generate only the following GeneralName choices in the 1275 SubjectAltName extension, as these choices map to legal IKEv1/ISAKMP/ 1276 IKEv2 Identification Payload types: rfc822Name, dNSName, or 1277 iPAddress. Although it is possible to specify any GeneralName choice 1278 in the Identification Payload by using the ID_DER_ASN1_GN ID type, 1279 implementations SHOULD NOT assume support for such functionality, and 1280 SHOULD NOT generate certificates that do so. 1282 4.1.3.6.1. dNSName 1284 This field MUST contain a fully qualified domain name. If the IKE ID 1285 type is FQDN then the dNSName field MUST match its contents. 1286 Implementations MUST NOT generate names that contain wildcards. 1287 Implementations MAY treat certificates that contain wildcards in this 1288 field as syntactically invalid. 1290 Although this field is in the form of an FQDN, IKE implementations 1291 SHOULD NOT assume that this field contains an FQDN that will resolve 1292 via the DNS, unless this is known by way of some out-of-band 1293 mechanism. Such a mechanism is out of the scope of this document. 1294 Implementations SHOULD NOT treat the failure to resolve as an error. 1296 4.1.3.6.2. iPAddress 1298 If the IKE ID type is IPV4_ADDR or IPV6_ADDR then the iPAddress field 1299 MUST match its contents. Note that although PKIX permits CIDR [14] 1300 notation in the "Name Constraints" extension, PKIX explicitly 1301 prohibits using CIDR notation for conveying identity information. In 1302 other words, the CIDR notation MUST NOT be used in the SubjectAltName 1303 extension. 1305 4.1.3.6.3. rfc822Name 1307 If the IKE ID type is USER_FQDN then the rfc822Name field MUST match 1308 its contents. Although this field is in the form of an Internet mail 1309 address, IKE implementations SHOULD NOT assume that this field 1310 contains a valid email address, unless this is known by way of some 1311 out-of-band mechanism. Such a mechanism is out of the scope of this 1312 document. 1314 4.1.3.7. IssuerAltName 1316 Certification Authority implementations SHOULD NOT assume that other 1317 implementations support the IssuerAltName extension, and especially 1318 should not assume that information contained in this extension will 1319 be displayed to end users. 1321 4.1.3.8. SubjectDirectoryAttributes 1323 The SubjectDirectoryAttributes extension is intended to convey 1324 identification attributes of the subject. IKE implementations MAY 1325 ignore this extension when it is marked non-critical, as PKIX 1326 mandates. 1328 4.1.3.9. BasicConstraints 1330 PKIX mandates that CA certificates contain this extension and that it 1331 be marked critical. IKE implementations SHOULD reject CA 1332 certificates that do not contain this extension. For backwards 1333 compatibility, implementations may accept such certificates if 1334 explicitly configured to do so, but the default for this setting MUST 1335 be to reject such certificates. 1337 4.1.3.10. NameConstraints 1339 Many IKE implementations do not support the NameConstraints 1340 extension. Since PKIX mandates that this extension be marked 1341 critical when present, Certification Authority implementations which 1342 are interested in maximal interoperability for IKE SHOULD NOT 1343 generate certificates which contain this extension. 1345 4.1.3.11. PolicyConstraints 1347 Many IKE implementations do not support the PolicyConstraints 1348 extension. Since PKIX mandates that this extension be marked 1349 critical when present, Certification Authority implementations which 1350 are interested in maximal interoperability for IKE SHOULD NOT 1351 generate certificates which contain this extension. 1353 4.1.3.12. ExtendedKeyUsage 1355 The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in 1356 certificates for use with IKE. Note that there were three IPsec 1357 related object identifiers in EKU that were assigned in 1999. The 1358 semantics of these values were never clearly defined. The use of 1359 these three EKU values in IKE/IPsec is obsolete and explicitly 1360 deprecated by this specification. CAs SHOULD NOT issue certificates 1361 for use in IKE with them. (For historical reference only, those 1362 values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp- 1363 ipsecUser.) 1365 The CA SHOULD NOT mark the EKU extension in certificates for use with 1366 IKE and one or more other applications. Nevertheless, this document 1367 defines an ExtendedKeyUsage keyPurposeID that MAY be used to limit a 1368 certificate's use: 1370 id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 } 1372 where id-kp is defined in RFC-3280 [5]. If a certificate is intended 1373 to be used with both IKE and other applications, and one of the other 1374 applications requires use of an EKU value, then such certificates 1375 MUST contain either the keyPurposeID id-kp-ipsecIKE or 1376 anyExtendedKeyUsage [5] as well as the keyPurposeID values associated 1377 with the other applications. Similarly, if a CA issues multiple 1378 otherwise-similar certificates for multiple applications including 1379 IKE, and it is intended that the IKE certificate NOT be used with 1380 another application, the IKE certificate MAY contain an EKU extension 1381 listing a keyPurposeID of id-kp-ipsecIKE to discourage its use with 1382 the other application. Recall however, EKU extensions in 1383 certificates meant for use in IKE are NOT RECOMMENDED. 1385 A summary of the logic flow for peer certificate validation regarding 1386 the EKU extension follows: 1388 o If no EKU extension, continue. 1389 o If EKU present AND contains either id-kp-ipsecIKE or 1390 anyExtendedKeyUsage, continue. 1391 o Otherwise, reject cert. 1393 4.1.3.13. CRLDistributionPoints 1395 Because this document deprecates the sending of CRLs in-band, the use 1396 of CRLDistributionPoints (CDP) becomes very important if CRLs are 1397 used for revocation checking (as opposed to say Online Certificate 1398 Status Protocol - OCSP [15]). The IPsec peer either needs to have a 1399 URL for a CRL written into its local configuration, or it needs to 1400 learn it from CDP. Therefore, Certification Authority 1401 implementations SHOULD issue certificates with a populated CDP. 1403 Failure to validate the CRLDistributionPoints/ 1404 IssuingDistributionPoint pair can result in CRL substitution where an 1405 entity knowingly substitutes a known good CRL from a different 1406 distribution point for the CRL which is supposed to be used which 1407 would show the entity as revoked. IKE implementations MUST support 1408 validating that the contents of CRLDistributionPoints match those of 1409 the IssuingDistributionPoint to prevent CRL substitution when the 1410 issuing CA is using them. At least one CA is known to default to 1411 this type of CRL use. See Section 4.2.2.5 for more information. 1413 CDPs SHOULD be "resolvable". Several non-compliant Certification 1414 Authority implementations are well known for including unresolvable 1415 CDPs like http://localhost/path_to_CRL and http:///path_to_CRL which 1416 are equivalent to failing to include the CDP extension in the 1417 certificate. 1419 See PKIX docs for CRLDistributionPoints intellectual property rights 1420 (IPR) information. Note that both the CRLDistributionPoints and 1421 IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED 1422 by PKIX, so there is no requirement to license any IPR. 1424 4.1.3.14. InhibitAnyPolicy 1426 Many IKE implementations do not support the InhibitAnyPolicy 1427 extension. Since PKIX mandates that this extension be marked 1428 critical when present, Certification Authority implementations which 1429 are interested in maximal interoperability for IKE SHOULD NOT 1430 generate certificates which contain this extension. 1432 4.1.3.15. FreshestCRL 1434 IKE implementations MUST NOT assume that the FreshestCRL extension 1435 will exist in peer certificates. Note that most IKE implementations 1436 do not support delta CRLs. 1438 4.1.3.16. AuthorityInfoAccess 1440 PKIX defines the AuthorityInfoAccess extension, which is used to 1441 indicate "how to access CA information and services for the issuer of 1442 the certificate in which the extension appears." Because this 1443 document deprecates the sending of CRLs in band, the use of 1444 AuthorityInfoAccess (AIA) becomes very important if OCSP [15] is to 1445 be used for revocation checking (as opposed to CRLs). The IPsec peer 1446 either needs to have a URI for the OCSP query written into its local 1447 configuration, or it needs to learn it from AIA. Therefore, 1448 implementations SHOULD support this extension, especially if OCSP 1449 will be used. 1451 4.1.3.17. SubjectInfoAccess 1453 PKIX defines the SubjectInfoAccess certificate extension, which is 1454 used to indicate "how to access information and services for the 1455 subject of the certificate in which the extension appears." This 1456 extension has no known use in the context of IPsec. Conformant IKE 1457 implementations SHOULD ignore this extension when present. 1459 4.2. X.509 Certificate Revocation Lists 1461 When validating certificates, IKE implementations MUST make use of 1462 certificate revocation information, and SHOULD support such 1463 revocation information in the form of CRLs, unless non-CRL revocation 1464 information is known to be the only method for transmitting this 1465 information. Deployments that intend to use CRLs for revocation 1466 SHOULD populate the CRLDistributionPoints extension. Therefore 1467 Certification Authority implementations MUST support issuing 1468 certificates with this field populated according to administrator's 1469 needs. IKE implementations MAY provide a configuration option to 1470 disable use of certain types of revocation information, but that 1471 option MUST be off by default. Such an option is often valuable in 1472 lab testing environments. 1474 4.2.1. Multiple Sources of Certificate Revocation Information 1476 IKE implementations which support multiple sources of obtaining 1477 certificate revocation information MUST act conservatively when the 1478 information provided by these sources is inconsistent: when a 1479 certificate is reported as revoked by one trusted source, the 1480 certificate MUST be considered revoked. 1482 4.2.2. X.509 Certificate Revocation List Extensions 1484 4.2.2.1. AuthorityKeyIdentifier 1486 Certification Authority implementations SHOULD NOT assume that IKE 1487 implementations support the AuthorityKeyIdentifier extension, and 1488 thus SHOULD NOT generate certificate hierarchies which are overly 1489 complex to process in the absence of this extension, such as those 1490 that require possibly verifying a signature against a large number of 1491 similarly named CA certificates in order to find the CA certificate 1492 which contains the key that was used to generate the signature. 1494 4.2.2.2. IssuerAltName 1496 Certification Authority implementations SHOULD NOT assume that IKE 1497 implementations support the IssuerAltName extension, and especially 1498 should not assume that information contained in this extension will 1499 be displayed to end users. 1501 4.2.2.3. CRLNumber 1503 As stated in PKIX, all issuers conforming to PKIX MUST include this 1504 extension in all CRLs. 1506 4.2.2.4. DeltaCRLIndicator 1508 4.2.2.4.1. If Delta CRLs Are Unsupported 1510 IKE implementations that do not support delta CRLs MUST reject CRLs 1511 which contain the DeltaCRLIndicator (which MUST be marked critical 1512 according to PKIX) and MUST make use of a base CRL if it is 1513 available. Such implementations MUST ensure that a delta CRL does 1514 not "overwrite" a base CRL, for instance in the keying material 1515 database. 1517 4.2.2.4.2. Delta CRL Recommendations 1519 Since some IKE implementations that do not support delta CRLs may 1520 behave incorrectly or insecurely when presented with delta CRLs, 1521 administrators and deployers should consider whether issuing delta 1522 CRLs increases security before issuing such CRLs. And, if all the 1523 elements in the VPN and PKI systems do not adequately support Delta 1524 CRLs, then their use should be questioned. 1526 The editors are aware of several implementations which behave in an 1527 incorrect or insecure manner when presented with delta CRLs. See 1528 Appendix B for a description of the issue. Therefore, this 1529 specification RECOMMENDS NOT issuing delta CRLs at this time. On the 1530 other hand, failure to issue delta CRLs may expose a larger window of 1531 vulnerability if a full CRL is not issued as often as delta CRLs 1532 would be. See the Security Considerations section of PKIX [5] for 1533 additional discussion. Implementors as well as administrators are 1534 encouraged to consider these issues. 1536 4.2.2.5. IssuingDistributionPoint 1538 A CA that is using CRLDistributionPoints may do so to provide many 1539 "small" CRLs, each only valid for a particular set of certificates 1540 issued by that CA. To associate a CRL with a certificate, the CA 1541 places the CRLDistributionPoints extension in the certificate, and 1542 places the IssuingDistributionPoint in the CRL. The 1543 distributionPointName field in the CRLDistributionPoints extension 1544 MUST be identical to the distributionPoint field in the 1545 IssuingDistributionPoint extension. At least one CA is known to 1546 default to this type of CRL use. See Section 4.1.3.13 for more 1547 information. 1549 4.2.2.6. FreshestCRL 1551 Given the recommendations against Certification Authority 1552 implementations generating delta CRLs, this specification RECOMMENDS 1553 that implementations do not populate CRLs with the FreshestCRL 1554 extension, which is used to obtain delta CRLs. 1556 5. Configuration Data Exchange Conventions 1558 Below we present a common format for exchanging configuration data. 1559 Implementations MUST support these formats, MUST support receiving 1560 arbitrary whitespace at the beginning and end of any line, MUST 1561 support receiving arbitrary line lengths although they SHOULD 1562 generate lines less than 76 characters, and MUST support receiving 1563 the following three line-termination disciplines: LF (US-ASCII 10), 1564 CR (US-ASCII 13), and CRLF. 1566 5.1. Certificates 1568 Certificates MUST be Base64 encoded and appear between the following 1569 delimiters: 1571 -----BEGIN CERTIFICATE----- 1572 -----END CERTIFICATE----- 1574 5.2. CRLs and ARLs 1576 CRLs and ARLs MUST be Base64 encoded and appear between the following 1577 delimiters: 1579 -----BEGIN CRL----- 1580 -----END CRL----- 1582 5.3. Public Keys 1584 IKE implementations MUST support two forms of public keys: 1585 certificates and so-called "raw" keys. Certificates should be 1586 transferred in the same form as above. A raw key is only the 1587 SubjectPublicKeyInfo portion of the certificate, and MUST be Base64 1588 encoded and appear between the following delimiters: 1590 -----BEGIN PUBLIC KEY----- 1591 -----END PUBLIC KEY----- 1593 5.4. PKCS#10 Certificate Signing Requests 1595 A PKCS#10 [9] Certificate Signing Request MUST be Base64 encoded and 1596 appear between the following delimiters: 1598 -----BEGIN CERTIFICATE REQUEST----- 1599 -----END CERTIFICATE REQUEST----- 1601 6. Security Considerations 1603 6.1. Certificate Request Payload 1605 The Contents of CERTREQ are not encrypted in IKE. In some 1606 environments this may leak private information. Administrators in 1607 some environments may wish to use the empty Certification Authority 1608 option to prevent such information from leaking, at the cost of 1609 performance. 1611 6.2. IKEv1 Main Mode 1613 Certificates may be included in any message, and therefore 1614 implementations may wish to respond with CERTs in a message that 1615 offers privacy protection, in Main Mode messages 5 and 6. 1616 Implementations may not wish to respond with CERTs in the second 1617 message, thereby violating the identity protection feature of Main 1618 Mode in IKEv1. 1620 6.3. Disabling Certificate Checks 1622 It is important to note that anywhere this document suggests 1623 implementors provide users with the configuration option to simplify, 1624 modify, or disable a feature or verification step, there may be 1625 security consequences for doing so. Deployment experience has shown 1626 that such flexibility may be required in some environments, but 1627 making use of such flexibility can be inappropriate in others. Such 1628 configuration options MUST default to "enabled" and it is appropriate 1629 to provide warnings to users when disabling such features. 1631 6.4. Strength of Signature Hashing Algorithms 1633 At the time that this document is being written, popular 1634 certification authorities and CA software issue certificates using 1635 the RSA-with-SHA1 and RSA-with-MD5 signature algorithms. 1636 Implementations MUST be able to validate certificates with either of 1637 those algorithms. 1639 As described in [16], both the MD5 and SHA-1 hash algorithms are 1640 weaker than originally expected with respect to hash collisions. 1641 Certificates that use these hash algorithms as part of their 1642 signature algorithms could conceivably be subject to an attack where 1643 a CA issues a certificate with a particular identity, and the 1644 recipient of that certificate can create a different valid 1645 certificate with a different identity. So far, such an attack is 1646 only theoretical, even with the weaknesses found in the hash 1647 algorithms. 1649 Because of the recent attacks, there has been a heightened interest 1650 in having widespread deployment of additional signature algorithms. 1651 The algorithm that has been mentioned most often is RSA-with-SHA256, 1652 two types of which are described in detail in [17]. It is widely 1653 expected that this signature algorithm will be much more resilient to 1654 collision-based attacks than the current RSA-with-SHA1 and RSA-with- 1655 MD5, although no proof of that has been shown. There is active 1656 discussion in the cryptographic community of better hash functions 1657 that could be used in signature algorithms. 1659 In order to interoperate, all implementations need to be able to 1660 validate signatures for all algorithms that the implementations will 1661 encounter. Therefore, implementations SHOULD be able to use 1662 signatures that use the sha256WithRSAEncryption signature algorithm 1663 (PKCS#1 version 1.5) as soon as possible. At the time that this 1664 document is being written, there are no common implementations that 1665 issue certificates with this algorithm, but it is expected that there 1666 will be significant deployment of this algorithm by the end of 2007. 1668 7. Intellectual Property Rights 1670 No new intellectual property rights are introduced by this document. 1672 8. IANA Considerations 1674 There are no known numbers which IANA will need to manage. 1676 9. References 1678 9.1. Normative References 1680 [1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1681 RFC 2409, November 1998. 1683 [2] Maughan, D., Schneider, M., and M. Schertler, "Internet Security 1684 Association and Key Management Protocol (ISAKMP)", RFC 2408, 1685 November 1998. 1687 [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1688 draft-ietf-ipsec-ikev2-15 (work in progress), August 2004. 1690 [4] Kent, S. and R. Atkinson, "Security Architecture for the 1691 Internet Protocol", RFC 2401, November 1998. 1693 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1694 Public Key Infrastructure Certificate and Certificate Revocation 1695 List (CRL) Profile", RFC 3280, April 2002. 1697 [6] Piper, D., "The Internet IP Security Domain of Interpretation 1698 for ISAKMP", RFC 2407, November 1998. 1700 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1701 Levels", BCP 14, RFC 2119, March 1997. 1703 [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 1705 [9] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1706 1.5", RFC 2314, March 1998. 1708 9.2. Informative References 1710 [10] Kent, S. and K. Seo, "Security Architecture for the Internet 1711 Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), 1712 March 2005. 1714 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1715 Specification", RFC 1883, December 1995. 1717 [12] Eastlake, D., "Domain Name System Security Extensions", 1718 RFC 2535, March 1999. 1720 [13] Lynn, C., "X.509 Extensions for IP Addresses and AS 1721 Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in 1722 progress), September 2003. 1724 [14] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- 1725 Domain Routing (CIDR): an Address Assignment and Aggregation 1726 Strategy", RFC 1519, September 1993. 1728 [15] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, 1729 "X.509 Internet Public Key Infrastructure Online Certificate 1730 Status Protocol - OCSP", RFC 2560, June 1999. 1732 [16] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes 1733 in Internet Protocols", RFC 4270, November 2005. 1735 [17] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms 1736 and Identifiers for RSA Cryptography for use in the Internet 1737 X.509 Public Key Infrastructure Certificate and Certificate 1738 Revocation List (CRL) Profile", RFC 4055, June 2005. 1740 [18] Arsenault, A. and S. Turner, "Internet X.509 Public Key 1741 Infrastructure: Roadmap", draft-ietf-pkix-roadmap-09 (work in 1742 progress), July 2002. 1744 Appendix A. Change History 1746 February 2006 (-08) 1748 * 3.2.6 - clarified text, that it applies to Main Mode only 1749 * Added text to security considerations regarding SHA-256 (30 Jan 1750 2005 pki4ipsec email from Paul Hoffman) 1752 November 2005 (-07) 1754 * 3.1 - renumbered table notes to avoid confusion with references 1755 (9 Nov 2005 pki4ipsec email from Jim Schaad) 1756 * 3.2.2 - changed "signing certificate" to "a certificate used 1757 for signing" (9 Nov 2005 pki4ipsec email from Jim Schaad) 1758 * 4.1 - added text re: implications of disabling checks ("escape 1759 clause") (8 Nov 2005 pki4ipsec email from Bill Sommerfeld, 10 1760 Nov 2005 pki4ipsec email from Gregory M Lebovitz) 1761 * 4.1.3.2 - removed text from pseudocode: "If told (by 1762 configuration) to ignore KeyUsage (KU), accept cert regardless 1763 of its markings." 1764 * 4.1.3.12 - replaced text with clearer text (8 Nov 2005 1765 pki4ipsec email from Bill Sommerfeld) 1766 * 4.1.3.12 - removed text from pseudocode: "If told (by 1767 configuration) to ignore ExtendedKeyUsage (EKU), accept cert 1768 regardless of the presence or absence of the extension." 1769 * 4.1.3.17 - removed gratuitous "private" modifier from 1770 SubjectInfoAccess section (9 Nov 2005 pki4ipsec email from Jim 1771 Schaad) 1772 * 4.2.2.4.2 - clarified delta CRL text so that it no longer could 1773 be read as implying that full CRLs can't be issued at the time 1774 a certificate is revoked. (9 Nov 2005 pki4ipsec email from Jim 1775 Schaad) 1777 * Security Considerations - added "Disabling Certificate Checks" 1778 section 1780 October 2005 (-06) 1782 * 4.1.3.12 - added text re: id-kp-ipsecIKE 1784 July 2005 (-05) 1786 * 3.1 - added "See 2401bis [10], section 4.4.3.2 for more 1787 details." to resolve issue #561. 1788 * 3.1.10 - added text pointing to PAD in 2401bis [10] to 1789 discussion of binding identity to policy. 1791 December 2004 (-04) 1793 * Added Paul Hoffman's text from issue #708 1794 * Added text explaining that it's possible for a recipient to 1795 receive CERT payloads containing certs that the recipient 1796 considers a trust anchor (15 Nov 2004 pki4ipsec email from 1797 Peter Williams) 1798 * Replaced text in 4.1.3 with Kent's text (issue #655) (22 Nov 1799 2004 pki4ipsec email from Stephen Kent, Paul Hoffman) 1801 September 2004 (-03) 1803 * Minor editorial changes in abstract and introduction clarifing 1804 when something is from IPsec, IKE, etc 1805 * Minor editorial changes throughout 1806 * Fixed "Certification Authority" instead of "Certificate 1807 Authority" 1808 * Cleaned up initiator/responder when really referred to sender/ 1809 recipient 1810 * Fixed inconsistancy in text by making sure that all text on the 1811 topic of sending CERTREQs follow Gregory Lebovitz's proposal 1812 for CERT payloads: "should deal with all the CRL, Intermediat 1813 Certs, Trust Anchors, etc OOB of IKE; MUST be able to send and 1814 receive EE cert payload; only real exception is Intermediate 1815 Cets which MAY be sent and SHOULD be able to be receivable (but 1816 in reality there are very few hierarchies in operation, so 1817 really it's a corner case); SHOULD NOT send the other stuff 1818 (CRL, Trust Anchors, etc) in cert payloads in IKE; SHOULD be 1819 able to accept the other stuff if by chance it gets sent, 1820 though we hope they don't get sent" 1822 * 3.1 - removed text suggesting that it would be reasonable to 1823 terminate IKEv2 processing if the initiator were to receive a 1824 responder-generated IDr 1825 * 3.1.1 - noted that certificates may contain multiple IP 1826 addresses 1827 * 3.1.9 - removed (temporarily?) confusing text stating that 1828 overlapping policies was prohibited, text which was 1829 inconsistent with text right above it 1830 * 3.2.7.2 - SHOULD changed to MUST terminate if peer's 1831 certificate chain violates local policy 1832 * 3.3 - removed text implying that pausing in the middle of an 1833 IKE exchange in order to obtain revocation status information 1834 via http or OCSP would reduce latency in IKE 1835 * 4.2 - allow deployments that don't wish to populate CDP (for 1836 instance if a source of revocation information is configured 1837 via some other means) to skip populating CDP, making consistent 1838 with 4.1.3.13 and the issues IPR spelled out in PKIX 1839 * Somehow a CRL out-of-band configuration format had been 1840 omitted. 1841 * #555: Kent-1.0 Introduction - document now references IKEv2 1842 * #559: Kent-Profile Document 3.1.0 - use sender/recipient 1843 instead of agent 1844 * #564: Kent-Profile Document 3.1.1 - specified that support for 1845 ID_IPV4_ADDR and/or ID_IPV6_ADDR are contingent on device 1846 support for IPv4 and/or IPv6 1847 * #568: Kent-Profile document 3.1.4 - specified that there wasn't 1848 a standard and besides no one has implemented it 1849 * #571: Kent-Profile document 3.1.8 - tried to be even more 1850 clearer than was asked for by spelling things out in detail 1851 * #572: Kent-Profile document 3.1.8 Formerly issue #18 - now 1852 specifies that it's only a local matter if that information is 1853 not coordinated with other administrators 1854 * #573: Kent-Profile document 3.2.3/Myers - revocation 1855 information no longer exchanged in-band, plus Mike Myers has 1856 submitted an OCSP w/IKE draft, which is references by this 1857 document. 1858 * #578 Kent-Profile document 4.0.0 - went through entire PKIX 1859 profile section and prefaced "implementation" with "IKE" or 1860 "Certification Authority" wherever it was sure to be one or the 1861 other 1862 * #581: Kent-Profile document 4.1.3.9 - replaced description with 1863 text from RFC 2459 1864 * #584: Maillist-Lebovitz PKI Life Cycle-Revocation - fixed 1865 * #586: Maillist-Allison Empty CertReq - there is now lots of 1866 text dealing with when empty certreqs are permitted 1867 * 3.2.7.1 - CERTREQ only mandatory if in-band exchange of keymat 1868 is desired (28 Jul 2004 pki4ipsec email from jknowles@ 1869 SonicWALL.com) 1871 * 3.3.6 - clarified that "non-compliant" means not sending a 1872 CERTREQ (28 Jul 2004 pki4ipsec email from jknowles@ 1873 SonicWALL.com) 1874 * 3.2.7.1 - fixed contradition: mandatory to respond to CERTREQ 1875 UNLESS configured not to (28 Jul 2004 pki4ipsec email from 1876 jknowles@SonicWALL.com) 1877 * 3.2.9.2 and 3.2.9.3 - CERTREQ contains an issuer name only for 1878 IKEv2 (19 Sep 2004 email from Charlie Kaufman) 1879 * Answered 'Section 3.1.9 para 2: "The initiator MUST know by 1880 policy..." is a difficult to interpret requirement. It could 1881 mean that it must be possible to configure in policy which ID 1882 is to be sent. Did you mean "the initiator must decide...", 1883 where the decision might be wired into a particular 1884 implementation?' by changing it to be merely descriptive, and 1885 to refer to policy configuration (19 Sep 2004 email from 1886 Charlie Kaufman) 1887 * IPSEC -> IPsec (19 Sep 2004 email from Charlie Kaufman) 1888 * 3.1.1 para 1: "MUST be stored" changed to "MUST be encoded" (19 1889 Sep 2004 email from Charlie Kaufman) 1890 * 3.1.5 para 2 - made it clear that empty SubjectNames are 1891 permitted by PKIX in certificates, but this document doesn't 1892 permit them in ID (19 Sep 2004 email from Charlie Kaufman) 1893 * 3.2.7.1 - clarified by specifying that it's a trust anchor 1894 that's being chosen, not end-entity certificate (19 Sep 2004 1895 email from Charlie Kaufman) 1896 * 3.3.9.5 - fixed confusing last paragraph (19 Sep 2004 email 1897 from Charlie Kaufman) 1898 * 3.3.10.3 - made it more clear that this section is really 1899 talking about duplicate certificate payloads (19 Sep 2004 email 1900 from Charlie Kaufman) 1901 * 4.1.2.2 para 2 and 3 - moved to 3.1.x section where is belongs 1902 (19 Sep 2004 email from Charlie Kaufman) 1903 * 4.1.3.5 - the last sentence of 4.1.3.4 copied here (19 Sep 2004 1904 email from Charlie Kaufman) 1905 * 4.2.2.4.2 - SHOULD -> should (19 Sep 2004 email from Charlie 1906 Kaufman) 1907 * 3.2.5 and 3.3.4 - added description of URL scheme support (16 1908 Aug 2004 pki4ipsec email from Tero Kivinen) 1909 * Removed 6.1 and 6.3 because they were either incorrect or 1910 didn't add any new security considerations above and beyond the 1911 IKE documents. 1912 August 2004 (-02) (Edited by Gregory Lebovitz, with XML formatting 1913 and cross-referencing by Paul Knight) 1915 * 3.1.1 the text between the **s was added to paragraph, per the 1916 question that arose in IETF60 WG session: Implementations MUST 1917 be capable of verifying that the address contained in the ID is 1918 the same as the peer source address **contained in the outer 1919 most IP header**. 1920 * 3.2.7 - added HTTP_CERT_LOOKUP_SUPPORTED to this section and 1921 described its use - #38 1922 * 3.3 - changed back sending of intermediate CA certificates from 1923 SHOULD NOT to MAY (for backward compatibility). Added text to 1924 explain further why we want to stay away from actually doing it 1925 though. 1926 * 3.3.8 - changed text per Knowles/Korver 2004.07.28. 1927 * 3.3.9.5 - Change discard of Irrelevant Certificates from may to 1928 SHOULD - #23(Kent 2004.04.26) 1929 * 4.1.3.2 KU - re-worked to reflect discussion on list and in 1930 IETF60 - #36 1931 * 4.1.3.12 EKU - re-worked to reflect discussion on list and in 1932 IETF60 - #36 1933 * [IKEv2] update the reference to the -14 draft of May 29, 2004 1935 July 2004 (-01) (Edited by Gregory Lebovitz) 1937 * Changed ISAKMP references in Abstract and Intro to IKE. 1938 * Editorial changes to make the text conform with the summary 1939 table in 3.1, especially in the text following the table in 1940 3.1. Particular note should be paid to changes in section 1941 3.5.1. 1942 * Sect 3.1.1 - editorial changes to aid in clarification. Added 1943 text on when deployers might consider using IP addr, but 1944 strongly encouraged not to. 1945 * Sect 3.1.8 removed IP address from list of practically used ID 1946 types. 1947 * 3.1.9 overhauled (per Kivinen, July 18) 1948 * 3.2 - added IKEv2's Hash and URL of x.509 to list of those 1949 profiled and gave it its own section, now 3.2.5 1950 * added note in CRL/ARL section about revocation occurring OOB of 1951 IKE 1952 * deleted ARL as its own section and collapsed it into Revocation 1953 Lists (CRL and ARL) for consciseness. Renumbered accordingly. 1954 * Sect 3.2.7.2 - Changed from MUST not send empty certreqs to 1955 SHOULD send CERTREQs which contain CA fields with direction on 1956 how, but MAY send empty CERTREQs in certain case. Use case 1957 added, and specifics of both initiator and responder behavior 1958 listed. 1959 * APPENDIX C added to fill out the explanation (mostly discussion 1960 from list). 1961 * 3.3 - clarified that sending CRLs and chaining certs is 1962 deprecated. 1963 * added IKEv2's Hash and URL of x.509 to list of those profiled 1964 and gave it its own section. Condensed ARL into CRL and 1965 renumbered accordingly. 1967 * duplicate section was removed, renumbered accordingly 1968 * 3.3.10.2 - title changed. sending chaining becomes SHOULD NOT. 1969 * 4.1.2 added text to explicity call out support for CN, C, O, OU 1970 * collapsed 4.1.2.3 into 4.1.2.2 and renumbered accordingly. 1971 * Collapsed 4.1.3.2 into 4.1.3.1 and renumbered accordingly 1972 * Edited 4.1.3.2 Key Usage and 4.1.3.12 ExtKey Usage according to 1973 Hoffman, July18 1974 * 4.1.3.3 if receive cert w/ PKUP, ignore it. 1975 * 4.1.3.13 - CDP changed text to represent SHOULD issue, and how 1976 important CDP becomes when we do not send CRLs in-band. Added 1977 SHOULD for CDPs actually being resolvable (reilly email). 1978 * Reordered 6.4 for better clarity. 1979 * Added Rescorla to Acknowledgements section, as he is no longer 1980 listed as an editor, since -00. 1982 May 2004 (renamed draft-ietf-pki4ipsec-ikecert-profile-00.txt) 1983 (edited by Brian Korver) 1985 * Made it clearer that the format of the ID_IPV4_ADDR payload 1986 comes from RFC791 and is nothing new. (Tero Kivinen Feb 29) 1987 * Permit implementations to skip verifying that the peer source 1988 address matches the contents of ID_IPV{4,6}_ADDR. (Tero 1989 Kivinen Feb 29, Gregory Lebovitz Feb 29) 1990 * Removed paragraph suggesting that implementations favor 1991 unauthenticated peer source addresses over an unauthenticated 1992 ID for initial policy lookup. (Tero Kivinen Feb 29, Gregory 1993 Lebovitz Feb 29) 1994 * Removed some text implying RSA encryption mode was in scope. 1995 (Tero Kivinen Feb 29) 1996 * Relaxed deprecation of PKCS#7 CERT payloads. (Tero Kivinen Feb 1997 29) 1998 * Made it clearer that out-of-scope local heuristics should be 1999 used for picking an EE cert to use when generating CERTREQ, not 2000 when receiving CERTREQ. (Tero Kivinen Feb 29) 2001 * Made it clearer that CERT processing can be skipped when the 2002 contents of a CERT are already known. (Tero Kivinen Feb 29) 2003 * Implementations SHOULD generate BASE64 lines less than 76 2004 characters. (Tero Kivinen Feb 29) 2005 * Added "Except where specifically stated in this document, 2006 implementations MUST conform to the requirements of PKIX" 2007 (Steve Hanna Oct 7, 2003) 2008 * RECOMMENDS against populating the ID payload with IP addresses 2009 due to interoperability issues such as problem with NAT 2010 traversal. (Gregory Lebovitz May 14) 2011 * Changed "as revoked by one source" to "as revoked by one 2012 trusted source". (Michael Myers, May 15) 2014 * Specifying Certificate Authorities section needed to be 2015 regularized with Gregory Lebovitz's CERT proposal from -04. 2016 (Tylor Allison, May 15) 2017 * Added text specifying how recipients SHOULD NOT be expected to 2018 iterate over multiple end-entity certs. (Tylor Allison, May 2019 15) 2020 * Modified text to refer to IKEv2 as well as IKEv1/ISAKMP where 2021 relevant. 2022 * IKEv2: Explained that IDr sent by responder doesn't have to 2023 match the [IDr] sent initiator in second exchange. 2024 * IKEv2: Noted that "The identity ... does not necessarily have 2025 to match anything in the CERT payload" (S3.5) is not 2026 contradicted by SHOULD in this document. 2027 * IKEv2: Noted that ID_USER_FQDN renamed to ID_RFC822_ADDR, and 2028 ID_USER_FQDN would be used exclusively in this document. 2029 * IKEv2: Declared that 3 new CERTREQ and CERT types are not 2030 profiled in this document (well, at least not yet, pending WG 2031 discussion of what to do -- note that they are only SHOULDs in 2032 IKEv2). 2033 * IKEv2: Noted that CERTREQ payload changed from DN to SHA-1 of 2034 SubjectPublicKeyInfo. 2035 * IKEv2: Noted new requirement that specifies that the first 2036 certificate sent MUST be the EE cert (section 3.6). 2038 February 2004 (-04) 2040 * Minor editorial changes to clean up language 2041 * Deprecate in-band exchange of CRLs 2042 * Incorporated Gregory Lebovitz's proposal for CERT payloads: 2043 "should deal with all the CRL, Intermediat Certs, Trust 2044 Anchors, etc OOB of IKE; MUST be able to send and receive EE 2045 cert payload; only real exception is Intermediate Cets which 2046 MAY be sent and SHOULD be able to be receivable (but in reality 2047 there are very few hierarchies in operation, so really it's a 2048 corner case); SHOULD NOT send the other stuff (CRL, Trust 2049 Anchors, etc) in cert payloads in IKE; SHOULD be able to accept 2050 the other stuff if by chance it gets sent, though we hope they 2051 don't get sent" 2052 * Incorporated comments contained in Oct 7, 2003 email from 2053 steve.hanna@sun.com to ipsec@lists.tislabs.com 2054 * Moved text from "Profile of ISAKMP" Background section to each 2055 payload section (removing duplication of these sections) 2056 * Removed "Certificate-Related Playloads in ISAKMP" section since 2057 it was not specific to IKE. 2058 * Incorporated Gregory Lebovitz's table in the "Identification 2059 Payload" section 2061 * Moved text from "binding identity to policy" sections to each 2062 payload section 2063 * Moved text from "IKE" section into now-combined "IKE/ISAKMP" 2064 section 2065 * ID_USER_FQDN and ID_FQDN promoted to MUST from MAY 2066 * Promoted sending ID_DER_ASN1_DN to MAY from SHOULD NOT, and 2067 receiving from MUST from MAY 2068 * Demoted ID_DER_ASN1_GN to MUST NOT 2069 * Demoted populating SubjectName in place of populating the 2070 dNSName from SHOULD NOT to MUST NOT and removed the text 2071 regarding domainComponent 2072 * Revocation information checking MAY now be disabled, although 2073 not by default 2074 * Aggressive Mode removed from this profile 2076 June 2003 (-03) 2078 * Minor editorial changes to clean up language 2079 * Minor additional clarifying text 2080 * Removed hyphenation 2081 * Added requirement that implementations support configuration 2082 data exchange having arbitrary line lengths 2084 February 2003 (-02) 2086 * Word choice: move from use of "root" to "trust anchor", in 2087 accordance with PKIX 2088 * SBGP note and reference for placing address subnet and range 2089 information into certificates 2090 * Clarification of text regarding placing names of hosts into the 2091 Name commonName attribute of SubjectName 2092 * Added table to clarify text regarding processing of the 2093 certificate extension criticality bit 2094 * Added text underscoring processing requirements for 2095 CRLDistributionPoints and IssuingDistributionPoint 2097 October 2002, Reorganization (-01) 2099 June 2002, Initial Draft (-00) 2101 Appendix B. The Possible Dangers of Delta CRLs 2103 The problem is that the CRL processing algorithm is sometimes written 2104 incorrectly with the assumption that all CRLs are base CRLs and it is 2105 assumed that CRLs will pass content validity tests. Specifically, 2106 such implementations fail to check the certificate against all 2107 possible CRLs: if the first CRL that is obtained from the keying 2108 material database fails to decode, no further revocation checks are 2109 performed for the relevant certificate. This problem is compounded 2110 by the fact that implementations which do not understand delta CRLs 2111 may fail to decode such CRLs due to the critical DeltaCRLIndicator 2112 extension. The algorithm that is implemented in this case is 2113 approximately: 2115 o fetch newest CRL 2116 o check validity of CRL signature 2117 o if CRL signature is valid then 2118 o if CRL does not contain unrecognized critical extensions 2119 o and certificate is on CRL then 2120 o set certificate status to revoked 2122 The authors note that a number of PKI toolkits do not even provide a 2123 method for obtaining anything but the newest CRL, which in the 2124 presence of delta CRLs may in fact be a delta CRL, not a base CRL. 2126 Note that the above algorithm is dangerous in many ways. See PKIX 2127 [5] for the correct algorithm. 2129 Appendix C. More on Empty CERTREQs 2131 Sending empty certificate requests is commonly used in 2132 implementations, and in the IPsec interop meetings, vendors have 2133 generally agreed that it means that send all/any end-entity 2134 certificates you have (if multiple end-entity certificates are sent, 2135 they must have same public key, as otherwise the other end does not 2136 know which key was used). For 99% of cases the client have exactly 2137 one certificate and public key, so it really doesn't matter, but the 2138 server might have multiple, thus it simply needs to say to the 2139 client, use any certificate you have. If we are talking about 2140 corporate vpns etc, even if the client have multiple certificates or 2141 keys, all of them would be usable when authenticating to the server, 2142 so client can simply pick one. 2144 If there is some real difference on which cert to use (like ones 2145 giving different permissions), then the client must be configured 2146 anyways, or it might even ask the user which one to use (the user is 2147 the only one who knows whether he needs admin privileges, thus needs 2148 to use admin cert, or is the normal email privileges ok, thus using 2149 email only cert). 2151 99% of the cases the client have exactly one certificate, so it will 2152 send it. In 90% of the rest of the cases, any of the certificates is 2153 ok, as they are simply different certificates from same CA, or 2154 different CAs for the same corporate VPN, thus any of them is ok. 2156 Sending empty certificate requests has been agreed there to mean 2157 "give me your cert; any cert". 2159 Justification: 2161 o Responder first does all it can to send a certreq with a CA, check 2162 for IP match in SPD, have a default set of CAs to use in ambiguous 2163 cases, etc. 2164 o sending empty certreq's is fairly common in implementations today, 2165 and is generally accepted to mean "send me a cert, any cert that 2166 works for you" 2167 o saves responder sending potentially 100's of certs, the 2168 fragmentation problems that follow, etc. 2169 o in +90% of use cases, Initiators have exactly 1 cert 2170 o in +90% of the remaining use cases, the multiple certs it has are 2171 issued by the same CA 2172 o in the remaining use case(s) -- if not all the others above -- the 2173 Initiator will be configured explicitly with which cert to send, 2174 so responding to an empty certreq is easy. 2176 The following example shows why initiators need to have sufficient 2177 policy definition to know which certificate to use for a given 2178 connection it initiates. 2180 EXAMPLE: Your client (initiator) is configured with VPN policies for 2181 gateways A and B (representing perhaps corporate partners). 2183 The policies for the two gateways look something like: 2185 Acme Company policy (gateway A) 2186 Engineering can access 10.1.1.0 2187 Trusted CA: CA-A, Trusted Users: OU=Engineering 2188 Partners can access 20.1.1.0 2189 Trusted CA: CA-B, Trusted Users: OU=AcmePartners 2191 Bizco Company policy (gateway B) 2192 sales can access 30.1.1.0 2193 Trusted CA: CA-C, Trusted Users: OU=Sales 2194 Partners can access 40.1.1.0 2195 Trusted CA: CA-B, Trusted Users: OU=BizcoPartners 2197 You are an employee of Acme and you are issued the following 2198 certificates: 2200 o From CA-A: CN=JoeUser,OU=Engineering 2201 o From CA-B: CN=JoePartner,OU=BizcoPartners 2203 The client MUST be configured locally to know which CA to use when 2204 connecting to either gateway. If your client is not configured to 2205 know the local credential to use for the remote gateway, this 2206 scenario will not work either. If you attempt to connect to Bizco, 2207 everything will work... as you are presented with responding with a 2208 certificate signed by CA-B or CA-C... as you only have a certificate 2209 from CA-B you are OK. If you attempt to connect to Acme, you have an 2210 issue because you are presented with an ambiguous policy selection. 2211 As the initiator, you will be presented with certificate requests 2212 from both CA A and CA B. You have certificates issued by both CAs, 2213 but only one of the certificates will be usable. How does the client 2214 know which certificate it should present? It must have sufficiently 2215 clear local policy specifying which one credential to present for the 2216 connection it initiates. 2218 Appendix D. Acknowledgements 2220 The authors would like to acknowledge the expired draft-ietf-ipsec- 2221 pki-req-05.txt for providing valuable materials for this document. 2223 The authors would like to especially thank Eric Rescorla, one of its 2224 original authors, in addition to Greg Carter, Steve Hanna, Russ 2225 Housley, Charlie Kaufman, Tero Kivinen, and Gregory Lebovitz for 2226 their valuable comments, some of which have been incorporated 2227 verbatim into this document. Paul Knight performed the arduous tasks 2228 of coverting the text to XML format. 2230 Author's Address 2232 Brian Korver 2233 Network Resonance, Inc. 2234 2483 E. Bayshore Rd. 2235 Palo Alto, CA 94303 2236 US 2238 Phone: +1 650 812 7705 2239 Email: briank@networkresonance.com 2241 Intellectual Property Statement 2243 The IETF takes no position regarding the validity or scope of any 2244 Intellectual Property Rights or other rights that might be claimed to 2245 pertain to the implementation or use of the technology described in 2246 this document or the extent to which any license under such rights 2247 might or might not be available; nor does it represent that it has 2248 made any independent effort to identify any such rights. Information 2249 on the procedures with respect to rights in RFC documents can be 2250 found in BCP 78 and BCP 79. 2252 Copies of IPR disclosures made to the IETF Secretariat and any 2253 assurances of licenses to be made available, or the result of an 2254 attempt made to obtain a general license or permission for the use of 2255 such proprietary rights by implementers or users of this 2256 specification can be obtained from the IETF on-line IPR repository at 2257 http://www.ietf.org/ipr. 2259 The IETF invites any interested party to bring to its attention any 2260 copyrights, patents or patent applications, or other proprietary 2261 rights that may cover technology that may be required to implement 2262 this standard. Please address the information to the IETF at 2263 ietf-ipr@ietf.org. 2265 Disclaimer of Validity 2267 This document and the information contained herein are provided on an 2268 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2269 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2270 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2271 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2272 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2273 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2275 Copyright Statement 2277 Copyright (C) The Internet Society (2006). This document is subject 2278 to the rights, licenses and restrictions contained in BCP 78, and 2279 except as set forth therein, the authors retain all their rights. 2281 Acknowledgment 2283 Funding for the RFC Editor function is currently provided by the 2284 Internet Society.