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]