[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Avoiding tricking IKE v2 nodes into talking v1



On Tue, 27 Aug 2002 23:20:54 EDT you wrote
> 
> > 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.

Good point. I actually think that what people actually use is Main Mode
but if it won't work in both then it isn't a solution.

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

I cannot see an argument for a bilingual implementation to negotiate IKEv1
first because there might be some broken code out there that does something 
that is not specified in IKEv1 and you admit is unwise. People that do
unwise things that are also not required/recommended/otherwise in the spec 
should be put into the position of fixing their code.

But now that we're into "what if"s: What if an implementation refuses 
negotiation when it receives a crypto algorithm it does not understand? 
That too is not a wise thing to do but I can see how someone might've 
thought that was a good idea. In fact, I saw it happen at a bakeoff.

Since the vendor ID thing won't work another solution to this (if a 
solution is necessary) is to say that when an IKEv2 capable implementation
speaks IKEv1 that the nonce it produces have a recognizable pattern in 
first N bits. If an IKEv2 capable implementation was speaking IKEv1 and
the nonce it received from the peer had the proscribed pattern the attack
would be detected. The nonce can be 8-256 bytes in IKEv1 so there is plenty
of room to have both a fixed pattern and some randomness. This is sort of 
like the cute solution Radia was talking about in SSL. Of course, there are 
those implementations out there that crash when they receive a nonce whose 
length is greater than 20 bytes....

  Dan.