IPSEC Working Group R. Canetti, P. Cheng, H. Krawczyk INTERNET-DRAFT IBM Research and the Technion draft-ietf-ipsec-dhless-enc-mode-00.txt July 1998 Expire in six months A DH-less encryption mode for IKE Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract The IKE document [HC98] describes a key exchange protocol for obtaining authenticated and secret keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. All the current modes for carrying out Phase 1 of the key exchange in [HC98] incorporate a Diffie- Hellman exponentiation. While the DH exponentiation enhances the security of the exchange (and in particular provides perfect forward secrecy (PFS)), this enhanced secrecy comes at a computational cost. In cases where PFS is not a requirement, most notably in authentication only scenarios, less expensive solutions are possible. This draft describes a ``DH-less'' version of the (revised) public- key encryption mode of [HC98]. This saves the DH exponentiation, which may be significant (especially on low-end machines and busy servers). The proposed mode is VERY similar to the existing modes and requires only minimal modifications. In particular, it is straightforward to implement as an addition to the existing modes. Remark: This document is NOT self-contained. It uses notation and definitions of [HC98]. It is best read in conjunction with [HC98]. Canetti, Cheng, Krawczyk [Page i] INTERNET DRAFT May 1998 2. Introduction The IKE protocol [HC98] defines four alternative modes of carrying out Phase 1 of the key exchange. Three of these modes are usable by parties that do not already share a secret key. These are the Signature Mode and the (original and revised) Public Key Encryption Modes. All three public-key based modes involve a Diffie-Hellman exponentiation. While this is essential in the Signature Mode, the Public Key Encryption Mode can be easily modified to do without the DH exponentiation (following [SKEME]). The main advantage of the DH exponentiation is perfect forward secrecy (PFS): an attacker that breaks the public key encryption at a later time (either by cryptanalysis or by obtaining the private key) still cannot compute g^xy from g^x and g^y, thus it cannot decipher messages encrypted with a key that was computed using g^xy. While PFS is very important for some applications, it is not a requirement for others. Two important examples are security associations that are used only for authentication, and associations that need only "ephemeral secrecy" (for example, timely stock quotes). See [SKEME] for further discussion. This draft describes a "DH-less" variant of the (revised) Public Key Encryption Mode. This variant does NOT provide PFS, and the security of the key is based solely on the security of the public key encryption algorithm in use. It avoids the DH exponentiations. This may be a considerable saving, especially for low-end machines or busy servers that authenticate all outgoing data. We note that in order to learn an exchanged key the attacker needs to find the secret private keys of BOTH Initiator AND Responder. The modifications from the current (revised) public key encryption mode are minimal. Simply delete the DH payloads (Ke_i and Ke_r) and in the ensuing computations set g^x = g^y = g^xy = 0 (one octet). The rest of this document is organized as follows. In Section 3 the DHless Encryption Mode is described. The description is written in a way so that Section 3 can be read as an additional subsection in Section 5 of [HC98]. Appendix A holds the authentication mode value of the new mode (see ISAKMP [MSST98] and Appendix A of [HC98]). Canetti, Cheng, Krawczyk [Page 1] INTERNET DRAFT May 1998 3. Phase 1 Authenticated With a DH-less Mode of Public Key Encryption This mode is identical to the Revised PK Encryption Mode (Section 5.3 in [HC98]), except for the omission of the DH payloads. When using the DH-less encryption mode for authentication, Main Mode is defined as follows. Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, [ HASH(1), ] Pubkey_r, Ke_i, [<Ke_i] --> HDR, PubKey_i, <-- Ke_r, HDR*, HASH_I --> <-- HDR*, HASH_R Aggressive Mode authenticated with the revised encryption mode is described as follows: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] Pubkey_r, Ke_i [, Ke_i ] --> HDR, SA, PubKey_i, Ke_r, <-- HASH_R HDR, HASH_I --> where HASH(1) is identical to section 5.2 in [HC98]. For the purpose of calculating HASH_I and HASH_R the values of g^xi and g^xr are set to an octet of 0. For the purpose of calculating SKEYID_d, SKEYID_a, and SKEYID_e, the value g^xy is set to an octet of 0. 4. Security Considerations The public key encryption modes of authentication in IKE require strong public key encryption. In particular, resistance to strong attacks generally known as "chosen ciphertext attacks" (CCA) is necessary. This is a practical need as well as the basis for a sound analysis of these protocols [BeCaKr]. Recently, an explicit chosen ciphertext attack on the PKCS #1 encryption standard was demonstrated [Ble]. RSA Labs., the authors of PKCS#1, are preparing a new release of PKCS #1 that will include the OAEP format of RSA encryption [RSAlabs]. It is strongly recommended that IKE specifications and implementations move to that format which was designed to resist CCA and other attacks. Canetti, Cheng, Krawczyk [Page 2] INTERNET DRAFT May 1998 References ========== [BeCaKr] Bellare, M., Canetti, R., and Krawczyk, H., "A Modular Approach to the Design and Analysis of Authentication and Key Exchange Protocols", Proceedings of the Thirtieth ACM Symposium on the Theory of Computation, May 1998. [Ble] Daniel Bleichenbacher, Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1, Proceedings of Crypto'98, August 1998. To appear. [HC98] Harkins, D. and D. Carrel, "The resolution of ISAKMP with Oakley", draft-ietf-ipsec-isakmp-oakley-08.txt, June 1998. [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security. [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", version 9, draft-ietf-ipsec-isakmp-09.{ps,txt}. [Pip96] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", version 2, draft-ietf-ipsec-ipsec-doi-02.txt. [RSAlabs] http://www.rsa.com/rsalabs/pkcs1/oem_counter.html Appendix A: XCHG attribute assigned number ========================================= This Appendix defines a new authentication mode value for the Revised Encryption Mode. This value is to be negotiated in Phase 1 (see [MSST98] and Appendix A in [HC98]). The value is: authentication mode value --------------------------- DHless RSA Encryption 6 Canetti, Cheng, Krawczyk [Page 3] INTERNET DRAFT May 1998 Authors' Addresses: ==================== Ran Canetti Pau-Chen Cheng IBM TJ Watson Research Center IBM TJ Watson Research Center POB. 704, Yorktown Heights, POB. 704, Yorktown Heights, NY 10598 NY 10598 Tel. 1-914-784-7076 Tel. 1-914-784-7446 canetti@watson.ibm.com pau@watson.ibm.com Hugo Krawczyk IBM TJ Watson Research Center POB. 704, Yorktown Heights, NY 10598 hugo@ee.technion.ac.il Canetti, Cheng, Krawczyk [Page 4]