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

Versions: 00                                                            
Internet Engineering Task Force                          Charlie Kaufman
IP Security Working Group                                Iris Associates
Internet Draft                                             Radia Perlman
                                                        Sun Microsystems
                                                        Andrew Krywaniuk
                                                            July 9, 2001

                  Code-preserving Simplifications and
                          Improvements to IKE

Status of this Memo

   This document is a submission to the IETF Internet Protocol Security
   (IPsec) Working Group. Comments are solicited and should be addressed
   to the working group mailing list (ipsec@lists.tislabs.com) or to the

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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 made obsolete 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

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   This document is a product of the IETF's IPsec Working Group.
   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Kaufman et al           Expires February 9, 2002                [Page 1]

Internet Draft             IKE Improvements                July 12, 2001


   This internet draft recommends modifications to Phase 1 IKE that will
   minimize code changes. We recommend simplification by removing some
   of the options, and minimal changes, when they provide a large
   increase in functionality, in the remaining portions of IKE.

IPsec Working Group                                             [Page 2]

Internet Draft             IKE Improvements                July 12, 2001

Table of Contents

   1.   Introduction.................................................4
   2.   Specification of Requirements................................4
   3.   Get Rid of Aggressive Mode...................................4
   4.   Remove Public Key Encryption Variants........................4
   5.   Allow stateless operation....................................4
   6.   Change Parameter Negotiation to Allow Choices................5
   7.   Fix Main-Mode with Preshared Keys............................5
   8.   Invert Identity Protection...................................6
   9.   Additional Functionality.....................................6
   9.1  Unidirectional Authentication................................6
   9.2  Weak Preshared Secret Authentication.........................7
   10.  IANA Considerations..........................................7
   11.  Security Considerations......................................7
   12.  References...................................................7

IPsec Working Group                                             [Page 3]

Internet Draft             IKE Improvements                July 12, 2001

1.   Introduction

   IKE has received criticism for being too complex. Rather than
   starting over, we recommend changes to IKE that are as code
   preserving as possible. For more analysis of these recommended
   changes see [PK01] or [PK00]. The reader is assumed to have some
   knowledge of IKE. Each section is a separate recommendation for
   something that significantly simplifies IKE, fixes bugs, or adds
   significant functionality.

2.   Specification of Requirements

   This document makes recommendations rather than specifying

3.   Get Rid of Aggressive Mode

   If identity hiding is considered important, then use it all the time.
   If smaller numbers of messages are important, then always use
   aggressive mode. Users are unlikely to understand the choices in
   order to decide which mode to use. The optimization of sometimes
   being able to use fewer messages, in ill-defined cases, seems not
   worth the complexity of doubling the number of permutations that need
   to be designed and implemented.

4.   Remove Public Key Encryption Variants

   Signature-only public keys are useful because they are less likely to
   be escrowed, it is unlikely that someone would have an encryption key
   but not a signature key, and each side knows its own signature key.
   IKE protocols using public encryption keys do not have significant
   advantages over public signature key SA establishment.

   Furthermore, the public encryption key variants are operationally
   awkward because they require the initiator to already know the
   responder's public key. Rather than fixing this flaw, which would
   require significant redesign of the protocols, it seems better to
   merely remove the public encryption variants.

5.   Allow stateless operation

   The idea of stateless cookies, as envisioned by Photuris, was that
   Bob need not keep state until he is assured that the initiator can

IPsec Working Group                                             [Page 4]

Internet Draft             IKE Improvements                July 12, 2001

   receive from the IP address she claims to be coming from. IKE does
   not allow Bob to be stateless, since he has to remember the
   information (such as the crypto suites that Alice offers) from
   message 1 in order to validate Alice's signature in message 5. If
   Alice repeats all the information from message 1 in message 3, Bob
   can be stateless until message 3.

6.   Change Parameter Negotiation to Allow Choices

   Sometimes several cryptographic algorithms work together. But IKE
   currently requires every combination to be specified. There are four
   types of crypto algorithms for each suggested suite (encryption
   algorithm, hash algorithm, authentication algorithm, and Diffie-
   Hellman group).

   If in many cases several of them can be used interchangeably, this
   causes an exponential explosion to specify all supported
   combinations. Instead we suggest a set of proposals, where there is
   allowed to be a choice of algorithms within a proposal. For instance:

   proposal 1: ({Enc-A, Enc-B}, MD5, {RSA public signature keys, RSA
   public keys with new protocol}, {DH group 1, DH group 2, DH group 3})

   proposal 2: ({Enc-C, Enc-D, Enc-E}, SHA, preshared keys, {DH group 1,
   DH group 4})

