Re: Avoiding tricking IKE v2 nodes into talking v1

[Charlie_Kaufman@notesdev.ibm.com]

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

I believe this would work.

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

I believe this would not work. Using IKEv1 in aggressive mode (which as I
understand it is what people actually use), vendor ID payloads are neither
signed nor integrity protected. That means anyone clever enough to get in
the middle to force a downgrade could also delete the vendor IDs
undetected.

> I wonder if the use Notification Payload (ISAKMP - 3.14) with a new
> Notify Message Type (some values were kept for future use) would work
> also. Is this payload in use in IKEv1 ? Or is it not related to IKEv1 ?

I don't believe this would work either. In IKEv1, Notification is not
reliable, so an attacker who deleted the Notify payloads would escape
detection.

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

It's not a question of the spec; it's a question of buggy implementations
(or even legal behavior that interacts badly with the new version). For
example, an implementation that gets an ill-formed UDP packet on port
500 might conclude that it is under attack and refuse all traffic from
the source IP address for 5 minutes. Probably not a wise thing to do,
but I can see how someone might have thought it was a good idea. If an
IKEv2 IKE-SA-init packet parses as bad and shuts the node off, that would
argue for a bilingual implementation trying to negotiate IKEv1 first.
If there were known buggy implementations that crashed on certain
invalid inputs, it's their fault, but we would be rude to specify such
a format in IKEv2. Unfortunately, I suspect there is no way to detect
such things except by testing, and by then it will be too late.

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

That's true, and argues for ignoring the problem. This is one of those
theoretical attacks that would rarely be useful, and the main
argument for preventing it is that we can. The argument against is
that it adds a couple more paragraphs to the spec, a little more
code to every implementation, and risks messing up existing buggy
implementations. I'd happily go either way (now I'm being the
donkey).

      --charlie