[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

IPSEC Working Group INTERNET-DRAFT
Radia Perlman


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


       Understanding IKEv2: Tutorial, and rationale for decisions
                <draft-ietf-ipsec-ikev2-tutorial-01.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
   difficult 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.




Perlman                                                 [Page 1]


INTERNET DRAFT                                             February 2002


1. 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, which were not
   documented in the base documents. 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 in IKEv1
   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 intention 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.

   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 is the initiator of the
   exchange. These names allow us to use the pronouns "she" and "he".

2.0 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 usually consists of two request/response pairs.
   (Additional request/response pairs might be needed for DOS
   protection, if Alice attempts to use a Diffie-Hellman group Bob does
   not support, or if Bob will authenticate Alice through some legacy
   mechanism such as a token card, OTP, or name/password.

   The first pair negotiates cryptographic algorithms and does a
   Diffie-Hellman exchange.  The second pair is encrypted and integrity



Perlman                                                 [Page 2]


INTERNET DRAFT                                             February 2002


   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.

3.0 Two Phases

   In IKEv2 terminology, the first phase consists of the (usually 4)
   messages that create the IKE-SA and the first associated IPsec SA
   (known as a "child-SA"). Once the IKE-SA is created, it can be used
   for sending authenticated notification messages, reliable dead-peer
   detection, and inexpensive creation of additional child-SAs.

   It was argued in [PK01] and [JFK] that having two phases was
   unnecessary and added complexity, and additional SAs between the same
   pair of nodes could be accomplished by creating additional IKE-SAs.
   However, child-SA creation is less expensive, and experience with
   IKEv1 showed the two phases to be useful, since there were scenarios
   in IPsec deployments in which a sufficient number of child-SAs
   between the same pair of nodes was desirable that the extra spec
   complexity was worth it for the efficiency of child-SA creation.

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



Perlman                                                 [Page 3]


INTERNET DRAFT                                             February 2002


   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.

   * 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] it was argued that
   all traffic might as well be protected according to the needs of the
   traffic that requires the strongest protection. The counter-argument
   is that 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 that 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 that are
   discarded. If different classes of service have widely different
   delivery times, the recipient would have to keep track of a larger,
   and possibly unbounded, set of sequence numbers.

   In JFK it was envisioned that IKE would be used solely for setting up
   an SA, and there would be no IKE messages other than the initial
   handshake. In IKEv1, the second phase was used either for setting up
   an additional SA or for sending informational messages.  Once the WG
   consensus was to keep the two phase structure, both uses of the
   second phase; creation of new child-SAs, and the ability to send
   reliable and authenticated informational messages were deemed
   important. The ability to send informational messages increases
   IKEv2's robustness by detecting error conditions, allowing rekeying,
   and detecting a dead peer, as well as being a potentially valuable
   feature for future functionality.

   Note that the ability to create additional child-SA's is optional in
   IKEv2, so it is legal for an implementation to have the behavior
   envisioned in the JFK spec.

4.0 Perfect Forward Secrecy/Computation Tradeoff

   The IKEv2 handshake includes nonces in addition to Diffie-Hellman



Perlman                                                 [Page 4]


INTERNET DRAFT                                             February 2002


   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.

   Note that even if Bob (or Alice) reuses his Diffie-Hellman value
   (call it "B"), there will still be perfect forward secrecy so long as
   Bob forgets B as soon as any SA based on B is closed. If Bob
   remembers B for, say, an hour longer than that, then perfect forward
   secrecy is only slightly affected, and really not affected in any
   practical sense.

5.0 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. The name is
   quite appropriate because in the same message in which Alice reveals
   her identity she requests a specific identity for Bob.

6.0 DOS protection

   Photuris specified a mechanism known as a "stateless cookie", in
   order to avoid a certain type of DoS attack. The attack involves
   sending nuisance SA-creation-request packets to a server (Bob) from
   an unauthorized node with the purpose of exhausting the server's
   computation or memory resources. Such attacks typically are sent from
   forged source addresses, both to avoid prosecution and to make it
   difficult for these packets to be easily filtered. Photuris's cookie
   design was a way of assuring Bob that the SA-requester could receive
   at the IP address it claimed to be coming from before Bob devoted
   significant resources to authenticating the request and creating the
   SA.

   A method of implementing stateless cookies is for Bob to have a
   secret S, that he shares with nobody and changes periodically.  When
   he gets a request from IP address x with no cookie, he sends
   cookie=h(S,x) to x, but otherwise does nothing with the request. When
   he gets a request from IP address x with cookie=c, Bob verifies if



Perlman                                                 [Page 5]


INTERNET DRAFT                                             February 2002


   c=h(S,x) and if so, continues processing. (If Bob has recently
   changed S's, he might want to see if the cookie verifies with the old
   S if it fails with the new S).

   OAKLEY had the stateless cookie be optional. If there was no attack,
   the protocol would avoid the extra round trip for the cookie
   exchange. If Bob was getting low on resources, perhaps because of an
   attack, Bob could refuse requests that didn't contain a cookie.
   IKEv2 uses the OAKLEY idea of having the cookie exchange be optional.

   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 the OAKLEY-style optional extra round trip. It was
   possible, (as specified in JFK, suggested in [PK01], and specified in
   the next version of IKEv2 after the JFK and IKEv2 author teams
   decided to work together on a single document), 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. With the variant in which
   Bob is stateless until verifying message 3, (and it is message 3 in
   which Alice sends the cookie), an attacker could send fragments,
   exhausting Bob's reassembly resources, so that Bob's IKE would never
   get to see and verify the cookie. With the extra two messages for
   cookie exchange, all messages are sufficiently short so that



Perlman                                                 [Page 6]


INTERNET DRAFT                                             February 2002


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

7.0 Cryptographic Negotiation

   In IKEv1, 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 somewhat.  Also,
   the exponential explosion of proposals was avoided by allowing sets
   of algorithms that could interwork together to 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 offering one
   or more suites and having the other side choose.  It was assumed this
   would be a noncontroversial decision, but unfortunately it turned out
   to be 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.




Perlman                                                 [Page 7]


INTERNET DRAFT                                             February 2002


   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.

8.0 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. Even if the endnode has an
   IP address for where it is currently residing in the Internet, it may
   need an address specific for the network inside the firewall, since
   with its IPsec tunnel, the endnode will now be logically inside the
   firewall.  There were two proposed methods of doing this:

   * MODECFG, which involves a field in the IKE exchange in which Bob
   tells Alice an IP address, and

   * DHCP-relay, which involves running DHCP over IKE or over an ESP
   connection set up specifically for this purpose.

   The appeal of MODECFG is that it is very simple, and 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 that might be
   defined in the future) and does so in a way that appears to make it
   independent of the IKE specification. One thing that can be done with
   DHCP-relay is end-to-end authentication between the client and the
   DHCP server, for instance.

   The use of MODECFG does not preclude the use of tunnelled DHCP for
   uses other than acquiring leases on IP addresses, and 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 even though DHCP-relay was more complex than MODECFG, if
   doing MODECFG meant implementations had to support both, doing DHCP-
   relay instead of MODECFG would mean less implementation effort.
   However, the decision was that for now, since MODECFG was simpler,
   higher performance, fully specified, and gave all currently-needed
   functionality, IKEv2 would assign addresses using MODECFG.


