idnits 2.17.00 (12 Aug 2021) /tmp/idnits30585/draft-ietf-pki4ipsec-ikecert-profile-03.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 2123. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2100. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2107. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2113. ** 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 5 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 1166 has weird spacing: '...lements bit...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * Changed ISAKMP references in Abstract and Intro to IKE. * Editorial changes to make the text conform with the summary table in 3.1, especially in the text following the table in 3.1. Particular note should be paid to changes in section 3.5.1. * Sect 3.1.1 - editorial changes to aid in clarification. Added text on when deployers might consider using IP addr, but strongly encouraged not to. * Sect 3.1.8 removed IP address from list of practically used ID types. * 3.1.9 overhauled (per Kivinen, July 18) * 3.2 - added IKEv2's Hash and URL of x.509 to list of those profiled and gave it its own section, now 3.2.5 * added note in CRL/ARL section about revocation occurring OOB of IKE * deleted ARL as its own section and collapsed it into Revocation Lists (CRL and ARL) for consciseness. Renumbered accordingly. * Sect 3.2.7.2 - Changed from MUST not send empty certreqs to SHOULD send CERTREQs which contain CA fields with direction on how, but MAY send empty CERTREQs in certain case. Use case added, and specifics of both initiator and responder behavior listed. * APPENDIX C added to fill out the explanation (mostly discussion from list). * 3.3 - clarified that sending CRLs and chaining certs is deprecated. * added IKEv2's Hash and URL of x.509 to list of those profiled and gave it its own section. Condensed ARL into CRL and renumbered accordingly. * duplicate section was removed, renumbered accordingly * 3.3.10.2 - title changed. sending chaining becomes SHOULD NOT. * 4.1.2 added text to explicity call out support for CN, C, O, OU * collapsed 4.1.2.3 into 4.1.2.2 and renumbered accordingly. * Collapsed 4.1.3.2 into 4.1.3.1 and renumbered accordingly * Edited 4.1.3.2 Key Usage and 4.1.3.12 ExtKey Usage according to Hoffman, July18 * 4.1.3.3 if receive cert w/ PKUP, ignore it. * 4.1.3.13 - CDP changed text to represent SHOULD issue, and how important CDP becomes when we do not send CRLs in-band. Added SHOULD for CDPs actually being resolvable (reilly email). * Reordered 6.4 for better clarity. -- 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 30, 2004) is 6441 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'IKEv2' on line 1795 -- Looks like a reference, but probably isn't: 'IDr' on line 1884 == Unused Reference: '15' is defined on line 1647, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2409 (ref. '1') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '2') (Obsoleted by RFC 4306) == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 ** Obsolete normative reference: RFC 2401 (ref. '4') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3280 (ref. '5') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2407 (ref. '6') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2314 (ref. '9') (Obsoleted by RFC 2986) -- Obsolete informational reference (is this intentional?): RFC 1883 (ref. '10') (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '11') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: draft-ietf-pkix-x509-ipaddr-as-extn has been published as RFC 3779 -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. '13') (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. '14') (Obsoleted by RFC 6960) Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 13 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 31, 2005 September 30, 2004 6 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX 7 draft-ietf-pki4ipsec-ikecert-profile-03 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 31, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 IKE and PKIX both provide frameworks that must be profiled for use in 43 a given application. This document provides a profile of IKE and 44 PKIX that defines the requirements for using PKI technology in the 45 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 . . . . . . . . . . . . . . . . . . . 4 55 3. Profile of IKEv1/ISAKMP and IKEv2 . . . . . . . . . . . . . 5 56 3.1 Identification Payload . . . . . . . . . . . . . . . . . . 5 57 3.1.1 ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . . . 7 58 3.1.2 ID_FQDN . . . . . . . . . . . . . . . . . . . . . . . 9 59 3.1.3 ID_USER_FQDN . . . . . . . . . . . . . . . . . . . . . 10 60 3.1.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, 61 ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE . . . . . . . . 11 62 3.1.5 ID_DER_ASN1_DN . . . . . . . . . . . . . . . . . . . . 11 63 3.1.6 ID_DER_ASN1_GN . . . . . . . . . . . . . . . . . . . . 12 64 3.1.7 ID_KEY_ID . . . . . . . . . . . . . . . . . . . . . . 12 65 3.1.8 Selecting an Identity from a Certificate . . . . . . . 12 66 3.1.9 SubjectName for DN Only . . . . . . . . . . . . . . . 12 67 3.1.10 Binding Identity to Policy . . . . . . . . . . . . . 13 68 3.2 Certificate Request Payload . . . . . . . . . . . . . . . 13 69 3.2.1 Certificate Type . . . . . . . . . . . . . . . . . . . 13 70 3.2.2 X.509 Certificate - Signature . . . . . . . . . . . . 14 71 3.2.3 Revocation Lists (CRL and ARL) . . . . . . . . . . . . 14 72 3.2.4 PKCS #7 wrapped X.509 certificate . . . . . . . . . . 15 73 3.2.5 IKEv2's Hash and URL of X.509 certificate . . . . . . 15 74 3.2.6 Presence or Absence of Certificate Request Payloads . 15 75 3.2.7 Certificate Requests . . . . . . . . . . . . . . . . . 15 76 3.2.8 Robustness . . . . . . . . . . . . . . . . . . . . . . 18 77 3.2.9 Optimizations . . . . . . . . . . . . . . . . . . . . 18 78 3.3 Certificate Payload . . . . . . . . . . . . . . . . . . . 19 79 3.3.1 Certificate Type . . . . . . . . . . . . . . . . . . . 20 80 3.3.2 X.509 Certificate - Signature . . . . . . . . . . . . 20 81 3.3.3 Revocation Lists (CRL and ARL) . . . . . . . . . . . . 20 82 3.3.4 IKEv2's Hash and URL of X.509 Certificate . . . . . . 20 83 3.3.5 PKCS #7 wrapped X.509 certificate . . . . . . . . . . 21 84 3.3.6 Certificate Payloads Not Mandatory . . . . . . . . . . 21 85 3.3.7 Response to Multiple Certification Authority 86 Proposals . . . . . . . . . . . . . . . . . . . . . . 22 87 3.3.8 Using Local Keying Materials . . . . . . . . . . . . . 22 88 3.3.9 Multiple End-Entity Certificates . . . . . . . . . . . 22 89 3.3.10 Robustness . . . . . . . . . . . . . . . . . . . . . 22 90 3.3.11 Optimizations . . . . . . . . . . . . . . . . . . . 23 91 4. Profile of PKIX . . . . . . . . . . . . . . . . . . . . . . 24 92 4.1 X.509 Certificates . . . . . . . . . . . . . . . . . . . . 24 93 4.1.1 Versions . . . . . . . . . . . . . . . . . . . . . . . 24 94 4.1.2 SubjectName . . . . . . . . . . . . . . . . . . . . . 24 95 4.1.3 X.509 Certificate Extensions . . . . . . . . . . . . . 25 96 4.2 X.509 Certificate Revocation Lists . . . . . . . . . . . . 31 97 4.2.1 Multiple Sources of Certificate Revocation 98 Information . . . . . . . . . . . . . . . . . . . . . 31 100 4.2.2 X.509 Certificate Revocation List Extensions . . . . . 31 101 5. Configuration Data Exchange Conventions . . . . . . . . . . 33 102 5.1 Certificates . . . . . . . . . . . . . . . . . . . . . . . 33 103 5.2 CRLs and ARLs . . . . . . . . . . . . . . . . . . . . . . 33 104 5.3 Public Keys . . . . . . . . . . . . . . . . . . . . . . . 33 105 5.4 PKCS#10 Certificate Signing Requests . . . . . . . . . . . 34 106 6. Security Considerations . . . . . . . . . . . . . . . . . . 34 107 6.1 Certificate Request Payload . . . . . . . . . . . . . . . 34 108 6.2 IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 34 109 7. Intellectual Property Rights . . . . . . . . . . . . . . . . 34 110 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 111 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 112 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 34 113 9.2 Informative References . . . . . . . . . . . . . . . . . . . 35 114 Author's Address . . . . . . . . . . . . . . . . . . . . . . 36 115 A. Change History . . . . . . . . . . . . . . . . . . . . . . . 36 116 B. The Possible Dangers of Delta CRLs . . . . . . . . . . . . . 42 117 C. More on Empty CERTREQs . . . . . . . . . . . . . . . . . . . 43 118 D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 119 Intellectual Property and Copyright Statements . . . . . . . 46 121 1. Introduction 123 IKE [1], ISAKMP [2] and IKEv2 [3] provide a secure key exchange 124 mechanism for use with IPsec [4]. In many cases the peers 125 authenticate using digital certificates as specified in PKIX [5]. 126 Unfortunately, the combination of these standards leads to an 127 underspecified set of requirements for the use of certificates in the 128 context of IPsec. 130 ISAKMP references PKIX but in many cases merely specifies the 131 contents of various messages without specifying their syntax or 132 semantics. Meanwhile, PKIX provides a large set of certificate 133 mechanisms which are generally applicable for Internet protocols, but 134 little specific guidance for IPsec. Given the numerous 135 underspecified choices, interoperability is hampered if all 136 implementers do not make similar choices, or at least fail to account 137 for implementations which have chosen differently. 139 This profile of the IKE and PKIX frameworks is intended to provide an 140 agreed-upon standard for using PKI technology in the context of IPsec 141 by profiling the PKIX framework for use with IKE and IPsec, and by 142 documenting the contents of the relevant IKE payloads and further 143 specifying their semantics. 145 In addition to providing a profile of IKE and PKIX, this document 146 attempts to incorporate lessons learned from recent experience with 147 both implementation and deployment, as well as the current state of 148 related protocols and technologies. 150 Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and 151 readers of this document are assumed to have read and understood 152 those documents. The requirements and security aspects of those 153 documents are fully relevant to this document as well. 155 This document is organized as follows. Section 2 defines special 156 terminology used in the rest of this document, Section 3 provides the 157 profile of IKEv1/ISAKMP and IKEv2, and Section 4 provides the profile 158 of PKIX. Section 5 covers conventions for the out-of-band exchange 159 of keying materials for configuration purposes. 161 This document is being discussed on the pki4ipsec@icsalabs.com 162 mailing list. 164 2. Terms and Definitions 166 Except for those terms which are defined immediately below, all terms 167 used in this document are defined in either the PKIX [5], ISAKMP [2], 168 IKEv1 [1], IKEv2 [3], or DOI [6] documents. 170 o Peer source address: The source address in packets from a peer. 171 This address may be different from any addresses asserted as the 172 "identity" of the peer. 173 o FQDN: Fully qualified domain name. 174 o ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both 175 are referred to as ID_USER_FQDN in this document. 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC-2119 [7]. 181 3. Profile of IKEv1/ISAKMP and IKEv2 183 3.1 Identification Payload 185 The Identification (ID) Payload is used to indicate the identity that 186 the sender claims to be speaking for. The recipient can then use the 187 ID as a lookup key for policy and whatever certificate store or 188 directory that it has available. Our primary concern in this section 189 is to profile the ID payload so that it can be safely used to 190 generate or lookup policy. IKE mandates the use of the ID payload in 191 Phase 1. 193 The DOI [6] defines the 11 types of Identification Data that can be 194 used and specifies the syntax for these types. These are discussed 195 below in detail. 197 The ID payload requirements in this document cover only the portion 198 of the explicit policy checks that deal with the Identification 199 Payload specifically. For instance, in the case where ID does not 200 contain an IP address, checks such as verifying that the peer source 201 address is permitted by the relevant policy are not addressed here as 202 they are out of the scope of this document. 204 Implementations SHOULD populate ID with identity information that is 205 contained within the end-entity certificate (This SHOULD does not 206 contradict text in IKEv2 [3] Section 3.5 that implies a looser 207 binding between these two). Populating ID with identity information 208 from the end-entity certificate enables recipients to use ID as a 209 lookup key to find the peer end-entity certificate. The only case 210 where implementations MAY populate ID with information that is not 211 contained in the end-entity certificate is when ID contains the peer 212 source address (a single address, not a subnet or range). 214 Because implementations may use ID as a lookup key to determine which 215 policy to use, all implementations MUST be especially careful to 216 verify the truthfulness of the contents by verifying that they 217 correspond to some keying material demonstrably held by the peer. 219 Failure to do so may result in the use of an inappropriate or 220 insecure policy. The following sections describe the methods for 221 performing this binding. 223 The following table summarizes the binding of the Identification 224 Payload to the contents of end-entity certificates and of identity 225 information to policy. Each ID type is covered more thoroughly in 226 the following sections. 228 ID type | Support | Correspond | Cert | SPD lookup 229 | for send | PKIX Attrib | matching | rules 230 ------------------------------------------------------------------- 231 | | | | 232 IP*_ADDR | MUST [1] | SubjAltName | MUST [2] | [3], [4] 233 | | iPAddress | | 234 | | | | 235 FQDN | MUST [1] | SubjAltName | MUST [2] | [3], [4] 236 | | dNSName | | 237 | | | | 238 USER_FQDN| MUST [1] | SubjAltName | MUST [2] | [3], [4] 239 | | rfc822Name | | 240 | | | | 241 DN | MUST [1] | Entire | MUST [2] | MUST support lookup 242 | | Subject, | | on any combination 243 | | bitwise | | of C, CN, O, or OU 244 | | compare | | 245 | | | | 246 IP range | MUST NOT | n/a | n/a | n/a 247 | | | | 248 | | | | 249 KEY_ID | MUST NOT | n/a | n/a | n/a 250 | | | | 252 [1] = Implementation MUST have the configuration option to send this 253 ID type in the ID payload. Whether or not the ID type is used is a 254 matter of local configuration. 256 [2] = The ID in the ID payload MUST match the contents of the 257 corresponding field (listed) in the certificate exactly, with no 258 other lookup. The matched ID MAY be used for SPD lookup, but is not 259 required to be used for this. 261 [3] = At a minimum, Implementation MUST be capable of being 262 configured to perform exact matching of the ID payload contents to an 263 entry in the local SPD. 265 [4] = In addition, the implementation MAY also be configurable to 266 perform substring or wildcard matches of ID payload contents to 267 entries in the local SPD. (More on this in Section 3.1.5). 269 When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, 270 implementations MUST be able to be configured to send the same string 271 as appears in the corresponding SubjectAltName attribute. This 272 document RECOMMENDS that deployers use this configuration option. 273 All these ID types are treated the same: as strings that can be 274 compared easily and quickly to a corresponding string in an explicit 275 attribute in the certificate. Of these types, FQDN and USER_FQDN are 276 RECOMMENDED over IP addresses (see discussion in Section 3.1.1). 278 When sending a DN as ID, implementations MUST send the entire DN in 279 ID. Also, implementations MUST support at least the C, CN, O, and OU 280 attributes for SPD matching. See Section 3.1.5 for more details 281 about DN, including SPD matching. 283 Recipients MUST be able to perform SPD matching on the exact contents 284 of the ID, and this SHOULD be the default setting. In addition, 285 implementations MAY use substrings or wildcards in local policy 286 configuration to do the SPD matching against the ID contents. In 287 other words, implementations MUST be able to do exact matches of ID 288 to SPD, but MAY also be configurable to do substring or wildcard 289 matches of ID to SPD. 291 IKEv2 adds an optional IDr payload in the second exchange that the 292 initiator may send to the responder in order to specify which of the 293 responder's multiple identities should be used. The responder MAY 294 choose to send an IDr in the 3rd exchange that differs in type or 295 content from the initiator-generated IDr. The initiator MUST be able 296 to receive a responder-generated IDr that is a different type from 297 the one the initiator generated. 299 3.1.1 ID_IPV4_ADDR and ID_IPV6_ADDR 301 Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR 302 ID type, depending on whether the implementation supports IPv4, IPv6 303 or both. These addresses MUST be encoded in "network byte order," as 304 specified in IP [8]: The least significant bit (LSB) of each octet is 305 the LSB of the corresponding byte in the network address. For the 306 ID_IPV4_ADDR type, the payload MUST contain exactly four octets [8]. 307 For the ID_IPV6_ADDR type, the payload MUST contain exactly sixteen 308 octets [10]. 310 Implementations SHOULD NOT populate ID payload with IP addresses due 311 to interoperability issues such as problems with NAT traversal, and 312 problems with IP verification behavior. 314 Deployments may only want to consider using the IP address as ID if 315 the following are true: 317 o the peer's IP address is static, not dynamically changing 318 o the peer is NOT behind a NAT'ing device 319 o the administrator intends the implementation to verify that the 320 peer source address matches the IP address in the ID received, and 321 that in the iPAddress field in the peer certificate's 322 SubjectAltName extension. 324 Implementations MUST be capable of verifying that the IP address 325 presented in ID matches via bitwise comparison the IP address present 326 in the certificate's iPAddress field of the SubjectAltName extension. 327 Implementations MUST perform this verification by default. When 328 comparing the contents of ID with the iPAddress field in the 329 SubjectAltName extension for equality, binary comparison MUST be 330 performed. Note that certificates may contain multiple address 331 identity types in which case at least one must match the source IP. 332 If the default is enabled, then a mismatch between the two addresses 333 MUST be treated as an error and security association setup MUST be 334 aborted. This event SHOULD be auditable. Implementations MAY 335 provide a configuration option to (i.e. local policy configuration 336 can enable) skip that verification step, but that option MUST be off 337 by default. We include the "option-to-skip-validation" in order to 338 permit better interoperability, as today implementations vary greatly 339 in how they behave on this topic. 341 In addition, implementations MUST be capable of verifying that the 342 address contained in the ID is the same as the peer source address, 343 contained in the outer most IP header. If ID is one of the IP 344 address types, then implementations MUST perform this verification by 345 default. If this default is enabled, then a mismatch MUST be treated 346 as an error and security association setup MUST be aborted. This 347 event SHOULD be auditable. Implementations MAY provide a 348 configuration option to (i.e. local policy configuration can enable) 349 skip that verification step, but that option MUST be off by default. 350 We include the "option-to-skip-validation" in order to permit better 351 interoperability, as today implementations vary greatly in how they 352 behave on the topic of verification of source IP. 354 If the default for both the verifications above are enabled, then, by 355 transitive property, the implementation will also be verifying that 356 the peer source IP address matches via a bitwise comparison the 357 contents of the iPAddress field in the SubjectAltName extension in 358 the certificate. In addition, implementations MAY allow 359 administrators to configure a local policy that explicitly requires 360 that the peer source IP address match via a bitwise comparison the 361 contents of the iPAddress field in the SubjectAltName extension in 362 the certificate. Implementations SHOULD allow administrators to 363 configure a local policy that skips this validation check. 365 Implementations MAY support substring, wildcard, or regular 366 expression matching of the contents of ID to lookup policy in the 367 SPD, and such would be a matter of local security policy 368 configuration. 370 Implementations MAY use the IP address found in the header of packets 371 received from the peer to lookup the policy, but such implementations 372 MUST still perform verification of the ID payload. Although packet 373 IP addresses are inherently untrustworthy and must therefore be 374 independently verified, it is often useful to use the apparent IP 375 address of the peer to locate a general class of policies that will 376 be used until the mandatory identity-based policy lookup can be 377 performed. 379 For instance, if the IP address of the peer is unrecognized, a VPN 380 gateway device might load a general "road warrior" policy that 381 specifies a particular CA that is trusted to issue certificates which 382 contain a valid rfc822Name which can be used by that implementation 383 to perform authorization based on access control lists (ACLs) after 384 the peer's certificate has been validated. The rfc822Name can then 385 be used to determine the policy that provides specific authorization 386 to access resources (such as IP addresses, ports, and so forth). 388 As another example, if the IP address of the peer is recognized to be 389 a known peer VPN endpoint, policy may be determined using that 390 address, but until the identity (address) is validated by validating 391 the peer certificate, the policy MUST NOT be used to authorize any 392 IPsec traffic. 394 3.1.2 ID_FQDN 396 Implementations MUST support the ID_FQDN ID type, generally to 397 support host-based access control lists for hosts without fixed IP 398 addresses. However, implementations SHOULD NOT use the DNS to map 399 the FQDN to IP addresses for input into any policy decisions, unless 400 that mapping is known to be secure, for example if DNSSEC [11] were 401 employed. 403 If ID contains an ID_FQDN, implementations MUST be capable of 404 verifying that the identity contained in the ID payload matches 405 identity information contained in the peer end-entity certificate, in 406 the dNSName field in the SubjectAltName extension. Implementations 407 MUST perform this verification by default. When comparing the 408 contents of ID with the dNSName field in the SubjectAltName extension 409 for equality, caseless string comparison MUST be performed. 411 Substring, wildcard, or regular expression matching MUST NOT be 412 performed for this comparison. If this default is enabled, then a 413 mismatch MUST be treated as an error and security association setup 414 MUST be aborted. This event SHOULD be auditable. Implementations 415 MAY provide a configuration option to (i.e. local policy 416 configuration can enable) skip that verification step, but that 417 option MUST be off by default. We include the 418 "option-to-skip-validation" in order to permit better 419 interoperability, as today implementations vary greatly in how they 420 behave on this topic. 422 Implementations MAY support substring, wildcard, or regular 423 expression matching of the contents of ID to lookup policy in the 424 SPD, and such would be a matter of local security policy 425 configuration. 427 3.1.3 ID_USER_FQDN 429 Implementations MUST support the ID_USER_FQDN ID type, generally to 430 support user-based access control lists for users without fixed IP 431 addresses. However, implementations SHOULD NOT use the DNS to map 432 the FQDN portion to IP addresses for input into any policy decisions, 433 unless that mapping is known to be secure, for example if DNSSEC [11] 434 were employed. 436 Implementations MUST be capable of verifying that the identity 437 contained in the ID payload matches identity information contained in 438 the peer end-entity certificate, in the rfc822Name field in the 439 SubjectAltName extension. Implementations MUST perform this 440 verification by default. When comparing the contents of ID with the 441 rfc822Name field in the SubjectAltName extension for equality, 442 caseless string comparison MUST be performed. Substring, wildcard, 443 or regular expression matching MUST NOT be performed for this 444 comparison. If this default is enabled, then a mismatch MUST be 445 treated as an error and security association setup MUST be aborted. 446 This event SHOULD be auditable. Implementations MAY provide a 447 configuration option to (i.e. local policy configuration can enable) 448 skip that verification step, but that option MUST be off by default. 449 We include the "option-to-skip-validation" in order to permit better 450 interoperability, as today implementations vary greatly in how they 451 behave on this topic. 453 Implementations MAY support substring, wildcard, or regular 454 expression matching of the contents of ID to lookup policy in the 455 SPD, and such would be a matter of local security policy 456 configuration. 458 3.1.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, 459 ID_IPV6_ADDR_RANGE 461 Historically there was no standard method for putting address subnet 462 or range identity information into certificates, nor are there any 463 implementations known to support these ID types. Therefore, use of 464 these ID types is currently undefined. Implementations MUST NOT 465 generate these ID types. 467 Note that work in SBGP [12] for defining blocks of addresses using 468 the certificate extension identified by: 470 id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } 472 is experimental at this time. 474 3.1.5 ID_DER_ASN1_DN 476 Implementations MUST support receiving the ID_DER_ASN1_DN ID type. 477 Implementations MUST be capable of generating this type, and the 478 decision to do so will be a matter of local security policy 479 configuration. When generating this type, implementations MUST 480 populate the contents of ID with the SubjectName from the end-entity 481 certificate, and MUST do so such that a binary comparison of the two 482 will succeed. If there is not a match, this MUST be treated as an 483 error and security association setup MUST be aborted. This event 484 SHOULD be auditable. Note, if the certificate was erroneously 485 created such that the encoding of the SubjectName DN varies from the 486 constraints set by DER, that non-conformant DN MUST be used to 487 populate the ID payload: in other words, implementations MUST NOT 488 re-encode the DN for the purposes of making it DER if it does not 489 appear in the certificate as DER. 491 Implementations MUST NOT populate ID with the SubjectName from the 492 end-entity certificate if it is empty, even though an empty 493 certificate SubjectName is explicitly allowed in the "Subject" 494 section of PKIX. 496 Regarding SPD matching, implementations MUST be able to perform 497 matching based on a bitwise comparison of the entire DN in ID to its 498 entry in the SPD. However, operational experience has shown that 499 using the entire DN in local configuration is difficult, especially 500 in large scale deployments. Therefore, implementations also MUST be 501 able to perform SPD matches of any combination of one or more of the 502 C, CN, O, OU attributes within Subject DN in the ID to the same in 503 the SPD. Implementations MAY support matching using additional DN 504 attributes in any combination, although interoperability is far from 505 certain and dubious. Implementations MAY also support performing 506 substring, wildcard, or regular expression matches for any of its 507 supported DN attributes from ID, in any combination, to the SPD. 508 Such flexibility allows deployers to create one SPD entry on the 509 gateway for an entire department of a company (e.g. O=Foobar Inc., 510 OU=Engineering) while still allowing them to draw out other details 511 from the DN (e.g. CN=John Doe) for auditing purposes. All the above 512 is a matter of local implementation and local policy definition and 513 enforcement capability, not bits on the wire, but will have a great 514 impact on interoperability. 516 3.1.6 ID_DER_ASN1_GN 518 Implementations MUST NOT generate this type. 520 3.1.7 ID_KEY_ID 522 The ID_KEY_ID type used to specify pre-shared keys and thus is out of 523 scope. 525 3.1.8 Selecting an Identity from a Certificate 527 Implementations MUST support certificates that contain more than a 528 single identity, such as when SubjectName and the SubjectAltName 529 extension are both populated, or the SubjectAltName extension 530 contains multiple identities irrespective of whether SubjectName is 531 empty or not. In many cases a certificate will contain an identity 532 such as an IP address in the SubjectAltName extension in addition to 533 a non-empty SubjectName. 535 Implementations SHOULD populate ID with whichever identity is likely 536 to be named in the peer's policy. In practice, this generally means 537 FQDN, or USER_FQDN, but this information may also be available to the 538 administrator through some out-of-band means. In the absence of such 539 out-of-band configuration information, the identity with which an 540 implementation chooses to populate the ID payload is a local matter. 542 3.1.9 SubjectName for DN Only 544 If an FQDN is intended to be processed as an identity for the 545 purposes ID matching, it MUST be placed in the dNSName field of the 546 SubjectAltName extension. Implementations MUST NOT populate 547 SubjectName with an FQDN in place of populating the dNSName field of 548 the SubjectAltName extension. 550 While nothing prevents an FQDN, USER_FQDN, or IP address information 551 from appearing somewhere in the SubjectName contents, such entries 552 MUST NOT be interpreted as identity information for the purposes of 553 matching with ID or for policy lookup. 555 3.1.10 Binding Identity to Policy 557 In the presence of certificates that contain multiple identities, 558 implementations MUST select the most appropriate identity from the 559 certificate and populate the ID with that. The recipient MUST use 560 the identity sent as a first key when selecting the policy. The 561 recipient MUST also use the most specific policy from that database 562 if there are overlapping policies caused by wildcards (or the 563 implementation can de-correlate the policy database so there will not 564 be overlapping entries, or it can also forbid creation of overlapping 565 policies and leave the de-correlation process to the administrator, 566 but as this moves the problem to the administrator it is NOT 567 RECOMMENDED). 569 For example, imagine that a implementation is configured with a 570 certificate that contains both a non-empty SubjectName and a dNSName. 571 The sender's policy may specify which of those to use, and it 572 indicates the policy to the other end by sending that ID. If the 573 recipient has both a specific policy for the dNSName for this host 574 and generic wildcard rule for some attributes present in the 575 SubjectName, it will match a different policy depending which ID is 576 sent. As the sender knows why it wanted to connect the peer, it also 577 knows what identity it should use to match the policy it needs to the 578 operation it tries to perform; it is the only party who can select 579 the ID adequately. 581 In the event the policy cannot be found in the recipient's SPD using 582 the ID sent, then the recipient MAY use the other identities in the 583 certificate when attempting to match a suitable policy. For example, 584 say the certificate contains non-empty SubjectName, a dNSName and an 585 iPAddress. If an iPAddress is sent in ID but no specific entry 586 exists for the address in the policy database, the recipient MAY 587 search in the policy database based on the SubjectName or the dNSName 588 contained in the certificate. 590 3.2 Certificate Request Payload 592 The Certificate Request (CERTREQ) Payload allows an implementation to 593 request that a peer provide some set of certificates or certificate 594 revocation lists. It is not clear from ISAKMP exactly how that set 595 should be specified or how the peer should respond. We describe the 596 semantics on both sides. 598 3.2.1 Certificate Type 600 The Certificate Type field identifies to the peer the type of 601 certificate keying materials that are desired. ISAKMP defines 10 602 types of Certificate Data that can be requested and specifies the 603 syntax for these types, and IKEv2 specifies 3 additional types. For 604 the purposes of this document, only the following types are relevant: 606 o X.509 Certificate - Signature 607 o Revocation Lists (CRL and ARL) 608 o PKCS #7 wrapped X.509 certificate 609 o IKEv2's Hash and URL of X.509 certificate 611 The use of the other types: 613 o X.509 Certificate - Key Exchange 614 o PGP Certificate 615 o DNS Signed Key 616 o Kerberos Tokens 617 o SPKI Certificate 618 o X.509 Certificate Attribute 619 o IKEv2's Raw RSA Key 620 o IKEv2's Hash and URL of X.509 bundle 622 are out of the scope of this document. 624 3.2.2 X.509 Certificate - Signature 626 This type requests that the end-entity certificate be a signing 627 certificate. 629 3.2.3 Revocation Lists (CRL and ARL) 631 ISAKMP and IKEv2 do not support Certificate Payload sizes over 632 approximately 64K, which is too small for many CRLs. Therefore, the 633 acquisition of revocation material is to be dealt with out-of-band of 634 IKE. For this and other reasons, implementations SHOULD NOT generate 635 CERTREQs where the Certificate Type is "Certificate Revocation List 636 (CRL)" or "Authority Revocation List (ARL)". Implementations that do 637 generate such CERTREQs MUST NOT require the recipient to respond with 638 a CRL or ARL, and MUST NOT fail when not receiving any. Upon receipt 639 of such a CERTREQ, implementations MAY ignore the request. 641 In lieu of exchanging revocation lists in-band, a pointer to 642 revocation checking SHOULD be listed in either the 643 CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA) 644 certificate extensions (see Section 4 for details). Unless other 645 methods for obtaining revocation information are available, 646 implementations SHOULD be able to process these attributes, and from 647 them be able to identify cached revocation material, or retrieve the 648 relevant revocation material from a URL, for validation processing. 649 In addition, implementations MUST have the ability to configure 650 validation checking information for each certification authority. 652 Regardless of the method (CDP, AIA, or static configuration), the 653 acquisition of revocation material SHOULD occur out-of-band of IKE. 655 3.2.4 PKCS #7 wrapped X.509 certificate 657 This ID type defines a particular encoding (not a particular 658 certificate type), some current implementations may ignore CERTREQs 659 they receive which contain this ID type, and the authors are unaware 660 of any implementations that generate such CERTREQ messages. 661 Therefore, the use of this type is deprecated. Implementations 662 SHOULD NOT require CERTREQs that contain this Certificate Type. 663 Implementations which receive CERTREQs which contain this ID type MAY 664 treat such payloads as synonymous with "X.509 Certificate - 665 Signature". 667 3.2.5 IKEv2's Hash and URL of X.509 certificate 669 This ID type defines a request for the peer to send a hash and URL of 670 it X.509 certificate, instead of the actual certificate itself. This 671 is a particularly useful mechanism when the peer is a device with 672 little memory and lower bandwidth, e.g. a mobile handset or consumer 673 electronics device. 675 If the IKEv2 implementation supports URL lookups, and prefers such a 676 URL to receiving actual certificates, then the implementation will 677 want to send a notify of type HTTP_CERT_LOOKUP_SUPPORTED. From IKEv2 678 [3], section 3.10.1, "This notification MAY be included in any 679 message that can include a CERTREQ payload and indicates that the 680 sender is capable of looking up certificates based on an HTTP-based 681 URL (and hence presumably would prefer to receive certificate 682 specifications in that format)." If an HTTP_LOOKUP_SUPPORTED 683 notification is sent the sender MUST support the http scheme. See 684 Section 3.3.4 for more discussion. 686 3.2.6 Presence or Absence of Certificate Request Payloads 688 When in-band exchange of certificate keying materials is desired, 689 implementations MUST inform the peer of this by sending at least one 690 CERTREQ. In other words, an implementation which does not send any 691 CERTREQs during an exchange SHOULD NOT expect to receive any CERT 692 payloads. 694 3.2.7 Certificate Requests 696 3.2.7.1 Specifying Certification Authorities 698 When requesting in-band exchange of keying materials, implementations 699 SHOULD generate CERTREQs for every peer trust anchor that local 700 policy explicitly deems trusted during a given exchange. For IKEv1, 701 implementations SHOULD populate the Certification Authority field 702 with the SubjectName of the trust anchor, populated such that binary 703 comparison of the SubjectName and the Certification Authority will 704 succeed. For IKEv2, implementations MUST populate the Certification 705 Authority field as specified in IKEv2 [3]. 707 Upon receipt of a CERTREQ, implementations MUST respond by sending at 708 least the end-entity certificate corresponding to the Certification 709 Authority listed in the CERTREQ unless local security policy 710 configuration specifies that keying materials must be exchanged 711 out-of-band. Implementations MAY send certificates other than the 712 end-entity certificate (see Section 3.3 for discussion). 714 Note, in the case where multiple end-entity certificates may be 715 available which chain to different trust anchors, implementations 716 SHOULD resort to local heuristics to determine which trust anchor is 717 most appropriate to use for generating the CERTREQ. Such heuristics 718 are out of the scope of this document. 720 3.2.7.2 Empty Certification Authority Field 722 Implementations SHOULD generate CERTREQs where the Certificate Type 723 is "X.509 Certificate - Signature" and where a the Certification 724 Authority field is not empty. However, implementations MAY generate 725 CERTREQs with an empty Certification Authority field under special 726 conditions. Although PKIX prohibits certificates with empty 727 IssuerName fields, there does exist a use case where doing so is 728 appropriate, and carries special meaning in the IKE context. This 729 has become a convention within the IKE interoperability tests and 730 usage space, and so its use is specified, explained here for the sake 731 of interoperability. 733 USE CASE: Consider the rare case where you have a gateway with 734 multiple policies for a large number of IKE peers: some of these 735 peers are business partners, some are remote access employees, some 736 are teleworkers, some are branch offices, and/or the gateway may be 737 simultaneously serving many customers (e.g. Virtual Routers). The 738 total number of certificates, and corresponding trust anchors, is 739 very high, say hundreds. Each of these policies is configured with 740 one or more acceptable trust anchors, so that in total, the gateway 741 has one hundred (100) trust anchors that could possibly used to 742 authenticate an incoming connection. Assume that many of those 743 connections originate from hosts/gateways with dynamically assigned 744 IP addresses, so that the source IP of the IKE initiator is not known 745 to the gateway, nor is the identity of the initiator (until it is 746 revealed in Main Mode message 5). In IKE main mode message 4, the 747 responder gateway will need to send a CERTREQ to the initiator. 749 Given this example, the gateway will have no idea which of the 750 hundred possible Certification Authorities to send in the CERTREQ. 751 Sending all possible Certification Authorities will cause significant 752 processing delays, bandwidth consumption, and UDP fragmentation, so 753 this tactic is ruled out. 755 In such a deployment, the responder gateway implementation should be 756 able to do all it can to indicate a Certification Authority in the 757 CERTREQ. This means the responder SHOULD first check SPD to see if 758 it can match the source IP, and find some indication of which CA is 759 associated with that IP. If this fails (because the source IP is not 760 familiar, as in the case above), then the responder SHOULD have a 761 configuration option specifying which CA's are the default CAs to 762 indicate in CERTREQ during such ambiguous connections (e.g. send 763 CERTREQ with these N CAs if there is an unknown source IP). If such 764 a fall-back is not configured or impractical in a certain deployment 765 scenario, then the responder implementation SHOULD have both of the 766 following configuration options: 768 o send a CERTREQ payload with an empty Certification Authority 769 field, or 770 o terminate the negotiation with an appropriate error message and 771 audit log entry. 773 Receiving a CERTREQ payload with an empty Certification Authority 774 field indicates that the recipient should send all/any end-entity 775 certificates it has, regardless of the trust anchor. The initiator 776 should be aware of what policy and which identity it will use, as it 777 initiated the connection on a matched policy to begin with, and can 778 thus respond with the appropriate certificate. 780 If, after sending an empty CERTREQ in Main Mode message 4, a 781 responder receives a certificate in message 5 that chains to a trust 782 anchor that the responder either (a) does NOT support, or (b) was not 783 configured for the policy (that policy was now able to be matched due 784 to having the initiator's certificate present), this MUST be treated 785 as an error and security association setup MUST be aborted. This 786 event SHOULD be auditable. 788 Instead of sending a empty CERTREQ, the responder implementation MAY 789 be configured to terminate the negotiation on the grounds of a 790 conflict with locally configured security policy. 792 The decision of which to configure is a matter of local security 793 policy, this document RECOMMENDS that both options be presented to 794 administrators. 796 More examples, and explanation on this issue are included in "More on 797 Empty CERTREQs" (Appendix C). 799 3.2.8 Robustness 801 3.2.8.1 Unrecognized or Unsupported Certificate Types 803 Implementations MUST be able to deal with receiving CERTREQs with 804 unsupported Certificate Types. Absent any recognized and supported 805 CERTREQ types, implementations MAY treat them as if they are of a 806 supported type with the Certification Authority field left empty, 807 depending on local policy. ISAKMP [2] Section 5.10 "Certificate 808 Request Payload Processing" specifies additional processing. 810 3.2.8.2 Undecodable Certification Authority Fields 812 Implementations MUST be able to deal with receiving CERTREQs with 813 undecodable Certification Authority fields. Implementations MAY 814 ignore such payloads, depending on local policy. ISAKMP specifies 815 other actions which may be taken. 817 3.2.8.3 Ordering of Certificate Request Payloads 819 Implementations MUST NOT assume that CERTREQs are ordered in any way. 821 3.2.9 Optimizations 823 3.2.9.1 Duplicate Certificate Request Payloads 825 Implementations SHOULD NOT send duplicate CERTREQs during an 826 exchange. 828 3.2.9.2 Name Lowest 'Common' Certification Authorities 830 When a peer's certificate keying materials have been cached, an 831 implementation can send a hint to the peer to elide some of the 832 certificates the peer would normally respond with. In addition to 833 the normal set of CERTREQs that are sent specifying the trust 834 anchors, an implementation MAY send CERTREQs specifying the relevant 835 cached end-entity certificates. When sending these hints, it is 836 still necessary to send the normal set of trust anchor CERTREQs 837 because the hints do not sufficiently convey all of the information 838 required by the peer. Specifically, either the peer may not support 839 this optimization or there may be additional chains that could be 840 used in this context but will not be if only the end-entity 841 certificate is specified. 843 No special processing is required on the part of the recipient of 844 such a CERTREQ, and the end-entity certificates will still be sent. 846 On the other hand, the recipient MAY elect to elide certificates 847 based on receipt of such hints. 849 CERTREQs must contain information that identifies a Certification 850 Authority certificate, which results in the peer always sending at 851 least the end-entity certificate. Always sending the end-entity 852 certificate allows implementations to determine unambiguously when a 853 new certificate is being used by a peer (perhaps because the previous 854 certificate has just expired), which may result in a failure because 855 a new intermediate CA certificate might not be available to validate 856 the new end-entity certificate). Implementations which implement 857 this optimization MUST recognize when the end-entity certificate has 858 changed and respond to it by not performing this optimization if the 859 exchange must be retried so that any missing keying materials will be 860 sent during retry. 862 3.2.9.3 Example 864 Imagine that an IKEv1 implementation has previously received and 865 cached the peer certificate chain TA->CA1->CA2->EE. If during a 866 subsequent exchange this implementation sends a CERTREQ containing 867 the SubjectName in certificate TA, this implementation is requesting 868 that the peer send at least 3 certificates: CA1, CA2, and EE. On the 869 other hand, if this implementation also sends a CERTREQ containing 870 the SubjectName of CA2, the implementation is providing a hint that 871 only 1 certificate needs to be sent: EE. Note that in this example, 872 the fact that TA is a trust anchor should not be construed to imply 873 that TA is a self-signed certificate. 875 3.3 Certificate Payload 877 The Certificate (CERT) Payload allows the peer to transmit a single 878 certificate or CRL. Multiple certificates should be transmitted in 879 multiple payloads. For backwards compatibility reasons, 880 implementations MAY send intermediate CA certificates in addition to 881 the appropriate end-entity certificate, but SHOULD NOT send any CRLs, 882 ARLs, or trust anchors. The reason for not exchanging CRLs or ARLs 883 in IKE is to: 885 o decrease UDP fragmentation 886 o simplify the IKE exchange 887 o reduce bandwidth requirements for IKE exchanges 889 Multiple certificates should be transmitted in multiple payloads. 890 However, not all certificate forms that are legal in PKIX make sense 891 in the context of IPsec. The issue of how to represent 892 IKE-meaningful name-forms in a certificate is especially problematic. 893 This document provides a profile for a subset of PKIX that makes 894 sense for IKEv1/ISAKMP and IKEv2. 896 3.3.1 Certificate Type 898 The Certificate Type field identifies to the peer the type of 899 certificate keying materials that are included. ISAKMP defines 10 900 types of Certificate Data that can be sent and specifies the syntax 901 for these types, and IKEv2 specifies 3 additional types. For the 902 purposes of this document, only the following types are relevant: 904 o X.509 Certificate - Signature 905 o Revocation Lists (CRL and ARL) 906 o PKCS #7 wrapped X.509 certificate 907 o IKEv2's Hash and URL of X.509 certificate 909 The use of the other types: 911 o X.509 Certificate - Key Exchange 912 o PGP Certificate 913 o DNS Signed Key 914 o Kerberos Tokens 915 o SPKI Certificate 916 o X.509 Certificate Attribute 917 o IKEv2's Raw RSA Key 918 o IKEv2's Hash and URL of X.509 bundle 920 are out of the scope of this document. 922 3.3.2 X.509 Certificate - Signature 924 This type specifies that Certificate Data contains a certificate used 925 for signing. 927 3.3.3 Revocation Lists (CRL and ARL) 929 These types specify that Certificate Data contains an X.509 CRL or 930 ARL. These types SHOULD NOT be sent in IKE. See Section 3.2.3 for 931 discussion. 933 3.3.4 IKEv2's Hash and URL of X.509 Certificate 935 This type specifies that Certificate Data contains a hash and the URL 936 to a repository where an X.509 certificate can be retrieved. 938 An implementation that sends a HTTP_LOOKUP_SUPPORTED notification 939 MUST support the http scheme and MAY support the ftp scheme, and MUST 940 NOT require any specific form of the url-path and it SHOULD support 941 having user-name, password and port parts in the URL. The following 942 are examples of mandatory forms: 944 o http://certs.example.com/certificate.crt 945 o http://certs.example.com/certs/cert.pl?u=foo;a=pw;valid-to=+86400 946 o http://certs.example.com/%0a/../foo/bar/zappa 948 while the following is an example of a form that SHOULD be supported: 950 o http://user:password@certs.example.com:8888/certificate.crt 952 The following is an example of the ftp scheme that MAY be supported: 954 o ftp://ftp.example.com/pub/certificate.crt 956 3.3.5 PKCS #7 wrapped X.509 certificate 958 This type defines a particular encoding, not a particular certificate 959 type. Implementations SHOULD NOT generate CERTs that contain this 960 Certificate Type. Implementations SHOULD accept CERTs that contain 961 this Certificate Type because several implementations are known to 962 generate them. Note that those implementations sometimes include 963 entire certificate hierarchies inside a single CERT PKCS #7 payload, 964 which violates the requirement specified in ISAKMP that this payload 965 contain a single certificate. 967 3.3.6 Certificate Payloads Not Mandatory 969 An implementation which does not receive any CERTREQs during an 970 exchange SHOULD NOT send any CERT payloads, except when explicitly 971 configured to proactively send CERT payloads in order to interoperate 972 with non-compliant implementations which fail to send CERTREQs even 973 when certificates are desired. In this case, an implementation MAY 974 send the certificate chain (not including the trust anchor) 975 associated with the end-entity certificate. This MUST NOT be the 976 default behavior of implementations. 978 Implementations whose local security policy configuration expects 979 that a peer must receive certificates through out-of-band means 980 SHOULD ignore any CERTREQ messages that are received. 982 Implementations that receive CERTREQs from a peer which contain only 983 unrecognized Certification Authorities SHOULD NOT continue the 984 exchange, in order to avoid unnecessary and potentially expensive 985 cryptographic processing, denial of service (resource starvation) 986 attacks. 988 3.3.7 Response to Multiple Certification Authority Proposals 990 In response to multiple CERTREQs which contain different 991 Certification Authority identities, implementations MAY respond using 992 an end-entity certificate which chains to a CA that matches any of 993 the identities provided by the peer. 995 3.3.8 Using Local Keying Materials 997 Implementations MAY elect to skip parsing or otherwise decoding a 998 given set of CERTs if equivalent keying materials are available via 999 some preferable means, such as the case where certificates from a 1000 previous exchange have been cached. 1002 3.3.9 Multiple End-Entity Certificates 1004 Implementations SHOULD NOT send multiple end-entity certificates and 1005 recipients SHOULD NOT be expected to iterate over multiple end-entity 1006 certificates. 1008 If multiple end-entity certificates are sent, they MUST have the same 1009 public key, otherwise the responder does not know which key was used 1010 in the Main Mode message 5. 1012 3.3.10 Robustness 1014 3.3.10.1 Unrecognized or Unsupported Certificate Types 1016 Implementations MUST be able to deal with receiving CERTs with 1017 unrecognized or unsupported Certificate Types. Implementations MAY 1018 discard such payloads, depending on local policy. ISAKMP [2] Section 1019 5.10 "Certificate Request Payload Processing" specifies additional 1020 processing. 1022 3.3.10.2 Undecodable Certificate Data Fields 1024 Implementations MUST be able to deal with receiving CERTs with 1025 undecodable Certificate Data fields. Implementations MAY discard 1026 such payloads, depending on local policy. ISAKMP specifies other 1027 actions which may be taken. 1029 3.3.10.3 Ordering of Certificate Payloads 1031 For IKEv1, implementations MUST NOT assume that CERTs are ordered in 1032 any way. For IKEv2, implementations MUST NOT assume that any except 1033 the first CERT is ordered in any way. IKEv2 specifies that the first 1034 CERT contain an end-entity certificate which can be used to 1035 authenticate the peer. 1037 3.3.10.4 Duplicate Certificate Payloads 1039 Implementations MUST support receiving multiple identical CERTs 1040 during an exchange. 1042 3.3.10.5 Irrelevant Certificates 1044 Implementations MUST be prepared to receive certificates and CRLs 1045 which are not relevant to the current exchange. Implementations MAY 1046 discard such extraneous certificates and CRLs. 1048 Implementations MAY send certificates which are irrelevant to an 1049 exchange. One reason for including certificates which are irrelevant 1050 to an exchange is to minimize the threat of leaking identifying 1051 information in exchanges where CERT is not encrypted. It should be 1052 noted, however, that this probably provides rather poor protection 1053 against leaking the identity. 1055 Another reason for including certificates that seem irrelevant to an 1056 exchange is that there may be two chains from the Certification 1057 Authority to the end entity, each of which is only valid with certain 1058 validation parameters (such as acceptable policies). Since the 1059 end-entity doesn't know which parameters the relying party is using, 1060 it should send the certificates needed for both chains (even if 1061 there's only one CERTREQ). 1063 Implementations SHOULD NOT send multiple end-entity certificates and 1064 recipients SHOULD NOT be expected to iterate over multiple end-entity 1065 certificates. 1067 3.3.11 Optimizations 1069 3.3.11.1 Duplicate Certificate Payloads 1071 Implementations SHOULD NOT send duplicate CERTs during an exchange. 1072 Such payloads should be suppressed. 1074 3.3.11.2 Send Lowest 'Common' Certificates 1076 When multiple CERTREQs are received which specify certificate 1077 authorities within the end-entity certificate chain, implementations 1078 MAY send the shortest chain possible. However, implementations 1079 SHOULD always send the end-entity certificate. See Section 3.2.9.2 1080 for more discussion of this optimization. 1082 3.3.11.3 Ignore Duplicate Certificate Payloads 1084 Implementations MAY employ local means to recognize CERTs that have 1085 already been received and SHOULD discard these duplicate CERTs. 1087 3.3.11.4 Hash Payload 1089 IKEv1 specifies the optional use of the Hash Payload to carry a 1090 pointer to a certificate in either of the Phase 1 public key 1091 encryption modes. This pointer is used by an implementation to 1092 locate the end-entity certificate that contains the public key that a 1093 peer should use for encrypting payloads during the exchange. 1095 Implementations SHOULD include this payload whenever the public 1096 portion of the keypair has been placed in a certificate. 1098 4. Profile of PKIX 1100 Except where specifically stated in this document, implementations 1101 MUST conform to the requirements of PKIX [5]. 1103 4.1 X.509 Certificates 1105 4.1.1 Versions 1107 Although PKIX states that "implementations SHOULD be prepared to 1108 accept any version certificate", in practice this profile requires 1109 certain extensions that necessitate the use of Version 3 certificates 1110 for all but self-signed certificates used as trust anchors. 1111 Implementations that conform to this document MAY therefore reject 1112 Version 1 and Version 2 certificates in all other cases. 1114 4.1.2 SubjectName 1116 Certification Authority implementations MUST be able to create 1117 certificates with SubjectName fields with at least the following four 1118 attributes: CN, C, O, OU. Implementations MAY support other 1119 SubjectName attributes as well. The contents of these attributes 1120 SHOULD be configurable on a certificate by certificate basis, as 1121 these fields will likely be used by IKE implementations to match SPD 1122 policy. 1124 See Section 3.1.5 for details on how IKE implementations need to be 1125 able to process SubjectName field attributes for SPD policy lookup. 1127 4.1.2.1 Empty SubjectName 1129 IKE Implementations MUST accept certificates which contain an empty 1130 SubjectName field, as specified in PKIX. Identity information in 1131 such certificates will be contained entirely in the SubjectAltName 1132 extension. 1134 4.1.2.2 Specifying Hosts and not FQDN in SubjectName 1136 Implementations which desire to place host names that are not 1137 intended to be processed by recipients as FQDNs (for instance 1138 "Gateway Router") in the SubjectName MUST use the commonName 1139 attribute. 1141 4.1.2.3 EmailAddress 1143 As specified in PKIX, implementations MUST NOT populate 1144 DistinguishedNames with the emailAddress attribute. 1146 4.1.3 X.509 Certificate Extensions 1148 Conforming IKE implementations MUST recognize extensions which must 1149 or may be marked critical according to this specification. These 1150 extensions are: KeyUsage, SubjectAltName, and BasicConstraints. 1152 Certification Authority implementations SHOULD generate certificates 1153 such that the extension criticality bits are set in accordance with 1154 PKIX and this document. With respect to PKIX compliance, IKE 1155 implementations processing certificates MAY ignore the value of the 1156 criticality bit for extensions that are supported by that 1157 implementation, but MUST support the criticality bit for extensions 1158 that are not supported by that implementation. That is, if an 1159 implementation supports (and thus is going to process) a given 1160 extension, then it isn't necessary to reject the certificate if the 1161 criticality bit is different from what PKIX states it must be. 1162 However, if an implementation does not support an extension that PKIX 1163 mandates be critical, then the implementation must reject the 1164 certificate. 1166 implements bit in cert PKIX mandate behavior 1167 ------------------------------------------------------ 1168 yes true true ok 1169 yes true false ok or reject 1170 yes false true ok or reject 1171 yes false false ok 1172 no true true reject 1173 no true false reject 1174 no false true reject 1175 no false false ok 1177 4.1.3.1 AuthorityKeyIdentifier and SubjectKeyIdentifier 1179 Implementations SHOULD NOT assume support for the 1180 AuthorityKeyIdentifier or SubjectKeyIdentifier extensions, and thus 1181 Certification Authority implementations SHOULD NOT generate 1182 certificate hierarchies which are overly complex to process in the 1183 absence of these extensions, such as those that require possibly 1184 verifying a signature against a large number of similarly named CA 1185 certificates in order to find the CA certificate which contains the 1186 key that was used to generate the signature. 1188 4.1.3.2 KeyUsage 1190 IKE uses an end-entity certificate in the authentication process. 1191 The end-entity certificate may be used for multiple applications. As 1192 such, the CA can impose some constraints on the manner that a public 1193 key ought to be used. The KeyUsage and ExtendedKeyUsage extensions 1194 apply in this situation. 1196 Since we are talking about using the public key to validate a 1197 signature, if the KeyUsage extension is present, then at least one of 1198 the digitalSignature or the nonRepudiation bits in the KeyUsage 1199 extension MUST be set (both can be set as well). It is also fine if 1200 other KeyUsage bits are set. 1202 A summary of the logic flow for peer cert validation follows: 1204 o If told (by configuration) to ignore KeyUsage (KU), accept cert 1205 regardless of its markings. 1206 o If no KU extension, accept cert. 1207 o If KU present and doesn't mention digitalSignature or 1208 nonRepudiation (both, in addition to other KUs, is also fine), 1209 reject cert. 1210 o If none of the above, accept cert. 1212 4.1.3.3 PrivateKeyUsagePeriod 1214 PKIX recommends against the use of this extension. The 1215 PrivateKeyUsageExtension is intended to be used when signatures will 1216 need to be verified long past the time when signatures using the 1217 private keypair may be generated. Since IKE SAs are short-lived 1218 relative to the intended use of this extension in addition to the 1219 fact that each signature is validated only a single time, the 1220 usefulness of this extension in the context of IKE is unclear. 1221 Therefore, Certification Authority implementations MUST NOT generate 1222 certificates that contain the PrivateKeyUsagePeriod extension. If an 1223 IKE implementation receives a certificate with this set, it SHOULD 1224 ignore it. 1226 4.1.3.4 CertificatePolicies 1228 Many IKE implementations do not currently provide support for the 1229 CertificatePolicies extension. Therefore, Certification Authority 1230 implementations that generate certificates which contain this 1231 extension SHOULD NOT mark the extension as critical. 1233 4.1.3.5 PolicyMappings 1235 Many IKE implementations do not support the PolicyMappings extension. 1236 Therefore, implementations that generate certificates which contain 1237 this extension SHOULD NOT mark the extension as critical. 1239 4.1.3.6 SubjectAltName 1241 Deployments that intend to use an ID of either FQDN, USER_FQDN, 1242 IPV4_ADDR or IPV6_ADDR MUST issue certificates with the corresponding 1243 SubjectAltName fields populated with the same data. Implementations 1244 SHOULD generate only the following GeneralName choices in the 1245 SubjectAltName extension, as these choices map to legal 1246 IKEv1/ISAKMP/IKEv2 Identification Payload types: rfc822Name, dNSName, 1247 or iPAddress. Although it is possible to specify any GeneralName 1248 choice in the Identification Payload by using the ID_DER_ASN1_GN ID 1249 type, implementations SHOULD NOT assume support for such 1250 functionality, and SHOULD NOT generate certificates that do so. 1252 4.1.3.6.1 dNSName 1254 This field MUST contain a fully qualified domain name. If the IKE ID 1255 type is FQDN then the dNSName field MUST match its contents. 1256 Implementations MUST NOT generate names that contain wildcards. 1257 Implementations MAY treat certificates that contain wildcards in this 1258 field as syntactically invalid. 1260 Although this field is in the form of an FQDN, IKE implementations 1261 SHOULD NOT assume that this field contains an FQDN that will resolve 1262 via the DNS, unless this is known by way of some out-of-band 1263 mechanism. Such a mechanism is out of the scope of this document. 1264 Implementations SHOULD NOT treat the failure to resolve as an error. 1266 4.1.3.6.2 iPAddress 1268 If the IKE ID type is IPV4_ADDR or IPV6_ADDR then the iPAddress field 1269 MUST match its contents. Note that although PKIX permits CIDR [13] 1270 notation in the "Name Constraints" extension, PKIX explicitly 1271 prohibits using CIDR notation for conveying identity information. In 1272 other words, the CIDR notation MUST NOT be used in the SubjectAltName 1273 extension. 1275 4.1.3.6.3 rfc822Name 1277 If the IKE ID type is USER_FQDN then the rfc822Name field MUST match 1278 its contents. Although this field is in the form of an Internet mail 1279 address, IKE implementations SHOULD NOT assume that this field 1280 contains a valid email address, unless this is known by way of some 1281 out-of-band mechanism. Such a mechanism is out of the scope of this 1282 document. 1284 4.1.3.7 IssuerAltName 1286 Certification Authority implementations SHOULD NOT assume that other 1287 implementations support the IssuerAltName extension, and especially 1288 should not assume that information contained in this extension will 1289 be displayed to end users. 1291 4.1.3.8 SubjectDirectoryAttributes 1293 The SubjectDirectoryAttributes extension is intended to convey 1294 identification attributes of the subject. IKE implementations MAY 1295 ignore this extension when it is marked non-critical, as PKIX 1296 mandates. 1298 4.1.3.9 BasicConstraints 1300 PKIX mandates that CA certificates contain this extension and that it 1301 be marked critical. IKE implementations SHOULD reject CA 1302 certificates that do not contain this extension. For backwards 1303 compatibility, implementations may accept such certificates if 1304 explicitly configured to do so, but the default for this setting MUST 1305 be to reject such certificates. 1307 4.1.3.10 NameConstraints 1309 Many IKE implementations do not support the NameConstraints 1310 extension. Since PKIX mandates that this extension be marked 1311 critical when present, Certification Authority implementations which 1312 are interested in maximal interoperability for IKE SHOULD NOT 1313 generate certificates which contain this extension. 1315 4.1.3.11 PolicyConstraints 1317 Many IKE implementations do not support the PolicyConstraints 1318 extension. Since PKIX mandates that this extension be marked 1319 critical when present, Certification Authority implementations which 1320 are interested in maximal interoperability for IKE SHOULD NOT 1321 generate certificates which contain this extension. 1323 4.1.3.12 ExtendedKeyUsage 1325 The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in 1326 certificates for use with IKE. Note that there were three IPsec 1327 related object identifiers in EKU that were assigned in 1999. The 1328 semantics of these values were never clearly defined. The use of 1329 these three EKU values in IKE/IPsec is obsolete and explicitly 1330 deprecated by this specification. CAs SHOULD NOT issue certificates 1331 for use in IKE with them. (For historical reference only, those 1332 values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and 1333 id-kp-ipsecUser.) 1335 PKIX [5] section 4.2.1.13 states, "If a CA includes extended key 1336 usages to satisfy such applications, but does not wish to restrict 1337 usages of the key, the CA can include the special keyPurposeID 1338 anyExtendedKeyUsage. If the anyExtendedKeyUsage keyPurposeID is 1339 present, the extension SHOULD NOT be critical." 1341 The CA SHOULD NOT mark the EKU extension in certificates for use with 1342 IKE and one or more other applications. If the CA administrator 1343 feels they must use an EKU for some other application, then such 1344 certificates MUST contain the keyPurposeID anyExtendedKeyUsage as 1345 well as the keyPurposeID values associated with the other 1346 applications for which the certificate is intended to be used. 1347 Recall however, EKU extensions in certificates meant for use in IKE 1348 are NOT RECOMMENDED. 1350 A summary of the logic flow for peer certificate validation regarding 1351 the EKU extension follows: 1353 o If told (by configuration) to ignore ExtendedKeyUsage (EKU), 1354 accept cert regardless of the presence or absence of the 1355 extension. 1356 o If no EKU extension, accept cert. 1357 o If EKU present AND anyExtendedKeyUsage is included, accept cert. 1358 o Otherwise, reject cert. 1360 4.1.3.13 CRLDistributionPoints 1362 Because this document deprecates the sending of CRLs in-band, the use 1363 of CRLDistributionPoints (CDP) becomes very important if CRLs are 1364 used for revocation checking (as opposed to say Online Certificate 1365 Status Protocol - OCSP [14]). The IPsec peer either needs to have a 1366 URL for a CRL written into its local configuration, or it needs to 1367 learn it from CDP. Therefore, Certification Authority 1368 implementations SHOULD issue certificates with a populated CDP. 1370 Failure to validate the 1371 CRLDistributionPoints/IssuingDistributionPoint pair can result in CRL 1372 substitution where an entity knowingly substitutes a known good CRL 1373 from a different distribution point for the CRL which is supposed to 1374 be used which would show the entity as revoked. IKE implementations 1375 MUST support validating that the contents of CRLDistributionPoints 1376 match those of the IssuingDistributionPoint to prevent CRL 1377 substitution when the issuing CA is using them. At least one CA is 1378 known to default to this type of CRL use. See Section 4.2.2.5 for 1379 more information. 1381 CDPs SHOULD be "resolvable". Several non-compliant Certification 1382 Authority implementations are well known for including unresolvable 1383 CDPs like http://localhost/path_to_CRL and http:///path_to_CRL which 1384 are equivalent to failing to include the CDP extension in the 1385 certificate. 1387 See PKIX docs for CRLDistributionPoints intellectual property rights 1388 (IPR) information. Note that both the CRLDistributionPoints and 1389 IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED 1390 by PKIX, so there is no requirement to license any IPR. 1392 4.1.3.14 InhibitAnyPolicy 1394 Many IKE implementations do not support the InhibitAnyPolicy 1395 extension. Since PKIX mandates that this extension be marked 1396 critical when present, Certification Authority implementations which 1397 are interested in maximal interoperability for IKE SHOULD NOT 1398 generate certificates which contain this extension. 1400 4.1.3.15 FreshestCRL 1402 IKE implementations MUST NOT assume that the FreshestCRL extension 1403 will exist in peer certificates. Note that most IKE implementations 1404 do not support delta CRLs. 1406 4.1.3.16 AuthorityInfoAccess 1408 PKIX defines the AuthorityInfoAccess extension, which is used to 1409 indicate "how to access CA information and services for the issuer of 1410 the certificate in which the extension appears." Because this 1411 document deprecates the sending of CRLs in band, the use of 1412 AuthorityInfoAccess (AIA) becomes very important if OCSP [14] is to 1413 be used for revocation checking (as opposed to CRLs). The IPsec peer 1414 either needs to have a URI for the OCSP query written into its local 1415 configuration, or it needs to learn it from AIA. Therefore, 1416 implementations SHOULD support this extension, especially if OCSP 1417 will be used. 1419 4.1.3.17 SubjectInfoAccess 1421 PKIX defines the SubjectInfoAccess private certificate extension, 1422 which is used to indicate "how to access information and services for 1423 the subject of the certificate in which the extension appears." This 1424 extension has no known use in the context of IPsec. Conformant IKE 1425 implementations SHOULD ignore this extension when present. 1427 4.2 X.509 Certificate Revocation Lists 1429 When validating certificates, IKE implementations MUST make use of 1430 certificate revocation information, and SHOULD support such 1431 revocation information in the form of CRLs, unless non-CRL revocation 1432 information is known to be the only method for transmitting this 1433 information. Deployments that intend to use CRLs for revocation 1434 SHOULD populate the CRLDistributionPoints extension. Therefore 1435 Certification Authority implementations MUST support issuing 1436 certificates with this field populated according to administrator's 1437 needs. IKE implementations MAY provide a configuration option to 1438 disable use of certain types of revocation information, but that 1439 option MUST be off by default. Such an option is often valuable in 1440 lab testing environments. 1442 4.2.1 Multiple Sources of Certificate Revocation Information 1444 IKE implementations which support multiple sources of obtaining 1445 certificate revocation information MUST act conservatively when the 1446 information provided by these sources is inconsistent: when a 1447 certificate is reported as revoked by one trusted source, the 1448 certificate MUST be considered revoked. 1450 4.2.2 X.509 Certificate Revocation List Extensions 1452 4.2.2.1 AuthorityKeyIdentifier 1454 Certification Authority implementations SHOULD NOT assume that IKE 1455 implementations support the AuthorityKeyIdentifier extension, and 1456 thus SHOULD NOT generate certificate hierarchies which are overly 1457 complex to process in the absence of this extension, such as those 1458 that require possibly verifying a signature against a large number of 1459 similarly named CA certificates in order to find the CA certificate 1460 which contains the key that was used to generate the signature. 1462 4.2.2.2 IssuerAltName 1464 Certification Authority implementations SHOULD NOT assume that IKE 1465 implementations support the IssuerAltName extension, and especially 1466 should not assume that information contained in this extension will 1467 be displayed to end users. 1469 4.2.2.3 CRLNumber 1471 As stated in PKIX, all issuers conforming to PKIX MUST include this 1472 extension in all CRLs. 1474 4.2.2.4 DeltaCRLIndicator 1476 4.2.2.4.1 If Delta CRLs Are Unsupported 1478 IKE implementations that do not support delta CRLs MUST reject CRLs 1479 which contain the DeltaCRLIndicator (which MUST be marked critical 1480 according to PKIX) and MUST make use of a base CRL if it is 1481 available. Such implementations MUST ensure that a delta CRL does 1482 not "overwrite" a base CRL, for instance in the keying material 1483 database. 1485 4.2.2.4.2 Delta CRL Recommendations 1487 Since some IKE implementations that do not support delta CRLs may 1488 behave incorrectly or insecurely when presented with delta CRLs, 1489 administrators and deployers should consider whether issuing delta 1490 CRLs increases security before issuing such CRLs. And, if all the 1491 elements in the VPN and PKI systems do not adequately support Delta 1492 CRLs, then their use should be questioned. 1494 The authors are aware of several implementations which behave in an 1495 incorrect or insecure manner when presented with delta CRLs. See 1496 Appendix B for a description of the issue. Therefore, this 1497 specification RECOMMENDS NOT issuing delta CRLs at this time. On the 1498 other hand, failure to issue delta CRLs exposes a larger window of 1499 vulnerability. See the Security Considerations section of PKIX [5] 1500 for additional discussion. Implementors as well as administrators 1501 are encouraged to consider these issues. 1503 4.2.2.5 IssuingDistributionPoint 1505 A CA that is using CRLDistributionPoints may do so to provide many 1506 "small" CRLs, each only valid for a particular set of certificates 1507 issued by that CA. To associate a CRL with a certificate, the CA 1508 places the CRLDistributionPoints extension in the certificate, and 1509 places the IssuingDistributionPoint in the CRL. The 1510 distributionPointName field in the CRLDistributionPoints extension 1511 MUST be identical to the distributionPoint field in the 1512 IssuingDistributionPoint extension. At least one CA is known to 1513 default to this type of CRL use. See Section 4.1.3.13 for more 1514 information. 1516 4.2.2.6 FreshestCRL 1518 Given the recommendations against Certification Authority 1519 implementations generating delta CRLs, this specification RECOMMENDS 1520 that implementations do not populate CRLs with the FreshestCRL 1521 extension, which is used to obtain delta CRLs. 1523 5. Configuration Data Exchange Conventions 1525 Below we present a common format for exchanging configuration data. 1526 Implementations MUST support these formats, MUST support receiving 1527 arbitrary whitespace at the beginning and end of any line, MUST 1528 support receiving arbitrary line lengths although they SHOULD 1529 generate lines less than 76 characters, and MUST support receiving 1530 the following three line-termination disciplines: LF (US-ASCII 10), 1531 CR (US-ASCII 13), and CRLF. 1533 5.1 Certificates 1535 Certificates MUST be Base64 encoded and appear between the following 1536 delimiters: 1538 -----BEGIN CERTIFICATE----- 1539 -----END CERTIFICATE----- 1541 5.2 CRLs and ARLs 1543 CRLs and ARLs MUST be Base64 encoded and appear between the following 1544 delimiters: 1546 -----BEGIN CRL----- 1547 -----END CRL----- 1549 5.3 Public Keys 1551 IKE implementations MUST support two forms of public keys: 1552 certificates and so-called "raw" keys. Certificates should be 1553 transferred in the same form as above. A raw key is only the 1554 SubjectPublicKeyInfo portion of the certificate, and MUST be Base64 1555 encoded and appear between the following delimiters: 1557 -----BEGIN PUBLIC KEY----- 1558 -----END PUBLIC KEY----- 1560 5.4 PKCS#10 Certificate Signing Requests 1562 A PKCS#10 [9] Certificate Signing Request MUST be Base64 encoded and 1563 appear between the following delimiters: 1565 -----BEGIN CERTIFICATE REQUEST----- 1566 -----END CERTIFICATE REQUEST----- 1568 6. Security Considerations 1570 6.1 Certificate Request Payload 1572 The Contents of CERTREQ are not encrypted in IKE. In some 1573 environments this may leak private information. Administrators in 1574 some environments may wish to use the empty Certification Authority 1575 option to prevent such information from leaking, at the cost of 1576 performance. 1578 6.2 IKEv1 Main Mode 1580 Certificates may be included in any message, and therefore 1581 implementations may wish to respond with CERTs in a message that 1582 offers privacy protection, in Main Mode messages 5 and 6. 1583 Implementations may not wish to respond with CERTs in the second 1584 message, thereby violating the identity protection feature of Main 1585 Mode in IKEv1. 1587 7. Intellectual Property Rights 1589 No new intellectual property rights are introduced by this document. 1591 8. IANA Considerations 1593 There are no known numbers which IANA will need to manage. 1595 9. References 1597 9.1 Normative References 1599 [1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1600 RFC 2409, November 1998. 1602 [2] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 1603 Association and Key Management Protocol (ISAKMP)", RFC 2408, 1604 November 1998. 1606 [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1607 draft-ietf-ipsec-ikev2-15 (work in progress), August 2004. 1609 [4] Kent, S. and R. Atkinson, "Security Architecture for the 1610 Internet Protocol", RFC 2401, November 1998. 1612 [5] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 1613 Public Key Infrastructure Certificate and Certificate Revocation 1614 List (CRL) Profile", RFC 3280, April 2002. 1616 [6] Piper, D., "The Internet IP Security Domain of Interpretation 1617 for ISAKMP", RFC 2407, November 1998. 1619 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1620 Levels", BCP 14, RFC 2119, March 1997. 1622 [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 1624 [9] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1625 1.5", RFC 2314, March 1998. 1627 9.2 Informative References 1629 [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1630 Specification", RFC 1883, December 1995. 1632 [11] Eastlake, D., "Domain Name System Security Extensions", RFC 1633 2535, March 1999. 1635 [12] Lynn, C., "X.509 Extensions for IP Addresses and AS 1636 Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in 1637 progress), September 2003. 1639 [13] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless 1640 Inter-Domain Routing (CIDR): an Address Assignment and 1641 Aggregation Strategy", RFC 1519, September 1993. 1643 [14] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, 1644 "X.509 Internet Public Key Infrastructure Online Certificate 1645 Status Protocol - OCSP", RFC 2560, June 1999. 1647 [15] Arsenault, A. and S. Turner, "Internet X.509 Public Key 1648 Infrastructure: Roadmap", draft-ietf-pkix-roadmap-09 (work in 1649 progress), July 2002. 1651 Author's Address 1653 Brian Korver 1654 Xythos Software, Inc. 1655 One Bush Street, Suite 600 1656 San Francisco, CA 94104 1657 US 1659 Phone: +1 415 248 3800 1660 EMail: briank@xythos.com 1662 Appendix A. Change History 1664 September 2004 (-03) 1666 * Minor editorial changes in abstract and introduction clarifing 1667 when something is from IPsec, IKE, etc 1668 * Minor editorial changes throughout 1669 * Fixed "Certification Authority" instead of "Certificate 1670 Authority" 1671 * Cleaned up initiator/responder when really referred to 1672 sender/recipient 1673 * Fixed inconsistancy in text by making sure that all text on the 1674 topic of sending CERTREQs follow Gregory Lebovitz's proposal 1675 for CERT payloads: "should deal with all the CRL, Intermediat 1676 Certs, Trust Anchors, etc OOB of IKE; MUST be able to send and 1677 receive EE cert payload; only real exception is Intermediate 1678 Cets which MAY be sent and SHOULD be able to be receivable (but 1679 in reality there are very few hierarchies in operation, so 1680 really it's a corner case); SHOULD NOT send the other stuff 1681 (CRL, Trust Anchors, etc) in cert payloads in IKE; SHOULD be 1682 able to accept the other stuff if by chance it gets sent, 1683 though we hope they don't get sent" 1684 * 3.1 - removed text suggesting that it would be reasonable to 1685 terminate IKEv2 processing if the initiator were to receive a 1686 responder-generated IDr 1687 * 3.1.1 - noted that certificates may contain multiple IP 1688 addresses 1689 * 3.1.9 - removed (temporarily?) confusing text stating that 1690 overlapping policies was prohibited, text which was 1691 inconsistent with text right above it 1692 * 3.2.7.2 - SHOULD changed to MUST terminate if peer's 1693 certificate chain violates local policy 1694 * 3.3 - removed text implying that pausing in the middle of an 1695 IKE exchange in order to obtain revocation status information 1696 via http or OCSP would reduce latency in IKE 1697 * 4.2 - allow deployments that don't wish to populate CDP (for 1698 instance if a source of revocation information is configured 1699 via some other means) to skip populating CDP, making consistent 1700 with 4.1.3.13 and the issues IPR spelled out in PKIX 1701 * Somehow a CRL out-of-band configuration format had been 1702 omitted. 1703 * #555: Kent-1.0 Introduction - document now references IKEv2 1704 * #559: Kent-Profile Document 3.1.0 - use sender/recipient 1705 instead of agent 1706 * #564: Kent-Profile Document 3.1.1 - specified that support for 1707 ID_IPV4_ADDR and/or ID_IPV6_ADDR are contingent on device 1708 support for IPv4 and/or IPv6 1709 * #568: Kent-Profile document 3.1.4 - specified that there wasn't 1710 a standard and besides no one has implemented it 1711 * #571: Kent-Profile document 3.1.8 - tried to be even more 1712 clearer than was asked for by spelling things out in detail 1713 * #572: Kent-Profile document 3.1.8 Formerly issue #18 - now 1714 specifies that it's only a local matter if that information is 1715 not coordinated with other administrators 1716 * #573: Kent-Profile document 3.2.3/Myers - revocation 1717 information no longer exchanged in-band, plus Mike Myers has 1718 submitted an OCSP w/IKE draft, which is references by this 1719 document. 1720 * #578 Kent-Profile document 4.0.0 - went through entire PKIX 1721 profile section and prefaced "implementation" with "IKE" or 1722 "Certification Authority" wherever it was sure to be one or the 1723 other 1724 * #581: Kent-Profile document 4.1.3.9 - replaced description with 1725 text from RFC 2459 1726 * #584: Maillist-Lebovitz PKI Life Cycle-Revocation - fixed 1727 * #586: Maillist-Allison Empty CertReq - there is now lots of 1728 text dealing with when empty certreqs are permitted 1729 * 3.2.7.1 - CERTREQ only mandatory if in-band exchange of keymat 1730 is desired (28 Jul 2004 pki4ipsec email from 1731 jknowles@SonicWALL.com) 1732 * 3.3.6 - clarified that "non-compliant" means not sending a 1733 CERTREQ (28 Jul 2004 pki4ipsec email from 1734 jknowles@SonicWALL.com) 1735 * 3.2.7.1 - fixed contradition: mandatory to respond to CERTREQ 1736 UNLESS configured not to (28 Jul 2004 pki4ipsec email from 1737 jknowles@SonicWALL.com) 1738 * 3.2.9.2 and 3.2.9.3 - CERTREQ contains an issuer name only for 1739 IKEv2 (19 Sep 2004 email from Charlie Kaufman) 1740 * Answered 'Section 3.1.9 para 2: "The initiator MUST know by 1741 policy..." is a difficult to interpret requirement. It could 1742 mean that it must be possible to configure in policy which ID 1743 is to be sent. Did you mean "the initiator must decide...", 1744 where the decision might be wired into a particular 1745 implementation?' by changing it to be merely descriptive, and 1746 to refer to policy configuration (19 Sep 2004 email from 1747 Charlie Kaufman) 1748 * IPSEC -> IPsec (19 Sep 2004 email from Charlie Kaufman) 1749 * 3.1.1 para 1: "MUST be stored" changed to "MUST be encoded" (19 1750 Sep 2004 email from Charlie Kaufman) 1751 * 3.1.5 para 2 - made it clear that empty SubjectNames are 1752 permitted by PKIX in certificates, but this document doesn't 1753 permit them in ID (19 Sep 2004 email from Charlie Kaufman) 1754 * 3.2.7.1 - clarified by specifying that it's a trust anchor 1755 that's being chosen, not end-entity certificate (19 Sep 2004 1756 email from Charlie Kaufman) 1757 * 3.3.9.5 - fixed confusing last paragraph (19 Sep 2004 email 1758 from Charlie Kaufman) 1759 * 3.3.10.3 - made it more clear that this section is really 1760 talking about duplicate certificate payloads (19 Sep 2004 email 1761 from Charlie Kaufman) 1762 * 4.1.2.2 para 2 and 3 - moved to 3.1.x section where is belongs 1763 (19 Sep 2004 email from Charlie Kaufman) 1764 * 4.1.3.5 - the last sentence of 4.1.3.4 copied here (19 Sep 2004 1765 email from Charlie Kaufman) 1766 * 4.2.2.4.2 - SHOULD -> should (19 Sep 2004 email from Charlie 1767 Kaufman) 1768 * 3.2.5 and 3.3.4 - added description of URL scheme support (16 1769 Aug 2004 pki4ipsec email from Tero Kivinen) 1770 * Removed 6.1 and 6.3 because they were either incorrect or 1771 didn't add any new security considerations above and beyond the 1772 IKE documents. 1773 August 2004 (-02) (Edited by Gregory Lebovitz, with XML formatting 1774 and cross-referencing by Paul Knight) 1776 * 3.1.1 the text between the **s was added to paragraph, per the 1777 question that arose in IETF60 WG session: Implementations MUST 1778 be capable of verifying that the address contained in the ID is 1779 the same as the peer source address **contained in the outer 1780 most IP header**. 1781 * 3.2.7 - added HTTP_CERT_LOOKUP_SUPPORTED to this section and 1782 described its use - #38 1783 * 3.3 - changed back sending of intermediate CA certificates from 1784 SHOULD NOT to MAY (for backward compatibility). Added text to 1785 explain further why we want to stay away from actually doing it 1786 though. 1787 * 3.3.8 - changed text per Knowles/Korver 2004.07.28. 1788 * 3.3.9.5 - Change discard of Irrelevant Certificates from may to 1789 SHOULD - #23(Kent 2004.04.26) 1790 * 4.1.3.2 KU - re-worked to reflect discussion on list and in 1791 IETF60 - #36 1792 * 4.1.3.12 EKU - re-worked to reflect discussion on list and in 1793 IETF60 - #36 1795 * [IKEv2] update the reference to the -14 draft of May 29, 2004 1797 July 2004 (-01) (Edited by Gregory Lebovitz) 1799 * Changed ISAKMP references in Abstract and Intro to IKE. 1800 * Editorial changes to make the text conform with the summary 1801 table in 3.1, especially in the text following the table in 1802 3.1. Particular note should be paid to changes in section 1803 3.5.1. 1804 * Sect 3.1.1 - editorial changes to aid in clarification. Added 1805 text on when deployers might consider using IP addr, but 1806 strongly encouraged not to. 1807 * Sect 3.1.8 removed IP address from list of practically used ID 1808 types. 1809 * 3.1.9 overhauled (per Kivinen, July 18) 1810 * 3.2 - added IKEv2's Hash and URL of x.509 to list of those 1811 profiled and gave it its own section, now 3.2.5 1812 * added note in CRL/ARL section about revocation occurring OOB of 1813 IKE 1814 * deleted ARL as its own section and collapsed it into Revocation 1815 Lists (CRL and ARL) for consciseness. Renumbered accordingly. 1816 * Sect 3.2.7.2 - Changed from MUST not send empty certreqs to 1817 SHOULD send CERTREQs which contain CA fields with direction on 1818 how, but MAY send empty CERTREQs in certain case. Use case 1819 added, and specifics of both initiator and responder behavior 1820 listed. 1821 * APPENDIX C added to fill out the explanation (mostly discussion 1822 from list). 1823 * 3.3 - clarified that sending CRLs and chaining certs is 1824 deprecated. 1825 * added IKEv2's Hash and URL of x.509 to list of those profiled 1826 and gave it its own section. Condensed ARL into CRL and 1827 renumbered accordingly. 1828 * duplicate section was removed, renumbered accordingly 1829 * 3.3.10.2 - title changed. sending chaining becomes SHOULD NOT. 1830 * 4.1.2 added text to explicity call out support for CN, C, O, OU 1831 * collapsed 4.1.2.3 into 4.1.2.2 and renumbered accordingly. 1832 * Collapsed 4.1.3.2 into 4.1.3.1 and renumbered accordingly 1833 * Edited 4.1.3.2 Key Usage and 4.1.3.12 ExtKey Usage according to 1834 Hoffman, July18 1835 * 4.1.3.3 if receive cert w/ PKUP, ignore it. 1836 * 4.1.3.13 - CDP changed text to represent SHOULD issue, and how 1837 important CDP becomes when we do not send CRLs in-band. Added 1838 SHOULD for CDPs actually being resolvable (reilly email). 1839 * Reordered 6.4 for better clarity. 1841 * Added Rescorla to Acknowledgements section, as he is no longer 1842 listed as an editor, since -00. 1844 May 2004 (renamed draft-ietf-pki4ipsec-ikecert-profile-00.txt) 1845 (edited by Brian Korver) 1847 * Made it clearer that the format of the ID_IPV4_ADDR payload 1848 comes from RFC791 and is nothing new. (Tero Kivinen Feb 29) 1849 * Permit implementations to skip verifying that the peer source 1850 address matches the contents of ID_IPV{4,6}_ADDR. (Tero 1851 Kivinen Feb 29, Gregory Lebovitz Feb 29) 1852 * Removed paragraph suggesting that implementations favor 1853 unauthenticated peer source addresses over an unauthenticated 1854 ID for initial policy lookup. (Tero Kivinen Feb 29, Gregory 1855 Lebovitz Feb 29) 1856 * Removed some text implying RSA encryption mode was in scope. 1857 (Tero Kivinen Feb 29) 1858 * Relaxed deprecation of PKCS#7 CERT payloads. (Tero Kivinen Feb 1859 29) 1860 * Made it clearer that out-of-scope local heuristics should be 1861 used for picking an EE cert to use when generating CERTREQ, not 1862 when receiving CERTREQ. (Tero Kivinen Feb 29) 1863 * Made it clearer that CERT processing can be skipped when the 1864 contents of a CERT are already known. (Tero Kivinen Feb 29) 1865 * Implementations SHOULD generate BASE64 lines less than 76 1866 characters. (Tero Kivinen Feb 29) 1867 * Added "Except where specifically stated in this document, 1868 implementations MUST conform to the requirements of PKIX" 1869 (Steve Hanna Oct 7, 2003) 1870 * RECOMMENDS against populating the ID payload with IP addresses 1871 due to interoperability issues such as problem with NAT 1872 traversal. (Gregory Lebovitz May 14) 1873 * Changed "as revoked by one source" to "as revoked by one 1874 trusted source". (Michael Myers, May 15) 1875 * Specifying Certificate Authorities section needed to be 1876 regularized with Gregory Lebovitz's CERT proposal from -04. 1877 (Tylor Allison, May 15) 1878 * Added text specifying how recipients SHOULD NOT be expected to 1879 iterate over multiple end-entity certs. (Tylor Allison, May 1880 15) 1881 * Modified text to refer to IKEv2 as well as IKEv1/ISAKMP where 1882 relevant. 1883 * IKEv2: Explained that IDr sent by responder doesn't have to 1884 match the [IDr] sent initiator in second exchange. 1885 * IKEv2: Noted that "The identity ... does not necessarily have 1886 to match anything in the CERT payload" (S3.5) is not 1887 contradicted by SHOULD in this document. 1888 * IKEv2: Noted that ID_USER_FQDN renamed to ID_RFC822_ADDR, and 1889 ID_USER_FQDN would be used exclusively in this document. 1890 * IKEv2: Declared that 3 new CERTREQ and CERT types are not 1891 profiled in this document (well, at least not yet, pending WG 1892 discussion of what to do -- note that they are only SHOULDs in 1893 IKEv2). 1894 * IKEv2: Noted that CERTREQ payload changed from DN to SHA-1 of 1895 SubjectPublicKeyInfo. 1896 * IKEv2: Noted new requirement that specifies that the first 1897 certificate sent MUST be the EE cert (section 3.6). 1899 February 2004 (-04) 1901 * Minor editorial changes to clean up language 1902 * Deprecate in-band exchange of CRLs 1903 * Incorporated Gregory Lebovitz's proposal for CERT payloads: 1904 "should deal with all the CRL, Intermediat Certs, Trust 1905 Anchors, etc OOB of IKE; MUST be able to send and receive EE 1906 cert payload; only real exception is Intermediate Cets which 1907 MAY be sent and SHOULD be able to be receivable (but in reality 1908 there are very few hierarchies in operation, so really it's a 1909 corner case); SHOULD NOT send the other stuff (CRL, Trust 1910 Anchors, etc) in cert payloads in IKE; SHOULD be able to accept 1911 the other stuff if by chance it gets sent, though we hope they 1912 don't get sent" 1913 * Incorporated comments contained in Oct 7, 2003 email from 1914 steve.hanna@sun.com to ipsec@lists.tislabs.com 1915 * Moved text from "Profile of ISAKMP" Background section to each 1916 payload section (removing duplication of these sections) 1917 * Removed "Certificate-Related Playloads in ISAKMP" section since 1918 it was not specific to IKE. 1919 * Incorporated Gregory Lebovitz's table in the "Identification 1920 Payload" section 1921 * Moved text from "binding identity to policy" sections to each 1922 payload section 1923 * Moved text from "IKE" section into now-combined "IKE/ISAKMP" 1924 section 1925 * ID_USER_FQDN and ID_FQDN promoted to MUST from MAY 1926 * Promoted sending ID_DER_ASN1_DN to MAY from SHOULD NOT, and 1927 receiving from MUST from MAY 1928 * Demoted ID_DER_ASN1_GN to MUST NOT 1929 * Demoted populating SubjectName in place of populating the 1930 dNSName from SHOULD NOT to MUST NOT and removed the text 1931 regarding domainComponent 1933 * Revocation information checking MAY now be disabled, although 1934 not by default 1935 * Aggressive Mode removed from this profile 1937 June 2003 (-03) 1939 * Minor editorial changes to clean up language 1940 * Minor additional clarifying text 1941 * Removed hyphenation 1942 * Added requirement that implementations support configuration 1943 data exchange having arbitrary line lengths 1945 February 2003 (-02) 1947 * Word choice: move from use of "root" to "trust anchor", in 1948 accordance with PKIX 1949 * SBGP note and reference for placing address subnet and range 1950 information into certificates 1951 * Clarification of text regarding placing names of hosts into the 1952 Name commonName attribute of SubjectName 1953 * Added table to clarify text regarding processing of the 1954 certificate extension criticality bit 1955 * Added text underscoring processing requirements for 1956 CRLDistributionPoints and IssuingDistributionPoint 1958 October 2002, Reorganization (-01) 1960 June 2002, Initial Draft (-00) 1962 Appendix B. The Possible Dangers of Delta CRLs 1964 The problem is that the CRL processing algorithm is sometimes written 1965 incorrectly with the assumption that all CRLs are base CRLs and it is 1966 assumed that CRLs will pass content validity tests. Specifically, 1967 such implementations fail to check the certificate against all 1968 possible CRLs: if the first CRL that is obtained from the keying 1969 material database fails to decode, no further revocation checks are 1970 performed for the relevant certificate. This problem is compounded 1971 by the fact that implementations which do not understand delta CRLs 1972 may fail to decode such CRLs due to the critical DeltaCRLIndicator 1973 extension. The algorithm that is implemented in this case is 1974 approximately: 1976 o fetch newest CRL 1977 o check validity of CRL signature 1978 o if CRL signature is valid then 1979 o if CRL does not contain unrecognized critical extensions 1980 o and certificate is on CRL then 1981 o set certificate status to revoked 1983 The authors note that a number of PKI toolkits do not even provide a 1984 method for obtaining anything but the newest CRL, which in the 1985 presence of delta CRLs may in fact be a delta CRL, not a base CRL. 1987 Note that the above algorithm is dangerous in many ways. See PKIX 1988 [5] for the correct algorithm. 1990 Appendix C. More on Empty CERTREQs 1992 Sending empty certificate requests is commonly used in 1993 implementations, and in the IPsec interop meetings, vendors have 1994 generally agreed that it means that send all/any end-entity 1995 certificates you have (if multiple end-entity certificates are sent, 1996 they must have same public key, as otherwise the other end does not 1997 know which key was used). For 99% of cases the client have exactly 1998 one certificate and public key, so it really doesn't matter, but the 1999 server might have multiple, thus it simply needs to say to the 2000 client, use any certificate you have. If we are talking about 2001 corporate vpns etc, even if the client have multiple certificates or 2002 keys, all of them would be usable when authenticating to the server, 2003 so client can simply pick one. 2005 If there is some real difference on which cert to use (like ones 2006 giving different permissions), then the client must be configured 2007 anyways, or it might even ask the user which one to use (the user is 2008 the only one who knows whether he needs admin privileges, thus needs 2009 to use admin cert, or is the normal email privileges ok, thus using 2010 email only cert). 2012 99% of the cases the client have exactly one certificate, so it will 2013 send it. In 90% of the rest of the cases, any of the certificates is 2014 ok, as they are simply different certificates from same CA, or 2015 different CAs for the same corporate VPN, thus any of them is ok. 2017 Sending empty certificate requests has been agreed there to mean 2018 "give me your cert; any cert". 2020 Justification: 2022 o Responder first does all it can to send a certreq with a CA, check 2023 for IP match in SPD, have a default set of CAs to use in ambiguous 2024 cases, etc. 2025 o sending empty certreq's is fairly common in implementations today, 2026 and is generally accepted to mean "send me a cert, any cert that 2027 works for you" 2028 o saves responder sending potentially 100's of certs, the 2029 fragmentation problems that follow, etc. 2030 o in +90% of use cases, Initiators have exactly 1 cert 2031 o in +90% of the remaining use cases, the multiple certs it has are 2032 issued by the same CA 2033 o in the remaining use case(s) -- if not all the others above -- the 2034 Initiator will be configured explicitly with which cert to send, 2035 so responding to an empty certreq is easy. 2037 The following example shows why initiators need to have sufficient 2038 policy definition to know which certificate to use for a given 2039 connection it initiates. 2041 EXAMPLE: Your client (initiator) is configured with VPN policies for 2042 gateways A and B (representing perhaps corporate partners). 2044 The policies for the two gateways look something like: 2046 Acme Company policy (gateway A) 2047 Engineering can access 10.1.1.0 2048 Trusted CA: CA-A, Trusted Users: OU=Engineering 2049 Partners can access 20.1.1.0 2050 Trusted CA: CA-B, Trusted Users: OU=AcmePartners 2052 Bizco Company policy (gateway B) 2053 sales can access 30.1.1.0 2054 Trusted CA: CA-C, Trusted Users: OU=Sales 2055 Partners can access 40.1.1.0 2056 Trusted CA: CA-B, Trusted Users: OU=BizcoPartners 2058 You are an employee of Acme and you are issued the following 2059 certificates: 2061 o From CA-A: CN=JoeUser,OU=Engineering 2062 o From CA-B: CN=JoePartner,OU=BizcoPartners 2064 The client MUST be configured locally to know which CA to use when 2065 connecting to either gateway. If your client is not configured to 2066 know the local credential to use for the remote gateway, this 2067 scenario will not work either. If you attempt to connect to Bizco, 2068 everything will work... as you are presented with responding with a 2069 certificate signed by CA-B or CA-C... as you only have a certificate 2070 from CA-B you are OK. If you attempt to connect to Acme, you have an 2071 issue because you are presented with an ambiguous policy selection. 2072 As the initiator, you will be presented with certificate requests 2073 from both CA A and CA B. You have certificates issued by both CAs, 2074 but only one of the certificates will be usable. How does the client 2075 know which certificate it should present? It must have sufficiently 2076 clear local policy specifying which one credential to present for the 2077 connection it initiates. 2079 Appendix D. Acknowledgements 2081 The authors would like to acknowledge the expired draft-ietf-ipsec- 2082 pki-req-05.txt for providing valuable materials for this document. 2084 The authors would like to especially thank Eric Rescorla, one of its 2085 original authors, in addition to Greg Carter, Steve Hanna, Russ 2086 Housley, Charlie Kaufman, Tero Kivinen, and Gregory Lebovitz for 2087 their valuable comments, some of which have been incorporated 2088 verbatim into this document. Paul Knight performed the arduous tasks 2089 of coverting the text to XML format. 2091 Intellectual Property Statement 2093 The IETF takes no position regarding the validity or scope of any 2094 Intellectual Property Rights or other rights that might be claimed to 2095 pertain to the implementation or use of the technology described in 2096 this document or the extent to which any license under such rights 2097 might or might not be available; nor does it represent that it has 2098 made any independent effort to identify any such rights. Information 2099 on the procedures with respect to rights in RFC documents can be 2100 found in BCP 78 and BCP 79. 2102 Copies of IPR disclosures made to the IETF Secretariat and any 2103 assurances of licenses to be made available, or the result of an 2104 attempt made to obtain a general license or permission for the use of 2105 such proprietary rights by implementers or users of this 2106 specification can be obtained from the IETF on-line IPR repository at 2107 http://www.ietf.org/ipr. 2109 The IETF invites any interested party to bring to its attention any 2110 copyrights, patents or patent applications, or other proprietary 2111 rights that may cover technology that may be required to implement 2112 this standard. Please address the information to the IETF at 2113 ietf-ipr@ietf.org. 2115 Disclaimer of Validity 2117 This document and the information contained herein are provided on an 2118 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2119 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2120 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2121 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2122 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2123 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2125 Copyright Statement 2127 Copyright (C) The Internet Society (2004). This document is subject 2128 to the rights, licenses and restrictions contained in BCP 78, and 2129 except as set forth therein, the authors retain all their rights. 2131 Acknowledgment 2133 Funding for the RFC Editor function is currently provided by the 2134 Internet Society.