history and why does IKE need a successor

[rcharlet@SonicWALL.com]

Howdy,

	This thread may be a bad idea, but I'm just curious...

	How did this working group come to the place where decided to replace IKE with something? As best as I can reconstruct history, it goes something like this...

	IKE was originally developed as a committee driven consensus product. This led to what some feel was an over inclusion of options. Field experience has since shown that some of the most confusion-causing options are rarely used. Peer review from security experts has taken IKE to task for its option explosion. Implementers have all struggled through the three cross-referential, non-terminology consistent, key management docs which force you through layer upon layer of options and thought to them selves "this could be better".

	All of the above forms only a general level of discontent which all participants were probably prepared to accept. No one was seriously thinking to them selves "I'll rewrite our key management protocol and show the world how it should be done" (except for a few nutty types who like to tinker with security protocols as their personal hobby. More on them later)

	But, while the level of discontent was at a safe equilibrium, there was another sub-plot brewing in the working group.

	Once upon a time there was a mulit-IETF meeting debate going on about how this working group should 'do' legacy authentication for remote access. VPN vendors wanted this feature because we were getting customer driven requests. The XAUTH proposal was earliest and became widely implemented. But 'non-consensus' in the working group centered around (probably invalid) arguments about its security properties, its efficiency properties, and its non-encouragement-of-PKI properties. Another VPN vendor entered a competing draft about how to do legacy auth. Dan Harkens entered a draft about how to do legacy auth in IKE directly. Some folks showed a way to use L2TP auth and IPsec for privacy only. Non-VPN IPsec'ers were asking why do this at all? PKI proponents were asking why do this at all? Debate was 'lively'. Interops showed XAUTH to work. A sub-working group was spun off to handle the question of the 'remote access scenario'. It came to a head at the Washington DC IETF (46th) when the working group was attempting to re-write its charter.

	At that meeting, the security ADs announced a policy of "no changes to IKE will be standards track". This effectively killed all current proposals and the working group found new chairs and recharted with this mandate in mind. It came up with two new, compliment proposals, PIC and GET-CERT, eventually picking PIC. But the "must not change IKE" policy also turned up that underlying discontent level a few notches and many folks 'questioned' the AD's wisdom on the matter.

	(now this next part I am most unsure about, I've probably got the principles all wrong. Please correct me gently)
	In the background, Kaufman and Perlman had been working on an SA and key management protocol which aimed to greatly reduce the numbers of options. They recruited Harkins to their efforts and presented a draft, IKEv2. In the background, Bellovin and Krawczyk, had been working on a key management protocol which aimed to greatly simplify key management in particular and did not really consider the question of SA management. They recruited several notables to their efforts and presented a draft, JFK. (Oh, and about that "nutty types" reference... I mean that only in jest and hold all these contributors in great respect. I'm quiet jeleous of their abilities).

	Neither of these drafts directly addressed the remote access debate. But since the possibility to 'change IKE' seems to be back on the table not many implementers are actually implementing PIC. Madson introduced a requirements draft which included a scenario about legacy auth based remote access. It appears that a successor to IKE may be allowed to address the largest remaining area of non-interoperability. But neither draft takes up this task yet and this was not the aim of any of the draft authors/contributers.

	So, where we stand now is that the market has solved the remote access problem by intrumenting with the only pragmatically available mechanisms XAUTH or L2TP over IPsec. We have a complicated protocol which is at great strains to do remote access user authentication from a radius or NT domain database. Yet this complicated and strained protocol is widely implemented in the market place. Both new IKE successor protocols are demonstrably more simple/efficient at authentication but neither directly solves a problem which IKE does not solve. 

	Both protocols may be more trustable from a security perspective. But trust is a fickle thing. They would have to be "more-trustable-enough" to overcome the distrust the market will have for anything new. That is a high standard to raise to.

	So why bother? What "Good Thing" will we write down on our brochures for customers about the IKE successor? Who would be interested in buying the IKE successor who would not be satisfied with IKE?




--

 Ricky Charlet     : rcharlet@sonciwall.com   : usa (408) 962-8711