9.0 NAT Traversal

   People love to hate NAT (Network Address Translation) gateways, but
   they are a fact of life in the Internet. NAT-Traversal [KSH01]
   designed a mechanism that was deployed in IKEv1, and IKEv2 copied the
   design. The NAT-Traversal design accommodated existing NATs as much
   as possible (without sacrificing security or significantly impacting
   performance).



Perlman                                                 [Page 8]


INTERNET DRAFT                                             February 2002


   NATs were originally invented primarily because of the shortage of
   IPv4 addresses, though there are other rationales. IP nodes that are
   "behind" a NAT have IP addresses that are not globally unique, but
   rather are assigned from some space that is unique within the network
   behind the NAT but which are likely to be reused by nodes behind
   other NATs.  Some people consider the fact that the nodes in their
   network cannot be directly addressed from outside a security feature.
   And it even allows a network using some addressing scheme different
   from IPv4 to connect to the Internet.

9.1 The games NATs play

   Generally, nodes behind NATs can communicate with other nodes behind
   the same NAT and with nodes with globally unique addresses, but not
   with nodes behind other NATs.  When a node behind a NAT makes a
   connection to a node on the real Internet, the NAT gateway assigns
   the inner node a global IP address (which the Internet will route to
   the NAT box), keeps the mapping for the duration of the conversation
   (where "duration" has to be heuristically determined by the NAT box),
   and modifies the IP addresses in the header appropriately.  For
   outgoing packets, the NAT box modifies the source address. For
   incoming packets, the NAT box modifies the destination address to be
   the address of the node on the internal network.

   If the NAT box does not have a sufficiently large pool of global IP
   addresses to hand out a unique one to each node inside its net that
   is communicating outside, then NAT boxes translate based on UDP or
   TCP ports. This is known as a NAPT box.

   NAPT boxes are foiled by ESP, because ESP encrypts the layer 4
   header.  Some NAPT boxes attempted to make ESP work by doing the
   following (assume the NAPT box has only one globally unique address,
   "C"):

   * when it sees an ESP packet from inner node IP address A to outer
   node IP address B, the only extra information is the SPI=x. So the
   NAPT box rewrites the source address A to C, and keeps track of the
   fact that an ESP packet came from A recently, and there is no current
   mapping for an incoming SPI corresponding to x.

   * when the NAPT sees an ESP packet from B to C, with an SPI=y that
   the NAPT has no mapping for, it assumes B is really trying to respond
   to A, and makes a mapping that (C,y)=A.

   An additional problem with NATs and IKEv1 is that IKEv1 specified
   that IKE messages must be sent to port 500, and sent from port 500.
   If IKEv1 had specified that you initiate by sending to 500, but
   respond to whatever port you received an IKE packet from, things



