Choosing between IKEv2 and JFK

[Eric Rescorla <ekr@rtfm.com>]

INTRODUCTION
The WG milestones say that we're supposed to select an IKE-replacement
protocol design in April so it's probably time to start thinking
about this now. Although neither of the leading contenders is
completely nailed down, the direction they're heading is clear
enough that we should be able to pick a winner at MSP or shortly
thereafter. 

In the interest of reaching a decision, here are my top 5 differences
between IKEv2 and JFK. I attempt to discuss each issue a bit but I'm
not taking sides here, just trying to elucidate the relevant
differences in a single document.

	(1) Algorithm Negotiation
	(2) 2-phase handshake
	(3) Management messages
	(4) Non-public-key authentication
	(5) DoS protection

Note that I've deliberately not mentioned the cryptographic core, for
two reasons:

(1) The cores are actually quite similar.
(2) Both groups seem perfectly willing to adapt a different
core if that's what the WG group wants. (In fact, JFKr adopts
SIGMA's core). 

In my view, the important differences between JFK and IKEv2 are in the
stuff that surrounds the cryptographic core, rather than the core
itself.


ALGORITHM NEGOTIATION
IKEv2 follows a fairly traditional approach to algorithm negotiation.
The initiator offers the algorithms he's happy with and the
responder selects among them. This is the same general approach
used by TLS.

JFK uses two different approaches, one for negotiating protection
of the rest of the handshake and one for the IPsec traffic to be
protected. The handshake protection algorithms are not negotiated--the
responder simply chooses and the initiator can take it or leave it
(with the exception of the DH group, which is proposed by the
responder and chosen by the initiator).  The traffic protection
negotiation is conceptually similar to that of IKEv2, with some
simplifications: namely that it uses cipher suites instead of
proposals and has a simplified traffic selector model. The former was
proposed (but rejected) by the IKEv2 authors.

Discussion:
I'm not sure how relevant this difference is in practice. There's been
a lot of discussion of JFK not negotiating, but that really only
applies to the handshake-protection algorithms. SA algorithms are
negotiated in JFK, just as in IKEv2, albeit with a rather simpler
negotiation model. It would be easy to graft IKEv2's negotiation model
onto JFK (especially since JFK's negotiation is somewhat
underspecified in the spec), or alternately, to simplify IKEv2's
negotiation so it looks more like JFK's. [0]


2-PHASE HANDSHAKE
[This section refers only to keying material establishment. 
The next section discusses the use of phase II for management
traffic.]
IKEv2 uses the same two-phase approach as IKE. The peers first
negotiate an SA for protecting the rest of the handshake (the IKE SA)
and then negotiate a second SA for protecting traffic. The idea
here is that you might want to use different SAs for different
traffic flows but don't want to perform a new DH exchange for
each SA establishment. Once you have the "IKE SA" established
you can use that to create other SAs for individual traffic flows.
In order to minimize round trips, you can establish a single
traffic SA at the same time as you establish the IKE SA.

JFK does not have two phases. If you want multiple SAs you do
multiple JFK handshakes. The rationale is as follows.

   We also feel that JFK is efficient enough that avoiding the overhead
   of a full key exchange is not required.  Rather than add new SAs
   to an existing Phase I SA, we suggest that a full JFK exchange
   be initiated instead.  We note that the client can also choose
   to reuse its exponential, it if wishes to trade perfect forward
   secrecy for computation time.

Discussion:
This ultimately comes down to performance: is it too expensive to
perform a new exchange for each traffic flow or not? Although JFK is
lighter weight than IKEv2, the reduced complexity is largely in
protocol processing, not cryptography. Extensive experience with SSL
performance tuning suggests that the vast majority of the time in both
JFK and IKEv2 will be in the cryptographic computations, which are
essentially identical.

The question, then, is whether IPsec implementations need to
negotiate a lot of different SAs for any given set of peers or
not. In principle this is an empirical question, but I don't
know if we have enough deployment experience to decide one way
or the other. 


MANAGEMENT TRAFFIC
Aside from child SA creation, IKEv2 allows a number of other
messages to be transmitted in Phase II, using the IKE SA. These
messages are primarily for management purposes including:

	(1) Dead peer detection
	(2) Rekeying
	(3) Deletion

JFK doesn't have a Phase II and uses separate and somewhat ad 
hoc mechanisms for each of these:

        (1) Dead peer detection is done with pings.
	(2) Rekeying and deletion are both done via a new
	    SA exchange (you delete by offering a zero lifetime).

Discussion:
The right approach really depends on how much is going to be done in
the Phase II exchange. Any individual one of these tasks can be
performed by other mechanisms (though JFK SA deletion is
clumsy). However, if we want all three features, it may be better to
simply write them into the protocol rather than develop ad hoc
techniques for each one. 


NON PUBLIC-KEY AUTHENTICATION
IKEv2 supports both public key authentication and shared-key based
authentication.

JFK supports only public key authentication, with the expectation that
they will be supported via some outboard protocol.

Discussion:
As we've seen from mailing list traffic, this is an incredibly
controversial issue. Despite our best efforts to the contrary,
legacy authentication systems which support/use shared keys
aren't going away any time soon and I'm not sure that there's
any point in standing athwart history yelling "Stop". 


DoS PROTECTION and COOKIE EXCHANGE
IKEv2 uses a variable-round-trip handshake, with 4 messages 
under normal circumstances and 6 under attack. The extra
two messages are a simple cookie exchange designed to force
the attacker to prove that he has a round-trip to the responsder.

JFK uses 4 messages in all cases. DoS protection is achieved by
not creating JFK state until message 3 has been read.

Discussion:
Both protocols are resistant to DoS attacks based on computational
loading. JFK is slightly more network efficient under attack because
it has two fewer messages. However, it is more susceptible to an IP
fragmentation memory consumption attack where the attacker sends a
series of partial messages to consume reassembly buffers, thus
blocking delivery of legitimate fragmented message 3s.  If one assumes
a rather intimate relationship between IKEv2 and the TCP stack, IKEv2
is less susceptible to this attack.


FINAL COMMENTS
Although neither IKEv2 nor JFK is completely finished, I think it's
clear enough what direction they're following to choose which protocol
we're going to pursue. I've attempted to list what I consider to
be the major technical (as opposed to stylistic) differences between
the two protocols. If people feel that I've missed some important
difference, please point it out and I'll try to cover that as well.

-Ekr



[0] Incidentally, why does JFK have two different sets of algorithms? It
seems like life would be simpler if the algorithms used for traffic
protection were the same as those used for the handshake. I suppose
one might complain if the SA negotiated message integrity only but
I can't see that peers who don't care about confidentiality care about
identity protection.