Internet Draft Rodney Thayer draft-ietf-ipsec-pki-req-05.txt Charles Kunzinger, IBM July 10, 2000 Paul Hoffman, VPNC Expires in six months A PKIX Profile for IKE 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The IKE protocol allows the use of the PKIX profile of X.509v3 certificates for encryption and authentication. Common practice in the IPsec community differs in some ways from these specifications made in the PKIX format specification and other specifications that have come from the PKIX WG. In order to promote interoperability in the IPsec market, this document lays out a profile for using PKIX in IKE. 1. Introduction Implementors of IKE [RFC-2409] who use public key certificates have almost universally used PKIX certificates and certificate processing, as described in the PKIX certificate profile [RFC-2459], often called "PKIX Part 1". However, many implementors have not adhered completely to the PKIX certificate profile specification for a variety of reasons. Note that many IPsec implementors are not completely happy with the PKIX documents and procedures, but have agreed to use the PKIX protocols because they are supported in other contexts and have a significant market share. This document is a profile for the PKIX certificate profile and other PKI-related documents. IKE Implementors should follow all requirements and suggestions in those documents except where this document specifies differently. This document is a profile of the PKIX certificate profile and the PKIX roadmap [ROADMAP]. Material from those two documents is not repeated here, and readers of this document are assumed to have read and fully understood both documents. All security aspects of those documents are fully relevant to this one. The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC-2119]. All PKI terms used in this document are defined either in the PKIX certificate profile or the PKIX roadmap [ROADMAP]. For terms where the two documents differ, the definition in the PKIX roadmap is used. In particular, this document follows the PKIX roadmap's use of the term "root CA", meaning "a CA that is directly trusted by an end entity; that is, securely acquiring the value of a root CA public key requires some out-of-band step(s)". This document is being discussed on the ipsec@lists.tislabs.com mailing list, which is the mailing list for the IPsec Working Group. 2. Certificate Validation and Revocation Checking As described in the PKIX certificate profile, in certificate path validation for a path whose length is longer than 2, the relying party needs to check the validity of the certificates of subordinate CAs. An IKE system that conforms to this profile MAY get the certificates of subordinate CAs during the IKE exchanges, or MAY get those certificates through other methods, such as through a local certificate cache or from a directory. IKE systems conforming to this profile MUST support a signing hierarchy containing at least seven subordinate CAs between an end entity and a root CA. This means that a certificate chain might have nine certificates in it (the end-entity certificate, seven intermediate CAs, and the trusted root certificate). IKE systems conforming to this profile MUST check the revocation status of any certificate on which they rely, as described in the PKIX certificate profile. Thus, every conforming IKE system MUST have a method for receiving up-to-date revocation information for the certificates it is validating. An IKE system that conforms to this profile that learns that a certificate that was used in association with the creation of an existing security association becomes invalid for any reason MUST delete the corresponding IKE and IPsec security associations. A conforming IKE system SHOULD periodically check for revocation information such as CRLs and OCSP responses. 3. Certificate Format This profile modifies the use of two fields specified in the PKIX certificate profile. 3.1 The extendedKeyUsage field In a certificate for an IPsec end entity, the extendedKeyUsage field (commonly called "EKU") MAY be present. If it is present, the field SHOULD contain the object identifier iKEIntermediate (iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or 1.3.6.1.5.5.8.2.2). Note that this field is not given in the PKIX certificate profile. In fact, the PKIX certificate profile lists three object identifiers for IPsec devices: id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp- ipsecUser. These object identifiers never achieved any significant use in the IPsec community; they SHOULD NOT be used. 3.2 The subjectAltName field The subjectAltName field MAY be checked for identification of the device. It is explicitly valid for an IKE system that conforms to this profile to reject an end entity certificate whose identification fails any of the following tests. - If a name is the subjectAltName is an IP address, the IKE system MAY confirm that the IP address is valid for the IKE negotiation process. - If a name is a domain name, the IKE system MAY find the A record in the DNS that matches that domain name and MAY confirm that the IP address is valid for the IKE negotiation process. [[[ Should there be some discussion here about comparing the identification in the cert with the ID payload? If so, what should it say? ]]] 4. Extending the Validity Field to SAs The notAfter field of the validity field specifies the date after which the certificate is always considered invalid. An IKE implementation MUST examine the notAfter date in conjunction with all relevant SA lifetimes (both IKE SA and IPsec SA's) at the date the certificate is used to authenticate creation of an SA. If the SA would definitely expire after the end of the certificate lifetime, then either: - the SA SHOULD NOT be created at all - the SA SHOULD be created but the lifetime of the SA SHOULD match the certificate lifetime 5. Algorithm Requirements IKE systems that conform to this profile SHOULD support DSA-with-SHA1 signatures and RSA-with-SHA1 signatures on certificates (as expressed by the signatureAlgorithm in the certificate). The OIDs associated with these algorithms are id-dsa-with-sha1 and sha-1WithRSAEncryption, respectively. 1024-bit keys MUST be supported for each signature algorithm supported, and longer keys SHOULD be supported. 6. ISAKMP Certificate and Certificate Request Payloads The steps in this section use sequential numbering of IKE messages as shown in Sections 5.1-5.5 of [RFC 2409]. The first message sent by the IKE initiator is numbered 1, the response sent by the IKE responder is numbered 2, the next message from the Initiator is numbered 3, and so on. 6.1 Signature-based authentication End entity certificates contain identity information about the certificate's owner. Thus, some systems will want to only transmit their certificates in the protected messages of the IKE exchange. Other systems will not find such protection needed, such as if the identity is the IP address or domain name of the device owning the certificate. Certificate requests may reveal information about the system making the request. For instance, a certificate request that names a particular root CA could help identify that the system requesting the certificate is part of a particular security realm. However, most IKE systems have not to date shown much care about revealing the names of the roots they trust. In order to protect the identity in a Certificate payload, the IKE device that wishes to deliver its own certificates to its peer MUST use Main Mode MUST only include Certificate payloads in message 5 or 6. Devices not concerned with protecting the identity in a Certificate payload MAY put that payload in any IKE message in either Main Mode or Aggressive Mode. Devices receiving certificate payloads MUST store them for use during further messages in the same IKE exchange, and MAY store them for longer-term use, such as for future IKE exchanges. In order to protect the information in a Certificate Request payload, the IKE initiator that wishes to request a certificate MUST use Main Mode and MUST send the Certificate Request payload in message 5. IKE responders cannot protect Certificate Request payloads. Devices not concerned with protecting the information in a Certificate Request payload can include those payloads in messages 1 through 5 in Main Mode, or in messages 1 and 2 in Aggressive Mode. 6.2 Encryption-based authentication In Main Mode with encryption-based authentication, Certificate Request payloads, if they are to be included anywhere, SHOULD appear only in messages 1 and 2 because that is the only place where they are useful for the exchange. Certificate Request payloads SHOULD NOT appear in Aggressive Mode encryption-based authentication because they are never useful. In Main Mode with encryption-based authentication, Certificate payloads SHOULD only appear in messages 1, 2, and 3 because that is the only place where they are useful for the exchange; note that the certificates in these messages are not encrypted and will thus reveal identity information. In Aggressive Mode with encryption-based authentication, Certificate payloads SHOULD only appear in message 1. 6.3 Certificate requests that yield no results If a Certificate Request payload is received for a certificate or CRL that the responder does not have, the responder SHOULD silently ignore the request. The responder SHOULD NOT send a notify payload in response to a Certificate Request that could not be fulfilled. [[[Note: the previous version said "If a responding device is not offering a certificate that will chain to the certificate authority named in the Certificate Request payload, the Certificate payload offered in response to a Certificate Request payload MUST specify a certificate encoding of type NONE." However, there was general agreement to delete this and replace it with the text above.]]] 6.4 Responding with multiple certificates Some requests might cause the responder to send multiple certificates as a response. Note that such responses may exceed the size of a single UDP packet. However, if the requestor needs (or the responder believes that the requestor needs) multiple certificates, such a response is probably worthwhile. Under this profile, a request for certificate type 1 (PKCS #7) indicates that the requestor wants the responder to send a chain of certificates, while a request for certificate type 4 or 5 (X.509 certificates) indicates that the requestor only wants an end entity cert. If a Certificate Request payload specifies a certificate type of 1 (PKCS #7), and the responder has a certificate that is not directly signed by the root named in the certificate request but is singed by CA in a chain that ends in the named root, the responder SHOULD send back a single Certificate payload of type 1 that contains multiple certificates: one for the end entity certificate, and one for each intermediate certificate in the chain (not including the certificate for the root). If a Certificate Request payload specifies a certificate type of 4 or 5, and the responder has a certificate that is not directly signed by the root named in the certificate request but is singed by CA in a chain that ends in the named root, the responder SHOULD send back the single end entity certificate and SHOULD NOT send back intermediate certificate in the chain. If a Certificate Request payload specifies a certificate type of 7 (CRL), and in the same message there is a Certificate Request payload that specifies a certificate type of 1 (PKCS #7), the responder MAY include the CRL in the PKCS #7 it returns. 6.5 Requests without certificate authority fields The meaning of Certificate Request payloads that do not include certificate authority fields is not well specified in [RFC-2408]. For this profile, the following interpretations are given: - For certificate type 2, 4, and 5, this means "return a single certificate that might chain to a root that you somehow believe I trust" - For certificate type 1, this means "return one or more certificates that might chain to a root that you somehow believe I trust in a single payload" - For certificate type 7, if the same message included a Certificate Request payload of type 1, 2, 4, or 5, this means "please also return any CRLs you have for the certificates you are returning for the other request". - For certificate type 7, if the same message did not include a Certificate Request payload of type 1, 2, 4, or 5, this has no meaning. Such requests SHOULD NOT be made. 6.6 Indicating validation failure If certificate validation fails for any reason, the responder SHOULD return an unprotected notify payload. The notify message SHOULD include a notify message type of 17, 18, 19, 20, 21, 22, 23, 24, or 25, as described in section 3.14.1 of [RFC-2408]. 6.7 Matching ID payloads with certificate subjects An IKE implementation that conforms to this profile MUST NOT use an end entity certificate received from an IKE peer for purposes of completing the IKE authentication process unless there is a match in both content and format between the ID payload (IDii or IDir) offered by the peer in the IKE negotiation and at least one of the name forms carried in either the subject or subjectAltName fields in the certificate received. 7. Obtaining a Certificate for a Device This specification explicitly does not mandate the use of any particular certificate enrollment mechanism for IKE systems. The process of a device presenting a CA with a public key and identification, and then receiving a certificate from that CA for the combination of the public key and identification, is often called "enrollment" and "fulfillment". Unfortunately, the PKI world has had little agreement on enrollment protocols. The PKIX Working Group has standardized one mechanism, CMP [RFC-2510], and has recently asked that a second, incompatible mechanism, CMC [CMC], be standardized as well. In addition to CMP and CMC, there are at least two other non-IETF protocols that have been used by a number of IPsec vendors and CAs. The IPsec market has coalesced around one method of enrollment that is not fully defined anywhere other than this document. That method can be called "PKCS10 plus out of band" or "P10POUB", described below. All IKE systems that need to obtain a certificate for the public key MAY do P10POUB, and MAY do CMP and/or CMC in the near future. After receiving the PKCS #10 request, the CA creates a certificate and makes it available to the requestor either as a PKCS #7 response or as a bare certificate. 7.1 Enrollment requests with PKCS10 plus out of band information The steps an end-entity uses in P10POUB are: 1. Obtain a key pair. 2. Create a PKCS #10 [RFC-2314] object that includes the public key portion of the key pair. This object MUST NOT use any PKCS #10 extensions. 3. Determine the subjectAltName information desired for the certificate. 4. Transmit the PKCS #10 object, the desired subjectAltName, and any desired extensions to the CA. The last step may be performed in many ways. One common method is a web form where the Base64 [RFC-2045] transformation of the PKCS #10 object is pasted into a text-entry field and the subjectAltName and the fact that the desired certificate is for IPsec is specified with a variety of form controls. A second common method is email message that is manually processed by the CA. Note that the CA may ask the person enrolling for the SHA-1 hash of the PKCS10. This check helps prevent a man-in-the-middle from replacing the person's PKCS #10 request with a fake one and tricking the CA into issuing a certificate. Devices enrolling with P10POUB over email MUST include the subjectAltName in the message. The public key SHOULD be included in the message as the Base64 transformation of the PKCS #10 object. That Base64 object SHOULD be preceded with either the line: -----BEGIN CERTIFICATE----- or the line: -----BEGIN CERTIFICATE REQUEST----- and should be followed by the line: -----END CERTIFICATE----- or the line: -----END CERTIFICATE REQUEST----- This latter mechanism is somewhat similar to the certificate request mechanism from PEM [RFC-1421]. The CA's response to a successful creation of a certificate using P10POUB MAY be any of the following: - A PKCS #7 object holding the certificate - The Base64 encoding of a PKCS #7 object holding the certificate - The bare certificate - The Base64 encoding of the bare certificate [[[ OK, folks, that really doesn't help on interoperability. Should we pick one of those four as a SHOULD? ]]] 8. Acknowledgements This document was based on discussions with various IPsec implementers and PKI service providers, as well as other members of the IETF community. It also benefits from the spirit of interoperability exhibited by participants in the various IPsec bakeoff events. 9. Security Considerations All security considerations from the PKIX certificate profile and the PKIX roadmap are relevant here. Identifiers in certificates such as IP addresses or FQDN's should be checked for consistency with other information about the security associations being formed. IKE Main Mode attempts to preserve identity protection by only sending ID payloads in messages 5 and 6, which are encrypted. Sending certificates in unencrypted IKE Main Mode messages (1 through 4) will reveal the identity of the sender. Note that sending certificates in Main Mode for encryption-based authentication by its very nature will expose the identity of the sender. 10. References [CMC] Myers, M., et. al., "Certificate Management Messages over CMS", draft-ietf-pkix-cmc-xx.txt. (Awaiting the RFC Editor) [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", February 1993. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC-2045] Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996. [RFC-2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", March 1998. [RFC-2408] Maughan, D., et. al., "Internet Security Association and Key Management Protocol (ISAKMP)", November, 1998. [RFC-2409] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", November 1998. [RFC-2459] Housley, R., et. al., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", January 1999. [RFC-2510] Adams, C. and Farrell, S., "Internet X.509 Public Key Infrastructure Certificate Management Protocols", March 1999. [ROADMAP] Arsenault, A., and Turner, S., "PKIX Roadmap", draft-ietf-pkix-roadmap-xx.txt. A. Change History Some of the requirements from this draft come from other related drafts in the IPsec WG. Many people have contributed to those drafts and this one. The differences between the -04 and -05 drafts were: 1. Added second paragraph to make it clear that implementors need to follow other documents as well. 2. Rearranged a bit to put validation before revocation, and changed the title of the section. 3.1 Changed this significantly because no one was requiring its use for interoperability. Relaxed all requirements (and even eliminated some). 3.2 Added open question at the end. 4. Changed "time" to "date" to match the PKIX usage. 5. Clarified what the signatures were for, added the SHA1 part, and added OIDs. Removed "or equivalent" for the key sizes, and added note about longer lengths. 6. Changed this whole section based on comments from the list. Split the information out into separate sub-parts. 7. Moved Appendix A to section 7. 7. (A.) Added "Note that P10POUB using PKCS7 responses is one mode of CMC." Described the reply from the CA being either a PKCS7 or a bare cert based on the results from the San Diego bakeoff. Removed the last paragraph about CAs MUST NOT issue certs with different subject or altNames. 7.1 (A.1) Changed step 4. Added the response stuff and the open question at the end of the section. B. Authors' Addresses Rodney Thayer rodney@tillerman.to Charles A. Kunzinger IBM kunzinge@us.ibm.com Paul Hoffman VPN Consortium paul.hoffman@vpnc.org