7.   Fix Main-Mode with Preshared Keys

   In IKE as currently specified, Alice sends her identity to Bob in a
   key encrypted with a key which is a function of the pre-shared key.
   So Bob can't decrypt the message to discover Alice's identity, unless
   he knows Alice's identity. IKE's solution is to require Alice's
   identity to be her IP address.

   But then there's no reason to use the extra messages to do identity
   hiding. Worse yet, it's useless in the "road warrior" case where
   someone might configure a shared secret between their laptop and the
   firewall, and attempt to connect from unpredictable locations on the
   Internet, since their IP address will change.

   The solution is to change the key used to encrypt Alice's identity to
   be only a function of the Diffie-Hellman key. The protocol already
   assures that Alice proves knowledge of the preshared key because she
   transmits something to Bob that is a hash of information including
   that key. This minimal change (changing the encryption key used for
   encrypting messages 5 and 6 to not be a function of the shared key)

IPsec Working Group                                             [Page 5]

Internet Draft             IKE Improvements                July 12, 2001

   allows use of arbitrary identifiers and makes this mode work for the
   road warrior case.

8.   Invert Identity Protection

   In the case of main mode with public key signatures, Bob's identity
   is hidden even from an active attacker, but Alice's identity is
   exposed to an active attacker impersonating Bob's address to Alice.

   We argue that it is preferable to hide Alice's identity rather than
   Bob's. The protocol could be modified to hide Alice's identity
   instead of Bob's from an active attacker. This would be done by
   moving the information from msg 6 into msg 4. This even completes the
   protocol in one fewer message.

9.   Additional Functionality

   The previous sections are either suggested simplifications or fixing
   problems. This section suggests two possible enhancements.

9.1  Unidirectional Authentication

   In some cases only one side has a cryptographic identity. For
   example, a common use case for SSL is where the server has a
   certificate and the user does not. In this case SSL creates an
   encrypted tunnel. The client side knows it is talking to the server,
   but the server does not know to whom it is talking. If the server
   needs to authenticate the user, the application typically asks for a
   name and password.

   The one-way authentication is vital in this case because the user has
   to know he is sending his password to the correct server, and the
   protocol also ensures that the password will be encrypted when
   transmitted. In some cases security is useful even if it is only one-
   way. For instance, a server might be disseminating public
   information, and the client would like to know that it is receiving
   this information from a reliable source, but the server does not need
   to authenticate the client.

   Since this is a useful case in SSL, it would be desirable to allow
   for unidirectional authentication within IPSec. None of the IKE
   protocols allow this.

IPsec Working Group                                             [Page 6]

Internet Draft             IKE Improvements                July 12, 2001

9.2  Weak Preshared Secret Authentication

   The IKE protocol for pre-shared secrets depends on the secret being
   cryptographically strong. If the secret were weak, say because it was
   a function of a password, an active attacker (someone impersonating
   one side to the other) could obtain information with which to do an
   off-line dictionary attack. Our suggested improvement to the protocol
   still requires a strong pre-shared secret.

   There is a family of protocols in which a weak secret, such as one
   derived from a password, can be used in a cryptographic exchange in a
   way that is invulnerable to dictionary attack, either by an
   eavesdropper or someone impersonating either side. The original such
   protocol, EKE, worked by encrypting a Diffie-Hellman exchange with a
   hash of the weak secret, and then authenticating based on the strong
   secret created by the Diffie-Hellman exchange.

   The ability to use a weak secret such as a password in a secure way
   is very powerful, in the case where it is a user being authenticated.
   The current IKE pre-shared secret protocol could be replaced with one
   of these protocols at no loss in security or performance. If an IKE
   weak secret variant were designed, then the strong secret variant
   should be dropped, since certainly a protocol that works with a weak
   secret will work with a strong secret.

10.  IANA Considerations

   This document does not require any assigned numbers.

11.  Security Considerations

   The suggested changes simplify IKE considerably, at no loss in
   security. Some changes, such as allowing stateless operation, enhance
   the security of IKE.

12.  References

   [IKE]   Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
           RFC 2409, November 1998

   [PK00]  Perlman, R., Kaufman, C., "Key Exchange in IPSec: Analysis of
           IKE", IEEE Internet Computing Journal special issue on
           Security Solutions, Nov/Dec 2000.

   [PK01]  Perlman, R., Kaufman, C., "Analysis of the IPSec Key Exchange

IPsec Working Group                                             [Page 7]

Internet Draft             IKE Improvements                July 12, 2001

           Standard", WET-ICE security conference, MIT,

   Authors' Addresses

     Charlie Kaufman
     Iris Associates
     E-mail: ckaufman@iris.com

     Radia Perlman
     Sun Microsystems
     E-mail: radia.perlman@sun.com

     Andrew Krywaniuk
     Alcatel Networks Corporation
     600 March Road
     Kanata, ON
     Canada, K2K 2E6
     +1 (613) 784-4237
     E-mail: andrew.krywaniuk@alcatel.com

   The IPsec working group can be contacted via the IPsec working
   group's mailing list (ipsec@lists.tislabs.com) or through its chairs:

     Theodore Y. Ts'o
     Massachusetts Institute of Technology

     Barbara Fraser
     Cisco Systems


   This document expires February 9th, 2002.

IPsec Working Group                                             [Page 8]