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

Versions: 00 01                                                         
IPSEC Working Group                       R. Canetti, P. Cheng, H. Krawczyk
INTERNET-DRAFT                                IBM Research and the Technion
draft-ietf-ipsec-revised-enc-mode-00.txt                         April 1997
Expire in six months

               A revised encryption mode for ISAKMP/Oakley

                          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 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), nic.nordu.net (Europe),
   munnari.oz.au (Australia), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   1. Abstract

   The ISAKMP/Oakley document [HC97] describes a proposed standard for
   using the Oakley Key Exchange Protocol in conjunction with ISAKMP to
   obtain authenticated and secret keying material for use with ISAKMP,
   and for other security associations such as AH and ESP for the IETF
   IPsec DOI.

   The public-key encryption method of carrying out Phase 1 of the key
   exchange in the ISAKMP/Oakley document requires two public key
   encryption and decryption operations from both the Initiator and
   the Responder. The present document describes a small modification
   to this method. The resulting method requires only one public key
   encryption and decryption operation from each party, while maintaining
   (and even improving on) the strong security properties of the
   ISAKMP/Oakley public-key encryption mode.

   Remark: This document is NOT self-contained. It uses notation and
   definitions of [HC97]. It is best read in conjunction with [HC97].

Canetti, Cheng, Krawczyk                                        [Page i]

INTERNET DRAFT                                             April 1997

   2. Introduction

   The ISAKMP/Oakley  protocol [HC97] defines three alternative methods of
   carrying out Phase 1 of the key exchange. Two of these methods are usable
   by parties that do not already share a secret key. These are the Signature
   Method (Section 5.1 in [HC97]) and the Encryption Method (Section 5.2
   in [HC97]).

   The Encryption Method enjoys several significant advantages over the
   Signature Method. These advantages are sketched in Section 4.
   However, in the ISAKMP/Oakley draft the Encryption Method requires
   TWO public key encryption and decryption operations for each party.
   This is unnecessarily expensive. (In weak processors the extra
   exponentiation may have a significantly adverse effect in performance.)

   This document describes a simple modification of the ISAKMP/Oakley
   Encryption Method. The resulting method enjoys the same security
   advantages, and requires only ONE public key encryption and decryption
   operation for each party. This method, called the Revised Encryption
   Method, is presented as an alternative method to the ISAKMP/Oakley
   Encryption Method. In fact, the revised method enjoys even additional
   security advantages on top of the ISAKMP/Oakley Encryption Method,
   as elaborated below.

   The change from the ISAKMP/Oakley Encryption Method is basically as
   follows. There, each party's identity and nonce are encrypted via
   TWO separate applications of the public-key encryption algorithm.
   (In fact, if the party's identity is long then this may require
   additional applications of the public-key encryption algorithm.)

   In the Revised Encryption Method the nonce is still encrypted
   using the public-key encryption algorithm. However,
   the sending party's identity (and also the certificate, if it is
   sent) is encrypted via symmetric encryption (e.g. DES), with a key
   derived from the nonce. This solution adds no significant complexity to
   the implementation and saves a costly long (RSA or other) exponentiation.
   In addition, the Key Exchange payload (ie. the DH challenges) is also
   encrypted using the same derived key. This provides additional protection
   against cryptanalysis of the DH exchange.

   The Revised Encryption mode has another advantage. The (optional)
   Certificate payload is also encrypted using the same derived key.
   Consequently anonymity is preserved even if the certificate is sent
   as part of the exchange.

   The rest of this document is organized as follows. In Section 3
   the Revised Encryption Method is described. The description is
   written in a way so that Section 3 can be read as a replacement to
   Section 5.2 in [HC97]. Section 4 discusses some security advantages
   of the Encryption Method relative to the Signature method.
   (These advantages are shared by the Revised Encryption Method.)
   Appendix A holds the authentication method value of the new method
   (see ISAKMP [MSST96] and Appendix A of [CH97]).

Canetti, Cheng, Krawczyk                                        [Page 1]

INTERNET DRAFT                                             April 1997

   3. The new method: Revised Encryption Method of Oakley Phase 1

   Using public key encryption to authenticate the exchange, the
   ancillary information exchanged is encrypted nonces. Each party's
   ability to reconstruct a hash (proving that the other party decrypted
   the nonce) authenticates the exchange.

   In order to perform the public key encryption, the initiator must
   already have the responder's public key. In the case where a party
   has multiple public keys, a hash of the certificate of the initiator
   used to encrypt the ancillary information is passed as part of the
   third message. In this way the responder can determine which
   corresponding private key to use to decrypt the encrypted payloads
   and identity protection is retained.

   The nonces are encrypted with the other party's public key.
   Only the body of the payload is encrypted, the payload header is
   left in the clear. The Key Exchange payloads (KE) and the identities
   of the parties (IDii and IDir) are encrypted with the negotiated
   symmetric encryption algorithm (e.g DES), using a key derived from
   the nonce. If the Initiator's certificate is passed from Initiator to
   Responder then, for anonymity, the certificate is also encrypted
   under the same key.

   That is, Phase 1 (Main Mode) is defined as follows.

          Initiator                        Responder
         -----------                      -----------
          HDR, SA                   -->
                                    <--    HDR, SA
          HDR, [ HASH(1), ]
            <Ni>PubKey_r            -->
                                    <--  HDR, <Nr>PubKey_i
          HDR*, HASH_I              -->
                                    <--    HDR*, HASH_R

Canetti, Cheng, Krawczyk                                        [Page  2]

