IPSEC Working Group INTERNET-DRAFT NEC Shigeyoshi Shima Expires in six months from July,31 1998 ISAKMP Certificate Key Exchange Type Specification Status of This Document This document is an Internet-Draft. 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 6 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), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document defines a new key exchange type of ISAKMP that reduce the number of transmission and encrypt message contents from first transmission. The Certificate Key Exchange is effective since it does not use Diffie-Hellman key exchange algorithm but public key cryptography. The Certificate Key Exchange use certificates as authentication information. Please send comments on this document to the ipsec@tis.com. S.Shima [Page 1] INTERNET-DRAFT July 31, 1998 Table of Contents Status of This Document ...................................1 Abstract ..................................................1 Table of Contents .........................................2 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 .......................4 3.3. Notation .........................................5 3.4. Certificate Key Exchange Type ....................5 4. Security Considerations ...............................7 Reference .............................................8 Acknowledgments .......................................8 Editor's Address ......................................8 1. Introduction The IPSEC Working Group of the IETF has defined some key management protocols (ISAKMP, IKE, SKIP etc), which are used for the establishment of Security Association of AH (Authentication Header) and ESP (Encapsulation Security Payload Header). This document particularly describes about ISAKMP. ISAKMP is based on Diffie-Hellman key exchange algorithms as a key establishment method between hosts. Never the less, ISAKMP does not guarantee correct correspondence between the host and the public key used for Diffie-Hellman key exchange algorithms. If a host continues to use an unguaranteed public key with Diffie-Hellman key exchange algorithms, a cracker can wiretap message contents between hosts after gaining unauthorized access to the host and obtain the public key of the host. The public key cryptography has a similar problem. This problem is generally settled through the third party with CA. CA issue certificates to hosts. Certificates are guaranteed to correspond the host and the public key with certificates if the host verifies them. Only the host, which corresponds to the public key, can access message contents if the message is encrypted with the public key. This document defines the Certificate Key Exchange type as a new S.Shima [Page 2] Internet Draft July 31, 1998 ISAKMP Key Exchange type [ISAKMP], 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 host can apply to both key exchange and encryption of a message at the first transmission, before the host shares secret information with a pair of host. 2. Definitions 2.1. Certificate For the contents of certificates that IPsec use, 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 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. S.Shima [Page 3] Internet Draft July 31, 1998 3 Certificate Key Exchange 3.1 Overview Key Exchange Types of ISAKMP can't encrypt a message from first transmission. The AGGRESSIVE Exchange Type of ISAKMP can encrypt a message from first transmission, if the host send a message in advance to share secret information with a pair of host. In the Certificate Key Exchange, the host can create an encrypted message with the public key using public key cryptography. The encrypted message can only be decrypted by a host which has the secret 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 make an encrypted message with the public key of the responder in the responder's certificate. The Certificate Key Exchange can reduce the number of transmissions in the key exchange, since a common key (secret) and identification related information can be set to payloads from first transmission. For example, in comparison with the BASE Key Exchange and the IDENTITY PROTECTION Key Exchange the number of transmissions in the Certificate Key Exchange is fewer, and in comparison with the AGGRESSIVE Key Exchange, the number of transmissions is the same. 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. The details of the Certificate Key Exchange will be explained in 3.4. 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 Key Exchange payload is set to ISAKMP packet of the first message before the all payloads and the common key of the Key Exchange payload is used for encryption and decryption of payloads. Therefore 4 as the Key Exchange payload(KE) MUST be set to payload type value of the ISAKMP Header MUST be set to 4 as the Key Exchange payload (KE). S.Shima [Page 4] Internet Draft July 31, 1998 ____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 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. KE is the key exchange payload. IDx is the identity payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder, respectively, 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. '( )*' signifies ISAKMP header and payloads in ( ) encryption with Common Key Cryptography. '**' signifies payload encryption with Public Key Cryptography. This encryption is generally used for KE. => 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, Key Exchange, 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. S.Shima [Page 5] INTERNET DRAFT July 31, 1998 CERTIFICATE EXCHANGE _#______Initiator____Direction_____Responder______________________NOTE____________________ (1) HDR; KE**; (SA => Begin ISAKMP-SA or Proxy negotiation NONCE; IDii; CERT)* and Key Exchange (2) <= HDR; KE**; (SA NONCE; IDir; AUTH)* Initiator Identity Verified by Responder Key Generated SA agreed upon (3) (HDR; AUTH)* Responder Identity Verified by Initiator SA established In the first message (1), It assume that the initiator already finished verifying the responder's certificate. The initiator generates a Proposal payload considered adequate to protect traffic in the preceding sessions. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). The initiator generates the common key to encrypt other payloads, such as SA, NONCE, IDx, and CERT, sets the Key Exchange payload to it, and encrypts the payload with the public key in the responder's certificate. Random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Additionally, the initiator transmits identification information. The initiator can obtain the public key, public key cryptography attribute, and common key cryptography attribute with the responder's certificate. The initiator encrypts Security Association, Proposal, Transform, Nonce, Identification, and Certificate payloads with the generated common key. 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 Key Exchange payload with the secret key of the responder since the ISAKMP Header contains Key Exchange information. The responder decrypts other payloads with the common key that is set to Key Exchange Payload. In the second message (2), the responder indicates the protection suite that was accepted with the Security Association, Proposal, and Transform payloads. The initiator generates a common key to encrypt other payloads, such as SA, NONCE, IDx, and CERT, sets the Key Exchange payload to it, and encrypts the payload with the public key in the responder's certificate. Random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the responder transmits S.Shima [Page 6] INTERNET DRAFT July 31, 1998 identification information. This information is transmitted under the protection of the agreed upon authentication function. The initiator encrypts Security Association, Proposal, Transform, Nonce, and Identification payloads as well as authentication information with the generated common key. Local security policy dictates the action of the responder if no proposed protection suite is 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 the Certificate key Exchange data and decrypts the Key Exchange payload with the secret key of the initiator since the ISAKMP Header has the Key Exchange information. The initiator decrypts other payloads with the common key that is set to the Key Exchange payload. In the third message (3), the initiator transmits the results of the agreed upon authentication function. This information is transmitted under the protection of the common shared secret. 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 ISAKMP draft on security and discusses a new type of ISAKMP Key Exchange. If the Certificate Key Exchange applies to the following Internet-Drafts, it improves security and efficiency. 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. 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. S.Shima [Page 7] INTERNET DRAFT July 31,1998 Reference [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol", draft-ietf-ipsec-isakmp-09 [IPSEC-CERT] Rodney Thayer, "PKI Processing Requirements for IP security", draft-thayer-ipsec-pki-00.txt [X.509] ITU-T Recommendation X.509 (1197 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework [DNSSEC-CERT] Donald E. Easrlake 3rd olafur Gudmudsson, "Storing Certificares in the Domain Name System", draft-ietf-dnssec-cert-02.txt [RFC2230] R. Atkinson, "Key Exchange Delegation Record for the DNS", rfc2230.txt 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. Editor's Address Shigeyoshi Shima shima@ccs.mt.nec.co.jp NEC Corporation +81 (03) 5476-1107 The IPSec working group can be contacted via the IPSec working group's mailing list (ipsec@tis.com) or through its chairs: Robert Moskowitz rgm@icsa.net International Computer Security Association Theodore Y. Ts'o tytso@mit.edu Massachusetts Institute of Technology S.Shima [Page 8]