RE: Avoiding tricking IKE v2 nodes into talking v1

["Marc Desrosiers" <mdesros@nortelnetworks.com>]

RE: Avoiding tricking IKE v2 nodes into talking v1

It is an great idea to have the ability to state what = version you are capable of supporting, I would suggest extending the = concept to a byte level to provide the ability to state what other = method you can support for key management to accommodate things like = KINK, PF_KEY, others. Why limit ourselves...

Marc DesRosiers

-----Original Message-----
From: Radia Perlman - Boston Center for = Networking
[<3d.htm>mailto:Radia.Perlman@sun.com]<= /FONT>
Sent: Saturday, August 24, 2002 9:19 PM
To: ipsec@lists.tislabs.com
Subject: Avoiding tricking IKE v2 nodes into talking = v1

In IKEv2, we were careful to specify how to safely = negotiate
new versions in the future. There's a bit in v2 = saying "I could be
speaking a higher version number". That way if = two version 3 nodes
are attempting to talk, and an attacker (or Maxwell) = throws away the
version 3 messages, and the nodes try to talk = version 2 instead,
they will know they could be speaking a higher = version, and try again
with version 3.

But since the IKEv1 spec didn't have any such bit, we = assumed there
was nothing we could do about the possibility of two = v2 nodes being
tricked into talking v1. But then I noticed the = feature in SSL
that cleverly manages to have SSLv3 nodes talk = SSLv2, but recognize
that they could be speaking v3, in a way that didn't = require any
modifications to v2 (it's amazingly cute how they do = it).

Inspired by SSL, it seems like it might be nice to = find some hack
so that IKE version 2 capable nodes won't get = tricked into talking IKEv1.
Currently the v2 spec says that you try to talk v2, = and if you don't
get a response, you try talking v1.

The IKEv1 spec is not very explicit about things like = how to handle
receipt of nonzero reserved bits (it says "must = be zero",
but doesn't say "must be ignored upon = receipt"). Otherwise, we could
use a reserved bit in IKEv1 similar to what we = defined in IKEv2.

But given that it looks like it might be dangerous to = fool with reserved
bits in v1, is there some other method that would be = guaranteed not to
upset any current implementations?

One thing I could imagine is defining a dummy crypto = algorithm. When
the initiator proposes that algorithm, it means = "I'm sending you v1 messages
since you didn't answer my v2 messages, but I am = capable of speaking
v2". If Bob speaks v2 and gets an IKE_SA_init = from Alice with that
dummy crypto algorithm, I'd suggest that Bob should = choose that dummy
crypto algorithm, which tells Alice "let's = start over with v2". Alice
then should abort the v1 IKE, and start up again = with a v2 IKE.

What do people think? Is there a more elegant way of = doing this?
Is it not worth the work?

Also, while I'm asking...would any IKEv1 = implementations crash or
do something possibly even worse if they receive an = version 2 IKE_SA_init?
I assume they either reject or ignore such messages, = because otherwise
it would be a trivial denial of service attack on = IKEv1.

Radia