idnits 2.17.1 draft-ietf-ipsec-pki-profile-03.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 138 instances of too long lines in the document, the longest one being 8 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 295 has weird spacing: '... of endpoin...' == Line 966 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) == Unused Reference: 'ROADMAP' is defined on line 1481, 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) ** 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: A later version (-03) exists of draft-ietf-pkix-x509-ipaddr-as-extn-00 Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Brian Korver 3 Xythos Software 4 Eric Rescorla 5 INTERNET-DRAFT RTFM, Inc. 6 Jul 2003 (Expires Jan 2004) 8 The Internet IP Security PKI Profile of ISAKMP and PKIX 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 ISAKMP and PKIX both provide frameworks that must be profiled for use 33 in a given application. This document provides a profile of ISAKMP 34 and PKIX that defines the requirements for using PKI technology in 35 the context of IPsec. The document compliments protocol 36 specifications such as IKE, which assume the existence of public key 37 certificates and related keying materials, but which do not address 38 PKI issues explicitly. This document addresses those issues. 40 Table of Contents 42 1 Introduction 4 43 2 Terms and Definitions 5 44 3 Profile of ISAKMP 6 45 3.1 Background 6 46 3.1.1 Certificate-Related Payloads in ISAKMP 6 47 3.1.1.1 Identification Payload 6 48 3.1.1.2 Certificate Payload 6 49 3.1.1.3 Certificate Request Payload 6 50 3.1.1.4 Hash Payload 6 51 3.1.2 Endpoint Identification 7 52 3.1.2.1 Identification Payload Only 7 53 3.1.2.2 Certificate Payload Only 7 54 3.2 Identification Payload 7 55 3.2.1 ID_IPV4_ADDR and ID_IPV6_ADDR 7 56 3.2.2 ID_FQDN 8 57 3.2.3 ID_USER_FQDN 8 58 3.2.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_A... 8 59 3.2.5 ID_DER_ASN1_DN 8 60 3.2.6 ID_DER_ASN1_GN 9 61 3.2.7 ID_KEY_ID 9 62 3.2.8 Using Peer Source IP Address to Bind Identity to Po... 9 63 3.2.9 Securely Binding Identity to Policy 10 64 3.2.9.1 Single Address Identification Data 10 65 3.2.9.2 Identification Data other than a Single Address 10 66 3.2.10 Selecting an Identity from a Certificate 11 67 3.2.11 Transitively Binding Identity to Policy 11 68 3.3 Certificate Request Payload 11 69 3.3.1 Certificate Type 11 70 3.3.2 X.509 Certificate - Signature 12 71 3.3.3 X.509 Certificate - Key Exchange 12 72 3.3.4 Certificate Revocation List (CRL) 12 73 3.3.5 Authority Revocation List (ARL) 12 74 3.3.6 PKCS #7 wrapped X.509 certificate 13 75 3.3.7 Presence or Absence of Certificate Request Payloads 13 76 3.3.8 Certificate Requests 13 77 3.3.8.1 Specifying Certificate Authorities 13 78 3.3.8.2 Empty Certificate Authority Field 13 79 3.3.9 CRL Requests 14 80 3.3.9.1 Specifying Certificate Authorities 14 81 3.3.9.2 Empty Certificate Authority Field 14 82 3.3.10 Robustness 14 83 3.3.10.1 Unrecognized or Unsupported Certificate Types 14 84 3.3.10.2 Undecodable Certificate Authority Fields 15 85 3.3.10.3 Ordering of Certificate Request Payloads 15 86 3.3.11 Optimizations 15 87 3.3.11.1 Duplicate Certificate Request Payloads 15 88 3.3.11.2 Name Lowest 'Common' Certification Authorities 15 89 3.3.11.3 Example 16 90 3.4 Certificate Payload 16 91 3.4.1 Certificate Type 16 92 3.4.2 X.509 Certificate - Signature 16 93 3.4.3 X.509 Certificate - Key Exchange 17 94 3.4.4 Certificate Revocation List (CRL) 17 95 3.4.5 Authority Revocation List (ARL) 17 96 3.4.6 PKCS #7 wrapped X.509 certificate 17 97 3.4.7 Certificate Payloads Not Mandatory 17 98 3.4.8 Response to Multiple Certificate Authority Proposals 18 99 3.4.9 Using Local Keying Materials 18 100 3.4.10 Robustness 18 101 3.4.10.1 Unrecognized or Unsupported Certificate Types 18 102 3.4.10.2 Undecodable Certificate Data Fields 18 103 3.4.10.3 Ordering of Certificate Payloads 18 104 3.4.10.4 Duplicate Certificate Payloads 18 105 3.4.10.5 Irrelevant Certificates 18 106 3.4.11 Optimizations 19 107 3.4.11.1 Duplicate Certificate Payloads 19 108 3.4.11.2 Send Lowest 'Common' Certificates 19 109 3.4.11.3 Ignore Duplicate Certificate Payloads 19 110 4 Profile of PKIX 19 111 4.1 X.509 Certificates 19 112 4.1.1 Versions 19 113 4.1.2 Subject Name 19 114 4.1.2.1 Empty Subject Name 20 115 4.1.2.2 Specifying Non-FQDN Hosts in Subject Name 20 116 4.1.2.3 Specifying FQDN Host Names in Subject Name 20 117 4.1.2.4 EmailAddress 20 118 4.1.3 X.509 Certificate Extensions 20 119 4.1.3.1 AuthorityKeyIdentifier 21 120 4.1.3.2 SubjectKeyIdentifier 21 121 4.1.3.3 KeyUsage 22 122 4.1.3.4 PrivateKeyUsagePeriod 22 123 4.1.3.5 Certificate Policies 22 124 4.1.3.6 PolicyMappings 22 125 4.1.3.7 SubjectAltName 22 126 4.1.3.7.1 dNSName 23 127 4.1.3.7.2 iPAddress 23 128 4.1.3.7.3 rfc822Name 23 129 4.1.3.8 IssuerAltName 23 130 4.1.3.9 SubjectDirectoryAttributes 23 131 4.1.3.10 BasicConstraints 23 132 4.1.3.11 NameConstraints 24 133 4.1.3.12 PolicyConstraints 24 134 4.1.3.13 ExtendedKeyUsage 24 135 4.1.3.14 CRLDistributionPoint 24 136 4.1.3.15 InhibitAnyPolicy 25 137 4.1.3.16 FreshestCRL 25 138 4.1.3.17 AuthorityInfoAccess 25 139 4.1.3.18 SubjectInfoAccess 25 140 4.2 X.509 Certificate Revocation Lists 25 141 4.2.1 Certificate Revocation Requirement 26 142 4.2.2 Multiple Sources of Certificate Revocation Informati... 26 143 4.2.3 X.509 Certificate Revocation List Extensions 26 144 4.2.3.1 AuthorityKeyIdentifier 26 145 4.2.3.2 IssuerAltName 26 146 4.2.3.3 CRLNumber 26 147 4.2.3.4 DeltaCRLIndicator 26 148 4.2.3.4.1 If Delta CRLs Are Unsupported 26 149 4.2.3.4.2 Delta CRL Recommendations 27 150 4.2.3.5 IssuingDistributionPoint 27 151 4.2.3.6 FreshestCRL 27 152 5 Configuration Data Exchange Conventions 27 153 5.1 Certificates 27 154 5.2 Public Keys 28 155 5.3 PKCS#10 Certificate Signing Requests 28 156 6 IKE 28 157 6.1 IKE Phase 1 Authenticated With Signatures 28 158 6.1.1 Identification Payload 28 159 6.1.2 X.509 Certificate Extensions 29 160 6.1.2.1 KeyUsage 29 161 6.1.3 Obtaining Peer Certificates and CRLs 29 162 6.2 IKE Phase 1 Authenticated With Public Key Encryption 29 163 6.2.1 Identification Payload 29 164 6.2.2 Hash Payload 29 165 6.2.3 X.509 Certificate Extensions 29 166 6.2.3.1 KeyUsage 29 167 6.2.4 Obtaining Peer Certificates and CRLs 30 168 6.3 IKE Phase 1 Authenticated With a Revised Mode of Pub... 30 169 7 Security Considerations 30 170 7.1 Identity Payload 30 171 7.2 Certificate Request Payload 30 172 7.3 Certificate Payload 30 173 7.4 IKE Main Mode 30 174 7.5 IKE Aggressive Mode 31 175 8 Intellectual Property Rights 31 176 9 IANA Considerations 31 177 10 Normative References 31 178 11 Informational References 32 179 12 Acknowledgements 32 180 13 Author's Addresses 32 182 1. Introduction 184 IKE [IKE] and ISAKMP [ISAKMP] provide a secure key exchange mechanism 185 for use with IPsec [IPSEC]. In many cases the peers authenticate 186 using digital certificates as specified in PKIX [PKIX]. 187 Unfortunately, the combination of these standards leads to an 188 underspecified set of requirements for the use of certificates in the 189 context of IPsec. 191 ISAKMP references PKIX but in many cases merely specifies the 192 contents of various messages without specifying their syntax or 193 semantics. Meanwhile, PKIX provides a large set of certificate 194 mechanisms which are generally applicable for Internet protocols, but 195 little specific guidance for IPsec. Given the numerous underspecified 196 choices, interoperability is hampered if all implementors do not make 197 similar choices, or at least fail to account for implementations 198 which have chosen differently. 200 This profile of the ISAKMP and PKIX frameworks is intended to provide 201 an agreed-upon standard for using PKI technology in the context of 202 IPsec by profiling the PKIX framework for use with ISAKMP and IPsec, 203 and by documenting the contents of the relevant ISAKMP payloads and 204 further specifying their semantics. 206 In addition to providing a profile of ISAKMP and PKIX, this document 207 attempts to incorporate lessons learned from recent experience with 208 both implementation and deployment, as well as the current state of 209 related protocols and technologies. 211 Material from ISAKMP and PKIX is not repeated here, and readers of 212 this document are assumed to have read and understood both documents. 213 The requirements and security aspects of those documents are fully 214 relevant to this document as well. 216 This document is organized as follows. Section 2 defines special 217 terminology used in threst of this document, Section 3 provides the 218 profile of ISAKMP and Section 4 provides the profile of PKIX. Section 219 5 covers conventions for the out-of-band exchange of keying materials 220 for configuration purposes. Section 6 covers aspects of ISAKMP and 221 PKIX which are unique to IKE. 223 Versions "00" through "03" of this document are intended as "straw 224 men" to encourage comments from implementors of IPsec and to 225 encourage discussion of the issues which the authors hope to address 226 this document. 228 This document is being discussed on the ipsec@lists.tislabs.com 229 mailing list, which is the mailing list for the IPsec Working Group. 231 2. Terms and Definitions 233 Except for those terms which are defined immediately below, all PKI 234 terms used in this document are defined in either the PKIX, ISAKMP, 235 or DOI [DOI] documents. 237 * Peer source address: The source address in packets from a peer. 238 This address may be different from any addresses asserted as the 239 "identity" of the peer. 240 * FQDN: Fully qualified domain name. 242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 244 document are to be interpreted as described in RFC-2119 [RFC2119]. 246 3. Profile of ISAKMP 248 3.1. Background 250 3.1.1. Certificate-Related Payloads in ISAKMP 252 ISAKMP has three primary certificate-related payloads: 253 Identification, Certificate, and Certificate Request. Additionally, 254 IKE specifies the optional use of the Hash Payload to carry a pointer 255 to a certificate in either of the Phase 1 public key encryption 256 modes. In this section we provide a short introduction to these 257 payload types. 259 3.1.1.1. Identification Payload 261 The Identification (ID) Payload is used to indicate the identity that 262 the agent claims to be speaking for. The receiving agent can then use 263 the ID as a lookup key for policy and whatever certificate store or 264 directory that it has available. Our primary concern in this document 265 is to profile the ID payload so that it can be safely used to 266 generate or lookup policy. 268 3.1.1.2. Certificate Payload 270 The Certificate (CERT) Payload allows the peer to transmit a single 271 certificate or CRL. Multiple certificates are transmitted in multiple 272 payloads. However, not all certificate forms that are legal in PKIX 273 make sense in the context of ISAKMP or IPsec. The issue of how to 274 represent ISAKMP-meaningful name-forms in a certificate is especially 275 problematic. This memo provides a profile for a subset of PKIX that 276 makes sense for ISAKMP. 278 3.1.1.3. Certificate Request Payload 280 The Certificate Request (CERTREQ) Payload allows an ISAKMP 281 implementation to request that a peer provide some set of 282 certificates or certificate revocation lists. It is not clear from 283 ISAKMP exactly how that set should be specified or how the peer 284 should respond. We describe the semantics on both sides. 286 3.1.1.4. Hash Payload 288 The Hash (HASH) Payload is a generic mechanism for ISAKMP 289 implementations to communicate hash values to a peer. The meaning of 290 the contents of such payloads is left undefined by ISAKMP. 292 3.1.2. Endpoint Identification 294 ISAKMP contains two different payloads that allow the specification 295 of endpoint identity, the ID payload and the CERT payload. According 296 to ISAKMP, these payloads can be used separately or together, 297 although specific profiles of ISAKMP may place additional 298 requirements on implementations. 300 3.1.2.1. Identification Payload Only 302 If one peer presents only the ID payload, it is expected that the 303 peer will be able to recover whatever keying material is required to 304 verify the peer's identity. How to do so is out of the scope of this 305 document but might include a local cache, an LDAP directory, or DNS. 307 3.1.2.2. Certificate Payload Only 309 If a peer presents only a CERT payload, this creates an ambiguity, 310 since ISAKMP does not specify which of potentially many certificates 311 corresponds to the end-entity and which are chaining certificates. 312 Implementations SHOULD compare whatever local hints they have about 313 peer identity to each certificate until they find one that appears 314 acceptable. 316 3.2. Identification Payload 318 The ID payload requirements in this document cover only the portion 319 of the explicit policy checks that deal with the Identity Payload 320 specifically. For instance, in the case where ID does not contain an 321 IP address, checks such as verifying that the peer source address is 322 permitted by the relevant policy are not addressed here as they are 323 out of the scope of this document. 325 The [DOI] defines the 11 types of Identification Data that can be 326 used and specifies the syntax for these types. All of these are 327 discussed immediately below. 329 3.2.1. ID_IPV4_ADDR and ID_IPV6_ADDR 331 Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR 332 ID type. These addresses MUST be stored in "network byte order," as 333 specified in [RFC791]. The least significant bit (LSB) of each octet 334 is the LSB of the corresponding byte in the network address. For the 335 ID_IPV4_ADDR type, the payload MUST contain exactly four octets 336 [RFC791]. For the ID_IPV6_ADDR type, the payload MUST contain exactly 337 sixteen octets [RFC1883]. When comparing the contents of ID with the 338 iPAddress field in the subjectAltName extension for equality, binary 339 comparison MUST be performed. 341 3.2.2. ID_FQDN 343 Implementations MAY support the ID_FQDN ID type, generally to support 344 host-based access control lists for hosts without fixed IP addresses. 345 However, implementations SHOULD NOT use the DNS to map the FQDN to IP 346 addresses for input into any policy decisions, unless that mapping is 347 known to be secure, such as when [DNSSEC] is employed. When comparing 348 the contents of ID with the dNSName field in the subjectAltName 349 extension for equality, caseless string comparison MUST be performed. 350 Substring, wildcard, or regular expression matching MUST NOT be 351 performed. 353 3.2.3. ID_USER_FQDN 355 Implementations MAY support the ID_USER_FQDN ID type, generally to 356 support user-based access control lists for users without fixed IP 357 addresses. However, implementations SHOULD NOT use the DNS to map the 358 FQDN portion to IP addresses for input into any policy decisions, 359 unless that mapping is known to be secure, such as when [DNSSEC] is 360 employed. When comparing the contents of ID with the rfc822Name field 361 in the subjectAltName extension for equality, caseless string 362 comparison MUST be performed. Substring, wildcard, or regular 363 expression matching MUST NOT be performed. 365 3.2.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, 366 ID_IPV6_ADDR_RANGE 368 As there is currently no standard method for putting address subnet 369 or range identity information into certificates, the use of these ID 370 types is currently undefined. 372 Note that work in [SBGP] for defining blocks of addresses using 373 the certificate extension identified by 375 id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } 377 is experimental at this time. 379 3.2.5. ID_DER_ASN1_DN 381 Implementations MAY support receiving the ID_DER_ASN1_DN ID type, 382 although implementations SHOULD NOT generate this type because many 383 implementations do not support this type. Implementations which 384 generate this type SHOULD populate the contents of ID with the 385 Subject Name from the end entity certificate, and MUST do so such 386 that a binary comparison of the two will succeed. For instance, if 387 the certificate was erroneously created such that the encoding of the 388 Subject Name DN varies from the constraints set by DER, that non- 389 conformant DN that MUST be used to populate the ID payload: in other 390 words, implementations MUST NOT re-encode the DN for the purposes of 391 making it DER if it does not appear in the certificate as DER. 392 Implementations MUST NOT populate ID with the Subject Name from the 393 end entity certificate if it is empty, as described in the "Subject" 394 section of PKIX. 396 3.2.6. ID_DER_ASN1_GN 398 Implementations MAY support receiving the ID_DER_ASN1_GN ID type, 399 although implementations SHOULD NOT generate this type unless it is 400 known through out-of-band means that the peer is capable of 401 understanding this type. Implementations which generate this type 402 MUST populate the contents of ID with the a GeneralName from the 403 SubjectAltName extension in the end entity certificate, and MUST do 404 so such that a binary comparison of the two will succeed. For 405 instance, if the certificate was erroneously created such that the 406 encoding of the GeneralName varies from the constraints set by DER, 407 that non-conformant GeneralName MUST be used to populate the ID 408 payload: in other words, implementations MUST NOT re-encode the 409 GeneralName for the purposes of making it DER if it does not appear 410 in the certificate as DER. 412 3.2.7. ID_KEY_ID 414 Type ID_KEY_ID type used to specify pre-shared keys and thus is not 415 relevant to this document. 417 3.2.8. Using Peer Source IP Address to Bind Identity to Policy 419 Because implementations sometimes use ID as a lookup key to determine 420 which policy to use, all implementations MUST be especially careful 421 to verify the truthfulness of the contents by verifying that they 422 correspond to some keying material demonstrably held by the peer. 423 Failure to do so may result in the use of an inappropriate or 424 insecure policy. The following sections describe the methods for 425 performing this binding. 427 Implementations MAY use the IP address found in the header of packets 428 received from the peer to lookup the policy, but such implementations 429 MUST still perform verification of the ID payload. Although packet IP 430 addresses are inherently untrustworthy and must therefore be 431 independently verified, it is often useful to use the apparent IP 432 address of the peer to locate a general class of policies that will 433 be used until the mandatory identity-based policy lookup can be 434 performed. 436 For instance, if the IP address of the peer is unrecognized, a VPN 437 gateway device might load a general "road warrior" policy that 438 specifies a particular CA that is trusted to issue certificates which 439 contain a valid rfc822Name which can be used by that implementation 440 to perform authorization based on access control lists (ACLs) after 441 the peer's certificate has been validated. The rfc822Name can then be 442 used to determine the policy that provides specific authorization to 443 access resources (such as IP addresses, ports, and so forth). 445 As another example, if the IP address of the peer is recognized to be 446 a known peer VPN endpoint, policy may be determined using that 447 address, but until the identity (address) is validated by validating 448 the peer certificate, the policy MUST NOT be used to authorize any 449 IPsec traffic. Whether the address need appear as an identity in the 450 certificate is a matter of local policy, and SHOULD be configurable 451 by an administrator. 453 As a general comment, however, it may be easier to spoof the contents 454 of an ID payload than it is to spoof a peer source address because 455 the peer source address must exist on the route to the peer, while ID 456 can contain essentially random identification information. 457 Implementations MUST validate the Identity Data provided by a peer, 458 but implementations MAY favor unauthenticated peer source addresses 459 over an unauthenticated ID for initial policy lookup. 461 3.2.9. Securely Binding Identity to Policy 463 3.2.9.1. Single Address Identification Data 465 In the case where ID contains ID_IPV4_ADDR or ID_IPV6_ADDR, 466 implementations MUST verify that this address is the same as the peer 467 source address. If the end entity certificate contains address 468 identities, then the peer source address must match at least one of 469 those identities. If either of the above do not match, this MUST be 470 treated as an error and security association setup MUST be aborted. 471 This event SHOULD be auditable. The definition of "match" is specific 472 to each ID type and was discussed above. In addition, implementations 473 MUST allow administrators to configure a local policy that requires 474 that the peer source address exist in the certificate. 475 Implementations SHOULD allow administrators to configure a local 476 policy that does not enforce this requirement. 478 3.2.9.2. Identification Data other than a Single Address 480 In the case where ID contains an identity type other than a single 481 address, implementations MUST verify that the identity contained in 482 the ID payload matches identity information contained in the peer end 483 entity certificate, either in the Subject Name field or 484 subjectAltName extension. If there is not a match, this MUST be 485 treated as an error and security association setup MUST be aborted. 486 This event SHOULD be auditable. The definition of "match" is specific 487 to each ID type and was discussed above. 489 3.2.10. Selecting an Identity from a Certificate 491 Implementations MUST support certificates that contain more than a 492 single identity. In many cases a certificate will contain an identity 493 such as an IP address in the subjectAltName extension in addition to 494 a non-empty Subject Name. 496 Which identity an implementation chooses to populate ID with is a 497 local matter. For compatibility with non-conformant implementations, 498 implementations SHOULD populate ID with whichever identity is likely 499 to be named in the peer's policy. In practice, this generally means 500 IP address, FQDN, or USER-FQDN. 502 3.2.11. Transitively Binding Identity to Policy 504 In the presence of certificates that contain multiple identities, 505 implementations SHOULD NOT assume that a peer will choose the most 506 appropriate identity with which to populate ID. Therefore, when 507 determining the appropriate policy, implementations SHOULD select the 508 most appropriate identity to use from the identities contained in the 509 certificate. 511 For example, imagine that a peer is configured with a certificate 512 that contains both a non-empty Subject Name and an FQDN. Independent 513 of which identity is used to populate ID, the host implementation 514 MUST locate the proper policy. For instance, if ID contains the peer 515 Subject Name, then the peer end entity certificate may be found using 516 the Subject Name as a key. Once the certificate has been located and 517 then validated, the FQDN in the certificate can be used to locate the 518 appropriate policy. In other wores, the Subject Name is used to find 519 the certificate, the certificate contains the FQDN, and the FQDN is 520 used to lookup policy. 522 3.3. Certificate Request Payload 524 3.3.1. Certificate Type 526 The Certificate Type field identifies to the peer the type of 527 certificate keying materials that are desired. ISAKMP defines 10 528 types of Certificate Data that can be requested and specifies the 529 syntax for these types. For the purposes of this document, only the 530 following types are relevant: 532 * X.509 Certificate - Signature 533 * X.509 Certificate - Key Exchange 534 * Certificate Revocation List (CRL) 535 * Authority Revocation List (ARL) 536 * PKCS #7 wrapped X.509 certificate 538 For example, if CRLs are desired, an implementation will populate the 539 Certificate Type field with the value associated with "Certificate 540 Revocation List (CRL)". 542 The use of the other types: 544 * PGP Certificate 545 * DNS Signed Key 546 * Kerberos Tokens 547 * SPKI Certificate 548 * X.509 Certificate - Attribute 550 are out of the scope of this document. 552 3.3.2. X.509 Certificate - Signature 554 This type requests that the end entity certificate be a signing 555 certificate. Implementations that receive CERTREQs which contain this 556 ID type in a context in which end entity signature certificates are 557 not used SHOULD ignore such CERTREQs. 559 3.3.3. X.509 Certificate - Key Exchange 561 This type requests that the end entity certificate be a key exchange 562 certificate. Implementations that receive CERTREQs which contain this 563 ID type in a context in which end entity key exchange certificates 564 are not used SHOULD ignore such CERTREQs. 566 3.3.4. Certificate Revocation List (CRL) 568 This type requests that X.509 CRLs be provided, along with any 569 certificates that may be needed to validate those CRLs. 571 3.3.5. Authority Revocation List (ARL) 573 Implementations SHOULD NOT generate CERTREQ payloads with this type, 574 but should instead generate CRL CERTREQs. That is, implementations 575 request CRLs generically, whether they be CRLs or ARLs, using the CRL 576 type. Recipients of this type SHOULD treat it as synonymous with the 577 CRL type. 579 3.3.6. PKCS #7 wrapped X.509 certificate 581 This ID type defines a particular encoding (not a particular 582 certificate or CRL type), some current implementations may ignore 583 CERTREQs they receive which contain this ID type, and the authors are 584 unaware of any implementations that generate such CERTREQ messages. 585 Therefore, the use of this type is deprecated. Implementations SHOULD 586 NOT require CERTREQs that contain this Certificate Type. 587 Implementations which receive CERTREQs which contain this ID type MAY 588 ignore such payloads. 590 3.3.7. Presence or Absence of Certificate Request Payloads 592 When in-band exchange of certificate keying materials is desired, 593 implementations MUST inform the peer of this by sending at least one 594 CERTREQ. An implementation which does not send any CERTREQs during an 595 exchange SHOULD NOT expect to receive any CERT payloads. 597 3.3.8. Certificate Requests 599 3.3.8.1. Specifying Certificate Authorities 601 Implementations MUST generate CERTREQs for every peer trust anchor 602 that local policy explicitly deems trusted during a given exchange. 603 Implementations MUST populate the Certificate Authority field with 604 the Subject Name of the trust anchor, populated such that binary 605 comparison of the Subject Name and the Certificate Authority will 606 succeed. 608 Upon receipt of a CERTREQ where the Certificate Type is either "X.509 609 Certificate - Signature" or "X.509 Certificate - Key Exchange", 610 implementations MUST respond by sending each certificate in the chain 611 from the end entity certificate to the certificate whose Issuer Name 612 matches the name specified in the Certificate Authority field. 613 Implementations MAY send other certificates from the chain. 615 Note, in the case where multiple end entity certificates may be 616 available, implementations SHOULD resort to local heuristics to 617 determine which end entity is most appropriate to use. Such 618 heuristics are out of the scope of this document. 620 3.3.8.2. Empty Certificate Authority Field 622 Implementations MUST NOT generate CERTREQs where the Certificate Type 623 is either "X.509 Certificate - Signature" or "X.509 Certificate - Key 624 Exchange" with an empty Certificate Authority field, as this form is 625 explicitly deprecated. Upon receipt of such a CERTREQ from a non- 626 conformant implementation, implementations SHOULD send just the 627 certificate chain associated with the end entity certificate, not 628 including any CRLs or the certificates that would be needed to 629 validate those CRLs. 631 Note that PKIX prohibits certificates with an empty issuer name 632 field. 634 3.3.9. CRL Requests 636 3.3.9.1. Specifying Certificate Authorities 638 Upon receipt of a CERTREQ where the Certificate Type is "Certificate 639 Revocation List (CRL)", implementations MUST respond by sending the 640 CRL issued by the issuer of each certificate in the chain between the 641 end entity certificate and the certificate whose Issuer Name matches 642 the name specified in the Certificate Authority field. In additional, 643 implementations MUST send any certificates that the peer will need to 644 validate those CRLs, while optionally eliding those certificates and 645 CRLs identified in CERTREQs as already being in the possession of the 646 peer. 648 3.3.9.2. Empty Certificate Authority Field 650 Implementations MAY generate CERTREQs where the Certificate Type is 651 "Certificate Revocation List (CRL)" with an empty Certificate 652 Authority field to signify that the peer should send all CRLs that 653 are possessed by that peer, whether relevant to the current exchange 654 or not. Upon receipt of such a CERTREQ, implementations SHOULD send 655 all CRLs that are possessed but MUST send all CRLs that are relevant 656 to the current exchange, including the certificates that are needed 657 to validate those CRLs, as a general mechanism for sharing revocation 658 information. 660 Note that PKIX prohibits CRLs with an empty issuer name field. 662 3.3.10. Robustness 664 3.3.10.1. Unrecognized or Unsupported Certificate Types 666 Implementations MUST be able to deal with receiving CERTREQs with 667 unsupported Certificate Types. Absent any recognized and supported 668 CERTREQs, implementations MAY treat them as if they are of a 669 supported type with the Certificate Authority field left empty, 670 depending on local policy. ISAKMP Section 5.10 "Certificate Request 671 Payload Processing" specifies additional processing. 673 3.3.10.2. Undecodable Certificate Authority Fields 675 Implementations MUST be able to deal with receiving CERTREQs with 676 undecodable Certificate Authority fields. Implementations MAY treat 677 such fields as if there were empty, depending on local policy. ISAKMP 678 specifies other actions which may be taken. 680 3.3.10.3. Ordering of Certificate Request Payloads 682 Implementations MUST NOT assume that CERTREQs are ordered in any way. 684 3.3.11. Optimizations 686 3.3.11.1. Duplicate Certificate Request Payloads 688 Implementations SHOULD NOT send duplicate CERTREQs during an 689 exchange. 691 3.3.11.2. Name Lowest 'Common' Certification Authorities 693 When a peer's certificate keying materials have been cached, an 694 implementation can send a hint to the peer to elide some of the 695 certificates and CRLs the peer would normally respond with. In 696 addition to the normal set of CERTREQs that are sent specifying the 697 trust anchors, an implementation MAY send CERTREQs containing the 698 Issuer Name of the relevant cached end entity certificates. When 699 sending these hints, it is still necessary to send the normal set of 700 CERTREQs because the hints do not sufficiently convey all of the 701 information required by the peer. Specifically, either the peer may 702 not support this optimization or there may be additional chains that 703 could be used in this context but will not be specified if only 704 supplying the issuer of the end entity certificate. 706 No special processing is required on the part of the recipient of 707 such a CERTREQ, and the end entity certificates will still be sent. 708 On the other hand, the recipient MAY elect to elide certificates 709 based on receipt of such hints. 711 ISAKMP mandates that CERTREQs contain the Subject Name of a 712 Certification Authority, which results in the peer always sending at 713 least the end entity certificate. This mechanism allows 714 implementations to determine unambiguously when a new certificate is 715 being used by the peer, perhaps because the previous certificate has 716 just expired, which will result in a failure because the needed 717 keying materials are not available to validate the new end entity 718 certificate. Implementations which implement this optimization MUST 719 recognize when the end entity certificate has changed and respond to 720 it by not performing this optimization when the exchange is retried. 722 3.3.11.3. Example 724 Imagine that an implementation has previously received and cached the 725 peer certificate chain TA->CA1->CA2->EE. If during a subsequent 726 exchange this implementation sends a CERTREQ containing the Subject 727 Name in certificate TA, this implementation is requesting that the 728 peer send at least 3 certificates: CA1, CA2, and EE. On the other 729 hand, if this implementation also sends a CERTREQ containing the 730 Subject Name of CA2, the implementation is providing a hint that only 731 1 certificate needs to be sent: EE. Note that in this example, that 732 TA is a trust anchor should not be construed to imply that TA is a 733 self-signed certificate. 735 3.4. Certificate Payload 737 3.4.1. Certificate Type 739 The Certificate Type field identifies to the peer the type of 740 certificate keying materials that are included. ISAKMP defines 10 741 types of Certificate Data that can be sent and specifies the syntax 742 for these types. For the purposes of this document, only the 743 following types are relevant: 745 * X.509 Certificate - Signature 746 * X.509 Certificate - Key Exchange 747 * Certificate Revocation List (CRL) 748 * Authority Revocation List (ARL) 749 * PKCS #7 wrapped X.509 certificate 751 For example, if CRLs are desired, an implementation will populate the 752 Certificate Type field with the value associated with "Certificate 753 Revocation List (CRL)". 755 The use of the other types: 757 * PGP Certificate 758 * DNS Signed Key 759 * Kerberos Tokens 760 * SPKI Certificate 761 * X.509 Certificate - Attribute 763 are out of the scope of this document. 765 3.4.2. X.509 Certificate - Signature 767 This type specifies that Certificate Data contains a certificate used 768 for signing, whether an end entity signature certificate or a CA 769 certificate or CRL signing certificate. 771 3.4.3. X.509 Certificate - Key Exchange 773 This type specifies that Certificate Data contains an end entity 774 certificate used for either key exchange (or key encipherment). 776 3.4.4. Certificate Revocation List (CRL) 778 This type specifies that Certificate Data contains an X.509 CRL. 780 3.4.5. Authority Revocation List (ARL) 782 This type specifies that Certificate Data contains an X.509 CRL that 783 revokes CAs. In response to CRL CERTREQs, an implementation MAY 784 include ARLs in an ARL payload to more precisely specify the contents 785 of the CERT payload. Recipients of this type MAY treat it as 786 synonymous with the CRL type. 788 3.4.6. PKCS #7 wrapped X.509 certificate 790 This type defines a particular encoding, not a particular certificate 791 or CRL type. Implementations SHOULD NOT generate CERTs that contain 792 this Certificate Type. Implementations which violate this requirement 793 SHOULD note that this is a single certificate as specified in ISAKMP. 794 Implementations SHOULD accept CERTs that contain this Certificate 795 Type. 797 3.4.7. Certificate Payloads Not Mandatory 799 An implementation which does not receive any CERTREQs during an 800 exchange SHOULD NOT send any CERT payloads, except when explicitly 801 configured to proactively send CERT payloads in order to interoperate 802 with non-compliant implementations. In this case, an implementation 803 MUST send the all certificate chains and CRLs associated with the end 804 entity certificate. This MUST NOT be the default behavior of 805 implementations. 807 Implementations which are configured to expect that a peer must 808 receive certificates through out-of-band means SHOULD ignore any 809 CERTREQ messages that are received. 811 Implementations that receive CERTREQs from a peer which contain only 812 unrecognized Certification Authorities SHOULD NOT continue the 813 exchange, in order to avoid unnecessary and potentially expensive 814 cryptographic processing. 816 3.4.8. Response to Multiple Certificate Authority Proposals 818 In response to multiple CERTREQs which contain different Certificate 819 Authority identities, implementations MAY respond using an end entity 820 certificate which chains to a CA that matches any of the identities 821 provided by the peer. 823 3.4.9. Using Local Keying Materials 825 Implementations MAY elect not to use keying materials contained in a 826 given set of CERTs if preferable keying materials are available. For 827 instance, the contents of a CERT may be available from a previous 828 exchange, or a newer CRL may be available through some out-of-band 829 means. 831 3.4.10. Robustness 833 3.4.10.1. Unrecognized or Unsupported Certificate Types 835 Implementations MUST be able to deal with receiving CERTs with 836 unrecognized or unsupported Certificate Types. Implementations MAY 837 discard such payloads, depending on local policy. ISAKMP Section 5.10 838 "Certificate Request Payload Processing" specifies additional 839 processing. 841 3.4.10.2. Undecodable Certificate Data Fields 843 Implementations MUST be able to deal with receiving CERTs with 844 undecodable Certificate Data fields. Implementations MAY discard such 845 payloads, depending on local policy. ISAKMP specifies other actions 846 which may be taken. 848 3.4.10.3. Ordering of Certificate Payloads 850 Implementations MUST NOT assume that CERTs are ordered in any way. 852 3.4.10.4. Duplicate Certificate Payloads 854 Implementations MUST support receiving multiple identical CERTs 855 during an exchange. 857 3.4.10.5. Irrelevant Certificates 859 Implementations MUST be prepared to receive certificates and CRLs 860 which are not relevant to the current exchange. Implementations MAY 861 discard such extraneous certificates and CRLs. 863 Implementations MAY send certificates which are irrelevant to an 864 exchange. One reason for including certificates which are irrelevant 865 to an exchange is to minimize the threat of leaking identifying 866 information in exchanges where CERT is not encrypted. It should be 867 noted, however, that this probably provides rather poor protection 868 against leaking the identity. 870 3.4.11. Optimizations 872 3.4.11.1. Duplicate Certificate Payloads 874 Implementations SHOULD NOT send duplicate CERTs during an exchange. 875 Such payloads should be suppressed. 877 3.4.11.2. Send Lowest 'Common' Certificates 879 When multiple CERTREQs are received which specify certificate 880 authorities within the end entity certificate chain, implementations 881 MAY send the shortest chain possible. However, implementations SHOULD 882 always send the end entity certificate. See section 3.3.11.2 for more 883 discussion of this optimization. 885 3.4.11.3. Ignore Duplicate Certificate Payloads 887 Implementations MAY employ local means to recognize CERTs that have 888 been received in the past, whether part of the current exchange or 889 not, for which keying material is available and may discard these 890 duplicate CERTs. 892 4. Profile of PKIX 894 4.1. X.509 Certificates 896 4.1.1. Versions 898 Although PKIX states that "implementations SHOULD be prepared to 899 accept any version certificate", in practice this profile requires 900 certain extensions that necessitate the use of Version 3 certificates 901 for all but certain self-signed certificates as trust anchors. 902 Implementations that conform to this document MAY therefore reject 903 Version 1 and Version 2 certificates in all other cases. 905 4.1.2. Subject Name 906 4.1.2.1. Empty Subject Name 908 Implementations MUST accept certificates which contain an empty 909 Subject Name field, as specified in PKIX. Identity information in 910 such certificates will be contained entirely in the SubjectAltName 911 extension. 913 4.1.2.2. Specifying Non-FQDN Hosts in Subject Name 915 Implementations which desire to place host names that are not 916 indended to be processed by recipients as FQDNs (for instance 917 "Gateway Router") in the Subject Name MUST use the commonName 918 attribute. 920 While nothing prevents an FQDN, USER-FQDN, or IP address information 921 from appearing somewhere in the Subject Name contents, with the 922 exception of domainComponent which is discussed below, such entries 923 MUST NOT be interpreted as identity information. 925 4.1.2.3. Specifying FQDN Host Names in Subject Name 927 Implementations SHOULD NOT populate the Subject Name in place of 928 populating the dNSName field of the SubjectAltName extension. 930 Implementations which desire to place resolvable FQDNs (for instance 931 "gateway.example.com") in the Subject Name field instead of the 932 SubjectAltName dNSName field MUST use the domainComponent attribute 933 type, as specified in PKIX. PKIX further specifies that 934 implementations MUST be prepared to receive the domainComponent 935 attribute. The contents of the domainComponent are semantically 936 identical to the contents of the SubjectAltName dNSName field. 938 Note, however, that support for the domainComponent attribute is far 939 from universal and some implementations will reject or fail to 940 display certificates that contain this attribute. 942 4.1.2.4. EmailAddress 944 As specified in PKIX, implementations MUST NOT populate 945 DistinguishedNames with the EmailAddress attribute. 947 4.1.3. X.509 Certificate Extensions 949 Conforming applications MUST recognize extensions which must or may 950 be marked critical according to this specification. These extensions 951 are: KeyUsage, SubjectAltName, and BasicConstraints. 953 Implementations SHOULD generate certificates such that the extension 954 criticality bits are set in accordance with PKIX and this document. 955 With respect to PKIX compliance, implementations processing 956 certificates MAY ignore the value of the criticality bit for 957 extensions that are supported by that implementation, but MUST 958 support the criticality bit for extensions that are not supported by 959 that implementation. That is, if an implementation supports (and thus 960 is going to process) a given extension, then it isn't necessary to 961 reject the certificate if the criticality bit is different from what 962 PKIX states it must be. However, if an implementation does not 963 support an extension that PKIX mandates be critical, then the 964 implementation must reject the certificate. 966 implements bit in cert PKIX mandate behavior 967 ------------------------------------------------------ 968 yes true true ok 969 yes true false ok or reject 970 yes false true ok or reject 971 yes false false ok 972 no true true reject 973 no true false reject 974 no false true reject 975 no false false ok 977 4.1.3.1. AuthorityKeyIdentifier 979 Implementations SHOULD NOT assume that other implementations support 980 the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate 981 certificate hierarchies which overly complex to process in the 982 absence of this extension, such that those that require possibly 983 verifying a signature against a large number of similarly named CA 984 certificates in order to find the CA certificate which contains the 985 key that was used to generate the signature. 987 4.1.3.2. SubjectKeyIdentifier 989 Implementations SHOULD NOT assume that other implementations support 990 the SubjectKeyIdentifier extension, and thus SHOULD NOT generate 991 certificate hierarchies which overly complex to process in the 992 absence of this extension, such that those that require possibly 993 verifying a signature against a large number of similarly named CA 994 certificates in order to find the CA certificate which contains the 995 key that was used to generate the signature. 997 4.1.3.3. KeyUsage 999 The meaning of the nonRepudiation bit is not defined in the context 1000 of IPsec, although implementations SHOULD interpret the 1001 nonRepudiation bit as synonymous with the digitalSignature bit. 1002 Implementations SHOULD NOT generate certificates which only assert 1003 the nonRepudiation bit. 1005 See PKIX for general guidance on which of the other KeyUsage bits 1006 should be set in any given certificate. 1008 4.1.3.4. PrivateKeyUsagePeriod 1010 PKIX recommends against the use of this extension. The 1011 PrivateKeyUsageExtension is intended to be used when signatures will 1012 need to be verified long past the time when signatures using the 1013 private keypair may be generated. Since ISAKMP SAs are short-lived 1014 relative to the intended use of this extension in addition to the 1015 fact that each signature is validated only a single time, the meaning 1016 of this extension in the context of ISAKMP is unclear. Therefore, the 1017 PrivateKeyUsagePeriod is inappropriate in the context of ISAKMP and 1018 therefore implementations MUST NOT generate certificates that contain 1019 the PrivateKeyUsagePeriod extension. 1021 4.1.3.5. Certificate Policies 1023 Many IPsec implementations do not currently provide support for the 1024 Certificate Policies extension. Therefore, implementations that 1025 generate certificates which contain this extension SHOULD mark the 1026 extension as non-critical. 1028 4.1.3.6. PolicyMappings 1030 Many implementations do not support the PolicyMappings extension. 1032 4.1.3.7. SubjectAltName 1034 Implementations SHOULD generate only the following GeneralName 1035 choices in the subjectAltName extension, as these choices map to 1036 legal ISAKMP Identity Payload types: rfc822Name, dNSName, or 1037 iPAddress. Although it is possible to specify any GeneralName choice 1038 in the ISAKMP Identity Payload by using the ID_DER_ASN1_GN ID type, 1039 implementations SHOULD NOT assume that a peer supports such 1040 functionality. 1042 4.1.3.7.1. dNSName 1044 This field MUST contain a fully qualified domain name. 1045 Implementations MUST NOT generate names that contain wildcards. 1047 Implementations MAY treat certificates that contain wildcards in this 1048 field as syntactically invalid. 1050 Although this field is in the form of an FQDN, implementations SHOULD 1051 NOT assume that the this field contains an FQDN that will resolve via 1052 the DNS, unless this is known by way of some out-of-band mechanism. 1053 Such a mechanism is out of the scope of this document. 1054 Implementations SHOULD NOT treat the failure to resolve as an error. 1056 4.1.3.7.2. iPAddress 1058 Note that although PKIX permits CIDR [CIDR] notation in the "Name 1059 Constraints", PKIX explicitly prohibits using CIDR notation for 1060 conveying identity information. In other words, the CIDR notation 1061 MUST NOT be used in the subjectAltName extension. 1063 4.1.3.7.3. rfc822Name 1065 Although this field is in the form of an Internet mail address, 1066 implementations SHOULD NOT assume that the this field contains a 1067 valid email address, unless this is known by way of some out-of-band 1068 mechanism. Such a mechanism is out of the scope of this document. 1070 4.1.3.8. IssuerAltName 1072 Implementations SHOULD NOT assume that other implementations support 1073 the IssuerAltName extension, and especially should not assume that 1074 information contained in this extension will be displayed to end 1075 users. 1077 4.1.3.9. SubjectDirectoryAttributes 1079 The SubjectDirectoryAttributes extension is intended to contain 1080 privilege information, in a manner analogous to privileges carried in 1081 Attribute Certificates. Implementations MAY ignore this extension as 1082 PKIX mandates it be marked non-critical. 1084 4.1.3.10. BasicConstraints 1086 PKIX mandates that CA certificates contain this extension and that it 1087 be marked critical. Implementations SHOULD reject CA certificates 1088 that do not contain this extension. For backwards compatibility, 1089 implementations may accept such certificates if explicitly configured 1090 to do so, but the default for this setting MUST be to reject such 1091 certificates. 1093 4.1.3.11. NameConstraints 1095 Many implementations do not support the NameConstraints extension. 1096 Since PKIX mandates that this extension be marked critical when 1097 present, implementations which intend to be maximally interoperable 1098 SHOULD NOT generate certificates which contain this extension. 1100 4.1.3.12. PolicyConstraints 1102 Many implementations do not support the PolicyConstraints extension. 1103 Since PKIX mandates that this extension be marked critical when 1104 present, implementations which intend to be maximally interoperable 1105 SHOULD NOT generate certificates which contain this extension. 1107 4.1.3.13. ExtendedKeyUsage 1109 No ExtendedKeyUsage usages are defined for IPsec, so if this 1110 extension is present and marked critical, use of this certificate for 1111 IPsec MUST be treated as an error. Implementations MUST NOT generate 1112 this extension in certificates which are being used for IPsec. 1114 Note that a previous proposal for the use of three ExtendedKeyUsage 1115 values is obsolete and explicitly deprecated by this specification. 1116 For historical reference, those values were id-kp-ipsecEndSystem, id- 1117 kp-ipsecTunnel, and id-kp-ipsecUser. 1119 4.1.3.14. CRLDistributionPoint 1121 Most implementations expect to exchange CRLs in band via the ISAKMP 1122 Certificate Payload. Implementations MUST NOT assume that the 1123 CRLDistributionPoint extension will exist in peer extensions and 1124 therefore implementations SHOULD request that peers send CRLs in the 1125 absence of knowledge that this extension exists in the peer's 1126 certificates. 1128 However receiving CRLs in band via ISAKMP does not alleviate the 1129 requirement to process the CRLDistributionPoint if the certificate 1130 being validated contains the extension and the CRL being used to 1131 validate the certificate contains the IssuingDistributionPoint. 1132 Failure to validate the 1133 CRLDistributionPoint/IssusingDistributionPoint pair can result in CRL 1134 substitution where an entity knowingly substitutes a known good CRL 1135 for the CRL which is supposed to be used which would show the entity 1136 as revoked. 1138 Implementations MUST support validating that the contents of 1139 CRLDistributionPoints match those of the IssuingDistributionPoint to 1140 prevent CRL substitution when the issuing CA is using them. At least 1141 one CA is known to default to this type of CRL use. See section 1142 4.2.3.5 for more information. 1144 See PKIX docs for CRLDistributionPoints intellectual rights 1145 information. 1147 4.1.3.15. InhibitAnyPolicy 1149 Many implementations do not support the InhibitAnyPolicy extension. 1150 Since PKIX mandates that this extension be marked critical when 1151 present, implementations which intend to be maximally interoperable 1152 SHOULD NOT generate certificates which contain this extension. 1154 4.1.3.16. FreshestCRL 1156 Most implementations expect to exchange CRLs in band via the ISAKMP 1157 Certificate Payload. Implementations MUST NOT assume that the 1158 FreshestCRL extension will exist in peer extensions and therefore 1159 implementations SHOULD request that peers send CRLs in the absence 1160 knowledge that this extension exists in the peer certificates. Note 1161 that most implementations do not support delta CRLs. 1163 4.1.3.17. AuthorityInfoAccess 1165 PKIX defines the AuthorityInfoAccess extension, which is used to 1166 indicate "how to access CA information and services for the issuer of 1167 the certificate in which the extension appears." This extension has 1168 no known use in the context of IPsec. Conformant implementations 1169 SHOULD ignore this extension when present. 1171 4.1.3.18. SubjectInfoAccess 1173 PKIX defines the SubjectInfoAccess private certificate extension, 1174 which is used to indicate "how to access information and services for 1175 the subject of the certificate in which the extension appears." This 1176 extension has no known use in the context of IPsec. Conformant 1177 implementations SHOULD ignore this extension when present. 1179 4.2. X.509 Certificate Revocation Lists 1181 Implementations SHOULD send CRLs, unless non-CRL certificate 1182 revocation information is known to be preferred by all interested 1183 parties in the application environment that the implementation is 1184 used. Implementations MUST send CRLs if non-CRL certificate 1185 revocation information may not be available to all interested 1186 parties. 1188 4.2.1. Certificate Revocation Requirement 1190 Implementations which validate certificates MUST make use of 1191 certificate revocation information, and SHOULD support such 1192 revocation information in the form of CRLs, unless non-CRL revocation 1193 information is known to be the only method for transmitting this 1194 information. 1196 4.2.2. Multiple Sources of Certificate Revocation Information 1198 Implementations which support multiple sources of obtaining 1199 certificate revocation information MUST act conservatively when the 1200 information provided by these sources is inconsistent: when a 1201 certificate is reported as revoked by one source, the certificate 1202 MUST be considered revoked. 1204 4.2.3. X.509 Certificate Revocation List Extensions 1206 4.2.3.1. AuthorityKeyIdentifier 1208 Implementations SHOULD NOT assume that other implementations support 1209 the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate 1210 certificate hierarchies which overly complex to process in the 1211 absence of this extension. 1213 4.2.3.2. IssuerAltName 1215 Implementations SHOULD NOT assume that other implementations support 1216 the IssuerAltName extension, and especially should not assume that 1217 information contained in this extension will be displayed to end 1218 users. 1220 4.2.3.3. CRLNumber 1222 As stated in PKIX, all issuers conforming to PKIX MUST include this 1223 extension in all CRLs. 1225 4.2.3.4. DeltaCRLIndicator 1227 4.2.3.4.1. If Delta CRLs Are Unsupported 1229 Implementations that do not support delta CRLs MUST reject CRLs which 1230 contain the DeltaCRLIndicator (which MUST be marked critical 1231 according to PKIX) and MUST make use of a base CRL if it is 1232 available. Such implementations MUST ensure that a delta CRL does not 1233 "overwrite" a base CRL, for instance in the keying material database. 1235 4.2.3.4.2. Delta CRL Recommendations 1237 Since some implementations that do not support delta CRLs may behave 1238 incorrectly or insecurely when presented with delta CRLs, 1239 implementations SHOULD consider whether issuing delta CRLs increases 1240 security before issuing such CRLs. 1242 The authors are aware of several implementations which behave in an 1243 incorrect or insecure manner when presented with delta CRLs. See 1244 Appendix B for a description of the issue. Therefore, this 1245 specification RECOMMENDS against issuing delta CRLs at this time. On 1246 the other hand, failure to issue delta CRLs exposes a larger window 1247 of vulnerability. See the Security Considerations section of PKIX for 1248 additional discussion. Implementors as well as administrators are 1249 encouraged to consider these issues. 1251 4.2.3.5. IssuingDistributionPoint 1253 A CA that is using CRLDistributionPoints may do so to provide many 1254 "small" CRLs, each only valid for a particular set of certificates 1255 issued by that CA. To associate a CRL with a certificate, the CA 1256 places the CRLDistributionPoint extension in the certificate, and 1257 places the IssuingDistributionPoint in the CRL. The 1258 distributionPointName field in the CRLDistributionPoint extension and 1259 the MUST be identical to the distributionPoint field in the 1260 IssuingDistributionPoint extension. At least one CA is known to 1261 default to this type of CRL use. See section 4.1.3.14 for more 1262 information. 1264 4.2.3.6. FreshestCRL 1266 Given the recommendations against implementations generating delta 1267 CRLs, this specification RECOMMENDS that implementations do not 1268 populate CRLs with the FreshestCRL extension, which is used to obtain 1269 delta CRLs. 1271 5. Configuration Data Exchange Conventions 1273 Below we present a common format for exchanging configuration data. 1274 Implementations MUST support these formats, MUST support arbitrary 1275 whitespace at the beginning and end of any line, MUST support 1276 arbitrary line lengths, and MUST support the three line-termination 1277 disciplines: LF (US-ASCII 10), CR (US-ASCII 13), and CRLF. 1279 5.1. Certificates 1280 Certificates MUST be Base64 encoded and appear between the following 1281 delimiters: 1283 -----BEGIN CERTIFICATE----- 1285 -----END CERTIFICATE----- 1287 5.2. Public Keys 1289 Implementations MUST support two forms of public keys: certificates 1290 and so-called "raw" keys. Certificates should be transferred in the 1291 same form as above. A raw key is only the SubjectPublicKeyInfo 1292 portion of the certificate, and MUST be Base64 encoded and appear 1293 between the following delimiters: 1295 -----BEGIN PUBLIC KEY----- 1297 -----END PUBLIC KEY----- 1299 5.3. PKCS#10 Certificate Signing Requests 1301 A PKCS#10 [PKCS-10] Certificiate Signing Request MUST be Base64 1302 encoded and appear between the following delimeters: 1304 -----BEGIN CERTIFICATE REQUEST----- 1306 -----END CERTIFICATE REQUEST----- 1308 6. IKE 1310 6.1. IKE Phase 1 Authenticated With Signatures 1312 6.1.1. Identification Payload 1314 IKE mandates the use of the ID payload in Phase 1. 1316 Implementations SHOULD populate ID with identity information that is 1317 contained within the end entity certificate. This enables recipients 1318 to use ID as a lookup key to find the peer end entity certificate. 1319 The only case where implementations MAY populate ID with information 1320 that is not contained in the end entity certificate is when ID 1321 contains the peer source address (a single address, not a subnet or 1322 range). This means that implementations MUST be able to map a peer 1323 source address to a peer end entity certificate, even when the 1324 certificate does not contain that address. The exact method for 1325 performing this mapping is out of the scope of this document. 1327 6.1.2. X.509 Certificate Extensions 1329 6.1.2.1. KeyUsage 1331 If the KeyUsage extension is present in an end entity certificate, 1332 the digitalSignature bit MUST be asserted, or if no other bits but 1333 the nonRepudiation bit are asserted and the certificate is being used 1334 to generate a signature, an implementation MAY interpret the 1335 nonRepudiation bit as synonymous with the digitalSignature. 1337 6.1.3. Obtaining Peer Certificates and CRLs 1339 IKE implementations MUST assume all necessary certificates and CRLs 1340 will be exchanged in-band. 1342 6.2. IKE Phase 1 Authenticated With Public Key Encryption 1344 6.2.1. Identification Payload 1346 IKE mandates the use of the ID payload in Phase 1. 1348 If certificates are not being used, the contents of ID are out of 1349 scope for this document. 1351 6.2.2. Hash Payload 1353 IKE specifies the optional use of the Hash Payload to carry a pointer 1354 to a certificate in either of the Phase 1 public key encryption 1355 modes. This pointer is used by an implementation to locate the end 1356 entity certificate that contains the public key that a peer should 1357 use for encrypting payloads during the exchange. 1359 Implementations SHOULD include this payload whenever the public 1360 portion of the keypair has been placed in a certificate. 1362 6.2.3. X.509 Certificate Extensions 1364 6.2.3.1. KeyUsage 1366 If the KeyUsage extension is present in an end entity certificate, 1367 the keyEncipherment bit MUST be asserted, or if no other bits but the 1368 nonRepudiation bit are asserted and the certificate is being used for 1369 key encipherment, an implementation MAY interpret the nonRepudiation 1370 bit as synonymous with the keyEncipherment. 1372 6.2.4. Obtaining Peer Certificates and CRLs 1374 Certificates are generally not exchanged in-band, but rather are 1375 exchanged out-of-band, with direct trust of the peer certificate 1376 being most prevalent. CRLs SHOULD be obtained out-of-band from a 1377 directory or other repository. 1379 6.3. IKE Phase 1 Authenticated With a Revised Mode of Public Key 1380 Encryption 1382 IKE Phase 1 Authenticated With a Revised Mode of Public Key 1383 Encryption has the same requirements as IKE Phase 1 Authenticated 1384 With Public Key Encryption. See section 6.2 for these requirements. 1386 7. Security Considerations 1388 7.1. Identity Payload 1390 Depending on the exchange type, ID may be passed in the clear. 1391 Administrators in some environments may wish to use the empty 1392 Certification Authority option to prevent such information from 1393 leaking, at the possible cost of some performance, although such use 1394 is discouraged. 1396 7.2. Certificate Request Payload 1398 The Contents of CERTREQ are not encrypted in IKE. In some 1399 environments this may leak private information. Administrators in 1400 some environments may wish to use the empty Certification Authority 1401 option to prevent such information from leaking, at the cost of 1402 performance. 1404 7.3. Certificate Payload 1406 Depending on the exchange type, CERTs may be passed in the clear and 1407 therefore may leak identity information. 1409 7.4. IKE Main Mode 1411 Implementations may not wish to respond with CERTs in the second 1412 message, thereby violating the identity protection feature of Main 1413 Mode IKE. ISAKMP allows CERTs to be included in any message, and 1414 therefore implementations may wish to respond with CERTs in a message 1415 that offers privacy protection in this case. 1417 7.5. IKE Aggressive Mode 1419 The contents of ID are not encrypted in Aggressive Mode when 1420 authentication is performed with signatures. In some environments 1421 this may leak private information. The solutions to this problem if 1422 such a leak is unacceptable are: 1424 * Use Main Mode instead of Aggressive Mode. 1425 * Populate ID Data with the address of the host. 1427 The contents of CERT are not encrypted in Aggressive Mode when 1428 authentication is performed with signatures. In some environments 1429 this may leak private information. The solutions to this problem if 1430 such a leak is unacceptable are: 1432 * Use Main Mode instead of Aggressive Mode. 1434 8. Intellectual Property Rights 1436 No new intellectual property rights are introduced by this document. 1438 9. IANA Considerations 1440 There are no known numbers which IANA will need to manage. 1442 10. Normative References 1444 [DOI] Piper, D., "The Internet IP Security Domain of 1445 Interpretation for ISAKMP", RFC 2407, November 1998. 1447 [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange 1448 (IKE)", RFC 2409, November 1998. 1450 [IPSEC] Kent, S. and Atkinson, R., "Security Architecture for the 1451 Internet Protocol", RFC 2401, November 1998. 1453 [ISAKMP] Maughan, D., et. al., "Internet Security Association and 1454 Key Management Protocol (ISAKMP)", RFC 2408, November 1998. 1456 [PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax 1457 Version 1.5", RFC 2314, March 1998. 1459 [PKIX] Housley, R., et al., "Internet X.509 Public Key 1460 Infrastructure Certificate and Certificate Revocation 1461 List (CRL) Profile", RFC 3280, April 2002. 1463 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1464 September 1981. 1466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1467 Requirement Levels", BCP 14, RFC 2119, March 1997. 1469 11. Informational References 1471 [CIDR] Fuller, V., et al., "Classless Inter-Domain Routing (CIDR): 1472 An Address Assignment and Aggregation Strategy", RFC 1519, 1473 September 1993. 1475 [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", 1476 RFC 2535, March 1999. 1478 [RFC1883] Deering, S. and Hinden, R. "Internet Protocol, Version 6 1479 (IPv6) Specification", RFC 1883, December 1995. 1481 [ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap", 1482 draft-ietf-pkix-roadmap-08.txt. 1484 [SBGP] Lynn, C., Kent, S., and Seo, K., "X.509 Extensions for 1485 IP Addresses and AS Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-00.txt. 1487 12. Acknowledgements 1489 The authors would like to acknowledge the expired draft-ietf-ipsec- 1490 pki-req-05.txt for providing valuable materials for this document. 1491 The authors would like to especially thank Greg Carter and Russ 1492 Housley for their valuable comments, some of which have been 1493 incorporated unchanged into this document. 1495 13. Author's Addresses 1497 Brian Korver 1498 Xythos Software, Inc. 1499 25 Maiden Lane, 6th Floor 1500 San Francisco, CA 94108 1501 USA 1502 Phone: +1 415 248-3800 1503 EMail: briank@xythos.com 1505 Eric Rescorla 1506 RTFM, Inc. 1507 2064 Edgewood Drive 1508 Palo Alto, CA 94303 1509 USA 1510 Phone: +1 650 320-8549 1511 EMail: ekr@rtfm.com 1512 Copyright (C) The Internet Society (2003). All Rights Reserved. 1514 This document and translations of it may be copied and furnished to 1515 others, and derivative works that comment on or otherwise explain it 1516 or assist in its implementation may be prepared, copied, published 1517 and distributed, in whole or in part, without restriction of any 1518 kind, provided that the above copyright notice and this paragraph are 1519 included on all such copies and derivative works. However, this 1520 document itself may not be modified in any way, such as by removing 1521 the copyright notice or references to the Internet Society or other 1522 Internet organizations, except as needed for the purpose of 1523 developing Internet standards in which case the procedures for 1524 copyrights defined in the Internet Standards process must be 1525 followed, or as required to translate it into languages other than 1526 English. 1528 The limited permissions granted above are perpetual and will not be 1529 revoked by the Internet Society or its successors or assigns. 1531 This document and the information contained herein is provided on an 1532 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1533 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1534 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1535 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1536 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1538 Acknowledgement 1540 Funding for the RFC Editor function is currently provided by the 1541 Internet Society. 1543 Appendix A. Change History 1545 * June 2003 (-03) 1547 Minor editorial changes to clean up language 1549 Minor additional clarifying text 1551 Removed hyphenation 1553 Added requirement that implementations support configuration data 1554 exchange having arbitrary line lengths 1555 * February 2003 (-02) 1557 Word choice: move from use of "root" to "trust anchor", in 1558 accordance with PKIX 1560 SBGP note and reference for placing address subnet and range 1561 information into certificates 1563 Clarification of text regarding placing names of hosts into the 1564 Name commonName attribute of SubjectName 1566 Added table to clarify text regarding processing of the 1567 certificate extension criticality bit 1569 Added text underscoring processing requirements for 1570 CRLDistributionPoints and IssuingDistributionPoint 1572 * October 2002, Reorganization (-01) 1573 * June 2002, Initial Draft (-00) 1575 Appendix B. The Possible Dangers of Delta CRLs 1577 The problem is that the CRL processing algorithm is often written 1578 with the assumption that all CRLs are base CRLs and it is assumed 1579 that CRLs will pass content validity tests. Specifically, such 1580 implementations fail to check the certificate against all possible 1581 CRLs: if the first CRL that is obtained from the keying material 1582 database fails to decode, no further revocation checks are performed 1583 for the relevant certificate. This problem is compounded by the fact 1584 that implementations which do not understand delta CRLs may fail to 1585 decode such CRLs due to the critical DeltaCRLIndicator extension. The 1586 algorithm that is implemented in this case is approximately: 1588 fetch newest CRL 1589 check validity of CRL signature 1590 if CRL signature is valid then 1591 if CRL does not contain unrecognized critical extensions 1592 and certificate is on CRL then 1593 set certificate status to revoked 1595 The authors note that a number of PKI toolkits do not even provide a 1596 method for obtaining anything but the newest CRL, which in the 1597 presence of delta CRLs may in fact be a delta CRL, not a base CRL.