Network Working Group S. Shima Internet Draft NEC M. Lechner IP Devices, Inc. February 1999 ISAKMP Certificate Key Exchange Type Specification 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. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document defines a new key exchange type for ISAKMP that provides full identity protection for an aggressive mode exhange. The Certificate Key Exchange accomplishes key exchange with public key cryptography rather than with the Diffie-Hellman key exchange algorithm. The Certificate Key Exchange uses certificates as authentication information. Please e-mail comments on this document to ipsec@tis.com. Shima & Lechner Expires August 1999 [Page 1] Internet Draft ISAKMP Certificate Key Exchange February 1999 Table of Contents 1. Introduction ..........................................2 2. Definitions ...........................................3 2.1. Certificate ......................................3 2.2. Certification Authority ..........................3 3. Certificate Key Exchange ..............................4 3.1. Overview .........................................4 3.2. ISAKMP Exchange Type Field .......................5 3.3. Notation .........................................5 3.4. Certificate Key Exchange Type ....................6 4. Security Considerations ...............................8 References ............................................9 Acknowledgments .......................................9 Authors' Address ......................................10 1. Introduction The IPSEC Working Group of the IETF has defined key management protocols (ISAKMP, IKE, SKIP etc), which are used for the establishment of Security Associations for AH (Authentication Header) and ESP (Encapsulation Security Payload Header). This document deals particularly with ISAKMP. ISAKMP uses the Diffie-Hellman key exchange algorithm as a key establishment method between hosts. While Diffie-Hellman provides a secure key exchange, it does not provide proof of identities. Proof of identity is accomplished by use of a shared secret between the parties, the use of public key cryptography, or a digital signature. Distribution of shared secrets is problematic, does not scale well, and is only suitable for relative small private networks. Public key is the only method that scales well for large networks. Public keys don't need to be kept secret, but they must be authenticated. There must be some way to be certain that the public key does indeed belong to the party being contacted. This process must be automated for the scaling advantage of public key to be realized. The way to accomplish this is by the use of Certificate Authorities (CA). A Certificate Authority (CA) uses the concept of a trusted third party to provide authentication of public keys. Parties who wish to communicate securely provide their public keys to a trusted CA. The CA verifies ownership of these keys and digitally signs them with its key. The resulting Certificate can then be distributed by any method. Parties to a secure communication can verify the public key Shima & Lechner Expires August 1999 [Page 2] Internet Draft ISAKMP Certificate Key Exchange February 1999 of their peers by checking the digital signatures of the keys of these peers against the public key of the CA. As long as the CA is trustworthy and diligent, secure communication is possible between all parties utilizing that CA. This document defines the Certificate Key Exchange type as a new ISAKMP Key Exchange type [RFC2408], which uses a public key certificate. The Certificate Key Exchange does not use Diffie- Hellman key exchange algorithms but public key cryptography, which has an encryption and a signature mechanism. Therefore, the two participating IKEs can accomplish both key exchange and authentication with their first transmissions and still avoid disclosing secret information. 2. Definitions 2.1 Certificate For the contents of certificates that IPsec uses, refer to [IPSEC- CERT]. [IPSEC-CERT] defines processes for handling IPsec certificates, including fulfillment, retrieval, validation, and management, to realize the IPsec certificate. o IPsec-aware devices have requirements to retrieve and to share certificates and CRLs. o There are two means of certificate exchange for IPsec devices: 1. Two IPsec devices exchange certificate information through a combination of out-of-band operations and IKE payload messages. 2. IPsec devices may use PKIX protocols or other mechanisms such as LDAP or HTTP to retrieve PKI information. o This certificate is used to identify an IPsec entity with the IKE protocol and is based on the X.509 format [X.509], which contains the public key, cryptography algorithm information, and naming information. 2.2. Certification Authority (CA) CAs generally have mechanisms for generation, verification, revocation, management and distribution of certification as described in section 2.1. It is assumed that there exists multiple CAs on the Internet, with each belonging to an organization and an area and some of them forming a CA hierarchy. There are two types of CA; CA to issue Shima & Lechner Expires August 1999 [Page 3] Internet Draft ISAKMP Certificate Key Exchange February 1999 certificates to hosts and CA to issue certificates to other CAs. Since a host obtains a CA certificate by off-line or through installation of software before the host communicates on the network, the host relies on the CA certificate. 3. Certificate Key Exchange 3.1 Overview The Key Exchange Types of ISAKMP cannot encrypt the first message of an ISAKMP SA negotiation. The AGGRESSIVE Exchange Type of ISAKMP can encrypt a message from first transmission, if the host sends a message in advance to share secret information with its peer. In the Certificate Key Exchange, the IKE can create an encrypted message with the public key of it's peer IKE. The encrypted message can only be decrypted by the receiving IKE, which has the secret part of the public key. Since correspondence of the host and the public key of the responder is certified by a CA, the initiator verifies the responder's certificate with the CA certificate, then the initiator makes an encrypted message with the public key of the responder in the responder's certificate. The Certificate Key Exchange is an aggressive mode exchange that provides identity protection. This means that only three messages are needed to establish the IKE's SA, while the identities of the negotiating parties is protected by the public keys of the IKE's. In comparison the identity protect exchange requires six messages to complete a key exchange. Keying material needed to construct the ISAKMP SA is also passed beteen the participating IKEs under the protection of public key cryptography. The keys used initially to encrypt the initial messages are also used to encrypt all the following IKE communication. This eliminates the need to pass KE payloads and to perform an expensive Diffie-Hellman computation to derive a common key. This is similar to the technique described in [DH-LESS]. In the Certificate Key Exchange it is possible to detect masquerade faster than with other types. In the case of the BASE Key Exchange, masquerade is detected after finishing the key exchange with Diffie- Hellman key exchange algorithms, while in the case of the Certificate Key Exchange they are detected at start point of the key exchange. Since the expense of the Diffie-Hellman computation is avoided, the effects of Denial of Serice attacks are reduced. The details of the Certificate Key Exchange will be explained in 3.4. Shima & Lechner Expires August 1999 [Page 4] Internet Draft ISAKMP Certificate Key Exchange February 1999 3.2 ISAKMP Exchange Field This section defines a new type of Exchange field for a ISAKMP header; the Certificate Key Exchange, which is assigned the value six (6). In the Certificate Key Exchange, the order of payloads MUST be as follow: An optional SA payload MAY be present and MUST be first. An optional HASH payload MAY be present and MUST follow the SA payload, and MUST proceed any other payloads. Inclusion of the HASH payload requires the inclusion of the SA payload. A Nonce payload MUST immediately follow any SA or HASH payloads. If there are no SA or HASH payloads, the Nonce payload MUST be the first payload. All other payloads MUST follow the Nonce payload and are encrypted with the common key derived from the Nonce payload. If an SA payload is present the ISAKMP header's Next Payload field MUST be set to four (4), indicating an SA payload. If no SA payload is present the ISAKMP header's Next Payload field MUST be set to ten (10), indicating a Nonce payload. ____Exchange_Type______Value___ NONE 0 Base 1 Identity Protection 2 Authentication Only 3 Aggressive 4 Informational 5 Certificate 6 (New) ISAKMP Future Use 7 - 31 DOI Specific Use 32 - 255 3.3 Notation The following notation from [RFC2409] is used throughout this draft. HDR is an ISAKMP header whose exchange type defines the payload orderings SA is an SA negotiation payload with one or more Proposal and Transform payloads. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one.

