IPSEC Working Group INTERNET-DRAFT
Radia Perlman


draft-ietf-ipsec-ikev2-tutorial-00.txt
February 2003


       Understanding IKEv2: Tutorial, and rationale for decisions
                <draft-ietf-ipsec-ikev2-tutorial-00.txt>


                          Status of this Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [Bra96]. 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).


Abstract

   The main job of a protocol specification is to document how the
   protocol works. It is sometimes difficult to learn how a protocol
   works from such a document, because there are so many details, and
   the necessary formalism for accuracy makes a specification long and
   intimidating to read. What also is usually lost in the process of
   creating an RFC for a protocol is documentation of the tradeoffs that
   were considered when making controversial choices.  Sometimes it is
   possible to find this information on the email archives, but that is
   a daunting task.  This document is intended to work both as a
   tutorial to understanding IKEv2, and a summary of the controversial
   issues, with the reasoning on all sides of each issue.  If any
   differences in details exist between this document and the IKEv2
   specification, the IKEv2 specification is authoritative. This
   document is intended only to make the IKEv2 specification more
   understandable on the first reading, as well as documenting reasoning
   behind decisions.

. Introduction

   IKE (Internet Key Exchange) is the protocol which performs mutual
   authentication and establishes security associations (SAs) for IPsec.
   The base protocol of the first version of IKE was documented in RFCs
   2407, 2408, 2409. Also, IKEv1 implementations incorporated additional
   functionality including features for NAT traversal, legacy
   authentication, and remote address acquisition. The goal of the IKEv2
   specification is to specify all that functionality in a single
   document, as well as simplify and improve the protocol, and fix
   various problems that had been found through deployment or analysis.
   It was also a goal of IKEv2 to understand IKEv1 and not to make
   gratuitous changes.  The goal was to make it as easy as possible for
   IKEv1 implementations to be modified for IKEv2, and to benefit from
   the experience gained from deployment of IKEv1. The design of IKEv2
   was a collaboration of the entire IPsec WG.


   IKEv2 preserves most of the features of the original IKE, including
   identity hiding, perfect forward secrecy, two phases, and
   cryptographic negotiation, while greatly redesigning the protocol for
   efficiency, security, robustness, and flexibility.  This document is
   intended to be a readable description of all the concepts, rather
   than being a complete specification of all the details. It also
   explains reasoning on all sides of controversial issues.

   For simplicity of description, we refer to the two parties in an IKE
   exchange as "Alice" and "Bob", where Alice will be the initiator of
   the exchange. These names allow us to use the pronouns "she" and
   "he".

1.1 Overview of IKEv2

   IKEv2 has an initial handshake in which Alice and Bob negotiate
   cryptographic algorithms, mutually authenticate, and establish a
   session key, creating an IKE-SA. Additionally, a first IPsec SA is
   established during the initial IKE-SA creation.

   All IKEv2 messages are request/response pairs. It is the
   responsibility of the side sending the request to retransmit if it
   does not receive a timely response.

   The initial exchange consists of two request/response pairs. The
   first pair negotiates cryptographic algorithms and does a Diffie-
   Hellman exchange.  The second pair is encrypted and integrity
   protected with keys based on the Diffie-Hellman exchange. In this
   exchange Alice and Bob divulge their identities and prove it using an
   integrity check generated based on the secret associated with their
   identity (private key or shared secret key) and the contents of the
   first pair of messages in the exchange. Also, the first IPsec SA is
   created.

   After the initial handshake, additional requests can be initiated by
   either Alice or Bob, and consist of either informational messages or
   requests to establish another child-SA. Informational messages
   include such things as null messages for detecting peer aliveness,
   and deletion of SAs.

   The exchange to establish a child-SA consists of an optional Diffie-
   Hellman exchange (if perfect forward secrecy for that child-SA is
   desired), nonces (so that a unique key for that child-SA will be
   established), and negotiation of traffic selector values which
   indicate what addresses, ports, and protocol types are to be
   transmitted over that child-SA.

