idnits 2.17.1 draft-ietf-ipsec-pki-profile-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 139 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 285 has weird spacing: '... of endpoin...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: As another example, if the IP address of the peer is recognized to be a known peer VPN endpoint, the general policy and the identity-based policy may be identical, but until the identity is validated, the policy MUST not be used to authorize any IPsec traffic. -- 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) == Missing Reference: 'RFC 791' is mentioned on line 323, but not defined == Unused Reference: 'ROADMAP' is defined on line 1369, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 2535 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** 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 3280 (ref. 'PKIX') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) == Outdated reference: A later version (-09) exists of draft-ietf-pkix-roadmap-08 ** Downref: Normative reference to an Informational draft: draft-ietf-pkix-roadmap (ref. 'ROADMAP') Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 2 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 October 2002 (Expires April 2003) 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 mate- 21 rial 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 specifica- 36 tions such as IKE, which assume the existence of public key certifi- 37 cates and related keying materials, but which do not address PKI 38 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_ADD... 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 Poli... 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 10 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 12 75 3.3.7 Presence or Absence of Certificate Request Payloads 12 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 13 80 3.3.9.1 Specifying Certificate Authorities 13 81 3.3.9.2 Empty Certificate Authority Field 13 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 14 85 3.3.10.3 Ordering of Certificate Request Payloads 14 86 3.3.11 Optimizations 14 87 3.3.11.1 Duplicate Certificate Request Payloads 14 88 3.3.11.2 Name Lowest 'Common' Certification Authorities 14 89 3.3.11.3 Example 15 90 3.4 Certificate Payload 15 91 3.4.1 Certificate Type 15 92 3.4.2 X.509 Certificate - Signature 16 93 3.4.3 X.509 Certificate - Key Exchange 16 94 3.4.4 Certificate Revocation List (CRL) 16 95 3.4.5 Authority Revocation List (ARL) 16 96 3.4.6 PKCS #7 wrapped X.509 certificate 16 97 3.4.7 Certificate Payloads Not Mandatory 16 98 3.4.8 Response to Multiple Certificate Authority Proposals... 17 99 3.4.9 Using Local Keying Materials 17 100 3.4.10 Robustness 17 101 3.4.10.1 Unrecognized or Unsupported Certificate Types 17 102 3.4.10.2 Undecodable Certificate Data Fields 17 103 3.4.10.3 Ordering of Certificate Payloads 17 104 3.4.10.4 Duplicate Certificate Payloads 18 105 3.4.10.5 Irrelevant Certificates 18 106 3.4.11 Optimizations 18 107 3.4.11.1 Duplicate Certificate Payloads 18 108 3.4.11.2 Send Lowest 'Common' Certificates 18 109 3.4.11.3 Drop Duplicate Certificate Payloads 18 110 4 Profile of PKIX 18 111 4.1 X.509 Certificates 18 112 4.1.1 Versions 19 113 4.1.2 Subject Name 19 114 4.1.2.1 Empty Subject Name 19 115 4.1.2.2 Specifying Hosts in Subject Name 19 116 4.1.2.2.1 Non-FQDN Host Names 19 117 4.1.2.2.2 FQDN Host Names 19 118 4.1.2.3 EmailAddress 19 119 4.1.3 X.509 Certificate Extensions 20 120 4.1.3.1 AuthorityKeyIdentifier 20 121 4.1.3.2 SubjectKeyIdentifier 20 122 4.1.3.3 KeyUsage 20 123 4.1.3.4 PrivateKeyUsagePeriod 20 124 4.1.3.5 Certificate Policies 21 125 4.1.3.6 PolicyMappings 21 126 4.1.3.7 SubjectAltName 21 127 4.1.3.7.1 Permitted Choices 21 128 4.1.3.7.1.1 dNSName 21 129 4.1.3.7.1.2 iPAddress 21 130 4.1.3.7.1.3 rfc822Name 22 131 4.1.3.8 IssuerAltName 22 132 4.1.3.9 SubjectDirectoryAttributes 22 133 4.1.3.10 BasicConstraints 22 134 4.1.3.11 NameConstraints 22 135 4.1.3.12 PolicyConstraints 22 136 4.1.3.13 ExtendedKeyUsage 22 137 4.1.3.14 CRLDistributionPoint 23 138 4.1.3.15 InhibitAnyPolicy 23 139 4.1.3.16 FreshestCRL 23 140 4.1.3.17 AuthorityInfoAccess 23 141 4.1.3.18 SubjectInfoAccess 23 142 4.2 X.509 Certificate Revocation Lists 23 143 4.2.1 Certificate Revocation Requirement 24 144 4.2.2 Multiple Sources of Certificate Revocation Informatio... 24 145 4.2.3 X.509 Certificate Revocation List Extensions 24 146 4.2.3.1 AuthorityKeyIdentifier 24 147 4.2.3.2 IssuerAltName 24 148 4.2.3.3 CRLNumber 24 149 4.2.3.4 DeltaCRLIndicator 24 150 4.2.3.4.1 If Delta CRLs Are Unsupported 24 151 4.2.3.4.2 Delta CRL Recommendations 25 152 4.2.3.5 IssuingDistributionPoint 25 153 4.2.3.6 FreshestCRL 25 154 5 Configuration Data Exchange Conventions 25 155 5.1 Certificates 25 156 5.2 Public Keys 26 157 5.3 PKCS#10 Certificate Signing Requests 26 158 6 IKE 26 159 6.1 IKE Phase 1 Authenticated With Signatures 26 160 6.1.1 Identification Payload 26 161 6.1.2 X.509 Certificate Extensions 26 162 6.1.2.1 KeyUsage 26 163 6.1.3 Obtaining Peer Certificates and CRLs 27 164 6.2 IKE Phase 1 Authenticated With Public Key Encryption... 27 165 6.2.1 Identification Payload 27 166 6.2.2 Hash Payload 27 167 6.2.3 X.509 Certificate Extensions 27 168 6.2.3.1 KeyUsage 27 169 6.2.4 Obtaining Peer Certificates and CRLs 27 170 6.3 IKE Phase 1 Authenticated With a Revised Mode of Publ... 27 171 7 Security Considerations 28 172 7.1 Identity Payload 28 173 7.2 Certificate Request Payload 28 174 7.3 Certificate Payload 28 175 7.4 IKE Main Mode 28 176 7.5 IKE Aggressive Mode 28 177 8 Intellectual Property Rights 29 178 9 IANA Considerations 29 180 1. Introduction 182 IKE [IKE] and ISAKMP [ISAKMP] provide a secure key exchange mechanism 183 for use with IPsec [IPSEC]. In many cases the peers authenticate 184 using digital certificates as specified in PKIX [PKIX]. Unfortu- 185 nately, the combination of these standards leads to an underspecified 186 set of requirements for the use of certificates in the context of 187 IPsec. 189 ISAKMP references PKIX but in many cases merely specifies the con- 190 tents of various messages without specifying their syntax or seman- 191 tics. Meanwhile, PKIX provides a large set of certificate mechanisms 192 which are generally applicable for Internet protocols, but little 193 specific guidance for IPsec. Given the numerous underspecified 194 choices, interoperability is hampered if all implementors do not make 195 similar choices, or at least fail to account for implementations 196 which have choosen differently. 198 This profile of the ISAKMP and PKIX frameworks is intended to provide 199 an agreed upon standard for using PKI technology in the context of 200 IPsec by profiling the PKIX framework for use with ISAKMP and IPsec, 201 and by documenting the contents of the relevant ISAKMP payloads and 202 further specifying their semantics. 204 In addition to providing a profile of ISAKMP and PKIX, this document 205 attempts to incorporate lessons learned from recent experience with 206 both implementation and deployment, as well as the current state of 207 related protocols and technologies. 209 Material from ISAKMP and PKIX is not repeated here, and readers of 210 this document are assumed to have read and understood both documents. 211 The requirements and security aspects of those documents are fully 212 relevant to this document as well. 214 Version "01" of this document is intended as a "straw man" to encour- 215 age comments from implementors of IPsec and to encourage discussion 216 of the issues which the authors hope to address this document. 218 This document is being discussed on the ipsec@lists.tislabs.com mail- 219 ing list, which is the mailing list for the IPsec Working Group. 221 2. Terms and Definitions 223 Except for those terms which are defined immediately below, all PKI 224 terms used in this document are defined in either the PKIX, ISAKMP, 225 or DOI [DOI] documents. 227 * Peer source address: The source address in packets from a peer. 228 This address may be different from any addresses asserted as the 229 "identity" of the peer. 230 * FQDN: Fully qualified domain name. 231 * Root CA: A CA that is directly trusted by an end entity. 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in RFC-2119 [RFC2119]. 237 3. Profile of ISAKMP 239 3.1. Background 241 3.1.1. Certificate-Related Payloads in ISAKMP 243 ISAKMP has three primary certificate-related payloads: Identifica- 244 tion, Certificate, and Certificate Request. Additionally, IKE speci- 245 fies the optional use of the Hash Payload to carry a pointer to a 246 certificate in either of the Phase 1 public key encryption modes. In 247 this section we provide a short introduction to these payload types. 249 3.1.1.1. Identification Payload 251 The Identification (ID) Payload is used to indicate the identity that 252 the agent claims to be speaking for. The receiving agent can then use 253 the ID as a lookup key for policy and whatever certificate store or 254 directory that it has available. Our primary concern in this document 255 is to profile the ID payload so that it can be safely used to gener- 256 ate or lookup policy. 258 3.1.1.2. Certificate Payload 260 The Certificate (CERT) Payload allows the peer to transmit a single 261 certificate or CRL. Multiple certificates are transmitted in multiple 262 payloads. However, not all certificate forms that are legal in PKIX 263 make sense in the context of ISAKMP or IPsec. The issue of how to 264 represent ISAKMP-meaningful name-forms in a certificate is especially 265 problematic. This memo provides a profile for a subset of PKIX that 266 makes sense for ISAKMP. 268 3.1.1.3. Certificate Request Payload 270 The Certificate Request (CERTREQ) Payload allows an ISAKMP implemen- 271 tation to request that a peer provide some set of certificates or 272 certificate revocation lists. It is not clear from ISAKMP exactly how 273 that set should be specified or how the peer should respond. We 274 describe the semantics on both sides. 276 3.1.1.4. Hash Payload 278 The Hash (HASH) Payload is a generic mechanism for ISAKMP implementa- 279 tions to communicate hash values to a peer. The meaning of the con- 280 tents of such payloads is left undefined by ISAKMP. 282 3.1.2. Endpoint Identification 284 ISAKMP contains two different payloads that allow the specification 285 of endpoint identity, the ID payload and the CERT payload. According 286 to ISAKMP, these payloads can be used separately or together, 287 although specific profiles of ISAKMP may place additional require- 288 ments on implementations. 290 3.1.2.1. Identification Payload Only 292 If one peer presents only the ID payload, it is expected that the 293 peer will be able to recover whatever keying material is required to 294 verify the peer's identity. How to do so is out of the scope of this 295 document but might include a local cache, an LDAP directory, or DNS. 297 3.1.2.2. Certificate Payload Only 299 If a peer presents only a CERT payload, this creates an ambiguity, 300 since ISAKMP does not specify which of potentially many certificates 301 corresponds to the end-entity and which are chaining certificates. 302 Implementations SHOULD compare whatever local hints they have about 303 peer identity to each certificate until they find one that appears 304 acceptable. 306 3.2. Identification Payload 308 The ID payload requirements in this document cover only the portion 309 of the explicit policy checks that deal with the Identity Payload 310 specifically. For instance, in the case where ID does not contain an 311 IP address, checks such as verifying that the peer source address is 312 permitted by the relevant policy are not addressed here as they are 313 out of the scope of this document. 315 The [DOI] defines the 11 types of Identification Data that can be 316 used and specifies the syntax for these types. All of these are dis- 317 cussed immediately below. 319 3.2.1. ID_IPV4_ADDR and ID_IPV6_ADDR 321 Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR 322 ID type. These addresses MUST be stored in "network byte order," as 323 specified in [RFC 791]. The least significant bit (LSB) of each octet 324 is the LSB of the corresponding byte in the network address. For the 325 ID_IPV4_ADDR type, the payload MUST contain exactly four octets 326 [RFC791]. For the ID_IPV6_ADDR type, the payload MUST contain exactly 327 sixteen octets [RFC1883]. When comparing the contents of ID with the 328 iPAddress field in the subjectAltName extension for equality, binary 329 comparison is performed. 331 3.2.2. ID_FQDN 333 Implementations MAY support the ID_FQDN ID type, generally to support 334 host-based access control lists for hosts without fixed IP addresses. 335 However, implementations SHOULD NOT use the DNS to map the FQDN to IP 336 addresses for input into any policy decisions, unless that mapping is 337 known to be secure, such as when [DNSSEC] is employed. When comparing 338 the contents of ID with the dNSName field in the subjectAltName 339 extension for equality, caseless string comparison is performed. Sub- 340 string, wildcard, or regular expression matching MUST NOT be per- 341 formed. 343 3.2.3. ID_USER_FQDN 345 Implementations MAY support the ID_USER_FQDN ID type, generally to 346 support user-based access control lists for users without fixed IP 347 addresses. However, implementations SHOULD NOT use the DNS to map the 348 FQDN portion to IP addresses for input into any policy decisions, 349 unless that mapping is known to be secure, such as when [DNSSEC] is 350 employed. When comparing the contents of ID with the rfc822Name field 351 in the subjectAltName extension for equality, caseless string compar- 352 ison is performed. Substring, wildcard, or regular expression match- 353 ing MUST NOT be performed. 355 3.2.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, 356 ID_IPV6_ADDR_RANGE 358 As there is currently no standard method for putting address subnet 359 or range identity information into certificates, the use of these ID 360 types is currently undefined. 362 3.2.5. ID_DER_ASN1_DN 364 Implementations MAY support receiving the ID_DER_ASN1_DN ID type, 365 although implementations SHOULD NOT generate this type. Implementa- 366 tions which generate this type SHOULD populate the contents of ID 367 with the Subject Name from the end entity certificate, and MUST do so 368 such that a binary comparison of the two will succeed. For instance, 369 if the certificate was erroneously created such that the encoding of 370 the Subject Name DN varies from the constraints set by DER, that non- 371 conformant DN that MUST be used to populate the ID payload: implemen- 372 tations MUST NOT re-encode the DN for the purposes of making it DER 373 if it does not appear in the certificate as DER. Implementations MUST 374 NOT populate ID with the Subject Name from the end entity certificate 375 if it is empty, as described in the "Subject" section of PKIX. 377 3.2.6. ID_DER_ASN1_GN 379 Implementations MAY support the ID_DER_ASN1_GN ID type, although 380 implementations SHOULD NOT generate this type unless it is known 381 through out-of-band means that the peer is capable of understanding 382 this type. Implementations which generate this type MUST populate the 383 contents of ID with the a GeneralName from the SubjectAltName exten- 384 sion in the end entity certificate, and MUST do so such that a binary 385 comparison of the two will succeed. For instance, if the certificate 386 was erroneously created such that the encoding of the GeneralName 387 varies from the constraints set by DER, that non- conformant General- 388 Name MUST be used to populate the ID payload: implementations MUST 389 NOT re-encode the GeneralName for the purposes of making it DER if it 390 does not appear in the certificate as DER. 392 3.2.7. ID_KEY_ID 394 Type ID_KEY_ID type used to specify pre-shared keys and thus is not 395 relevant to this document. 397 3.2.8. Using Peer Source IP Address to Bind Identity to Policy 399 Because implementations sometimes use ID as a lookup key to determine 400 which policy to use, all implementations MUST be especially careful 401 to verify the truthfulness of the contents by verifying that they 402 correspond to some keying material demonstrably held by the peer. 403 Failure to do so may result in the use of an inappropriate or inse- 404 cure policy. The following sections describe the methods for perform- 405 ing this binding. 407 Implementations MAY use the IP address found in the header of packets 408 received from the peer to lookup the policy, but such implementations 409 MUST still perform verification of the ID payload. Although packet IP 410 addresses are inherently untrustworthy and must therefore be indepen- 411 dently verified, it is often useful to use the apparent IP address of 412 the peer to locate a general class of policies that will be used 413 until the mandatory identity-based policy lookup can be performed. 415 For instance, if the IP address of the peer is unrecognized, a VPN 416 gateway device might load a general "road warrior" policy that speci- 417 fies a particular CA that is trusted to issue certificates which con- 418 tain a valid rfc822Name which can be used by that implementation to 419 perform authorization based on access control lists (ACLs). The 420 rfc822Name can then be used to determine the policy that provides 421 specific authorization to access resources (such as IP addresses, 422 ports, and so forth). 424 As another example, if the IP address of the peer is recognized to be 425 a known peer VPN endpoint, the general policy and the identity-based 426 policy may be identical, but until the identity is validated, the 427 policy MUST not be used to authorize any IPsec traffic. 429 As a general comment, however, it may be easier to spoof the contents 430 of an ID payload than it is to spoof a peer source address because 431 the peer source address must exist on the route to the peer, while ID 432 can contain essentially random identification information. Implemen- 433 tations MUST validate the Identity Data provided by a peer, but 434 implementations MAY favor unauthenticated peer source addresses over 435 an unauthenticated ID for initial policy lookup. 437 3.2.9. Securely Binding Identity to Policy 439 3.2.9.1. Single Address Identification Data 441 In the case where ID contains ID_IPV4_ADDR or ID_IPV6_ADDR (that is, 442 is not an address range or subnet), implementations MUST verify that 443 this address is the same as the peer source address. If the end 444 entity certificate contains addresses identities, then the peer 445 source address must match at least one of those identities. If either 446 of the above do not match, this MUST be treated as an error and secu- 447 rity association setup MUST be aborted. This event SHOULD be 448 auditable. The definition of "match" is specific to each ID type and 449 was discussed above. In addition, implementations MUST allow adminis- 450 trators to configure a local policy that requires that the peer 451 source address exist in the certificate. Implementations SHOULD allow 452 administrators to configure a local policy that does not enforce this 453 requirement. 455 3.2.9.2. Identification Data other than a Single Address 457 In the case where ID contains an identity type other than a single 458 address, implementations MUST verify that the identity contained in 459 the ID payload matches identity information contained in the peer end 460 entity certificate, either in the Subject Name field or subjectAlt- 461 Name extension. If there is not a match, this MUST be treated as an 462 error and security association setup MUST be aborted. This event 463 SHOULD be auditable. The definition of "match" is specific to each ID 464 type and was discussed above. 466 3.2.10. Selecting an Identity from a Certificate 468 Implementations MUST support certificates that contain more than a 469 single identity. In many cases a certificate will contain an identity 470 such as an IP address in the subjectAltName extension in addition to 471 a non-empty Subject Name. 473 Which identity an implementations chooses to populate ID with is a 474 local matter. For compatibility with non-conformant implementations, 475 implementations SHOULD populate ID with whichever identity is likely 476 to be named in the peer's policy. In practice, this generally means 477 IP address, FQDN, or USER-FQDN. 479 3.2.11. Transitively Binding Identity to Policy 481 In the presence of certificates that contain multiple identities, 482 implementations SHOULD NOT assume that a peer will choose the most 483 appropriate identity with which to populate ID. Therefore, implemen- 484 tations SHOULD select the most appropriate identity to use from the 485 identities contained in the certificate when determining the appro- 486 priate policy. 488 For example, imagine that a peer is configured with a certificate 489 that contains both a non-empty Subject Name and an FQDN. Independent 490 of which identity is used to populate ID, the host implementation 491 MUST locate the proper policy. For instance, if ID contains the peer 492 Subject Name, then the peer end entity certificate may be found using 493 the Subject Name as a key. Once the certificate has been located and 494 then validated, the FQDN in the certificate can be used to locate the 495 appropriate policy. 497 3.3. Certificate Request Payload 499 3.3.1. Certificate Type 501 The Certificate Type field identifies to the peer the type of 502 certificate keying materials that are desired. ISAKMP defines 10 503 types of Certificate Data that can be requested and specifies the 504 syntax for these types. For the purposes of this document, only the 505 following types are relevant: 507 * X.509 Certificate - Signature 508 * X.509 Certificate - Key Exchange 509 * Certificate Revocation List (CRL) 510 * Authority Revocation List (ARL) 511 * PKCS #7 wrapped X.509 certificate 513 For example, if CRLs are desired, an implementation will populate the 514 Certificate Type field with the value associated with "Certificate 515 Revocation List (CRL)". 517 The use of the other types: 519 * PGP Certificate 520 * DNS Signed Key 521 * Kerberos Tokens 522 * SPKI Certificate 523 * X.509 Certificate - Attribute 525 are out of the scope of this document. 527 3.3.2. X.509 Certificate - Signature 529 This type requests that the end entity certificate be a signing 530 certificate. Implementations that receive CERTREQs which contain this 531 ID type in a context in which end entity signature certificates are 532 not used SHOULD ignore such CERTREQs. 534 3.3.3. X.509 Certificate - Key Exchange 536 This type requests that the end entity certificate be a key exchange 537 certificate. Implementations that receive CERTREQs which contain this 538 ID type in a context in which end entity key exchange certificates 539 are not used SHOULD ignore such CERTREQs. 541 3.3.4. Certificate Revocation List (CRL) 543 This type requests that X.509 CRLs be provided, along with any cer- 544 tificates that may be needed to validate those CRLs. 546 3.3.5. Authority Revocation List (ARL) 548 This ID type SHOULD be treated as synonymous with the CRL type. 549 Implementations SHOULD NOT generate CERTREQ payloads with this type, 550 but should instead generate CRL CERTREQs. 552 3.3.6. PKCS #7 wrapped X.509 certificate 554 This ID type defines a particular encoding (not a particular 555 certificate or CRL type), some current implementations may ignore 556 CERTREQs they receive which contain this ID type, and the authors are 557 unaware of any implementations that generate such CERTREQ messages. 558 Therefore, the use of this type is deprecated. Implementations SHOULD 559 NOT generate CERTREQs that contain this Certificate Type. Implementa- 560 tions which receive CERTREQs which contain this ID type MAY ignore 561 such payloads. 563 3.3.7. Presence or Absence of Certificate Request Payloads 565 When in-band exchange of certificate keying materials is desired, 566 implementations MUST inform the peer of this by sending at least one 567 CERTREQ. An implementation which does not send any CERTREQs during an 568 exchange SHOULD NOT expect to receive any CERT payloads. 570 3.3.8. Certificate Requests 572 3.3.8.1. Specifying Certificate Authorities 574 Implementations MUST generate CERTREQs for every peer root that local 575 policy explicitly deems trusted during a given exchange. Implementa- 576 tions MUST populate the Certificate Authority field with the Subject 577 Name of the trusted root, populated such that binary comparison of 578 the Subject Name and the Certificate Authority will succeed. 580 Upon receipt of a CERTREQ where the Certificate Type is either "X.509 581 Certificate - Signature" or "X.509 Certificate - Key Exchange", 582 implementations MUST respond by sending each certificate in the chain 583 from the end entity certificate to the certificate whose Issuer Name 584 matches the name specified in the Certificate Authority field. Imple- 585 mentations MAY send other certificates from the chain. 587 3.3.8.2. Empty Certificate Authority Field 589 Implementations MUST NOT generate CERTREQs where the Certificate Type 590 is either "X.509 Certificate - Signature" or "X.509 Certificate - Key 591 Exchange" with an empty Certificate Authority field. Upon receipt of 592 such a CERTREQ from a non-conformant implementation, implementations 593 SHOULD send just the certificate chain associated with the end entity 594 certificate, not including any CRLs or the certificates that would be 595 needed to validate those CRLs. 597 Note, in the case where multiple end entity certificates may be 598 available, implementations SHOULD resort to local heuristics to 599 determine which end entity is most appropriate to use. Such heuris- 600 tics are out of the scope of this document. 602 3.3.9. CRL Requests 604 3.3.9.1. Specifying Certificate Authorities 606 Upon receipt of a CERTREQ where the Certificate Type is "Certificate 607 Revocation List (CRL)", implementations MUST respond by sending the 608 CRL issued by the issuer of each certificate in the chain between the 609 end entity certificate and the certificate whose Issuer Name matches 610 the name specified in the Certificate Authority field. In additional, 611 implementations MUST send any certificates that are needed to vali- 612 date those CRLs. 614 3.3.9.2. Empty Certificate Authority Field 616 Implementations MAY generate CERTREQs where the Certificate Type is 617 "Certificate Revocation List (CRL)" with an empty Certificate 618 Authority field to signify that the peer should send all CRLs that 619 are possessed by that peer, whether relevant to the current exchange 620 or not. Upon receipt of such a CERTREQ, implementations SHOULD send 621 all CRLs that are possessed but MUST send all CRLs that are relevant 622 to the current exchange, including the certificates that are needed 623 to validate those CRLs. 625 3.3.10. Robustness 627 3.3.10.1. Unrecognized or Unsupported Certificate Types 629 Implementations MUST be able to deal with receiving CERTREQs with 630 unsupported Certificate Types. Absent any recognized and supported 631 CERTREQs, implementations MAY treat them as if they are of a sup- 632 ported type with the Certificate Authority field left empty, depend- 633 ing on local policy. ISAKMP Section 5.10 "Certificate Request Payload 634 Processing" specifies additional processing. 636 3.3.10.2. Undecodable Certificate Authority Fields 638 Implementations MUST be able to deal with receiving CERTREQs with 639 undecodable Certificate Authority fields. Implementations MAY treat 640 such fields as if there were empty, depending on local policy. ISAKMP 641 specifies other actions which may be taken. 643 3.3.10.3. Ordering of Certificate Request Payloads 645 Implementations MUST NOT assume that CERTREQs are ordered in any way. 647 3.3.11. Optimizations 649 3.3.11.1. Duplicate Certificate Request Payloads 651 Implementations SHOULD NOT send duplicate CERTREQs during an 652 exchange. 654 3.3.11.2. Name Lowest 'Common' Certification Authorities 656 When a peer's certificate keying materials have been cached, an 657 implementation can send a hint to the peer to elide some of the cer- 658 tificates and CRLs the peer would normally respond with. In addition 659 to the normal set of CERTREQs that are sent, an implementation MAY 660 send CERTREQs containing the Issuer Name of the relevant cached end 661 entity certificates. When sending these hints, it is still necessary 662 to send the normal set of CERTREQs because the hints do not suffi- 663 ciently convey all of the information required by the peer. Specifi- 664 cally, either the peer may not support this optimization or there may 665 be additional chains that could be used in this context but will not 666 be specified if only supplying the issuer of the end entity 667 certificate. 669 No special processing is required on the part of the recipient of 670 such a CERTREQ, and the end entity certificates will still be sent. 671 On the other hand, the recipient MAY elect to elide certificates 672 based on receipt of such hints. 674 ISAKMP mandates that CERTREQs contain the Subject Name of a Certifi- 675 cation Authority, which results in the peer always sending at least 676 the end entity certificate. This mechanism allows implementations to 677 determine unambiguously when a new certificate is being used by the 678 peer, perhaps because the previous certificate has just expired, 679 which will result in a failure because the needed keying materials 680 are not available to validate the new end entity certificate. Imple- 681 mentations which implement this optimization MUST recognize when the 682 end entity certificate has changed and respond to it by not perform- 683 ing this optimization when the exchange is retried. 685 3.3.11.3. Example 687 Imagine that an implementation has previously received and cached the 688 peer certificate chain R->CA1->CA2->EE. If during a subsequent 689 exchange this implementation sends a CERTREQ containing the Subject 690 Name in certificate R, this implementation is requesting that the 691 peer send at least 3 certificates: CA1, CA2, and EE. On the other 692 hand, if this implementation also sends a CERTREQ containing the Sub- 693 ject Name of CA2, the implementation is providing a hint that only 1 694 certificate needs to be sent: EE. 696 3.4. Certificate Payload 698 3.4.1. Certificate Type 700 The Certificate Type field identifies to the peer the type of 701 certificate keying materials that are included. ISAKMP defines 10 702 types of Certificate Data that can be sent and specifies the syntax 703 for these types. For the purposes of this document, only the follow- 704 ing types are relevant: 706 * X.509 Certificate - Signature 707 * X.509 Certificate - Key Exchange 708 * Certificate Revocation List (CRL) 709 * Authority Revocation List (ARL) 710 * PKCS #7 wrapped X.509 certificate 712 For example, if CRLs are desired, an implementation will populate the 713 Certificate Type field with the value associated with "Certificate 714 Revocation List (CRL)". 716 The use of the other types: 718 * PGP Certificate 719 * DNS Signed Key 720 * Kerberos Tokens 721 * SPKI Certificate 722 * X.509 Certificate - Attribute 724 are out of the scope of this document. 726 3.4.2. X.509 Certificate - Signature 728 This type specifies that Certificate Data contains a certificate used 729 for signing, whether an end entity signature certificate or a CA 730 certificate signing certificate. 732 3.4.3. X.509 Certificate - Key Exchange 734 This type specifies that Certificate Data contains an end entity 735 certificate used for either key exchange (or key encipherment). 737 3.4.4. Certificate Revocation List (CRL) 739 This type specifies that Certificate Data contains an X.509 CRL. 741 3.4.5. Authority Revocation List (ARL) 743 This type specifies that Certificate Data contains an X.509 CRL that 744 revokes CAs. 746 3.4.6. PKCS #7 wrapped X.509 certificate 748 This type defines a particular encoding, not a particular certificate 749 or CRL type. Implementations MUST NOT generate CERTs that contain 750 this Certificate Type. Implementations which violate this requirement 751 SHOULD note that this is a single certificate as specified in ISAKMP. 752 Implementations MAY accept CERTs that contain this Certificate type. 754 3.4.7. Certificate Payloads Not Mandatory 756 An implementation which does not receive any CERTREQs during an 757 exchange SHOULD NOT send any CERT payloads, except when explicitly 758 configured to proactively send CERT payloads in order to interoperate 759 with non-compliant implementations. In this case, an implementation 760 MUST send the all certificate chains and CRLs associated with the end 761 entity certificate. This MUST NOT be the default behavior of 762 implementations. 764 Implementations which are configured to expect that a peer must 765 receive certificates through out-of-band means SHOULD ignore any 766 CERTREQ messages that are received. 768 Implementations that receive CERTREQs from a peer which contain only 769 unrecognized Certification Authorities SHOULD NOT continue the 770 exchange, in order to avoid unnecessary and potentially expensive 771 cryptographic processing. 773 3.4.8. Response to Multiple Certificate Authority Proposals 775 In response to multiple CERTREQs which contain different Certificate 776 Authority identities, implementations MAY respond using an end entity 777 certificate which chains to a CA that matches any of the identities 778 provided by the peer. 780 3.4.9. Using Local Keying Materials 782 Implementations MAY elect not to use keying materials contained in a 783 given set of CERTs if preferable keying materials are available. For 784 instance, the contents of a CERT may be available from a previous 785 exchange, or a newer CRL may be available through some out-of-band 786 means. 788 3.4.10. Robustness 790 3.4.10.1. Unrecognized or Unsupported Certificate Types 792 Implementations MUST be able to deal with receiving CERTs with unrec- 793 ognized or unsupported Certificate Types. Implementations MAY discard 794 such payloads, depending on local policy. ISAKMP Section 5.10 795 "Certificate Request Payload Processing" specifies additional pro- 796 cessing. 798 3.4.10.2. Undecodable Certificate Data Fields 800 Implementations MUST be able to deal with receiving CERTs with unde- 801 codable Certificate Data fields. Implementations MAY discard such 802 payloads, depending on local policy. ISAKMP specifies other actions 803 which may be taken. 805 3.4.10.3. Ordering of Certificate Payloads 807 Implementations MUST NOT assume that CERTs are ordered in any way. 809 3.4.10.4. Duplicate Certificate Payloads 811 Implementations MUST support receiving multiple identical CERTs dur- 812 ing an exchange. 814 3.4.10.5. Irrelevant Certificates 816 Implementations MUST be prepared to receive certificates and CRLs 817 which are not relevant to the current exchange. Implementations MAY 818 discard such keying materials. 820 Implementations MAY include certificates which are irrelevant to an 821 exchange. One reason for including certificates which are irrelevant 822 to an exchange is to minimize the threat of leaking identifying 823 information in exchanges where CERT is not encrypted. It should be 824 noted, however, that this probably provides rather poor protection 825 against leaking the identity. 827 3.4.11. Optimizations 829 3.4.11.1. Duplicate Certificate Payloads 831 Implementations SHOULD NOT send duplicate CERTs during an exchange. 832 Such payloads should be suppressed. 834 3.4.11.2. Send Lowest 'Common' Certificates 836 When multiple CERTREQs are received which specify certificate author- 837 ities within the end entity certificate chain, implementations MAY 838 send the shortest chain possible. However, implementations SHOULD 839 always send the end entity certificate. See section 3.3.12.2 for more 840 discussion of this optimization. 842 3.4.11.3. Drop Duplicate Certificate Payloads 844 Implementations MAY employ local means to recognize CERTs that have 845 been received in the past, whether part of the current exchange or 846 not, for which keying material is available and may discard these 847 duplicate CERTs. 849 4. Profile of PKIX 851 4.1. X.509 Certificates 852 4.1.1. Versions 854 Although PKIX states that "implementations SHOULD be prepared to 855 accept any version certificate", in practice this profile requires 856 certain extensions that necessitate the use of Version 3 certifi- 857 cates. Implementations that conform to this document MAY therefore 858 reject Version 1 and Version 2 certificates. 860 4.1.2. Subject Name 862 4.1.2.1. Empty Subject Name 864 Implementations MUST accept certificates which contain an empty Sub- 865 ject Name field, as specified in PKIX. Identity information in such 866 certificates will be contained entirely in the SubjectAltName exten- 867 sion. 869 4.1.2.2. Specifying Hosts in Subject Name 871 4.1.2.2.1. Non-FQDN Host Names 873 Implementations which desire to place host names that are not FQDNs 874 (for instance "Gateway Router") in the Subject Name MUST use the com- 875 monName attribute. 877 4.1.2.2.2. FQDN Host Names 879 Implementations which desire to place host names that are FQDNs (for 880 instance "gateway.xythos.com") in the Subject Name field SHOULD use 881 the commonName attribute type. 883 Implementations SHOULD NOT populate the Subject Name in place of pop- 884 ulating the dNSName field of the SubjectAltName extension. Host names 885 that appear in the Subject Name cannot be unambiguously determined to 886 be a host name. 888 Note, PKIX defines a domainComponent attribute for representing FQDNs 889 in DistinguishedNames such as Subject Name. As an alternative to 890 using commonName, implementations MAY use the domainComponent 891 attribute type. However, note that support for the domainComponent 892 attribute is far from universal and some implementations will reject 893 certificates that contain this attribute. 895 4.1.2.3. EmailAddress 897 As specified in PKIX, implementations MUST NOT populate Distin- 898 guishedNames with the EmailAddress attribute. 900 4.1.3. X.509 Certificate Extensions 902 Conforming applications MUST recognize extensions which must or may 903 be marked critical according to this specification. These extensions 904 are: KeyUsage, SubjectAltName, and BasicConstraints. 906 Implementations SHOULD generate certificates such that the extension 907 criticality bits are set in accordance with PKIX and this document. 908 With respect to PKIX compliance, implementations processing certifi- 909 cates MAY ignore the value of the criticality bit for extensions that 910 are supported by that implementation, but MUST support the critical- 911 ity bit for extensions that are not supported by that implementation. 913 4.1.3.1. AuthorityKeyIdentifier 915 Implementations SHOULD NOT assume that other implementations support 916 the AuthorityKeyIdentifier extension, and thus should generate 917 certificate hierarchies which overly complex to process in the 918 absence of this extension, such that those that require possibly ver- 919 ifying a signature against a large number of similarly named CA cer- 920 tificates in order to find the CA certificate which contains the key 921 that was used to generate the signature. 923 4.1.3.2. SubjectKeyIdentifier 925 Implementations SHOULD NOT assume that other implementations support 926 the SubjectKeyIdentifier extension, and thus should generate 927 certificate hierarchies which overly complex to process in the 928 absence of this extension, such that those that require possibly ver- 929 ifying a signature against a large number of similarly named CA cer- 930 tificates in order to find the CA certificate which contains the key 931 that was used to generate the signature. 933 4.1.3.3. KeyUsage 935 The meaning of the nonRepudiation bit is undefined in the context of 936 IPsec. Implementations SHOULD ignore this bit if present. 938 See PKIX for general guidance on which of the other KeyUsage bits 939 should be set in any given certificate. 941 4.1.3.4. PrivateKeyUsagePeriod 943 PKIX recommends against the use of this extension. The Pri- 944 vateKeyUsageExtension is intended to be used when signatures will 945 need to be verified long past the time when signatures using the pri- 946 vate keypair may be generated. Since ISAKMP SAs are short-lived rela- 947 tive to the intended use of this extension in addition to the fact 948 that each signature is validated only a single time, the meaning of 949 this extension in the context of ISAKMP is unclear. Therefore, the 950 PrivateKeyUsagePeriod is inappropriate in the context of ISAKMP and 951 therefore implementations MUST NOT generate certificates that contain 952 the PrivateKeyUsagePeriod extension. 954 4.1.3.5. Certificate Policies 956 Many IPsec implementations do not currently provide support for the 957 Certificate Policies extension. Therefore, implementations that gen- 958 erate certificates which contain this extension SHOULD mark the 959 extension as non-critical. 961 4.1.3.6. PolicyMappings 963 Many implementations do not support the PolicyMappings extension. 965 4.1.3.7. SubjectAltName 967 4.1.3.7.1. Permitted Choices 969 Implementations SHOULD generate only the following GeneralName 970 choices in the subjectAltName extension, as these choices map to 971 legal ISAKMP Identity Payload types ISAKMP: rfc822Name, dNSName, or 972 iPAddress. Although it is possible to specify any GeneralName choice 973 in the ISAKMP Identity Payload by using the ID_DER_ASN1_GN ID type, 974 implementations SHOULD NOT assume that a peer supports such function- 975 ality. 977 4.1.3.7.1.1. dNSName 979 This field MUST contain a fully qualified domain name. Implementa- 980 tions MUST NOT generate names that contain wildcards. 982 Implementations MAY treat certificates that contain wildcards in this 983 field as syntactically invalid. 985 Although this field is in the form of an FQDN, implementations SHOULD 986 NOT assume that the this field contains an FQDN that will resolve via 987 the DNS, unless this is known by way of some out-of-band mechanism. 988 Such a mechanism is out of the scope of this document. Implementa- 989 tions SHOULD NOT treat the failure to resolve as an error. 991 4.1.3.7.1.2. iPAddress 993 Note that the CIDR [CIDR] notation permitted in the "Name Con- 994 straints" section of PKIX is explicitly not permitted by that speci- 995 fication for conveying identity information. In other words, the CIDR 996 notation MUST NOT be used in the subjectAltName extension. 998 4.1.3.7.1.3. rfc822Name 1000 Although this field is in the form of an Internet mail address, 1001 implementations SHOULD NOT assume that the this field contains a 1002 valid email address, unless this is known by way of some out-of-band 1003 mechanism. Such a mechanism is out of the scope of this document. 1005 4.1.3.8. IssuerAltName 1007 Implementations SHOULD NOT assume that other implementations support 1008 the IssuerAltName extension, and especially should not assume that 1009 information contained in this extension will be displayed to end 1010 users. 1012 4.1.3.9. SubjectDirectoryAttributes 1014 The SubjectDirectoryAttributes extension is intended to contain priv- 1015 ilege information, in a manner analogous to privileges carried in 1016 Attribute Certificates. Implementations MAY ignore this extension as 1017 PKIX mandates it be marked non-critical. 1019 4.1.3.10. BasicConstraints 1021 PKIX mandates that CA certificates contain this extension and that it 1022 be marked critical. For backwards compatibility, implementations 1023 SHOULD accept CA certificates that do not contain this extension or 1024 that contain this extension marked non-critical. 1026 4.1.3.11. NameConstraints 1028 Many implementations do not support the NameConstraints extension. 1029 Since PKIX mandates that this extension be marked critical when pre- 1030 sent, implementations which intend to be maximally interoperable 1031 SHOULD NOT generate certificates which contain this extension. 1033 4.1.3.12. PolicyConstraints 1035 Many implementations do not support the PolicyConstraints extension. 1036 Since PKIX mandates that this extension be marked critical when pre- 1037 sent, implementations which intend to be maximally interoperable 1038 SHOULD NOT generate certificates which contain this extension. 1040 4.1.3.13. ExtendedKeyUsage 1042 No ExtendedKeyUsage usages are defined for IPsec, so if this exten- 1043 sion is present and marked critical, use of this certificate for 1044 IPsec MUST be treated as an error. Implementations MUST NOT generate 1045 this extension in certificates which are being used for IPsec. 1047 4.1.3.14. CRLDistributionPoint 1049 Most implementations expect to exchange CRLs in band via the ISAKMP 1050 Certificate Payload. Implementations MUST NOT assume that the CRLDis- 1051 tributionPoint extension will exist in peer extensions and therefore 1052 implementations SHOULD request that peers send CRLs in the absence of 1053 knowledge that this extension exists in the peer's certificates. 1055 4.1.3.15. InhibitAnyPolicy 1057 Many implementations do not support the InhibitAnyPolicy extension. 1058 Since PKIX mandates that this extension be marked critical when pre- 1059 sent, implementations which intend to be maximally interoperable 1060 SHOULD NOT generate certificates which contain this extension. 1062 4.1.3.16. FreshestCRL 1064 Most implementations expect to exchange CRLs in band via the ISAKMP 1065 Certificate Payload. Implementations MUST NOT assume that the Fresh- 1066 estCRL extension will exist in peer extensions and therefore imple- 1067 mentations SHOULD request that peers send CRLs in the absence knowl- 1068 edge that this extension exists in the peer certificates. 1070 4.1.3.17. AuthorityInfoAccess 1072 PKIX defines the AuthorityInfoAccess extension, which is used to "how 1073 to access CA information and services for the issuer of the 1074 certificate in which the extension appears." This extension has no 1075 known use in the context of IPsec. Conformant implementations SHOULD 1076 ignore this extension when present. 1078 4.1.3.18. SubjectInfoAccess 1080 PKIX defines the SubjectInfoAccess private certificate extension, 1081 which is used to indicate "how to access information and services for 1082 the subject of the certificate in which the extension appears." This 1083 extension has no known use in the context of IPsec. Conformant imple- 1084 mentations SHOULD ignore this extension when present. 1086 4.2. X.509 Certificate Revocation Lists 1088 Implementations SHOULD send CRLs, unless non-CRL certificate revoca- 1089 tion information is known to be preferred by all interested parties 1090 in the application environment that the implementation is used. 1091 Implementations MUST send CRLs if non-CRL certificate revocation 1092 information may not be available to all interested parties. 1094 4.2.1. Certificate Revocation Requirement 1096 Implementations which validate certificates MUST make use of 1097 certificate revocation information, and SHOULD support such revoca- 1098 tion information in the form of CRLs, unless non-CRL revocation 1099 information is known to be the only method for transmitting this 1100 information. 1102 4.2.2. Multiple Sources of Certificate Revocation Information 1104 Implementations which support multiple sources of obtaining 1105 certificate revocation information MUST act conservatively when the 1106 information provided by these sources is inconsistent: when a 1107 certificate is reported as revoked by one source, the certificate 1108 MUST be considered revoked. 1110 4.2.3. X.509 Certificate Revocation List Extensions 1112 4.2.3.1. AuthorityKeyIdentifier 1114 Implementations SHOULD NOT assume that other implementations support 1115 the AuthorityKeyIdentifier extension, and thus should generate 1116 certificate hierarchies which overly complex to process in the 1117 absence of this extension. 1119 4.2.3.2. IssuerAltName 1121 Implementations SHOULD NOT assume that other implementations support 1122 the IssuerAltName extension, and especially should not assume that 1123 information contained in this extension will be displayed to end 1124 users. 1126 4.2.3.3. CRLNumber 1128 As stated in PKIX, all issuers conforming to PKIX MUST include this 1129 extension in all CRLs. 1131 4.2.3.4. DeltaCRLIndicator 1133 4.2.3.4.1. If Delta CRLs Are Unsupported 1135 Implementations that do not support delta CRLs MUST reject CRLs which 1136 contain the DeltaCRLIndicator (which MUST be marked critical accord- 1137 ing to PKIX) and MUST make use of a base CRL if it is available. Such 1138 implementations MUST ensure that a delta CRL does not "overwrite" a 1139 base CRL, for instance in the keying material database. 1141 4.2.3.4.2. Delta CRL Recommendations 1143 Since some implementations that do not support delta CRLs may behave 1144 incorrectly or insecurely when presented with delta CRLs, implementa- 1145 tions SHOULD consider whether issuing delta CRLs increases security 1146 before issuing such CRLs. 1148 The authors are aware of several implementations which behave in an 1149 incorrect or insecure manner when presented with delta CRLs. See 1150 Appendix B for a description of the issue. Therefore, this specifica- 1151 tion RECOMMENDS against issuing delta CRLs at this time. On the other 1152 hand, failure to issue delta CRLs exposes a larger window of vulnera- 1153 bility. See the Security Considerations section of PKIX for addi- 1154 tional discussion. Implementors as well as administrators are encour- 1155 aged to consider these issues. 1157 4.2.3.5. IssuingDistributionPoint 1159 Given the recommendations against implementations generating delta 1160 CRLs, this specification RECOMMENDS that implementations do not popu- 1161 late CRLs with the IssuingDistributionPoint extension, which must be 1162 marked critical if present according to PKIX but is generally only 1163 useful in the context of delta CRLs. 1165 4.2.3.6. FreshestCRL 1167 Given the recommendations against implementations generating delta 1168 CRLs, this specification RECOMMENDS that implementations do not popu- 1169 late CRLs with the FreshestCRL extension, which is used to obtain 1170 delta CRLs. 1172 5. Configuration Data Exchange Conventions 1174 Below we present a common format for exchanging configuration data. 1175 Implementations MUST support these formats, MUST support arbitrary 1176 whitespace at the beginning and end of any line, and MUST support the 1177 three line-termination disciplines: LF (US-ASCII 10), CR (US-ASCII 1178 13), and CRLF. 1180 5.1. Certificates 1182 Certificates MUST be Base64 encoded and appear between the following 1183 delimiters: 1185 -----BEGIN CERTIFICATE----- 1186 -----END CERTIFICATE----- 1188 5.2. Public Keys 1190 Implementations MUST support two forms of public keys: certificates 1191 and so-called "raw" keys. Certificates should be transferred in the 1192 same form as above. A raw key is only the SubjectPublicKeyInfo por- 1193 tion of the certificate, and MUST be Base64 encoded and appear 1194 between the following delimiters: 1196 -----BEGIN PUBLIC KEY----- 1198 -----END PUBLIC KEY----- 1200 5.3. PKCS#10 Certificate Signing Requests 1202 A PKCS#10 Certificiate Signing Request MUST be Base64 encoded and 1203 appear between the following delimeters: 1205 -----BEGIN CERTIFICATE REQUEST----- 1207 -----END CERTIFICATE REQUEST----- 1209 6. IKE 1211 6.1. IKE Phase 1 Authenticated With Signatures 1213 6.1.1. Identification Payload 1215 IKE mandates the use of the ID payload in Phase 1. 1217 Implementations SHOULD populate ID with identity information that is 1218 contained within the end entity certificate. This enables recipients 1219 to use ID as a lookup key to find the peer end entity certificate. 1220 The only case where implementations MAY populate ID with information 1221 that is not contained in the end entity certificate is when ID con- 1222 tains the peer source address (a single address, not a subnet or 1223 range). This means that implementations MUST be able to map a peer 1224 source address to a peer end entity certificate, even when the 1225 certificate does not contain that address. The exact method for per- 1226 forming this mapping is out of the scope of this document. 1228 6.1.2. X.509 Certificate Extensions 1230 6.1.2.1. KeyUsage 1232 If the KeyUsage extension is present in an end entity certificate, 1233 the digitalSignature bit must be asserted. 1235 6.1.3. Obtaining Peer Certificates and CRLs 1237 IKE implementations MUST assume all necessary certificates and CRLs 1238 will be exchanged in-band. 1240 6.2. IKE Phase 1 Authenticated With Public Key Encryption 1242 6.2.1. Identification Payload 1244 IKE mandates the use of the ID payload in Phase 1. 1246 If certificates are not being used, the contents of ID are out of 1247 scope for this document. 1249 6.2.2. Hash Payload 1251 IKE specifies the optional use of the Hash Payload to carry a pointer 1252 to a certificate in either of the Phase 1 public key encryption 1253 modes. This pointer is used by an implementation to locate the end 1254 entity certificate that contains the public key that a peer should 1255 use for encrypting payloads during the exchange. 1257 Implementations SHOULD include this payload whenever the public por- 1258 tion of the keypair has been placed in a certificate. 1260 6.2.3. X.509 Certificate Extensions 1262 6.2.3.1. KeyUsage 1264 If the KeyUsage extension is present in an end entity certificate, 1265 the keyEncipherment bit must be asserted. 1267 6.2.4. Obtaining Peer Certificates and CRLs 1269 Certificates are generally not exchanged in-band, but rather are 1270 exchanged out-of-band, with direct trust of the peer certificate 1271 being most prevalent. CRLs SHOULD be obtained out-of-band from a 1272 directory or other repository. 1274 6.3. IKE Phase 1 Authenticated With a Revised Mode of Public Key 1275 Encryption 1277 IKE Phase 1 Authenticated With a Revised Mode of Public Key Encryp- 1278 tion has the same requirements as IKE Phase 1 Authenticated With Pub- 1279 lic Key Encryption. See section 6.2 for these requirements. 1281 7. Security Considerations 1283 7.1. Identity Payload 1285 Depending on the exchange type, ID may be passed in the clear. Admin- 1286 istrators in some environments may wish to use the empty Certifica- 1287 tion Authority option to prevent such information from leaking, at 1288 the possible cost of some performance. 1290 7.2. Certificate Request Payload 1292 The Contents of CERTREQ are not encrypted in IKE. In some environ- 1293 ments this may leak private information. Administrators in some envi- 1294 ronments may wish to use the empty Certification Authority option to 1295 prevent such information from leaking, at the cost of performance. 1297 7.3. Certificate Payload 1299 Depending on the exchange type, CERTs may be passed in the clear and 1300 therefore may leak identity information. 1302 7.4. IKE Main Mode 1304 Implementations may not wish to respond with CERTs in the second mes- 1305 sage, thereby violating the identity protection feature of Main Mode 1306 IKE. ISAKMP allows CERTs to be included in any message, and therefore 1307 implementations may wish to respond with CERTs in a message that 1308 offers privacy protection in this case. 1310 7.5. IKE Aggressive Mode 1312 The contents of ID are not encrypted in Aggressive Mode when authen- 1313 tication is performed with signatures. In some environments this may 1314 leak private information. The solutions to this problem if such a 1315 leak is unacceptable are: 1317 * Use Main Mode instead of Aggressive Mode. 1318 * Populate ID Data with the address of the host. 1320 The contents of CERT are not encrypted in Aggressive Mode when 1321 authentication is performed with signatures. In some environments 1322 this may leak private information. The solutions to this problem if 1323 such a leak is unacceptable are: 1325 * Use Main Mode instead of Aggressive Mode. 1327 8. Intellectual Property Rights 1329 No new intellectual property rights are introduced by this document. 1331 9. IANA Considerations 1333 There are no known numbers which IANA will need to manage. 1335 References 1337 [CIDR] Fuller, V., et al., "Classless Inter-Domain Routing (CIDR): 1338 An Address Assignment and Aggregation Strategy", RFC 1519, 1339 September 1993. 1341 [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", 1342 RFC 2535, March 1999. 1344 [DOI] Piper, D., "The Internet IP Security Domain of 1345 Interpretation for ISAKMP", RFC 2407, November 1998. 1347 [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange 1348 (IKE)", RFC 2409, November 1998. 1350 [IPSEC] Kent, S. and Atkinson, R., "Security Architecture for the 1351 Internet Protocol", RFC 2401, November 1998. 1353 [ISAKMP] Maughan, D., et. al., "Internet Security Association and 1354 Key Management Protocol (ISAKMP)", RFC 2408, November 1998. 1356 [PKIX] Housley, R., et al., "Internet X.509 Public Key 1357 Infrastructure Certificate and Certificate Revocation 1358 List (CRL) Profile", RFC 3280, April 2002. 1360 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1361 September 1981. 1363 [RFC1883] Deering, S. and Hinden, R. "Internet Protocol, Version 6 1364 (IPv6) Specification", RFC 1883, December 1995. 1366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1367 Requirement Levels", BCP 14, RFC 2119, March 1997. 1369 [ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap", 1370 draft-ietf-pkix-roadmap-08.txt. 1372 Acknowledgments 1374 The authors would like to acknowledge the expired draft-ietf-ipsec- 1375 pki-req-05.txt for providing valuable materials for this document. 1376 The authors would like to thank Greg Carter for his valuable comments 1377 on an early draft of this document. 1379 Author's Addresses 1381 Brian Korver 1382 Xythos Software, Inc. 1383 25 Maiden Lane, 6th Floor 1384 San Francisco, CA 94108 1385 USA 1386 Phone: +1 415 248-3800 1387 EMail: briank@xythos.com 1389 Eric Rescorla 1390 RTFM, Inc. 1391 2064 Edgewood Drive 1392 Palo Alto, CA 94303 1393 USA 1394 Phone: +1 650 320-8549 1395 EMail: ekr@rtfm.com 1397 Full Copyright Statement 1399 Copyright (C) The Internet Society (2002). 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 docu- 1407 ment itself may not be modified in any way, such as by removing the 1408 copyright notice or references to the Internet Society or other 1409 Internet organizations, except as needed for the purpose of develop- 1410 ing Internet standards in which case the procedures for copyrights 1411 defined in the Internet Standards process must be followed, or as 1412 required to translate it into languages other than English. 1414 The limited permissions granted above are perpetual and will not be 1415 revoked by the Internet Society or its successors or assigns. 1417 This document and the information contained herein is provided on an 1418 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1419 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1420 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1421 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 1422 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1424 Appendix A. Change History 1426 * October 2002, Reorganization 1427 * June 2002, Initial Draft 1429 Appendix B. The Possible Dangers of Delta CRLs 1431 The problem is that the CRL processing algorithm is often written 1432 with the assumption that all CRLs are base CRLs and it is assumed 1433 that CRLs will pass content validity tests. Specifically, such imple- 1434 mentations fail to check the certificate against all possible CRLs: 1435 if the first CRL that is obtained from the keying material database 1436 fails to decode, no further revocation checks are performed for the 1437 relevant certificate. This problem is compounded by the fact that 1438 implementations which do not understand delta CRLs may fail to decode 1439 such CRLs due to the critical DeltaCRLIndicator extension. The algo- 1440 rithm that is implemented in this case is approximately: 1442 fetch newest CRL 1443 check validity of CRL signature 1444 if CRL signature is valid then 1445 if CRL does not contain unrecognized critical extensions 1446 and certificate is on CRL then 1447 set certificate status to revoked 1449 The authors note that a number of PKI toolkits do not even provide a 1450 method for obtaining anything but the newest CRL, which in the 1451 presence of delta CRLs may in fact be a delta CRL, not a base CRL.