IPSEC Working Group                                       Dan Harkins
INTERNET-DRAFT                                        Charlie Kaufman
draft-ietf-ipsec-ikev2-rationale-00.txt                  Tero Kivinen
Expires: August 2002                                     Stephen Kent
                                                        Radia Perlman
                                                        February 2002



                       Design Rationale for IKEv2
               <draft-ietf-ipsec-ikev2-rationale-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."


     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/1id-abstracts.html

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html

Abstract

   This document describes the reasons for the design choices in IKEv2,
   the protocol described in draft-ietf-ipsec-ikev2-01.txt.  This
   document describes why certain features are supported, and explains
   the modifications between the second draft of IKEv2 and the first. It
   describes both the changes we chose to make and the changes that we
   considered but chose not to make. The changes are minor and mostly
   based on feedback received from the first draft.

1. Introduction

   IKEv2 [Har01] has been presented to the IPsec WG as a possible
   successor to IKE (IKE is documented in RFCs 2407, 2408, and 2409).
   IKEv2 preserves most of the features of the original IKE, including



Harkins, Kaufman, Kivinen, Kent, Perlman                        [Page 1]


INTERNET DRAFT                                             February 2002


   identity hiding, perfect forward secrecy, two phases, and
   cryptographic negotiation, while greatly redesigning the protocol for
   efficiency, security, robustness, and flexibility.  This document
   explains the reasoning for the design choices made by IKEv2, as well
   as possible alternatives, the advantages and disadvantages of these
   alternatives, and a description of how the alternatives, if desired,
   would be implemented.

2.0 Features for an IKE successor

   At a minimum, such a protocol should perform mutual authentication
   between two parties and establish cryptographic keys for integrity
   and encryption of an IPsec SA. Simplicity is always a goal in any
   protocol.  Additional features, apropos a key and security
   association management protocol for IPsec, include identity hiding,
   cheap and graceful rekeying, dead peer detection, plausible
   deniability, support for multiple services co-located at an IP
   address, negotiation of peer-dependent IPsec policies, and a two-
   phase structure to enable inexpensive creation of multiple SAs
   between the same two hosts or security gateways. 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 (backwards) compatible with
   IKEv1. A node that implements both IKEv2 and IKEv1 can interwork with
   an IKEv1 node by detecting that the peer implements only IKEv1, and
   thereafter communicating using only 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 for subscriber traffic.
   In theory, IKE could facilitate creation of SAs for other protocols
   as well.

   We argued in [PK01] that having two phases was unnecessary and added
   complexity. Since then, we have gotten feedback that the two phase
   structure is useful and in typical IPsec deployments, multiple child-
   SAs are indeed created. Also, once the details of the design were
   worked out, we found that the ability to send authenticated
   notification messages made certain necessary features, such as dead
   peer detection, simpler and more robust.

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

   - avoiding multiplexing multiple conversations over the same SA.



Harkins, Kaufman, Kivinen, Kent, Perlman                        [Page 2]


