IPSEC Working Group INTERNET-DRAFT Radia Perlman draft-ietf-ipsec-ikev2-tutorial-00.txt February 2003 Understanding IKEv2: Tutorial, and rationale for decisions 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. 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. 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