idnits 2.17.1 draft-ietf-ipsec-pki-profile-04.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 32) being 2109 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 140 instances of too long lines in the document, the longest one being 73 characters in excess of 72. == There are 1 instance 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 932 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 290 -- Looks like a reference, but probably isn't: '2' on line 292 -- Looks like a reference, but probably isn't: '3' on line 297 == Unused Reference: 'ROADMAP' is defined on line 1364, 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. 'IKE') (Obsoleted by 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX' -- 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: A later version (-03) exists of draft-ietf-pkix-x509-ipaddr-as-extn-00 Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Brian Korver 2 Xythos Software 3 Eric Rescorla 4 INTERNET-DRAFT RTFM, Inc. 5 Feb 2004 (Expires Jul 2004) 7 The Internet IP Security PKI Profile of IKE/ISAKMP and PKIX 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 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. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 ISAKMP and PKIX both provide frameworks that must be profiled for use 32 in a given application. This document provides a profile of ISAKMP 33 and PKIX that defines the requirements for using PKI technology in 34 the context of IPsec. The document complements protocol 35 specifications such as IKE, which assume the existence of public key 36 certificates and related keying materials, but which do not address 37 PKI issues explicitly. This document addresses those issues. 39 Table of Contents 41 1 Introduction 4 42 2 Terms and Definitions 5 43 3 Profile of IKE/ISAKMP 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 8 49 Korver, Rescorla [Page 1]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 51 3.1.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_A... 9 52 3.1.5 ID_DER_ASN1_DN 9 53 3.1.6 ID_DER_ASN1_GN 10 54 3.1.7 ID_KEY_ID 10 55 3.1.8 Selecting an Identity from a Certificate 10 56 3.1.9 Transitively Binding Identity to Policy 10 57 3.2 Certificate Request Payload 10 58 3.2.1 Certificate Type 11 59 3.2.2 X.509 Certificate - Signature 11 60 3.2.3 Certificate Revocation List (CRL) 11 61 3.2.4 Authority Revocation List (ARL) 11 62 3.2.5 PKCS #7 wrapped X.509 certificate 12 63 3.2.6 Presence or Absence of Certificate Request Payloads 12 64 3.2.7 Certificate Requests 12 65 3.2.7.1 Specifying Certificate Authorities 12 66 3.2.7.2 Empty Certificate Authority Field 12 67 3.2.8 Robustness 13 68 3.2.8.1 Unrecognized or Unsupported Certificate Types 13 69 3.2.8.2 Undecodable Certificate Authority Fields 13 70 3.2.8.3 Ordering of Certificate Request Payloads 13 71 3.2.9 Optimizations 13 72 3.2.9.1 Duplicate Certificate Request Payloads 13 73 3.2.9.2 Name Lowest 'Common' Certification Authorities 13 74 3.2.9.3 Example 14 75 3.3 Certificate Payload 14 76 3.3.1 Certificate Type 14 77 3.3.2 X.509 Certificate - Signature 15 78 3.3.3 Certificate Revocation List (CRL) 15 79 3.3.4 Authority Revocation List (ARL) 15 80 3.3.5 PKCS #7 wrapped X.509 certificate 15 81 3.3.6 Certificate Payloads Not Mandatory 15 82 3.3.7 Response to Multiple Certificate Authority Proposals 16 83 3.3.8 Using Local Keying Materials 16 84 3.3.9 Robustness 16 85 3.3.9.1 Unrecognized or Unsupported Certificate Types 16 86 3.3.9.2 Undecodable Certificate Data Fields 16 87 3.3.9.3 Ordering of Certificate Payloads 16 88 3.3.9.4 Duplicate Certificate Payloads 17 89 3.3.9.5 Irrelevant Certificates 17 90 3.3.10 Optimizations 17 91 3.3.10.1 Duplicate Certificate Payloads 17 92 3.3.10.2 Send Lowest 'Common' Certificates 17 93 3.3.10.3 Ignore Duplicate Certificate Payloads 17 94 3.3.11 Hash Payload 18 95 4 Profile of PKIX 18 96 4.1 X.509 Certificates 18 97 4.1.1 Versions 18 98 4.1.2 Subject Name 18 100 Korver, Rescorla [Page 2]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 102 4.1.2.1 Empty Subject Name 18 103 4.1.2.2 Specifying Non-FQDN Hosts in Subject Name 18 104 4.1.2.3 Specifying FQDN Host Names in Subject Name 19 105 4.1.2.4 EmailAddress 19 106 4.1.3 X.509 Certificate Extensions 19 107 4.1.3.1 AuthorityKeyIdentifier 19 108 4.1.3.2 SubjectKeyIdentifier 20 109 4.1.3.3 KeyUsage 20 110 4.1.3.4 PrivateKeyUsagePeriod 20 111 4.1.3.5 Certificate Policies 20 112 4.1.3.6 PolicyMappings 20 113 4.1.3.7 SubjectAltName 21 114 4.1.3.7.1 dNSName 21 115 4.1.3.7.2 iPAddress 21 116 4.1.3.7.3 rfc822Name 21 117 4.1.3.8 IssuerAltName 21 118 4.1.3.9 SubjectDirectoryAttributes 22 119 4.1.3.10 BasicConstraints 22 120 4.1.3.11 NameConstraints 22 121 4.1.3.12 PolicyConstraints 22 122 4.1.3.13 ExtendedKeyUsage 22 123 4.1.3.14 CRLDistributionPoints 23 124 4.1.3.15 InhibitAnyPolicy 23 125 4.1.3.16 FreshestCRL 23 126 4.1.3.17 AuthorityInfoAccess 23 127 4.1.3.18 SubjectInfoAccess 23 128 4.2 X.509 Certificate Revocation Lists 24 129 4.2.1 Multiple Sources of Certificate Revocation Informati... 24 130 4.2.2 X.509 Certificate Revocation List Extensions 24 131 4.2.2.1 AuthorityKeyIdentifier 24 132 4.2.2.2 IssuerAltName 24 133 4.2.2.3 CRLNumber 24 134 4.2.2.4 DeltaCRLIndicator 24 135 4.2.2.4.1 If Delta CRLs Are Unsupported 25 136 4.2.2.4.2 Delta CRL Recommendations 25 137 4.2.2.5 IssuingDistributionPoint 25 138 4.2.2.6 FreshestCRL 25 139 5 Configuration Data Exchange Conventions 25 140 5.1 Certificates 26 141 5.2 Public Keys 26 142 5.3 PKCS#10 Certificate Signing Requests 26 143 6 Security Considerations 26 144 6.1 Identity Payload 26 145 6.2 Certificate Request Payload 27 146 6.3 Certificate Payload 27 147 6.4 IKE Main Mode 27 148 7 Intellectual Property Rights 27 149 8 IANA Considerations 27 151 Korver, Rescorla [Page 3]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 153 9 Normative References 27 154 10 Informational References 28 155 11 Acknowledgements 28 156 12 Author's Addresses 28 158 1. Introduction 160 IKE [IKE] and ISAKMP [ISAKMP] provide a secure key exchange mechanism 161 for use with IPsec [IPSEC]. In many cases the peers authenticate 162 using digital certificates as specified in PKIX [PKIX]. 163 Unfortunately, the combination of these standards leads to an 164 underspecified set of requirements for the use of certificates in the 165 context of IPsec. 167 ISAKMP references PKIX but in many cases merely specifies the 168 contents of various messages without specifying their syntax or 169 semantics. Meanwhile, PKIX provides a large set of certificate 170 mechanisms which are generally applicable for Internet protocols, but 171 little specific guidance for IPsec. Given the numerous underspecified 172 choices, interoperability is hampered if all implementors do not make 173 similar choices, or at least fail to account for implementations 174 which have chosen differently. 176 This profile of the ISAKMP and PKIX frameworks is intended to provide 177 an agreed-upon standard for using PKI technology in the context of 178 IPsec by profiling the PKIX framework for use with ISAKMP and IPsec, 179 and by documenting the contents of the relevant ISAKMP payloads and 180 further specifying their semantics. 182 In addition to providing a profile of ISAKMP and PKIX, this document 183 attempts to incorporate lessons learned from recent experience with 184 both implementation and deployment, as well as the current state of 185 related protocols and technologies. 187 Material from ISAKMP and PKIX is not repeated here, and readers of 188 this document are assumed to have read and understood both documents. 189 The requirements and security aspects of those documents are fully 190 relevant to this document as well. 192 This document is organized as follows. Section 2 defines special 193 terminology used in the rest of this document, Section 3 provides the 194 profile of IKE/ISAKMP and Section 4 provides the profile of PKIX. 195 Section 5 covers conventions for the out-of-band exchange of keying 196 materials for configuration purposes. 198 This document is being discussed on the pki4ipsec@icsalabs.com 199 mailing list. 201 Korver, Rescorla [Page 4]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 203 2. Terms and Definitions 205 Except for those terms which are defined immediately below, all terms 206 used in this document are defined in either the PKIX, ISAKMP, or DOI 207 [DOI] documents. 209 * Peer source address: The source address in packets from a peer. 210 This address may be different from any addresses asserted as the 211 "identity" of the peer. 212 * FQDN: Fully qualified domain name. 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in RFC-2119 [RFC2119]. 218 3. Profile of IKE/ISAKMP 220 3.1. Identification Payload 222 The Identification (ID) Payload is used to indicate the identity that 223 the agent claims to be speaking for. The receiving agent can then use 224 the ID as a lookup key for policy and whatever certificate store or 225 directory that it has available. Our primary concern in this document 226 is to profile the ID payload so that it can be safely used to 227 generate or lookup policy. IKE mandates the use of the ID payload in 228 Phase 1. 230 The [DOI] defines the 11 types of Identification Data that can be 231 used and specifies the syntax for these types. These are discussed 232 below in detail. 234 The ID payload requirements in this document cover only the portion 235 of the explicit policy checks that deal with the Identity Payload 236 specifically. For instance, in the case where ID does not contain an 237 IP address, checks such as verifying that the peer source address is 238 permitted by the relevant policy are not addressed here as they are 239 out of the scope of this document. 241 Implementations SHOULD populate ID with identity information that is 242 contained within the end entity certificate. This enables recipients 243 to use ID as a lookup key to find the peer end entity certificate. 244 The only case where implementations MAY populate ID with information 245 that is not contained in the end entity certificate is when ID 246 contains the peer source address (a single address, not a subnet or 247 range). This means that implementations MUST be able to map a peer 248 source address to a peer end entity certificate, even when the 249 certificate does not contain that address. The exact method for 250 performing this mapping is out of the scope of this document. 252 Korver, Rescorla [Page 5]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 254 Because implementations may use ID as a lookup key to determine which 255 policy to use, all implementations MUST be especially careful to 256 verify the truthfulness of the contents by verifying that they 257 correspond to some keying material demonstrably held by the peer. 258 Failure to do so may result in the use of an inappropriate or 259 insecure policy. The following sections describe the methods for 260 performing this binding. 262 The following table summarizes the binding of the Identification 263 Payload to the contents of end-entity certificates and of identity 264 information to policy. 266 ID type | Support | Correspond | Cert | SPD lookup 267 | for send | PKIX Attrib | matching | rules 268 ------------------------------------------------------------------- 269 | | | | 270 IP*_ADDR | MUST [1] | SubjAltName | MUST [2] | MUST [3] 271 | | iPAddress | | 272 | | | | 273 FQDN | MUST [1] | SubjAltName | MUST [2] | MUST [3] 274 | | dNSName | | 275 | | | | 276 USER_FQDN| MUST [1] | SubjAltName | MUST [2] | MUST [3] 277 | | rfc822Name | | 278 | | | | 279 DN | MUST [1] | Entire | MUST [2] | MUST support lookup 280 | | Subject, | | on any combination 281 | | bitwise | | of C, CN, O, or OU 282 | | compare | | 283 | | | | 284 IP range | MUST NOT | n/a | n/a | n/a 285 | | | | 286 | | | | 287 KEY_ID | MUST NOT | n/a | n/a | n/a 288 | | | | 290 [1] = MUST be able to send based on local configuration. 292 [2] = The ID in the ID payload MUST match the contents of the 293 corresponding field (listed) in the certificate exactly, with no 294 other lookup. The matched ID MAY be used for SPD lookup, but is 295 not required to be used for this. 297 [3] = MUST be able to support exact matching in the SPD, but MAY 298 also support substring or wildcard matches. 300 When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, 301 implementations MUST be configurable to send the same string as 303 Korver, Rescorla [Page 6]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 305 appears in the corresponding SubjectAltName attribute. Recipients MAY 306 use wildcards to do the SPD matching. 308 When sending a DN as ID, implementations MUST send the entire DN in 309 ID. Recipients MAY perform SPD lookup based on some combination of C, 310 CN, O, OU. Implementations MUST at a minimum be configurable to match 311 on any combination of those 4 attributes. Implementations MAY support 312 matching using other DN attributes in any combination, including the 313 entire DN. 315 3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR 317 Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR 318 ID type. These addresses MUST be stored in "network byte order," as 319 specified in [RFC791]. The least significant bit (LSB) of each octet 320 is the LSB of the corresponding byte in the network address. For the 321 ID_IPV4_ADDR type, the payload MUST contain exactly four octets 322 [RFC791]. For the ID_IPV6_ADDR type, the payload MUST contain exactly 323 sixteen octets [RFC1883]. When comparing the contents of ID with the 324 iPAddress field in the subjectAltName extension for equality, binary 325 comparison MUST be performed. 327 Implementations MUST verify that the address contained in ID is the 328 same as the peer source address. If the end entity certificate 329 contains address identities, then the peer source address must match 330 at least one of those identities. If either of the above do not 331 match, this MUST be treated as an error and security association 332 setup MUST be aborted. This event SHOULD be auditable. In addition, 333 implementations MUST allow administrators to configure a local policy 334 that requires that the peer source address exist in the certificate. 335 Implementations SHOULD allow administrators to configure a local 336 policy that does not enforce this requirement. 338 Implementations MAY use the IP address found in the header of packets 339 received from the peer to lookup the policy, but such implementations 340 MUST still perform verification of the ID payload. Although packet IP 341 addresses are inherently untrustworthy and must therefore be 342 independently verified, it is often useful to use the apparent IP 343 address of the peer to locate a general class of policies that will 344 be used until the mandatory identity-based policy lookup can be 345 performed. 347 For instance, if the IP address of the peer is unrecognized, a VPN 348 gateway device might load a general "road warrior" policy that 349 specifies a particular CA that is trusted to issue certificates which 350 contain a valid rfc822Name which can be used by that implementation 352 Korver, Rescorla [Page 7]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 354 to perform authorization based on access control lists (ACLs) after 355 the peer's certificate has been validated. The rfc822Name can then be 356 used to determine the policy that provides specific authorization to 357 access resources (such as IP addresses, ports, and so forth). 359 As another example, if the IP address of the peer is recognized to be 360 a known peer VPN endpoint, policy may be determined using that 361 address, but until the identity (address) is validated by validating 362 the peer certificate, the policy MUST NOT be used to authorize any 363 IPsec traffic. Whether the address need appear as an identity in the 364 certificate is a matter of local policy, and SHOULD be configurable 365 by an administrator. 367 As a general comment, however, it may be easier to spoof the contents 368 of an ID payload than it is to spoof a peer source address because 369 the peer source address must exist on the route to the peer, while ID 370 can contain essentially random identification information. 371 Implementations MUST validate the Identity Data provided by a peer, 372 but implementations MAY wish to favor unauthenticated peer source 373 addresses over an unauthenticated ID for initial policy lookup. 375 3.1.2. ID_FQDN 377 Implementations MUST support the ID_FQDN ID type, generally to 378 support host-based access control lists for hosts without fixed IP 379 addresses. However, implementations SHOULD NOT use the DNS to map the 380 FQDN to IP addresses for input into any policy decisions, unless that 381 mapping is known to be secure, such as when [DNSSEC] is employed. 382 When comparing the contents of ID with the dNSName field in the 383 subjectAltName extension for equality, caseless string comparison 384 MUST be performed. Substring, wildcard, or regular expression 385 matching MUST NOT be performed. 387 Implementations MUST verify that the identity contained in the ID 388 payload matches identity information contained in the peer end entity 389 certificate, in the subjectAltName extension. If there is not a 390 match, this MUST be treated as an error and security association 391 setup MUST be aborted. This event SHOULD be auditable. 393 3.1.3. ID_USER_FQDN 395 Implementations MUST support the ID_USER_FQDN ID type, generally to 396 support user-based access control lists for users without fixed IP 397 addresses. However, implementations SHOULD NOT use the DNS to map the 398 FQDN portion to IP addresses for input into any policy decisions, 399 unless that mapping is known to be secure, such as when [DNSSEC] is 400 employed. When comparing the contents of ID with the rfc822Name field 401 in the subjectAltName extension for equality, caseless string 403 Korver, Rescorla [Page 8]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 405 comparison MUST be performed. Substring, wildcard, or regular 406 expression matching MUST NOT be performed. 408 Implementations MUST verify that the identity contained in the ID 409 payload matches identity information contained in the peer end entity 410 certificate, in the subjectAltName extension. If there is not a 411 match, this MUST be treated as an error and security association 412 setup MUST be aborted. This event SHOULD be auditable. 414 3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, 415 ID_IPV6_ADDR_RANGE 417 As there is currently no standard method for putting address subnet 418 or range identity information into certificates, the use of these ID 419 types is currently undefined. Implementations MUST NOT generate these 420 ID types. 422 Note that work in [SBGP] for defining blocks of addresses using 423 the certificate extension identified by 425 id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } 427 is experimental at this time. 429 3.1.5. ID_DER_ASN1_DN 431 Implementations MUST support receiving the ID_DER_ASN1_DN ID type. 432 Implementations MAY generate this type. Implementations which 433 generate this type MUST populate the contents of ID with the Subject 434 Name from the end entity certificate, and MUST do so such that a 435 binary comparison of the two will succeed. For instance, if the 436 certificate was erroneously created such that the encoding of the 437 Subject Name DN varies from the constraints set by DER, that non- 438 conformant DN MUST be used to populate the ID payload: in other 439 words, implementations MUST NOT re-encode the DN for the purposes of 440 making it DER if it does not appear in the certificate as DER. 441 Implementations MUST NOT populate ID with the Subject Name from the 442 end entity certificate if it is empty, as described in the "Subject" 443 section of PKIX. 445 Implementations MUST verify that the identity contained in the ID 446 payload matches identity information contained in the peer end entity 447 certificate, in the Subject Name field. If there is not a match, this 448 MUST be treated as an error and security association setup MUST be 449 aborted. This event SHOULD be auditable. 451 Korver, Rescorla [Page 9]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 453 3.1.6. ID_DER_ASN1_GN 455 Implementations MUST NOT generate this type. 457 3.1.7. ID_KEY_ID 459 The ID_KEY_ID type used to specify pre-shared keys and thus is out of 460 scope. 462 3.1.8. Selecting an Identity from a Certificate 464 Implementations MUST support certificates that contain more than a 465 single identity. In many cases a certificate will contain an identity 466 such as an IP address in the subjectAltName extension in addition to 467 a non-empty Subject Name. 469 Which identity an implementation chooses to populate ID with is a 470 local matter. For compatibility with non-conformant implementations, 471 implementations SHOULD populate ID with whichever identity is likely 472 to be named in the peer's policy. In practice, this generally means 473 IP address, FQDN, or USER-FQDN. 475 3.1.9. Transitively Binding Identity to Policy 477 In the presence of certificates that contain multiple identities, 478 implementations SHOULD NOT assume that a peer will choose the most 479 appropriate identity with which to populate ID. Therefore, when 480 determining the appropriate policy, implementations SHOULD select the 481 most appropriate identity to use from the identities contained in the 482 certificate. 484 For example, imagine that a peer is configured with a certificate 485 that contains both a non-empty Subject Name and an dNSName. 486 Independent of which identity is used to populate ID, the host 487 implementation MUST locate the proper policy. For instance, if ID 488 contains the peer Subject Name, then the peer end entity certificate 489 may be found using the Subject Name as a key. Once the certificate 490 has been located and then validated, the dNSName in the certificate 491 can be used to locate the appropriate policy. In other words, the 492 Subject Name is used to find the certificate, the certificate 493 contains the dNSName, and the dNSName is used to lookup policy. 495 3.2. Certificate Request Payload 497 The Certificate Request (CERTREQ) Payload allows an ISAKMP 498 implementation to request that a peer provide some set of 500 Korver, Rescorla [Page 10]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 502 certificates or certificate revocation lists. It is not clear from 503 ISAKMP exactly how that set should be specified or how the peer 504 should respond. We describe the semantics on both sides. 506 3.2.1. Certificate Type 508 The Certificate Type field identifies to the peer the type of 509 certificate keying materials that are desired. ISAKMP defines 10 510 types of Certificate Data that can be requested and specifies the 511 syntax for these types. For the purposes of this document, only the 512 following types are relevant: 514 * X.509 Certificate - Signature 515 * Certificate Revocation List (CRL) 516 * Authority Revocation List (ARL) 517 * PKCS #7 wrapped X.509 certificate 519 The use of the other types: 521 * X.509 Certificate - Key Exchange 522 * PGP Certificate 523 * DNS Signed Key 524 * Kerberos Tokens 525 * SPKI Certificate 526 * X.509 Certificate - Attribute 528 are out of the scope of this document. 530 3.2.2. X.509 Certificate - Signature 532 This type requests that the end entity certificate be a signing 533 certificate. Implementations that receive CERTREQs which contain this 534 ID type in a context in which end entity signature certificates are 535 not used SHOULD ignore such CERTREQs. 537 3.2.3. Certificate Revocation List (CRL) 539 ISAKMP does not support Certificate Payload sizes over approximately 540 64K, which is too small for many CRLs. For this and other reasons, 541 implementations SHOULD NOT generate CERTREQs where the Certificate 542 Type is "Certificate Revocation List (CRL)". Upon receipt of such a 543 CERTREQ, implementations MAY ignore the request. 545 3.2.4. Authority Revocation List (ARL) 547 Implementations SHOULD NOT generate CERTREQ payloads with this type. 548 Recipients of this type SHOULD treat it as synonymous with the CRL 549 type. 551 Korver, Rescorla [Page 11]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 553 3.2.5. PKCS #7 wrapped X.509 certificate 555 This ID type defines a particular encoding (not a particular 556 certificate), some current implementations may ignore CERTREQs they 557 receive which contain this ID type, and the authors are unaware of 558 any implementations that generate such CERTREQ messages. Therefore, 559 the use of this type is deprecated. Implementations SHOULD NOT 560 require CERTREQs that contain this Certificate Type. Implementations 561 which receive CERTREQs which contain this ID type MAY treat such 562 payloads as synonymous with "X.509 Certificate - Signature". 564 3.2.6. Presence or Absence of Certificate Request Payloads 566 When in-band exchange of certificate keying materials is desired, 567 implementations MUST inform the peer of this by sending at least one 568 CERTREQ. An implementation which does not send any CERTREQs during an 569 exchange SHOULD NOT expect to receive any CERT payloads. 571 3.2.7. Certificate Requests 573 3.2.7.1. Specifying Certificate Authorities 575 Implementations MUST generate CERTREQs for every peer trust anchor 576 that local policy explicitly deems trusted during a given exchange. 577 Implementations MUST populate the Certificate Authority field with 578 the Subject Name of the trust anchor, populated such that binary 579 comparison of the Subject Name and the Certificate Authority will 580 succeed. 582 Upon receipt of a CERTREQ where the Certificate Type is "X.509 583 Certificate - Signature", implementations MUST respond by sending 584 each certificate in the chain from the end entity certificate up to 585 and including the certificate whose Issuer Name matches the name 586 specified in the Certificate Authority field. Implementations MAY 587 send other certificates. 589 Note, in the case where multiple end entity certificates may be 590 available, implementations SHOULD resort to local heuristics to 591 determine which end entity is most appropriate to use. Such 592 heuristics are out of the scope of this document. 594 3.2.7.2. Empty Certificate Authority Field 596 Implementations MUST NOT generate CERTREQs where the Certificate Type 597 is "X.509 Certificate - Signature" with an empty Certificate 598 Authority field, as this form is explicitly deprecated. Upon receipt 599 of such a CERTREQ from a non-conformant implementation, 600 implementations SHOULD send just the certificate chain associated 602 Korver, Rescorla [Page 12]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 604 with the end entity certificate, not including any CRLs or the 605 certificates that would be needed to validate those CRLs. 607 Note that PKIX prohibits certificates with an empty issuer name 608 field. 610 3.2.8. Robustness 612 3.2.8.1. Unrecognized or Unsupported Certificate Types 614 Implementations MUST be able to deal with receiving CERTREQs with 615 unsupported Certificate Types. Absent any recognized and supported 616 CERTREQs, implementations MAY treat them as if they are of a 617 supported type with the Certificate Authority field left empty, 618 depending on local policy. ISAKMP Section 5.10 "Certificate Request 619 Payload Processing" specifies additional processing. 621 3.2.8.2. Undecodable Certificate Authority Fields 623 Implementations MUST be able to deal with receiving CERTREQs with 624 undecodable Certificate Authority fields. Implementations MAY ignore 625 such payloads, depending on local policy. ISAKMP specifies other 626 actions which may be taken. 628 3.2.8.3. Ordering of Certificate Request Payloads 630 Implementations MUST NOT assume that CERTREQs are ordered in any way. 632 3.2.9. Optimizations 634 3.2.9.1. Duplicate Certificate Request Payloads 636 Implementations SHOULD NOT send duplicate CERTREQs during an 637 exchange. 639 3.2.9.2. Name Lowest 'Common' Certification Authorities 641 When a peer's certificate keying materials have been cached, an 642 implementation can send a hint to the peer to elide some of the 643 certificates the peer would normally respond with. In addition to the 644 normal set of CERTREQs that are sent specifying the trust anchors, an 645 implementation MAY send CERTREQs containing the Issuer Name of the 646 relevant cached end entity certificates. When sending these hints, it 647 is still necessary to send the normal set of CERTREQs because the 648 hints do not sufficiently convey all of the information required by 649 the peer. Specifically, either the peer may not support this 650 optimization or there may be additional chains that could be used in 651 this context but will not be specified if only supplying the issuer 653 Korver, Rescorla [Page 13]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 655 of the end entity certificate. 657 No special processing is required on the part of the recipient of 658 such a CERTREQ, and the end entity certificates will still be sent. 659 On the other hand, the recipient MAY elect to elide certificates 660 based on receipt of such hints. 662 ISAKMP mandates that CERTREQs contain the Subject Name of a 663 Certification Authority, which results in the peer always sending at 664 least the end entity certificate. This mechanism allows 665 implementations to determine unambiguously when a new certificate is 666 being used by the peer, perhaps because the previous certificate has 667 just expired, which will result in a failure because the needed 668 keying materials are not available to validate the new end entity 669 certificate. Implementations which implement this optimization MUST 670 recognize when the end entity certificate has changed and respond to 671 it by not performing this optimization when the exchange is retried. 673 3.2.9.3. Example 675 Imagine that an implementation has previously received and cached the 676 peer certificate chain TA->CA1->CA2->EE. If during a subsequent 677 exchange this implementation sends a CERTREQ containing the Subject 678 Name in certificate TA, this implementation is requesting that the 679 peer send at least 3 certificates: CA1, CA2, and EE. On the other 680 hand, if this implementation also sends a CERTREQ containing the 681 Subject Name of CA2, the implementation is providing a hint that only 682 1 certificate needs to be sent: EE. Note that in this example, the 683 fact that TA is a trust anchor should not be construed to imply that 684 TA is a self-signed certificate. 686 3.3. Certificate Payload 688 The Certificate (CERT) Payload allows the peer to transmit a single 689 certificate or CRL. Multiple certificates are transmitted in multiple 690 payloads. However, not all certificate forms that are legal in PKIX 691 make sense in the context of ISAKMP or IPsec. The issue of how to 692 represent ISAKMP-meaningful name-forms in a certificate is especially 693 problematic. This memo provides a profile for a subset of PKIX that 694 makes sense for IKE/ISAKMP. 696 3.3.1. Certificate Type 698 The Certificate Type field identifies to the peer the type of 699 certificate keying materials that are included. ISAKMP defines 10 700 types of Certificate Data that can be sent and specifies the syntax 701 for these types. For the purposes of this document, only the 702 following types are relevant: 704 Korver, Rescorla [Page 14]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 706 * X.509 Certificate - Signature 707 * Certificate Revocation List (CRL) 708 * Authority Revocation List (ARL) 709 * PKCS #7 wrapped X.509 certificate 711 The use of the other types: 713 * X.509 Certificate - Key Exchange 714 * PGP Certificate 715 * DNS Signed Key 716 * Kerberos Tokens 717 * SPKI Certificate 718 * X.509 Certificate - Attribute 720 are out of the scope of this document. 722 3.3.2. X.509 Certificate - Signature 724 This type specifies that Certificate Data contains a certificate used 725 for signing, whether an end entity signature certificate or a CA 726 signature certificate. 728 3.3.3. Certificate Revocation List (CRL) 730 This type specifies that Certificate Data contains an X.509 CRL. 732 3.3.4. Authority Revocation List (ARL) 734 This type specifies that Certificate Data contains an X.509 CRL that 735 applies only to CA certificates. Recipients of this type MAY treat it 736 as synonymous with the CRL type. 738 3.3.5. PKCS #7 wrapped X.509 certificate 740 This type defines a particular encoding, not a particular certificate 741 type. Implementations SHOULD NOT generate CERTs that contain this 742 Certificate Type. Implementations which violate this requirement 743 SHOULD note that this is a single certificate as specified in ISAKMP. 744 Implementations SHOULD accept CERTs that contain this Certificate 745 Type. 747 3.3.6. Certificate Payloads Not Mandatory 749 An implementation which does not receive any CERTREQs during an 750 exchange SHOULD NOT send any CERT payloads, except when explicitly 751 configured to proactively send CERT payloads in order to interoperate 752 with non-compliant implementations. In this case, an implementation 753 MAY send the certificate chain (not including the trust anchor) 755 Korver, Rescorla [Page 15]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 757 associated with the end entity certificate. This MUST NOT be the 758 default behavior of implementations. 760 Implementations which are configured to expect that a peer must 761 receive certificates through out-of-band means SHOULD ignore any 762 CERTREQ messages that are received. 764 Implementations that receive CERTREQs from a peer which contain only 765 unrecognized Certification Authorities SHOULD NOT continue the 766 exchange, in order to avoid unnecessary and potentially expensive 767 cryptographic processing. 769 3.3.7. Response to Multiple Certificate Authority Proposals 771 In response to multiple CERTREQs which contain different Certificate 772 Authority identities, implementations MAY respond using an end entity 773 certificate which chains to a CA that matches any of the identities 774 provided by the peer. 776 3.3.8. Using Local Keying Materials 778 Implementations MAY elect not to use keying materials contained in a 779 given set of CERTs if preferable keying materials are available. For 780 instance, the contents of a CERT may be available from a previous 781 exchange or may be available through some out-of-band means. 783 3.3.9. Robustness 785 3.3.9.1. Unrecognized or Unsupported Certificate Types 787 Implementations MUST be able to deal with receiving CERTs with 788 unrecognized or unsupported Certificate Types. Implementations MAY 789 discard such payloads, depending on local policy. ISAKMP Section 5.10 790 "Certificate Request Payload Processing" specifies additional 791 processing. 793 3.3.9.2. Undecodable Certificate Data Fields 795 Implementations MUST be able to deal with receiving CERTs with 796 undecodable Certificate Data fields. Implementations MAY discard such 797 payloads, depending on local policy. ISAKMP specifies other actions 798 which may be taken. 800 3.3.9.3. Ordering of Certificate Payloads 802 Implementations MUST NOT assume that CERTs are ordered in any way. 804 Korver, Rescorla [Page 16]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 806 3.3.9.4. Duplicate Certificate Payloads 808 Implementations MUST support receiving multiple identical CERTs 809 during an exchange. 811 3.3.9.5. Irrelevant Certificates 813 Implementations MUST be prepared to receive certificates and CRLs 814 which are not relevant to the current exchange. Implementations MAY 815 discard such extraneous certificates and CRLs. 817 Implementations MAY send certificates which are irrelevant to an 818 exchange. One reason for including certificates which are irrelevant 819 to an exchange is to minimize the threat of leaking identifying 820 information in exchanges where CERT is not encrypted. It should be 821 noted, however, that this probably provides rather poor protection 822 against leaking the identity. 824 Another reason for including certificates that seem irrelevant to an 825 exchange is that there may be two chains from the Certificate 826 Authority to the end entity, each of which is only valid with certain 827 validation parameters (such as acceptable policies). Since the end 828 entity doesn't know which parameters the relying party is using, it 829 should send the certs needed for both chains (even if there's only 830 one CERTREQ). 832 3.3.10. Optimizations 834 3.3.10.1. Duplicate Certificate Payloads 836 Implementations SHOULD NOT send duplicate CERTs during an exchange. 837 Such payloads should be suppressed. 839 3.3.10.2. Send Lowest 'Common' Certificates 841 When multiple CERTREQs are received which specify certificate 842 authorities within the end entity certificate chain, implementations 843 MAY send the shortest chain possible. However, implementations SHOULD 844 always send the end entity certificate. See section 3.2.9.2 for more 845 discussion of this optimization. 847 3.3.10.3. Ignore Duplicate Certificate Payloads 849 Implementations MAY employ local means to recognize CERTs that have 850 been received in the past, whether part of the current exchange or 851 not, for which keying material is available and may discard these 852 duplicate CERTs. 854 Korver, Rescorla [Page 17]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 856 3.3.11. Hash Payload 858 IKE specifies the optional use of the Hash Payload to carry a pointer 859 to a certificate in either of the Phase 1 public key encryption 860 modes. This pointer is used by an implementation to locate the end 861 entity certificate that contains the public key that a peer should 862 use for encrypting payloads during the exchange. 864 Implementations SHOULD include this payload whenever the public 865 portion of the keypair has been placed in a certificate. 867 4. Profile of PKIX 869 4.1. X.509 Certificates 871 4.1.1. Versions 873 Although PKIX states that "implementations SHOULD be prepared to 874 accept any version certificate", in practice this profile requires 875 certain extensions that necessitate the use of Version 3 certificates 876 for all but self-signed certificates used as trust anchors. 877 Implementations that conform to this document MAY therefore reject 878 Version 1 and Version 2 certificates in all other cases. 880 4.1.2. Subject Name 882 4.1.2.1. Empty Subject Name 884 Implementations MUST accept certificates which contain an empty 885 Subject Name field, as specified in PKIX. Identity information in 886 such certificates will be contained entirely in the SubjectAltName 887 extension. 889 4.1.2.2. Specifying Non-FQDN Hosts in Subject Name 891 Implementations which desire to place host names that are not 892 intended to be processed by recipients as FQDNs (for instance 893 "Gateway Router") in the Subject Name MUST use the commonName 894 attribute. 896 While nothing prevents an FQDN, USER-FQDN, or IP address information 897 from appearing somewhere in the Subject Name contents, such entries 898 MUST NOT be interpreted as identity information for the purposes of 899 matching with ID or for policy lookup. 901 Korver, Rescorla [Page 18]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 903 4.1.2.3. Specifying FQDN Host Names in Subject Name 905 Implementations MUST NOT populate the Subject Name in place of 906 populating the dNSName field of the SubjectAltName extension. 908 4.1.2.4. EmailAddress 910 As specified in PKIX, implementations MUST NOT populate 911 DistinguishedNames with the EmailAddress attribute. 913 4.1.3. X.509 Certificate Extensions 915 Conforming applications MUST recognize extensions which must or may 916 be marked critical according to this specification. These extensions 917 are: KeyUsage, SubjectAltName, and BasicConstraints. 919 Implementations SHOULD generate certificates such that the extension 920 criticality bits are set in accordance with PKIX and this document. 921 With respect to PKIX compliance, implementations processing 922 certificates MAY ignore the value of the criticality bit for 923 extensions that are supported by that implementation, but MUST 924 support the criticality bit for extensions that are not supported by 925 that implementation. That is, if an implementation supports (and thus 926 is going to process) a given extension, then it isn't necessary to 927 reject the certificate if the criticality bit is different from what 928 PKIX states it must be. However, if an implementation does not 929 support an extension that PKIX mandates be critical, then the 930 implementation must reject the certificate. 932 implements bit in cert PKIX mandate behavior 933 ------------------------------------------------------ 934 yes true true ok 935 yes true false ok or reject 936 yes false true ok or reject 937 yes false false ok 938 no true true reject 939 no true false reject 940 no false true reject 941 no false false ok 943 4.1.3.1. AuthorityKeyIdentifier 945 Implementations SHOULD NOT assume that other implementations support 946 the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate 947 certificate hierarchies which are overly complex to process in the 948 absence of this extension, such as those that require possibly 949 verifying a signature against a large number of similarly named CA 951 Korver, Rescorla [Page 19]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 953 certificates in order to find the CA certificate which contains the 954 key that was used to generate the signature. 956 4.1.3.2. SubjectKeyIdentifier 958 Implementations SHOULD NOT assume that other implementations support 960 the SubjectKeyIdentifier extension, and thus SHOULD NOT generate 961 certificate hierarchies which are overly complex to process in the 962 absence of this extension, such as those that require possibly 963 verifying a signature against a large number of similarly named CA 964 certificates in order to find the CA certificate which contains the 965 key that was used to generate the signature. 967 4.1.3.3. KeyUsage 969 The meaning of the nonRepudiation bit is not defined in the context 970 of IPsec, although implementations SHOULD interpret the 971 nonRepudiation bit as synonymous with the digitalSignature bit. 972 Implementations SHOULD NOT generate certificates which only assert 973 the nonRepudiation bit. 975 See PKIX for general guidance on which of the other KeyUsage bits 976 should be set in any given certificate. 978 4.1.3.4. PrivateKeyUsagePeriod 980 PKIX recommends against the use of this extension. The 981 PrivateKeyUsageExtension is intended to be used when signatures will 982 need to be verified long past the time when signatures using the 983 private keypair may be generated. Since IKE SAs are short-lived 984 relative to the intended use of this extension in addition to the 985 fact that each signature is validated only a single time, the 986 usefulness of this extension in the context of IKE is unclear. 987 Therefore, implementations MUST NOT generate certificates that 988 contain the PrivateKeyUsagePeriod extension. 990 4.1.3.5. Certificate Policies 992 Many IPsec implementations do not currently provide support for the 993 Certificate Policies extension. Therefore, implementations that 994 generate certificates which contain this extension SHOULD mark the 995 extension as non-critical. 997 4.1.3.6. PolicyMappings 999 Many implementations do not support the PolicyMappings extension. 1001 Korver, Rescorla [Page 20]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1003 4.1.3.7. SubjectAltName 1005 Implementations SHOULD generate only the following GeneralName 1006 choices in the subjectAltName extension, as these choices map to 1007 legal ISAKMP Identity Payload types: rfc822Name, dNSName, or 1008 iPAddress. Although it is possible to specify any GeneralName choice 1009 in the ISAKMP Identity Payload by using the ID_DER_ASN1_GN ID type, 1010 implementations SHOULD NOT assume that a peer supports such 1011 functionality. 1013 4.1.3.7.1. dNSName 1015 This field MUST contain a fully qualified domain name. 1016 Implementations MUST NOT generate names that contain wildcards. 1018 Implementations MAY treat certificates that contain wildcards in this 1019 field as syntactically invalid. 1021 Although this field is in the form of an FQDN, implementations SHOULD 1022 NOT assume that this field contains an FQDN that will resolve via the 1023 DNS, unless this is known by way of some out-of-band mechanism. Such 1024 a mechanism is out of the scope of this document. Implementations 1025 SHOULD NOT treat the failure to resolve as an error. 1027 4.1.3.7.2. iPAddress 1029 Note that although PKIX permits CIDR [CIDR] notation in the "Name 1030 Constraints" extension, PKIX explicitly prohibits using CIDR notation 1031 for conveying identity information. In other words, the CIDR notation 1032 MUST NOT be used in the subjectAltName extension. 1034 4.1.3.7.3. rfc822Name 1036 Although this field is in the form of an Internet mail address, 1037 implementations SHOULD NOT assume that this field contains a valid 1038 email address, unless this is known by way of some out-of-band 1039 mechanism. Such a mechanism is out of the scope of this document. 1041 4.1.3.8. IssuerAltName 1043 Implementations SHOULD NOT assume that other implementations support 1044 the IssuerAltName extension, and especially should not assume that 1045 information contained in this extension will be displayed to end 1046 users. 1048 Korver, Rescorla [Page 21]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1050 4.1.3.9. SubjectDirectoryAttributes 1052 The SubjectDirectoryAttributes extension is intended to contain 1053 privilege information, in a manner analogous to privileges carried in 1054 Attribute Certificates. Implementations MAY ignore this extension 1055 when it is marked non-critical, as PKIX mandates. 1057 4.1.3.10. BasicConstraints 1059 PKIX mandates that CA certificates contain this extension and that it 1060 be marked critical. Implementations SHOULD reject CA certificates 1061 that do not contain this extension. For backwards compatibility, 1062 implementations may accept such certificates if explicitly configured 1063 to do so, but the default for this setting MUST be to reject such 1064 certificates. 1066 4.1.3.11. NameConstraints 1068 Many implementations do not support the NameConstraints extension. 1069 Since PKIX mandates that this extension be marked critical when 1070 present, implementations which intend to be maximally interoperable 1071 SHOULD NOT generate certificates which contain this extension. 1073 4.1.3.12. PolicyConstraints 1075 Many implementations do not support the PolicyConstraints extension. 1076 Since PKIX mandates that this extension be marked critical when 1077 present, implementations which intend to be maximally interoperable 1078 SHOULD NOT generate certificates which contain this extension. 1080 4.1.3.13. ExtendedKeyUsage 1082 No ExtendedKeyUsage usages are defined specifically for IPsec, so if 1083 this extension is present and marked critical, use of this 1084 certificate for IPsec MUST be treated as an error unless the 1085 extension contains the anyExtendedKeyUsage keyPurposeID, which 1086 asserts that the certificate can be used for any purpose. 1087 Implementations MAY ignore this extension if it is marked non- 1088 critical. Implementations MUST NOT generate this extension in 1089 certificates which are being used for IPsec. 1091 Note that a previous proposal for the use of three ExtendedKeyUsage 1092 values is obsolete and explicitly deprecated by this specification. 1093 For historical reference, those values were id-kp-ipsecEndSystem, id- 1094 kp-ipsecTunnel, and id-kp-ipsecUser. 1096 Korver, Rescorla [Page 22]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1098 4.1.3.14. CRLDistributionPoints 1100 Receiving CRLs in band via IKE/ISAKMP does not alleviate the 1101 requirement to process the CRLDistributionPoints if the certificate 1102 being validated contains the extension and the CRL being used to 1103 validate the certificate contains the IssuingDistributionPoint 1104 extension. Failure to validate the 1105 CRLDistributionPoints/IssuingDistributionPoint pair can result in CRL 1106 substitution where an entity knowingly substitutes a known good CRL 1107 from a different distribution point for the CRL which is supposed to 1108 be used which would show the entity as revoked. 1110 Implementations MUST support validating that the contents of 1111 CRLDistributionPoints match those of the IssuingDistributionPoint to 1112 prevent CRL substitution when the issuing CA is using them. At least 1113 one CA is known to default to this type of CRL use. See section 1114 4.2.2.5 for more information. 1116 See PKIX docs for CRLDistributionPoints intellectual rights 1117 information. Note that both the CRLDistributionPoints and 1118 IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED 1119 by PKIX, so there is no requirement to license any IPR. 1121 4.1.3.15. InhibitAnyPolicy 1123 Many implementations do not support the InhibitAnyPolicy extension. 1124 Since PKIX mandates that this extension be marked critical when 1125 present, implementations which intend to be maximally interoperable 1126 SHOULD NOT generate certificates which contain this extension. 1128 4.1.3.16. FreshestCRL 1130 Implementations MUST NOT assume that the FreshestCRL extension will 1131 exist in peer extensions. Note that most implementations do not 1132 support delta CRLs. 1134 4.1.3.17. AuthorityInfoAccess 1136 PKIX defines the AuthorityInfoAccess extension, which is used to 1137 indicate "how to access CA information and services for the issuer of 1138 the certificate in which the extension appears." Conformant 1139 implementations MAY support this extension. 1141 4.1.3.18. SubjectInfoAccess 1143 PKIX defines the SubjectInfoAccess private certificate extension, 1144 which is used to indicate "how to access information and services for 1146 Korver, Rescorla [Page 23]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1148 the subject of the certificate in which the extension appears." This 1149 extension has no known use in the context of IPsec. Conformant 1150 implementations SHOULD ignore this extension when present. 1152 4.2. X.509 Certificate Revocation Lists 1154 When validating certificates, implementations MUST make use of 1155 certificate revocation information, and SHOULD support such 1156 revocation information in the form of CRLs, unless non-CRL revocation 1157 information is known to be the only method for transmitting this 1158 information. Implementations MAY provide a configuration option to 1159 disable use of certain types of revocation information, but that 1160 option MUST be off by default. 1162 4.2.1. Multiple Sources of Certificate Revocation Information 1164 Implementations which support multiple sources of obtaining 1165 certificate revocation information MUST act conservatively when the 1166 information provided by these sources is inconsistent: when a 1167 certificate is reported as revoked by one source, the certificate 1168 MUST be considered revoked. 1170 4.2.2. X.509 Certificate Revocation List Extensions 1172 4.2.2.1. AuthorityKeyIdentifier 1174 Implementations SHOULD NOT assume that other implementations support 1175 the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate 1176 certificate hierarchies which are overly complex to process in the 1177 absence of this extension. 1179 4.2.2.2. IssuerAltName 1181 Implementations SHOULD NOT assume that other implementations support 1182 the IssuerAltName extension, and especially should not assume that 1183 information contained in this extension will be displayed to end 1184 users. 1186 4.2.2.3. CRLNumber 1188 As stated in PKIX, all issuers conforming to PKIX MUST include this 1189 extension in all CRLs. 1191 4.2.2.4. DeltaCRLIndicator 1193 Korver, Rescorla [Page 24]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1195 4.2.2.4.1. If Delta CRLs Are Unsupported 1197 Implementations that do not support delta CRLs MUST reject CRLs which 1198 contain the DeltaCRLIndicator (which MUST be marked critical 1199 according to PKIX) and MUST make use of a base CRL if it is 1200 available. Such implementations MUST ensure that a delta CRL does not 1201 "overwrite" a base CRL, for instance in the keying material database. 1203 4.2.2.4.2. Delta CRL Recommendations 1205 Since some implementations that do not support delta CRLs may behave 1206 incorrectly or insecurely when presented with delta CRLs, 1207 implementations SHOULD consider whether issuing delta CRLs increases 1208 security before issuing such CRLs. 1210 The authors are aware of several implementations which behave in an 1211 incorrect or insecure manner when presented with delta CRLs. See 1212 Appendix B for a description of the issue. Therefore, this 1213 specification RECOMMENDS against issuing delta CRLs at this time. On 1214 the other hand, failure to issue delta CRLs exposes a larger window 1215 of vulnerability. See the Security Considerations section of PKIX for 1216 additional discussion. Implementors as well as administrators are 1217 encouraged to consider these issues. 1219 4.2.2.5. IssuingDistributionPoint 1221 A CA that is using CRLDistributionPoints may do so to provide many 1222 "small" CRLs, each only valid for a particular set of certificates 1223 issued by that CA. To associate a CRL with a certificate, the CA 1224 places the CRLDistributionPoints extension in the certificate, and 1225 places the IssuingDistributionPoint in the CRL. The 1227 distributionPointName field in the CRLDistributionPoints extension 1228 MUST be identical to the distributionPoint field in the 1229 IssuingDistributionPoint extension. At least one CA is known to 1230 default to this type of CRL use. See section 4.1.3.14 for more 1231 information. 1233 4.2.2.6. FreshestCRL 1235 Given the recommendations against implementations generating delta 1236 CRLs, this specification RECOMMENDS that implementations do not 1237 populate CRLs with the FreshestCRL extension, which is used to obtain 1238 delta CRLs. 1240 5. Configuration Data Exchange Conventions 1242 Below we present a common format for exchanging configuration data. 1243 Implementations MUST support these formats, MUST support arbitrary 1245 Korver, Rescorla [Page 25]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1247 whitespace at the beginning and end of any line, MUST support 1248 arbitrary line lengths, and MUST support the three line-termination 1249 disciplines: LF (US-ASCII 10), CR (US-ASCII 13), and CRLF. 1251 5.1. Certificates 1253 Certificates MUST be Base64 encoded and appear between the following 1254 delimiters: 1256 -----BEGIN CERTIFICATE----- 1258 -----END CERTIFICATE----- 1260 5.2. Public Keys 1262 Implementations MUST support two forms of public keys: certificates 1263 and so-called "raw" keys. Certificates should be transferred in the 1264 same form as above. A raw key is only the SubjectPublicKeyInfo 1265 portion of the certificate, and MUST be Base64 encoded and appear 1266 between the following delimiters: 1268 -----BEGIN PUBLIC KEY----- 1270 -----END PUBLIC KEY----- 1272 5.3. PKCS#10 Certificate Signing Requests 1274 A PKCS#10 [PKCS-10] Certificiate Signing Request MUST be Base64 1275 encoded and appear between the following delimeters: 1277 -----BEGIN CERTIFICATE REQUEST----- 1279 -----END CERTIFICATE REQUEST----- 1281 6. Security Considerations 1283 6.1. Identity Payload 1285 Depending on the exchange type, ID may be passed in the clear. 1286 Administrators in some environments may wish to use the empty 1287 Certification Authority option to prevent such information from 1288 leaking, at the possible cost of some performance, although such use 1289 is discouraged. 1291 Korver, Rescorla [Page 26]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1293 6.2. Certificate Request Payload 1295 The Contents of CERTREQ are not encrypted in IKE. In some 1296 environments this may leak private information. Administrators in 1297 some environments may wish to use the empty Certification Authority 1298 option to prevent such information from leaking, at the cost of 1299 performance. 1301 6.3. Certificate Payload 1303 Depending on the exchange type, CERTs may be passed in the clear and 1304 therefore may leak identity information. 1306 6.4. IKE Main Mode 1308 Implementations may not wish to respond with CERTs in the second 1309 message, thereby violating the identity protection feature of Main 1310 Mode IKE. ISAKMP allows CERTs to be included in any message, and 1311 therefore implementations may wish to respond with CERTs in a message 1312 that offers privacy protection in this case. 1314 7. Intellectual Property Rights 1316 No new intellectual property rights are introduced by this document. 1318 8. IANA Considerations 1320 There are no known numbers which IANA will need to manage. 1322 9. Normative References 1324 [DOI] Piper, D., "The Internet IP Security Domain of 1325 Interpretation for ISAKMP", RFC 2407, November 1998. 1327 [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange 1328 (IKE)", RFC 2409, November 1998. 1330 [IPSEC] Kent, S. and Atkinson, R., "Security Architecture for the 1331 Internet Protocol", RFC 2401, November 1998. 1333 [ISAKMP] Maughan, D., et. al., "Internet Security Association and 1334 Key Management Protocol (ISAKMP)", RFC 2408, November 1998. 1336 [PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax 1337 Version 1.5", RFC 2314, March 1998. 1339 [PKIX] Housley, R., et al., "Internet X.509 Public Key 1341 Korver, Rescorla [Page 27]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1343 Infrastructure Certificate and Certificate Revocation 1344 List (CRL) Profile", RFC 3280, April 2002. 1346 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1347 September 1981. 1349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1350 Requirement Levels", BCP 14, RFC 2119, March 1997. 1352 10. Informational References 1354 [CIDR] Fuller, V., et al., "Classless Inter-Domain Routing (CIDR): 1355 An Address Assignment and Aggregation Strategy", RFC 1519, 1356 September 1993. 1358 [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", 1359 RFC 2535, March 1999. 1361 [RFC1883] Deering, S. and Hinden, R. "Internet Protocol, Version 6 1362 (IPv6) Specification", RFC 1883, December 1995. 1364 [ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap", 1365 draft-ietf-pkix-roadmap-08.txt. 1367 [SBGP] Lynn, C., Kent, S., and Seo, K., "X.509 Extensions for 1368 IP Addresses and AS Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-00.txt. 1370 11. Acknowledgements 1372 The authors would like to acknowledge the expired draft-ietf-ipsec- 1373 pki-req-05.txt for providing valuable materials for this document. 1374 The authors would like to especially thank Greg Carter, Russ Housley, 1375 Steve Hanna, and Gregory Lebovitz for their valuable comments, some 1376 of which have been incorporated unchanged into this document. 1378 12. Author's Addresses 1380 Brian Korver 1381 Xythos Software, Inc. 1382 One Bush Street, Suite 600 1383 San Francisco, CA 94104 1384 USA 1385 Phone: +1 415 248-3800 1386 EMail: briank@xythos.com 1388 Eric Rescorla 1389 RTFM, Inc. 1390 2064 Edgewood Drive 1392 Korver, Rescorla [Page 28]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1394 Palo Alto, CA 94303 1395 USA 1396 Phone: +1 650 320-8549 1397 EMail: ekr@rtfm.com 1399 Copyright (C) The Internet Society (2004). All Rights Reserved. 1401 This document and translations of it may be copied and furnished to 1402 others, and derivative works that comment on or otherwise explain it 1403 or assist in its implementation may be prepared, copied, published 1404 and distributed, in whole or in part, without restriction of any 1405 kind, provided that the above copyright notice and this paragraph are 1406 included on all such copies and derivative works. However, this 1407 document itself may not be modified in any way, such as by removing 1408 the copyright notice or references to the Internet Society or other 1409 Internet organizations, except as needed for the purpose of 1410 developing Internet standards in which case the procedures for 1411 copyrights defined in the Internet Standards process must be 1412 followed, or as required to translate it into languages other than 1413 English. 1415 The limited permissions granted above are perpetual and will not be 1416 revoked by the Internet Society or its successors or assigns. 1418 This document and the information contained herein is provided on an 1419 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1420 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1421 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1422 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1423 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1425 Acknowledgement 1427 Funding for the RFC Editor function is currently provided by the 1428 Internet Society. 1430 Appendix A. Change History 1432 * February 2004 (-04) 1434 Minor editorial changes to clean up language 1436 Deprecate in-band exchange of CRLs 1438 Incorporated Gregory Lebovitz's proposal for CERT payloads: 1440 Korver, Rescorla [Page 29]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1442 "should deal with all the CRL, Intermediat Certs, Trust Anchors, 1443 etc OOB of IKE; MUST be able to send and receive EE cert payload; 1444 only real exception is Intermediate Cets which MAY be sent and 1445 SHOULD be able to be receivable (but in reality there are very few 1446 hierarchies in operation, so really it's a corner case); SHOULD 1447 NOT send the other stuff (CRL, Trust Anchors, etc) in cert 1448 payloads in IKE; SHOULD be able to accept the other stuff if by 1449 chance it gets sent, though we hope they don't get sent" 1451 Incorporated comments contained in Oct 7, 2003 email from 1452 steve.hanna@sun.com to ipsec@lists.tislabs.com 1454 Moved text from "Profile of ISAKMP" Background section to each 1455 payload section (removing duplication of these sections) 1457 Removed "Certificate-Related Playloads in ISAKMP" section since it 1458 was not specific to IKE. 1460 Incorporated Gregory Lebovitz's table in the "Identification 1461 Payload" section 1463 Moved text from "binding identity to policy" sections to each 1464 payload section 1466 Moved text from "IKE" section into now-combined "IKE/ISAKMP" 1467 section 1469 ID_USER_FQDN and ID_FQDN promoted to MUST from MAY 1471 Promoted sending ID_DER_ASN1_DN to MAY from SHOULD NOT, and 1472 receiving from MUST from MAY 1474 Demoted ID_DER_ASN1_GN to MUST NOT 1476 Demoted populating Subject Name in place of populating the dNSName 1477 from SHOULD NOT to MUST NOT and removed the text regarding 1478 domainComponent 1480 Revocation information checking MAY now be disabled, although not 1481 by default 1483 Aggressive Mode removed from this profile 1485 * June 2003 (-03) 1487 Korver, Rescorla [Page 30]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1489 Minor editorial changes to clean up language 1491 Minor additional clarifying text 1493 Removed hyphenation 1495 Added requirement that implementations support configuration data 1496 exchange having arbitrary line lengths 1498 * February 2003 (-02) 1500 Word choice: move from use of "root" to "trust anchor", in 1501 accordance with PKIX 1503 SBGP note and reference for placing address subnet and range 1504 information into certificates 1506 Clarification of text regarding placing names of hosts into the 1507 Name commonName attribute of SubjectName 1509 Added table to clarify text regarding processing of the 1510 certificate extension criticality bit 1512 Added text underscoring processing requirements for 1513 CRLDistributionPoints and IssuingDistributionPoint 1515 * October 2002, Reorganization (-01) 1516 * June 2002, Initial Draft (-00) 1518 Appendix B. The Possible Dangers of Delta CRLs 1520 The problem is that the CRL processing algorithm is sometimes written 1521 incorrectly with the assumption that all CRLs are base CRLs and it is 1522 assumed that CRLs will pass content validity tests. Specifically, 1523 such implementations fail to check the certificate against all 1524 possible CRLs: if the first CRL that is obtained from the keying 1525 material database fails to decode, no further revocation checks are 1526 performed for the relevant certificate. This problem is compounded by 1527 the fact that implementations which do not understand delta CRLs may 1528 fail to decode such CRLs due to the critical DeltaCRLIndicator 1529 extension. The algorithm that is implemented in this case is 1530 approximately: 1532 Korver, Rescorla [Page 31]Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 2/2004 1534 fetch newest CRL 1535 check validity of CRL signature 1536 if CRL signature is valid then 1537 if CRL does not contain unrecognized critical extensions 1538 and certificate is on CRL then 1539 set certificate status to revoked 1541 The authors note that a number of PKI toolkits do not even provide a 1542 method for obtaining anything but the newest CRL, which in the 1543 presence of delta CRLs may in fact be a delta CRL, not a base CRL. 1545 Note that the above algorithm is dangerous in many ways. See PKIX 1546 for the correct algorithm.