idnits 2.17.00 (12 Aug 2021) /tmp/idnits27167/draft-ietf-pki4ipsec-ikecert-profile-02.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2013. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1990. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1997. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2003. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 3 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 1125 has weird spacing: '...lements bit...' == Line 1208 has weird spacing: '... type equal...' == Line 1222 has weird spacing: '... its conten...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Sect 3.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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 3, 2004) is 6468 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: 'DNSSEC' on line 419 -- Looks like a reference, but probably isn't: 'IKEv2' on line 1641 -- Looks like a reference, but probably isn't: 'IDr' on line 1758 == Unused Reference: '11' is defined on line 1583, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1593, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2407 (ref. '1') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (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 2408 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2314 (ref. '6') (Obsoleted by RFC 2986) ** Obsolete normative reference: RFC 3280 (ref. '7') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. '10') (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '11') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. '12') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 1883 (ref. '13') (Obsoleted by RFC 2460) == Outdated reference: draft-ietf-pkix-x509-ipaddr-as-extn has been published as RFC 3779 Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 pki4ipsec B. Korver 3 Internet-Draft Xythos Software, Inc. 4 Expires: March 4, 2005 September 3, 2004 6 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX 7 draft-ietf-pki4ipsec-ikecert-profile-02 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 4, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 IKE/IPsec and PKIX both provide frameworks that must be profiled for 43 use in a given application. This document provides a profile of IKE/ 44 IPsec and PKIX that defines the requirements for using PKI technology 45 in the context of IKE/IPsec. The document complements protocol 46 specifications such as IKEv1 and IKEv2, which assume the existence of 47 public key certificates and related keying materials, but which do 48 not address PKI issues explicitly. This document addresses those 49 issues. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . 5 55 3. Profile of IKEv1/ISAKMP and IKEv2 . . . . . . . . . . . . . 6 56 3.1 Identification Payload . . . . . . . . . . . . . . . . . . 6 57 3.1.1 ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . . . 8 58 3.1.2 ID_FQDN . . . . . . . . . . . . . . . . . . . . . . . 10 59 3.1.3 ID_USER_FQDN . . . . . . . . . . . . . . . . . . . . . 11 60 3.1.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, 61 ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE . . . . . . . . 11 62 3.1.5 ID_DER_ASN1_DN . . . . . . . . . . . . . . . . . . . . 12 63 3.1.6 ID_DER_ASN1_GN . . . . . . . . . . . . . . . . . . . . 13 64 3.1.7 ID_KEY_ID . . . . . . . . . . . . . . . . . . . . . . 13 65 3.1.8 Selecting an Identity from a Certificate . . . . . . . 13 66 3.1.9 Transitively Binding Identity to Policy . . . . . . . 13 67 3.2 Certificate Request Payload . . . . . . . . . . . . . . . 14 68 3.2.1 Certificate Type . . . . . . . . . . . . . . . . . . . 14 69 3.2.2 X.509 Certificate - Signature . . . . . . . . . . . . 15 70 3.2.3 Revocation Lists (CRL and ARL) . . . . . . . . . . . . 15 71 3.2.4 PKCS #7 wrapped X.509 certificate . . . . . . . . . . 15 72 3.2.5 IKEv2's Hash and URL of X.509 certificate . . . . . . 16 73 3.2.6 Presence or Absence of Certificate Request Payloads . 16 74 3.2.7 Certificate Requests . . . . . . . . . . . . . . . . . 16 75 3.2.8 Robustness . . . . . . . . . . . . . . . . . . . . . . 18 76 3.2.9 Optimizations . . . . . . . . . . . . . . . . . . . . 19 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 Certificate Payloads Not Mandatory . . . . . . . . . . 21 84 3.3.7 Response to Multiple Certificate Authority Proposals . 22 85 3.3.8 Using Local Keying Materials . . . . . . . . . . . . . 22 86 3.3.9 Robustness . . . . . . . . . . . . . . . . . . . . . . 22 87 3.3.10 Optimizations . . . . . . . . . . . . . . . . . . . 23 88 4. Profile of PKIX . . . . . . . . . . . . . . . . . . . . . . 25 89 4.1 X.509 Certificates . . . . . . . . . . . . . . . . . . . . 25 90 4.1.1 Versions . . . . . . . . . . . . . . . . . . . . . . . 25 91 4.1.2 Subject Name . . . . . . . . . . . . . . . . . . . . . 25 92 4.1.3 X.509 Certificate Extensions . . . . . . . . . . . . . 26 93 4.2 X.509 Certificate Revocation Lists . . . . . . . . . . . . 31 94 4.2.1 Multiple Sources of Certificate Revocation 95 Information . . . . . . . . . . . . . . . . . . . . . 32 96 4.2.2 X.509 Certificate Revocation List Extensions . . . . . 32 97 5. Configuration Data Exchange Conventions . . . . . . . . . . 34 98 5.1 Certificates . . . . . . . . . . . . . . . . . . . . . . . 34 99 5.2 Public Keys . . . . . . . . . . . . . . . . . . . . . . . 34 100 5.3 PKCS#10 Certificate Signing Requests . . . . . . . . . . . 34 101 6. Security Considerations . . . . . . . . . . . . . . . . . . 35 102 6.1 Identification Payload . . . . . . . . . . . . . . . . . . 35 103 6.2 Certificate Request Payload . . . . . . . . . . . . . . . 35 104 6.3 Certificate Payload . . . . . . . . . . . . . . . . . . . 35 105 6.4 IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 35 106 7. Intellectual Property Rights . . . . . . . . . . . . . . . . 36 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37 108 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 109 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 38 110 9.2 Informative References . . . . . . . . . . . . . . . . . . . 38 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . 39 112 A. Change History . . . . . . . . . . . . . . . . . . . . . . . 40 113 B. The Possible Dangers of Delta CRLs . . . . . . . . . . . . . 46 114 C. More on Empty CERTREQs . . . . . . . . . . . . . . . . . . . 47 115 D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 116 Intellectual Property and Copyright Statements . . . . . . . 50 118 1. Introduction 120 IKE [2], ISAKMP [5] and IKEv2 [3] provide a secure key exchange 121 mechanism for use with IPSEC [4]. In many cases the peers 122 authenticate using digital certificates as specified in PKIX [7]. 123 Unfortunately, the combination of these standards leads to an 124 underspecified set of requirements for the use of certificates in the 125 context of IPsec. 127 ISAKMP references PKIX but in many cases merely specifies the 128 contents of various messages without specifying their syntax or 129 semantics. Meanwhile, PKIX provides a large set of certificate 130 mechanisms which are generally applicable for Internet protocols, but 131 little specific guidance for IPsec. Given the numerous 132 underspecified choices, interoperability is hampered if all 133 implementers do not make similar choices, or at least fail to account 134 for implementations which have chosen differently. 136 This profile of the IKE and PKIX frameworks is intended to provide an 137 agreed-upon standard for using PKI technology in the context of IPsec 138 by profiling the PKIX framework for use with IKE and IPsec, and by 139 documenting the contents of the relevant IKE payloads and further 140 specifying their semantics. 142 In addition to providing a profile of IKE and PKIX, this document 143 attempts to incorporate lessons learned from recent experience with 144 both implementation and deployment, as well as the current state of 145 related protocols and technologies. 147 Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and 148 readers of this document are assumed to have read and understood 149 those documents. The requirements and security aspects of those 150 documents are fully relevant to this document as well. 152 This document is organized as follows. Section 2 defines special 153 terminology used in the rest of this document, Section 3 provides the 154 profile of IKEv1/ISAKMP and IKEv2, and Section 4 provides the profile 155 of PKIX. Section 5 covers conventions for the out-of-band exchange 156 of keying materials for configuration purposes. 158 This document is being discussed on the pki4ipsec@icsalabs.com 159 mailing list. 161 2. Terms and Definitions 163 Except for those terms which are defined immediately below, all terms 164 used in this document are defined in either the PKIX [7], ISAKMP [5], 165 IKEv1 [2], IKEv2 [3], or DOI [1] documents. 166 o Peer source address: The source address in packets from a peer. 167 This address may be different from any addresses asserted as the 168 "identity" of the peer. 169 o FQDN: Fully qualified domain name. 170 o ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both 171 are referred to as ID_USER_FQDN in this document. 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC-2119 [9]. 177 3. Profile of IKEv1/ISAKMP and IKEv2 179 3.1 Identification Payload 181 The Identification (ID) Payload is used to indicate the identity that 182 the agent claims to be speaking for. The receiving agent can then 183 use the ID as a lookup key for policy and whatever certificate store 184 or directory that it has available. Our primary concern in this 185 document is to profile the ID payload so that it can be safely used 186 to generate or lookup policy. IKE mandates the use of the ID payload 187 in Phase 1. 189 The DOI [1] defines the 11 types of Identification Data that can be 190 used and specifies the syntax for these types. These are discussed 191 below in detail. 193 The ID payload requirements in this document cover only the portion 194 of the explicit policy checks that deal with the Identification 195 Payload specifically. For instance, in the case where ID does not 196 contain an IP address, checks such as verifying that the peer source 197 address is permitted by the relevant policy are not addressed here as 198 they are out of the scope of this document. 200 Implementations SHOULD populate ID with identity information that is 201 contained within the end entity certificate (This SHOULD does not 202 contradict text in IKEv2 [3] Section 3.5 that implies a looser 203 binding between these two). Populating ID with identity information 204 from the end entity certificate enables recipients to use ID as a 205 lookup key to find the peer end entity certificate. 207 Because implementations may use ID as a lookup key to determine which 208 policy to use, all implementations MUST be especially careful to 209 verify the truthfulness of the contents by verifying that they 210 correspond to some keying material demonstrably held by the peer. 211 Failure to do so may result in the use of an inappropriate or 212 insecure policy. The following sections describe the methods for 213 performing this binding. 215 The following table summarizes the binding of the Identification 216 Payload to the contents of end-entity certificates and of identity 217 information to policy. Each ID type is covered more thoroughly in 218 the following sections. 220 ID type | Support | Correspond | Cert | SPD lookup 221 | for send | PKIX Attrib | matching | rules 222 ------------------------------------------------------------------- 223 | | | | 224 IP*_ADDR | MUST [1] | SubjAltName | MUST [2] | [3], [4] 225 | | iPAddress | | 226 | | | | 227 FQDN | MUST [1] | SubjAltName | MUST [2] | [3], [4] 228 | | dNSName | | 229 | | | | 230 USER_FQDN| MUST [1] | SubjAltName | MUST [2] | [3], [4] 231 | | rfc822Name | | 232 | | | | 233 DN | MUST [1] | Entire | MUST [2] | MUST support lookup 234 | | Subject, | | on any combination 235 | | bitwise | | of C, CN, O, or OU 236 | | compare | | 237 | | | | 238 IP range | MUST NOT | n/a | n/a | n/a 239 | | | | 240 | | | | 241 KEY_ID | MUST NOT | n/a | n/a | n/a 242 | | | | 244 [1] = Implementation MUST have the configuration option to send this 245 ID type in the ID payload. Whether or not the ID type is used is a 246 matter of local configuration. 248 [2] = The ID in the ID payload MUST match the contents of the 249 corresponding field (listed) in the certificate exactly, with no 250 other lookup. The matched ID MAY be used for SPD lookup, but is not 251 required to be used for this. 253 [3] = At a minimum, Implementation MUST be able to be configured to 254 perform exact matching of the ID payload contents to an entry in the 255 local SPD. 257 [4] = In addition, the implementation MAY also be configurable to 258 perform substring or wildcard matches of ID payload contents to 259 entries in the local SPD. (More on this in Section 3.1.5). 261 When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, 262 implementations MUST be able to be configured to send the same string 263 as appears in the corresponding SubjectAltName attribute. This 264 document RECOMMENDS that deployers use this configuration option. 265 All these ID types are treated the same: as strings that can be 266 compared easily and quickly to a corresponding string in an explicit 267 attribute in the certificate. Of these types, FQDN and USER_FQDN are 268 RECOMMENDED over IP addresses (see discussion in Section 3.1.1). 270 When sending a DN as ID, implementations MUST send the entire DN in 271 ID. Also, implementations MUST support at least the C, CN, O, and OU 272 attributes for SPD matching. See Section 3.1.5 for more details 273 about DN, including SPD matching. 275 Recipients MUST be able to perform SPD matching on the exact contents 276 of the ID, and this SHOULD be the default setting. In addition, 277 implementations MAY use substrings or wildcards in local policy 278 configuration to do the SPD matching against the ID contents. In 279 other words, implementations MUST be able to do exact matches of ID 280 to SPD, but MAY also be configurable to do substring or wildcard 281 matches of ID to SPD. 283 IKEv2 adds an optional IDr payload in the second exchange that the 284 initiator may send to the responder in order to specify which of the 285 responder's multiple identities should be used. The responder MAY 286 choose to send an IDr in the 3rd exchange that differs in type or 287 content from the initiator-generated IDr. The initiator MUST be able 288 to receive a responder-generated IDr that is different from the one 289 the initiator generated. Whether or not to accept such a response 290 and continue with IKE processing is a matter of local policy. 292 3.1.1 ID_IPV4_ADDR and ID_IPV6_ADDR 294 Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR 295 ID type. These addresses MUST be stored in "network byte order," as 296 specified in IP [8]: The least significant bit (LSB) of each octet 297 is the LSB of the corresponding byte in the network address. For the 298 ID_IPV4_ADDR type, the payload MUST contain exactly four octets [8]. 299 For the ID_IPV6_ADDR type, the payload MUST contain exactly sixteen 300 octets [13]. 302 Note that this document does NOT RECOMMEND populating the ID payload 303 with IP addresses due to interoperability issues such as problems 304 with NAT traversal, and problems with IP verification behavior. 306 Deployments may only want to consider using the IP address as IKE_ID 307 if the following are true: 308 o the peer's IP address is fixed, not dynamically changing 309 o the peer is NOT behind a NAT'ing device 310 o the administrator intends the implementation to verify that the IP 311 address in the peer's source matches the IP address in the IKE_ID 312 received, and that of the certificate's iPAddress field in the 313 subjectAltName extension. 315 Implementations MUST be capable of verifying that the IP address 316 presented in IKE_ID matches via bitwise comparison the IP address 317 present in the certificate's iPAddress field in the subjectAltName 318 extension. Implementations MUST perform this verification by 319 default. When comparing the contents of ID with the iPAddress field 320 in the subjectAltName extension for equality, binary comparison MUST 321 be performed. If the default is enabled, then a mismatch between the 322 two MUST be treated as an error and security association setup MUST 323 be aborted. This event SHOULD be auditable. Implementations MAY 324 provide a configuration option to (i.e. local policy configuration 325 can enable) skip that verification step, but that option MUST be off 326 by default. We include the "option-to-skip" in order to permit 327 better interoperability, as today implementations vary greatly in how 328 they behave on this topic of verification between IKE_ID and cert 329 contents. 331 Implementations MUST be capable of verifying that the address 332 contained in the ID is the same as the peer source address, contained 333 in the outer most IP header. If IKE_ID is one of the IP address 334 types, then implementations MUST perform this verification by 335 default. If this default is enabled, then a mismatch MUST be treated 336 as an error and security association setup MUST be aborted. This 337 event SHOULD be auditable. Implementations MAY provide a 338 configuration option to (i.e. local policy configuration can enable) 339 skip that verification step, but that option MUST be off by default. 340 We include the "option-to-skip-validation" in order to permit better 341 interoperability, as today implementations vary greatly in how they 342 behave on this topic of verification to source IP. 344 If the default for both the verifications above are enabled, then, by 345 transitive property, the implementation will also be verifying that 346 the peer source IP address matches via a bitwise comparison the 347 contents of the iPAddress field in the subjectAltName extension in 348 the certificate. In addition, implementations MAY allow 349 administrators to configure a local policy that explicitly requires 350 that the peer source IP address match via a bitwise comparison the 351 contents of the iPAddress field in the subjectAltName extension in 352 the certificate. Implementations SHOULD allow administrators to 353 configure a local policy that skips this validation check. 355 Implementations MAY support substring, wildcard, or regular 356 expression matching of the IKE_ID to contents in the SPD, and such 357 would be a matter of local security policy configuration. 359 Implementations MAY use the IP address found in the header of packets 360 received from the peer to lookup the policy, but such implementations 361 MUST still perform verification of the ID payload. Although packet 362 IP addresses are inherently untrustworthy and must therefore be 363 independently verified, it is often useful to use the apparent IP 364 address of the peer to locate a general class of policies that will 365 be used until the mandatory identity-based policy lookup can be 366 performed. 368 For instance, if the IP address of the peer is unrecognized, a VPN 369 gateway device might load a general "road warrior" policy that 370 specifies a particular CA that is trusted to issue certificates which 371 contain a valid rfc822Name which can be used by that implementation 372 to perform authorization based on access control lists (ACLs) after 373 the peer's certificate has been validated. The rfc822Name can then 374 be used to determine the policy that provides specific authorization 375 to access resources (such as IP addresses, ports, and so forth). 377 As another example, if the IP address of the peer is recognized to be 378 a known peer VPN endpoint, policy may be determined using that 379 address, but until the identity (address) is validated by validating 380 the peer certificate, the policy MUST NOT be used to authorize any 381 IPsec traffic. 383 3.1.2 ID_FQDN 385 Implementations MUST support the ID_FQDN ID type, generally to 386 support host-based access control lists for hosts without fixed IP 387 addresses. However, implementations SHOULD NOT use the DNS to map 388 the FQDN to IP addresses for input into any policy decisions, unless 389 that mapping is known to be secure, such as when [DNSSEC] is 390 employed. 392 Implementations MUST be capable of verifying that the identity 393 contained in the ID payload matches identity information contained in 394 the peer end entity certificate, in the dNSName field in the 395 subjectAltName extension. Implementations MUST perform this 396 verification by default. When comparing the contents of ID with the 397 dNSName field in the subjectAltName extension for equality, caseless 398 string comparison MUST be performed. Substring, wildcard, or regular 399 expression matching MUST NOT be performed for this comparison. If 400 this default is enabled, then a mismatch MUST be treated as an error 401 and security association setup MUST be aborted. This event SHOULD be 402 auditable. Implementations MAY provide a configuration option to 403 (i.e. local policy configuration can enable) skip that verification 404 step, but that option MUST be off by default. We include the 405 "option-to-skip-validation" in order to permit better 406 interoperability, as today implementations vary greatly in how they 407 behave on this topic. 409 Implementations MAY support substring, wildcard, or regular 410 expression matching of the IKE_ID to contents in the SPD, and such 411 would be a matter of local security policy configuration. 413 3.1.3 ID_USER_FQDN 415 Implementations MUST support the ID_USER_FQDN ID type, generally to 416 support user-based access control lists for users without fixed IP 417 addresses. However, implementations SHOULD NOT use the DNS to map 418 the FQDN portion to IP addresses for input into any policy decisions, 419 unless that mapping is known to be secure, such as when [DNSSEC] is 420 employed. 422 Implementations MUST be capable of verifying that the identity 423 contained in the ID payload matches identity information contained in 424 the peer end entity certificate, in the rfc822Name field in the 425 subjectAltName extension. Implementations MUST perform this 426 verification by default. When comparing the contents of ID with the 427 rfc822Name field in the subjectAltName extension for equality, 428 caseless string comparison MUST be performed. Substring, wildcard, 429 or regular expression matching MUST NOT be performed for this 430 comparison. If this default is enabled, then a mismatch MUST be 431 treated as an error and security association setup MUST be aborted. 432 This event SHOULD be auditable. Implementations MAY provide a 433 configuration option to (i.e. local policy configuration can enable) 434 skip that verification step, but that option MUST be off by default. 435 We include the "option-to-skip-validation" in order to permit better 436 interoperability, as today implementations vary greatly in how they 437 behave on this topic. 439 Implementations MAY support substring, wildcard, or regular 440 expression matching of the IKE_ID to contents in the SPD, and such 441 would be a matter of local security policy configuration. 443 3.1.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, 444 ID_IPV6_ADDR_RANGE 446 As there is currently no standard method for putting address subnet 447 or range identity information into certificates, the use of these ID 448 types is currently undefined. Implementations MUST NOT generate 449 these ID types. 451 Note that work in SBGP [15] for defining blocks of addresses using 452 the certificate extension identified by: 454 id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } 456 is experimental at this time. 458 3.1.5 ID_DER_ASN1_DN 460 Implementations MUST support receiving the ID_DER_ASN1_DN ID type. 461 Implementations MUST be capable of generating this type, and the 462 decision to do so will be a matter of local security policy 463 configuration. When generating this type, implementations MUST 464 populate the contents of ID with the Subject Name from the end entity 465 certificate, and MUST do so such that a binary comparison of the two 466 will succeed. If there is not a match, this MUST be treated as an 467 error and security association setup MUST be aborted. This event 468 SHOULD be auditable. For instance, if the certificate was 469 erroneously created such that the encoding of the Subject Name DN 470 varies from the constraints set by DER, that non-conformant DN MUST 471 be used to populate the ID payload: in other words, implementations 472 MUST NOT re-encode the DN for the purposes of making it DER if it 473 does not appear in the certificate as DER. 475 Implementations MUST NOT populate ID with the Subject Name from the 476 end entity certificate if it is empty, as described in the "Subject" 477 section of PKIX. 479 Regarding SPD matching, implementations MUST be able to perform 480 matching based on a bitwise comparison of the entire DN in ID to its 481 entry in the SPD. However, operational experience has shown that 482 using the entire DN in local configuration is difficult, especially 483 in large scale deployments. Therefore, implementations also MUST be 484 able to perform SPD matches of any combination of one or more of the 485 C, CN, O, OU attributes within Subject DN in the ID to the same in 486 the SPD. Implementations MAY support matching using additional DN 487 attributes in any combination, although interoperability is far from 488 certain and dubious. Implementations MAY also support performing 489 substring, wildcard, or regular expression matches for any of its 490 supported DN attributes from ID, in any combination, to the SPD. 491 Such flexibility allows deployers to create one SPD entry on the 492 gateway for an entire department of a company (e.g. O=Foobar Inc., 493 OU=Engineering) while still allowing them to draw out other details 494 from the DN (e.g. CN=John Doe) for auditing purposes. All the above 495 is a matter of local implementation and local policy definition and 496 enforcement capability, not bits on the wire, but will have a great 497 impact on interoperability. 499 3.1.6 ID_DER_ASN1_GN 501 Implementations MUST NOT generate this type. 503 3.1.7 ID_KEY_ID 505 The ID_KEY_ID type used to specify pre-shared keys and thus is out of 506 scope. 508 3.1.8 Selecting an Identity from a Certificate 510 Implementations MUST support certificates that contain more than a 511 single identity. In many cases a certificate will contain an 512 identity such as an IP address in the subjectAltName extension in 513 addition to a non-empty Subject Name. 515 The identity with which an implementation chooses to populate the 516 IKE_ID payload is a local matter. For compatibility with 517 non-conformant implementations, implementations SHOULD populate ID 518 with whichever identity is likely to be named in the peer's policy. 519 In practice, this generally means FQDN, or USER_FQDN. 521 3.1.9 Transitively Binding Identity to Policy 523 In the presence of certificates that contain multiple identities, 524 implementations MUST select the most appropriate identity from the 525 certificate and populate the ID with that. The responder MUST use 526 the identity sent as a first key when selecting the policy. 527 Responder MUST also use most specific policy from that database if 528 there are overlapping policies caused by wildcards (or the 529 implementation can de-correlate the policy database so there will not 530 be overlapping entries, or it can also forbid creation of overlapping 531 policies and leave the de-correlation process to the administrator, 532 but as this moves the problem to the administrator it is NOT 533 RECOMMENDED). 535 For example, imagine that a peer is configured with a certificate 536 that contains both a non-empty Subject Name and a dNSName. The 537 initiator MUST know by policy which of those to use, and it indicates 538 the policy in the other end by selecting the correct ID. If the 539 responder has both a specific policy for the dNSName for this host, 540 and generic wildcard rule for some attributes present in the subject 541 Name, it will match a different policy depending which ID is sent. 542 As the initiator knows why it wanted to connect the responder, it 543 also knows what identity it should use to match the policy it needs 544 to the operation it tries to perform; it is the only party who can 545 select the ID adequately. 547 In the event the policy cannot be found in the responder's SPD using 548 the ID sent by the initiator, then the responder MAY use the other 549 identities in the certificate when attempting to match a suitable 550 policy. For example, say the certificate contains both non-empty 551 Subject Name, dNSName and iPAddress. The initiator sends ID of 552 iPAddress, but the responder does not have that in the policy 553 database. If the responder has a rule for the dNSName it MAY use 554 policy based on that. 556 If overlapping policies are found in this step, the responder cannot 557 know which one of those should be selected, i.e. if the responder 558 does have rules for both Subject Name and for dNSName, and it would 559 need to select one of those policies, but it cannot know which one to 560 select. One or both of those rules could also be wildcard rules. 562 The responder cannot use de-correlation or forbidding the overlapping 563 policies, as there is no way to detect those overlaps exist before 564 the arrival of the certificate that makes the overlapping a reality. 565 In the case where overlapping policies exist, the responder SHOULD 566 terminate the negotiation with error, which informs the other end 567 that administrative modification to its policy must be performed 568 (i.e. it needs to use some other identity). 570 3.2 Certificate Request Payload 572 The Certificate Request (CERTREQ) Payload allows an implementation to 573 request that a peer provide some set of certificates or certificate 574 revocation lists. It is not clear from ISAKMP exactly how that set 575 should be specified or how the peer should respond. We describe the 576 semantics on both sides. 578 3.2.1 Certificate Type 580 The Certificate Type field identifies to the peer the type of 581 certificate keying materials that are desired. ISAKMP defines 10 582 types of Certificate Data that can be requested and specifies the 583 syntax for these types. For the purposes of this document, only the 584 following types are relevant: 585 o X.509 Certificate - Signature 586 o Revocation Lists (CRL and ARL) 587 o PKCS #7 wrapped X.509 certificate 588 o IKEv2's Hash and URL of X.509 certificate 590 The use of the other types: 591 o X.509 Certificate - Key Exchange 592 o PGP Certificate 593 o DNS Signed Key 594 o Kerberos Tokens 595 o SPKI Certificate 596 o X.509 Certificate Attribute 597 o IKEv2's Raw RSA Key 598 o IKEv2's Hash and URL of X.509 bundle 600 are out of the scope of this document. 602 3.2.2 X.509 Certificate - Signature 604 This type requests that the end entity certificate be a signing 605 certificate. 607 3.2.3 Revocation Lists (CRL and ARL) 609 ISAKMP and IKEv2 do not support Certificate Payload sizes over 610 approximately 64K, which is too small for many CRLs. In addition, 611 the acquisition of revocation material is to be dealt with out of 612 band of IKE. For this and other reasons, implementations SHOULD NOT 613 generate CERTREQs where the Certificate Type is "Certificate 614 Revocation List (CRL)" or "Authority Revocation List (ARL)". 615 Implementations that do generate such CERTREQs MUST NOT expect the 616 responder to send a CRL or ARL, and MUST NOT fail for not receiving 617 it. Upon receipt of such a CERTREQ, implementations MAY ignore the 618 request. 620 In lieu of exchanging entire revocation lists in band, a pointer to 621 revocation checking SHOULD be listed in either the Certificate 622 Distribution Point (CDP) or the Authority Information Access (AIA) 623 attributes of the certificate extensions (see Section 4 for details.) 624 Implementations MUST be able to process these attributes, and from 625 them be able to identify cached revocation material, or retrieve the 626 relevant revocation material from a URL, for validation processing. 627 In addition, implementations MUST have the ability to configure 628 validation checking information for each certificate authority. 629 Regardless of the method (CDP, AIA, or static configuration), the 630 acquisition of revocation material occurs out of band of IKE. 632 3.2.4 PKCS #7 wrapped X.509 certificate 634 This ID type defines a particular encoding (not a particular 635 certificate), some current implementations may ignore CERTREQs they 636 receive which contain this ID type, and the authors are unaware of 637 any implementations that generate such CERTREQ messages. Therefore, 638 the use of this type is deprecated. Implementations SHOULD NOT 639 require CERTREQs that contain this Certificate Type. Implementations 640 which receive CERTREQs which contain this ID type MAY treat such 641 payloads as synonymous with "X.509 Certificate - Signature". 643 3.2.5 IKEv2's Hash and URL of X.509 certificate 645 This ID type defines a request for the peer to send a hash and URL of 646 it X.509 certificate, instead of the actual certificate itself. This 647 is a particularly useful mechanism when the peer is a device with 648 little memory and lower bandwidth, e.g. a mobile handset or consumer 649 electronics device. 651 If the IKEv2 peer supports HTTP lookups, and prefers an HTTP-based 652 URL to receiving the actual certificate, then the peer will want to 653 send a notify of type HTTP_CERT_LOOKUP_SUPPORTED. From IKEv2 [3], 654 section 3.10.1, "This notification MAY be included in any message 655 that can include a CERTREQ payload and indicates that the sender is 656 capable of looking up certificates based on an HTTP-based URL (and 657 hence presumably would prefer to receive certificate specifications 658 in that format)." 660 3.2.6 Presence or Absence of Certificate Request Payloads 662 When in-band exchange of certificate keying materials is desired, 663 implementations MUST inform the peer of this by sending at least one 664 CERTREQ. An implementation which does not send any CERTREQs during 665 an exchange SHOULD NOT expect to receive any CERT payloads. 667 3.2.7 Certificate Requests 669 3.2.7.1 Specifying Certificate Authorities 671 Implementations MUST generate CERTREQs for every peer trust anchor 672 that local policy explicitly deems trusted during a given exchange. 673 For IKEv1, implementations MUST populate the Certificate Authority 674 field with the Subject Name of the trust anchor, populated such that 675 binary comparison of the Subject Name and the Certificate Authority 676 will succeed. For IKEv2, implementations MUST populate the 677 Certificate Authority field as specified in IKEv2 [3]. 679 Upon receipt of a CERTREQ, implementations MUST respond by sending 680 the end entity certificate corresponding to the Certificate Authority 681 listed in the CERTREQ. Implementations SHOULD NOT send any 682 certificates other than the appropriate end entity certificate (see 683 Section 3.3 for discussion). 685 Note, in the case where multiple end entity certificates may be 686 available, implementations SHOULD resort to local heuristics to 687 determine which end entity is most appropriate to use for generating 688 the CERTREQ. Such heuristics are out of the scope of this document. 690 3.2.7.2 Empty Certificate Authority Field 692 Implementations SHOULD generate CERTREQs where the Certificate Type 693 is "X.509 Certificate - Signature" and where an entry exits in the 694 Certificate Authority field. However, implementations MAY generate 695 CERTREQs with an empty Certificate Authority field under special 696 conditions. Though PKIX prohibits certificates with empty issuer 697 name fields, there does exist a use case where doing so is 698 appropriate, and carries special meaning in the IKE context. This 699 has become a convention within the IKE interoperability tests and 700 usage space, and so its use is specified, explained and RECOMMENDED 701 here for the sake of interoperability. 703 USE CASE: Consider the case where you have a gateway with multiple 704 policies for a large number of IKE peers.'some of these peers are 705 business partners, some are remote access employees, some are 706 teleworkers, some are branch offices, and/or the gateway may be 707 simultaneously serving many many customers (e.g. Virtual Routers). 708 The total number of certificates, and corresponding trust anchors, is 709 very high, say hundreds. Each of these policies is configured with 710 one or more acceptable trust anchors, so that in total, the gateway 711 has one hundred (100) trust anchors that could possibly used to 712 authenticate an incoming connection. Assume that many of those 713 connections originate from hosts/gateways with dynamically assigned 714 IP addresses, so that the source IP of the IKE initiator is not known 715 to the gateway, nor is the identity of the intiator (until it is 716 revealed in Main Mode message 5). In IKE main mode message 4, the 717 responder gateway will need to send a CERTREQ to the initiator. 718 Given this example, the gateway will have no idea which of the 719 hundred possible Certificate Authorities to send in the CERTREQ. 720 Sending all possible Certificate Authorities will cause significant 721 processing delays, bandwidth consumption, and UDP fragmentation, so 722 this tactic is ruled out. 724 In such a deployment, the responder gateway implementation should be 725 able to all it can to indicate a Certificate Authority in the 726 CERTREQ. This means the responder SHOULD first check SPD to see if 727 it can match the source IP, and find some indication of which CA is 728 associated with that IP. If this fails (because the source IP is not 729 familiar, as in the case above), then the responder SHOULD have a 730 configuration option specifying which CA's are the default CAs to 731 indicate in CERTREQ during such ambiguous connections (e.g. send 732 CERTREQ with these N CAs if there is an unknown source IP). If such 733 a fall-back is not configured or impractical in a certain deployment 734 scenario, then the responder implementation SHOULD have both of the 735 following configuration options: 736 o send a CERTREQ payload with an empty Certificate Authority field, 737 or 739 o terminate the negotiation with an appropriate error message and 740 audit log entry. 742 Receiving a CERTREQ payload with an empty Certificate Authority field 743 indicates that the initiator peer should send all/any certificates it 744 has, regardless of the trust anchor. The initiator should be aware 745 of what policy and which identity it will use, as it initiated the 746 connection on a matched policy to begin with, and can thus respond 747 with the appropriate certificate. If multiple certificates are sent, 748 they MUST have the same public key, otherwise the responder does not 749 know which key was used in the Main Mode message 5. 751 If, after sending an empty CERTREQ in Main Mode message 4, a 752 responder receives a certificate in message 5 from a trust anchor 753 that the responder either (a) does NOT support, or (b) was not 754 configured for the policy (that policy was now able to be matched due 755 to having the initiators certificate present), then the responder 756 SHOULD terminate the exchange with proper error message and audit log 757 entry. 759 Instead of sending a empty CERTREQ, the responder implementation may 760 be configured to terminate the negotiation on the grounds of a 761 conflict with locally configured security policy. 763 The decision of which to configure is a matter of local security 764 policy, this document RECOMMENDS that both options be presented to 765 administrators. 767 More examples, and explanation on this issue are included in "More on 768 Empty CERTREQs" (Appendix C). 770 3.2.8 Robustness 772 3.2.8.1 Unrecognized or Unsupported Certificate Types 774 Implementations MUST be able to deal with receiving CERTREQs with 775 unsupported Certificate Types. Absent any recognized and supported 776 CERTREQs, implementations MAY treat them as if they are of a 777 supported type with the Certificate Authority field left empty, 778 depending on local policy. ISAKMP [5] Section 5.10 "Certificate 779 Request Payload Processing" specifies additional processing. 781 3.2.8.2 Undecodable Certificate Authority Fields 783 Implementations MUST be able to deal with receiving CERTREQs with 784 undecodable Certificate Authority fields. Implementations MAY ignore 785 such payloads, depending on local policy. ISAKMP specifies other 786 actions which may be taken. 788 3.2.8.3 Ordering of Certificate Request Payloads 790 Implementations MUST NOT assume that CERTREQs are ordered in any way. 792 3.2.9 Optimizations 794 3.2.9.1 Duplicate Certificate Request Payloads 796 Implementations SHOULD NOT send duplicate CERTREQs during an 797 exchange. 799 3.2.9.2 Name Lowest 'Common' Certification Authorities 801 When a peer's certificate keying materials have been cached, an 802 implementation can send a hint to the peer to elide some of the 803 certificates the peer would normally respond with. In addition to 804 the normal set of CERTREQs that are sent specifying the trust 805 anchors, an implementation MAY send CERTREQs containing the Issuer 806 Name of the relevant cached end entity certificates. When sending 807 these hints, it is still necessary to send the normal set of CERTREQs 808 because the hints do not sufficiently convey all of the information 809 required by the peer. Specifically, either the peer may not support 810 this optimization or there may be additional chains that could be 811 used in this context but will not be specified if only supplying the 812 issuer of the end entity certificate. 814 No special processing is required on the part of the recipient of 815 such a CERTREQ, and the end entity certificates will still be sent. 816 On the other hand, the recipient MAY elect to elide certificates 817 based on receipt of such hints. 819 CERTREQs must contain information that identifies a Certification 820 Authority certificate, which results in the peer always sending at 821 least the end entity certificate. This mechanism allows 822 implementations to determine unambiguously when a new certificate is 823 being used by the peer, perhaps because the previous certificate has 824 just expired, which will result in a failure because the needed 825 keying materials are not available to validate the new end entity 826 certificate. Implementations which implement this optimization MUST 827 recognize when the end entity certificate has changed and respond to 828 it by not performing this optimization when the exchange is retried. 830 3.2.9.3 Example 832 Imagine that an implementation has previously received and cached the 833 peer certificate chain TA->CA1->CA2->EE. If during a subsequent 834 exchange this implementation sends a CERTREQ containing the Subject 835 Name in certificate TA, this implementation is requesting that the 836 peer send at least 3 certificates: CA1, CA2, and EE. On the other 837 hand, if this implementation also sends a CERTREQ containing the 838 Subject Name of CA2, the implementation is providing a hint that only 839 1 certificate needs to be sent: EE. Note that in this example, the 840 fact that TA is a trust anchor should not be construed to imply that 841 TA is a self-signed certificate. 843 3.3 Certificate Payload 845 The Certificate (CERT) Payload allows the peer to transmit a single 846 certificate or CRL. The following practice is explicitly deprecated: 847 Some implementations also transmit each certificate in the chain 848 above the end entity certificate up to and including the certificate 849 whose Issuer Name matches the name specified in the Certificate 850 Authority field. This practice is deprecated because the chaining 851 certificates and validation material has now become a responsibility 852 of the certificate management and lifecycle protocols between the 853 IKE/IPsec peer and the PKI system, and not the transmission within 854 IKE. For backwards compatibility reasons, implementations MAY send 855 intermediate CA certificates in addition to the appropriate end 856 entity certificate, but SHOULD NOT send any CRLs, ARLs, or Trust 857 Anchors. The reason for transmitting the intermediate CA 858 certificates, CRL, ARL, and Trust anchors in the certificate 859 management protocol instead of IKE is to: 860 o simplify the IKE exchange 861 o reduce bandwidth requirements for IKE exchanges 862 o increase speed of completion (reduce latency) in IKE 863 o decrease UDP fragmentation 865 Multiple certificates should be transmitted in multiple payloads. 866 However, not all certificate forms that are legal in PKIX make sense 867 in the context of IPsec. The issue of how to represent 868 IKE-meaningful name-forms in a certificate is especially problematic. 869 This document provides a profile for a subset of PKIX that makes 870 sense for IKEv1/ISAKMP and IKEv2. 872 3.3.1 Certificate Type 874 The Certificate Type field identifies to the peer the type of 875 certificate keying materials that are included. ISAKMP defines 10 876 types of Certificate Data that can be sent and specifies the syntax 877 for these types. For the purposes of this document, only the 878 following types are relevant: 879 o X.509 Certificate - Signature 880 o Revocation Lists (CRL and ARL) 881 o PKCS #7 wrapped X.509 certificate 882 o IKEv2's Hash and URL of X.509 certificate 883 The use of the other types: 884 o X.509 Certificate - Key Exchange 885 o PGP Certificate 886 o DNS Signed Key 887 o Kerberos Tokens 888 o SPKI Certificate 889 o X.509 Certificate Attribute 890 o IKEv2's Raw RSA Key 891 o IKEv2's Hash and URL of X.509 bundle 893 are out of the scope of this document. 895 3.3.2 X.509 Certificate - Signature 897 This type specifies that Certificate Data contains a certificate used 898 for signing. Implementations SHOULD only send an end entity 899 signature certificate. 901 3.3.3 Revocation Lists (CRL and ARL) 903 These types specify that Certificate Data contains an X.509 CRL or 904 ARL. These types SHOULD NOT be sent in IKE. See Section 3.2.3 for 905 discussion. 907 3.3.4 IKEv2's Hash and URL of X.509 certificate 909 This type specifies that Certificate Data contains a hash and the URL 910 to a repository where an X.509 certificate can be retrieved. 912 3.3.5 PKCS #7 wrapped X.509 certificate 914 This type defines a particular encoding, not a particular certificate 915 type. Implementations SHOULD NOT generate CERTs that contain this 916 Certificate Type. Implementations SHOULD accept CERTs that contain 917 this Certificate Type because several implementations are known to 918 generate them. Note that those implementations may include entire 919 certificate hierarchies inside a single CERT PKCS #7 payload, which 920 violates the requirement specified in ISAKMP that this payload 921 contain a single certificate. 923 3.3.6 Certificate Payloads Not Mandatory 925 An implementation which does not receive any CERTREQs during an 926 exchange SHOULD NOT send any CERT payloads, except when explicitly 927 configured to proactively send CERT payloads in order to interoperate 928 with non-compliant implementations. This MUST NOT be the default 929 behavior of implementations. 931 Implementations whose local security policy configuration expects 932 that a peer must receive certificates through out-of-band means 933 SHOULD ignore any CERTREQ messages that are received. 935 Implementations that receive CERTREQs from a peer which contain only 936 unrecognized Certification Authorities SHOULD NOT continue the 937 exchange, in order to avoid unnecessary and potentially expensive 938 cryptographic processing, denial of service (resource starvation) 939 attacks. 941 3.3.7 Response to Multiple Certificate Authority Proposals 943 In response to multiple CERTREQs which contain different Certificate 944 Authority identities, implementations MAY respond using an end entity 945 certificate which chains to a CA that matches any of the identities 946 provided by the peer. 948 3.3.8 Using Local Keying Materials 950 Implementations MAY elect to skip parsing or otherwise decoding a 951 given set of CERTs if equivalent keying materials are available via 952 some preferable means, such as the case where certificates from a 953 previous exchange have been cached. 955 3.3.9 Robustness 957 3.3.9.1 Unrecognized or Unsupported Certificate Types 959 Implementations MUST be able to deal with receiving CERTs with 960 unrecognized or unsupported Certificate Types. Implementations MAY 961 discard such payloads, depending on local policy. ISAKMP [5] Section 962 5.10 "Certificate Request Payload Processing" specifies additional 963 processing. 965 3.3.9.2 Undecodable Certificate Data Fields 967 Implementations MUST be able to deal with receiving CERTs with 968 undecodable Certificate Data fields. Implementations MAY discard 969 such payloads, depending on local policy. ISAKMP specifies other 970 actions which may be taken. 972 3.3.9.3 Ordering of Certificate Payloads 974 For IKEv1, implementations MUST NOT assume that CERTs are ordered in 975 any way. For IKEv2, implementations MUST NOT assume that any except 976 the first CERT is ordered in any way. IKEv2 specifies that the first 977 CERT contain the end entity certificate which is to be used to 978 authenticate the peer. 980 3.3.9.4 Duplicate Certificate Payloads 982 Implementations MUST support receiving multiple identical CERTs 983 during an exchange. 985 3.3.9.5 Irrelevant Certificates 987 Implementations MUST be prepared to receive certificates and CRLs 988 which are not relevant to the current exchange. Implementations MAY 989 discard such extraneous certificates and CRLs. 991 Implementations MAY send certificates which are irrelevant to an 992 exchange. One reason for including certificates which are irrelevant 993 to an exchange is to minimize the threat of leaking identifying 994 information in exchanges where CERT is not encrypted. It should be 995 noted, however, that this probably provides rather poor protection 996 against leaking the identity. 998 Another reason for including certificates that seem irrelevant to an 999 exchange is that there may be two chains from the Certificate 1000 Authority to the end entity, each of which is only valid with certain 1001 validation parameters (such as acceptable policies). Since the end 1002 entity doesn't know which parameters the relying party is using, it 1003 should send the certs needed for both chains (even if there's only 1004 one CERTREQ). 1006 Although implementations SHOULD NOT send multiple end entity 1007 certificates if the receipient cannot determine the correct 1008 certificate to use for authentication by using either the contents of 1009 the ID payload to match the certificate or, in IKEv2, the correct 1010 certificate is contained in the first CERT. In other words, 1011 receipients SHOULD NOT be expected to iterate over multiple end 1012 entity certs. 1014 3.3.10 Optimizations 1016 3.3.10.1 Duplicate Certificate Payloads 1018 Implementations SHOULD NOT send duplicate CERTs during an exchange. 1019 Such payloads should be suppressed. 1021 3.3.10.2 Send Only End Entity Certificates 1023 When multiple CERTREQs are received which specify certificate 1024 authorities within the end entity certificate chain, implementations 1025 SHOULD send always and only the relevant end entity certificate, as 1026 chaining will take place out-of-band of IKE, between the IPsec peer 1027 and the PKI system. Implementations SHOULD NOT send the chain. 1029 3.3.10.3 Ignore Duplicate Certificate Payloads 1031 Implementations MAY employ local means to recognize CERTs that have 1032 been received in the past, whether part of the current exchange or 1033 not, for which keying material is available and SHOULD discard these 1034 duplicate CERTs. 1036 3.3.10.4 Hash Payload 1038 IKEv1 specifies the optional use of the Hash Payload to carry a 1039 pointer to a certificate in either of the Phase 1 public key 1040 encryption modes. This pointer is used by an implementation to 1041 locate the end entity certificate that contains the public key that a 1042 peer should use for encrypting payloads during the exchange. 1044 Implementations SHOULD include this payload whenever the public 1045 portion of the keypair has been placed in a certificate. 1047 4. Profile of PKIX 1049 Except where specifically stated in this document, implementations 1050 MUST conform to the requirements of PKIX [7]. 1052 4.1 X.509 Certificates 1054 4.1.1 Versions 1056 Although PKIX states that "implementations SHOULD be prepared to 1057 accept any version certificate", in practice this profile requires 1058 certain extensions that necessitate the use of Version 3 certificates 1059 for all but self-signed certificates used as trust anchors. 1060 Implementations that conform to this document MAY therefore reject 1061 Version 1 and Version 2 certificates in all other cases. 1063 4.1.2 Subject Name 1065 Certificate Authority implementations MUST be able to create 1066 certificates with Subject Name fields with at least the following 1067 four attributes: CN, C, O, OU. Implementations MAY support other 1068 Subject Name attributes as well. The contents of these attributes 1069 SHOULD be configurable on a certificate by certificate basis, as 1070 these fields will likely be used by IKE implementations to match SPD 1071 policy. 1073 See Section 3.1.5 for details on how IKE implementations need to be 1074 able to process Subject Name field attributes for SPD policy lookup. 1076 4.1.2.1 Empty Subject Name 1078 Implementations MUST accept certificates which contain an empty 1079 Subject Name field, as specified in PKIX. Identity information in 1080 such certificates will be contained entirely in the SubjectAltName 1081 extension. 1083 4.1.2.2 Specifying Hosts and FQDN in Subject Name 1085 Implementations which desire to place host names that are not 1086 intended to be processed by recipients as FQDNs (for instance 1087 "Gateway Router") in the Subject Name MUST use the commonName 1088 attribute. 1090 While nothing prevents an FQDN, USER_FQDN, or IP address information 1091 from appearing somewhere in the Subject Name contents, such entries 1092 MUST NOT be interpreted as identity information for the purposes of 1093 matching with IKE_ID or for policy lookup. 1095 If the FQDN is intended to be processed as identity for the purposes 1096 IKE_ID matching, it MUST be placed in the dNSName field of the 1097 SubjectAltName extension. Implementations MUST NOT populate the 1098 Subject Name in place of populating the dNSName field of the 1099 SubjectAltName extension. 1101 4.1.2.3 EmailAddress 1103 As specified in PKIX, implementations MUST NOT populate 1104 DistinguishedNames with the EmailAddress attribute. 1106 4.1.3 X.509 Certificate Extensions 1108 Conforming applications MUST recognize extensions which must or may 1109 be marked critical according to this specification. These extensions 1110 are: KeyUsage, SubjectAltName, and BasicConstraints. 1112 Implementations SHOULD generate certificates such that the extension 1113 criticality bits are set in accordance with PKIX and this document. 1114 With respect to PKIX compliance, implementations processing 1115 certificates MAY ignore the value of the criticality bit for 1116 extensions that are supported by that implementation, but MUST 1117 support the criticality bit for extensions that are not supported by 1118 that implementation. That is, if an implementation supports (and 1119 thus is going to process) a given extension, then it isn't necessary 1120 to reject the certificate if the criticality bit is different from 1121 what PKIX states it must be. However, if an implementation does not 1122 support an extension that PKIX mandates be critical, then the 1123 implementation must reject the certificate. 1125 implements bit in cert PKIX mandate behavior 1126 ------------------------------------------------------ 1127 yes true true ok 1128 yes true false ok or reject 1129 yes false true ok or reject 1130 yes false false ok 1131 no true true reject 1132 no true false reject 1133 no false true reject 1134 no false false ok 1136 4.1.3.1 AuthorityKeyIdentifier and SubjectKey ID 1138 Implementations SHOULD NOT assume that other implementations support 1139 the AuthorityKeyIdentifier and SubjectKey ID extensions, and thus 1140 SHOULD NOT generate certificate hierarchies which are overly complex 1141 to process in the absence of this extension, such as those that 1142 require possibly verifying a signature against a large number of 1143 similarly named CA certificates in order to find the CA certificate 1144 which contains the key that was used to generate the signature. 1146 4.1.3.2 KeyUsage 1148 IKE uses an end-entity certificate in the authentication process. 1149 The end-entity certificate may be used for multiple applications. As 1150 such, the CA can impose some constraints on the manner that a public 1151 key ought to be used. The key usage and extended key usage 1152 extensions apply in this situation. 1154 Since we are talking about using the public key to validate a 1155 signature, if the key usage extension is present, then at least one 1156 of the digitalSignature (0) or the nonRepudiation (1) bit in the key 1157 usage extension MUST be set (both can be set as well). It is also 1158 fine if other key usage bits are set. 1160 A summary of the logic flow for peer cert validation follows: 1161 o If told (by configuration) to ignore KeyUsage (KU), accept cert 1162 regardless of its markings. 1163 o If no KU extension, accept cert. 1164 o If KU present and doesn't mention digitalSig or nonRepudiation, 1165 (both, in addition to other KUs, is also fine), reject cert. 1166 o If none of the above, accept cert. 1168 4.1.3.3 PrivateKeyUsagePeriod 1170 PKIX recommends against the use of this extension. The 1171 PrivateKeyUsageExtension is intended to be used when signatures will 1172 need to be verified long past the time when signatures using the 1173 private keypair may be generated. Since IKE SAs are short-lived 1174 relative to the intended use of this extension in addition to the 1175 fact that each signature is validated only a single time, the 1176 usefulness of this extension in the context of IKE is unclear. 1177 Therefore, implementations MUST NOT generate certificates that 1178 contain the PrivateKeyUsagePeriod extension. If an implementation 1179 receives a certificate with this set, it SHOULD ignore it. 1181 4.1.3.4 Certificate Policies 1183 Many IPsec implementations do not currently provide support for the 1184 Certificate Policies extension. Therefore, implementations that 1185 generate certificates which contain this extension SHOULD NOT mark 1186 the extension as critical. 1188 4.1.3.5 PolicyMappings 1190 Many implementations do not support the PolicyMappings extension. 1192 4.1.3.6 SubjectAltName 1194 Deployments that intend to use an IKE_ID of either FQDN, USER_FQDN or 1195 IP*_ADDR MUST issue certificates with the corresponding SujectAltName 1196 fields populated with the same data. Implementations SHOULD generate 1197 only the following GeneralName choices in the subjectAltName 1198 extension, as these choices map to legal IKEv1/ISAKMP/IKEv2 1199 Identification Payload types: rfc822Name, dNSName, or iPAddress. 1200 Although it is possible to specify any GeneralName choice in the 1201 Identification Payload by using the ID_DER_ASN1_GN ID type, 1202 implementations SHOULD NOT assume that a peer supports such 1203 functionality, and SHOULD NOT generate certificates that do so. 1205 4.1.3.6.1 dNSName 1207 This field MUST contain a fully qualified domain name. If IKE ID 1208 type equals FQDN then the dNSName field MUST match its contents. 1209 Implementations MUST NOT generate names that contain wildcards. 1210 Implementations MAY treat certificates that contain wildcards in this 1211 field as syntactically invalid. 1213 Although this field is in the form of an FQDN, implementations SHOULD 1214 NOT assume that this field contains an FQDN that will resolve via the 1215 DNS, unless this is known by way of some out-of-band mechanism. Such 1216 a mechanism is out of the scope of this document. Implementations 1217 SHOULD NOT treat the failure to resolve as an error. 1219 4.1.3.6.2 iPAddress 1221 If IKE ID type equals IP*_ADDR then the iPAddress field MUST match 1222 its contents. Note that although PKIX permits CIDR [10] notation in 1223 the "Name Constraints" extension, PKIX explicitly prohibits using 1224 CIDR notation for conveying identity information. In other words, 1225 the CIDR notation MUST NOT be used in the subjectAltName extension. 1227 4.1.3.6.3 rfc822Name 1229 If IKE ID type equals USER_FQDN then the rfc822Name field MUST match 1230 its contents. Although this field is in the form of an Internet mail 1231 address, implementations SHOULD NOT assume that this field contains a 1232 valid email address, unless this is known by way of some out-of-band 1233 mechanism. Such a mechanism is out of the scope of this document. 1235 4.1.3.7 IssuerAltName 1237 Implementations SHOULD NOT assume that other implementations support 1238 the IssuerAltName extension, and especially should not assume that 1239 information contained in this extension will be displayed to end 1240 users. 1242 4.1.3.8 SubjectDirectoryAttributes 1244 The SubjectDirectoryAttributes extension is intended to contain 1245 privilege information, in a manner analogous to privileges carried in 1246 Attribute Certificates. Implementations MAY ignore this extension 1247 when it is marked non-critical, as PKIX mandates. 1249 4.1.3.9 BasicConstraints 1251 PKIX mandates that CA certificates contain this extension and that it 1252 be marked critical. Implementations SHOULD reject CA certificates 1253 that do not contain this extension. For backwards compatibility, 1254 implementations may accept such certificates if explicitly configured 1255 to do so, but the default for this setting MUST be to reject such 1256 certificates. 1258 4.1.3.10 NameConstraints 1260 Many implementations do not support the NameConstraints extension. 1261 Since PKIX mandates that this extension be marked critical when 1262 present, implementations which intend to be maximally interoperable 1263 SHOULD NOT generate certificates which contain this extension. 1265 4.1.3.11 PolicyConstraints 1267 Many implementations do not support the PolicyConstraints extension. 1268 Since PKIX mandates that this extension be marked critical when 1269 present, implementations which intend to be maximally interoperable 1270 SHOULD NOT generate certificates which contain this extension. 1272 4.1.3.12 ExtendedKeyUsage 1274 The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in 1275 certificates for use with IKE. Note that there were three IPsec 1276 related object identifiers in EKU that were assigned in 1999. The 1277 semantics of these values were never clearly defined. The use of 1278 these three EKU values in IKE/IPsec is obsolete and explicitly 1279 deprecated by this specification. CAs SHOULD NOT issue certificates 1280 for use in IKE with them. (For historical reference only, those 1281 values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and 1282 id-kp-ipsecUser.) 1283 PKIX [7] section 4.2.1.13 states, "If a CA includes extended key 1284 usages to satisfy such applications, but does not wish to restrict 1285 usages of the key, the CA can include the special keyPurposeID 1286 anyExtendedKeyUsage. If the anyExtendedKeyUsage keyPurposeID is 1287 present, the extension SHOULD NOT be critical." 1289 The CA SHOULD NOT mark the EKU extension in certificates for use with 1290 IKE and one or more other applications. If the CA administrator 1291 feels they must use an EKU for some other application, then such 1292 certificates MUST contain the keyPurposeID anyExtendedKeyUsage as 1293 well as the keyPurposeID values associated with the other 1294 applications for which the certificate is intended to be used. 1295 Recall however, EKU extensions in certificates meant for use in IKE 1296 are NOT RECOMMENDED. 1298 A summary of the logic flow for peer certificate validation regarding 1299 the EKU extension follows: 1300 o If told (by configuration) to ignore ExtendedKeyUsage (EKU), 1301 accept cert regardless of the presence or absence of the 1302 extension. 1303 o If no EKU extension, accept cert. 1304 o If EKU present AND anyExtendedKeyUsage is included, accept cert. 1305 o Otherwise, reject cert. 1307 4.1.3.13 CRLDistributionPoints 1309 Because this document deprecates the sending of CRLs in band, the use 1310 of CRLDistributionPoints (CDP) becomes very important if CRLs are 1311 used for revocation checking (as opposed to say Online Certificate 1312 Status Protocol - OCSP [12]). The IPsec peer either needs to have a 1313 URL for a CRL written into its local configuration, or it needs to 1314 learn it from CDP. Therefore, implementations SHOULD issue 1315 certificates with a populated CDP. 1317 Failure to validate the CRLDistributionPoints/ 1318 IssuingDistributionPoint pair can result in CRL substitution where an 1319 entity knowingly substitutes a known good CRL from a different 1320 distribution point for the CRL which is supposed to be used which 1321 would show the entity as revoked. 1323 Implementations MUST support validating that the contents of 1324 CRLDistributionPoints match those of the IssuingDistributionPoint to 1325 prevent CRL substitution when the issuing CA is using them. At 1326 least one CA is known to default to this type of CRL use. See 1327 Section 4.2.2.5 for more information. 1329 CDPs SHOULD be "resolvable". For example some very prominent 1330 implementations are well known for including CDPs like 1331 http://localhost/path_to_CRL and http:///path_to_CRL which are as bad 1332 as not including the CDP. 1334 See PKIX docs for CRLDistributionPoints intellectual property rights 1335 (IPR) information. Note that both the CRLDistributionPoints and 1336 IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED 1337 by PKIX, so there is no requirement to license any IPR. 1339 4.1.3.14 InhibitAnyPolicy 1341 Many implementations do not support the InhibitAnyPolicy extension. 1342 Since PKIX mandates that this extension be marked critical when 1343 present, implementations which intend to be maximally interoperable 1344 SHOULD NOT generate certificates which contain this extension. 1346 4.1.3.15 FreshestCRL 1348 Implementations MUST NOT assume that the FreshestCRL extension will 1349 exist in peer extensions. Note that most implementations do not 1350 support delta CRLs. 1352 4.1.3.16 AuthorityInfoAccess 1354 PKIX defines the AuthorityInfoAccess extension, which is used to 1355 indicate "how to access CA information and services for the issuer of 1356 the certificate in which the extension appears." Because this 1357 document deprecates the sending of CRLs in band, the use of 1358 AuthorityInfoAccess (AIA) becomes very important if OCSP [12] is to 1359 be used for revocation checking (as opposed to CRLs). The IPsec peer 1360 either needs to have a URI for the OCSP query written into its local 1361 configuration, or it needs to learn it from AIA. Therefore, 1362 implementations SHOULD support this extension, especially if OCSP 1363 will be used. 1365 4.1.3.17 SubjectInfoAccess 1367 PKIX defines the SubjectInfoAccess private certificate extension, 1368 which is used to indicate "how to access information and services for 1369 the subject of the certificate in which the extension appears." This 1370 extension has no known use in the context of IPsec. Conformant 1371 implementations SHOULD ignore this extension when present 1373 4.2 X.509 Certificate Revocation Lists 1375 When validating certificates, implementations MUST make use of 1376 certificate revocation information, and SHOULD support such 1377 revocation information in the form of CRLs, unless non-CRL revocation 1378 information is known to be the only method for transmitting this 1379 information. Deployment that intend to use CRLs for revocation MUST 1380 populate the CRLDistributionPoint field. Therefore implementations 1381 MUST support issuing certificates with this field populated according 1382 to administrator's needs. Implementations MAY provide a 1383 configuration option to disable use of certain types of revocation 1384 information, but that option MUST be off by default. Such an option 1385 is often valuable in lab testing environments. 1387 4.2.1 Multiple Sources of Certificate Revocation Information 1389 Implementations which support multiple sources of obtaining 1390 certificate revocation information MUST act conservatively when the 1391 information provided by these sources is inconsistent: when a 1392 certificate is reported as revoked by one trusted source, the 1393 certificate MUST be considered revoked. 1395 4.2.2 X.509 Certificate Revocation List Extensions 1397 4.2.2.1 AuthorityKeyIdentifier 1399 Implementations SHOULD NOT assume that other implementations support 1400 the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate 1401 certificate hierarchies which are overly complex to process in the 1402 absence of this extension. 1404 4.2.2.2 IssuerAltName 1406 Implementations SHOULD NOT assume that other implementations support 1407 the IssuerAltName extension, and especially should not assume that 1408 information contained in this extension will be displayed to end 1409 users. 1411 4.2.2.3 CRLNumber 1413 As stated in PKIX, all issuers conforming to PKIX MUST include this 1414 extension in all CRLs. 1416 4.2.2.4 DeltaCRLIndicator 1418 4.2.2.4.1 If Delta CRLs Are Unsupported 1420 Implementations that do not support delta CRLs MUST reject CRLs which 1421 contain the DeltaCRLIndicator (which MUST be marked critical 1422 according to PKIX) and MUST make use of a base CRL if it is 1423 available. Such implementations MUST ensure that a delta CRL does 1424 not "overwrite" a base CRL, for instance in the keying material 1425 database. 1427 4.2.2.4.2 Delta CRL Recommendations 1429 Since some implementations that do not support delta CRLs may behave 1430 incorrectly or insecurely when presented with delta CRLs, 1431 administrators and deployers SHOULD consider whether issuing delta 1432 CRLs increases security before issuing such CRLs. 1434 And, if all the elements in the VPN and PKI systems do not adequately 1435 support Delta CRLs, then their use should be questioned. 1437 The authors are aware of several implementations which behave in an 1438 incorrect or insecure manner when presented with delta CRLs. See 1439 Appendix B for a description of the issue. Therefore, this 1440 specification RECOMMENDS NOT issuing delta CRLs at this time. On the 1441 other hand, failure to issue delta CRLs exposes a larger window of 1442 vulnerability. See the Security Considerations section of PKIX [7] 1443 for additional discussion. Implementors as well as administrators 1444 are encouraged to consider these issues. 1446 4.2.2.5 IssuingDistributionPoint 1448 A CA that is using CRLDistributionPoints may do so to provide many 1449 "small" CRLs, each only valid for a particular set of certificates 1450 issued by that CA. To associate a CRL with a certificate, the CA 1451 places the CRLDistributionPoints extension in the certificate, and 1452 places the IssuingDistributionPoint in the CRL. The 1453 distributionPointName field in the CRLDistributionPoints extension 1454 MUST be identical to the distributionPoint field in the 1455 IssuingDistributionPoint extension. At least one CA is known to 1456 default to this type of CRL use. See Section 4.1.3.13 for more 1457 information. 1459 4.2.2.6 FreshestCRL 1461 Given the recommendations against implementations generating delta 1462 CRLs, this specification RECOMMENDS that implementations do not 1463 populate CRLs with the FreshestCRL extension, which is used to obtain 1464 delta CRLs. 1466 5. Configuration Data Exchange Conventions 1468 Below we present a common format for exchanging configuration data. 1469 Implementations MUST support these formats, MUST support arbitrary 1470 whitespace at the beginning and end of any line, MUST support 1471 arbitrary line lengths although they SHOULD generate lines less than 1472 76 characters, and MUST support the following three line-termination 1473 disciplines: LF (US-ASCII 10), CR (US-ASCII 13), and CRLF. 1475 5.1 Certificates 1477 Certificates MUST be Base64 encoded and appear between the following 1478 delimiters: 1480 -----BEGIN CERTIFICATE----- 1482 -----END CERTIFICATE----- 1484 5.2 Public Keys 1486 Implementations MUST support two forms of public keys: certificates 1487 and so-called "raw" keys. Certificates should be transferred in the 1488 same form as above. A raw key is only the SubjectPublicKeyInfo 1489 portion of the certificate, and MUST be Base64 encoded and appear 1490 between the following delimiters: 1492 -----BEGIN PUBLIC KEY----- 1494 -----END PUBLIC KEY----- 1496 5.3 PKCS#10 Certificate Signing Requests 1498 A PKCS#10 [6] Certificiate Signing Request MUST be Base64 encoded and 1499 appear between the following delimiters: 1501 -----BEGIN CERTIFICATE REQUEST----- 1503 -----END CERTIFICATE REQUEST----- 1505 6. Security Considerations 1507 6.1 Identification Payload 1509 Depending on the exchange type, ID may be passed in the clear. 1510 Administrators in some environments may wish to use the empty 1511 Certification Authority option to prevent such information from 1512 leaking, at the possible cost of some performance, although such use 1513 is discouraged. 1515 6.2 Certificate Request Payload 1517 The Contents of CERTREQ are not encrypted in IKE. In some 1518 environments this may leak private information. Administrators in 1519 some environments may wish to use the empty Certification Authority 1520 option to prevent such information from leaking, at the cost of 1521 performance. 1523 6.3 Certificate Payload 1525 Depending on the exchange type, CERTs may be passed in the clear and 1526 therefore may leak identity information. 1528 6.4 IKEv1 Main Mode 1530 Certificates may be included in any message, and therefore 1531 implementations may wish to respond with CERTs in a message that 1532 offers privacy protection, in Main Mode messages 5 and 6. 1533 Implementations may not wish to respond with CERTs in the second 1534 message, thereby violating the identity protection feature of Main 1535 Mode in IKEv1. 1537 7. Intellectual Property Rights 1539 No new intellectual property rights are introduced by this document. 1541 8. IANA Considerations 1543 There are no known numbers which IANA will need to manage. 1545 9. References 1547 9.1 Normative References 1549 [1] Piper, D., "The Internet IP Security Domain of Interpretation 1550 for ISAKMP", RFC 2407, November 1998. 1552 [2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1553 RFC 2409, November 1998. 1555 [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1556 draft-ietf-ipsec-ikev2-15 (work in progress), August 2004. 1558 [4] Kent, S. and R. Atkinson, "Security Architecture for the 1559 Internet Protocol", RFC 2401, November 1998. 1561 [5] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 1562 Association and Key Management Protocol (ISAKMP)", RFC 2408, 1563 November 1998. 1565 [6] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1566 1.5", RFC 2314, March 1998. 1568 [7] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 1569 Public Key Infrastructure Certificate and Certificate Revocation 1570 List (CRL) Profile", RFC 3280, April 2002. 1572 [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 1574 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1575 Levels", BCP 14, RFC 2119, March 1997. 1577 9.2 Informative References 1579 [10] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless 1580 Inter-Domain Routing (CIDR): an Address Assignment and 1581 Aggregation Strategy", RFC 1519, September 1993. 1583 [11] Eastlake, D., "Domain Name System Security Extensions", RFC 1584 2535, March 1999. 1586 [12] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, 1587 "X.509 Internet Public Key Infrastructure Online Certificate 1588 Status Protocol - OCSP", RFC 2560, June 1999. 1590 [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1591 Specification", RFC 1883, December 1995. 1593 [14] Arsenault, A. and S. Turner, "Internet X.509 Public Key 1594 Infrastructure:Roadmap", draft-ietf-pkix-roadmap-09 (work in 1595 progress), July 2002. 1597 [15] Lynn, C., "X.509 Extensions for IP Addresses and AS 1598 Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in 1599 progress), September 2003. 1601 Author's Address 1603 Brian Korver 1604 Xythos Software, Inc. 1605 One Bush Street, Suite 600 1606 San Francisco, CA 94104 1607 US 1609 Phone: +1 415 248 3800 1610 EMail: briank@xythos.com 1612 Appendix A. Change History 1614 * August 2004 (-02) (Edited by Gregory Lebovitz, with XML formatting 1615 and cross-referencing by Paul Knight) 1617 3.1.1 the text between the **s was added to paragraph, per the 1618 question that arose in IETF60 WG session: Implementations MUST be 1619 capable of verifying that the address contained in the ID is the same 1620 as the peer source address **contained in the outer most IP header**. 1622 3.2.7 - added HTTP_CERT_LOOKUP_SUPPORTED to this section and 1623 described its use - #38 1625 3.3 - changed back sending of intermediate CA certificates from 1626 SHOULD NOT to MAY (for backward compatibility). Added text to 1627 explain further why we want to stay away from actually doing it 1628 though. 1630 3.3.8 - changed text per Knowles/Korver 2004.07.28. 1632 3.3.9.5 - Change discard of Irrelevant Certificates from may to 1633 SHOULD - #23(Kent 2004.04.26) 1635 4.1.3.2 - KU - re-worked to reflect discussion on list and in IETF60 1636 - #36 1638 4.1.3.12 - EKU - re-worked to reflect discussion on list and in 1639 IETF60 - #36 1641 [IKEv2] - update the reference to the -14 draft of May 29, 2004 1643 * July 2004 (-01) (Edited by Gregory Lebovitz) 1645 Changed ISAKMP references in Abstract and Intro to IKE. 1647 Editorial changes to make the text conform with the summary table in 1648 3.1, especially in the text following the table in 3.1. Particular 1649 note should be paid to changes in section 3.5.1. 1651 Sect 3.1.1 - editorial changes to aid in clarification. Added text 1652 on when deployers might consider using IP addr, but strongly 1653 encouraged not to. 1655 Sect 3.1.8 - removed IP address from list of practically used ID 1656 types. 1658 3.1.9 overhauled (per Kivinen, July 18) 1660 3.2 - added IKEv2's Hash and URL of x.509 to list of those profiled 1661 and gave it its own section, now 3.2.5 1663 - added note in CRL/ARL section about revocation occurring OOB of IKE 1665 - deleted ARL as its own section and collapsed it into Revocation 1666 Lists (CRL and ARL) for consciseness. Renumbered accordingly. 1668 Sect 3.2.7.2 - Changed from MUST not send empty certreqs to SHOULD 1669 send CERTREQs which contain CA fields with direction on how, but MAY 1670 send empty CERTREQs in certain case. Use case added, and specifics 1671 of both initiator and responder behavior listed. 1673 APPENDIX C added to fill out the explanation (mostly discussion from 1674 list). 1676 3.3 - clarified that sending CRLs and chaining certs is deprecated. 1678 - added IKEv2's Hash and URL of x.509 to list of those profiled and 1679 gave it its own section. Condensed ARL into CRL and renumbered 1680 accordingly. 1682 - duplicate section was removed, renumbered accordingly 1684 3.3.10.2 - title changed. sending chaining becomes SHOULD NOT. 1686 4.1.2 added text to explicity call out support for CN, C, O, OU 1688 collapsed 4.1.2.3 into 4.1.2.2 and renumbered accordingly. 1690 Collapsed 4.1.3.2 into 4.1.3.1 and renumbered accordingly 1692 Edited 4.1.3.2 Key Usage and 4.1.3.12 ExtKey Usage according to 1693 Hoffman, July18 1695 4.1.3.3 if receive cert w/ PKUP, ignore it. 1697 4.1.3.13 - CDP changed text to represent SHOULD issue, and how 1698 important CDP becomes when we do not send CRLs in-band. Added SHOULD 1699 for CDPs actually being resolvable (reilly email). 1701 Reordered 6.4 for better clarity. 1703 Added Rescorla to Acknowledgements section, as he is no longer listed 1704 as an editor, since -00. 1706 * May 2004 (renamed draft-ietf-pki4ipsec-ikecert-profile-00.txt) 1707 (edited by Brian Korver) 1709 Made it clearer that the format of the ID_IPV4_ADDR payload comes 1710 from RFC791 and is nothing new. (Tero Kivinen Feb 29) 1712 Permit implementations to skip verifying that the peer source address 1713 matches the contents of ID_IPV{4,6}_ADDR. (Tero Kivinen Feb 29, 1714 Gregory Lebovitz Feb 29) 1716 Removed paragraph suggesting that implementations favor 1717 unauthenticated peer source addresses over an unauthenticated ID for 1718 initial policy lookup. (Tero Kivinen Feb 29, Gregory Lebovitz Feb 1719 29) 1721 Removed some text implying RSA encryption mode was in scope. (Tero 1722 Kivinen Feb 29) 1724 Relaxed deprecation of PKCS#7 CERT payloads. (Tero Kivinen Feb 29) 1726 Made it clearer that out-of-scope local heuristics should be used for 1727 picking an EE cert to use when generating CERTREQ, not when receiving 1728 CERTREQ. (Tero Kivinen Feb 29) 1730 Made it clearer that CERT processing can be skipped when the contents 1731 of a CERT are already known. (Tero Kivinen Feb 29) 1733 Implementations SHOULD generate BASE64 lines less than 76 characters. 1734 (Tero Kivinen Feb 29) 1736 Added "Except where specifically stated in this document, 1737 implementations MUST conform to the requirements of PKIX" (Steve 1738 Hanna Oct 7, 2003) 1740 RECOMMENDS against populating the ID payload with IP addresses due to 1741 interoperability issues such as problem with NAT traversal. (Gregory 1742 Lebovitz May 14) 1744 Changed "as revoked by one source" to "as revoked by one trusted 1745 source". (Michael Myers, May 15) 1747 Specifying Certificate Authorities section needed to be regularized 1748 with Gregory Lebovitz's CERT proposal from -04. (Tylor Allison, May 1749 15) 1751 Added text specifying how receipients SHOULD NOT be expected to 1752 iterate over multiple end-entity certs. (Tylor Allison, May 15) 1754 Modified text to refer to IKEv2 as well as IKEv1/ISAKMP where 1755 relevant. 1757 IKEv2: Explained that IDr sent by responder doesn't have to match the 1758 [IDr] sent initiator in second exchange. 1760 IKEv2: Noted that "The identity ... does not necessarily have to 1761 match anything in the CERT payload" (S3.5) is not contradicted by 1762 SHOULD in this document. 1764 IKEv2: Noted that ID_USER_FQDN renamed to ID_RFC822_ADDR, and 1765 ID_USER_FQDN would be used exclusively in this document. 1767 IKEv2: Declared that 3 new CERTREQ and CERT types are not profiled in 1768 this document (well, at least not yet, pending WG discussion of what 1769 to do -- note that they are only SHOULDs in IKEv2). 1771 IKEv2: Noted that CERTREQ payload changed from DN to SHA-1 of 1772 SubjectPublicKeyInfo. 1774 IKEv2: Noted new requirement that specifies that the first 1775 certificate sent MUST be the EE cert (section 3.6). 1777 * February 2004 (-04) 1779 Minor editorial changes to clean up language 1781 Deprecate in-band exchange of CRLs 1783 Incorporated Gregory Lebovitz's proposal for CERT payloads: "should 1784 deal with all the CRL, Intermediat Certs, Trust Anchors, etc OOB of 1785 IKE; MUST be able to send and receive EE cert payload; only real 1786 exception is Intermediate Cets which MAY be sent and SHOULD be able 1787 to be receivable (but in reality there are very few hierarchies in 1788 operation, so really it's a corner case); SHOULD NOT send the other 1789 stuff (CRL, Trust Anchors, etc) in cert payloads in IKE; SHOULD be 1790 able to accept the other stuff if by chance it gets sent, though we 1791 hope they don't get sent" 1793 Incorporated comments contained in Oct 7, 2003 email from 1794 steve.hanna@sun.com to ipsec@lists.tislabs.com 1796 Moved text from "Profile of ISAKMP" Background section to each 1797 payload section (removing duplication of these sections) 1799 Removed "Certificate-Related Playloads in ISAKMP" section since it 1800 was not specific to IKE. 1802 Incorporated Gregory Lebovitz's table in the "Identification Payload" 1803 section 1805 Moved text from "binding identity to policy" sections to each payload 1806 section 1808 Moved text from "IKE" section into now-combined "IKE/ISAKMP" section 1810 ID_USER_FQDN and ID_FQDN promoted to MUST from MAY 1812 Promoted sending ID_DER_ASN1_DN to MAY from SHOULD NOT, and receiving 1813 from MUST from MAY 1815 Demoted ID_DER_ASN1_GN to MUST NOT 1817 Demoted populating Subject Name in place of populating the dNSName 1818 from SHOULD NOT to MUST NOT and removed the text regarding 1819 domainComponent 1821 Revocation information checking MAY now be disabled, although not by 1822 default 1824 Aggressive Mode removed from this profile 1826 * June 2003 (-03) 1828 Minor editorial changes to clean up language 1830 Minor additional clarifying text 1832 Removed hyphenation 1834 Added requirement that implementations support configuration data 1835 exchange having arbitrary line lengths 1837 * February 2003 (-02) 1839 Word choice: move from use of "root" to "trust anchor", in accordance 1840 with PKIX 1842 SBGP note and reference for placing address subnet and range 1843 information into certificates 1845 Clarification of text regarding placing names of hosts into the Name 1846 commonName attribute of SubjectName 1848 Added table to clarify text regarding processing of the certificate 1849 extension criticality bit 1851 Added text underscoring processing requirements for 1852 CRLDistributionPoints and IssuingDistributionPoint 1854 * October 2002, Reorganization (-01) 1856 * June 2002, Initial Draft (-00) 1858 Appendix B. The Possible Dangers of Delta CRLs 1860 The problem is that the CRL processing algorithm is sometimes written 1861 incorrectly with the assumption that all CRLs are base CRLs and it is 1862 assumed that CRLs will pass content validity tests. Specifically, 1863 such implementations fail to check the certificate against all 1864 possible CRLs: if the first CRL that is obtained from the keying 1865 material database fails to decode, no further revocation checks are 1866 performed for the relevant certificate. This problem is compounded 1867 by the fact that implementations which do not understand delta CRLs 1868 may fail to decode such CRLs due to the critical DeltaCRLIndicator 1869 extension. The algorithm that is implemented in this case is 1870 approximately: 1871 o fetch newest CRL 1872 o check validity of CRL signature 1873 o if CRL signature is valid then 1874 o if CRL does not contain unrecognized critical extensions 1875 o and certificate is on CRL then 1876 o set certificate status to revoked 1878 The authors note that a number of PKI toolkits do not even provide a 1879 method for obtaining anything but the newest CRL, which in the 1880 presence of delta CRLs may in fact be a delta CRL, not a base CRL. 1882 Note that the above algorithm is dangerous in many ways. See PKIX 1883 [7] for the correct algorithm. 1885 Appendix C. More on Empty CERTREQs 1887 Sending empty certificate requests is commonly used in 1888 implementations, and in the IPsec interop meetings, vendors have 1889 generally agreed that it means that send all/any certificates you 1890 have (if multiple certificates are sent, they must have same public 1891 key, as otherwise the other end does not know which key was used). 1892 For 99% of cases the client have exactly one certificate and public 1893 key, so it really doesn't matter, but the server might have multiple, 1894 thus it simply needs to say to the client, use any certificate you 1895 have. If we are talking about corporate vpns etc, even if the client 1896 have multiple certificates or keys, all of them would be usable when 1897 authenticating to the server, so client can simply pick one. 1899 If there is some real difference on which cert to use (like ones 1900 giving different permissions), then the client MUST be configured 1901 anyways, or it might even ask the user which one to use (the user is 1902 the only one who knows whether he needs admin privileges, thus needs 1903 to use admin cert, or is the normal email privileges ok, thus using 1904 email only cert). 1906 99% of the cases the client have exactly one certificate, so it will 1907 send it. In 90% of the rest of the cases, any of the certificates is 1908 ok, as they are simply different certificates from same CA, or 1909 different CAs for the same corporate VPN, thus any of them is ok. 1911 Sending empty certificate requests has been agreed there to mean 1912 "give me a cert; any cert". 1914 Justification: 1915 o Responder first does all it can to send a certreq with a CA, check 1916 for IP match in SPD, have a default set of CAs to use in ambiguous 1917 cases, etc. 1918 o sending empty certreq's is fairly common in implementations today, 1919 and is generally accepted to mean "send me a cert, any cert that 1920 works for you" 1921 o saves responder sending potentially 100's of certs, the 1922 fragmentation problems that follow, etc. 1923 o in +90% of use cases, Initiators have exactly 1 cert 1924 o in +90% of the remaining use cases, the multiple certs it has are 1925 issued by the same CA 1926 o in the remaining use case(s) -- if not all the others above -- the 1927 Initiator will be configured explicitly with which cert to send, 1928 so responding to an empty certreq is easy. 1930 The following example shows why initiators need to have sufficient 1931 policy definition to know which certificate to use for a given 1932 connection it initiates. 1934 EXAMPLE: Your client (initiator) is configured with VPN policies for 1935 gateways A and B (representing perhaps corporate partners). 1937 The policies for the two gateways look something like: 1939 Acme Company policy (gateway A) 1940 Engineering can access 10.1.1.0 1941 Trusted CA: CA-A, Trusted Users: OU=Engineering 1942 Partners can access 20.1.1.0 1943 Trusted CA: CA-B, Trusted Users: OU=AcmePartners 1945 Bizco Company policy (gateway B) 1946 sales can access 30.1.1.0 1947 Trusted CA: CA-C, Trusted Users: OU=Sales 1948 Partners can access 40.1.1.0 1949 Trusted CA: CA-B, Trusted Users: OU=BizcoPartners 1951 You are an employee of Acme and you are issued the following 1952 certificates: 1953 o From CA-A: CN=JoeUser,OU=Engineering 1954 o From CA-B: CN=JoePartner,OU=BizcoPartners 1956 The client MUST be configured locally to know which CA to use when 1957 connecting to either gateway. If your client is not configured to 1958 know the local credential to use for the remote gateway, this 1959 scenario will not work either. If you attempt to connect to Bizco, 1960 everything will work... as you are presented with responding with a 1961 certificate signed by CA-B or CA-C... as you only have a certificate 1962 from CA-B you are OK. If you attempt to connect to Acme, you have an 1963 issue because you are presented with an ambiguous policy selection. 1964 As the initiator, you will be presented with certificate requests 1965 from both CA A and CA B. You have certificates issued by both CAs, 1966 but only one of the certificates will be usable. How does the client 1967 know which certificate it should present? It must have sufficiently 1968 clear local policy specifying which one credential to present for the 1969 connection it initiates. 1971 Appendix D. Acknowledgements 1973 The authors would like to acknowledge the expired draft-ietf-ipsec- 1974 pki-req-05.txt for providing valuable materials for this document, 1975 especially Eric Rescorla, one of its original authors. 1977 The authors would like to especially thank Greg Carter, Russ Housley, 1978 Steve Hanna, and Gregory Lebovitz for their valuable comments, some 1979 of which have been incorporated unchanged into this document. 1981 Intellectual Property Statement 1983 The IETF takes no position regarding the validity or scope of any 1984 Intellectual Property Rights or other rights that might be claimed to 1985 pertain to the implementation or use of the technology described in 1986 this document or the extent to which any license under such rights 1987 might or might not be available; nor does it represent that it has 1988 made any independent effort to identify any such rights. Information 1989 on the procedures with respect to rights in RFC documents can be 1990 found in BCP 78 and BCP 79. 1992 Copies of IPR disclosures made to the IETF Secretariat and any 1993 assurances of licenses to be made available, or the result of an 1994 attempt made to obtain a general license or permission for the use of 1995 such proprietary rights by implementers or users of this 1996 specification can be obtained from the IETF on-line IPR repository at 1997 http://www.ietf.org/ipr. 1999 The IETF invites any interested party to bring to its attention any 2000 copyrights, patents or patent applications, or other proprietary 2001 rights that may cover technology that may be required to implement 2002 this standard. Please address the information to the IETF at 2003 ietf-ipr@ietf.org. 2005 Disclaimer of Validity 2007 This document and the information contained herein are provided on an 2008 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2009 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2010 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2011 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2012 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2013 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2015 Copyright Statement 2017 Copyright (C) The Internet Society (2004). This document is subject 2018 to the rights, licenses and restrictions contained in BCP 78, and 2019 except as set forth therein, the authors retain all their rights. 2021 Acknowledgment 2023 Funding for the RFC Editor function is currently provided by the 2024 Internet Society.