Brian Korver Xythos Software Eric Rescorla INTERNET-DRAFT RTFM, Inc. October 2002 (Expires April 2003) The Internet IP Security PKI Profile of ISAKMP and PKIX Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract ISAKMP and PKIX both provide frameworks that must be profiled for use in a given application. This document provides a profile of ISAKMP and PKIX that defines the requirements for using PKI technology in the context of IPsec. The document compliments protocol specifica- tions such as IKE, which assume the existence of public key certifi- cates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. Table of Contents 1 Introduction 4 2 Terms and Definitions 5 3 Profile of ISAKMP 6 Korver, Rescorla [Page 1] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 3.1 Background 6 3.1.1 Certificate-Related Payloads in ISAKMP 6 3.1.1.1 Identification Payload 6 3.1.1.2 Certificate Payload 6 3.1.1.3 Certificate Request Payload 6 3.1.1.4 Hash Payload 6 3.1.2 Endpoint Identification 7 3.1.2.1 Identification Payload Only 7 3.1.2.2 Certificate Payload Only 7 3.2 Identification Payload 7 3.2.1 ID_IPV4_ADDR and ID_IPV6_ADDR 7 3.2.2 ID_FQDN 8 3.2.3 ID_USER_FQDN 8 3.2.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADD... 8 3.2.5 ID_DER_ASN1_DN 8 3.2.6 ID_DER_ASN1_GN 9 3.2.7 ID_KEY_ID 9 3.2.8 Using Peer Source IP Address to Bind Identity to Poli... 9 3.2.9 Securely Binding Identity to Policy 10 3.2.9.1 Single Address Identification Data 10 3.2.9.2 Identification Data other than a Single Address 10 3.2.10 Selecting an Identity from a Certificate 10 3.2.11 Transitively Binding Identity to Policy 11 3.3 Certificate Request Payload 11 3.3.1 Certificate Type 11 3.3.2 X.509 Certificate - Signature 12 3.3.3 X.509 Certificate - Key Exchange 12 3.3.4 Certificate Revocation List (CRL) 12 3.3.5 Authority Revocation List (ARL) 12 3.3.6 PKCS #7 wrapped X.509 certificate 12 3.3.7 Presence or Absence of Certificate Request Payloads 12 3.3.8 Certificate Requests 13 3.3.8.1 Specifying Certificate Authorities 13 3.3.8.2 Empty Certificate Authority Field 13 3.3.9 CRL Requests 13 3.3.9.1 Specifying Certificate Authorities 13 3.3.9.2 Empty Certificate Authority Field 13 3.3.10 Robustness 14 3.3.10.1 Unrecognized or Unsupported Certificate Types 14 3.3.10.2 Undecodable Certificate Authority Fields 14 3.3.10.3 Ordering of Certificate Request Payloads 14 3.3.11 Optimizations 14 3.3.11.1 Duplicate Certificate Request Payloads 14 3.3.11.2 Name Lowest 'Common' Certification Authorities 14 3.3.11.3 Example 15 3.4 Certificate Payload 15 3.4.1 Certificate Type 15 3.4.2 X.509 Certificate - Signature 16 Korver, Rescorla [Page 2] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 3.4.3 X.509 Certificate - Key Exchange 16 3.4.4 Certificate Revocation List (CRL) 16 3.4.5 Authority Revocation List (ARL) 16 3.4.6 PKCS #7 wrapped X.509 certificate 16 3.4.7 Certificate Payloads Not Mandatory 16 3.4.8 Response to Multiple Certificate Authority Proposals... 17 3.4.9 Using Local Keying Materials 17 3.4.10 Robustness 17 3.4.10.1 Unrecognized or Unsupported Certificate Types 17 3.4.10.2 Undecodable Certificate Data Fields 17 3.4.10.3 Ordering of Certificate Payloads 17 3.4.10.4 Duplicate Certificate Payloads 18 3.4.10.5 Irrelevant Certificates 18 3.4.11 Optimizations 18 3.4.11.1 Duplicate Certificate Payloads 18 3.4.11.2 Send Lowest 'Common' Certificates 18 3.4.11.3 Drop Duplicate Certificate Payloads 18 4 Profile of PKIX 18 4.1 X.509 Certificates 18 4.1.1 Versions 19 4.1.2 Subject Name 19 4.1.2.1 Empty Subject Name 19 4.1.2.2 Specifying Hosts in Subject Name 19 4.1.2.2.1 Non-FQDN Host Names 19 4.1.2.2.2 FQDN Host Names 19 4.1.2.3 EmailAddress 19 4.1.3 X.509 Certificate Extensions 20 4.1.3.1 AuthorityKeyIdentifier 20 4.1.3.2 SubjectKeyIdentifier 20 4.1.3.3 KeyUsage 20 4.1.3.4 PrivateKeyUsagePeriod 20 4.1.3.5 Certificate Policies 21 4.1.3.6 PolicyMappings 21 4.1.3.7 SubjectAltName 21 4.1.3.7.1 Permitted Choices 21 4.1.3.7.1.1 dNSName 21 4.1.3.7.1.2 iPAddress 21 4.1.3.7.1.3 rfc822Name 22 4.1.3.8 IssuerAltName 22 4.1.3.9 SubjectDirectoryAttributes 22 4.1.3.10 BasicConstraints 22 4.1.3.11 NameConstraints 22 4.1.3.12 PolicyConstraints 22 4.1.3.13 ExtendedKeyUsage 22 4.1.3.14 CRLDistributionPoint 23 4.1.3.15 InhibitAnyPolicy 23 4.1.3.16 FreshestCRL 23 4.1.3.17 AuthorityInfoAccess 23 Korver, Rescorla [Page 3] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 4.1.3.18 SubjectInfoAccess 23 4.2 X.509 Certificate Revocation Lists 23 4.2.1 Certificate Revocation Requirement 24 4.2.2 Multiple Sources of Certificate Revocation Informatio... 24 4.2.3 X.509 Certificate Revocation List Extensions 24 4.2.3.1 AuthorityKeyIdentifier 24 4.2.3.2 IssuerAltName 24 4.2.3.3 CRLNumber 24 4.2.3.4 DeltaCRLIndicator 24 4.2.3.4.1 If Delta CRLs Are Unsupported 24 4.2.3.4.2 Delta CRL Recommendations 25 4.2.3.5 IssuingDistributionPoint 25 4.2.3.6 FreshestCRL 25 5 Configuration Data Exchange Conventions 25 5.1 Certificates 25 5.2 Public Keys 26 5.3 PKCS#10 Certificate Signing Requests 26 6 IKE 26 6.1 IKE Phase 1 Authenticated With Signatures 26 6.1.1 Identification Payload 26 6.1.2 X.509 Certificate Extensions 26 6.1.2.1 KeyUsage 26 6.1.3 Obtaining Peer Certificates and CRLs 27 6.2 IKE Phase 1 Authenticated With Public Key Encryption... 27 6.2.1 Identification Payload 27 6.2.2 Hash Payload 27 6.2.3 X.509 Certificate Extensions 27 6.2.3.1 KeyUsage 27 6.2.4 Obtaining Peer Certificates and CRLs 27 6.3 IKE Phase 1 Authenticated With a Revised Mode of Publ... 27 7 Security Considerations 28 7.1 Identity Payload 28 7.2 Certificate Request Payload 28 7.3 Certificate Payload 28 7.4 IKE Main Mode 28 7.5 IKE Aggressive Mode 28 8 Intellectual Property Rights 29 9 IANA Considerations 29 1. Introduction IKE [IKE] and ISAKMP [ISAKMP] provide a secure key exchange mechanism for use with IPsec [IPSEC]. In many cases the peers authenticate using digital certificates as specified in PKIX [PKIX]. Unfortu- nately, the combination of these standards leads to an underspecified set of requirements for the use of certificates in the context of IPsec. Korver, Rescorla [Page 4] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 ISAKMP references PKIX but in many cases merely specifies the con- tents of various messages without specifying their syntax or seman- tics. Meanwhile, PKIX provides a large set of certificate mechanisms which are generally applicable for Internet protocols, but little specific guidance for IPsec. Given the numerous underspecified choices, interoperability is hampered if all implementors do not make similar choices, or at least fail to account for implementations which have choosen differently. This profile of the ISAKMP and PKIX frameworks is intended to provide an agreed upon standard for using PKI technology in the context of IPsec by profiling the PKIX framework for use with ISAKMP and IPsec, and by documenting the contents of the relevant ISAKMP payloads and further specifying their semantics. In addition to providing a profile of ISAKMP and PKIX, this document attempts to incorporate lessons learned from recent experience with both implementation and deployment, as well as the current state of related protocols and technologies. Material from ISAKMP and PKIX is not repeated here, and readers of this document are assumed to have read and understood both documents. The requirements and security aspects of those documents are fully relevant to this document as well. Version "01" of this document is intended as a "straw man" to encour- age comments from implementors of IPsec and to encourage discussion of the issues which the authors hope to address this document. This document is being discussed on the ipsec@lists.tislabs.com mail- ing list, which is the mailing list for the IPsec Working Group. 2. Terms and Definitions Except for those terms which are defined immediately below, all PKI terms used in this document are defined in either the PKIX, ISAKMP, or DOI [DOI] documents. * Peer source address: The source address in packets from a peer. This address may be different from any addresses asserted as the "identity" of the peer. * FQDN: Fully qualified domain name. * Root CA: A CA that is directly trusted by an end entity. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Korver, Rescorla [Page 5] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 3. Profile of ISAKMP 3.1. Background 3.1.1. Certificate-Related Payloads in ISAKMP ISAKMP has three primary certificate-related payloads: Identifica- tion, Certificate, and Certificate Request. Additionally, IKE speci- fies the optional use of the Hash Payload to carry a pointer to a certificate in either of the Phase 1 public key encryption modes. In this section we provide a short introduction to these payload types. 3.1.1.1. Identification Payload The Identification (ID) Payload is used to indicate the identity that the agent claims to be speaking for. The receiving agent can then use the ID as a lookup key for policy and whatever certificate store or directory that it has available. Our primary concern in this document is to profile the ID payload so that it can be safely used to gener- ate or lookup policy. 3.1.1.2. Certificate Payload The Certificate (CERT) Payload allows the peer to transmit a single certificate or CRL. Multiple certificates are transmitted in multiple payloads. However, not all certificate forms that are legal in PKIX make sense in the context of ISAKMP or IPsec. The issue of how to represent ISAKMP-meaningful name-forms in a certificate is especially problematic. This memo provides a profile for a subset of PKIX that makes sense for ISAKMP. 3.1.1.3. Certificate Request Payload The Certificate Request (CERTREQ) Payload allows an ISAKMP implemen- tation to request that a peer provide some set of certificates or certificate revocation lists. It is not clear from ISAKMP exactly how that set should be specified or how the peer should respond. We describe the semantics on both sides. 3.1.1.4. Hash Payload The Hash (HASH) Payload is a generic mechanism for ISAKMP implementa- tions to communicate hash values to a peer. The meaning of the con- tents of such payloads is left undefined by ISAKMP. Korver, Rescorla [Page 6] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 3.1.2. Endpoint Identification ISAKMP contains two different payloads that allow the specification of endpoint identity, the ID payload and the CERT payload. According to ISAKMP, these payloads can be used separately or together, although specific profiles of ISAKMP may place additional require- ments on implementations. 3.1.2.1. Identification Payload Only If one peer presents only the ID payload, it is expected that the peer will be able to recover whatever keying material is required to verify the peer's identity. How to do so is out of the scope of this document but might include a local cache, an LDAP directory, or DNS. 3.1.2.2. Certificate Payload Only If a peer presents only a CERT payload, this creates an ambiguity, since ISAKMP does not specify which of potentially many certificates corresponds to the end-entity and which are chaining certificates. Implementations SHOULD compare whatever local hints they have about peer identity to each certificate until they find one that appears acceptable. 3.2. Identification Payload The ID payload requirements in this document cover only the portion of the explicit policy checks that deal with the Identity Payload specifically. For instance, in the case where ID does not contain an IP address, checks such as verifying that the peer source address is permitted by the relevant policy are not addressed here as they are out of the scope of this document. The [DOI] defines the 11 types of Identification Data that can be used and specifies the syntax for these types. All of these are dis- cussed immediately below. 3.2.1. ID_IPV4_ADDR and ID_IPV6_ADDR Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR ID type. These addresses MUST be stored in "network byte order," as specified in [RFC 791]. The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For the ID_IPV4_ADDR type, the payload MUST contain exactly four octets [RFC791]. For the ID_IPV6_ADDR type, the payload MUST contain exactly sixteen octets [RFC1883]. When comparing the contents of ID with the iPAddress field in the subjectAltName extension for equality, binary comparison is performed. Korver, Rescorla [Page 7] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 3.2.2. ID_FQDN Implementations MAY support the ID_FQDN ID type, generally to support host-based access control lists for hosts without fixed IP addresses. However, implementations SHOULD NOT use the DNS to map the FQDN to IP addresses for input into any policy decisions, unless that mapping is known to be secure, such as when [DNSSEC] is employed. When comparing the contents of ID with the dNSName field in the subjectAltName extension for equality, caseless string comparison is performed. Sub- string, wildcard, or regular expression matching MUST NOT be per- formed. 3.2.3. ID_USER_FQDN Implementations MAY support the ID_USER_FQDN ID type, generally to support user-based access control lists for users without fixed IP addresses. However, implementations SHOULD NOT use the DNS to map the FQDN portion to IP addresses for input into any policy decisions, unless that mapping is known to be secure, such as when [DNSSEC] is employed. When comparing the contents of ID with the rfc822Name field in the subjectAltName extension for equality, caseless string compar- ison is performed. Substring, wildcard, or regular expression match- ing MUST NOT be performed. 3.2.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE As there is currently no standard method for putting address subnet or range identity information into certificates, the use of these ID types is currently undefined. 3.2.5. ID_DER_ASN1_DN Implementations MAY support receiving the ID_DER_ASN1_DN ID type, although implementations SHOULD NOT generate this type. Implementa- tions which generate this type SHOULD populate the contents of ID with the Subject Name from the end entity certificate, and MUST do so such that a binary comparison of the two will succeed. For instance, if the certificate was erroneously created such that the encoding of the Subject Name DN varies from the constraints set by DER, that non- conformant DN that MUST be used to populate the ID payload: implemen- tations MUST NOT re-encode the DN for the purposes of making it DER if it does not appear in the certificate as DER. Implementations MUST NOT populate ID with the Subject Name from the end entity certificate if it is empty, as described in the "Subject" section of PKIX. Korver, Rescorla [Page 8] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 3.2.6. ID_DER_ASN1_GN Implementations MAY support the ID_DER_ASN1_GN ID type, although implementations SHOULD NOT generate this type unless it is known through out-of-band means that the peer is capable of understanding this type. Implementations which generate this type MUST populate the contents of ID with the a GeneralName from the SubjectAltName exten- sion in the end entity certificate, and MUST do so such that a binary comparison of the two will succeed. For instance, if the certificate was erroneously created such that the encoding of the GeneralName varies from the constraints set by DER, that non- conformant General- Name MUST be used to populate the ID payload: implementations MUST NOT re-encode the GeneralName for the purposes of making it DER if it does not appear in the certificate as DER. 3.2.7. ID_KEY_ID Type ID_KEY_ID type used to specify pre-shared keys and thus is not relevant to this document. 3.2.8. Using Peer Source IP Address to Bind Identity to Policy Because implementations sometimes use ID as a lookup key to determine which policy to use, all implementations MUST be especially careful to verify the truthfulness of the contents by verifying that they correspond to some keying material demonstrably held by the peer. Failure to do so may result in the use of an inappropriate or inse- cure policy. The following sections describe the methods for perform- ing this binding. Implementations MAY use the IP address found in the header of packets received from the peer to lookup the policy, but such implementations MUST still perform verification of the ID payload. Although packet IP addresses are inherently untrustworthy and must therefore be indepen- dently verified, it is often useful to use the apparent IP address of the peer to locate a general class of policies that will be used until the mandatory identity-based policy lookup can be performed. For instance, if the IP address of the peer is unrecognized, a VPN gateway device might load a general "road warrior" policy that speci- fies a particular CA that is trusted to issue certificates which con- tain a valid rfc822Name which can be used by that implementation to perform authorization based on access control lists (ACLs). The rfc822Name can then be used to determine the policy that provides specific authorization to access resources (such as IP addresses, ports, and so forth). Korver, Rescorla [Page 9] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 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. As a general comment, however, it may be easier to spoof the contents of an ID payload than it is to spoof a peer source address because the peer source address must exist on the route to the peer, while ID can contain essentially random identification information. Implemen- tations MUST validate the Identity Data provided by a peer, but implementations MAY favor unauthenticated peer source addresses over an unauthenticated ID for initial policy lookup. 3.2.9. Securely Binding Identity to Policy 3.2.9.1. Single Address Identification Data In the case where ID contains ID_IPV4_ADDR or ID_IPV6_ADDR (that is, is not an address range or subnet), implementations MUST verify that this address is the same as the peer source address. If the end entity certificate contains addresses identities, then the peer source address must match at least one of those identities. If either of the above do not match, this MUST be treated as an error and secu- rity association setup MUST be aborted. This event SHOULD be auditable. The definition of "match" is specific to each ID type and was discussed above. In addition, implementations MUST allow adminis- trators to configure a local policy that requires that the peer source address exist in the certificate. Implementations SHOULD allow administrators to configure a local policy that does not enforce this requirement. 3.2.9.2. Identification Data other than a Single Address In the case where ID contains an identity type other than a single address, implementations MUST verify that the identity contained in the ID payload matches identity information contained in the peer end entity certificate, either in the Subject Name field or subjectAlt- Name extension. If there is not a match, this MUST be treated as an error and security association setup MUST be aborted. This event SHOULD be auditable. The definition of "match" is specific to each ID type and was discussed above. 3.2.10. Selecting an Identity from a Certificate Implementations MUST support certificates that contain more than a single identity. In many cases a certificate will contain an identity such as an IP address in the subjectAltName extension in addition to a non-empty Subject Name. Korver, Rescorla [Page 10] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 Which identity an implementations chooses to populate ID with is a local matter. For compatibility with non-conformant implementations, implementations SHOULD populate ID with whichever identity is likely to be named in the peer's policy. In practice, this generally means IP address, FQDN, or USER-FQDN. 3.2.11. Transitively Binding Identity to Policy In the presence of certificates that contain multiple identities, implementations SHOULD NOT assume that a peer will choose the most appropriate identity with which to populate ID. Therefore, implemen- tations SHOULD select the most appropriate identity to use from the identities contained in the certificate when determining the appro- priate policy. For example, imagine that a peer is configured with a certificate that contains both a non-empty Subject Name and an FQDN. Independent of which identity is used to populate ID, the host implementation MUST locate the proper policy. For instance, if ID contains the peer Subject Name, then the peer end entity certificate may be found using the Subject Name as a key. Once the certificate has been located and then validated, the FQDN in the certificate can be used to locate the appropriate policy. 3.3. Certificate Request Payload 3.3.1. Certificate Type The Certificate Type field identifies to the peer the type of certificate keying materials that are desired. ISAKMP defines 10 types of Certificate Data that can be requested and specifies the syntax for these types. For the purposes of this document, only the following types are relevant: * X.509 Certificate - Signature * X.509 Certificate - Key Exchange * Certificate Revocation List (CRL) * Authority Revocation List (ARL) * PKCS #7 wrapped X.509 certificate For example, if CRLs are desired, an implementation will populate the Certificate Type field with the value associated with "Certificate Revocation List (CRL)". The use of the other types: * PGP Certificate * DNS Signed Key Korver, Rescorla [Page 11] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 * Kerberos Tokens * SPKI Certificate * X.509 Certificate - Attribute are out of the scope of this document. 3.3.2. X.509 Certificate - Signature This type requests that the end entity certificate be a signing certificate. Implementations that receive CERTREQs which contain this ID type in a context in which end entity signature certificates are not used SHOULD ignore such CERTREQs. 3.3.3. X.509 Certificate - Key Exchange This type requests that the end entity certificate be a key exchange certificate. Implementations that receive CERTREQs which contain this ID type in a context in which end entity key exchange certificates are not used SHOULD ignore such CERTREQs. 3.3.4. Certificate Revocation List (CRL) This type requests that X.509 CRLs be provided, along with any cer- tificates that may be needed to validate those CRLs. 3.3.5. Authority Revocation List (ARL) This ID type SHOULD be treated as synonymous with the CRL type. Implementations SHOULD NOT generate CERTREQ payloads with this type, but should instead generate CRL CERTREQs. 3.3.6. PKCS #7 wrapped X.509 certificate This ID type defines a particular encoding (not a particular certificate or CRL type), some current implementations may ignore CERTREQs they receive which contain this ID type, and the authors are unaware of any implementations that generate such CERTREQ messages. Therefore, the use of this type is deprecated. Implementations SHOULD NOT generate CERTREQs that contain this Certificate Type. Implementa- tions which receive CERTREQs which contain this ID type MAY ignore such payloads. 3.3.7. Presence or Absence of Certificate Request Payloads When in-band exchange of certificate keying materials is desired, implementations MUST inform the peer of this by sending at least one CERTREQ. An implementation which does not send any CERTREQs during an exchange SHOULD NOT expect to receive any CERT payloads. Korver, Rescorla [Page 12] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 3.3.8. Certificate Requests 3.3.8.1. Specifying Certificate Authorities Implementations MUST generate CERTREQs for every peer root that local policy explicitly deems trusted during a given exchange. Implementa- tions MUST populate the Certificate Authority field with the Subject Name of the trusted root, populated such that binary comparison of the Subject Name and the Certificate Authority will succeed. Upon receipt of a CERTREQ where the Certificate Type is either "X.509 Certificate - Signature" or "X.509 Certificate - Key Exchange", implementations MUST respond by sending each certificate in the chain from the end entity certificate to the certificate whose Issuer Name matches the name specified in the Certificate Authority field. Imple- mentations MAY send other certificates from the chain. 3.3.8.2. Empty Certificate Authority Field Implementations MUST NOT generate CERTREQs where the Certificate Type is either "X.509 Certificate - Signature" or "X.509 Certificate - Key Exchange" with an empty Certificate Authority field. Upon receipt of such a CERTREQ from a non-conformant implementation, implementations SHOULD send just the certificate chain associated with the end entity certificate, not including any CRLs or the certificates that would be needed to validate those CRLs. Note, in the case where multiple end entity certificates may be available, implementations SHOULD resort to local heuristics to determine which end entity is most appropriate to use. Such heuris- tics are out of the scope of this document. 3.3.9. CRL Requests 3.3.9.1. Specifying Certificate Authorities Upon receipt of a CERTREQ where the Certificate Type is "Certificate Revocation List (CRL)", implementations MUST respond by sending the CRL issued by the issuer of each certificate in the chain between the end entity certificate and the certificate whose Issuer Name matches the name specified in the Certificate Authority field. In additional, implementations MUST send any certificates that are needed to vali- date those CRLs. 3.3.9.2. Empty Certificate Authority Field Implementations MAY generate CERTREQs where the Certificate Type is "Certificate Revocation List (CRL)" with an empty Certificate Korver, Rescorla [Page 13] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 Authority field to signify that the peer should send all CRLs that are possessed by that peer, whether relevant to the current exchange or not. Upon receipt of such a CERTREQ, implementations SHOULD send all CRLs that are possessed but MUST send all CRLs that are relevant to the current exchange, including the certificates that are needed to validate those CRLs. 3.3.10. Robustness 3.3.10.1. Unrecognized or Unsupported Certificate Types Implementations MUST be able to deal with receiving CERTREQs with unsupported Certificate Types. Absent any recognized and supported CERTREQs, implementations MAY treat them as if they are of a sup- ported type with the Certificate Authority field left empty, depend- ing on local policy. ISAKMP Section 5.10 "Certificate Request Payload Processing" specifies additional processing. 3.3.10.2. Undecodable Certificate Authority Fields Implementations MUST be able to deal with receiving CERTREQs with undecodable Certificate Authority fields. Implementations MAY treat such fields as if there were empty, depending on local policy. ISAKMP specifies other actions which may be taken. 3.3.10.3. Ordering of Certificate Request Payloads Implementations MUST NOT assume that CERTREQs are ordered in any way. 3.3.11. Optimizations 3.3.11.1. Duplicate Certificate Request Payloads Implementations SHOULD NOT send duplicate CERTREQs during an exchange. 3.3.11.2. Name Lowest 'Common' Certification Authorities When a peer's certificate keying materials have been cached, an implementation can send a hint to the peer to elide some of the cer- tificates and CRLs the peer would normally respond with. In addition to the normal set of CERTREQs that are sent, an implementation MAY send CERTREQs containing the Issuer Name of the relevant cached end entity certificates. When sending these hints, it is still necessary to send the normal set of CERTREQs because the hints do not suffi- ciently convey all of the information required by the peer. Specifi- cally, either the peer may not support this optimization or there may be additional chains that could be used in this context but will not Korver, Rescorla [Page 14] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 be specified if only supplying the issuer of the end entity certificate. No special processing is required on the part of the recipient of such a CERTREQ, and the end entity certificates will still be sent. On the other hand, the recipient MAY elect to elide certificates based on receipt of such hints. ISAKMP mandates that CERTREQs contain the Subject Name of a Certifi- cation Authority, which results in the peer always sending at least the end entity certificate. This mechanism allows implementations to determine unambiguously when a new certificate is being used by the peer, perhaps because the previous certificate has just expired, which will result in a failure because the needed keying materials are not available to validate the new end entity certificate. Imple- mentations which implement this optimization MUST recognize when the end entity certificate has changed and respond to it by not perform- ing this optimization when the exchange is retried. 3.3.11.3. Example Imagine that an implementation has previously received and cached the peer certificate chain R->CA1->CA2->EE. If during a subsequent exchange this implementation sends a CERTREQ containing the Subject Name in certificate R, this implementation is requesting that the peer send at least 3 certificates: CA1, CA2, and EE. On the other hand, if this implementation also sends a CERTREQ containing the Sub- ject Name of CA2, the implementation is providing a hint that only 1 certificate needs to be sent: EE. 3.4. Certificate Payload 3.4.1. Certificate Type The Certificate Type field identifies to the peer the type of certificate keying materials that are included. ISAKMP defines 10 types of Certificate Data that can be sent and specifies the syntax for these types. For the purposes of this document, only the follow- ing types are relevant: * X.509 Certificate - Signature * X.509 Certificate - Key Exchange * Certificate Revocation List (CRL) * Authority Revocation List (ARL) * PKCS #7 wrapped X.509 certificate For example, if CRLs are desired, an implementation will populate the Certificate Type field with the value associated with "Certificate Korver, Rescorla [Page 15] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 Revocation List (CRL)". The use of the other types: * PGP Certificate * DNS Signed Key * Kerberos Tokens * SPKI Certificate * X.509 Certificate - Attribute are out of the scope of this document. 3.4.2. X.509 Certificate - Signature This type specifies that Certificate Data contains a certificate used for signing, whether an end entity signature certificate or a CA certificate signing certificate. 3.4.3. X.509 Certificate - Key Exchange This type specifies that Certificate Data contains an end entity certificate used for either key exchange (or key encipherment). 3.4.4. Certificate Revocation List (CRL) This type specifies that Certificate Data contains an X.509 CRL. 3.4.5. Authority Revocation List (ARL) This type specifies that Certificate Data contains an X.509 CRL that revokes CAs. 3.4.6. PKCS #7 wrapped X.509 certificate This type defines a particular encoding, not a particular certificate or CRL type. Implementations MUST NOT generate CERTs that contain this Certificate Type. Implementations which violate this requirement SHOULD note that this is a single certificate as specified in ISAKMP. Implementations MAY accept CERTs that contain this Certificate type. 3.4.7. Certificate Payloads Not Mandatory An implementation which does not receive any CERTREQs during an exchange SHOULD NOT send any CERT payloads, except when explicitly configured to proactively send CERT payloads in order to interoperate with non-compliant implementations. In this case, an implementation MUST send the all certificate chains and CRLs associated with the end entity certificate. This MUST NOT be the default behavior of Korver, Rescorla [Page 16] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 implementations. Implementations which are configured to expect that a peer must receive certificates through out-of-band means SHOULD ignore any CERTREQ messages that are received. Implementations that receive CERTREQs from a peer which contain only unrecognized Certification Authorities SHOULD NOT continue the exchange, in order to avoid unnecessary and potentially expensive cryptographic processing. 3.4.8. Response to Multiple Certificate Authority Proposals In response to multiple CERTREQs which contain different Certificate Authority identities, implementations MAY respond using an end entity certificate which chains to a CA that matches any of the identities provided by the peer. 3.4.9. Using Local Keying Materials Implementations MAY elect not to use keying materials contained in a given set of CERTs if preferable keying materials are available. For instance, the contents of a CERT may be available from a previous exchange, or a newer CRL may be available through some out-of-band means. 3.4.10. Robustness 3.4.10.1. Unrecognized or Unsupported Certificate Types Implementations MUST be able to deal with receiving CERTs with unrec- ognized or unsupported Certificate Types. Implementations MAY discard such payloads, depending on local policy. ISAKMP Section 5.10 "Certificate Request Payload Processing" specifies additional pro- cessing. 3.4.10.2. Undecodable Certificate Data Fields Implementations MUST be able to deal with receiving CERTs with unde- codable Certificate Data fields. Implementations MAY discard such payloads, depending on local policy. ISAKMP specifies other actions which may be taken. 3.4.10.3. Ordering of Certificate Payloads Implementations MUST NOT assume that CERTs are ordered in any way. Korver, Rescorla [Page 17] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 3.4.10.4. Duplicate Certificate Payloads Implementations MUST support receiving multiple identical CERTs dur- ing an exchange. 3.4.10.5. Irrelevant Certificates Implementations MUST be prepared to receive certificates and CRLs which are not relevant to the current exchange. Implementations MAY discard such keying materials. Implementations MAY include certificates which are irrelevant to an exchange. One reason for including certificates which are irrelevant to an exchange is to minimize the threat of leaking identifying information in exchanges where CERT is not encrypted. It should be noted, however, that this probably provides rather poor protection against leaking the identity. 3.4.11. Optimizations 3.4.11.1. Duplicate Certificate Payloads Implementations SHOULD NOT send duplicate CERTs during an exchange. Such payloads should be suppressed. 3.4.11.2. Send Lowest 'Common' Certificates When multiple CERTREQs are received which specify certificate author- ities within the end entity certificate chain, implementations MAY send the shortest chain possible. However, implementations SHOULD always send the end entity certificate. See section 3.3.12.2 for more discussion of this optimization. 3.4.11.3. Drop Duplicate Certificate Payloads Implementations MAY employ local means to recognize CERTs that have been received in the past, whether part of the current exchange or not, for which keying material is available and may discard these duplicate CERTs. 4. Profile of PKIX 4.1. X.509 Certificates Korver, Rescorla [Page 18] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 4.1.1. Versions Although PKIX states that "implementations SHOULD be prepared to accept any version certificate", in practice this profile requires certain extensions that necessitate the use of Version 3 certifi- cates. Implementations that conform to this document MAY therefore reject Version 1 and Version 2 certificates. 4.1.2. Subject Name 4.1.2.1. Empty Subject Name Implementations MUST accept certificates which contain an empty Sub- ject Name field, as specified in PKIX. Identity information in such certificates will be contained entirely in the SubjectAltName exten- sion. 4.1.2.2. Specifying Hosts in Subject Name 4.1.2.2.1. Non-FQDN Host Names Implementations which desire to place host names that are not FQDNs (for instance "Gateway Router") in the Subject Name MUST use the com- monName attribute. 4.1.2.2.2. FQDN Host Names Implementations which desire to place host names that are FQDNs (for instance "gateway.xythos.com") in the Subject Name field SHOULD use the commonName attribute type. Implementations SHOULD NOT populate the Subject Name in place of pop- ulating the dNSName field of the SubjectAltName extension. Host names that appear in the Subject Name cannot be unambiguously determined to be a host name. Note, PKIX defines a domainComponent attribute for representing FQDNs in DistinguishedNames such as Subject Name. As an alternative to using commonName, implementations MAY use the domainComponent attribute type. However, note that support for the domainComponent attribute is far from universal and some implementations will reject certificates that contain this attribute. 4.1.2.3. EmailAddress As specified in PKIX, implementations MUST NOT populate Distin- guishedNames with the EmailAddress attribute. Korver, Rescorla [Page 19] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 4.1.3. X.509 Certificate Extensions Conforming applications MUST recognize extensions which must or may be marked critical according to this specification. These extensions are: KeyUsage, SubjectAltName, and BasicConstraints. Implementations SHOULD generate certificates such that the extension criticality bits are set in accordance with PKIX and this document. With respect to PKIX compliance, implementations processing certifi- cates MAY ignore the value of the criticality bit for extensions that are supported by that implementation, but MUST support the critical- ity bit for extensions that are not supported by that implementation. 4.1.3.1. AuthorityKeyIdentifier Implementations SHOULD NOT assume that other implementations support the AuthorityKeyIdentifier extension, and thus should generate certificate hierarchies which overly complex to process in the absence of this extension, such that those that require possibly ver- ifying a signature against a large number of similarly named CA cer- tificates in order to find the CA certificate which contains the key that was used to generate the signature. 4.1.3.2. SubjectKeyIdentifier Implementations SHOULD NOT assume that other implementations support the SubjectKeyIdentifier extension, and thus should generate certificate hierarchies which overly complex to process in the absence of this extension, such that those that require possibly ver- ifying a signature against a large number of similarly named CA cer- tificates in order to find the CA certificate which contains the key that was used to generate the signature. 4.1.3.3. KeyUsage The meaning of the nonRepudiation bit is undefined in the context of IPsec. Implementations SHOULD ignore this bit if present. See PKIX for general guidance on which of the other KeyUsage bits should be set in any given certificate. 4.1.3.4. PrivateKeyUsagePeriod PKIX recommends against the use of this extension. The Pri- vateKeyUsageExtension is intended to be used when signatures will need to be verified long past the time when signatures using the pri- vate keypair may be generated. Since ISAKMP SAs are short-lived rela- tive to the intended use of this extension in addition to the fact Korver, Rescorla [Page 20] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 that each signature is validated only a single time, the meaning of this extension in the context of ISAKMP is unclear. Therefore, the PrivateKeyUsagePeriod is inappropriate in the context of ISAKMP and therefore implementations MUST NOT generate certificates that contain the PrivateKeyUsagePeriod extension. 4.1.3.5. Certificate Policies Many IPsec implementations do not currently provide support for the Certificate Policies extension. Therefore, implementations that gen- erate certificates which contain this extension SHOULD mark the extension as non-critical. 4.1.3.6. PolicyMappings Many implementations do not support the PolicyMappings extension. 4.1.3.7. SubjectAltName 4.1.3.7.1. Permitted Choices Implementations SHOULD generate only the following GeneralName choices in the subjectAltName extension, as these choices map to legal ISAKMP Identity Payload types ISAKMP: rfc822Name, dNSName, or iPAddress. Although it is possible to specify any GeneralName choice in the ISAKMP Identity Payload by using the ID_DER_ASN1_GN ID type, implementations SHOULD NOT assume that a peer supports such function- ality. 4.1.3.7.1.1. dNSName This field MUST contain a fully qualified domain name. Implementa- tions MUST NOT generate names that contain wildcards. Implementations MAY treat certificates that contain wildcards in this field as syntactically invalid. Although this field is in the form of an FQDN, implementations SHOULD NOT assume that the this field contains an FQDN that will resolve via the DNS, unless this is known by way of some out-of-band mechanism. Such a mechanism is out of the scope of this document. Implementa- tions SHOULD NOT treat the failure to resolve as an error. 4.1.3.7.1.2. iPAddress Note that the CIDR [CIDR] notation permitted in the "Name Con- straints" section of PKIX is explicitly not permitted by that speci- fication for conveying identity information. In other words, the CIDR Korver, Rescorla [Page 21] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 notation MUST NOT be used in the subjectAltName extension. 4.1.3.7.1.3. rfc822Name Although this field is in the form of an Internet mail address, implementations SHOULD NOT assume that the this field contains a valid email address, unless this is known by way of some out-of-band mechanism. Such a mechanism is out of the scope of this document. 4.1.3.8. IssuerAltName Implementations SHOULD NOT assume that other implementations support the IssuerAltName extension, and especially should not assume that information contained in this extension will be displayed to end users. 4.1.3.9. SubjectDirectoryAttributes The SubjectDirectoryAttributes extension is intended to contain priv- ilege information, in a manner analogous to privileges carried in Attribute Certificates. Implementations MAY ignore this extension as PKIX mandates it be marked non-critical. 4.1.3.10. BasicConstraints PKIX mandates that CA certificates contain this extension and that it be marked critical. For backwards compatibility, implementations SHOULD accept CA certificates that do not contain this extension or that contain this extension marked non-critical. 4.1.3.11. NameConstraints Many implementations do not support the NameConstraints extension. Since PKIX mandates that this extension be marked critical when pre- sent, implementations which intend to be maximally interoperable SHOULD NOT generate certificates which contain this extension. 4.1.3.12. PolicyConstraints Many implementations do not support the PolicyConstraints extension. Since PKIX mandates that this extension be marked critical when pre- sent, implementations which intend to be maximally interoperable SHOULD NOT generate certificates which contain this extension. 4.1.3.13. ExtendedKeyUsage No ExtendedKeyUsage usages are defined for IPsec, so if this exten- sion is present and marked critical, use of this certificate for Korver, Rescorla [Page 22] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 IPsec MUST be treated as an error. Implementations MUST NOT generate this extension in certificates which are being used for IPsec. 4.1.3.14. CRLDistributionPoint Most implementations expect to exchange CRLs in band via the ISAKMP Certificate Payload. Implementations MUST NOT assume that the CRLDis- tributionPoint extension will exist in peer extensions and therefore implementations SHOULD request that peers send CRLs in the absence of knowledge that this extension exists in the peer's certificates. 4.1.3.15. InhibitAnyPolicy Many implementations do not support the InhibitAnyPolicy extension. Since PKIX mandates that this extension be marked critical when pre- sent, implementations which intend to be maximally interoperable SHOULD NOT generate certificates which contain this extension. 4.1.3.16. FreshestCRL Most implementations expect to exchange CRLs in band via the ISAKMP Certificate Payload. Implementations MUST NOT assume that the Fresh- estCRL extension will exist in peer extensions and therefore imple- mentations SHOULD request that peers send CRLs in the absence knowl- edge that this extension exists in the peer certificates. 4.1.3.17. AuthorityInfoAccess PKIX defines the AuthorityInfoAccess extension, which is used to "how to access CA information and services for the issuer of the certificate in which the extension appears." This extension has no known use in the context of IPsec. Conformant implementations SHOULD ignore this extension when present. 4.1.3.18. SubjectInfoAccess PKIX defines the SubjectInfoAccess private certificate extension, which is used to indicate "how to access information and services for the subject of the certificate in which the extension appears." This extension has no known use in the context of IPsec. Conformant imple- mentations SHOULD ignore this extension when present. 4.2. X.509 Certificate Revocation Lists Implementations SHOULD send CRLs, unless non-CRL certificate revoca- tion information is known to be preferred by all interested parties in the application environment that the implementation is used. Implementations MUST send CRLs if non-CRL certificate revocation Korver, Rescorla [Page 23] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 information may not be available to all interested parties. 4.2.1. Certificate Revocation Requirement Implementations which validate certificates MUST make use of certificate revocation information, and SHOULD support such revoca- tion information in the form of CRLs, unless non-CRL revocation information is known to be the only method for transmitting this information. 4.2.2. Multiple Sources of Certificate Revocation Information Implementations which support multiple sources of obtaining certificate revocation information MUST act conservatively when the information provided by these sources is inconsistent: when a certificate is reported as revoked by one source, the certificate MUST be considered revoked. 4.2.3. X.509 Certificate Revocation List Extensions 4.2.3.1. AuthorityKeyIdentifier Implementations SHOULD NOT assume that other implementations support the AuthorityKeyIdentifier extension, and thus should generate certificate hierarchies which overly complex to process in the absence of this extension. 4.2.3.2. IssuerAltName Implementations SHOULD NOT assume that other implementations support the IssuerAltName extension, and especially should not assume that information contained in this extension will be displayed to end users. 4.2.3.3. CRLNumber As stated in PKIX, all issuers conforming to PKIX MUST include this extension in all CRLs. 4.2.3.4. DeltaCRLIndicator 4.2.3.4.1. If Delta CRLs Are Unsupported Implementations that do not support delta CRLs MUST reject CRLs which contain the DeltaCRLIndicator (which MUST be marked critical accord- ing to PKIX) and MUST make use of a base CRL if it is available. Such implementations MUST ensure that a delta CRL does not "overwrite" a base CRL, for instance in the keying material database. Korver, Rescorla [Page 24] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 4.2.3.4.2. Delta CRL Recommendations Since some implementations that do not support delta CRLs may behave incorrectly or insecurely when presented with delta CRLs, implementa- tions SHOULD consider whether issuing delta CRLs increases security before issuing such CRLs. The authors are aware of several implementations which behave in an incorrect or insecure manner when presented with delta CRLs. See Appendix B for a description of the issue. Therefore, this specifica- tion RECOMMENDS against issuing delta CRLs at this time. On the other hand, failure to issue delta CRLs exposes a larger window of vulnera- bility. See the Security Considerations section of PKIX for addi- tional discussion. Implementors as well as administrators are encour- aged to consider these issues. 4.2.3.5. IssuingDistributionPoint Given the recommendations against implementations generating delta CRLs, this specification RECOMMENDS that implementations do not popu- late CRLs with the IssuingDistributionPoint extension, which must be marked critical if present according to PKIX but is generally only useful in the context of delta CRLs. 4.2.3.6. FreshestCRL Given the recommendations against implementations generating delta CRLs, this specification RECOMMENDS that implementations do not popu- late CRLs with the FreshestCRL extension, which is used to obtain delta CRLs. 5. Configuration Data Exchange Conventions Below we present a common format for exchanging configuration data. Implementations MUST support these formats, MUST support arbitrary whitespace at the beginning and end of any line, and MUST support the three line-termination disciplines: LF (US-ASCII 10), CR (US-ASCII 13), and CRLF. 5.1. Certificates Certificates MUST be Base64 encoded and appear between the following delimiters: -----BEGIN CERTIFICATE----- Korver, Rescorla [Page 25] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 -----END CERTIFICATE----- 5.2. Public Keys Implementations MUST support two forms of public keys: certificates and so-called "raw" keys. Certificates should be transferred in the same form as above. A raw key is only the SubjectPublicKeyInfo por- tion of the certificate, and MUST be Base64 encoded and appear between the following delimiters: -----BEGIN PUBLIC KEY----- -----END PUBLIC KEY----- 5.3. PKCS#10 Certificate Signing Requests A PKCS#10 Certificiate Signing Request MUST be Base64 encoded and appear between the following delimeters: -----BEGIN CERTIFICATE REQUEST----- -----END CERTIFICATE REQUEST----- 6. IKE 6.1. IKE Phase 1 Authenticated With Signatures 6.1.1. Identification Payload IKE mandates the use of the ID payload in Phase 1. Implementations SHOULD populate ID with identity information that is contained within the end entity certificate. This enables recipients to use ID as a lookup key to find the peer end entity certificate. The only case where implementations MAY populate ID with information that is not contained in the end entity certificate is when ID con- tains the peer source address (a single address, not a subnet or range). This means that implementations MUST be able to map a peer source address to a peer end entity certificate, even when the certificate does not contain that address. The exact method for per- forming this mapping is out of the scope of this document. 6.1.2. X.509 Certificate Extensions 6.1.2.1. KeyUsage If the KeyUsage extension is present in an end entity certificate, the digitalSignature bit must be asserted. Korver, Rescorla [Page 26] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 6.1.3. Obtaining Peer Certificates and CRLs IKE implementations MUST assume all necessary certificates and CRLs will be exchanged in-band. 6.2. IKE Phase 1 Authenticated With Public Key Encryption 6.2.1. Identification Payload IKE mandates the use of the ID payload in Phase 1. If certificates are not being used, the contents of ID are out of scope for this document. 6.2.2. Hash Payload IKE specifies the optional use of the Hash Payload to carry a pointer to a certificate in either of the Phase 1 public key encryption modes. This pointer is used by an implementation to locate the end entity certificate that contains the public key that a peer should use for encrypting payloads during the exchange. Implementations SHOULD include this payload whenever the public por- tion of the keypair has been placed in a certificate. 6.2.3. X.509 Certificate Extensions 6.2.3.1. KeyUsage If the KeyUsage extension is present in an end entity certificate, the keyEncipherment bit must be asserted. 6.2.4. Obtaining Peer Certificates and CRLs Certificates are generally not exchanged in-band, but rather are exchanged out-of-band, with direct trust of the peer certificate being most prevalent. CRLs SHOULD be obtained out-of-band from a directory or other repository. 6.3. IKE Phase 1 Authenticated With a Revised Mode of Public Key Encryption IKE Phase 1 Authenticated With a Revised Mode of Public Key Encryp- tion has the same requirements as IKE Phase 1 Authenticated With Pub- lic Key Encryption. See section 6.2 for these requirements. Korver, Rescorla [Page 27] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 7. Security Considerations 7.1. Identity Payload Depending on the exchange type, ID may be passed in the clear. Admin- istrators in some environments may wish to use the empty Certifica- tion Authority option to prevent such information from leaking, at the possible cost of some performance. 7.2. Certificate Request Payload The Contents of CERTREQ are not encrypted in IKE. In some environ- ments this may leak private information. Administrators in some envi- ronments may wish to use the empty Certification Authority option to prevent such information from leaking, at the cost of performance. 7.3. Certificate Payload Depending on the exchange type, CERTs may be passed in the clear and therefore may leak identity information. 7.4. IKE Main Mode Implementations may not wish to respond with CERTs in the second mes- sage, thereby violating the identity protection feature of Main Mode IKE. ISAKMP allows CERTs to be included in any message, and therefore implementations may wish to respond with CERTs in a message that offers privacy protection in this case. 7.5. IKE Aggressive Mode The contents of ID are not encrypted in Aggressive Mode when authen- tication is performed with signatures. In some environments this may leak private information. The solutions to this problem if such a leak is unacceptable are: * Use Main Mode instead of Aggressive Mode. * Populate ID Data with the address of the host. The contents of CERT are not encrypted in Aggressive Mode when authentication is performed with signatures. In some environments this may leak private information. The solutions to this problem if such a leak is unacceptable are: * Use Main Mode instead of Aggressive Mode. Korver, Rescorla [Page 28] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 8. Intellectual Property Rights No new intellectual property rights are introduced by this document. 9. IANA Considerations There are no known numbers which IANA will need to manage. References [CIDR] Fuller, V., et al., "Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [IPSEC] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [ISAKMP] Maughan, D., et. al., "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [PKIX] Housley, R., et al., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1883] Deering, S. and Hinden, R. "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap", draft-ietf-pkix-roadmap-08.txt. Korver, Rescorla [Page 29] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 Acknowledgments The authors would like to acknowledge the expired draft-ietf-ipsec- pki-req-05.txt for providing valuable materials for this document. The authors would like to thank Greg Carter for his valuable comments on an early draft of this document. Author's Addresses Brian Korver Xythos Software, Inc. 25 Maiden Lane, 6th Floor San Francisco, CA 94108 USA Phone: +1 415 248-3800 EMail: briank@xythos.com Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA Phone: +1 650 320-8549 EMail: ekr@rtfm.com Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Korver, Rescorla [Page 30] Internet-Draft PKI Profile for ISAKMP/PKIX 10/2002 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Appendix A. Change History * October 2002, Reorganization * June 2002, Initial Draft Appendix B. The Possible Dangers of Delta CRLs The problem is that the CRL processing algorithm is often written with the assumption that all CRLs are base CRLs and it is assumed that CRLs will pass content validity tests. Specifically, such imple- mentations fail to check the certificate against all possible CRLs: if the first CRL that is obtained from the keying material database fails to decode, no further revocation checks are performed for the relevant certificate. This problem is compounded by the fact that implementations which do not understand delta CRLs may fail to decode such CRLs due to the critical DeltaCRLIndicator extension. The algo- rithm that is implemented in this case is approximately: fetch newest CRL check validity of CRL signature if CRL signature is valid then if CRL does not contain unrecognized critical extensions and certificate is on CRL then set certificate status to revoked The authors note that a number of PKI toolkits do not even provide a method for obtaining anything but the newest CRL, which in the presence of delta CRLs may in fact be a delta CRL, not a base CRL. Korver, Rescorla [Page 31]