[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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
               <draft-ietf-ipsec-dhless-enc-mode-00.txt>


                          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_b>Ke_i and <KE_b>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), ]
          <Ni_b>Pubkey_r,
          <IDii_b>Ke_i,
          [<<Cert-I_b>Ke_i]       -->
                                         HDR, <Nr_b>PubKey_i,
                                  <--         <IDir_b>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),]
          <Ni_b>Pubkey_r,
          <IDii_b>Ke_i
          [, <Cert-I_b>Ke_i ]     -->
                                         HDR, SA, <Nr_b>PubKey_i,
                                              <IDir_b>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]