Re: Choosing between IKEv2 and JFK

[Ran Canetti <canetti@watson.ibm.com>]

Looking back at the note that started this thread, it seems that Eric 
corretly identified the main differences between the two protocols. 
In a nutshell, the JFK approach prefers a lean and simple protocol, that is
easier to code, deploy, and analyze, at the price of somewhat limited 
functionality. IKEv2 maintains more of the functionality of IKEv1, at the 
price of additional complexity. No protocol totally dominates the other.
There are scenarios where each protocol fares better than the other. 

Anyway, when deciding between the two protocols for the next generation of
IKE, it may be good to keep in mind that IKEv1 will most probably be around
for a while (if not for good), living side-by-side with the next generation. 
Thus, it may be beneficial to have a next generation protocol that best 
matches the scenarios that IKEv1 doesnt. Here it seems to me that JFK
provides a good complement to IKEv1: If you want algorithm negotiation,
two-phase structure, pre-shared key mode (and are willing to pay the price)
then use IKEv1. If you want a leaner protocol and your particular 
application does not require these funtions then use JFK.


Ran


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