INTERNET DRAFT                                             April 1997

   HASH(1) is a hash (using the negotiated hash function) of the
   responder's certificate which the initiator is using to encrypt
   the nonce.

   The notation <...>PubKey refers to public key encryption
   (e.g.  using the RSA algorithm) while the notation <...>Ke
   refers to encryption under the negotiated symmetric cipher.
   The keys for the symmetric cipher are derived as follows.
   First, derive the values Ne_i and Ne_r:

         Ne_i = prf(Ni, CKY-I)
         Ne_r = prf(Nr, CKY-R)

   Next, the keys Ke_i and Ke_r are derived from Ne_i and Ne_r,
   respectively, in the way described in Appendix B of [HC97].
   That is, to derive Ke_i run the procedure described in Appendix B of
   [HC97], where SKEYID_e is replaced by Ne_i. To derive Ke_r run the
   procedure described in Appendix B of [HC97], where SKEYID_e is
   replaced by Ne_r.

   For completeness, we detail the  procedure for deriving Ke_i.
   Ke_r is derived analogously. If the desired length of Ke_i is
   at most the length of Ne_i then Ke_i is the sufficient number
   of most significant bits of Ne_i. If the desired length of Ke_i
   exceeds the length of Ne_i then more bits are generated by applying
   the prf with Ne_i as the key and a byte of 0 as the input.
   The output of the prf is fed back into itself until sufficient
   number of bits are generated. For example, if the output of prf
   is 128-bit long and Ne_i needs to be 320-bit long, then Ne_i is
   the most significant 320 bits of K, where K = K1 | K2 | K3  and

           K1 = prf(Ne_i, 0)
           K2 = prf(Ne_i, K1)
           K3 = prf(Ne_i, K2)

   Note that the values of Ke_i and Ke_r are ephemeral and discarded
   after this use.

Canetti, Cheng, Krawczyk                                        [Page  3]

INTERNET DRAFT                                             April 1997

   If CBC mode is used for the symmetric encryption then the
   initialization vectors (IV) are set as follows. The IV for
   encrypting KE is set to 0. The IV for encrypting IDii (resp., IDir)
   is the last ciphertext block of <KE>Ke_i (resp., <KE>Ke_r).
   The IV for encrypting the certificate
   is the last ciphertext block of <IDii>Ke_i (resp., <IDir>Ke_r).
   Encrypted payloads are padded up to the nearest block
   size. All padding bytes, except for the last one, contain 0x00.
   The last byte of the padding contains the number of the padding
   bytes use, excluding the last one.
   Note that this means that there will always be padding.
   Note also that the IV chaining method used here implies that KE,
   the ID and the certificate have to be encrypted (and decrypted) in
   that order.

   When a Certificate payload is sent in the context of
   the Revised Encryption Method, it MUST be encrypted in the manner
   described above.

     Oakley Aggressive Mode in conjunction with the Revised Encryption
     Method is described as follows (notation is as described above):

          Initiator                        Responder
         -----------                      -----------
          HDR, SA, [ HASH(1),]
            <IDii>Ke_i               -->
                                           HDR, SA, <Nr>PubKey_i,
                                    <--         <IDir>Ke_r, HASH_R
          HDR, HASH_I               -->

   RSA encryption MUST be encoded in PKCS #1 format. The payload length
   is the length of the entire encrypted payload plus header. The PKCS
   #1 encoding allows for determination of the actual length of the
   cleartext payload upon decryption.

Canetti, Cheng, Krawczyk                                        [Page 4]

INTERNET DRAFT                                             April 1997

   4. Security Considerations

   In this section we sketch the advantages of authentication by
   public-key encryption, as opposed to authentication by signature.
   First, in the Encryption mode an attacker has to break BOTH the
   the public key encryption in use (e.g. RSA) and DH exchange
   in order to learn the agreed key. In the Signature Mode breaking the
   DH exchange is sufficient. This is a substantial security advantage
   in a scenario where the same prime is used  to secure a large number
   of exchanges: such a prime will become an attractive
   target for cryptanalysis, thus it may provide only weak security.
   It also adds protection against a party that chooses weak parameters
   in the DH exchange, such as weak primes or short exponents.

   Next, using encryption for authentication provides for a plausibly
   deniable exchange. There is no proof (in contrast to the use of
   digital signatures) that the conversation ever took place since each
   party could have generated both sides of the exchange.

   Furthermore, unlike other authentication methods, authentication with
   public key encryption allows for identity protection even in
   Aggressive Mode.

   We remark that both the ISAKMP/Oakley Encryption Method and the
   Revised Encryption method described here are based on a similar
   mode in [Kra96] where a more extensive discussion on the above issues
   can be found.

   5. Acknowledgments

   We thank Dan Harkins for helpful discussions and suggestions.

   6. References

   [HC97] Harkins, D. and D. Carrel, "The resolution of ISAKMP with
   Oakley", draft-ietf-ipsec-isakmp-oakley-03.txt, February 1997.

   [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
   Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium
   on Network and Distributed Systems Security.

Canetti, Cheng, Krawczyk                                        [Page 5]

INTERNET DRAFT                                             April 1997

   [MSST96] Maughhan, D., Schertler, M., Schneider, M., and Turner, J.,
   "Internet Security Association and Key Management Protocol (ISAKMP)",
   version 7, draft-ietf-ipsec-isakmp-07.{ps,txt}.

   [Pip96] Piper, D., "The Internet IP Security Domain Of Interpretation
   for ISAKMP", version 2, draft-ietf-ipsec-ipsec-doi-02.txt.

   Appendix A: XCHG attribute assigned number

   This Appendix defines a new authentication method value for the
   Revised Encryption Method.  This value is to be negotiated in
   Phase 1 (see [MSST96] and Appendix A in [HC97]).  The value is:

             authentication method value

              Revised RSA Encryption              5

   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

Canetti, Cheng, Krawczyk                                        [Page 6]