Perlman                                                 [Page 9]


INTERNET DRAFT                                             February 2002


   would have been simpler. But NAPTs, understanding IKE will want both
   source and destination UDP ports to remain as 500 make a special case
   for packets on UDP port 500. If the ports are 500, the NAPT does not
   modify the UDP ports. Instead, the NAPT makes mappings based on the
   what used to be called the "cookie fields" in the IKEv1 payload (and
   in IKEv2 are called the SPIs).

   The way it works is that when the NAPT box sees a packet on port 500,
   it looks at the SPI pair (ci,cr). If it does not yet have a mapping
   for that pair, the packet will have to be coming from inside the net,
   from IP address A, to IP address B. The NAPT box makes a mapping that
   IKE connection (ci,cr) is for node A. The box does not modify the UDP
   ports or the IKE SPIs. It merely records the SPI pair for its IP
   address mapping. Outgoing packets from A to that IKE connection will
   always get translated as having source address C. But incoming
   packets to C from that SPI pair will get translated to destination
   address A.

   In the beginning of the IKE connection, Bob has not yet chosen a SPI,
   so the SPI pair will be (ci,0). If two nodes from inside the net
   initiate IKE connections to Bob simultaneously, and both choose
   SPI=ci, the NAPT would not be able to differentiate.  But since SPIs
   are 8-bytes long, and recommended to be chosen at random, this is
   unlikely to happen.

9.2 NAT detection

   NAT-Traversal was designed for enabling IKEv1 to work through NATs
   without requiring modifications of the NATs, and IKEv2 has pretty
   much copied the design. The first step is for Alice and Bob to notice
   that one of them is behind a NAT. In IKEv2 this is done by including
   two notify payloads in messages 1 and 2, called NAT-DETECTION-
   SOURCE-IP and NAT-DETECTION-DESTINATION-IP. These notify payloads
   consist of a one-way hash of the IP address and port. The reason it
   is a hash rather than the actual address is because some people have
   argued that the actual address of a node behind a NAT might be
   secret. Given there are only 32-bits in an IP address and the port is
   known to be equal to 500, it is possible to do a brute force search
   and discover the actual IP address, but having the payload convey the
   hash rather than the actual address is at least a nuisance to someone
   that would want to find the address.

   Mysteriously, the NAT-DETECTION payloads are ignored by Bob. However,
   if Alice notices a discrepancy between the IP addresses in the header
   of the received message 2, and the hashes in the payloads, she
   reverts to NAT behavior.





