Internet Draft Paul Hoffman draft-hoffman-pki4ipsec-profile-00.txt VPN Consortium December 18, 2003 Expires in six months Intended status: Informational Profile for Certificate Use in IKE version 1 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 use of certificates for authenticating the creation of IPsec security associations has long been fraught with difficulty. The specifications in IKE version 1 are sometimes ambiguous about important issues, and developers of IPsec systems are often unprepared to deal with the complexities of PKIX certificates and certificate handling. This document is a profile of certificate use in IPsec whose primary goal is to greatly increase interoperability while maintaining high security. 1. Introduction The most common method for setting up IPsec security associations is to use the Internet Key Exchange versions 1 [IKEv1]. IKE specifies many ways to authenticate the two parties in a security association, some of which use digital certificates. This document profiles one such use of digital certificates. The primary purpose of this profile is to greatly increase interoperability among developers of IPsec systems. This profile greatly narrows the number of choices that a developer has for certificate format and how public key information is exchanged in IKE. At the same time, this profile uses options that are considered to be strong enough for typical IPsec usage. In order for two parties to use this profile, both parties MUST have at least one certificate authority whom they both fully trust to issue certificates that associate one or more identities with public keys. The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 2. Certificate contents All certificates used in this profile MUST be PKIX [PKIX] certificates. All certificates send and received by either party in the IKE negotiation MUST follow the content rules described in this section. 2.1 Identities in the Name and SubjectAltName fields for end entities The first thing to acknowledge when dealing with PKIX certificates is that the PKIX rules for naming the parties is a mess. The PKIX rules evolved from the naming rules for X.500 and LDAP directories, and were not originally designed for Internet identities. The Subject field in all end entity certificates SHOULD be null. The identity in the Subject field of end entity certificates MUST NOT be use by either party for identification. The SubjectAltName field MUST have at least one identity in it. At least one identity in the SubjectAltName field of a certificate MUST be either an iPAddress (an IPv4 IP address), an rfc822Name (an email address), or a dNSName (a fully-qualified domain name). An end entity certificate MAY have multiple identities and types of identities within the subjectAltName field. For example, it is valid to have a certificate that has DNS names, it is valid to have a certificate that has a DNS name and an email address, and it is valid to have a certificate that as two IP addresses and a DNS name. IKE implementations MUST be able to find all the identities in end entity certificate that have multiple identities and types of identities within the subjectAltName field. 2.2 KeyUsage and ExtendedKeyUsage fields for end entities There is no threat model in IKE that requires a system to demand particular values in the KeyUsage and ExtendedKeyUsage fields of an end entity certificate. Certificates SHOULD have the digitalSignature bit in the KeyUsage field turned on, but authenticating parties SHOULD NOT reject a certificate if that bit is not asserted. Both parties SHOULD ignore the values in the KeyUsage and ExtendedKeyUsage fields. 2.3 Cryptographic algorithms All certificates (trust anchors, intermediate CAs, and end entities) MUST use sha-1WithRSAEncryption signature algorithm with RSA keys. All RSA keys SHOULD be 1024 bits or longer. 2.4 Critical extensions Certificates used in this profile SHOULD NOT have any critical extensions except those that are listed in [PKIX] as being mandatory to be marked as critical. 2.5 Matching identities with systems Identities in certificates are often misunderstood. In most cases, the issuer of a certificate believed that, at the time the certificate was issued, that the identity in the certificate is associated with the entity that controlled the private key that is paired with the public key in the certificate. For example, a certificate that has an identity of an IP address often indicates that, at the time the certificate was issued, the certificate authority believes that the IP address is that of the system that managed the private key that is paired with the public key in the certificate. Of course, things change over time. The IP address of a device might change due to any number of reasons. Domain name hierarchies change and email addresses change. A system that controls a private key is still able to use it to authenticate itself even if the identifier associated with the public key has changed. When matching the identity in an end entity certificate with that in a policy database, there is no inherent need to match the identity with the topological location of the peer. That is, an IP address in a certificate does not have to match the IP address of the system that is authenticating using that certificate. Similarly, a DNS address in a certificate does not have to resolve to the IP address of the system that is authenticating using that certificate. (Of course, it is impossible for the email address in a certificate to match the email address of the system authentication using that certificate because IKE systems don't have any particular email addresses.) 3. IKE processing This section describes how to process certificates in IKEv1. Many of the restrictions in this profile go counter to what some IKEv1 implementations do today. This is not to say that what those current implementations do today is wrong or insecure; however, the restrictions listed here are believed to achieve higher interoperability without sacrificing security. This profile only covers Main Mode of IKEv1. Both parties MUST use authentication with RSA signatures (authentication method 3 in [IKEv1]). Both parties MUST already have the full chain of certificates to all mutually-trusted trust anchors. Neither party can assume that the other party will send anything other than its end entity certificate. 3.1 Use of the CERTREQ and CERT payloads Either party MAY send a CERTREQ payload. Note that this is strictly optional; neither party has to send a CERTREQ payload. Systems MUST NOT fail if the other party did not send a CERTREQ payload. If sent, the CERTREQ payload MAY appear in messages 1 through 5. If a CERTREQ payload appears, it MUST have encoding type 5 (X.509 Certificate - Signature). The CERTREQ payload MUST NOT be used for requesting certificate revocation lists (CRLs). The certificate authority field in the CERTREQ payload MAY be empty If a party receives a CERTREQ payload with an empty name, the receiving party SHOULD send all of its end entity certificates. That is, an empty certificate authority name in a CERTREQ payload indicates that the party wants any end entity certificates that the other party can use. CERT payloads MUST only contain end entity certificates. They MUST not contain trust anchors or intermediate certificates. Each party MUST send at least one CERT payload during IKE. Parties SHOULD send their end entity certificates in message 5 or 6, but each party MAY send one or more CERT payloads in any message. If a CERT payload appears, it MUST have encoding type 5 (X.509 Certificate - Signature). Receiving parties MUST be able to handle multiple incoming certificates, even if they are different payloads. 3.2 Use of the ID payload IKEv1 requires that messages 5 and 6 contain ID payloads; these payloads MUST be present. However, the interpretation of their contents is up to the receiving party. The receiver MAY ignore the contents ID payload. The sender MUST NOT assume that the receiver will take any particular action based on the contents of the ID payload that was sent. The receiver MUST NOT fail just because the ID payload does not match one of the identities in the sender's certificate. The receiver SHOULD NOT fail if the ID payload does not match an entry in the receiver's policy database; instead, the receiver SHOULD try to match any identity in the sender's certificate(s) to the policy database. If any certificate sent has more than one identity, the ID payload SHOULD match one of the identities. That is the "preferred identity" 3.3 Certificate expiration and revocation Some IPsec environments purposely use short-lived certificates. Systems adhering to this profile MUST check certificate expiration times when authenticating using IKEv1. If a certificate has expired, the system MUST NOT create an SA. If the certificate would expire during the SA being created, the SA MUST expire when the certificate expires. In order to meet these requirements, conformant IPsec systems MUST have a reasonably accurate clock. Systems following this profile MUST have access to revocation information (usually CRLs) for all certificates they use. In the real world, very few systems today have such access, and this profile does not propose how to improve that situation. 3.4 Path validation Most IPsec environments do fine without certificate paths. In typical corporate use, a single certificate authority signs end entity certificates, so there is no certificate chain. If the mutually-trusted anchor has intermediate certificates between it and the end entity certificates used by the IPsec systems, the systems MUST be able to do full PKIX path validation. If they cannot validate the path between the end entity and the trust anchor following the (admittedly intricate) rules in PKIX, then they MUST NOT authenticate with those end entity certificates. 3.5 Critical extensions IPsec systems following this specification MUST process critical extensions as described in PKIX. Systems MUST NOT ignore the criticality of any extension in any certificate that they use for authentication. 4. Security considerations This profile deals extensively with security. Using certificates for authentication in IPsec is generally considered to be more secure than using preshared secrets because typical preshared secret use often devolves to passwords instead of preshared secrets. The security of any system that uses certificates for authentication relies on both the strength of the certificate's key and on how well the private key associated with the public key is protected. 5. References 5.1 Normative references [IKEv1] Harkins, D., et. al., "The Internet Key Exchange (IKE)", RFC 2409, November 1997. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [PKIX] Housley, R., et. al., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. 6. Author's address Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA paul.hoffman@vpnc.org