_b indicates the body of payload

-- the ISAKMP generic payload header is not included. IDx is the identity payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder, respectively, Shima & Lechner Expires August 1999 [Page 5] Internet Draft ISAKMP Certificate Key Exchange February 1999 or x can be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator), for the user initiator and responder, respectively. HASH is the hash payload. SIG is the signature payload. The data to sign is exchange-specific. AUTH is a generic authentication mechanism, such as HASH or SIG. NONCE is the nonce payload. CERT is the certificate payload. [x] indicates that payload x is optional. => signifies "initiator to responder" communication (requests). <= signifies "responder to initiator" communication (replies). 3.4 Certificate Key Exchange The Certificate Key Exchange is designed to allow the Security Association, Nonce, Identification, and Certificate payloads to be transmitted together. The following diagram shows messages with possible payloads sent in each message and notes regarding an example of Certificate Exchange. CERTIFICATE EXCHANGE # Initiator Direction Responder (1) HDR; [SA; [HASH;]] => PubKey_r; <[NONCE;] IDii [; CERT]>Ke_i (2) <= HDR; [PubKey_i;] <[NONCE;] IDir; AUTH>Ke_r (3) HDR; AUTH => In the first message (1), it is assumed that the initiator has obtained and verifyied the responder's public key certificate. The responder's public key certificate specifies the SA proposal(s) that it will accept to secure ISAKMP traffic. If more than proposal is present in the responder's certificate, the initiator must choose one Shima & Lechner Expires August 1999 [Page 6] Internet Draft ISAKMP Certificate Key Exchange February 1999 and indicate it's choice in an SA payload. The SA payload is omitted, if there is only one proposal specified in the responder's certificate. If there the responder has multiple certificates, a HASH payload must be included to indicate which certificate is being used by the initiator. The algorithm used for the HASH payload is specified in the SA payload. The initiator generates a Nonce from random information. The body of the Nonce (Ni_b) payload is encrypted with the responder's public key (Pubkey_r). The key (Ke_i) derived from the Nonce (Ni_b) is used to encrypt the remaining payloads in the message. The algorithm to determine this key is specified in [RFC2409] as: Ne_i = prf(Ni_b, CKY-I) Ke_i = prf(Ne_i, 0) If a longer key is needed, the key is extended thus: Ke_i = K1 | K2 | . . . Kn K1 = prf(Ne_i, 0) K2 = prf(Ne_i, K1) Kn = prf(Ne_i, Kn-1) A second NONCE MAY be included at the beginning of the Ke_i encrypted payload to guarantee livliness of the exchange and protect against replay attacks. The remaining payloads include the optional second NONCE, Identity IDii, and an option Certificate (CERT) payload. The initiator can obtain the public key, public key cryptography attribute, and common key cryptography attribute with the responder's certificate. The initiator encrypts Nonce, Identification, and Certificate payloads with the generated key Ke_i. Since the ISAKMP Header is not encrypted with the public key, hosts prevented from wasting computation capacity by Denial of Service Attacks. The responder confirms that the header and payloads are data of the Certificate Key Exchange and decrypts the Ni_b payload with the secret key of the responder. The responder uses the Ni_b to compute Ke_i according to the method shown above. The resulting Ke_i is used the decrypt the payloads that follow the Ni_b payload. If the initiator included an SA payload, it specifies the properties used to encrypt the payload protected by Ke_i and the algorithm used to compute HASH. The SA also specifies the algorithms to be used for all further encryption and authentication. If the initiator included a HASH payload, it identifies which of the repsonder's certificates was used to encrypt Ni_b. In the second message (2), the responder verifies the initiator's public key certificate. If the certificate was not included in the initiator's message, the responder MUST obtain that certificate by Shima & Lechner Expires August 1999 [Page 7] Internet Draft ISAKMP Certificate Key Exchange February 1999 other means. After verifying the initiator's public key certificate, the responder computes a random value for Nr_b. The value of Nr_b is encrypted using the public key of the initiator (Pubkey_i). Similar to the process for Ke_i, the encryption key Ke_i is computed and used to encrypt the remaining payloads. A second NONCE MAY be included as the first payload protected by key Ke_r to provide authentication and to provide shared proof of participation in the exchange. Additionally, the responder transmits identification information. This information is transmitted under the protection of the the key Ke_r. The initiator encrypts Nonce, and Identification payloads as well as authentication information with the key Ke_r. Local security policy dictates the action of the responder if proposed protection suite is not accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange. The initiator confirms that the header and payloads are data of the Certificate key Exchange and decrypts the Nr_b payload with the secret key of the initiator. The initiator uses the Nr_b to compute Ke_r according to the method shown above. The resulting Ke_r is used the decrypt the payloads that follow the Nr_b payload. The identity payload IDir and the AUTH payload are used to validate the reponder's message. In the third message (3), the initiator acknowleges acceptance of the SA, encryptions keys, and identity of the responder. This final message MAY be encrypted by the initiator's key Ke_i. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange. 4. Security Considerations This entire draft is based on the work of [RFC2408] and [RFC2409]. It defines a new key exchange type for ISAKMP and draws upon the previous work to retain good security properties. However, since Diffie-Hellman key is not used in this exchange, Perfect Forward Secrecy (PFS) of the ISAKMP SA is not possible. This Certificate Key Exchange relies on the strength of public key cryptography to protect the session key used by the ISAKMP SA. Weaknesses in the public key algorithms or poor key choices negatively impact the security of this key exchange. 1. Storing Certificates in the Domain Name System [DNSSEC-CERT] This document describes a mechanism whereby a CERT resource record (RR) is defined so that certificate and certificate revocation lists can be conveniently stored in the Domain Name System(DNS). The secure DNS distributes IPsec CA certificates to the host. The host can securely and efficiently obtain IPsec certificates. Shima & Lechner Expires August 1999 [Page 8] Internet Draft ISAKMP Certificate Key Exchange February 1999 2. Key Exchange Delegation Record for the DNS [RFC2230] This document describes a mechanism whereby authorization for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. It can be used with several security services. If the host wants to find the trusted CA, secure DNS can record access point of the correct CA on the network. References [RFC2408] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", Standards Track, RFC 2408, November 1998. [IPSEC-CERT] Rodney Thayer, "PKI Requirements for IP Security", Internet Draft, draft-ietf-ipsec-pki-req-01.txt, September 1998. [X.509] ITU-T Recommendation X.509 (1197 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework [DH-LESS] R. Canetti, P. Cheng, H. Krawczyk, "A HD-less Encryption Mode for IKE", Internet Draft, draft-ieft-ipsec-dhless-enc-mode-00.txt, July 1998. [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", Standards Track, RFC 2409, November 1998. [DNSSEC-CERT] Donald E. Eastlake 3rd, Olafur Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", Internet Draft, draft-ietf-dnssec-certs-04.txt, December 1998. [RFC2230] R. Atkinson, "Key Exchange Delegation Record for the DNS", Informational, RFC 2230, November 1997. Acknowledgments This document is the result of close consultation with Mine Sakurai, Takao Miyabe, and Shiuji Ishii. We would also like to thank the members of NEC Internet Technology Laboratories. Shima & Lechner Expires August 1999 [Page 9] Internet Draft ISAKMP Certificate Key Exchange February 1999 Authors' Addresses Shigeyoshi Shima NEC Corporation Phone: +81 (03) 5476-1107 eMail: shima@ccs.mt.nec.co.jp Mikel Lechner 5339 Prospect Road, Suite 250 San Jose, CA 95129 Phone: 1-408-433-1281 Fax: 1-408-433-1226 eMail: mikel@ipdevices.com Shima & Lechner Expires August 1999 [Page 10]