Perlman                                                [Page 10]


INTERNET DRAFT                                             February 2002


9.3 So, you're behind a NAT. What do you do?

   In NAT-mode, packets on a child-SA (e.g., ESP packets) are sent with
   UDP encapsulation. This means that instead of indicating the ESP
   header with an IP header protocol type (and having the ESP header
   immediately following the IP header), the IP header will indicate
   "UDP", and the presence of the ESP header will be indicated by using
   port 4500 in the UDP header.

   NAPTs do not do any special-case processing with port 4500 (as they
   do with port 500). So, if there is a packet from internal node A to
   B, with UDP header, and ports 4500, and no mapping on the NAPT box
   yet for A, the NAPT box will make a mapping from A to (IP address C,
   port x), and overwrite the IP source address to C and the UDP source
   port to x. When Bob receives a packet to port 4500 (indicating IPsec
   UDP encapsulation), Bob responds to the port from which it was
   received, so will respond to IP address C, port x. When the NAPT box
   receives this packet from Bob to (C,x), it will translate the IP
   address from C to A, and the port from x to 4500.

   In addition to sending the child-SA packets on 4500, IKE (once the
   NAT is detected) sends the remaining messages of the IKE handshake
   over port 4500 instead of 500 (and does not insist on receiving them
   from source port 4500). Using port 4500 for IKE wasn't strictly
   necessary but had some advantages:

   * It enables the NAPT box not to do special case processing for IKE,
   and instead modify the UDP ports (as it would with anything else)
   instead of relying on the IKE SPIs, which was a somewhat fragile and
   very complex mechanism,

   * It winds up creating fewer mapping entries in the NAPT box, since
   the same port mapping for UDP-encapsulated child-SA packets will work
   for the IKE exchange. (i.e., there is no need to keep mappings for
   IKE cookie pairs).

   * Since NAT boxes are only using heuristics for how long to keep a
   mapping, if there were a different mapping for IKE than for the
   child-SA, it could be that the NAT would forget the UDP port mapping
   for the child-SA, but remember the IKE-SA cookie mapping. This would
   be bad because dead peer detection is done by sending IKE
   informational messages, which would indicate the SA was alive, but
   child-SAs would go into a black hole because the NAT box would no
   longer know how to map packets from B to A.

9.3 Encoding both IKE and ESP with port 4500

   The mechanism for this encoding was copied from [HSSVC].  If a NAT is



Perlman                                                [Page 11]


INTERNET DRAFT                                             February 2002


   detected, ESP packets will be sent with UDP encapsulation, using port
   4500. Also, IKE packets will be sent to port 4500. How can the
   receiving end distinguish between an ESP packet and an IKE packet?

   In either case the packet will start with an IP header, with protocol
   type=UDP (17). Then there is a UDP header, with destination
   port=4500. After the UDP header is either an ESP packet or an IKE
   packet. The first 4 bytes of an ESP packet is the SPI, which is not
   allowed to be zero. So, to distinguish an IKE packet from an ESP
   packet, if it is an IKE packet, the first 4 bytes after the UDP
   header are 0, and then the IKE packet.

   With this encoding, the overhead for UDP encapsulation of ESP packets
   is minimized, and the extra 4 bytes of overhead is only on IKE
   packets, and there are not many of those (compared to data packets).