1.2 Perfect Forward Secrecy/Computation Tradeoff

   The IKEv2 handshake includes nonces in addition to Diffie-Hellman
   values. If each side chose a unique private Diffie-Hellman number for
   each exchange, there would be no need for nonces. It is reasonable
   for an implementation to choose less than perfect forward secrecy by
   reusing the Diffie-Hellman number (avoiding expensive
   exponentiations), since the nonces, which must be unique for each
   exchange, will ensure unique keys for each IKE-SA. Likewise, child-
   SAs established through an IKE-SA can choose perfect forward secrecy
   and generate and send Diffie-Hellman values, or simply use nonces to
   establish unique keys.
1.3 Colocated Services

   In some cases Bob might host many different services (e.g., distinct
   web sites with different identities). All these identities would have
   the same IP address, but would have different keys and certificates.
   Having Alice initiate a connection to Bob's IP address does not
   inform Bob who she wants to communicate with. Therefore, IKEv2 allows
   Alice to specify an identity for Bob. This feature was given the
   affectionate name "You Tarzan. Me Jane." by Hugh Daniel.
1.4 DOS protection

   IKEv2 uses the stateless cookie feature of Photuris, as well as the
   optional additional exchange to request it, in order for Bob to
   ensure that the IKEv2 initiator can receive at the IP address it is
   claiming to be coming from before Bob devotes state and significant
   computation to the exchange.

   This aspect of IKEv2 was the subject of some debate in the WG. There
   were two alternatives for providing this feature. The chosen
   alternative was to have an extra round trip if a stateless cookie was
   desired. It was possible, (as specified in JFK, suggested in [PK01],
   and specified in the first version of IKEv2 which was declared to be
   a merging of the original IKEv2 and JFK), to provide this feature
   without adding an additional round trip. The arguments for avoiding
   the extra round trip were:

   * it saves a round trip

   * it avoids forcing Bob to make a decision about whether he is under
   attack

   The WG decided in favor of the additional round trip for this case
   because:

   * it made the protocol much simpler, since after the initial pre-
   exchange, Bob is not stateless. As a result of the protocol being
   simpler, it was likely that future changes would not break the
   handshake, and that future functionality could be incorporated
   without a redesign.

   * it makes message 3 shorter, since the mechanism by which Bob can be
   stateless is to have Alice repeat everything Bob would have needed to
   remember in message 3.

   * This design makes it easy to defend against a "fragmentation
   attack", a DOS attack on an IKE exchange that was pointed out by
   Charlie Kaufman that could enable an attacker to prevent IKE
   exchanges from completing.  Since message 3 in an IKE exchange tends
   to be long (it includes certificates), and IKE runs over UDP, it is
   likely that it will need to be fragmented. Without the extra round
   trip, it is message 3 in which Bob receives and verifies the cookie.
   An attacker could send fragments, exhausting Bob's reassembly
   resources. With the extra two messages for cookie exchange, all
   messages are sufficiently short so that reassembly would not be
   required, and a fragmentation attack cannot prevent Bob from
   verifying Alice's cookie. Once Bob has verified Alice's cookie, it is
   a fairly easy implementation trick to ensure the rest of the IKE
   exchange completes, even in the face of a fragmentation attack, by
   providing a side-channel from IKE to the reassembly code, whereby Bob
   can inform the reassembly code of preferred IP addresses (those that
   have returned a valid cookie).
