Internet Draft Rodney Thayer, SSH draft-ietf-ipsec-pki-req-04.txt Charles Kunzinger, IBM December 14, 1999 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 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)". (It is noted that the fact that the two documents differ does not give great confidence to the IPsec community or other users of the PKIX protocols.) 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 Revocation IKE systems conforming to this profile MUST check the revocation status of any certificate on which they rely, using the algorithm 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. 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). 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") MUST be present and MUST contain only the object identifier iKEIntermediate (iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or 1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD NOT accept end-entity certificates that do not follow this rule. Note that this requirement 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 MUST NOT be used and are deprecated in this profile. 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. 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 time in conjunction with all relevant SA lifetimes (both IKE SA and IPsec SA's) at the time 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 signatures and RSA signatures. 1024-bit keys or the equivalent MUST be supported for each signature algorithm 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 When the IKE messages are authenticated using either RSA Signatures or DSS Signatures, the following rules apply. These rules specify exactly where Certificate and Certificate Request payloads may and may not appear in messages. Note that [RFC-2408] requires that Certificate and Certificate Request payloads MUST be accepted in any ISAKMP message; that doesn't mean that they must be processed if they appear. This section describes the messages in which these payloads MUST appear in order to be processed by the receiving IKE system. - In Main Mode, an IKE initiator MUST include Certificate Request payloads only in Message 5 if they are to be included anywhere in the IKE negotiation. An IKE responder MUST include them only in Message 4 if they are to be included anywhere in the IKE negotiation. Certificate Request payloads appearing in other messages MAY be ignored by the party receiving them. - In Aggressive Mode, an IKE Initiator MUST include Certificate Request payloads only in Message 1 if they are to be included anywhere in the IKE negotiation. An IKE Responder MUST include them in Message 2 if they are to be included anywhere in the IKE negotiation. - In Main Mode, an IKE device that wishes to deliver its own certificates to its peer without having been previously received a Certificate Request payload from the peer MUST deliver the Certificate payloads only in Message 5 if it is the IKE initiator, or only in Message 6 if it is the IKE responder. Certificate payloads in other messages MAY be ignored by the party receiving them. - In Aggressive Mode, an IKE device that wishes to deliver its own certificates to its peer without having been previously received a Certificate Request payload from the peer MUST deliver the Certificate payloads only in Message 3 if it is the IKE initiator, or only in Message 2 if it is the IKE responder. 6.2 Encryption-based authentication In Main Mode with encryption-based authentication, Certificate Request payloads, if they are to be included anywhere, MUST appear only in messages 1 and 2. Certificate Request payloads MUST NOT appear in Aggressive Mode encryption-based authentication. In Main Mode with encryption-based authentication, Certificate payloads MUST only appear in messages 1, 2, and 3; 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 MUST only appear in message 1. 6.3 Content of Certificate payloads If a responding device is offering a certificate that will chain to the certificate authority named in the Certificate Request payload, and there are intermediate certificates in the chain, the responding device SHOULD include the intermediate certificates in Certificate payloads in the response. [[[Editorial note: we might want to downgrade this to a MAY. Including a bunch of certs in a UDP transmission greatly increases the chances of a blown exchange due to dropped packets, particularly because a typical cert is 5-10 packets long. Of course, not including intermediate certs means that the sender assumes the recipient has them all, which can't be determined easily.]]] 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. 6.4 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. 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. 8. 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. 9. References [CMC] Myers, M., et. al., "Certificate Management Messages over CMS", draft-ietf-pkix-cmc-xx.txt. (Has finished WG Last Call and is currently awaiting IETF Last Call.) [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC-1421, 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. 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. Regardless of the protocol used, a CA who gets an IKE system's enrollment request that includes the subject and subjectAltName desired for the device MUST include exactly the same subject and subjectAltName in the certificate. If the CA does not want to issue a certificate with the same subject and subjectAltName that was requested, the CA MUST NOT issue a certificate with a different name and subjectAltName. A.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 the fact that this is an IPsec certificate 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. 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]. B. 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. B.1 Differences between the -03 and -04 drafts 1. Spelled out the definition of a root CA from the PKIX roadmap. 2. Clarified the wording on number of intermediate CAs. Clarified that it's both IKE and IPsec SAs that need to be taken down if certs are revoked. 3.2. Removed the first paragraph, which disagreed with PKIX. Also removed the prohibition on Ipv6 and subnetwork address, which also disagreed with PKIX. Also removed the last paragraph, which disagreed with PKIX. 6. Added this entire section, and therefore renumbered the current 6-9 to 7-10. 8. Added new third paragraph to the security considerations. C. Authors' Addresses Rodney Thayer Rodney@tillerman.to Charles A. Kunzinger IBM kunzinge@us.ibm.com Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 paul.hoffman@vpnc.org