INTERNET DRAFT                                             February 2002


   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 through a shared crypto implementation
   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 under these circumstances. It is likely there is no
   similar flaw if integrity is used. But in a case where a security
   gateway is delivering traffic on behalf of multiple customers, and
   the data is going to another security gateway in order to access
   other machines of those customers, the customers feel safer knowing
   that their traffic is being carried via a different SA (and different
   key) than traffic between nodes belonging to other customers.

   - different security properties of different flows. According to
   policy, some traffic might be only integrity-protected. Other traffic
   might be encrypted with a short key. Other traffic might be encrypted
   with a long key. Other traffic might use a vanity crypto algorithm
   designed by one of your customers, and it will make them happy if you
   use their algorithm for their traffic. In [PK01] we argued that all
   traffic might as well be protected according to the needs of the
   traffic that requires the strongest protection, but there might be
   performance reasons or legal reasons (or vanity reasons) why this is
   undesirable.

   - different SAs for different classes of service. There might be
   different classes of service, such as priority classes, that might
   cause traffic for one class to travel much more slowly to the SA
   destination than other types of traffic to the same SA destination.
   To avoid replay attacks, the recipient keeps track of which sequence
   numbers have been received.  Typically, it only keeps track of the
   highest n sequence numbers, up to the highest sequence number it has
   seen on this SA, and data with sequence numbers lower than the "left"
   side of the receive window are discarded. If different classes of
   service have widely disparate delivery times, the recipient would
   have to maintain a (potentially much) larger receive window to avoid
   inappropriate discarding of "late arriving" IPsec traffic.

   In addition to these reasons for creating multiple child-SAs, we
   found that IKEv2's robustness is enhanced by its ability to use the
   IKE-SA to send reliable and authenticated informational messages.
   This detects error conditions, allows rekeying, and provides a method
   for detecting a dead peer.

   2.2 Identity Hiding

   Some people argue that identity hiding is an exotic feature that
   cryptographers put into IKEv1 just because they could. In many cases,



Harkins, Kaufman, Kivinen, Kent, Perlman                        [Page 3]


INTERNET DRAFT                                             February 2002


   such as those where nodes are at  fixed IP addresses, the identity is
   not hidden.

   And, there are different flavors of identity hiding. IKEv2 provides
   identity hiding for both parties from passive attackers. Beyond that,
   one might want to hide the identities from active attackers.  With
   public encryption keys, if at least one side already knows the
   identity and public key of the other, then it is possible to protect
   both sides from any active attacker (assuming the encryption key is
   not escrowed or otherwise compromised). With pre-shared secret keys,
   assuming both parties already know who they expect to be speaking
   with (within a small set, perhaps), it is also possible to protect
   both identities from active attack.

   However, with public signature keys, one side or the other has to
   reveal its identity first. If it is talking to an active attacker, it
   will have revealed its identity.  In [PK01] we argued that it was
   more important to protect the identity of the initiator, since in the
   client-server model, the server would be at a fixed IP address and
   would not have a hideable identity.  However, we later realized that
   a much easier attack is a polling attack, in which the attacker
   merely opens an IPsec connection to a node. If the responder reveals
   its identity first, then this simple attack, which is easier to mount
   than a passive attack, will reveal the identity at that address. If
   the model were changed to a strict client-server model in which
   clients never respond to connections, and server identities are not
   important to protect, then it is reasonable to have the responder
   reveal its identity first. The feedback we got from the WG was that
   they did not want to change IPsec from a peer-ti-peer protocol into a
   client-serverprotocol.

   To avoid a polling attack, (in which an active attacker simply
   initiates a connection to an IP address to find the identity
   associated with that IP address) IKEv2 has the initiator reveal its
   identity first. The active attack that IKEv2 has chosen not to deal
   with involves having someone impersonate Bob's IP address and
   discover the identities of parties that attempt to communicate with
   that IP address. This attack is more difficult to mount (than the
   polling attack described above) and it is not obvious what benefit it
   would provide the active attacker. Alice has only initiated a
   connection to an IP address. If she is not speaking to the real Bob,
   she will discover this and break the connection. So the active
   attacker cannot prove she intended to speak to Bob; merely that she
   initiated an IPsec connection to a particular IP address.

   2.3 Plausible Deniability

   This feature enables Alice and Bob to communicate, leaving no ability



Harkins, Kaufman, Kivinen, Kent, Perlman                        [Page 4]


