Brian Korver Xythos Software INTERNET-DRAFT May 2004 (Expires Oct 2004) The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, 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 material 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 complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates 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 IKEv1/ISAKMP and IKEv2 5 3.1 Identification Payload 5 3.1.1 ID_IPV4_ADDR and ID_IPV6_ADDR 7 3.1.2 ID_FQDN 8 3.1.3 ID_USER_FQDN 9 Korver [Page 1] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 3.1.4 ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_A... 9 3.1.5 ID_DER_ASN1_DN 9 3.1.6 ID_DER_ASN1_GN 10 3.1.7 ID_KEY_ID 10 3.1.8 Selecting an Identity from a Certificate 10 3.1.9 Transitively Binding Identity to Policy 10 3.2 Certificate Request Payload 11 3.2.1 Certificate Type 11 3.2.2 X.509 Certificate - Signature 11 3.2.3 Certificate Revocation List (CRL) 11 3.2.4 Authority Revocation List (ARL) 12 3.2.5 PKCS #7 wrapped X.509 certificate 12 3.2.6 Presence or Absence of Certificate Request Payloads 12 3.2.7 Certificate Requests 12 3.2.7.1 Specifying Certificate Authorities 12 3.2.7.2 Empty Certificate Authority Field 13 3.2.8 Robustness 13 3.2.8.1 Unrecognized or Unsupported Certificate Types 13 3.2.8.2 Undecodable Certificate Authority Fields 13 3.2.8.3 Ordering of Certificate Request Payloads 13 3.2.9 Optimizations 13 3.2.9.1 Duplicate Certificate Request Payloads 13 3.2.9.2 Name Lowest 'Common' Certification Authorities 14 3.2.9.3 Example 14 3.3 Certificate Payload 14 3.3.1 Certificate Type 15 3.3.2 X.509 Certificate - Signature 15 3.3.3 X.509 Certificate - Signature 15 3.3.4 Certificate Revocation List (CRL) 16 3.3.5 Authority Revocation List (ARL) 16 3.3.6 PKCS #7 wrapped X.509 certificate 16 3.3.7 Certificate Payloads Not Mandatory 16 3.3.8 Response to Multiple Certificate Authority Proposals 16 3.3.9 Using Local Keying Materials 17 3.3.10 Robustness 17 3.3.10.1 Unrecognized or Unsupported Certificate Types 17 3.3.10.2 Undecodable Certificate Data Fields 17 3.3.10.3 Ordering of Certificate Payloads 17 3.3.10.4 Duplicate Certificate Payloads 17 3.3.10.5 Irrelevant Certificates 17 3.3.11 Optimizations 18 3.3.11.1 Duplicate Certificate Payloads 18 3.3.11.2 Send Lowest 'Common' Certificates 18 3.3.11.3 Ignore Duplicate Certificate Payloads 18 3.3.12 Hash Payload 18 4 Profile of PKIX 19 4.1 X.509 Certificates 19 4.1.1 Versions 19 Korver [Page 2] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 4.1.2 Subject Name 19 4.1.2.1 Empty Subject Name 19 4.1.2.2 Specifying Non-FQDN Hosts in Subject Name 19 4.1.2.3 Specifying FQDN Host Names in Subject Name 19 4.1.2.4 EmailAddress 20 4.1.3 X.509 Certificate Extensions 20 4.1.3.1 AuthorityKeyIdentifier 20 4.1.3.2 SubjectKeyIdentifier 21 4.1.3.3 KeyUsage 21 4.1.3.4 PrivateKeyUsagePeriod 21 4.1.3.5 Certificate Policies 21 4.1.3.6 PolicyMappings 21 4.1.3.7 SubjectAltName 21 4.1.3.7.1 dNSName 22 4.1.3.7.2 iPAddress 22 4.1.3.7.3 rfc822Name 22 4.1.3.8 IssuerAltName 22 4.1.3.9 SubjectDirectoryAttributes 22 4.1.3.10 BasicConstraints 23 4.1.3.11 NameConstraints 23 4.1.3.12 PolicyConstraints 23 4.1.3.13 ExtendedKeyUsage 23 4.1.3.14 CRLDistributionPoints 23 4.1.3.15 InhibitAnyPolicy 24 4.1.3.16 FreshestCRL 24 4.1.3.17 AuthorityInfoAccess 24 4.1.3.18 SubjectInfoAccess 24 4.2 X.509 Certificate Revocation Lists 24 4.2.1 Multiple Sources of Certificate Revocation Information 25 4.2.2 X.509 Certificate Revocation List Extensions 25 4.2.2.1 AuthorityKeyIdentifier 25 4.2.2.2 IssuerAltName 25 4.2.2.3 CRLNumber 25 4.2.2.4 DeltaCRLIndicator 25 4.2.2.4.1 If Delta CRLs Are Unsupported 25 4.2.2.4.2 Delta CRL Recommendations 25 4.2.2.5 IssuingDistributionPoint 26 4.2.2.6 FreshestCRL 26 5 Configuration Data Exchange Conventions 26 5.1 Certificates 26 5.2 Public Keys 27 5.3 PKCS#10 Certificate Signing Requests 27 6 Security Considerations 27 6.1 Identification Payload 27 6.2 Certificate Request Payload 27 6.3 Certificate Payload 27 6.4 IKEv1 Main Mode 28 7 Intellectual Property Rights 28 Korver [Page 3] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 8 IANA Considerations 28 9 Normative References 28 10 Informational References 29 11 Acknowledgements 29 12 Author's Addresses 29 1. Introduction IKE [IKEv1] and ISAKMP [ISAKMP] and IKEv2 [IKEv2] 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]. Unfortunately, the combination of these standards leads to an underspecified set of requirements for the use of certificates in the context of IPsec. ISAKMP references PKIX but in many cases merely specifies the contents of various messages without specifying their syntax or semantics. 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 chosen 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, IKEv2, or 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. This document is organized as follows. Section 2 defines special terminology used in the rest of this document, Section 3 provides the profile of IKEv1/ISAKMP and IKEv2, and Section 4 provides the profile of PKIX. Section 5 covers conventions for the out-of-band exchange of keying materials for configuration purposes. This document is being discussed on the pki4ipsec@icsalabs.com mailing list. Korver [Page 4] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 2. Terms and Definitions Except for those terms which are defined immediately below, all terms used in this document are defined in either the PKIX, ISAKMP, IKEv2, 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. * ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both are referred to as ID_USER_FQDN in this document. 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]. 3. Profile of IKEv1/ISAKMP and IKEv2 3.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 generate or lookup policy. IKE mandates the use of the ID payload in Phase 1. The [DOI] defines the 11 types of Identification Data that can be used and specifies the syntax for these types. These are discussed below in detail. The ID payload requirements in this document cover only the portion of the explicit policy checks that deal with the Identification 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. Implementations SHOULD populate ID with identity information that is contained within the end entity certificate (This SHOULD does not contradict text in IKEv2 Section 3.5 that implies a looser binding between these two). Populating ID with identity information from the end entity certificate 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 contains the peer Korver [Page 5] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 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 performing this mapping is out of the scope of this document. Because implementations may 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 insecure policy. The following sections describe the methods for performing this binding. The following table summarizes the binding of the Identification Payload to the contents of end-entity certificates and of identity information to policy. ID type | Support | Correspond | Cert | SPD lookup | for send | PKIX Attrib | matching | rules ------------------------------------------------------------------- | | | | IP*_ADDR | MUST [1] | SubjAltName | MUST [2] | MUST [3] | | iPAddress | | | | | | FQDN | MUST [1] | SubjAltName | MUST [2] | MUST [3] | | dNSName | | | | | | USER_FQDN| MUST [1] | SubjAltName | MUST [2] | MUST [3] | | rfc822Name | | | | | | DN | MUST [1] | Entire | MUST [2] | MUST support lookup | | Subject, | | on any combination | | bitwise | | of C, CN, O, or OU | | compare | | | | | | IP range | MUST NOT | n/a | n/a | n/a | | | | | | | | KEY_ID | MUST NOT | n/a | n/a | n/a | | | | [1] = MUST be able to send based on local configuration. [2] = The ID in the ID payload MUST match the contents of the corresponding field (listed) in the certificate exactly, with no other lookup. The matched ID MAY be used for SPD lookup, but is not required to be used for this. Korver [Page 6] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 [3] = MUST be able to support exact matching in the SPD, but MAY also support substring or wildcard matches. When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, implementations MUST be configurable to send the same string as appears in the corresponding SubjectAltName attribute. Recipients MAY use wildcards to do the SPD matching. When sending a DN as ID, implementations MUST send the entire DN in ID. Recipients MAY perform SPD lookup based on some combination of C, CN, O, OU. Implementations MUST at a minimum be configurable to match on any combination of those 4 attributes. Implementations MAY support matching using other DN attributes in any combination, including the entire DN. IKEv2 ads an optional IDr payload in the second exchange that the initiator may send to the responder specify which of the responder's identities should be used. The responder MAY choose to send an IDr in the 3rd exchange that differs in type or content from the initiator- generator IDr. The initiator MUST be able to receive a responder- generated IDr that is different from the one the initiator generated. 3.1.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 [RFC791]: 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 MUST be performed. Note that this document RECOMMENDS against populating the ID payload with IP addresses due to interoperability issues such as problem with NAT traversal. Implementations MUST be capable of verifying that the address contained in ID is the same as the peer source address. Implementations MAY provide a configuration option to skip that verification step, but that option MUST be off by default. If the end entity certificate contains address 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 security association setup MUST be aborted. This event SHOULD be auditable. In Korver [Page 7] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 addition, implementations MUST allow administrators 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. 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 independently 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 specifies a particular CA that is trusted to issue certificates which contain a valid rfc822Name which can be used by that implementation to perform authorization based on access control lists (ACLs) after the peer's certificate has been validated. 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). As another example, if the IP address of the peer is recognized to be a known peer VPN endpoint, policy may be determined using that address, but until the identity (address) is validated by validating the peer certificate, the policy MUST NOT be used to authorize any IPsec traffic. Whether the address need appear as an identity in the certificate is a matter of local policy, and SHOULD be configurable by an administrator. 3.1.2. ID_FQDN Implementations MUST 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 MUST be performed. Substring, wildcard, or regular expression matching MUST NOT be performed. Implementations MUST verify that the identity contained in the ID payload matches identity information contained in the peer end entity certificate, in the subjectAltName 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. Korver [Page 8] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 3.1.3. ID_USER_FQDN Implementations MUST 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 comparison MUST be performed. Substring, wildcard, or regular expression matching MUST NOT be performed. Implementations MUST verify that the identity contained in the ID payload matches identity information contained in the peer end entity certificate, in the subjectAltName 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. 3.1.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. Implementations MUST NOT generate these ID types. Note that work in [SBGP] for defining blocks of addresses using the certificate extension identified by id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 } is experimental at this time. 3.1.5. ID_DER_ASN1_DN Implementations MUST support receiving the ID_DER_ASN1_DN ID type. Implementations MAY generate this type. Implementations which generate this type MUST 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 MUST be used to populate the ID payload: in other words, implementations 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 [Page 9] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 Implementations MUST verify that the identity contained in the ID payload matches identity information contained in the peer end entity certificate, in the Subject Name field. 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. 3.1.6. ID_DER_ASN1_GN Implementations MUST NOT generate this type. 3.1.7. ID_KEY_ID The ID_KEY_ID type used to specify pre-shared keys and thus is out of scope. 3.1.8. 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. Which identity an implementation 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.1.9. 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, when determining the appropriate policy, implementations SHOULD select the most appropriate identity to use from the identities contained in the certificate. For example, imagine that a peer is configured with a certificate that contains both a non-empty Subject Name and an dNSName. 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 dNSName in the certificate can be used to locate the appropriate policy. In other words, the Subject Name is used to find the certificate, the certificate contains the dNSName, and the dNSName is used to lookup policy. Korver [Page 10 ] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 3.2. Certificate Request Payload The Certificate Request (CERTREQ) Payload allows an implementation 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.2.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 * Certificate Revocation List (CRL) * Authority Revocation List (ARL) * PKCS #7 wrapped X.509 certificate The use of the other types: * X.509 Certificate - Key Exchange * PGP Certificate * DNS Signed Key * Kerberos Tokens * SPKI Certificate * X.509 Certificate - Attribute are out of the scope of this document. In addition to the above, IKEv2 adds 3 additional types which are not profiled in this document: * Raw RSA Key * Hash and URL of X.509 certificate * Hash and URL of X.509 bundle 3.2.2. X.509 Certificate - Signature This type requests that the end entity certificate be a signing certificate. 3.2.3. Certificate Revocation List (CRL) ISAKMP and IKEv2 do not support Certificate Payload sizes over approximately 64K, which is too small for many CRLs. For this and other reasons, implementations SHOULD NOT generate CERTREQs where the Korver [Page 11 ] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 Certificate Type is "Certificate Revocation List (CRL)". Upon receipt of such a CERTREQ, implementations MAY ignore the request. 3.2.4. Authority Revocation List (ARL) Implementations SHOULD NOT generate CERTREQ payloads with this type. Recipients of this type SHOULD treat it as synonymous with the CRL type. 3.2.5. PKCS #7 wrapped X.509 certificate This ID type defines a particular encoding (not a particular certificate), 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 require CERTREQs that contain this Certificate Type. Implementations which receive CERTREQs which contain this ID type MAY treat such payloads as synonymous with "X.509 Certificate - Signature". 3.2.6. 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. 3.2.7. Certificate Requests 3.2.7.1. Specifying Certificate Authorities Implementations MUST generate CERTREQs for every peer trust anchor that local policy explicitly deems trusted during a given exchange. For IKEv1, implementations MUST populate the Certificate Authority field with the Subject Name of the trust anchor, populated such that binary comparison of the Subject Name and the Certificate Authority will succeed. For IKEv2, implementations MUST populate the Certificate Authority field as specified in [IKEv2]. Upon receipt of a CERTREQ, implementations MUST respond by sending the end entity certificate but MAY also send each certificate in the chain above the end entity certificate up to and including the certificate whose Issuer Name matches the name specified in the Certificate Authority field. Implementations MAY send other certificates. Note, in the case where multiple end entity certificates may be available, implementations SHOULD resort to local heuristics to Korver [Page 12 ] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 determine which end entity is most appropriate to use for generating the CERTREQ. Such heuristics are out of the scope of this document. 3.2.7.2. Empty Certificate Authority Field Implementations MUST NOT generate CERTREQs where the Certificate Type is "X.509 Certificate - Signature" with an empty Certificate Authority field, as this form is explicitly deprecated. 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 that PKIX prohibits certificates with an empty issuer name field. 3.2.8. Robustness 3.2.8.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 supported type with the Certificate Authority field left empty, depending on local policy. ISAKMP Section 5.10 "Certificate Request Payload Processing" specifies additional processing. 3.2.8.2. Undecodable Certificate Authority Fields Implementations MUST be able to deal with receiving CERTREQs with undecodable Certificate Authority fields. Implementations MAY ignore such payloads, depending on local policy. ISAKMP specifies other actions which may be taken. 3.2.8.3. Ordering of Certificate Request Payloads Implementations MUST NOT assume that CERTREQs are ordered in any way. 3.2.9. Optimizations 3.2.9.1. Duplicate Certificate Request Payloads Implementations SHOULD NOT send duplicate CERTREQs during an exchange. Korver [Page 13 ] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 3.2.9.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 certificates the peer would normally respond with. In addition to the normal set of CERTREQs that are sent specifying the trust anchors, 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 sufficiently convey all of the information required by the peer. Specifically, either the peer may not support this optimization or there may be additional chains that could be used in this context but will not 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. CERTREQs must contain information that identifies a Certification Authority certificate, 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. Implementations which implement this optimization MUST recognize when the end entity certificate has changed and respond to it by not performing this optimization when the exchange is retried. 3.2.9.3. Example Imagine that an implementation has previously received and cached the peer certificate chain TA->CA1->CA2->EE. If during a subsequent exchange this implementation sends a CERTREQ containing the Subject Name in certificate TA, 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 Subject Name of CA2, the implementation is providing a hint that only 1 certificate needs to be sent: EE. Note that in this example, the fact that TA is a trust anchor should not be construed to imply that TA is a self-signed certificate. 3.3. Certificate Payload The Certificate (CERT) Payload allows the peer to transmit a single certificate or CRL. Multiple certificates should be transmitted in Korver [Page 14] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 multiple payloads. However, not all certificate forms that are legal in PKIX make sense in the context of IPsec. The issue of how to represent IKE-meaningful name-forms in a certificate is especially problematic. This memo provides a profile for a subset of PKIX that makes sense for IKEv1/ISAKMP and IKEv2. 3.3.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 following types are relevant: * X.509 Certificate - Signature * Certificate Revocation List (CRL) * Authority Revocation List (ARL) * PKCS #7 wrapped X.509 certificate The use of the other types: * X.509 Certificate - Key Exchange * PGP Certificate * DNS Signed Key * Kerberos Tokens * SPKI Certificate * X.509 Certificate - Attribute are out of the scope of this document. In addition to the above, IKEv2 adds 3 additional types which are not profiled in this document: * Raw RSA Key * Hash and URL of X.509 certificate * Hash and URL of X.509 bundle 3.3.2. X.509 Certificate - Signature This type requests that the end entity certificate be a signing certificate. 3.3.3. 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 signature certificate. Korver [Page 15] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 3.3.4. Certificate Revocation List (CRL) This type specifies that Certificate Data contains an X.509 CRL. 3.3.5. Authority Revocation List (ARL) This type specifies that Certificate Data contains an X.509 CRL that applies only to CA certificates. Recipients of this type MAY treat it as synonymous with the CRL type. 3.3.6. PKCS #7 wrapped X.509 certificate This type defines a particular encoding, not a particular certificate type. Implementations SHOULD NOT generate CERTs that contain this Certificate Type. Implementations SHOULD accept CERTs that contain this Certificate Type because several implementations are known to generate them. Note that those implementations may include entire certificate hierarchies inside a single CERT PKCS #7 payload, which violates the requirement specified in ISAKMP that this payload contain a single certificate. 3.3.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 MAY send the certificate chain (not including the trust anchor) associated with the end entity certificate. This MUST NOT be the default behavior of 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.3.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. Korver [Page 16] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 3.3.9. Using Local Keying Materials Implementations MAY elect skip the processing of 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 may be available through some out-of-band means. 3.3.10. Robustness 3.3.10.1. Unrecognized or Unsupported Certificate Types Implementations MUST be able to deal with receiving CERTs with unrecognized or unsupported Certificate Types. Implementations MAY discard such payloads, depending on local policy. ISAKMP Section 5.10 "Certificate Request Payload Processing" specifies additional processing. 3.3.10.2. Undecodable Certificate Data Fields Implementations MUST be able to deal with receiving CERTs with undecodable Certificate Data fields. Implementations MAY discard such payloads, depending on local policy. ISAKMP specifies other actions which may be taken. 3.3.10.3. Ordering of Certificate Payloads For IKEv1, implementations MUST NOT assume that CERTs are ordered in any way. For IKEv2, implementations MUST NOT assume that any except the first CERT is ordered in any way. IKEv2 specifies that the first CERT contain the end entity certificate which is to be used to authenticate the peer. 3.3.10.4. Duplicate Certificate Payloads Implementations MUST support receiving multiple identical CERTs during an exchange. 3.3.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 extraneous certificates and CRLs. Implementations MAY send 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 Korver [Page 17] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 against leaking the identity. Another reason for including certificates that seem irrelevant to an exchange is that there may be two chains from the Certificate Authority to the end entity, each of which is only valid with certain validation parameters (such as acceptable policies). Since the end entity doesn't know which parameters the relying party is using, it should send the certs needed for both chains (even if there's only one CERTREQ). Although implementations SHOULD NOT send multiple end entity certificates if the receipient cannot determine the correct certificate to use for authentication by using either the contents of the ID payload to match the certificate or, in IKEv2, the correct certificate is contained in the first CERT. In other words, receipients SHOULD NOT be expected to iterate over multiple end- entity certs. 3.3.11. Optimizations 3.3.11.1. Duplicate Certificate Payloads Implementations SHOULD NOT send duplicate CERTs during an exchange. Such payloads should be suppressed. 3.3.11.2. Send Lowest 'Common' Certificates When multiple CERTREQs are received which specify certificate authorities 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.2.9.2 for more discussion of this optimization. 3.3.11.3. Ignore 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. 3.3.12. Hash Payload IKEv1 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 Korver [Page 18] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 should use for encrypting payloads during the exchange. Implementations SHOULD include this payload whenever the public portion of the keypair has been placed in a certificate. 4. Profile of PKIX Except where specifically stated in this document, implementations MUST conform to the requirements of [PKIX]. 4.1. X.509 Certificates 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 certificates for all but self-signed certificates used as trust anchors. Implementations that conform to this document MAY therefore reject Version 1 and Version 2 certificates in all other cases. 4.1.2. Subject Name 4.1.2.1. Empty Subject Name Implementations MUST accept certificates which contain an empty Subject Name field, as specified in PKIX. Identity information in such certificates will be contained entirely in the SubjectAltName extension. 4.1.2.2. Specifying Non-FQDN Hosts in Subject Name Implementations which desire to place host names that are not intended to be processed by recipients as FQDNs (for instance "Gateway Router") in the Subject Name MUST use the commonName attribute. While nothing prevents an FQDN, USER_FQDN, or IP address information from appearing somewhere in the Subject Name contents, such entries MUST NOT be interpreted as identity information for the purposes of matching with ID or for policy lookup. 4.1.2.3. Specifying FQDN Host Names in Subject Name Implementations MUST NOT populate the Subject Name in place of populating the dNSName field of the SubjectAltName extension. Korver [Page 19] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 4.1.2.4. EmailAddress As specified in PKIX, implementations MUST NOT populate DistinguishedNames with the EmailAddress attribute. 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 certificates MAY ignore the value of the criticality bit for extensions that are supported by that implementation, but MUST support the criticality bit for extensions that are not supported by that implementation. That is, if an implementation supports (and thus is going to process) a given extension, then it isn't necessary to reject the certificate if the criticality bit is different from what PKIX states it must be. However, if an implementation does not support an extension that PKIX mandates be critical, then the implementation must reject the certificate. implements bit in cert PKIX mandate behavior ------------------------------------------------------ yes true true ok yes true false ok or reject yes false true ok or reject yes false false ok no true true reject no true false reject no false true reject no false false ok 4.1.3.1. AuthorityKeyIdentifier Implementations SHOULD NOT assume that other implementations support the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate certificate hierarchies which are overly complex to process in the absence of this extension, such as those that require possibly verifying a signature against a large number of similarly named CA certificates in order to find the CA certificate which contains the key that was used to generate the signature. Korver [Page 20] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 4.1.3.2. SubjectKeyIdentifier Implementations SHOULD NOT assume that other implementations support the SubjectKeyIdentifier extension, and thus SHOULD NOT generate certificate hierarchies which are overly complex to process in the absence of this extension, such as those that require possibly verifying a signature against a large number of similarly named CA certificates 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 not defined in the context of IPsec, although implementations SHOULD interpret the nonRepudiation bit as synonymous with the digitalSignature bit. Implementations SHOULD NOT generate certificates which only assert the nonRepudiation bit. 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 PrivateKeyUsageExtension is intended to be used when signatures will need to be verified long past the time when signatures using the private keypair may be generated. Since IKE SAs are short-lived relative to the intended use of this extension in addition to the fact that each signature is validated only a single time, the usefulness of this extension in the context of IKE is unclear. 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 generate 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 Implementations SHOULD generate only the following GeneralName choices in the subjectAltName extension, as these choices map to Korver [Page 21] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 legal Identification Payload types: rfc822Name, dNSName, or iPAddress. Although it is possible to specify any GeneralName choice in the Identification Payload by using the ID_DER_ASN1_GN ID type, implementations SHOULD NOT assume that a peer supports such functionality. 4.1.3.7.1. dNSName This field MUST contain a fully qualified domain name. Implementations 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 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. Implementations SHOULD NOT treat the failure to resolve as an error. 4.1.3.7.2. iPAddress Note that although PKIX permits CIDR [CIDR] notation in the "Name Constraints" extension, PKIX explicitly prohibits using CIDR notation for conveying identity information. In other words, the CIDR notation MUST NOT be used in the subjectAltName extension. 4.1.3.7.3. rfc822Name Although this field is in the form of an Internet mail address, implementations SHOULD NOT assume that 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 privilege information, in a manner analogous to privileges carried in Attribute Certificates. Implementations MAY ignore this extension when it is marked non-critical, as PKIX mandates. Korver [Page 22] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 4.1.3.10. BasicConstraints PKIX mandates that CA certificates contain this extension and that it be marked critical. Implementations SHOULD reject CA certificates that do not contain this extension. For backwards compatibility, implementations may accept such certificates if explicitly configured to do so, but the default for this setting MUST be to reject such certificates. 4.1.3.11. NameConstraints Many implementations do not support the NameConstraints extension. Since PKIX mandates that this extension be marked critical when present, 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 present, 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 specifically for IPsec, so if this extension is present and marked critical, use of this certificate for IPsec MUST be treated as an error unless the extension contains the anyExtendedKeyUsage keyPurposeID, which asserts that the certificate can be used for any purpose. Implementations MAY ignore this extension if it is marked non- critical. Implementations MUST NOT generate this extension in certificates which are being used for IPsec. Note that a previous proposal for the use of three ExtendedKeyUsage values is obsolete and explicitly deprecated by this specification. For historical reference, those values were id-kp-ipsecEndSystem, id- kp-ipsecTunnel, and id-kp-ipsecUser. 4.1.3.14. CRLDistributionPoints Receiving CRLs in band via IKE does not alleviate the requirement to process the CRLDistributionPoints if the certificate being validated contains the extension and the CRL being used to validate the certificate contains the IssuingDistributionPoint extension. Failure to validate the CRLDistributionPoints/IssuingDistributionPoint pair can result in CRL substitution where an entity knowingly substitutes a known good CRL from a different distribution point for the CRL Korver [Page 23] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 which is supposed to be used which would show the entity as revoked. Implementations MUST support validating that the contents of CRLDistributionPoints match those of the IssuingDistributionPoint to prevent CRL substitution when the issuing CA is using them. At least one CA is known to default to this type of CRL use. See section 4.2.2.5 for more information. See PKIX docs for CRLDistributionPoints intellectual rights information. Note that both the CRLDistributionPoints and IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED by PKIX, so there is no requirement to license any IPR. 4.1.3.15. InhibitAnyPolicy Many implementations do not support the InhibitAnyPolicy extension. Since PKIX mandates that this extension be marked critical when present, implementations which intend to be maximally interoperable SHOULD NOT generate certificates which contain this extension. 4.1.3.16. FreshestCRL Implementations MUST NOT assume that the FreshestCRL extension will exist in peer extensions. Note that most implementations do not support delta CRLs. 4.1.3.17. AuthorityInfoAccess PKIX defines the AuthorityInfoAccess extension, which is used to indicate "how to access CA information and services for the issuer of the certificate in which the extension appears." Conformant implementations MAY support this extension. 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 implementations SHOULD ignore this extension when present. 4.2. X.509 Certificate Revocation Lists When validating certificates, implementations MUST make use of certificate revocation information, and SHOULD support such revocation information in the form of CRLs, unless non-CRL revocation information is known to be the only method for transmitting this Korver [Page 24] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 information. Implementations MAY provide a configuration option to disable use of certain types of revocation information, but that option MUST be off by default. 4.2.1. 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 trusted source, the certificate MUST be considered revoked. 4.2.2. X.509 Certificate Revocation List Extensions 4.2.2.1. AuthorityKeyIdentifier Implementations SHOULD NOT assume that other implementations support the AuthorityKeyIdentifier extension, and thus SHOULD NOT generate certificate hierarchies which are overly complex to process in the absence of this extension. 4.2.2.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.2.3. CRLNumber As stated in PKIX, all issuers conforming to PKIX MUST include this extension in all CRLs. 4.2.2.4. DeltaCRLIndicator 4.2.2.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 according 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. 4.2.2.4.2. Delta CRL Recommendations Since some implementations that do not support delta CRLs may behave incorrectly or insecurely when presented with delta CRLs, implementations SHOULD consider whether issuing delta CRLs increases Korver [Page 25] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 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 specification RECOMMENDS against issuing delta CRLs at this time. On the other hand, failure to issue delta CRLs exposes a larger window of vulnerability. See the Security Considerations section of PKIX for additional discussion. Implementors as well as administrators are encouraged to consider these issues. 4.2.2.5. IssuingDistributionPoint A CA that is using CRLDistributionPoints may do so to provide many "small" CRLs, each only valid for a particular set of certificates issued by that CA. To associate a CRL with a certificate, the CA places the CRLDistributionPoints extension in the certificate, and places the IssuingDistributionPoint in the CRL. The distributionPointName field in the CRLDistributionPoints extension MUST be identical to the distributionPoint field in the IssuingDistributionPoint extension. At least one CA is known to default to this type of CRL use. See section 4.1.3.14 for more information. 4.2.2.6. FreshestCRL Given the recommendations against implementations generating delta CRLs, this specification RECOMMENDS that implementations do not populate 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, MUST support arbitrary line lengths although they SHOULD generate lines less than 76 characters, and MUST support the following 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 [Page 26] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 -----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 portion 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 [PKCS-10] Certificiate Signing Request MUST be Base64 encoded and appear between the following delimeters: -----BEGIN CERTIFICATE REQUEST----- -----END CERTIFICATE REQUEST----- 6. Security Considerations 6.1. Identification Payload Depending on the exchange type, ID may be passed in the clear. Administrators in some environments may wish to use the empty Certification Authority option to prevent such information from leaking, at the possible cost of some performance, although such use is discouraged. 6.2. Certificate Request Payload The Contents of CERTREQ are not encrypted in IKE. In some environments this may leak private information. Administrators in some environments may wish to use the empty Certification Authority option to prevent such information from leaking, at the cost of performance. 6.3. Certificate Payload Depending on the exchange type, CERTs may be passed in the clear and therefore may leak identity information. Korver [Page 27] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 6.4. IKEv1 Main Mode Implementations may not wish to respond with CERTs in the second message, thereby violating the identity protection feature of Main Mode in IKEv1. CERTs may 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. Intellectual Property Rights No new intellectual property rights are introduced by this document. 8. IANA Considerations There are no known numbers which IANA will need to manage. 9. Normative References [DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [IKEv1] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-13.txt, March 2004, work in progress. [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. [PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Korver [Page 28] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 10. Informational 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. [RFC1883] Deering, S. and Hinden, R. "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. [ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap", draft-ietf-pkix-roadmap-08.txt. [SBGP] Lynn, C., Kent, S., and Seo, K., "X.509 Extensions for IP Addresses and AS Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-00.txt. 11. Acknowledgements 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 especially thank Greg Carter, Russ Housley, Steve Hanna, and Gregory Lebovitz for their valuable comments, some of which have been incorporated unchanged into this document. 12. Author's Addresses Brian Korver Xythos Software, Inc. One Bush Street, Suite 600 San Francisco, CA 94104 USA Phone: +1 415 248-3800 EMail: briank@xythos.com Copyright (C) The Internet Society (2004). 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 document 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 developing Internet standards in which case the procedures for Korver [Page 29] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 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. 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Appendix A. Change History * May 2004 (renamed draft-ietf-pki4ipsec-ikecert-profile-00.txt) Made it clearer that the format of the ID_IPV4_ADDR payload comes from RFC791 and is nothing new. (Tero Kivinen Feb 29) Permit implementations to skip verifying that the peer source address matches the contents of ID_IPV{4,6}_ADDR. (Tero Kivinen Feb 29, Gregory Lebovitz Feb 29) Removed paragraph suggesting that implementations favor unauthenticated peer source addresses over an unauthenticated ID for initial policy lookup. (Tero Kivinen Feb 29, Gregory Lebovitz Feb 29) Removed some text implying RSA encryption mode was in scope. (Tero Kivinen Feb 29) Relaxed deprecation of PKCS#7 CERT payloads. (Tero Kivinen Feb 29) Made it clearer that out-of-scope local heuristics should be used for picking an EE cert to use when generating CERTREQ, not when receiving CERTREQ. (Tero Kivinen Feb 29) Korver [Page 30] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 Made it clearer that CERT processing can be skipped when the contents of a CERT are already known. (Tero Kivinen Feb 29) Implementations SHOULD generate BASE64 lines less than 76 characters. (Tero Kivinen Feb 29) Added "Except where specifically stated in this document, implementations MUST conform to the requirements of PKIX" (Steve Hanna Oct 7, 2003) RECOMMENDS against populating the ID payload with IP addresses due to interoperability issues such as problem with NAT traversal. (Gregory Lebovitz May 14) Changed "as revoked by one source" to "as revoked by one trusted source". (Michael Myers, May 15) Specifying Certificate Authorities section needed to be regularized with Gregory Lebovitz's CERT proposal from -04. (Tylor Allison, May 15) Added text specifying how receipients SHOULD NOT be expected to iterate over multiple end-entity certs. (Tylor Allison, May 15) Modified text to refer to IKEv2 as well as IKEv1/ISAKMP where relevant. IKEv2: Explained that IDr sent by responder doesn't have to match the [IDr] sent initiator in second exchange. IKEv2: Noted that "The identity ... does not necessarily have to match anything in the CERT payload" (S3.5) is not contradicted by SHOULD in this document. IKEv2: Noted that ID_USER_FQDN renamed to ID_RFC822_ADDR, and ID_USER_FQDN would be used exclusively in this document. IKEv2: Declared that 3 new CERTREQ and CERT types are not profiled in this document (well, at least not yet, pending WG discussion of what to do -- note that they are only SHOULDs in IKEv2). IKEv2: Noted that CERTREQ payload changed from DN to SHA-1 of SubjectPublicKeyInfo. IKEv2: Noted new requirement that specifies that the first certificate sent MUST be the EE cert (section 3.6). Korver [Page 31] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 * February 2004 (-04) Minor editorial changes to clean up language Deprecate in-band exchange of CRLs Incorporated Gregory Lebovitz's proposal for CERT payloads: "should deal with all the CRL, Intermediat Certs, Trust Anchors, etc OOB of IKE; MUST be able to send and receive EE cert payload; only real exception is Intermediate Cets which MAY be sent and SHOULD be able to be receivable (but in reality there are very few hierarchies in operation, so really it's a corner case); SHOULD NOT send the other stuff (CRL, Trust Anchors, etc) in cert payloads in IKE; SHOULD be able to accept the other stuff if by chance it gets sent, though we hope they don't get sent" Incorporated comments contained in Oct 7, 2003 email from steve.hanna@sun.com to ipsec@lists.tislabs.com Moved text from "Profile of ISAKMP" Background section to each payload section (removing duplication of these sections) Removed "Certificate-Related Playloads in ISAKMP" section since it was not specific to IKE. Incorporated Gregory Lebovitz's table in the "Identification Payload" section Moved text from "binding identity to policy" sections to each payload section Moved text from "IKE" section into now-combined "IKE/ISAKMP" section ID_USER_FQDN and ID_FQDN promoted to MUST from MAY Promoted sending ID_DER_ASN1_DN to MAY from SHOULD NOT, and receiving from MUST from MAY Demoted ID_DER_ASN1_GN to MUST NOT Demoted populating Subject Name in place of populating the dNSName from SHOULD NOT to MUST NOT and removed the text regarding domainComponent Revocation information checking MAY now be disabled, although not by default Korver [Page 32] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 Aggressive Mode removed from this profile * June 2003 (-03) Minor editorial changes to clean up language Minor additional clarifying text Removed hyphenation Added requirement that implementations support configuration data exchange having arbitrary line lengths * February 2003 (-02) Word choice: move from use of "root" to "trust anchor", in accordance with PKIX SBGP note and reference for placing address subnet and range information into certificates Clarification of text regarding placing names of hosts into the Name commonName attribute of SubjectName Added table to clarify text regarding processing of the certificate extension criticality bit Added text underscoring processing requirements for CRLDistributionPoints and IssuingDistributionPoint * October 2002, Reorganization (-01) * June 2002, Initial Draft (-00) Appendix B. The Possible Dangers of Delta CRLs The problem is that the CRL processing algorithm is sometimes written incorrectly with the assumption that all CRLs are base CRLs and it is assumed that CRLs will pass content validity tests. Specifically, such implementations 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 Korver [Page 33] Internet-Draft PKI Profile for IKE/ISAKMP/PKIX 5/2004 the fact that implementations which do not understand delta CRLs may fail to decode such CRLs due to the critical DeltaCRLIndicator extension. The algorithm 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. Note that the above algorithm is dangerous in many ways. See PKIX for the correct algorithm. Korver [Page 34]