10.0 Identity Hiding


   Some people argue that identity hiding is an exotic feature that
   cryptographers put into IKEv1 just because they could. In many cases,
   such as those where nodes are at a fixed IP address, the identity is
   not hidden.

   And, there are different flavors of identity hiding. IKEv2 does
   identity hiding of both parties from passive attackers.

   In theory (and in IKEv1) one could 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. (But in fact,
   in IKEv1, this was too strong an assumption, and identities with the
   in-theory identity-hiding secret key protocol required, in practice,
   that the identities be the IP addresses.) Additionally, having n
   different protocols for slightly different security properties in
   IKEv1 was deemed to be too complex for any benefit it gained, so
   IKEv2 only supports public signature keys and pre-shared keys.

   However, with public signature keys, one side or the other has to
   reveal its identity first (before the other side has proven its
   identity). Whichever side reveals its identity first, if it is
   talking to an active attacker, it will have revealed its identity to
   that attacker.  In [PK01] it was argued that it was more important to
   protect the identity of the initiator, since in the client-server



Perlman                                                [Page 12]


INTERNET DRAFT                                             February 2002


   model, the server would be at a fixed IP address and would not have a
   hideable identity.  However, Charlie Kaufman later argued 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 WG's decision was that they did not want to limit
   IPsec's use to a strict client-server mode.

   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 difficult to mount and it is not
   obvious what benefit it would gain 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.

11.0 Legacy Authentication


   Alice might be a human, without a public key pair or a shared
   cryptographic key. She might be using a token card (such as
   SecureID), or a password.

   There were several proposed extensions to IKEv1 for providing legacy
   authentication [XAUTH], [CRACK], [EAP]. Given they were all
   technically acceptable, one had to be chosen.  The EAP protocol
   [EAP], designed within the pppext WG, was adopted for IKEv2.

   To use EAP with IKEv2, Alice, in message 3, reveals her identity, but
   does not put in a certificate or an authentication payload.  Bob, in
   message 4, reveals and proves his identity, and specifies what type
   of legacy authentication he wants, along with a text string to be
   displayed at the client end (such as "this is your challenge for your
   challenge/response token"). Alice can respond as Bob requests, or can
   NAK and suggest a different type of EAP authentication.  The IKEv2
   spec really just references the EAP specification, so the design and
   the types are defined within EAP. In IKEv2, mostly for illustrative
   purposes, 3 of the EAP types are mentioned; MD5-Challenge, OTP, and
   generic token card. In MD5-Challenge, the client must compute the



Perlman                                                [Page 13]


INTERNET DRAFT                                             February 2002


   response, and not just mirror the text string. For OTP, depending on
   whether the implementation is based on human-with-paper or client-
   computed hash, the client either just sends the string the user types
   or treats it as a password and hashes it n times. In the third type,
   the client displays the text string to the human, which responds by
   typing something (perhaps the display from the token card), and the
   client sends that string back to the server. If the server is
   satisfied, it responds with what would have been the 4th message in
   the IKE handshake, choosing the selectors and cryptographic
   algorithms for the child-SA. Additional exchanges are allowed, for
   instance, if the user mistypes the value and the server gives the
   user an extra chance.

12.0 References


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

      [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

      [HSSVC]  Huttunen, A., Swander, B., Stenbert, M., Volpe, V., and
   DiBurro, L.,
               "UDP Encapsulation of IPsec Packets", draft-ietf-ipsec-
   udp-encaps-06.txt,
               January 2003.

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

      [KSH01]  Kivinen, T., Stenberg, M., Huttunen, A., Dixon, W.,
   Swander, B.,
               Volpe, V., and DiBurro, L., "Negotiation of NAT-Traversal



Perlman                                                [Page 14]


INTERNET DRAFT                                             February 2002


   in
               the IKE", draft-ietf-ipsec-nat-t-ike-01.txt, October
   2001.


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

      [Orm96]  Orman, H., "The Oakley Key Determination Protocol", RFC
               2412, 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.

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

      [XAUTH]  Beaulieu, S., and Pereira, R., "Extended Authentication
               within IKE (XAUTH)", draft-beaulieu-ike-xauth-02.txt,
               October 2001.





Authors' Addresses


Radia Perlman
radia.perlman@sun.com
Sun Microsystems















Perlman                                                [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/