INTERNET DRAFT                                             February 2002


   for anyone to prove that they did have a conversation, even with the
   collusion of one of the parties. Alice does indeed sign a message
   proving she is Alice, but she does not sign Bob's name or IP address.
   The only thing she signs that belongs to Bob is his nonce, but anyone
   could have generated that nonce. It is sent in the clear, and so the
   fact that Bob generated that nonce certainly does not imply that
   nobody else could have generated that nonce. The fact that Alice
   carried on an IPsec connection with someone that used that nonce does
   not prove she talked to Bob.

   In the first draft of IKEv2, we had Alice sign the entire contents of
   messages 1 and 2. This meant that all fields would be integrity
   protected, either through Alice's signature (and Bob also signed both
   messages), or through the integrity protection that all packets
   beyond the first two automatically had through IKE's integrity
   protection. Sara Bitan suggested a modification so that each side
   only signs the fields it generates, plus the other side's nonce. This
   still protects all fields, either through Bob's signature or Alice's.
   It also makes it more obvious that the protocol provides plausiable
   deniability.  Some people argue that having Alice additionally sign
   Bob's Diffie-Hellman value proves she talked to Bob, because only Bob
   can produce the private exponent associated with that Diffie-Hellman
   number. However, all it proves is that Alice talked to someone who
   presented that Diffie-Hellman number. The fact that Bob knows the
   private exponent does not mean that it was Bob. Instead, it could be
   someone else that told Bob the Diffie-Hellman parameters.

   2.4 Cookies

   Although in [PK01] we explained how to effect a stateless cookie
   exchange without adding messages (by having Alice repeat, in message
   3, what she said in message 1, in IKEv2 we chose to have Bob request
   stateless operation with an extra round trip, so the exchange in this
   case would be 6 messages. The reasons for this:

   - Having the message be 4 exchanges does not come for free. Repeating
   everything in message 3 makes message 3 longer.

   - Message 3 is likely to be large (it can contain Alice's
   certificate).  If message 3 needs to be fragmented, then Bob cannot
   be stateless. He has to reassemble message 3 before he can determine
   if the cookie is correct. Therefore, it was simpler to ensure that
   all the messages before Bob starts needing to keep state are
   sufficiently small as not to require fragmentation.

   2.5 Cryptographic Negotiation

   In IKEv2, Alice proposes a set of potential cryptographic algorithms,



Harkins, Kaufman, Kivinen, Kent, Perlman                        [Page 5]


INTERNET DRAFT                                             February 2002


   and Bob chooses. Why is it necessary to negotiate? Why not let one
   side or the other choose? Suppose IPsec just agreed upon a particular
   set of cryptographic algorithms, and, say, Bob told Alice what
   cryptographic algorithms to use. The problem with this is that if the
   world ever wanted to phase in a new cryptographic algorithm, there
   would be no way to do it until Bob could be assured that all the
   clients had upgraded to support it.

   In SSL, cryptographic negotiation is based on complete suites rather
   than, as in IKEv1, individually negotiating each cryptographic
   algorithm. In the first draft of IKEv2 we cleaned up the syntax
   somewhat to avoid exponential explosion if many of one type of
   algorithm can work with any of a number of choices for some other
   type of algorithm. We argued on the list and during the meeting for
   moving towards suites.

   We considered switching over to suites in this draft of IKEv2, but we
   got a surprising amount of feedback that people prefer negotiating
   individual algorithms. Since there was no compelling reason to
   change, and most opinions we heard were in favor of individual
   algorithm negotiation, we kept it the way it was. If there were
   working group consensus to move to suites, we would be delighted to
   make the change.

   3.0 Changes in this version of the draft

   Very little needed to be changed from the previous draft of IKEv2.
   In this section we describe the changes we considered making, but
   decided against, and the changes we did decide to make.

   3.1 Changes we considered and rejected

   We considered making the following changes, but decided against them:

   - negotiating cryptography with suites rather than individual
   algorithms

   - changing the encoding to "type of this payload" rather than "type
   of next payload". We find the "type of next payload" harder to
   understand, and if we had been laying out the packet formats from
   scratch, we would have argued for that encoding. However, there is no
   compelling reason in terms of compactness or parsing efficiency to
   change it, and one of our stated goals in IKEv2 was not to make
   "gratuitous changes" so that implementers might be able to reuse
   code. This change would have been totally a subjective preference.

   - changing to an exchange that allows Bob to have stateless operation
   and still have the exchange fit within 4 messages. As we explained



Harkins, Kaufman, Kivinen, Kent, Perlman                        [Page 6]


INTERNET DRAFT                                             February 2002


   above, we decided the exchange was better the way it is; 4 messages
   with an extra round trip if Bob wants Alice to return his stateless
   cookie before the exchange begins in earnest. It seemed like fitting
   within 4 messages in this case was only motivated by "bragging
   rights", and the downside was making message 3 bigger all the time,
   and the issue that if message 3 is sufficiently large to need
   fragmentation, then Bob would not be able to do stateless operation.

   - adding in Bill Sommerfeld's "birth certificate" idea. In this idea
   Bob keeps a number in nonvolatile memory that increments each time
   the node restarts. When Bob restarts, he signs a "birth certificate"
   stating what the value of that counter is. This birth certificate is
   transmitted as a payload in message 4. Alice keeps this value. If Bob
   ever receives an ESP packet that doesn't decrypt properly or with an
   unknown SPI, he responds to that packet with his birth certificate.
   If the recipient has an SA for Bob with an older birth certificate,
   this lets them know Bob has restarted and forgotten state for that
   SA. We decided not to add that to this version of the draft, although
   we think it is a good idea, until it's been written up in a separate
   draft and there has been an opportunity for people to understand it
   and give feedback.

   - adding an option of having Bob include, in message 2, a signed g^b
   value, his name (in the clear), and his certificate. This is the JFK
   [Aie01] idea, and our motivation for considering it was to come up
   with a document that incorporated good ideas from everyone. If this
   would have resulted in a single document, we felt it was worth doing,
   but technically it seemed like adding this as an option would add
   more complexity than any functionality gained. As explained in the
   section on identity hiding, if a choice were made to do one mechanism
   or the other, we felt the IKEv2 mechanism that avoided a polling
   attack and hid both identities from passive attackers was preferable.

   - Some people suggested that our choice of the name IKEv2 was
   unfortunate for two reasons. Some people thought it was
   "presumptious" to call it IKEv2 when there were other contenders.
   However, at the time, Dan Harkins was tasked to come out with a
   cleaned up and document-merged version of IKEv2. The other contenders
   appeared simultaneously with the IKEv2 draft.  Other people thought
   the name was unfortunate because many people concluded, without even
   looking at the draft, that anything named IKEv2 would just be
   patching IKEv1, and everyone agreed that IKEv1 was terminally
   complex. The confusion was exacerbated by naming the document the
   same name (The Internet Key Exchange) as IKEv1, so many people
   couldn't even find "IKEv2" listed in the drafts.  We considered
   changing the name, but given that the only cute name any of the
   authors could come up with was "DOI" (daughter of IKE), and given
   that IKEv2 by now had "brand recognition", we decided to stick with



Harkins, Kaufman, Kivinen, Kent, Perlman                        [Page 7]


INTERNET DRAFT                                             February 2002


   the name IKEv2. However, we changed the title of the draft to
   "Proposal for the IKEv2 Protocol".

   3.2 Changes we decided to make

   - We added support for preshared keys. Many people were against
   preshared keys because they were so awkwardly supported in IKEv1.  In
   particular, in main mode, the ID had to be the IP address in order
   for Bob to look up the relevant key and decrypt Alice's identity. And
   they assumed that having multiple authentication methods was one of
   the reasons IKEv1 became so complex. However, other people like the
   performance advantage and configuration ease of preshared keys. Given
   the structure of the IKEv2 exchange, it was trivial to support
   preshared keys, and in a way that allowed arbitrary identities. The
   only change is that the proof of identity, instead of being a
   signature on what you sent plus the other side's nonce, becomes an
   HMAC of the preshared key with what you sent plus the other side's
   nonce.

   - We added the option of having Alice specify, in message 1, Bob's
   identity. This facilitates having multiple services co-located at an
   address. The idea had come up before, and was suggested in [Ker01].
   This did require us to explicitly say that this field, if present,
   should be excluded from what Alice signs.

   - We added explicit instructions for the syntax of integrity
   protection and encryption rather than pointing to the syntax in the
   ESP spec. Our laziness in the first draft of IKEv2 caused confusion
   because people assumed there was some dependency of IKEv2 on ESP.
   [Note from CWK: I would characterize this as an attempt to minimize
   redundant specification rather than laziness, but in any case it is
   now fixed].

   - We changed what each side signs to be what they send in the first
   pair of messages (minus Bob's name, if Alice sends that), plus the
   other side's nonce.

   - We added the ability to provide IDs in phase 2, so that IKE can set
   up process-to-process IPsec SAs.

   - We believe IKEv2's switch from random message IDs to sequence
   numbers, and changing the cookies to recipient-specified SPIs fixes
   the reflection and replay attacks in IKEv1. However, just because it
   is "good cryptographic hygiene", we computed different cryptographic
   keys in the two directions of the IKE-SA.

   - We added the nonces into the SKEYSEED_a, SKEYSEED_d, and SKEYSEED_e
   stew. Again this is "good cryptographic hygiene", and certainly is at



Harkins, Kaufman, Kivinen, Kent, Perlman                        [Page 8]


INTERNET DRAFT                                             February 2002


   least as good as what was there. It might count as a "gratuitous
   change", and can be changed back to what it was with minimal effort.
   This addition was suggested by Tero Kivinen.

   - We allow the port number of the other end to be something other
   than 500, so that the protocol would work through NAT.

   - We made some clarifications. We noted that the INITIAL-CONTACT
   message should affect SAs only from the same IP address. We specified
   the order of the fields, as being required to always be in the same
   order.  We specified that, after rekeying, the sequence numbers start
   again at 1.

   - All previous proposals (IKEv1, IKEv2, JFK, and SIGMA) were
   vulnerable to an active attacker answering Alice's message with bogus
   information.  Alice cannot distinguish a legitimate message 2 from a
   bogus message 2.  In this draft we explain how Alice can protect
   herself from this attack, which is to be willing to continue
   negotiation with every reply she receives. Only the legitimate Bob
   will be able to send an acceptable message 4, so the multiple SA's-
   in-progress will only last until the SA is set up.


    [Aie01]  Aiello, W., Bellovin, S., Blaze, M., Canetti, R.,
             Ioannidis, J., Keromytis, A., Reingold, O.,
             "Just Fast Keying (JFK)", draft-ietf-ipsec-jfk-00.txt

    [Bra96]  Bradner, S., "The Internet Standards Process --
             Revision 3", BCP 9, RFC 2026, October 1996.

    [Har01]  Harkins, D., Kaufman, C., and Perlman, R., "The Internet
             Key Exchange (IKE) Protocol, draft-ietf-ipsec-ikev2-00.txt

    [Ker01]  Keromytis, A., and Sommerfeld, B., "The 'suggested ID'
             extension for IKE, draft-keromytis-ike-id-00.txt.

    [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.





Authors' Addresses

   Dan Harkins
   dharkins@tibernian.com



Harkins, Kaufman, Kivinen, Kent, Perlman                        [Page 9]


INTERNET DRAFT                                             February 2002


   Tibernian Systems

   Charlie Kaufman
   ckaufman@notesdev.ibm.com
   IBM

   Tero Kivinen
   kivinen@ssh.fi
   SSH Communications Security Crop
   Fredrikinkatu 42
   FIN-00100 Helsinki
   Finland

   Stephen Kent
   kent@bbn.com
   BBN Corporation

   Radia Perlman
   radia.perlman@sun.com
   Sun Microsystems































Harkins, Kaufman, Kivinen, Kent, Perlman                       [Page 10]