1.5 Cryptographic Negotiation

   In IKE, cryptographic negotiation was "a la carte", meaning that each
   algorithm (encryption, integrity protection/prf (prf=pseudorandom
   function), Diffie-Hellman group), was independently negotiated. Aside
   from being complex to understand, it also created an exponential
   expansion, since if there were k of one type of algorithm that could
   interwork with j of another, there had to be k*j seperate proposals.
   In the original IKEv2 design, the a la carte concept was kept, but
   the SA payload was simplified, and sets of algorithms that could
   interwork together could be presented as a single proposal, and Bob
   could narrow the choices down to any one from the set. JFK, in
   contrast, had no negotiation of cryptographic algorithms, which was
   even simpler, but made it difficult to migrate to different
   algorithms in the future.

   The IKEv2 and JFK authors together agreed that a compromise would be
   suites, as was done in SSL. With a suite, all parameters are encoded
   into a single suite number, and negotiation consists of specifying
   one or more suites and having the other side choose.  It was assumed
   to be a noncontroversial decision, but unfortunately it was
   controversial. The arguments in favor of suites are:

   * it is simpler and more compact to encode

   The arguments in favor of a la carte are:

   * it is more flexible

   * there is the fear that there will be an exponential number of
   suites defined

   * it is a gratuitous change from IKEv1 that made a lot of unnecessary
   work for implementations. Suites might have been OK if starting from
   scratch, but a la carte was easier for migrating from an IKEv1 code
   base.

   Although there was sympathy with the a la carte supporters, a
   decision had to be made, and based on a straw poll at a WG meeting,
   the decision was to use suites.

1.6 Acquiring an IP address

   When an endnode dials into a firewall, it is often the case that the
   endnode needs to be given an IP address by the firewall. There were
   two proposed methods of doing this:

   tells Alice an IP address, and


   The appeal of MODECFG is that it minimizes the number of messages and
   crypto operations in getting an IPsec session set up. The appeal of
   DHCP-relay is that it provides all of the flexibility and power of
   DHCP (including extensions defined in the future) and does so in a
   way that appears to make it independent of the IKE specification.

   It was decided to go with MODECFG because of the following reasoning:

   For an endnode to acquire an IP address on a remote network for use
   with IPsec, there are several things going on - only one of which
   involves DHCP.  The address must be leased, but in addition the IPsec
   gateway implementation has to begin responding to ARPs to that
   address and forwarding packets addressed to that address over the
   IPsec tunnel. The IPsec gateway should only accept packets over the
   IPsec tunnel with source address equal to one that the endnode has
   legitimately leased. That means the gateway can't be a passive relay.
   It has to parse the messages it is passing through, and if there are
   extensions to DHCP in the future that affect leases on IP addresses,
   the gateways will have to be updated to understand them.

   With DHCP-relay, the IPsec endnode, the IPsec gateway, and the DHCP
   server are running a three party protocol. The IPsec gateway can
   either eavesdrop on the DHCP conversation or be a full participant by
   acting as a DHCP server to the endnode and a client to the DHCP
   server.

   As a practical matter, MODECFG specifies exactly what the two
   participants have to do, while DHCP-relay is more open to
   interpretation. Unless DHCP-relay were specified more precisely in
   terms of what the IPsec gateway had to do with the information it saw
   passing by, it seemed likely that MODECFG would give us better
   interoperability.

   The use of MODECFG does not preclude the use of tunnelled DHCP for
   uses other than acquiring leases on IP addresses, and in the future,
   if there is functionality that can only be done using DHCP-relay,
   this may be done. The worry was that both MODECFG and DHCP-relay
   might be needed, and that doing DHCP-relay instead of MODECFG would
   mean less implementation effort. However, the decision was that for
   now, since MODECFG was simpler and higher performance, and gave all
   currently-needed functionality, IKEv2 would assign addresses using
   MODECFG.



