idnits 2.17.00 (12 Aug 2021) /tmp/idnits20439/draft-ietf-pki4ipsec-ikecert-profile-01.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.5 on line 1579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1590. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1603. ** 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. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 8. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 971 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([SBGP], [2], [DNSSEC], [RFC791], [3], [4], [RFC2119], [PKCS-10], [RFC1883], [PKIX], [IPSEC], [DOI], [IKEv1], [CIDR], [IKEv2], [ISAKMP], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 42 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1132 has weird spacing: '...lements bit...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Sect 3.2.7.2 - Changed from MUST not send empty certreqs to SHOULD send CERTREQs which contain CA fields with direction on how, but MAY send empty CERTREQs in certain case. Use case added, and specifics of both initiator and responder behavior listed. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jan 2005) is 6334 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: '1' on line 279 -- Looks like a reference, but probably isn't: '2' on line 283 -- Looks like a reference, but probably isn't: '3' on line 288 -- Looks like a reference, but probably isn't: '4' on line 292 == Missing Reference: 'IDr' is mentioned on line 1719, but not defined == Unused Reference: 'ROADMAP' is defined on line 1543, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2407 (ref. 'DOI') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (ref. 'IKEv1') (Obsoleted by RFC 4306) == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2314 (ref. 'PKCS-10') (Obsoleted by RFC 2986) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 1883 (Obsoleted by RFC 2460) == Outdated reference: A later version (-09) exists of draft-ietf-pkix-roadmap-08 == Outdated reference: draft-ietf-pkix-x509-ipaddr-as-extn has been published as RFC 3779 Summary: 22 errors (**), 0 flaws (~~), 11 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Profiling the use of PKI in IPsec Brian Korver 3 (pkiPKI4Ipsec) Xythos Software 4 Internet-Draft July 2004 5 Expires Jan 2005 7 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX 8 draft-ietf-pki4ipsec-ikecert-profile-01.txt 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. By submitting this Internet- 16 Draft, I certify that any applicable patent or other IPR claims of 17 which I am aware have been disclosed, and any of which I become 18 aware will be disclosed, in accordance with RFC 3668 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 IKE/IPsec and PKIX both provide frameworks that must be profiled for 35 use in a given application. This document provides a profile of 36 IKE/IPsec and PKIX that defines the requirements for using PKI 37 technology in the context of IKE/IPsec. The document complements 38 protocol specifications such as IKEv1 and IKEv2, which assume the 39 existence of public key certificates and related keying materials, but 40 which do not address PKI issues explicitly. This document addresses 41 those issues. 43 Table of Contents 45 1 Introduction 4 46 2 Terms and Definitions 5 47 3 Profile of IKEv1/ISAKMP and IKEv2 5 48 3.1 Identification Payload 5 49 3.1.1 ID_IPV4_ADDR and ID_IPV6_ADDR 7 50 3.1.2 ID_FQDN 8 51 3.1.3 ID_USER_FQDN 9 52 3.1.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_A... 9 53 3.1.5 ID_DER_ASN1_DN 9 54 3.1.6 ID_DER_ASN1_GN 10 55 3.1.7 ID_KEY_ID 10 56 3.1.8 Selecting an Identity from a Certificate 10 57 3.1.9 Transitively Binding Identity to Policy 10 58 3.2 Certificate Request Payload 11 59 3.2.1 Certificate Type 11 60 3.2.2 X.509 Certificate - Signature 11 61 3.2.3 Revocation Lists (CRL and ARL) 11 62 3.2.4 PKCS #7 wrapped X.509 certificate 12 63 3.2.5 IKEv2's Hash and URL of X.509 certificate 12 64 3.2.6 Presence or Absence of Certificate Request Payloads 12 65 3.2.7 Certificate Requests 12 66 3.2.7.1 Specifying Certificate Authorities 12 67 3.2.7.2 Empty Certificate Authority Field 13 68 3.2.8 Robustness 13 69 3.2.8.1 Unrecognized or Unsupported Certificate Types 13 70 3.2.8.2 Undecodable Certificate Authority Fields 13 71 3.2.8.3 Ordering of Certificate Request Payloads 13 72 3.2.9 Optimizations 13 73 3.2.9.1 Duplicate Certificate Request Payloads 13 74 3.2.9.2 Name Lowest 'Common' Certification Authorities 14 75 3.2.9.3 Example 14 76 3.3 Certificate Payload 14 77 3.3.1 Certificate Type 15 78 3.3.2 X.509 Certificate - Signature 15 79 3.3.3 Revocation Lists (CRL & ARL) 16 80 3.3.4 IKEv2's Hash and URL of X.509 certificate 16 81 3.3.5 PKCS #7 wrapped X.509 certificate 16 82 3.3.6 Certificate Payloads Not Mandatory 16 83 3.3.7 Response to Multiple Certificate Authority Proposals 16 84 3.3.8 Using Local Keying Materials 17 85 3.3.9 Robustness 17 86 3.3.9.1 Unrecognized or Unsupported Certificate Types 17 87 3.3.9.2 Undecodable Certificate Data Fields 17 88 3.3.9.3 Ordering of Certificate Payloads 17 89 3.3.9.4 Duplicate Certificate Payloads 17 90 3.3.9.5 Irrelevant Certificates 17 91 3.3.10 Optimizations 18 92 3.3.10.1 Duplicate Certificate Payloads 18 93 3.3.10.2 Send Only End Entity Certificates 18 94 3.3.10.3 Ignore Duplicate Certificate Payloads 18 95 3.3.11 Hash Payload 18 96 4 Profile of PKIX 19 97 4.1 X.509 Certificates 19 98 4.1.1 Versions 19 99 4.1.2 Subject Name 19 100 4.1.2.2 Specifying Hosts and FQDN Subject Name 19 101 4.1.2.3 EmailAddress 20 102 4.1.3 X.509 Certificate Extensions 20 103 4.1.3.1 AuthorityKeyIdentifier & SubjectKey ID 20 104 4.1.3.2 KeyUsage 21 105 4.1.3.3 PrivateKeyUsagePeriod 21 106 4.1.3.4 Certificate Policies 21 107 4.1.3.5 PolicyMappings 21 108 4.1.3.6 SubjectAltName 21 109 4.1.3.6.1 dNSName 22 110 4.1.3.6.2 iPAddress 22 111 4.1.3.6.3 rfc822Name 22 112 4.1.3.7 IssuerAltName 22 113 4.1.3.8 SubjectDirectoryAttributes 22 114 4.1.3.9 BasicConstraints 23 115 4.1.3.10 NameConstraints 23 116 4.1.3.11 PolicyConstraints 23 117 4.1.3.12 ExtendedKeyUsage 23 118 4.1.3.13 CRLDistributionPoints 23 119 4.1.3.14 InhibitAnyPolicy 24 120 4.1.3.15 FreshestCRL 24 121 4.1.3.16 AuthorityInfoAccess 24 122 4.1.3.17 SubjectInfoAccess 24 123 4.2 X.509 Certificate Revocation Lists 24 124 4.2.1 Multiple Sources of Certificate Revocation Information 25 125 4.2.2 X.509 Certificate Revocation List Extensions 25 126 4.2.2.1 AuthorityKeyIdentifier 25 127 4.2.2.2 IssuerAltName 25 128 4.2.2.3 CRLNumber 25 129 4.2.2.4 DeltaCRLIndicator 25 130 4.2.2.4.1 If Delta CRLs Are Unsupported 25 131 4.2.2.4.2 Delta CRL Recommendations 25 132 4.2.2.5 IssuingDistributionPoint 26 133 4.2.2.6 FreshestCRL 26 134 5 Configuration Data Exchange Conventions 26 135 5.1 Certificates 26 136 5.2 Public Keys 27 137 5.3 PKCS#10 Certificate Signing Requests 27 138 6 Security Considerations 27 139 6.1 Identification Payload 27 140 6.2 Certificate Request Payload 27 141 6.3 Certificate Payload 27 142 6.4 IKEv1 Main Mode 28 143 7 Intellectual Property Rights 28 144 8 IANA Considerations 28 145 9 Normative References 28 146 10 Informational References 29 147 11 Acknowledgements 29 148 12 Author's Addresses 29 149 Full Copyright Statement 150 Appendix A - Change History 151 Appendix B - Possible Dangers of Delta CRLs 152 Appendix C - More on Empty CERTREQs 154 1. Introduction 156 IKE [IKEv1] and ISAKMP [ISAKMP] and IKEv2 [IKEv2] provide a secure 157 key exchange mechanism for use with IPsec [IPSEC]. In many cases the 158 peers authenticate using digital certificates as specified in PKIX 159 [PKIX]. Unfortunately, the combination of these standards leads to an 160 underspecified set of requirements for the use of certificates in the 161 context of IPsec. 163 ISAKMP references PKIX but in many cases merely specifies the 164 contents of various messages without specifying their syntax or 165 semantics. Meanwhile, PKIX provides a large set of certificate 166 mechanisms which are generally applicable for Internet protocols, but 167 little specific guidance for IPsec. Given the numerous underspecified 168 choices, interoperability is hampered if all implementers do not make 169 similar choices, or at least fail to account for implementations 170 which have chosen differently. 172 This profile of the IKE and PKIX frameworks is intended to provide 173 an agreed-upon standard for using PKI technology in the context of 174 IPsec by profiling the PKIX framework for use with IKE and IPsec, 175 and by documenting the contents of the relevant IKE payloads and 176 further specifying their semantics. 178 In addition to providing a profile of IKE and PKIX, this document 179 attempts to incorporate lessons learned from recent experience with 180 both implementation and deployment, as well as the current state of 181 related protocols and technologies. 183 Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and 184 readers of this document are assumed to have read and understood both 185 documents. The requirements and security aspects of those documents 186 are fully relevant to this document as well. 188 This document is organized as follows. Section 2 defines special 189 terminology used in the rest of this document, Section 3 provides the 190 profile of IKEv1/ISAKMP and IKEv2, and Section 4 provides the profile 191 of PKIX. Section 5 covers conventions for the out-of-band exchange of 192 keying materials for configuration purposes. 194 This document is being discussed on the pki4ipsec@icsalabs.com 195 mailing list. 197 2. Terms and Definitions 198 Except for those terms which are defined immediately below, all terms 199 used in this document are defined in either the PKIX, ISAKMP, IKEv1, 200 IKEv2, or DOI [DOI] documents. 202 * Peer source address: The source address in packets from a peer. 203 This address may be different from any addresses asserted as the 204 "identity" of the peer. 205 * FQDN: Fully qualified domain name. 206 * ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both 207 are referred to as ID_USER_FQDN in this document. 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in RFC-2119 [RFC2119]. 213 3. Profile of IKEv1/ISAKMP and IKEv2 215 3.1. Identification Payload 217 The Identification (ID) Payload is used to indicate the identity that 218 the agent claims to be speaking for. The receiving agent can then use 219 the ID as a lookup key for policy and whatever certificate store or 220 directory that it has available. Our primary concern in this document 221 is to profile the ID payload so that it can be safely used to 222 generate or lookup policy. IKE mandates the use of the ID payload in 223 Phase 1. 225 The [DOI] defines the 11 types of Identification Data that can be 226 used and specifies the syntax for these types. These are discussed 227 below in detail. 229 The ID payload requirements in this document cover only the portion 230 of the explicit policy checks that deal with the Identification 231 Payload specifically. For instance, in the case where ID does not 232 contain an IP address, checks such as verifying that the peer source 233 address is permitted by the relevant policy are not addressed here as 234 they are out of the scope of this document. 236 Implementations SHOULD populate ID with identity information that is 237 contained within the end entity certificate (This SHOULD does not 238 contradict text in IKEv2 Section 3.5 that implies a looser binding 239 between these two). Populating ID with identity information from the 240 end entity certificate enables recipients to use ID as a lookup key 241 to find the peer end entity certificate. 243 Because implementations may use ID as a lookup key to determine which 244 policy to use, all implementations MUST be especially careful to 245 verify the truthfulness of the contents by verifying that they 246 correspond to some keying material demonstrably held by the peer. 247 Failure to do so may result in the use of an inappropriate or 248 performing this binding. 250 The following table summarizes the binding of the Identification 251 Payload to the contents of end-entity certificates and of identity 252 information to policy. Each ID type is covered more thoroughly in the 253 following sections. 255 ID type | Support | Correspond | Cert | SPD lookup 256 | for send | PKIX Attrib | matching | rules 257 ------------------------------------------------------------------- 258 | | | | 259 IP*_ADDR | MUST [1] | SubjAltName | MUST [2] | [3] & [4] 260 | | iPAddress | | 261 | | | | 262 FQDN | MUST [1] | SubjAltName | MUST [2] | [3] & [4] 263 | | dNSName | | 264 | | | | 265 USER_FQDN| MUST [1] | SubjAltName | MUST [2] | [3] & [4] 266 | | rfc822Name | | 267 | | | | 268 DN | MUST [1] | Entire | MUST [2] | MUST support lookup 269 | | Subject, | | on any combination 270 | | bitwise | | of C, CN, O, or OU 271 | | compare | | 272 | | | | 273 IP range | MUST NOT | n/a | n/a | n/a 274 | | | | 275 | | | | 276 KEY_ID | MUST NOT | n/a | n/a | n/a 277 | | | | 279 [1] = Implementation MUST have the configuration option to send 280 this ID type in the ID payload. Whether or not the ID type is 281 used is a matter of local configuration. 283 [2] = The ID in the ID payload MUST match the contents of the 284 corresponding field (listed) in the certificate exactly, with no 285 other lookup. The matched ID MAY be used for SPD lookup, but is 286 not required to be used for this. 288 [3] = At a minimum, Implementation MUST be able to be configured to 289 perform exact matching of the ID payload contents to an entry in 290 the local SPD. 292 [4] = In addition, the implementation MAY also be configurable to 293 perform substring or wildcard matches of ID payload contents to 294 entries in the local SPD. (More on this in sect 3.1.5). 296 When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, 298 string as appears in the corresponding SubjectAltName attribute. 299 This document RECOMMENDS that deployers use this configuration 300 option. All these ID types are treated the same: as strings that can 301 be compared easily and quickly to a corresponding string in an 302 explicit attribute in the certificate. Of these types, FQDN and 303 USER_FQDN are RECOMMENDED over IP addresses (see discussion in 304 3.1.1). 306 When sending a DN as ID, implementations MUST send the entire DN in 307 ID. Also, implementations MUST support at least the C, CN, O, and OU 308 attributes for SPD matching. See 3.1.5 for more details about DN, 309 including SPD matching. 311 Recipients MUST be able to perform SPD matching on the exact 312 contents of the ID, and this SHOULD be the default setting. In 313 addition, implementations MAY use substrings or wildcards in local 314 policy configuration to do the SPD matching against the ID contents. 315 In other words, implementations MUST be able to do exact matches of 316 ID to SPD, but MAY also be configurable to do substring or wildcard 317 matches of ID to SPD. 319 IKEv2 adds an optional IDr payload in the second exchange that the 320 initiator may send to the responder in order to specify which of the 321 responder's multiple identities should be used. The responder MAY 322 choose to send an IDr in the 3rd exchange that differs in type or 323 content from the initiator-generated IDr. The initiator MUST be able 324 to receive a responder- 325 generated IDr that is different from the one the initiator generated. 326 Whether or not to accept such a response and continue with IKE 327 processing is a matter of local policy. 329 3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR 331 Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR 332 ID type. These addresses MUST be stored in "network byte order," as 333 specified in [RFC791]: The least significant bit (LSB) of each octet 334 is the LSB of the corresponding byte in the network address. For the 335 ID_IPV4_ADDR type, the payload MUST contain exactly four octets 336 [RFC791]. For the ID_IPV6_ADDR type, the payload MUST contain exactly 337 sixteen octets [RFC1883]. 339 Note that this document does NOT RECOMMEND populating the ID payload 340 with IP addresses due to interoperability issues such as problems with 341 NAT traversal, and problems with IP verification behavior. 343 Deployments may only want to consider using the IP address as IKE_ID 344 if the following are true: 345 - the peer's IP address are fixed, not dynamically changing 346 - the peer's are NOT behind a NAT'ing device 347 - the administrator intends the implementation to verify that the 348 IP address in the peer's source matches the IP address in the IKE_ID 349 received, and that of the certificate's iPAddress field in the 350 subjectAltName extension. 352 presented in IKE_ID matches via bitwise comparison the IP address 353 present in the certificate's iPAddress field in the subjectAltName 354 extension. Implementations MUST perform this verification by default. 355 When comparing the contents of ID with the iPAddress field in the 356 subjectAltName extension for equality, binary comparison MUST be 357 performed. If the default is enabled, then a mismatch between the 358 two MUST be treated as an error and security association setup MUST 359 be aborted. This event SHOULD be auditable. Implementations MAY 360 provide a configuration option to (i.e. local policy configuration 361 can enable) skip that verification step, but that option MUST be off 362 by default. We include the "option-to-skip" in order to permit 363 better interoperability, as today implementations vary greatly in 364 how they behave on this topic of verification between IKE_ID and 365 cert contents. 367 Implemenations MUST be capable of verifying that the address 368 contained in the ID is the same as the peer source address. If 369 IKE_ID is one of the IP address types, then implementations MUST 370 perform this verification by default. If this default is enabled, 371 then a mismatch MUST be treated as an error and security association 372 setup MUST be aborted. This event SHOULD be auditable. 373 Implementations MAY provide a configuration option to (i.e. local 374 policy configuration can enable) skip that verification step, but 375 that option MUST be off by default. We include the "option-to-skip- 376 validatation" in order to permit better interoperability, as today 377 implementations vary greatly in how they behave on this topic of 378 verification to source IP. 380 If the default for both the verifications above are enabled, then, 381 by transitive property, the implementation will also be verifying 382 that the peer source IP address matches via a bitwise comparison the 383 contents of the iPAddress field in the subjectAltName extension in 384 the certificate. In addition, implementations MAY allow 385 administrators to configure a local policy that explicitly requires 386 that the peer source IP address match via a bitwise comparison the 387 contents of the iPAddress field in the subjectAltName extension in 388 the certificate. Implementations SHOULD allow administrators to 389 configure a local policy that skips this validation check. 391 Implementations MAY support substring, wildcard, or regular 392 expression matching of the IKE_ID to contents in the SPD, and such 393 would be a matter of local security policy configuration. 395 Implementations MAY use the IP address found in the header of packets 396 received from the peer to lookup the policy, but such implementations 397 MUST still perform verification of the ID payload. Although packet IP 398 addresses are inherently untrustworthy and must therefore be 399 independently verified, it is often useful to use the apparent IP 400 be used until the mandatory identity-based policy lookup can be 401 performed. 403 For instance, if the IP address of the peer is unrecognized, a VPN 404 gateway device might load a general "road warrior" policy that 405 specifies a particular CA that is trusted to issue certificates which 406 contain a valid rfc822Name which can be used by that implementation 407 to perform authorization based on access control lists (ACLs) after 408 the peer's certificate has been validated. The rfc822Name can then be 409 used to determine the policy that provides specific authorization to 410 access resources (such as IP addresses, ports, and so forth). 412 As another example, if the IP address of the peer is recognized to be 413 a known peer VPN endpoint, policy may be determined using that 414 address, but until the identity (address) is validated by validating 415 the peer certificate, the policy MUST NOT be used to authorize any 416 IPsec traffic. 418 3.1.2. ID_FQDN 420 Implementations MUST support the ID_FQDN ID type, generally to 421 support host-based access control lists for hosts without fixed IP 422 addresses. However, implementations SHOULD NOT use the DNS to map the 423 FQDN to IP addresses for input into any policy decisions, unless that 424 mapping is known to be secure, such as when [DNSSEC] is employed. 426 Implemenations MUST be capable of verifying that the identity 427 contained in the ID payload matches identity information contained 428 in the peer end entity certificate, in the dNSName field in the 429 subjectAltName extension. Implementations MUST perform this 430 verification by default. When comparing the contents of ID with the 431 dNSName field in the subjectAltName extension for equality, caseless 432 string comparison MUST be performed. Substring, wildcard, or regular 433 expression matching MUST NOT be performed for this comparison. If 434 this default is enabled, then a mismatch MUST be treated as an error 435 and security association setup MUST be aborted. This event SHOULD be 436 auditable. Implementations MAY provide a configuration option to 437 (i.e. local policy configuration can enable) skip that verification 438 step, but that option MUST be off by default. We include the 439 "option-to-skip-validatation" in order to permit better 440 interoperability, as today implementations vary greatly in how they 441 behave on this topic. 443 Implementations MAY support substring, wildcard, or regular 444 expression matching of the IKE_ID to contents in the SPD, and such 445 would be a matter of local security policy configuration. 447 3.1.3. ID_USER_FQDN 449 Implementations MUST support the ID_USER_FQDN ID type, generally to 450 support user-based access control lists for users without fixed IP 451 FQDN portion to IP addresses for input into any policy decisions, 452 unless that mapping is known to be secure, such as when [DNSSEC] is 453 employed. 455 Implemenations MUST be capable of verifying that the identity 456 contained in the ID payload matches identity information contained 457 in the peer end entity certificate, in the rfc822Name field in the 458 subjectAltName extension. Implementations MUST perform this 459 verification by default. When comparing the contents of ID with the 460 rfc822Name field in the subjectAltName extension for equality, 461 caseless string comparison MUST be performed. Substring, wildcard, 462 or regular expression matching MUST NOT be performed for this 463 comparison. If this default is enabled, then a mismatch MUST be 464 treated as an error and security association setup MUST be aborted. 465 This event SHOULD be auditable. Implementations MAY provide a 466 configuration option to (i.e. local policy configuration can enable) 467 skip that verification step, but that option MUST be off by default. 468 We include the "option-to-skip-validatation" in order to permit 469 better interoperability, as today implementations vary greatly in 470 how they behave on this topic. 472 Implementations MAY support substring, wildcard, or regular 473 expression matching of the IKE_ID to contents in the SPD, and such 474 would be a matter of local security policy configuration. 476 3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, 477 ID_IPV6_ADDR_RANGE 479 As there is currently no standard method for putting address subnet 480 or range identity information into certificates, the use of these ID 481 types is currently undefined. Implementations MUST NOT generate these 482 ID types. 484 Note that work in [SBGP] for defining blocks of addresses using 485 the certificate extension identified by 487 id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } 489 is experimental at this time. 491 3.1.5. ID_DER_ASN1_DN 493 Implementations MUST support receiving the ID_DER_ASN1_DN ID type. 494 Implementations MUST be capable of generating this type, and the 495 decision to do so will be a matter of local security policy 496 configuration. When generating this type, implementations MUST 497 populate the contents of ID with the Subject Name from the end 498 entity certificate, and MUST do so such that a binary comparison of 499 the two will succeed. If there is not a match, this MUST be treated 500 as an error and security association setup MUST be aborted. This 501 event SHOULD be auditable. For instance, if the certificate was 502 erroneously created such that the encoding of the Subject Name DN 503 varies from the constraints set by DER, that non-conformant DN MUST 504 be used to populate the ID payload: in other words, implementations 505 does not appear in the certificate as DER. 507 Implementations MUST NOT populate ID with the Subject Name from the 508 end entity certificate if it is empty, as described in the "Subject" 509 section of PKIX. 511 Regarding SPD matching, implementations MUST be able to perform 512 matching based on a bitwise comparison of the entire DN in ID to its 513 entry in the SPD. However, operational experience has shown that 514 using the entire DN in local configuration is difficult, especially 515 in large scale deployments. Therefore, implementations also MUST be 516 able to perform SPD matches of any combination of one or more of the 517 C, CN, O, OU attributes within Subject DN in the ID to the same in 518 the SPD. Implementations MAY support matching using additional DN 519 attributes in any combination, although interoperability is far from 520 certain and dubious. Implementations MAY also support performing 521 substring, wildcard, or regular expression matches for any of its 522 supported DN attributes from ID, in any combination, to the SPD. 523 Such flexibility allows deployers to create one SPD entry on the 524 gateway for an entire department of a company (e.g. O=Foobar Inc., 525 OU=Engineering) while still allowing them to draw out other details 526 from the DN (e.g. CN=John Doe) for auditing purposes. All the above 527 is a matter of local implementation and local policy definition and 528 enforcement capability, not bits on the wire, but will have a great 529 impact on interoperability. 531 3.1.6. ID_DER_ASN1_GN 533 Implementations MUST NOT generate this type. 535 3.1.7. ID_KEY_ID 537 The ID_KEY_ID type used to specify pre-shared keys and thus is out of 538 scope. 540 3.1.8. Selecting an Identity from a Certificate 542 Implementations MUST support certificates that contain more than a 543 single identity. In many cases a certificate will contain an identity 544 such as an IP address in the subjectAltName extension in addition to 545 a non-empty Subject Name. 547 The identity with which an implementation chooses to populate the 548 IKE_ID payload is a local matter. For compatibility with non- 549 conformant implementations, implementations SHOULD populate ID with 550 whichever identity is likely to be named in the peer's policy. In 551 practice, this generally means FQDN, or USER_FQDN. 553 3.1.9. Transitively Binding Identity to Policy 554 In the presence of certificates that contain multiple identities, 555 implementations MUST select the most appropriate identity from the 556 certificate and populate the ID with that. The responder MUST use 557 the identity sent as a first key when selecting the policy. 558 Responder MUST also use most specific policy from that database if 559 there are overlapping policies caused by wildcards (or the 560 implementation can de-correlate the policy database so there will 561 not be overlapping entries, or it can also forbid creation of 562 overlapping policies and leave the de-correlation process to the 563 administrator, but this moves the problem to administrator it is NOT 564 RECOMMENDED). 566 For example, imagine that a peer is configured with a certificate 567 that contains both a non-empty Subject Name and a dNSName. The 568 initiator MUST know by policy which of those to use, and it 569 indicates the policy in the other end by selecting the correct ID. 570 If the responder has both a specific policy for the dNSName for this 571 host, and generic wildcard rule for some attributes present in the 572 subject Name, it will match a different policy depending which ID is 573 sent. As the initiator knows why it wanted to connect the responder, 574 it also knows what identity it should use to match the policy it 575 needs to the operation it tries to perform; it is the only party who 576 can select the ID adequately. 578 In the event the policy cannot be found in the responder's SPD using 579 the ID sent by the initiator, then the responder MAY use the other 580 identities in the certificate when attempting to match a suitable 581 policy. For example, say the certificate contains both non- 582 empty'subject Name, dNSName and iPAddress. The initiator sends ID of 583 iPAddress, but the responder does not have that in the policy 584 database. If the responder has a rule for the dNSName it MAY use 585 policy based on that. 587 If overlapping policies are found in this step, the responder cannot 588 know which one of those should be selected, i.e. if the responder 589 does have rules for both Subject Name and for dNSName, and it would 590 need to select one of those policies, but it cannot know which one 591 to select. One or both of those rules could also be wildcard rules. 593 The responder cannot use de-correctlation or forbidding the 594 overlapping policies, as there is no way to detect those overlaps 595 exist before the arrival of the certificate that makes the 596 overlapping a reality. In the case where overlapping policies exist, 597 the responder SHOULD terminate the negotiation with error, which 598 informs the other end that adminstrative modification to its policy 599 must be performed (i.e. it needs to use some other identity). 601 3.2. Certificate Request Payload 603 The Certificate Request (CERTREQ) Payload allows an implementation to 604 revocation lists. It is not clear from ISAKMP exactly how that set 605 should be specified or how the peer should respond. We describe the 606 semantics on both sides. 608 3.2.1. Certificate Type 610 The Certificate Type field identifies to the peer the type of 611 certificate keying materials that are desired. ISAKMP defines 10 612 types of Certificate Data that can be requested and specifies the 613 syntax for these types. For the purposes of this document, only the 614 following types are relevant: 616 * X.509 Certificate - Signature 617 * Revocation Lists (CRL and ARL) 618 * PKCS #7 wrapped X.509 certificate 619 * IKEv2's Hash and URL of X.509 certificate 621 The use of the other types: 623 * X.509 Certificate - Key Exchange 624 * PGP Certificate 625 * DNS Signed Key 626 * Kerberos Tokens 627 * SPKI Certificate 628 * X.509 Certificate Attribute 629 * IKEv2's Raw RSA Key 630 * IKEv2's Hash and URL of X.509 bundle 632 are out of the scope of this document. 634 3.2.2. X.509 Certificate - Signature 636 This type requests that the end entity certificate be a signing 637 certificate. 639 3.2.3. Revocation Lists (CRL and ARL) 641 ISAKMP and IKEv2 do not support Certificate Payload sizes over 642 approximately 64K, which is too small for many CRLs. In addition, 643 the acquisition of revocation material is to be dealt with out of 644 band of IKE. For this and other reasons, implementations SHOULD NOT 645 generate CERTREQs where the 646 Certificate Type is "Certificate Revocation List (CRL)" or 647 "Authority Revocation List (ARL)". Implementations that do generate 648 such CERTREQs MUST NOT expect the responder to send a CRL or ARL, 649 and MUST NOT fail for not receiving it. Upon receipt of such a 650 CERTREQ, implementations MAY ignore the request. 652 revocation checking SHOULD be listed in either the Certificate 653 Distribution Point (CDP) or the Authority Information Access (AIA) 654 attributes of the certificate extensions (see section 4 for 655 details.) Implementations MUST be able to process these attributes, 656 and from them be able to identify cached revocation material, or 657 retrieve the relevant revocation material from a URL, for validation 658 processing. In addition, implementations MUST have the ability to 659 configure validation checking information for each certificate 660 authority. Regardless of the method (CDP, AIA, or static 661 configuration), the acquisition of revocation material occurs out of 662 band of IKE. 664 3.2.4. PKCS #7 wrapped X.509 certificate 666 This ID type defines a particular encoding (not a particular 667 certificate), some current implementations may ignore CERTREQs they 668 receive which contain this ID type, and the authors are unaware of 669 any implementations that generate such CERTREQ messages. Therefore, 670 the use of this type is deprecated. Implementations SHOULD NOT 671 require CERTREQs that contain this Certificate Type. Implementations 672 which receive CERTREQs which contain this ID type MAY treat such 673 payloads as synonymous with "X.509 Certificate - Signature". 675 3.2.5 IKEv2's Hash and URL of X.509 certificate 677 This ID type defines a request for the peer to send a hash and URL 678 of it X.509 certificate, instead of the actual certificate itself. 679 This is a particularly useful mechanism when the peer is a device 680 with little memory and lower bandwidth, e.g. a mobile handset or 681 consumer electronics device. 683 3.2.6. Presence or Absence of Certificate Request Payloads 685 When in-band exchange of certificate keying materials is desired, 686 implementations MUST inform the peer of this by sending at least one 687 CERTREQ. An implementation which does not send any CERTREQs during an 688 exchange SHOULD NOT expect to receive any CERT payloads. 690 3.2.7. Certificate Requests 692 3.2.7.1. Specifying Certificate Authorities 694 Implementations MUST generate CERTREQs for every peer trust anchor 695 that local policy explicitly deems trusted during a given exchange. 696 For IKEv1, implementations MUST populate the Certificate Authority 697 field with the Subject Name of the trust anchor, populated such that 698 binary comparison of the Subject Name and the Certificate Authority 699 will succeed. For IKEv2, implementations MUST populate the 700 Certificate Authority field as specified in [IKEv2]. 702 Upon receipt of a CERTREQ, implementations MUST respond by sending 703 the end entity certificate corresponding to the Certificate Authority 704 listed in the CERTREQ. Implementations SHOULD NOT NOT send any 705 certificates other than the appropriate end entity certificate (see 706 sect 3.3 for discussion). 708 available, implementations SHOULD resort to local heuristics to 709 determine which end entity is most appropriate to use for generating 710 the CERTREQ. Such heuristics are out of the scope of this document. 712 3.2.6.2. Empty Certificate Authority Field 714 Implementations SHOULD generate CERTREQs where the Certificate Type is 715 "X.509 Certificate - Signature" and where an entry exits in the 716 Certificate Authority field. However, implementations MAY generate 717 CERTREQs with an empty Certificate Authority field under special 718 conditions. Though PKIX prohibits certificates with empty issuer name 719 fields, there does exist a use case where doing so is appropriate, and 720 carries special meaning in the IKE context. This has become a 721 convention within the IKE interoperability tests and usage space, and 722 so its use is specified, explained and RECOMMENDED here for the sake 723 of interoperability. 725 USE CASE: Consider the case where you have a gateway with multiple 726 policies for a large number of IKE peers.'some of these peers are 727 business partners, some are remote access employees, some are 728 teleworkers, some are branch offices, and/or the gateway may be 729 simultaneously serving many many customers (e.g. Virtual Routers). The 730 total number of certificates, and corresponding trust anchors, is very 731 high, say hundreds. Each of these policies is configured with one or 732 more acceptable trust anchors, so that in total, the gateway has one 733 hundred (100) trust anchors that could possibly used to authenticate 734 an incoming connection. Assume that many of those connections 735 originate from hosts/gateways with dynamically assigned IP addresses, 736 so that the source IP of the IKE initiator is not known to the gateway, 737 nor is the identity of the intiator (until it is revealed in Main Mode 738 message 5). In IKE main mode message 4, the responder gateway will 739 need to send a CERTREQ to the initiator. Given this example, the 740 gateway will have no idea which of the hundred possible Certificate 741 Authorities to send in the CERTREQ. Sending all possible Certificate 742 Authorities will cause significant processing delays, bandwidth 743 consumption, and UDP fragmentation, so this tactic is ruled out. 745 In such a deployment, the responder gateway implementation should be 746 able to all it can to indicate a Certificate Authority in the CERTREQ. 747 This means the responder SHOULD first check SPD to see if it can match 748 the source IP, and find some indication of which CA is associated with 749 that IP. If this fails (because the source IP is not familiar, as in 750 the case above), then the responder SHOULD have a configuration option 751 specifying which CA's are the default CAs to indicate in CERTREQ 752 during such ambiguous connections (e.g. send CERTREQ with these N CAs 753 if there is an unknown source IP). If such a fall-back is not 754 configured or impractical in a certain deployment scenario, then the 755 responder implementation SHOULD have both of the following 756 configuration options: 758 - send a CERTREQ payload with an empty Certificate Authority field, 759 or 761 - terminate the negotiation with an appropriate error message and 762 audit log entry. 764 Receiving a CERTREQ payload with an empty Certificate Authority field 765 indicates that the initiator peer should send all/any certificates it 766 has, regardless of the trust anchor. The initiator should be aware of 767 what policy and which identity it will use, as it initiated the 768 connection on a matched policy to begin with, and can thus respond 769 with the appropriate certificate. If multiple certificates are sent, 770 they MUST have the same public key, otherwise the responder does not 771 know which key was used in the Main Mode message 5. 773 If, after sending an empty CERTREQ in Main Mode message 4, a responder 774 receives a certificate in message 5 from a trust anchor that the 775 responder either (a) does NOT support, or (b) was not configured for 776 the policy (that policy was now able to be matched due to having the 777 initiators certificate present), then the responder SHOULD terminate 778 the exchange with proper error message and audit log entry. 780 Instead of sending a empty CERTREQ, the responder implementation may 781 be configured to terminate the negotiation on the grounds of a 782 conflict with locally configured security policy. 784 The decision of which to configure is a matter of local security 785 policy, this document RECOMMENDS that both options be presented to 786 administrators. 788 More examples, and explanation on this issue are included in Appendix 789 C - More on Empty CERTREQs. 791 3.2.7. Robustness 793 3.2.7.1. Unrecognized or Unsupported Certificate Types 795 Implementations MUST be able to deal with receiving CERTREQs with 796 unsupported Certificate Types. Absent any recognized and supported 797 CERTREQs, implementations MAY treat them as if they are of a 798 supported type with the Certificate Authority field left empty, 799 depending on local policy. ISAKMP Section 5.10 "Certificate Request 800 Payload Processing" specifies additional processing. 802 3.2.7.2. Undecodable Certificate Authority Fields 804 Implementations MUST be able to deal with receiving CERTREQs with 805 undecodable Certificate Authority fields. Implementations MAY ignore 806 such payloads, depending on local policy. ISAKMP specifies other 807 actions which may be taken. 809 3.2.7.3. Ordering of Certificate Request Payloads 811 Implementations MUST NOT assume that CERTREQs are ordered in any way. 813 3.2.8.1. Duplicate Certificate Request Payloads 815 Implementations SHOULD NOT send duplicate CERTREQs during an 816 exchange. 818 3.2.8.2. Name Lowest 'Common' Certification Authorities 820 When a peer's certificate keying materials have been cached, an 821 implementation can send a hint to the peer to elide some of the 822 certificates the peer would normally respond with. In addition to the 823 normal set of CERTREQs that are sent specifying the trust anchors, an 824 implementation MAY send CERTREQs containing the Issuer Name of the 825 relevant cached end entity certificates. When sending these hints, it 826 is still necessary to send the normal set of CERTREQs because the 827 hints do not sufficiently convey all of the information required by 828 the peer. Specifically, either the peer may not support this 829 optimization or there may be additional chains that could be used in 830 this context but will not be specified if only supplying the issuer 831 of the end entity certificate. 833 No special processing is required on the part of the recipient of 834 such a CERTREQ, and the end entity certificates will still be sent. 835 On the other hand, the recipient MAY elect to elide certificates 836 based on receipt of such hints. 838 CERTREQs must contain information that identifies a Certification 839 Authority certificate, which results in the peer always sending at 840 least the end entity certificate. This mechanism allows 841 implementations to determine unambiguously when a new certificate is 842 being used by the peer, perhaps because the previous certificate has 843 just expired, which will result in a failure because the needed 844 keying materials are not available to validate the new end entity 845 certificate. Implementations which implement this optimization MUST 846 recognize when the end entity certificate has changed and respond to 847 it by not performing this optimization when the exchange is retried. 849 3.2.8.3. Example 851 Imagine that an implementation has previously received and cached the 852 peer certificate chain TA->CA1->CA2->EE. If during a subsequent 853 exchange this implementation sends a CERTREQ containing the Subject 854 Name in certificate TA, this implementation is requesting that the 855 peer send at least 3 certificates: CA1, CA2, and EE. On the other 856 hand, if this implementation also sends a CERTREQ containing the 857 Subject Name of CA2, the implementation is providing a hint that only 858 fact that TA is a trust anchor should not be construed to imply that 859 TA is a self-signed certificate. 861 3.3. Certificate Payload 863 The Certificate (CERT) Payload allows the peer to transmit a single 864 certificate or CRL. The following practice is explicitly deprecated: 865 Some implementations also transmit each certificate in the chain above 866 the end entity certificate up to and including the certificate whose 867 Issuer Name matches the name specified in the Certificate Authority 868 field. This practice is deprecated because the chaining certificates 869 and validation material has now become a responsibility of the 870 lifecycle protocols between the IPsec peer and the PKI system, and not 871 the transmission within IKE. Therefore implementations SHOULD NOT send 872 any certificates other than the appropriate end entity certificate, 873 and SHOULD NOT send any CRLs/ARLs. 875 Multiple certificates should be transmitted in 876 multiple payloads. However, not all certificate forms that are legal 877 in PKIX make sense in the context of IPsec. The issue of how to 878 represent IKE-meaningful name-forms in a certificate is especially 879 problematic. This document provides a profile for a subset of PKIX 880 that 881 makes sense for IKEv1/ISAKMP and IKEv2. 883 3.3.1. Certificate Type 885 The Certificate Type field identifies to the peer the type of 886 certificate keying materials that are included. ISAKMP defines 10 887 types of Certificate Data that can be sent and specifies the syntax 888 for these types. For the purposes of this document, only the 889 following types are relevant: 891 * X.509 Certificate - Signature 892 * Revocation Lists (CRL and ARL) 893 * PKCS #7 wrapped X.509 certificate 894 * IKEv2's Hash and URL of X.509 certificate 896 The use of the other types: 898 * X.509 Certificate - Key Exchange 899 * PGP Certificate 900 * DNS Signed Key 901 * Kerberos Tokens 902 * SPKI Certificate 903 * X.509 Certificate Attribute 904 * IKEv2's Raw RSA Key 905 * IKEv2's Hash and URL of X.509 bundle 907 3.3.2. X.509 Certificate - Signature 909 This type specifies that Certificate Data contains a certificate used 910 for signing. Implementations SHOULD only send an end entity signature 911 certificate. 913 3.3.3. Revocation Lists (CRL and ARL) 915 These types specify that Certificate Data contains an X.509 CRL or ARL. 916 These types SHOULD NOT be sent in IKE. See section 3.2.3 for discussion. 918 3.3.4. IKEv2's Hash and URL of X.509 certificate 920 This type specifies that Certificate Data contains a hash and the URL 921 to a repository where an X.509 certificate can be retrieved. 923 3.3.5. PKCS #7 wrapped X.509 certificate 925 This type defines a particular encoding, not a particular certificate 926 type. Implementations SHOULD NOT generate CERTs that contain this 927 Certificate Type. Implementations SHOULD accept CERTs that contain 928 this Certificate Type because several implementations are known to 929 generate them. Note that those implementations may include entire 930 certificate hierarchies inside a single CERT PKCS #7 payload, which 931 violates the requirement specified in ISAKMP that this payload 932 contain a single certificate. 934 3.3.6. Certificate Payloads Not Mandatory 936 An implementation which does not receive any CERTREQs during an 937 exchange SHOULD NOT send any CERT payloads, except when explicitly 938 configured to proactively send CERT payloads in order to interoperate 939 with non-compliant implementations. This MUST NOT be the 940 default behavior of implementations. 942 Implementations whose local security policy configuration expects that 943 a peer must receive certificates through out-of-band means SHOULD 944 ignore any CERTREQ messages that are received. 946 Implementations that receive CERTREQs from a peer which contain only 947 unrecognized Certification Authorities SHOULD NOT continue the 948 exchange, in order to avoid unnecessary and potentially expensive 949 cryptographic processing, denial of service (resource starvation) 950 attacks. 952 3.3.7. Response to Multiple Certificate Authority Proposals 953 In response to multiple CERTREQs which contain different Certificate 954 Authority identities, implementations MAY respond using an end entity 955 certificate which chains to a CA that matches any of the identities 956 provided by the peer. 958 3.3.8. Using Local Keying Materials 960 Implementations MAY elect to skip the processing of a given set of 961 CERTs 962 if preferable keying materials are available. For instance, the 963 contents of a CERT may be available from a previous exchange or may 964 be available through some out-of-band means. 966 3.3.9. Robustness 968 3.3.9.1. Unrecognized or Unsupported Certificate Types 970 Implementations MUST be able to deal with receiving CERTs with 971 unrecognized or unsupported Certificate Types. Implementations MAY 973 discard such payloads, depending on local policy. ISAKMP Section 5.10 974 "Certificate Request Payload Processing" specifies additional 975 processing. 977 3.3.9.2. Undecodable Certificate Data Fields 979 Implementations MUST be able to deal with receiving CERTs with 980 undecodable Certificate Data fields. Implementations MAY discard such 981 payloads, depending on local policy. ISAKMP specifies other actions 982 which may be taken. 984 3.3.9.3. Ordering of Certificate Payloads 986 For IKEv1, implementations MUST NOT assume that CERTs are ordered in 987 any way. For IKEv2, implementations MUST NOT assume that any except 988 the first CERT is ordered in any way. IKEv2 specifies that the first 989 CERT contain the end entity certificate which is to be used to 990 authenticate the peer. 992 3.3.9.4. Duplicate Certificate Payloads 994 Implementations MUST support receiving multiple identical CERTs 995 during an exchange. 997 3.3.9.5. Irrelevant Certificates 999 Implementations MUST be prepared to receive certificates and CRLs 1000 which are not relevant to the current exchange. Implementations MAY 1001 Implementations MAY send certificates which are irrelevant to an 1002 exchange. One reason for including certificates which are irrelevant 1003 to an exchange is to minimize the threat of leaking identifying 1004 information in exchanges where CERT is not encrypted. It should be 1005 noted, however, that this probably provides rather poor protection 1006 against leaking the identity. 1008 Another reason for including certificates that seem irrelevant to an 1009 exchange is that there may be two chains from the Certificate 1010 Authority to the end entity, each of which is only valid with certain 1011 validation parameters (such as acceptable policies). Since the end 1012 entity doesn't know which parameters the relying party is using, it 1013 should send the certs needed for both chains (even if there's only 1014 one CERTREQ). 1016 Although implementations SHOULD NOT send multiple end entity 1017 certificates if the receipient cannot determine the correct 1018 certificate to use for authentication by using either the contents of 1019 the ID payload to match the certificate or, in IKEv2, the correct 1020 certificate is contained in the first CERT. In other words, 1021 receipients SHOULD NOT be expected to iterate over multiple end- 1022 entity certs. 1024 3.3.10. Optimizations 1026 3.3.10.1. Duplicate Certificate Payloads 1028 Implementations SHOULD NOT send duplicate CERTs during an exchange. 1029 Such payloads should be suppressed. 1031 3.3.10.2. Send Only End Entity Certificates 1033 When multiple CERTREQs are received which specify certificate 1034 authorities within the end entity certificate chain, implementations 1035 SHOULD send always and only the relevant end entity certificate, as 1036 chaining will take place out-of-band of IKE, between the IPsec peer 1037 and the PKI system. Implementations SHOULD NOT send the chain. 1039 3.3.11.0. Ignore Duplicate Certificate Payloads 1041 Implementations MAY employ local means to recognize CERTs that have 1042 been received in the past, whether part of the current exchange or 1043 not, for which keying material is available and may discard these 1044 duplicate CERTs. 1046 3.3.11. Hash Payload 1047 IKEv1 specifies the optional use of the Hash Payload to carry a 1048 pointer to a certificate in either of the Phase 1 public key 1049 encryption modes. This pointer is used by an implementation to locate 1050 the end entity certificate that contains the public key that a peer 1051 should use for encrypting payloads during the exchange. 1053 Implementations SHOULD include this payload whenever the public 1054 portion of the keypair has been placed in a certificate. 1056 4. Profile of PKIX 1058 Except where specifically stated in this document, implementations 1059 MUST conform to the requirements of [PKIX]. 1061 4.1. X.509 Certificates 1063 4.1.1. Versions 1065 Although PKIX states that "implementations SHOULD be prepared to 1066 accept any version certificate", in practice this profile requires 1067 certain extensions that necessitate the use of Version 3 certificates 1068 for all but self-signed certificates used as trust anchors. 1069 Implementations that conform to this document MAY therefore reject 1070 Version 1 and Version 2 certificates in all other cases. 1072 4.1.2. Subject Name 1074 Certificate Authority implementations MUST be able to create 1075 certificates with Subject Name fields with at least the following four 1076 attributes: CN, C, O, OU. Implementations MAY support other Subject 1077 Name attributes as well. The contents of these attributes SHOULD be 1078 configurable on a certificate by certificate basis, as these fields 1079 will likely be used by IKE implementations to match SPD policy. 1081 See sect 3.1.5 for details on how IKE implementations need to be able 1082 to process Subject Name field attributes for SPD policy lookup. 1084 4.1.2.1. Empty Subject Name 1086 Implementations MUST accept certificates which contain an empty 1087 Subject Name field, as specified in PKIX. Identity information in 1088 such certificates will be contained entirely in the SubjectAltName 1089 extension. 1091 4.1.2.2. Specifying Hosts and FQDN in Subject Name 1093 Implementations which desire to place host names that are not 1094 "Gateway Router") in the Subject Name MUST use the commonName 1095 attribute. 1097 While nothing prevents an FQDN, USER_FQDN, or IP address information 1098 from appearing somewhere in the Subject Name contents, such entries 1099 MUST NOT be interpreted as identity information for the purposes of 1100 matching with IKE_ID or for policy lookup. 1102 If the FQDN is intended to be processed as identity for the purposes 1103 IKE_ID matching, it MUST be placed in the dNSName field of the 1104 SubjectAltName extension. Implementations MUST NOT populate the 1105 Subject Name in place of populating the dNSName field of the 1106 SubjectAltName extension. 1108 4.1.2.3. EmailAddress 1110 As specified in PKIX, implementations MUST NOT populate 1111 DistinguishedNames with the EmailAddress attribute. 1113 4.1.3. X.509 Certificate Extensions 1115 Conforming applications MUST recognize extensions which must or may 1116 be marked critical according to this specification. These extensions 1117 are: KeyUsage, SubjectAltName, and BasicConstraints. 1119 Implementations SHOULD generate certificates such that the extension 1120 criticality bits are set in accordance with PKIX and this document. 1121 With respect to PKIX compliance, implementations processing 1122 certificates MAY ignore the value of the criticality bit for 1123 extensions that are supported by that implementation, but MUST 1124 support the criticality bit for extensions that are not supported by 1125 that implementation. That is, if an implementation supports (and thus 1126 is going to process) a given extension, then it isn't necessary to 1127 reject the certificate if the criticality bit is different from what 1128 PKIX states it must be. However, if an implementation does not 1129 support an extension that PKIX mandates be critical, then the 1130 implementation must reject the certificate. 1132 implements bit in cert PKIX mandate behavior 1133 ------------------------------------------------------ 1134 yes true true ok 1135 yes true false ok or reject 1136 yes false true ok or reject 1137 yes false false ok 1138 no true true reject 1139 no true false reject 1140 no false true reject 1141 no false false ok 1142 Implementations SHOULD NOT assume that other implementations support 1143 the AuthorityKeyIdentifier and SubjectKey ID extensions, and thus 1144 SHOULD NOT generate certificate hierarchies which are overly complex 1145 to process in the absence of this extension, such as those that 1146 require possibly verifying a signature against a large number of 1147 similarly named CA certificates in order to find the CA certificate 1148 which contains the key that was used to generate the signature. 1150 4.1.3.2. KeyUsage 1152 KeyUsage is not defined in the context of IPsec. Implementations 1153 SHOULD accept certificates with any set of KeyUsage bits asserted, as 1154 certificates may be used for multiple applications. 1156 4.1.3.3. PrivateKeyUsagePeriod 1158 PKIX recommends against the use of this extension. The 1159 PrivateKeyUsageExtension is intended to be used when signatures will 1160 need to be verified long past the time when signatures using the 1161 private keypair may be generated. Since IKE SAs are short-lived 1162 relative to the intended use of this extension in addition to the 1163 fact that each signature is validated only a single time, the 1164 usefulness of this extension in the context of IKE is unclear. 1165 Therefore, implementations MUST NOT generate certificates that 1166 contain the PrivateKeyUsagePeriod extension. If an implementation 1167 receives a certificate with this set, it SHOULD ignore it. 1169 4.1.3.4. Certificate Policies 1171 Many IPsec implementations do not currently provide support for the 1172 Certificate Policies extension. Therefore, implementations that 1173 generate certificates which contain this extension SHOULD NOT mark the 1174 extension as critical. 1176 4.1.3.5. PolicyMappings 1178 Many implementations do not support the PolicyMappings extension. 1180 4.1.3.6. SubjectAltName 1182 Deployments that intend to use an IKE_ID of either FQDN, USER_FQDN or 1183 IP*_ADDR MUST issue certificates with the corresponding SujectAltName 1184 fields populated with the same data. Implementations SHOULD generate 1185 only the following GeneralName choices in the subjectAltName extension, 1186 as these choices map to 1187 legal IKEv1/ISAKMP/IKEv2 Identification Payload types: rfc822Name, 1188 dNSName, or iPAddress. Although it is possible to specify any 1189 GeneralName choice in the Identification Payload by using the 1190 ID_DER_ASN1_GN ID type, implementations SHOULD NOT assume that a peer 1191 supports such functionality, and SHOULD NOT generate certificates that 1192 do so. 1194 4.1.3.6.1. dNSName 1196 This field MUST contain a fully qualified domain name. If IKE ID type 1197 equals FQDN then the dNSName field MUST match its contents. 1198 Implementations MUST NOT generate names that contain wildcards. 1199 Implementations MAY treat certificates that contain wildcards in this 1200 field as syntactically invalid. 1202 Although this field is in the form of an FQDN, implementations SHOULD 1203 NOT assume that this field contains an FQDN that will resolve via the 1204 DNS, unless this is known by way of some out-of-band mechanism. Such 1205 a mechanism is out of the scope of this document. Implementations 1206 SHOULD NOT treat the failure to resolve as an error. 1208 4.1.3.6.2. iPAddress 1210 If IKE ID type equals IP*_ADDR then the iPAddress field MUST match its 1211 contents. Note that although PKIX permits CIDR [CIDR] notation in the 1212 "Name Constraints" extension, PKIX explicitly prohibits using CIDR 1213 notation for conveying identity information. In other words, the CIDR 1214 notation MUST NOT be used in the subjectAltName extension. 1216 4.1.3.6.3. rfc822Name 1218 If IKE ID type equals USER_FQDN then the rfc822Name field MUST match 1219 its contents. Although this field is in the form of an Internet mail 1220 address, implementations SHOULD NOT assume that this field contains a 1221 valid email address, unless this is known by way of some out-of-band 1222 mechanism. Such a mechanism is out of the scope of this document. 1224 4.1.3.7. IssuerAltName 1226 Implementations SHOULD NOT assume that other implementations support 1227 the IssuerAltName extension, and especially should not assume that 1228 information contained in this extension will be displayed to end 1229 users. 1231 4.1.3.8. SubjectDirectoryAttributes 1233 The SubjectDirectoryAttributes extension is intended to contain 1234 privilege information, in a manner analogous to privileges carried in 1235 Attribute Certificates. Implementations MAY ignore this extension 1236 when it is marked non-critical, as PKIX mandates. 1238 4.1.3.9. BasicConstraints 1240 PKIX mandates that CA certificates contain this extension and that it 1241 be marked critical. Implementations SHOULD reject CA certificates 1242 that do not contain this extension. For backwards compatibility, 1243 implementations may accept such certificates if explicitly configured 1244 to do so, but the default for this setting MUST be to reject such 1245 certificates. 1247 4.1.3.10. NameConstraints 1249 Many implementations do not support the NameConstraints extension. 1250 Since PKIX mandates that this extension be marked critical when 1251 present, implementations which intend to be maximally interoperable 1252 SHOULD NOT generate certificates which contain this extension. 1254 4.1.3.11. PolicyConstraints 1256 Many implementations do not support the PolicyConstraints extension. 1257 Since PKIX mandates that this extension be marked critical when 1258 present, implementations which intend to be maximally interoperable 1259 SHOULD NOT generate certificates which contain this extension. 1261 4.1.3.12. ExtendedKeyUsage 1263 ExtendedKeyUsage is not defined in the context of IKE/IPsec. 1264 Implementations SHOULD accept certificates with any set of 1265 ExtendedKeyUsage usages asserted. Implementations MUST NOT generate 1266 this extension in certificates which are being used for IPsec. 1268 Note that a previous proposal for the use of three ExtendedKeyUsage 1269 values is obsolete and explicitly deprecated by this specification. 1270 For historical reference, those values were id-kp-ipsecEndSystem, 1271 id-kp-ipsecTunnel, and id-kp-ipsecUser. 1273 4.1.3.13. CRLDistributionPoints 1275 Because this document deprecates the sending of CRLs in band, the use 1276 of CRLDistributionPoints (CDP) becomes very important if CRLs are used 1277 for revocation checking (as opposed to say OCSP). The ipsec peer 1278 either needs to have a URL for a CRL written into its local 1279 configuration, or it needs to learn it from CDP. Therefore, 1280 implementations SHOULD issue certificates with a populated CDP. 1282 Failure to validate the CRLDistributionPoints/IssuingDistributionPoint 1283 pair can result in CRL substitution where an entity knowingly 1285 the CRL 1286 which is supposed to be used which would show the entity as revoked. 1288 Implementations MUST support validating that the contents of 1289 CRLDistributionPoints match those of the IssuingDistributionPoint to 1290 prevent CRL substitution when the issuing CA is using them. At least 1291 one CA is known to default to this type of CRL use. See section 1292 4.2.2.5 for more information. 1294 CDPs SHOULD be "resolvable". For example some very prominent 1295 implementations are well known for including CDPs like 1296 http://localhost/path_to_CRL and http:///path_to_CRL which are as bad 1297 as not including the CDP. 1299 See PKIX docs for CRLDistributionPoints intellectual rights 1300 information. Note that both the CRLDistributionPoints and 1301 IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED 1302 by PKIX, so there is no requirement to license any IPR. 1304 4.1.3.14. InhibitAnyPolicy 1306 Many implementations do not support the InhibitAnyPolicy extension. 1307 Since PKIX mandates that this extension be marked critical when 1308 present, implementations which intend to be maximally interoperable 1309 SHOULD NOT generate certificates which contain this extension. 1311 4.1.3.15. FreshestCRL 1313 Implementations MUST NOT assume that the FreshestCRL extension will 1314 exist in peer extensions. Note that most implementations do not 1315 support delta CRLs. 1317 4.1.3.16. AuthorityInfoAccess 1319 PKIX defines the AuthorityInfoAccess extension, which is used to 1320 indicate "how to access CA information and services for the issuer of 1321 the certificate in which the extension appears." Because this document 1322 deprecates the sending of CRLs in band, the use of AuthorityInfoAccess 1323 (AIA) becomes very important if OCSP is to be used for revocation 1324 checking (as opposed to CRLs). The ipsec peer either needs to have a 1325 URI for the OCSP query written into its local configuration, or it 1326 needs to learn it from AIA. Therefore, implementations SHOULD support 1327 this extension, especially if OCSP will be used. 1329 4.1.3.17. SubjectInfoAccess 1331 PKIX defines the SubjectInfoAccess private certificate extension, 1332 which is used to indicate "how to access information and services for 1333 extension has no known use in the context of IPsec. Conformant 1334 implementations SHOULD ignore this extension when present. 1336 4.2. X.509 Certificate Revocation Lists 1338 When validating certificates, implementations MUST make use of 1339 certificate revocation information, and SHOULD support such 1340 revocation information in the form of CRLs, unless non-CRL revocation 1341 information is known to be the only method for transmitting this 1343 information. Deployment that intend to use CRLs for revocation MUST 1344 populate the CRLDistributionPoint field. Therefore Implementation MUST 1345 support issuing certificates with this field populated according to 1346 administrator's needs. Implementations MAY provide a configuration 1347 option to disable use of certain types of revocation information, but 1348 that option MUST be off by default. Such an option is often valuable 1349 in lab testing environments. 1351 4.2.1. Multiple Sources of Certificate Revocation Information 1353 Implementations which support multiple sources of obtaining 1354 certificate revocation information MUST act conservatively when the 1355 information provided by these sources is inconsistent: when a 1356 certificate is reported as revoked by one trusted source, the 1357 certificate MUST be considered revoked. 1359 4.2.2. X.509 Certificate Revocation List Extensions 1361 4.2.2.1. AuthorityKeyIdentifier 1363 Implementations SHOULD NOT assume that other implementations support 1364 the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate 1365 certificate hierarchies which are overly complex to process in the 1366 absence of this extension. 1368 4.2.2.2. IssuerAltName 1370 Implementations SHOULD NOT assume that other implementations support 1371 the IssuerAltName extension, and especially should not assume that 1372 information contained in this extension will be displayed to end 1373 users. 1375 4.2.2.3. CRLNumber 1377 As stated in PKIX, all issuers conforming to PKIX MUST include this 1378 extension in all CRLs. 1380 4.2.2.4. DeltaCRLIndicator 1381 Implementations that do not support delta CRLs MUST reject CRLs which 1382 contain the DeltaCRLIndicator (which MUST be marked critical 1383 according to PKIX) and MUST make use of a base CRL if it is 1384 available. Such implementations MUST ensure that a delta CRL does not 1385 "overwrite" a base CRL, for instance in the keying material database. 1387 4.2.2.4.2. Delta CRL Recommendations 1389 Since some implementations that do not support delta CRLs may behave 1390 incorrectly or insecurely when presented with delta CRLs, 1391 administrators and deployers SHOULD consider whether issuing delta 1392 CRLs increases security before issuing such CRLs. 1394 And, if all the elements in the VPN and PKI systems do not adequately 1395 support Delta CRLs, then their use should be questioned. 1397 The authors are aware of several implementations which behave in an 1398 incorrect or insecure manner when presented with delta CRLs. See 1399 Appendix B for a description of the issue. Therefore, this 1400 specification RECOMMENDS NOT issuing delta CRLs at this time. On 1401 the other hand, failure to issue delta CRLs exposes a larger window 1402 of vulnerability. See the Security Considerations section of PKIX for 1403 additional discussion. Implementors as well as administrators are 1404 encouraged to consider these issues. 1406 4.2.2.5. IssuingDistributionPoint 1408 A CA that is using CRLDistributionPoints may do so to provide many 1409 "small" CRLs, each only valid for a particular set of certificates 1410 issued by that CA. To associate a CRL with a certificate, the CA 1411 places the CRLDistributionPoints extension in the certificate, and 1412 places the IssuingDistributionPoint in the CRL. The 1413 distributionPointName field in the CRLDistributionPoints extension 1414 MUST be identical to the distributionPoint field in the 1415 IssuingDistributionPoint extension. At least one CA is known to 1416 default to this type of CRL use. See section 4.1.3.14 for more 1417 information. 1419 4.2.2.6. FreshestCRL 1421 Given the recommendations against implementations generating delta 1422 CRLs, this specification RECOMMENDS that implementations do not 1423 populate CRLs with the FreshestCRL extension, which is used to obtain 1424 delta CRLs. 1426 5. Configuration Data Exchange Conventions 1428 Below we present a common format for exchanging configuration data. 1429 Implementations MUST support these formats, MUST support arbitrary 1430 whitespace at the beginning and end of any line, MUST support 1431 arbitrary line lengths although they SHOULD generate lines less than 1432 disciplines: LF (US-ASCII 10), CR (US-ASCII 13), and CRLF. 1434 5.1. Certificates 1436 Certificates MUST be Base64 encoded and appear between the following 1437 delimiters: 1439 -----BEGIN CERTIFICATE----- 1440 -----END CERTIFICATE----- 1442 5.2. Public Keys 1444 Implementations MUST support two forms of public keys: certificates 1445 and so-called "raw" keys. Certificates should be transferred in the 1446 same form as above. A raw key is only the SubjectPublicKeyInfo 1447 portion of the certificate, and MUST be Base64 encoded and appear 1448 between the following delimiters: 1450 -----BEGIN PUBLIC KEY----- 1452 -----END PUBLIC KEY----- 1454 5.3. PKCS#10 Certificate Signing Requests 1456 A PKCS#10 [PKCS-10] Certificiate Signing Request MUST be Base64 1457 encoded and appear between the following delimeters: 1459 -----BEGIN CERTIFICATE REQUEST----- 1461 -----END CERTIFICATE REQUEST----- 1463 6. Security Considerations 1465 6.1. Identification Payload 1467 Depending on the exchange type, ID may be passed in the clear. 1468 Administrators in some environments may wish to use the empty 1469 Certification Authority option to prevent such information from 1470 leaking, at the possible cost of some performance, although such use 1471 is discouraged. 1473 6.2. Certificate Request Payload 1475 The Contents of CERTREQ are not encrypted in IKE. In some 1476 some environments may wish to use the empty Certification Authority 1477 option to prevent such information from leaking, at the cost of 1478 performance. 1480 6.3. Certificate Payload 1482 Depending on the exchange type, CERTs may be passed in the clear and 1483 therefore may leak identity information. 1485 6.4. IKEv1 Main Mode 1487 Certificates may be included in any message, and therefore 1488 implementations may wish to respond with CERTs in a message that 1489 offers privacy protection, in Main Mode messages 5 and 6. 1490 Implementations may not wish to respond with CERTs in the second 1491 message, thereby violating the identity protection feature of Main 1492 Mode in IKEv1. 1494 7. Intellectual Property Rights 1496 No new intellectual property rights are introduced by this document. 1498 8. IANA Considerations 1500 There are no known numbers which IANA will need to manage. 1502 9. Normative References 1504 [DOI] Piper, D., "The Internet IP Security Domain of 1505 Interpretation for ISAKMP", RFC 2407, November 1998. 1507 [IKEv1] Harkins, D. and Carrel, D., "The Internet Key Exchange 1508 (IKE)", RFC 2409, November 1998. 1510 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1511 draft-ietf-ipsec-ikev2-13.txt, March 2004, work in progress. 1513 [IPSEC] Kent, S. and Atkinson, R., "Security Architecture for the 1514 Internet Protocol", RFC 2401, November 1998. 1516 [ISAKMP] Maughan, D., et. al., "Internet Security Association and 1517 Key Management Protocol (ISAKMP)", RFC 2408, November 1998. 1519 [PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax 1520 Version 1.5", RFC 2314, March 1998. 1522 [PKIX] Housley, R., et al., "Internet X.509 Public Key 1523 List (CRL) Profile", RFC 3280, April 2002. 1525 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1526 September 1981. 1528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1529 Requirement Levels", BCP 14, RFC 2119, March 1997. 1531 10. Informational References 1533 [CIDR] Fuller, V., et al., "Classless Inter-Domain Routing (CIDR): 1534 An Address Assignment and Aggregation Strategy", RFC 1519, 1535 September 1993. 1537 [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", 1538 RFC 2535, March 1999. 1540 [RFC1883] Deering, S. and Hinden, R. "Internet Protocol, Version 6 1541 (IPv6) Specification", RFC 1883, December 1995. 1543 [ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap", 1544 draft-ietf-pkix-roadmap-08.txt. 1546 [SBGP] Lynn, C., Kent, S., and Seo, K., "X.509 Extensions for 1547 IP Addresses and AS Identifiers", 1548 draft-ietf-pkix-x509-ipaddr-as-extn-00.txt. 1550 11. Acknowledgements 1552 The authors would like to acknowledge the expired draft-ietf-ipsec- 1553 pki-req-05.txt for providing valuable materials for this document, 1554 especially Eric Rescorla, one of its original authors. 1555 The authors would like to especially thank Greg Carter, Russ Housley, 1556 Steve Hanna, and Gregory Lebovitz for their valuable comments, some of 1557 which have been incorporated unchanged into this document. 1559 12. Author's Addresses 1561 Brian Korver 1562 Xythos Software, Inc. 1563 One Bush Street, Suite 600 1564 San Francisco, CA 94104 1565 USA 1566 Phone: +1 415 248-3800 1567 EMail: briank@xythos.com 1569 Full Copyright Statement 1570 to the rights, licenses and restrictions contained in BCP 78 and 1571 except as set forth therein, the authors retain all their rights. 1573 This document and the information contained herein are provided on an 1574 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1575 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1576 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1577 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1578 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1579 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1581 Intellectual Property 1583 The IETF takes no position regarding the validity or scope of any 1584 Intellectual Property Rights or other rights that might be claimed 1585 to pertain to the implementation or use of the technology 1586 described in this document or the extent to which any license 1587 under such rights might or might not be available; nor does it 1588 represent that it has made any independent effort to identify any 1589 such rights. Information on the procedures with respect to 1590 rights in RFC documents can be found in BCP 78 and BCP 79. 1592 Copies of IPR disclosures made to the IETF Secretariat and any 1593 assurances of licenses to be made available, or the result of an 1594 attempt made to obtain a general license or permission for the use 1595 of such proprietary rights by implementers or users of this 1596 specification can be obtained from the IETF on-line IPR repository 1597 at http://www.ietf.org/ipr. 1599 The IETF invites any interested party to bring to its attention 1600 any copyrights, patents or patent applications, or other 1601 proprietary rights that may cover technology that may be required 1602 to implement this standard. Please address the information to the 1603 IETF at ietf-ipr@ietf.org. 1605 Acknowledgement 1607 Funding for the RFC Editor function is currently provided by the 1608 Internet Society. 1610 Appendix A. Change History 1612 * July 2004 (-01) (Edited by Gregory Lebovitz) 1614 Changed ISAKMP references in Abstract and Intro to IKE. 1616 Editorial changes to make the text conform with the summary table in 1617 3.1, especially in the text following the table in 3.1. Particular 1618 note should be paid to changes in section 3.5.1. 1620 Sect 3.1.1 - editorial changes to aid in clarification. Added text on 1621 when deployers might consider using IP addr, but strongly encouraged 1622 not to. 1624 Sect 3.1.8 - removed IP address from list of practically used ID types. 1626 3.1.9 overhauled (per Kivinen, July 18) 1628 3.2 - added IKEv2's Hash and URL of x.509 to list of those profiled 1629 and gave it its own section, now 3.2.5 1630 - added note in CRL/ARL section about revocation occurring OOB of 1631 IKE 1632 - deleted ARL as its own section and collapsed it into Revocation 1633 Lists (CRL and ARL) for consciseness. Renumbered accordingly. 1635 Sect 3.2.7.2 - Changed from MUST not send empty certreqs to SHOULD 1636 send CERTREQs which contain CA fields with direction on how, but MAY 1637 send empty CERTREQs in certain case. Use case added, and specifics of 1638 both initiator and responder behavior listed. 1640 APPENDIX C added to fill out the explanation (mostly discussion from 1641 list). 1643 3.3 - clarified that sending CRLs and chaining certs is deprecated. 1644 - 1645 added IKEv2's Hash and URL of x.509 to list of those profiled and gave 1646 it its own section. Condensed ARL into CRL and renumbered accordingly. 1647 - duplicate section was removed, renumbered accordingly 1649 3.3.10.2 - title changed. sending chaining becomes SHOULD NOT. 1651 4.1.2 added text to explicity call out support for CN, C, O, OU 1653 collapsed 4.1.2.3 into 4.1.2.2 and renumbered accordingly. 1655 Collapsed 4.1.3.2 into 4.1.3.1 and renumbered accordingly 1657 Edited 4.1.3.2 Key Usage and 4.1.3.12 ExtKey Usage according to 1658 Hoffman, July18 1660 4.1.3.3 if receive cert w/ PKUP, ignore it. 1662 4.1.3.13 - CDP changed text to represent SHOULD issue, and how 1663 important CDP becomes when we do not send CRLs in-band. Added SHOULD 1664 for CDPs actually being resolvable (reilly email). 1666 Reordered 6.4 for better clarity. 1668 Added Rescorla to Acknowledgements section, as he is no longer listed 1669 as an editor, since -00. 1671 * May 2004 (renamed draft-ietf-pki4ipsec-ikecert-profile-00.txt) 1673 Made it clearer that the format of the ID_IPV4_ADDR payload comes 1674 from RFC791 and is nothing new. (Tero Kivinen Feb 29) 1676 Permit implementations to skip verifying that the peer source 1677 address matches the contents of ID_IPV{4,6}_ADDR. (Tero Kivinen 1678 Feb 29, Gregory Lebovitz Feb 29) 1680 Removed paragraph suggesting that implementations favor 1681 unauthenticated peer source addresses over an unauthenticated ID 1682 for initial policy lookup. (Tero Kivinen Feb 29, Gregory Lebovitz 1683 Feb 29) 1685 Removed some text implying RSA encryption mode was in scope. (Tero 1686 Kivinen Feb 29) 1688 Relaxed deprecation of PKCS#7 CERT payloads. (Tero Kivinen Feb 29) 1690 Made it clearer that out-of-scope local heuristics should be used 1691 for picking an EE cert to use when generating CERTREQ, not when 1692 receiving CERTREQ. (Tero Kivinen Feb 29) 1693 Made it clearer that CERT processing can be skipped when the 1694 contents of a CERT are already known. (Tero Kivinen Feb 29) 1696 Implementations SHOULD generate BASE64 lines less than 76 1697 characters. (Tero Kivinen Feb 29) 1699 Added "Except where specifically stated in this document, 1700 implementations MUST conform to the requirements of PKIX" (Steve 1701 Hanna Oct 7, 2003) 1703 RECOMMENDS against populating the ID payload with IP addresses due 1704 to interoperability issues such as problem with NAT traversal. 1705 (Gregory Lebovitz May 14) 1707 Changed "as revoked by one source" to "as revoked by one trusted 1708 source". (Michael Myers, May 15) 1710 Specifying Certificate Authorities section needed to be 1711 regularized with Gregory Lebovitz's CERT proposal from -04. (Tylor 1712 Allison, May 15) 1714 Added text specifying how receipients SHOULD NOT be expected to 1715 iterate over multiple end-entity certs. (Tylor Allison, May 15) 1716 relevant. 1718 IKEv2: Explained that IDr sent by responder doesn't have to match 1719 the [IDr] sent initiator in second exchange. 1721 IKEv2: Noted that "The identity ... does not necessarily have to 1722 match anything in the CERT payload" (S3.5) is not contradicted by 1723 SHOULD in this document. 1725 IKEv2: Noted that ID_USER_FQDN renamed to ID_RFC822_ADDR, and 1726 ID_USER_FQDN would be used exclusively in this document. 1728 IKEv2: Declared that 3 new CERTREQ and CERT types are not profiled 1729 in this document (well, at least not yet, pending WG discussion of 1730 what to do -- note that they are only SHOULDs in IKEv2). 1732 IKEv2: Noted that CERTREQ payload changed from DN to SHA-1 of 1733 SubjectPublicKeyInfo. 1735 IKEv2: Noted new requirement that specifies that the first 1736 certificate sent MUST be the EE cert (section 3.6). 1738 * February 2004 (-04) 1740 Minor editorial changes to clean up language 1742 Deprecate in-band exchange of CRLs 1744 Incorporated Gregory Lebovitz's proposal for CERT payloads: 1745 "should deal with all the CRL, Intermediat Certs, Trust Anchors, 1746 etc OOB of IKE; MUST be able to send and receive EE cert payload; 1747 only real exception is Intermediate Cets which MAY be sent and 1748 SHOULD be able to be receivable (but in reality there are very few 1749 hierarchies in operation, so really it's a corner case); SHOULD 1750 NOT send the other stuff (CRL, Trust Anchors, etc) in cert 1751 payloads in IKE; SHOULD be able to accept the other stuff if by 1752 chance it gets sent, though we hope they don't get sent" 1754 Incorporated comments contained in Oct 7, 2003 email from 1755 steve.hanna@sun.com to ipsec@lists.tislabs.com 1757 Moved text from "Profile of ISAKMP" Background section to each 1758 payload section (removing duplication of these sections) 1760 Removed "Certificate-Related Playloads in ISAKMP" section since it 1761 was not specific to IKE. 1763 Incorporated Gregory Lebovitz's table in the "Identification 1764 Moved text from "binding identity to policy" sections to each 1765 payload section 1767 Moved text from "IKE" section into now-combined "IKE/ISAKMP" 1768 section 1770 ID_USER_FQDN and ID_FQDN promoted to MUST from MAY 1772 Promoted sending ID_DER_ASN1_DN to MAY from SHOULD NOT, and 1773 receiving from MUST from MAY 1775 Demoted ID_DER_ASN1_GN to MUST NOT 1777 Demoted populating Subject Name in place of populating the dNSName 1778 from SHOULD NOT to MUST NOT and removed the text regarding 1779 domainComponent 1781 Revocation information checking MAY now be disabled, although not 1782 by default 1783 Aggressive Mode removed from this profile 1785 * June 2003 (-03) 1787 Minor editorial changes to clean up language 1789 Minor additional clarifying text 1791 Removed hyphenation 1793 Added requirement that implementations support configuration data 1794 exchange having arbitrary line lengths 1796 * February 2003 (-02) 1798 Word choice: move from use of "root" to "trust anchor", in 1799 accordance with PKIX 1801 SBGP note and reference for placing address subnet and range 1802 information into certificates 1804 Clarification of text regarding placing names of hosts into the 1805 Added table to clarify text regarding processing of the 1806 certificate extension criticality bit 1808 Added text underscoring processing requirements for 1809 CRLDistributionPoints and IssuingDistributionPoint 1811 * October 2002, Reorganization (-01) 1812 * June 2002, Initial Draft (-00) 1814 Appendix B. The Possible Dangers of Delta CRLs 1816 The problem is that the CRL processing algorithm is sometimes written 1817 incorrectly with the assumption that all CRLs are base CRLs and it is 1818 assumed that CRLs will pass content validity tests. Specifically, 1819 such implementations fail to check the certificate against all 1820 possible CRLs: if the first CRL that is obtained from the keying 1821 material database fails to decode, no further revocation checks are 1822 performed for the relevant certificate. This problem is compounded by 1823 the fact that implementations which do not understand delta CRLs may 1824 fail to decode such CRLs due to the critical DeltaCRLIndicator 1825 extension. The algorithm that is implemented in this case is 1826 approximately: 1828 fetch newest CRL 1829 check validity of CRL signature 1830 if CRL signature is valid then 1831 if CRL does not contain unrecognized critical extensions 1832 and certificate is on CRL then 1833 set certificate status to revoked 1835 The authors note that a number of PKI toolkits do not even provide a 1836 method for obtaining anything but the newest CRL, which in the 1837 presence of delta CRLs may in fact be a delta CRL, not a base CRL. 1839 Note that the above algorithm is dangerous in many ways. See PKIX 1840 for the correct algorithm. 1842 Appendix C - More on Empty CERTREQs 1844 Sending empty certificate requests is commonly used in 1845 implementations, and in the IPsec interop meetings, vendors have 1846 generally agreed that it means that send all/any certificates you 1848 key, as otherwise the other end does not know which key was used). 1849 For 99% of cases the client have exactly one certificate and public 1850 key, so it really doesn't matter, but the server might have multiple, 1851 thus it simply needs to say to the client, use any certificate you 1852 have. If we are talking about corporate vpns etc, even if the client 1853 have multiple certificates or keys, all of them would be usable when 1854 authenticating to the server, so client can simply pick one. 1856 If there is some real difference on which cert to use (like ones 1857 giving different permissions), then the client MUST be configured 1858 anyways, or it might even ask the user which one to use (the user is 1859 the only one who knows whether he needs admin privileges, thus needs 1860 to use admin cert, or is the normal email privileges ok, thus using 1861 email only cert). 1863 99% of the cases the client have exactly one certificate, so it will 1864 send it. In 90% of the rest of the cases, any of the certificates is 1865 ok, as they are simply different certificates from same CA, or 1866 different CAs for the same corporate VPN, thus any of them is ok. 1868 Sending empty certificate requests has been agreed 1869 there to mean "give me a cert; any cert". 1871 Justification: 1872 - Responder first does all it can to send a certreq with a CA, 1873 check for IP match in SPD, have a default set of CAs to use in 1874 ambiguous cases, etc. 1875 - sending empty certreq's is fairly common in implementations today, 1876 and is generally accepted to mean "send me a cert, any cert that works 1877 for you" 1878 - saves responder sending potentially 100's of certs, the 1879 fragmentation problems that follow, etc. 1880 - in +90% of use cases, Initiators have exactly 1 cert 1881 - in +90% of the remaining use cases, the multiple certs it has are 1882 issued by the same CA 1883 - in the remaining use case(s) -- if not all the others above -- 1884 the Initiator will be configured explicitly with which cert to send, 1885 so responding to an empty certreq is easy. 1887 The following example shows why initiators need to have sufficient 1888 policy definition to know which certificate to use for a given 1889 connecting it initiates. 1891 EXAMPLE: Your client (initiator) is configured with VPN policies for 1892 gateways A and B (representing perhaps corporate partners). The 1893 policies for the two gateways look something like: 1895 Acme Company policy (gateway A) 1896 Engineering can access 10.1.1.0 1897 Trusted CA: CA-A, Trusted Users: OU=Engineering 1898 Partners can access 20.1.1.0 1899 Trusted CA: CA-B, Trusted Users: OU=AcmePartners 1901 Bizco Company policy (gateway B) 1902 sales can access 30.1.1.0 1903 Partners can access 40.1.1.0 1904 Trusted CA: CA-B, Trusted Users: OU=BizcoPartners 1906 You are an employee of Acme and you are issued the following 1907 certificates: 1908 From CA-A: CN=JoeUser,OU=Engineering 1909 From CA-B: CN=JoePartner,OU=BizcoPartners 1911 The client MUST be configured locally to know which CA to use when 1912 connecting to either gateway. If your client is not configured to know 1913 the local credential to use for the remote gateway, this scenario will 1914 not work either. If you attempt to connect to Bizco, everything will 1915 work... as you are presented with responding with a certificate signed 1916 by CA-B or CA-C... as you only have a certificated from CA-B you are 1917 OK. If you attempt to connect to Acme, you have an issue because you 1918 are presented with an ambiguous policy selection. As the initiator, 1919 you will be presented with certificate requests from both CA A and CA 1920 B. You have certificates issued by both CAs, but only one of the 1921 certificates will be usable. How does the client know which 1922 certificate it should present It must have sufficiently clear local 1923 policy specifying which one credential to present for the connection 1924 it initiates. 1926 Copyright (C) The Internet Society (2004). This document is subject 1927 to the rights, licenses and restrictions contained in BCP 78 and 1928 except as set forth therein, the authors retain all their rights.