Re: Avoiding tricking IKE v2 nodes into talking v1

[Jan Vilhuber <vilhuber@cisco.com>]

On Mon, 26 Aug 2002, Paul Koning wrote:

> >>>>> "Dan" == Dan Harkins <dharkins@tibernian.com> writes:
>
>  Dan> The complaint about IKEv1 is that it is too complex and hard to
>  Dan> understand, not that it is insecure. So I don't see falling back
>  Dan> to IKEv1 as a real problem.
>
>  Dan> If something really has to be done I suggest we come up with an
>  Dan> IKEv1 "vendor ID" payload that says something like "I can
>  Dan> actually speak a higher version of IKE". This payload would be
>  Dan> sent in the 5th and 6th message in Main Mode or the 2nd and 3rd
>  Dan> in Aggressive Mode. Most implementations can handle "vendor ID"
>  Dan> payloads in these parts of the exchanges.
>
> But vendor ID payloads don't announce any protocol action, they only
> set a namespace for subsequent private payloads.  You can only have
> one at a time

Where does it say this? I see no reason why you couldn't have 15
vendor-id payloads in message 5 or 6 (or anywhere else for that
matter).

Also, I don't see why a vendor-id is narrowly defined as "set a
namespace for subsequent private payloads" (unless I missed a section
in the IKE spec). I see them as announcing any capability you like,
with or without additional private payloads.

Using the vendor-id make a lot of sense to me (modulo the "it's not
authenticated" bit).

jan


>, so this approach wouldn't work if someone is already
> using the vendor ID payload for some other purpose.
>
>  Dan> Regarding your question about an IKEv1 implementation that
>  Dan> crashes or worse if they receive an IKEv2 IKE_SA_init message,
>  Dan> while the IKEv1 spec does not proscribe such behavior it also
>  Dan> doesn't explicitly prohibit it (another area in which it is
>  Dan> vague) but I'd argue that any implementation that crashed (or
>  Dan> worse) for any reason is broken.
>
> Exactly.  I don't see any reason for the IKE spec to say that.  This
> rule is true for every protocol.  If you crash because of something
> you received, you're broken, end of discussion.  One could put that
> statement in every protocol spec but it would just be duplicating a
> statement of the obvious...
>
> 	  paul
>
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

http://www.eff.org/cafe