RE: history and why does IKE need a successor

["Stephane Beaulieu" <stephane@cisco.com>]

Hi Ricky,

Leaving all the history stuff aside, I believe that SOI will (hopefully)
offer more than IKEv1++ (IKEv1 + proprietary extensions that make it
useable) does today.

Let's assume that we could finally get agreement on the following for IKEv1:
- remote access
- DPD / Keepalives / Heartbeats
- rekeying
- Continuous Channel mode vs. dangling
- NAT traversal
- INITIAL-CONTACT / Birth Certificates
- etc...

I think we'd probably still need to at least have a new mode (Base Mode,
Hybrid, CRACK, etc...) to solve other issues that can't be solved without
major changes to IKEv1.

Once you cram all the things listed above in IKEv1, it starts to look a heck
of a lot like IKEv2 (except of course for the controversial remote access
issues).

However, things like DoS protection can't easily be put in IKEv1 without
making new modes (and then more or less rewriting much of your code anyway).
Identity protection is another issue that comes to mind that may not fit
well into IKEv1.

I fully understand where you're coming from... if, once we nail down the
requirements, we decide that any new additions can be reasonably easily
inserted into IKEv1, then I fully agree with you.  However, I don't think
the requirements will fall that way.  At least not the kind of requirements
I'm hoping to get...

Stephane.

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of
> rcharlet@SonicWALL.com
> Sent: Tuesday, June 18, 2002 7:39 PM
> To: ipsec@lists.tislabs.com
> Subject: history and why does IKE need a successor
>
>
> 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) whe!
> n !
> 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