idnits 2.17.00 (12 Aug 2021) /tmp/idnits16660/draft-ietf-pki4ipsec-ikecert-profile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 14) being 281 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 213 instances of too long lines in the document, the longest one being 9 characters in excess of 72. == There are 45 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 923 has weird spacing: '...tion to locat...' == Line 1003 has weird spacing: '...lements bit...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 303 -- Looks like a reference, but probably isn't: '2' on line 305 -- Looks like a reference, but probably isn't: '3' on line 313 == Missing Reference: 'IDr' is mentioned on line 1565, but not defined == Unused Reference: 'ROADMAP' is defined on line 1450, 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: 12 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Brian Korver 2 Xythos Software 3 INTERNET-DRAFT May 2004 (Expires Oct 2004) 4 6 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 ISAKMP and PKIX both provide frameworks that must be profiled for use 31 in a given application. This document provides a profile of ISAKMP 32 and PKIX that defines the requirements for using PKI technology in 33 the context of IPsec. The document complements protocol 34 specifications such as IKEv1 and IKEv2, which assume the existence of 35 public key certificates and related keying materials, but which do 36 not address PKI issues explicitly. This document addresses those 37 issues. 39 Table of Contents 41 1 Introduction 4 42 2 Terms and Definitions 5 43 3 Profile of IKEv1/ISAKMP and IKEv2 5 44 3.1 Identification Payload 5 45 3.1.1 ID_IPV4_ADDR and ID_IPV6_ADDR 7 46 3.1.2 ID_FQDN 8 47 3.1.3 ID_USER_FQDN 9 49 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 50 5/2004 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 Certificate Revocation List (CRL) 11 62 3.2.4 Authority Revocation List (ARL) 12 63 3.2.5 PKCS #7 wrapped 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 X.509 Certificate - Signature 15 80 3.3.4 Certificate Revocation List (CRL) 16 81 3.3.5 Authority Revocation List (ARL) 16 82 3.3.6 PKCS #7 wrapped X.509 certificate 16 83 3.3.7 Certificate Payloads Not Mandatory 16 84 3.3.8 Response to Multiple Certificate Authority Proposals 16 85 3.3.9 Using Local Keying Materials 17 86 3.3.10 Robustness 17 87 3.3.10.1 Unrecognized or Unsupported Certificate Types 17 88 3.3.10.2 Undecodable Certificate Data Fields 17 89 3.3.10.3 Ordering of Certificate Payloads 17 90 3.3.10.4 Duplicate Certificate Payloads 17 91 3.3.10.5 Irrelevant Certificates 17 92 3.3.11 Optimizations 18 93 3.3.11.1 Duplicate Certificate Payloads 18 94 3.3.11.2 Send Lowest 'Common' Certificates 18 95 3.3.11.3 Ignore Duplicate Certificate Payloads 18 96 3.3.12 Hash Payload 18 97 4 Profile of PKIX 19 98 4.1 X.509 Certificates 19 99 4.1.1 Versions 19 101 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 102 5/2004 104 4.1.2 Subject Name 19 105 4.1.2.1 Empty Subject Name 19 106 4.1.2.2 Specifying Non-FQDN Hosts in Subject Name 19 107 4.1.2.3 Specifying FQDN Host Names in Subject Name 19 108 4.1.2.4 EmailAddress 20 109 4.1.3 X.509 Certificate Extensions 20 110 4.1.3.1 AuthorityKeyIdentifier 20 111 4.1.3.2 SubjectKeyIdentifier 21 112 4.1.3.3 KeyUsage 21 113 4.1.3.4 PrivateKeyUsagePeriod 21 114 4.1.3.5 Certificate Policies 21 115 4.1.3.6 PolicyMappings 21 116 4.1.3.7 SubjectAltName 21 117 4.1.3.7.1 dNSName 22 118 4.1.3.7.2 iPAddress 22 119 4.1.3.7.3 rfc822Name 22 120 4.1.3.8 IssuerAltName 22 121 4.1.3.9 SubjectDirectoryAttributes 22 122 4.1.3.10 BasicConstraints 23 123 4.1.3.11 NameConstraints 23 124 4.1.3.12 PolicyConstraints 23 125 4.1.3.13 ExtendedKeyUsage 23 126 4.1.3.14 CRLDistributionPoints 23 127 4.1.3.15 InhibitAnyPolicy 24 128 4.1.3.16 FreshestCRL 24 129 4.1.3.17 AuthorityInfoAccess 24 130 4.1.3.18 SubjectInfoAccess 24 131 4.2 X.509 Certificate Revocation Lists 24 132 4.2.1 Multiple Sources of Certificate Revocation Information 25 133 4.2.2 X.509 Certificate Revocation List Extensions 25 134 4.2.2.1 AuthorityKeyIdentifier 25 135 4.2.2.2 IssuerAltName 25 136 4.2.2.3 CRLNumber 25 137 4.2.2.4 DeltaCRLIndicator 25 138 4.2.2.4.1 If Delta CRLs Are Unsupported 25 139 4.2.2.4.2 Delta CRL Recommendations 25 140 4.2.2.5 IssuingDistributionPoint 26 141 4.2.2.6 FreshestCRL 26 142 5 Configuration Data Exchange Conventions 26 143 5.1 Certificates 26 144 5.2 Public Keys 27 145 5.3 PKCS#10 Certificate Signing Requests 27 146 6 Security Considerations 27 147 6.1 Identification Payload 27 148 6.2 Certificate Request Payload 27 149 6.3 Certificate Payload 27 150 6.4 IKEv1 Main Mode 28 151 7 Intellectual Property Rights 28 153 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 154 5/2004 156 8 IANA Considerations 28 157 9 Normative References 28 158 10 Informational References 29 159 11 Acknowledgements 29 160 12 Author's Addresses 29 162 1. Introduction 164 IKE [IKEv1] and ISAKMP [ISAKMP] and IKEv2 [IKEv2] provide a secure 165 key exchange mechanism for use with IPsec [IPSEC]. In many cases the 166 peers authenticate using digital certificates as specified in PKIX 167 [PKIX]. Unfortunately, the combination of these standards leads to an 168 underspecified set of requirements for the use of certificates in the 169 context of IPsec. 171 ISAKMP references PKIX but in many cases merely specifies the 172 contents of various messages without specifying their syntax or 173 semantics. Meanwhile, PKIX provides a large set of certificate 174 mechanisms which are generally applicable for Internet protocols, but 175 little specific guidance for IPsec. Given the numerous underspecified 176 choices, interoperability is hampered if all implementors do not make 177 similar choices, or at least fail to account for implementations 178 which have chosen differently. 180 This profile of the ISAKMP and PKIX frameworks is intended to provide 181 an agreed-upon standard for using PKI technology in the context of 182 IPsec by profiling the PKIX framework for use with ISAKMP and IPsec, 183 and by documenting the contents of the relevant ISAKMP payloads and 184 further specifying their semantics. 186 In addition to providing a profile of ISAKMP and PKIX, this document 187 attempts to incorporate lessons learned from recent experience with 188 both implementation and deployment, as well as the current state of 189 related protocols and technologies. 191 Material from ISAKMP, IKEv2, or PKIX is not repeated here, and 192 readers of this document are assumed to have read and understood both 193 documents. The requirements and security aspects of those documents 194 are fully relevant to this document as well. 196 This document is organized as follows. Section 2 defines special 197 terminology used in the rest of this document, Section 3 provides the 198 profile of IKEv1/ISAKMP and IKEv2, and Section 4 provides the profile 199 of PKIX. Section 5 covers conventions for the out-of-band exchange of 200 keying materials for configuration purposes. 202 This document is being discussed on the pki4ipsec@icsalabs.com 203 mailing list. 205 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 206 5/2004 208 2. Terms and Definitions 210 Except for those terms which are defined immediately below, all terms 211 used in this document are defined in either the PKIX, ISAKMP, IKEv2, 212 or DOI [DOI] documents. 214 * Peer source address: The source address in packets from a peer. 215 This address may be different from any addresses asserted as the 216 "identity" of the peer. 217 * FQDN: Fully qualified domain name. 218 * ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both 219 are referred to as ID_USER_FQDN in this document. 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 223 document are to be interpreted as described in RFC-2119 [RFC2119]. 225 3. Profile of IKEv1/ISAKMP and IKEv2 227 3.1. Identification Payload 229 The Identification (ID) Payload is used to indicate the identity that 230 the agent claims to be speaking for. The receiving agent can then use 231 the ID as a lookup key for policy and whatever certificate store or 232 directory that it has available. Our primary concern in this document 233 is to profile the ID payload so that it can be safely used to 234 generate or lookup policy. IKE mandates the use of the ID payload in 235 Phase 1. 237 The [DOI] defines the 11 types of Identification Data that can be 238 used and specifies the syntax for these types. These are discussed 239 below in detail. 241 The ID payload requirements in this document cover only the portion 242 of the explicit policy checks that deal with the Identification 243 Payload specifically. For instance, in the case where ID does not 244 contain an IP address, checks such as verifying that the peer source 245 address is permitted by the relevant policy are not addressed here as 246 they are out of the scope of this document. 248 Implementations SHOULD populate ID with identity information that is 249 contained within the end entity certificate (This SHOULD does not 250 contradict text in IKEv2 Section 3.5 that implies a looser binding 251 between these two). Populating ID with identity information from the 252 end entity certificate enables recipients to use ID as a lookup key 253 to find the peer end entity certificate. The only case where 254 implementations MAY populate ID with information that is not 255 contained in the end entity certificate is when ID contains the peer 257 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 258 5/2004 260 source address (a single address, not a subnet or range). This means 261 that implementations MUST be able to map a peer source address to a 262 peer end entity certificate, even when the certificate does not 263 contain that address. The exact method for performing this mapping is 264 out of the scope of this document. 266 Because implementations may use ID as a lookup key to determine which 267 policy to use, all implementations MUST be especially careful to 268 verify the truthfulness of the contents by verifying that they 269 correspond to some keying material demonstrably held by the peer. 270 Failure to do so may result in the use of an inappropriate or 271 insecure policy. The following sections describe the methods for 272 performing this binding. 274 The following table summarizes the binding of the Identification 275 Payload to the contents of end-entity certificates and of identity 276 information to policy. 278 ID type | Support | Correspond | Cert | SPD lookup 279 | for send | PKIX Attrib | matching | rules 281 ------------------------------------------------------------------- 282 | | | | 283 IP*_ADDR | MUST [1] | SubjAltName | MUST [2] | MUST [3] 284 | | iPAddress | | 285 | | | | 286 FQDN | MUST [1] | SubjAltName | MUST [2] | MUST [3] 287 | | dNSName | | 288 | | | | 289 USER_FQDN| MUST [1] | SubjAltName | MUST [2] | MUST [3] 290 | | rfc822Name | | 291 | | | | 292 DN | MUST [1] | Entire | MUST [2] | MUST support lookup 293 | | Subject, | | on any combination 294 | | bitwise | | of C, CN, O, or OU 295 | | compare | | 296 | | | | 297 IP range | MUST NOT | n/a | n/a | n/a 298 | | | | 299 | | | | 300 KEY_ID | MUST NOT | n/a | n/a | n/a 301 | | | | 303 [1] = MUST be able to send based on local configuration. 305 [2] = The ID in the ID payload MUST match the contents of the 306 corresponding field (listed) in the certificate exactly, with no 307 other lookup. The matched ID MAY be used for SPD lookup, but is 308 not required to be used for this. 310 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 311 5/2004 313 [3] = MUST be able to support exact matching in the SPD, but MAY 314 also support substring or wildcard matches. 316 When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, 317 implementations MUST be configurable to send the same string as 318 appears in the corresponding SubjectAltName attribute. Recipients MAY 319 use wildcards to do the SPD matching. 321 When sending a DN as ID, implementations MUST send the entire DN in 322 ID. Recipients MAY perform SPD lookup based on some combination of C, 323 CN, O, OU. Implementations MUST at a minimum be configurable to match 324 on any combination of those 4 attributes. Implementations MAY support 325 matching using other DN attributes in any combination, including the 326 entire DN. 328 IKEv2 ads an optional IDr payload in the second exchange that the 329 initiator may send to the responder specify which of the responder's 330 identities should be used. The responder MAY choose to send an IDr in 331 the 3rd exchange that differs in type or content from the initiator- 332 generator IDr. The initiator MUST be able to receive a responder- 333 generated IDr that is different from the one the initiator generated. 335 3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR 337 Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR 338 ID type. These addresses MUST be stored in "network byte order," as 339 specified in [RFC791]: The least significant bit (LSB) of each octet 340 is the LSB of the corresponding byte in the network address. For the 341 ID_IPV4_ADDR type, the payload MUST contain exactly four octets 342 [RFC791]. For the ID_IPV6_ADDR type, the payload MUST contain exactly 343 sixteen octets [RFC1883]. When comparing the contents of ID with the 344 iPAddress field in the subjectAltName extension for equality, binary 345 comparison MUST be performed. 347 Note that this document RECOMMENDS against populating the ID payload 348 with IP addresses due to interoperability issues such as problem with 349 NAT traversal. 351 Implementations MUST be capable of verifying that the address 352 contained in ID is the same as the peer source address. 353 Implementations MAY provide a configuration option to skip that 354 verification step, but that option MUST be off by default. If the end 355 entity certificate contains address identities, then the peer source 356 address must match at least one of those identities. If either of the 357 above do not match, this MUST be treated as an error and security 358 association setup MUST be aborted. This event SHOULD be auditable. In 360 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 361 5/2004 363 addition, implementations MUST allow administrators to configure a 364 local policy that requires that the peer source address exist in the 365 certificate. Implementations SHOULD allow administrators to configure 366 a local policy that does not enforce this requirement. 368 Implementations MAY use the IP address found in the header of packets 369 received from the peer to lookup the policy, but such implementations 370 MUST still perform verification of the ID payload. Although packet IP 371 addresses are inherently untrustworthy and must therefore be 372 independently verified, it is often useful to use the apparent IP 373 address of the peer to locate a general class of policies that will 374 be used until the mandatory identity-based policy lookup can be 375 performed. 377 For instance, if the IP address of the peer is unrecognized, a VPN 378 gateway device might load a general "road warrior" policy that 379 specifies a particular CA that is trusted to issue certificates which 380 contain a valid rfc822Name which can be used by that implementation 381 to perform authorization based on access control lists (ACLs) after 382 the peer's certificate has been validated. The rfc822Name can then be 383 used to determine the policy that provides specific authorization to 384 access resources (such as IP addresses, ports, and so forth). 386 As another example, if the IP address of the peer is recognized to be 387 a known peer VPN endpoint, policy may be determined using that 388 address, but until the identity (address) is validated by validating 389 the peer certificate, the policy MUST NOT be used to authorize any 390 IPsec traffic. Whether the address need appear as an identity in the 391 certificate is a matter of local policy, and SHOULD be configurable 392 by an administrator. 394 3.1.2. ID_FQDN 396 Implementations MUST support the ID_FQDN ID type, generally to 397 support host-based access control lists for hosts without fixed IP 398 addresses. However, implementations SHOULD NOT use the DNS to map the 399 FQDN to IP addresses for input into any policy decisions, unless that 400 mapping is known to be secure, such as when [DNSSEC] is employed. 401 When comparing the contents of ID with the dNSName field in the 402 subjectAltName extension for equality, caseless string comparison 403 MUST be performed. Substring, wildcard, or regular expression 404 matching MUST NOT be performed. 406 Implementations MUST verify that the identity contained in the ID 407 payload matches identity information contained in the peer end entity 408 certificate, in the subjectAltName extension. If there is not a 409 match, this MUST be treated as an error and security association 410 setup MUST be aborted. This event SHOULD be auditable. 412 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 413 5/2004 415 3.1.3. ID_USER_FQDN 417 Implementations MUST support the ID_USER_FQDN ID type, generally to 418 support user-based access control lists for users without fixed IP 419 addresses. However, implementations SHOULD NOT use the DNS to map the 420 FQDN portion to IP addresses for input into any policy decisions, 421 unless that mapping is known to be secure, such as when [DNSSEC] is 422 employed. When comparing the contents of ID with the rfc822Name field 423 in the subjectAltName extension for equality, caseless string 424 comparison MUST be performed. Substring, wildcard, or regular 425 expression matching MUST NOT be performed. 427 Implementations MUST verify that the identity contained in the ID 428 payload matches identity information contained in the peer end entity 429 certificate, in the subjectAltName extension. If there is not a 430 match, this MUST be treated as an error and security association 431 setup MUST be aborted. This event SHOULD be auditable. 433 3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, 434 ID_IPV6_ADDR_RANGE 436 As there is currently no standard method for putting address subnet 437 or range identity information into certificates, the use of these ID 438 types is currently undefined. Implementations MUST NOT generate these 439 ID types. 441 Note that work in [SBGP] for defining blocks of addresses using 442 the certificate extension identified by 444 id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } 446 is experimental at this time. 448 3.1.5. ID_DER_ASN1_DN 450 Implementations MUST support receiving the ID_DER_ASN1_DN ID type. 451 Implementations MAY generate this type. Implementations which 452 generate this type MUST populate the contents of ID with the Subject 453 Name from the end entity certificate, and MUST do so such that a 454 binary comparison of the two will succeed. For instance, if the 455 certificate was erroneously created such that the encoding of the 456 Subject Name DN varies from the constraints set by DER, that non- 457 conformant DN MUST be used to populate the ID payload: in other 458 words, implementations MUST NOT re-encode the DN for the purposes of 459 making it DER if it does not appear in the certificate as DER. 460 Implementations MUST NOT populate ID with the Subject Name from the 461 end entity certificate if it is empty, as described in the "Subject" 462 section of PKIX. 464 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 465 5/2004 467 Implementations MUST verify that the identity contained in the ID 468 payload matches identity information contained in the peer end entity 469 certificate, in the Subject Name field. If there is not a match, this 470 MUST be treated as an error and security association setup MUST be 471 aborted. This event SHOULD be auditable. 473 3.1.6. ID_DER_ASN1_GN 475 Implementations MUST NOT generate this type. 477 3.1.7. ID_KEY_ID 479 The ID_KEY_ID type used to specify pre-shared keys and thus is out of 480 scope. 482 3.1.8. Selecting an Identity from a Certificate 484 Implementations MUST support certificates that contain more than a 485 single identity. In many cases a certificate will contain an identity 486 such as an IP address in the subjectAltName extension in addition to 487 a non-empty Subject Name. 489 Which identity an implementation chooses to populate ID with is a 490 local matter. For compatibility with non-conformant implementations, 491 implementations SHOULD populate ID with whichever identity is likely 492 to be named in the peer's policy. In practice, this generally means 493 IP address, FQDN, or USER_FQDN. 495 3.1.9. Transitively Binding Identity to Policy 497 In the presence of certificates that contain multiple identities, 498 implementations SHOULD NOT assume that a peer will choose the most 499 appropriate identity with which to populate ID. Therefore, when 500 determining the appropriate policy, implementations SHOULD select the 501 most appropriate identity to use from the identities contained in the 502 certificate. 504 For example, imagine that a peer is configured with a certificate 505 that contains both a non-empty Subject Name and an dNSName. 506 Independent of which identity is used to populate ID, the host 507 implementation MUST locate the proper policy. For instance, if ID 508 contains the peer Subject Name, then the peer end entity certificate 509 may be found using the Subject Name as a key. Once the certificate 510 has been located and then validated, the dNSName in the certificate 511 can be used to locate the appropriate policy. In other words, the 512 Subject Name is used to find the certificate, the certificate 513 contains the dNSName, and the dNSName is used to lookup policy. 515 Korver [Page 10 ] 516 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 517 5/2004 519 3.2. Certificate Request Payload 521 The Certificate Request (CERTREQ) Payload allows an implementation to 522 request that a peer provide some set of certificates or certificate 523 revocation lists. It is not clear from ISAKMP exactly how that set 524 should be specified or how the peer should respond. We describe the 525 semantics on both sides. 527 3.2.1. Certificate Type 529 The Certificate Type field identifies to the peer the type of 530 certificate keying materials that are desired. ISAKMP defines 10 531 types of Certificate Data that can be requested and specifies the 532 syntax for these types. For the purposes of this document, only the 533 following types are relevant: 535 * X.509 Certificate - Signature 536 * Certificate Revocation List (CRL) 537 * Authority Revocation List (ARL) 538 * PKCS #7 wrapped X.509 certificate 540 The use of the other types: 542 * X.509 Certificate - Key Exchange 543 * PGP Certificate 544 * DNS Signed Key 545 * Kerberos Tokens 546 * SPKI Certificate 547 * X.509 Certificate - Attribute 549 are out of the scope of this document. 551 In addition to the above, IKEv2 adds 3 additional types which are not 552 profiled in this document: 553 * Raw RSA Key 554 * Hash and URL of X.509 certificate 555 * Hash and URL of X.509 bundle 557 3.2.2. X.509 Certificate - Signature 559 This type requests that the end entity certificate be a signing 560 certificate. 562 3.2.3. Certificate Revocation List (CRL) 564 ISAKMP and IKEv2 do not support Certificate Payload sizes over 565 approximately 64K, which is too small for many CRLs. For this and 566 other reasons, implementations SHOULD NOT generate CERTREQs where the 568 Korver [Page 11 ] 569 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 570 5/2004 572 Certificate Type is "Certificate Revocation List (CRL)". Upon receipt 573 of such a CERTREQ, implementations MAY ignore the request. 575 3.2.4. Authority Revocation List (ARL) 577 Implementations SHOULD NOT generate CERTREQ payloads with this type. 578 Recipients of this type SHOULD treat it as synonymous with the CRL 579 type. 581 3.2.5. PKCS #7 wrapped X.509 certificate 583 This ID type defines a particular encoding (not a particular 584 certificate), some current implementations may ignore CERTREQs they 585 receive which contain this ID type, and the authors are unaware of 586 any implementations that generate such CERTREQ messages. Therefore, 587 the use of this type is deprecated. Implementations SHOULD NOT 588 require CERTREQs that contain this Certificate Type. Implementations 589 which receive CERTREQs which contain this ID type MAY treat such 590 payloads as synonymous with "X.509 Certificate - Signature". 592 3.2.6. Presence or Absence of Certificate Request Payloads 594 When in-band exchange of certificate keying materials is desired, 595 implementations MUST inform the peer of this by sending at least one 596 CERTREQ. An implementation which does not send any CERTREQs during an 597 exchange SHOULD NOT expect to receive any CERT payloads. 599 3.2.7. Certificate Requests 601 3.2.7.1. Specifying Certificate Authorities 603 Implementations MUST generate CERTREQs for every peer trust anchor 604 that local policy explicitly deems trusted during a given exchange. 605 For IKEv1, implementations MUST populate the Certificate Authority 606 field with the Subject Name of the trust anchor, populated such that 607 binary comparison of the Subject Name and the Certificate Authority 608 will succeed. For IKEv2, implementations MUST populate the 609 Certificate Authority field as specified in [IKEv2]. 611 Upon receipt of a CERTREQ, implementations MUST respond by sending 612 the end entity certificate but MAY also send each certificate in the 613 chain above the end entity certificate up to and including the 614 certificate whose Issuer Name matches the name specified in the 615 Certificate Authority field. Implementations MAY send other 616 certificates. 618 Note, in the case where multiple end entity certificates may be 619 available, implementations SHOULD resort to local heuristics to 621 Korver [Page 12 ] 622 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 623 5/2004 625 determine which end entity is most appropriate to use for generating 626 the CERTREQ. Such heuristics are out of the scope of this document. 628 3.2.7.2. Empty Certificate Authority Field 630 Implementations MUST NOT generate CERTREQs where the Certificate Type 631 is "X.509 Certificate - Signature" with an empty Certificate 632 Authority field, as this form is explicitly deprecated. Upon receipt 633 of such a CERTREQ from a non-conformant implementation, 634 implementations SHOULD send just the certificate chain associated 635 with the end entity certificate, not including any CRLs or the 636 certificates that would be needed to validate those CRLs. 638 Note that PKIX prohibits certificates with an empty issuer name 639 field. 641 3.2.8. Robustness 643 3.2.8.1. Unrecognized or Unsupported Certificate Types 645 Implementations MUST be able to deal with receiving CERTREQs with 646 unsupported Certificate Types. Absent any recognized and supported 647 CERTREQs, implementations MAY treat them as if they are of a 648 supported type with the Certificate Authority field left empty, 649 depending on local policy. ISAKMP Section 5.10 "Certificate Request 650 Payload Processing" specifies additional processing. 652 3.2.8.2. Undecodable Certificate Authority Fields 654 Implementations MUST be able to deal with receiving CERTREQs with 655 undecodable Certificate Authority fields. Implementations MAY ignore 656 such payloads, depending on local policy. ISAKMP specifies other 657 actions which may be taken. 659 3.2.8.3. Ordering of Certificate Request Payloads 661 Implementations MUST NOT assume that CERTREQs are ordered in any way. 663 3.2.9. Optimizations 665 3.2.9.1. Duplicate Certificate Request Payloads 667 Implementations SHOULD NOT send duplicate CERTREQs during an 668 exchange. 670 Korver [Page 13 ] 671 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 672 5/2004 674 3.2.9.2. Name Lowest 'Common' Certification Authorities 676 When a peer's certificate keying materials have been cached, an 677 implementation can send a hint to the peer to elide some of the 678 certificates the peer would normally respond with. In addition to the 679 normal set of CERTREQs that are sent specifying the trust anchors, an 680 implementation MAY send CERTREQs containing the Issuer Name of the 681 relevant cached end entity certificates. When sending these hints, it 682 is still necessary to send the normal set of CERTREQs because the 683 hints do not sufficiently convey all of the information required by 684 the peer. Specifically, either the peer may not support this 685 optimization or there may be additional chains that could be used in 686 this context but will not be specified if only supplying the issuer 687 of the end entity certificate. 689 No special processing is required on the part of the recipient of 690 such a CERTREQ, and the end entity certificates will still be sent. 691 On the other hand, the recipient MAY elect to elide certificates 692 based on receipt of such hints. 694 CERTREQs must contain information that identifies a Certification 695 Authority certificate, which results in the peer always sending at 696 least the end entity certificate. This mechanism allows 697 implementations to determine unambiguously when a new certificate is 698 being used by the peer, perhaps because the previous certificate has 699 just expired, which will result in a failure because the needed 700 keying materials are not available to validate the new end entity 701 certificate. Implementations which implement this optimization MUST 702 recognize when the end entity certificate has changed and respond to 703 it by not performing this optimization when the exchange is 704 retried. 706 3.2.9.3. Example 708 Imagine that an implementation has previously received and cached the 709 peer certificate chain TA->CA1->CA2->EE. If during a subsequent 710 exchange this implementation sends a CERTREQ containing the Subject 711 Name in certificate TA, this implementation is requesting that the 712 peer send at least 3 certificates: CA1, CA2, and EE. On the other 713 hand, if this implementation also sends a CERTREQ containing the 714 Subject Name of CA2, the implementation is providing a hint that only 715 1 certificate needs to be sent: EE. Note that in this example, the 716 fact that TA is a trust anchor should not be construed to imply that 717 TA is a self-signed certificate. 719 3.3. Certificate Payload 721 The Certificate (CERT) Payload allows the peer to transmit a single 722 certificate or CRL. Multiple certificates should be transmitted in 724 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 725 5/2004 727 multiple payloads. However, not all certificate forms that are legal 728 in PKIX make sense in the context of IPsec. The issue of how to 729 represent IKE-meaningful name-forms in a certificate is especially 730 problematic. This memo provides a profile for a subset of PKIX that 731 makes sense for IKEv1/ISAKMP and IKEv2. 733 3.3.1. Certificate Type 735 The Certificate Type field identifies to the peer the type of 736 certificate keying materials that are included. ISAKMP defines 10 737 types of Certificate Data that can be sent and specifies the syntax 738 for these types. For the purposes of this document, only the 739 following types are relevant: 741 * X.509 Certificate - Signature 742 * Certificate Revocation List (CRL) 743 * Authority Revocation List (ARL) 744 * PKCS #7 wrapped X.509 certificate 746 The use of the other types: 748 * X.509 Certificate - Key Exchange 749 * PGP Certificate 750 * DNS Signed Key 751 * Kerberos Tokens 752 * SPKI Certificate 753 * X.509 Certificate - Attribute 755 are out of the scope of this document. 757 In addition to the above, IKEv2 adds 3 additional types which are not 758 profiled in this document: 759 * Raw RSA Key 760 * Hash and URL of X.509 certificate 761 * Hash and URL of X.509 bundle 763 3.3.2. X.509 Certificate - Signature 765 This type requests that the end entity certificate be a signing 766 certificate. 768 3.3.3. X.509 Certificate - Signature 770 This type specifies that Certificate Data contains a certificate used 771 for signing, whether an end entity signature certificate or a CA 772 signature certificate. 774 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 775 5/2004 777 3.3.4. Certificate Revocation List (CRL) 779 This type specifies that Certificate Data contains an X.509 CRL. 781 3.3.5. Authority Revocation List (ARL) 783 This type specifies that Certificate Data contains an X.509 CRL that 784 applies only to CA certificates. Recipients of this type MAY treat it 785 as synonymous with the CRL type. 787 3.3.6. PKCS #7 wrapped X.509 certificate 789 This type defines a particular encoding, not a particular certificate 790 type. Implementations SHOULD NOT generate CERTs that contain this 791 Certificate Type. Implementations SHOULD accept CERTs that contain 792 this Certificate Type because several implementations are known to 793 generate them. Note that those implementations may include entire 794 certificate hierarchies inside a single CERT PKCS #7 payload, which 795 violates the requirement specified in ISAKMP that this payload 796 contain a single certificate. 798 3.3.7. Certificate Payloads Not Mandatory 800 An implementation which does not receive any CERTREQs during an 801 exchange SHOULD NOT send any CERT payloads, except when explicitly 802 configured to proactively send CERT payloads in order to interoperate 803 with non-compliant implementations. In this case, an implementation 804 MAY send the certificate chain (not including the trust anchor) 805 associated with the end entity certificate. This MUST NOT be the 806 default behavior of implementations. 808 Implementations which are configured to expect that a peer must 809 receive certificates through out-of-band means SHOULD ignore any 810 CERTREQ messages that are received. 812 Implementations that receive CERTREQs from a peer which contain only 813 unrecognized Certification Authorities SHOULD NOT continue the 814 exchange, in order to avoid unnecessary and potentially expensive 815 cryptographic processing. 817 3.3.8. Response to Multiple Certificate Authority Proposals 819 In response to multiple CERTREQs which contain different Certificate 820 Authority identities, implementations MAY respond using an end entity 821 certificate which chains to a CA that matches any of the identities 822 provided by the peer. 824 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 825 5/2004 827 3.3.9. Using Local Keying Materials 829 Implementations MAY elect skip the processing of a given set of CERTs 830 if preferable keying materials are available. For instance, the 831 contents of a CERT may be available from a previous exchange or may 832 be available through some out-of-band means. 834 3.3.10. Robustness 836 3.3.10.1. Unrecognized or Unsupported Certificate Types 838 Implementations MUST be able to deal with receiving CERTs with 839 unrecognized or unsupported Certificate Types. Implementations MAY 840 discard such payloads, depending on local policy. ISAKMP Section 5.10 841 "Certificate Request Payload Processing" specifies additional 842 processing. 844 3.3.10.2. Undecodable Certificate Data Fields 846 Implementations MUST be able to deal with receiving CERTs with 847 undecodable Certificate Data fields. Implementations MAY discard such 848 payloads, depending on local policy. ISAKMP specifies other actions 849 which may be taken. 851 3.3.10.3. Ordering of Certificate Payloads 853 For IKEv1, implementations MUST NOT assume that CERTs are ordered in 854 any way. For IKEv2, implementations MUST NOT assume that any except 855 the first CERT is ordered in any way. IKEv2 specifies that the first 856 CERT contain the end entity certificate which is to be used to 857 authenticate the peer. 859 3.3.10.4. Duplicate Certificate Payloads 861 Implementations MUST support receiving multiple identical CERTs 862 during an exchange. 864 3.3.10.5. Irrelevant Certificates 866 Implementations MUST be prepared to receive certificates and CRLs 867 which are not relevant to the current exchange. Implementations MAY 868 discard such extraneous certificates and CRLs. 870 Implementations MAY send certificates which are irrelevant to an 871 exchange. One reason for including certificates which are irrelevant 872 to an exchange is to minimize the threat of leaking identifying 873 information in exchanges where CERT is not encrypted. It should be 874 noted, however, that this probably provides rather poor protection 876 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 877 5/2004 879 against leaking the identity. 881 Another reason for including certificates that seem irrelevant to an 882 exchange is that there may be two chains from the Certificate 883 Authority to the end entity, each of which is only valid with certain 884 validation parameters (such as acceptable policies). Since the end 885 entity doesn't know which parameters the relying party is using, it 886 should send the certs needed for both chains (even if there's only 887 one CERTREQ). 889 Although implementations SHOULD NOT send multiple end entity 890 certificates if the receipient cannot determine the correct 891 certificate to use for authentication by using either the contents of 892 the ID payload to match the certificate or, in IKEv2, the correct 893 certificate is contained in the first CERT. In other words, 894 receipients SHOULD NOT be expected to iterate over multiple end- 895 entity certs. 897 3.3.11. Optimizations 899 3.3.11.1. Duplicate Certificate Payloads 901 Implementations SHOULD NOT send duplicate CERTs during an exchange. 902 Such payloads should be suppressed. 904 3.3.11.2. Send Lowest 'Common' Certificates 906 When multiple CERTREQs are received which specify certificate 907 authorities within the end entity certificate chain, implementations 908 MAY send the shortest chain possible. However, implementations SHOULD 909 always send the end entity certificate. See section 3.2.9.2 for more 910 discussion of this optimization. 912 3.3.11.3. Ignore Duplicate Certificate Payloads 914 Implementations MAY employ local means to recognize CERTs that have 915 been received in the past, whether part of the current exchange or 916 not, for which keying material is available and may discard these 917 duplicate CERTs. 919 3.3.12. Hash Payload 921 IKEv1 specifies the optional use of the Hash Payload to carry a 922 pointer to a certificate in either of the Phase 1 public key 923 encryption modes. This pointer is used by an implementation to locate 924 the end entity certificate that contains the public key that a peer 926 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 927 5/2004 929 should use for encrypting payloads during the exchange. 931 Implementations SHOULD include this payload whenever the public 932 portion of the keypair has been placed in a certificate. 934 4. Profile of PKIX 936 Except where specifically stated in this document, implementations 937 MUST conform to the requirements of [PKIX]. 939 4.1. X.509 Certificates 941 4.1.1. Versions 943 Although PKIX states that "implementations SHOULD be prepared to 944 accept any version certificate", in practice this profile requires 945 certain extensions that necessitate the use of Version 3 certificates 946 for all but self-signed certificates used as trust anchors. 947 Implementations that conform to this document MAY therefore reject 948 Version 1 and Version 2 certificates in all other cases. 950 4.1.2. Subject Name 952 4.1.2.1. Empty Subject Name 954 Implementations MUST accept certificates which contain an empty 955 Subject Name field, as specified in PKIX. Identity information in 956 such certificates will be contained entirely in the SubjectAltName 957 extension. 959 4.1.2.2. Specifying Non-FQDN Hosts in Subject Name 961 Implementations which desire to place host names that are not 962 intended to be processed by recipients as FQDNs (for instance 963 "Gateway Router") in the Subject Name MUST use the commonName 964 attribute. 966 While nothing prevents an FQDN, USER_FQDN, or IP address information 967 from appearing somewhere in the Subject Name contents, such entries 968 MUST NOT be interpreted as identity information for the purposes of 969 matching with ID or for policy lookup. 971 4.1.2.3. Specifying FQDN Host Names in Subject Name 973 Implementations MUST NOT populate the Subject Name in place of 974 populating the dNSName field of the SubjectAltName extension. 976 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 977 5/2004 979 4.1.2.4. EmailAddress 981 As specified in PKIX, implementations MUST NOT populate 982 DistinguishedNames with the EmailAddress attribute. 984 4.1.3. X.509 Certificate Extensions 986 Conforming applications MUST recognize extensions which must or may 987 be marked critical according to this specification. These extensions 988 are: KeyUsage, SubjectAltName, and BasicConstraints. 990 Implementations SHOULD generate certificates such that the extension 991 criticality bits are set in accordance with PKIX and this document. 992 With respect to PKIX compliance, implementations processing 993 certificates MAY ignore the value of the criticality bit for 994 extensions that are supported by that implementation, but MUST 995 support the criticality bit for extensions that are not supported by 996 that implementation. That is, if an implementation supports (and thus 997 is going to process) a given extension, then it isn't necessary to 998 reject the certificate if the criticality bit is different from what 999 PKIX states it must be. However, if an implementation does not 1000 support an extension that PKIX mandates be critical, then the 1001 implementation must reject the certificate. 1003 implements bit in cert PKIX mandate behavior 1004 ------------------------------------------------------ 1005 yes true true ok 1006 yes true false ok or reject 1007 yes false true ok or reject 1008 yes false false ok 1009 no true true reject 1010 no true false reject 1011 no false true reject 1012 no false false ok 1014 4.1.3.1. AuthorityKeyIdentifier 1016 Implementations SHOULD NOT assume that other implementations support 1017 the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate 1018 certificate hierarchies which are overly complex to process in the 1019 absence of this extension, such as those that require possibly 1020 verifying a signature against a large number of similarly named CA 1021 certificates in order to find the CA certificate which contains the 1022 key that was used to generate the signature. 1024 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1025 5/2004 1027 4.1.3.2. SubjectKeyIdentifier 1029 Implementations SHOULD NOT assume that other implementations support 1030 the SubjectKeyIdentifier extension, and thus SHOULD NOT generate 1031 certificate hierarchies which are overly complex to process in the 1032 absence of this extension, such as those that require possibly 1033 verifying a signature against a large number of similarly named CA 1034 certificates in order to find the CA certificate which contains the 1035 key that was used to generate the signature. 1037 4.1.3.3. KeyUsage 1039 The meaning of the nonRepudiation bit is not defined in the context 1040 of IPsec, although implementations SHOULD interpret the 1041 nonRepudiation bit as synonymous with the digitalSignature bit. 1042 Implementations SHOULD NOT generate certificates which only assert 1043 the nonRepudiation bit. 1045 See PKIX for general guidance on which of the other KeyUsage bits 1046 should be set in any given certificate. 1048 4.1.3.4. PrivateKeyUsagePeriod 1050 PKIX recommends against the use of this extension. The 1051 PrivateKeyUsageExtension is intended to be used when signatures will 1052 need to be verified long past the time when signatures using the 1053 private keypair may be generated. Since IKE SAs are short-lived 1054 relative to the intended use of this extension in addition to the 1055 fact that each signature is validated only a single time, the 1056 usefulness of this extension in the context of IKE is unclear. 1057 Therefore, implementations MUST NOT generate certificates that 1058 contain the PrivateKeyUsagePeriod extension. 1060 4.1.3.5. Certificate Policies 1062 Many IPsec implementations do not currently provide support for the 1063 Certificate Policies extension. Therefore, implementations that 1064 generate certificates which contain this extension SHOULD mark the 1065 extension as non-critical. 1067 4.1.3.6. PolicyMappings 1069 Many implementations do not support the PolicyMappings extension. 1071 4.1.3.7. SubjectAltName 1073 Implementations SHOULD generate only the following GeneralName 1074 choices in the subjectAltName extension, as these choices map to 1076 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1077 5/2004 1079 legal Identification Payload types: rfc822Name, dNSName, or 1080 iPAddress. Although it is possible to specify any GeneralName choice 1081 in the Identification Payload by using the ID_DER_ASN1_GN ID type, 1082 implementations SHOULD NOT assume that a peer supports such 1083 functionality. 1085 4.1.3.7.1. dNSName 1087 This field MUST contain a fully qualified domain name. 1088 Implementations MUST NOT generate names that contain wildcards. 1090 Implementations MAY treat certificates that contain wildcards in this 1091 field as syntactically invalid. 1093 Although this field is in the form of an FQDN, implementations SHOULD 1094 NOT assume that this field contains an FQDN that will resolve via the 1095 DNS, unless this is known by way of some out-of-band mechanism. Such 1096 a mechanism is out of the scope of this document. Implementations 1097 SHOULD NOT treat the failure to resolve as an error. 1099 4.1.3.7.2. iPAddress 1101 Note that although PKIX permits CIDR [CIDR] notation in the "Name 1102 Constraints" extension, PKIX explicitly prohibits using CIDR notation 1103 for conveying identity information. In other words, the CIDR notation 1104 MUST NOT be used in the subjectAltName extension. 1106 4.1.3.7.3. rfc822Name 1108 Although this field is in the form of an Internet mail address, 1109 implementations SHOULD NOT assume that this field contains a valid 1110 email address, unless this is known by way of some out-of-band 1111 mechanism. Such a mechanism is out of the scope of this document. 1113 4.1.3.8. IssuerAltName 1115 Implementations SHOULD NOT assume that other implementations support 1116 the IssuerAltName extension, and especially should not assume that 1117 information contained in this extension will be displayed to end 1118 users. 1120 4.1.3.9. SubjectDirectoryAttributes 1122 The SubjectDirectoryAttributes extension is intended to contain 1123 privilege information, in a manner analogous to privileges carried in 1124 Attribute Certificates. Implementations MAY ignore this extension 1125 when it is marked non-critical, as PKIX mandates. 1127 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1128 5/2004 1130 4.1.3.10. BasicConstraints 1132 PKIX mandates that CA certificates contain this extension and that it 1133 be marked critical. Implementations SHOULD reject CA certificates 1134 that do not contain this extension. For backwards compatibility, 1135 implementations may accept such certificates if explicitly configured 1136 to do so, but the default for this setting MUST be to reject such 1137 certificates. 1139 4.1.3.11. NameConstraints 1141 Many implementations do not support the NameConstraints extension. 1142 Since PKIX mandates that this extension be marked critical when 1143 present, implementations which intend to be maximally interoperable 1144 SHOULD NOT generate certificates which contain this extension. 1146 4.1.3.12. PolicyConstraints 1148 Many implementations do not support the PolicyConstraints extension. 1149 Since PKIX mandates that this extension be marked critical when 1150 present, implementations which intend to be maximally interoperable 1151 SHOULD NOT generate certificates which contain this extension. 1153 4.1.3.13. ExtendedKeyUsage 1155 No ExtendedKeyUsage usages are defined specifically for IPsec, so if 1156 this extension is present and marked critical, use of this 1157 certificate for IPsec MUST be treated as an error unless the 1158 extension contains the anyExtendedKeyUsage keyPurposeID, which 1159 asserts that the certificate can be used for any purpose. 1160 Implementations MAY ignore this extension if it is marked non- 1161 critical. Implementations MUST NOT generate this extension in 1162 certificates which are being used for IPsec. 1164 Note that a previous proposal for the use of three ExtendedKeyUsage 1165 values is obsolete and explicitly deprecated by this specification. 1166 For historical reference, those values were id-kp-ipsecEndSystem, 1167 id- 1168 kp-ipsecTunnel, and id-kp-ipsecUser. 1170 4.1.3.14. CRLDistributionPoints 1172 Receiving CRLs in band via IKE does not alleviate the requirement to 1173 process the CRLDistributionPoints if the certificate being validated 1174 contains the extension and the CRL being used to validate the 1175 certificate contains the IssuingDistributionPoint extension. Failure 1176 to validate the CRLDistributionPoints/IssuingDistributionPoint pair 1177 can result in CRL substitution where an entity knowingly substitutes 1178 a known good CRL from a different distribution point for the CRL 1180 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1181 5/2004 1183 which is supposed to be used which would show the entity as 1184 revoked. 1186 Implementations MUST support validating that the contents of 1187 CRLDistributionPoints match those of the IssuingDistributionPoint to 1188 prevent CRL substitution when the issuing CA is using them. At least 1189 one CA is known to default to this type of CRL use. See section 1190 4.2.2.5 for more information. 1192 See PKIX docs for CRLDistributionPoints intellectual rights 1193 information. Note that both the CRLDistributionPoints and 1194 IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED 1195 by PKIX, so there is no requirement to license any IPR. 1197 4.1.3.15. InhibitAnyPolicy 1199 Many implementations do not support the InhibitAnyPolicy extension. 1200 Since PKIX mandates that this extension be marked critical when 1201 present, implementations which intend to be maximally interoperable 1202 SHOULD NOT generate certificates which contain this extension. 1204 4.1.3.16. FreshestCRL 1206 Implementations MUST NOT assume that the FreshestCRL extension will 1207 exist in peer extensions. Note that most implementations do not 1208 support delta CRLs. 1210 4.1.3.17. AuthorityInfoAccess 1212 PKIX defines the AuthorityInfoAccess extension, which is used to 1213 indicate "how to access CA information and services for the issuer of 1214 the certificate in which the extension appears." Conformant 1215 implementations MAY support this extension. 1217 4.1.3.18. SubjectInfoAccess 1219 PKIX defines the SubjectInfoAccess private certificate extension, 1220 which is used to indicate "how to access information and services for 1221 the subject of the certificate in which the extension appears." This 1222 extension has no known use in the context of IPsec. Conformant 1223 implementations SHOULD ignore this extension when present. 1225 4.2. X.509 Certificate Revocation Lists 1227 When validating certificates, implementations MUST make use of 1228 certificate revocation information, and SHOULD support such 1229 revocation information in the form of CRLs, unless non-CRL revocation 1230 information is known to be the only method for transmitting this 1232 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1233 5/2004 1235 information. Implementations MAY provide a configuration option to 1236 disable use of certain types of revocation information, but that 1237 option MUST be off by default. 1239 4.2.1. Multiple Sources of Certificate Revocation Information 1241 Implementations which support multiple sources of obtaining 1242 certificate revocation information MUST act conservatively when the 1243 information provided by these sources is inconsistent: when a 1244 certificate is reported as revoked by one trusted source, the 1245 certificate MUST be considered revoked. 1247 4.2.2. X.509 Certificate Revocation List Extensions 1249 4.2.2.1. AuthorityKeyIdentifier 1251 Implementations SHOULD NOT assume that other implementations support 1252 the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate 1253 certificate hierarchies which are overly complex to process in the 1254 absence of this extension. 1256 4.2.2.2. IssuerAltName 1258 Implementations SHOULD NOT assume that other implementations support 1259 the IssuerAltName extension, and especially should not assume that 1260 information contained in this extension will be displayed to end 1261 users. 1263 4.2.2.3. CRLNumber 1265 As stated in PKIX, all issuers conforming to PKIX MUST include this 1266 extension in all CRLs. 1268 4.2.2.4. DeltaCRLIndicator 1270 4.2.2.4.1. If Delta CRLs Are Unsupported 1272 Implementations that do not support delta CRLs MUST reject CRLs 1273 which 1274 contain the DeltaCRLIndicator (which MUST be marked critical 1275 according to PKIX) and MUST make use of a base CRL if it is 1276 available. Such implementations MUST ensure that a delta CRL does not 1277 "overwrite" a base CRL, for instance in the keying material database. 1279 4.2.2.4.2. Delta CRL Recommendations 1281 Since some implementations that do not support delta CRLs may behave 1282 incorrectly or insecurely when presented with delta CRLs, 1283 implementations SHOULD consider whether issuing delta CRLs 1284 increases 1286 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1287 5/2004 1289 security before issuing such CRLs. 1291 The authors are aware of several implementations which behave in an 1292 incorrect or insecure manner when presented with delta CRLs. See 1293 Appendix B for a description of the issue. Therefore, this 1294 specification RECOMMENDS against issuing delta CRLs at this time. On 1295 the other hand, failure to issue delta CRLs exposes a larger window 1296 of vulnerability. See the Security Considerations section of PKIX for 1297 additional discussion. Implementors as well as administrators are 1298 encouraged to consider these issues. 1300 4.2.2.5. IssuingDistributionPoint 1302 A CA that is using CRLDistributionPoints may do so to provide many 1303 "small" CRLs, each only valid for a particular set of certificates 1304 issued by that CA. To associate a CRL with a certificate, the CA 1305 places the CRLDistributionPoints extension in the certificate, and 1306 places the IssuingDistributionPoint in the CRL. The 1307 distributionPointName field in the CRLDistributionPoints extension 1308 MUST be identical to the distributionPoint field in the 1309 IssuingDistributionPoint extension. At least one CA is known to 1310 default to this type of CRL use. See section 4.1.3.14 for more 1311 information. 1313 4.2.2.6. FreshestCRL 1315 Given the recommendations against implementations generating delta 1316 CRLs, this specification RECOMMENDS that implementations do not 1317 populate CRLs with the FreshestCRL extension, which is used to obtain 1318 delta CRLs. 1320 5. Configuration Data Exchange Conventions 1322 Below we present a common format for exchanging configuration data. 1323 Implementations MUST support these formats, MUST support arbitrary 1324 whitespace at the beginning and end of any line, MUST support 1325 arbitrary line lengths although they SHOULD generate lines less than 1326 76 characters, and MUST support the following three line-termination 1327 disciplines: LF (US-ASCII 10), CR (US-ASCII 13), and CRLF. 1329 5.1. Certificates 1331 Certificates MUST be Base64 encoded and appear between the following 1332 delimiters: 1334 -----BEGIN CERTIFICATE----- 1336 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1337 5/2004 1339 -----END CERTIFICATE----- 1341 5.2. Public Keys 1343 Implementations MUST support two forms of public keys: certificates 1344 and so-called "raw" keys. Certificates should be transferred in the 1345 same form as above. A raw key is only the SubjectPublicKeyInfo 1346 portion of the certificate, and MUST be Base64 encoded and appear 1347 between the following delimiters: 1349 -----BEGIN PUBLIC KEY----- 1351 -----END PUBLIC KEY----- 1353 5.3. PKCS#10 Certificate Signing Requests 1355 A PKCS#10 [PKCS-10] Certificiate Signing Request MUST be Base64 1356 encoded and appear between the following delimeters: 1358 -----BEGIN CERTIFICATE REQUEST----- 1360 -----END CERTIFICATE REQUEST----- 1362 6. Security Considerations 1364 6.1. Identification Payload 1366 Depending on the exchange type, ID may be passed in the clear. 1367 Administrators in some environments may wish to use the empty 1368 Certification Authority option to prevent such information from 1369 leaking, at the possible cost of some performance, although such use 1370 is discouraged. 1372 6.2. Certificate Request Payload 1374 The Contents of CERTREQ are not encrypted in IKE. In some 1375 environments this may leak private information. Administrators in 1376 some environments may wish to use the empty Certification Authority 1377 option to prevent such information from leaking, at the cost of 1378 performance. 1380 6.3. Certificate Payload 1382 Depending on the exchange type, CERTs may be passed in the clear and 1383 therefore may leak identity information. 1385 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1386 5/2004 1388 6.4. IKEv1 Main Mode 1390 Implementations may not wish to respond with CERTs in the second 1391 message, thereby violating the identity protection feature of Main 1392 Mode in IKEv1. CERTs may be included in any message, and therefore 1393 implementations may wish to respond with CERTs in a message that 1394 offers privacy protection in this case. 1396 7. Intellectual Property Rights 1398 No new intellectual property rights are introduced by this 1399 document. 1401 8. IANA Considerations 1403 There are no known numbers which IANA will need to manage. 1405 9. Normative References 1407 [DOI] Piper, D., "The Internet IP Security Domain of 1408 Interpretation for ISAKMP", RFC 2407, November 1998. 1410 [IKEv1] Harkins, D. and Carrel, D., "The Internet Key Exchange 1411 (IKE)", RFC 2409, November 1998. 1413 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1414 draft-ietf-ipsec-ikev2-13.txt, March 2004, work in progress. 1416 [IPSEC] Kent, S. and Atkinson, R., "Security Architecture for the 1417 Internet Protocol", RFC 2401, November 1998. 1419 [ISAKMP] Maughan, D., et. al., "Internet Security Association and 1420 Key Management Protocol (ISAKMP)", RFC 2408, November 1998. 1422 [PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax 1423 Version 1.5", RFC 2314, March 1998. 1425 [PKIX] Housley, R., et al., "Internet X.509 Public Key 1426 Infrastructure Certificate and Certificate Revocation 1427 List (CRL) Profile", RFC 3280, April 2002. 1429 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1430 September 1981. 1432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1433 Requirement Levels", BCP 14, RFC 2119, March 1997. 1435 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1436 5/2004 1438 10. Informational References 1440 [CIDR] Fuller, V., et al., "Classless Inter-Domain Routing (CIDR): 1441 An Address Assignment and Aggregation Strategy", RFC 1519, 1442 September 1993. 1444 [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", 1445 RFC 2535, March 1999. 1447 [RFC1883] Deering, S. and Hinden, R. "Internet Protocol, Version 6 1448 (IPv6) Specification", RFC 1883, December 1995. 1450 [ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap", 1451 draft-ietf-pkix-roadmap-08.txt. 1453 [SBGP] Lynn, C., Kent, S., and Seo, K., "X.509 Extensions for 1454 IP Addresses and AS Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-00.txt. 1456 11. Acknowledgements 1458 The authors would like to acknowledge the expired draft-ietf-ipsec- 1459 pki-req-05.txt for providing valuable materials for this document. 1460 The authors would like to especially thank Greg Carter, Russ Housley, 1461 Steve Hanna, and Gregory Lebovitz for their valuable comments, some 1462 of which have been incorporated unchanged into this document. 1464 12. Author's Addresses 1466 Brian Korver 1467 Xythos Software, Inc. 1468 One Bush Street, Suite 600 1469 San Francisco, CA 94104 1470 USA 1471 Phone: +1 415 248-3800 1472 EMail: briank@xythos.com 1474 Copyright (C) The Internet Society (2004). All Rights Reserved. 1476 This document and translations of it may be copied and furnished to 1477 others, and derivative works that comment on or otherwise explain it 1478 or assist in its implementation may be prepared, copied, published 1479 and distributed, in whole or in part, without restriction of any 1480 kind, provided that the above copyright notice and this paragraph are 1481 included on all such copies and derivative works. However, this 1482 document itself may not be modified in any way, such as by removing 1483 the copyright notice or references to the Internet Society or other 1484 Internet organizations, except as needed for the purpose of 1485 developing Internet standards in which case the procedures for 1487 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1488 5/2004 1490 copyrights defined in the Internet Standards process must be 1491 followed, or as required to translate it into languages other than 1492 English. 1494 The limited permissions granted above are perpetual and will not be 1495 revoked by the Internet Society or its successors or assigns. 1497 This document and the information contained herein is provided on an 1498 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1499 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1500 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1501 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1502 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1504 Acknowledgement 1506 Funding for the RFC Editor function is currently provided by the 1507 Internet Society. 1509 Appendix A. Change History 1511 * May 2004 (renamed draft-ietf-pki4ipsec-ikecert-profile-00.txt) 1513 Made it clearer that the format of the ID_IPV4_ADDR payload comes 1514 from RFC791 and is nothing new. (Tero Kivinen Feb 29) 1516 Permit implementations to skip verifying that the peer source 1517 address matches the contents of ID_IPV{4,6}_ADDR. (Tero Kivinen 1518 Feb 29, Gregory Lebovitz Feb 29) 1520 Removed paragraph suggesting that implementations favor 1521 unauthenticated peer source addresses over an unauthenticated ID 1522 for initial policy lookup. (Tero Kivinen Feb 29, Gregory Lebovitz 1523 Feb 29) 1525 Removed some text implying RSA encryption mode was in scope. (Tero 1526 Kivinen Feb 29) 1528 Relaxed deprecation of PKCS#7 CERT payloads. (Tero Kivinen Feb 29) 1530 Made it clearer that out-of-scope local heuristics should be used 1531 for picking an EE cert to use when generating CERTREQ, not when 1532 receiving CERTREQ. (Tero Kivinen Feb 29) 1534 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1535 5/2004 1537 Made it clearer that CERT processing can be skipped when the 1538 contents of a CERT are already known. (Tero Kivinen Feb 29) 1540 Implementations SHOULD generate BASE64 lines less than 76 1541 characters. (Tero Kivinen Feb 29) 1543 Added "Except where specifically stated in this document, 1544 implementations MUST conform to the requirements of PKIX" (Steve 1545 Hanna Oct 7, 2003) 1547 RECOMMENDS against populating the ID payload with IP addresses due 1548 to interoperability issues such as problem with NAT traversal. 1549 (Gregory Lebovitz May 14) 1551 Changed "as revoked by one source" to "as revoked by one trusted 1552 source". (Michael Myers, May 15) 1554 Specifying Certificate Authorities section needed to be 1555 regularized with Gregory Lebovitz's CERT proposal from -04. (Tylor 1556 Allison, May 15) 1558 Added text specifying how receipients SHOULD NOT be expected to 1559 iterate over multiple end-entity certs. (Tylor Allison, May 15) 1561 Modified text to refer to IKEv2 as well as IKEv1/ISAKMP where 1562 relevant. 1564 IKEv2: Explained that IDr sent by responder doesn't have to match 1565 the [IDr] sent initiator in second exchange. 1567 IKEv2: Noted that "The identity ... does not necessarily have to 1568 match anything in the CERT payload" (S3.5) is not contradicted by 1569 SHOULD in this document. 1571 IKEv2: Noted that ID_USER_FQDN renamed to ID_RFC822_ADDR, and 1572 ID_USER_FQDN would be used exclusively in this document. 1574 IKEv2: Declared that 3 new CERTREQ and CERT types are not profiled 1575 in this document (well, at least not yet, pending WG discussion of 1576 what to do -- note that they are only SHOULDs in IKEv2). 1578 IKEv2: Noted that CERTREQ payload changed from DN to SHA-1 of 1579 SubjectPublicKeyInfo. 1581 IKEv2: Noted new requirement that specifies that the first 1582 certificate sent MUST be the EE cert (section 3.6). 1584 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1585 5/2004 1587 * February 2004 (-04) 1589 Minor editorial changes to clean up language 1591 Deprecate in-band exchange of CRLs 1593 Incorporated Gregory Lebovitz's proposal for CERT payloads: 1594 "should deal with all the CRL, Intermediat Certs, Trust Anchors, 1595 etc OOB of IKE; MUST be able to send and receive EE cert payload; 1596 only real exception is Intermediate Cets which MAY be sent and 1597 SHOULD be able to be receivable (but in reality there are very few 1598 hierarchies in operation, so really it's a corner case); SHOULD 1599 NOT send the other stuff (CRL, Trust Anchors, etc) in cert 1600 payloads in IKE; SHOULD be able to accept the other stuff if by 1601 chance it gets sent, though we hope they don't get sent" 1603 Incorporated comments contained in Oct 7, 2003 email from 1604 steve.hanna@sun.com to ipsec@lists.tislabs.com 1606 Moved text from "Profile of ISAKMP" Background section to each 1607 payload section (removing duplication of these sections) 1609 Removed "Certificate-Related Playloads in ISAKMP" section since it 1610 was not specific to IKE. 1612 Incorporated Gregory Lebovitz's table in the "Identification 1613 Payload" section 1615 Moved text from "binding identity to policy" sections to each 1616 payload section 1618 Moved text from "IKE" section into now-combined "IKE/ISAKMP" 1619 section 1621 ID_USER_FQDN and ID_FQDN promoted to MUST from MAY 1623 Promoted sending ID_DER_ASN1_DN to MAY from SHOULD NOT, and 1624 receiving from MUST from MAY 1626 Demoted ID_DER_ASN1_GN to MUST NOT 1628 Demoted populating Subject Name in place of populating the dNSName 1629 from SHOULD NOT to MUST NOT and removed the text regarding 1630 domainComponent 1632 Revocation information checking MAY now be disabled, although not 1633 by default 1635 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1636 5/2004 1638 Aggressive Mode removed from this profile 1640 * June 2003 (-03) 1642 Minor editorial changes to clean up language 1644 Minor additional clarifying text 1646 Removed hyphenation 1648 Added requirement that implementations support configuration data 1649 exchange having arbitrary line lengths 1651 * February 2003 (-02) 1653 Word choice: move from use of "root" to "trust anchor", in 1654 accordance with PKIX 1656 SBGP note and reference for placing address subnet and range 1657 information into certificates 1659 Clarification of text regarding placing names of hosts into the 1660 Name commonName attribute of SubjectName 1662 Added table to clarify text regarding processing of the 1663 certificate extension criticality bit 1665 Added text underscoring processing requirements for 1666 CRLDistributionPoints and IssuingDistributionPoint 1668 * October 2002, Reorganization (-01) 1669 * June 2002, Initial Draft (-00) 1671 Appendix B. The Possible Dangers of Delta CRLs 1673 The problem is that the CRL processing algorithm is sometimes written 1674 incorrectly with the assumption that all CRLs are base CRLs and it is 1675 assumed that CRLs will pass content validity tests. Specifically, 1676 such implementations fail to check the certificate against all 1677 possible CRLs: if the first CRL that is obtained from the keying 1678 material database fails to decode, no further revocation checks are 1679 performed for the relevant certificate. This problem is compounded by 1681 Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 1682 5/2004 1684 the fact that implementations which do not understand delta CRLs may 1685 fail to decode such CRLs due to the critical DeltaCRLIndicator 1686 extension. The algorithm that is implemented in this case is 1687 approximately: 1689 fetch newest CRL 1690 check validity of CRL signature 1691 if CRL signature is valid then 1692 if CRL does not contain unrecognized critical extensions 1693 and certificate is on CRL then 1694 set certificate status to revoked 1696 The authors note that a number of PKI toolkits do not even provide a 1697 method for obtaining anything but the newest CRL, which in the 1698 presence of delta CRLs may in fact be a delta CRL, not a base CRL. 1700 Note that the above algorithm is dangerous in many ways. See PKIX 1701 for the correct algorithm.