2.0 Features for an IKE successor

   The features of IKEv2 include:

   * mutual authentication: At the conclusion of the handshake, Alice
   and Bob will both know who they are talking to

   * cryptographic negotiation: The protocol should allow negotiation of
   cryptographic algorithms rather than specifying one choice. The
   reasons for this are that some algorithms are appropriate for
   different circumstances (such as supporting legacy cryptographic
   hardware that only supports older algorithms, or weaker encryption
   algorithms for exportability, or allowing migration to newer
   algorithms if flaws are found in older ones).

   * establishment of integrity and encryption keys for the SA
   established through the handshake.

   * DOS protection: IKEv2 should protect itself from having memory
   and/or computation resources exhausted due to DOS attacks

   * identity hiding: an eavesdropper will not discover who the parties
   are (though the IP addresses will be known)

   * perfect forward secrecy: even if someone has recorded the
   conversation and, subsequent to closing of the SA, broken into one or
   both of Alice and Bob, and obtained all stored secrets, it should not
   be possible to decrypt the conversation.

   * cheap and graceful rekeying: it is considered good cryptographic
   practice to change keys periodically, and IKEv2 should enable
   rekeying during a conversation without disrupting the conversation

   * dead peer detection: IKEv2 should detect when a peer is dead, both
   to prevent transmitting data into a "black hole", and to avoid
   wasting resources maintaining state about a nonfunctioning SA

   * inexpensive creation of multiple SAs between a pair of nodes: IKEv2
   should leverage the initial expensive (because it is usually based on
   public key technology) handshake in order to enable creation of many
   SAs between the same pair of nodes

   * coexistence with NATs: IKEv2 should be designed so that, when
   possible, it can work through NAT devices

   * legacy authentication: IKEv2 should allow Alice to authenticate
   using a token card, or a name and password

   * support for multiple services colocated at an IP address: Bob might
   have multiple services colocated at his IP address, and Alice needs
   to be able to specify which of these she wants to talk to



   IKEv2 is a major redesign of IKEv1. Syntax is preserved when there is
   no compelling technical reason to change it, so that there might be
   some ability to preserve code. However, IKEv2 is not compatible with
   IKEv1. A node that speaks both IKEv2 and IKEv1 can interwork with an
   IKEv1 node by detecting that the peer speaks only IKEv1, and
   thereafter speaking IKEv1.

   2.1 Why Two Phases?

   In IKEv2 terminology, the first phase is known as the IKE-SA. Once
   the IKE-SA is created, it can be used for sending authenticated
   notification messages, reliable dead-peer detection, and inexpensive
   creation of "child-SAs", which are IPsec SAs, and in theory could
   facilitate creation of SAs for other protocols as well.

   It was argued in [PK01] and [JFK] that having two phases was
   unnecessary and added complexity. However, experience with IKEv1
   showed the two phases to be useful, since there were scenarios in
   IPsec deployments in which multiple child-SAs between the same pair
   of nodes was desirable.

   Why do people find it useful to create multiple IPsec SAs between the
   same pair of hosts?

   Several years ago Bellovin pointed out that if encryption is done
   without integrity protection, there is a splicing attack whereby a
   process involved in one flow can, through an active attack, cause
   traffic for a different flow to be decrypted and delivered to the
   process in the first flow. Of course, nobody should be doing
   encryption without integrity protection. It is likely there is no
   similar flaw if integrity is used. But in a case where a router is
   delivering traffic on behalf of multiple customers, and the data is
   going to another router in order to access other machines of those
   customers, the customers feel safer knowing that their traffic is
   being delivered with a different SA (and different key) than traffic
   between nodes belonging to other customers.

3.0 References


   [EAP]    Blunk, L. and Volibrecht, J., "PPP Extensible Authentication
            Protocol (EAP), RFC 2284, March 1998.

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

   [HKP99]  Harkins, D., Korver, B., Piper, D., "IKE Challenge/Response for
            Authenticated Cryptographic Keys", draft-ietf-ipsec-ike-crack-00.txt

   [JFK]   Aiello, W., Bellovin, S., Blaze, M., Canetti, R., Ioannidis,
           J., Keromytis, A., Reingold, O., draft-ietf-ipsec-jfk-03, April 2002

   [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J.
            "Internet Security Association and Key Management Protocol
            (ISAKMP)", RFC 2408, November 1998.

   [Pip98]  Piper, D., "The Internet IP Security Domain Of
            Interpretation for ISAKMP", RFC 2407, November 1998.

   [PK01]   Perlman, R., and Kaufman, C., "Analysis of the IPsec key
            exchange Standard", WET-ICE Security Conference, MIT, 2001,
            http://sec.femto.org/wetice-2001/papers/radia-paper.pdf.

   [Orm96]  Orman, H., "The Oakley Key Determination Protocol", RFC
            2412, November 1998.


Author Address

Radia Perlman
radia.perlman@sun.com
Sun Microsystems