Re: Avoiding tricking IKE v2 nodes into talking v1

[Dan Harkins <dharkins@tibernian.com>]

  The complaint about IKEv1 is that it is too complex and hard to
understand, not that it is insecure. So I don't see falling back
to IKEv1 as a real problem. 

  If something really has to be done I suggest we come up with an 
IKEv1 "vendor ID" payload that says something like "I can actually 
speak a higher version of IKE". This payload would be sent in the 
5th and 6th message in Main Mode or the 2nd and 3rd in Aggressive 
Mode. Most implementations can handle "vendor ID" payloads in these 
parts of the exchanges.

  Regarding your question about an IKEv1 implementation that crashes 
or worse if they receive an IKEv2 IKE_SA_init message, while the
IKEv1 spec does not proscribe such behavior it also doesn't explicitly
prohibit it (another area in which it is vague) but I'd argue that
any implementation that crashed (or worse) for any reason is broken.
There was a very popular IP stack that used to crash when it received
the "Christmas Tree" packet (all options, lights, bells and whistles
turned on). That wasn't a problem with IP, it was a problem with that
implementation. Similarly with IKEv1, if it crashes upon receipt of
unexpected input it's not a problem with the protocol it's a problem
with the implementation.

  Dan.

On Sat, 24 Aug 2002 21:19:21 EDT you wrote
> 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
>