[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Avoiding tricking IKE v2 nodes into talking v1
On Mon, 26 Aug 2002, Dan Harkins wrote:
> KINK should be using a different port than IKEv*
It does (or should or will):
"9. Transport Considerations
KINK uses UDP on port [XXX -- TBA by IANA] to transport its
messages.
"
I assume "TBD by IANA" means != UDP 500.
jan
> and PF_KEY is an
> internal issue which should have no impact on the protocol. A good
> reason to limit ourselves is that we've gone down that road before
> and we decided to turn around and try another route. One of the reasons
> IKEv1 is so complicated is the desire for it to not limit itself. We all
> now almost universally agree that was a mistake.
>
> Dan.
>
> On Mon, 26 Aug 2002 13:02:36 EDT you wrote
> > This message is in MIME format. Since your mail reader does not understand
> > this format, some or all of this message may not be legible.
> >
> > ------_=_NextPart_001_01C24D21.DCB83256
> > Content-Type: text/plain;
> > charset="iso-8859-1"
> >
> > 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
> > [mailto:Radia.Perlman@sun.com]
> > 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
> >
> >
> > ------_=_NextPart_001_01C24D21.DCB83256
> > Content-Type: text/html;
> > charset="iso-8859-1"
> > Content-Transfer-Encoding: quoted-printable
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > RE: Avoiding tricking IKE v2 nodes into talking v1
> >
> > It is an great idea to have the ability to state what = version you are capab
> >le of supporting, I would suggest extending the = concept to a byte level to p
> >rovide the ability to state what other = method you can support for key manage
> >ment 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 message
> >s
> > 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
> > ------_=_NextPart_001_01C24D21.DCB83256--
> >
> > --=====================_449718591==_.ALT
> > Content-Type: text/html; charset="us-ascii"
> >
> > Approved: Dob.ipsec
> > >From majordomo-owner Mon Aug 26 12:48:30 2002
> > Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [19
> >2.94.214.100])
> > by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id MAA27390
> > Mon, 26 Aug 2002 12:48:30 -0400 (EDT)
> > Received: by sentry.gw.tislabs.com; id NAA10536; Mon, 26 Aug 2002 13:03:08 -0
> >400 (EDT)
> > Received: from zcars04e.nortelnetworks.com(47.129.242.56) by sentry.gw.tislab
> >s.com via smap (V5.5)
> > id xma010528; Mon, 26 Aug 02 17:02:28 GMT
> > Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]
> >)
> > by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g
> >7QH2eb11285;
> > Mon, 26 Aug 2002 13:02:40 -0400 (EDT)
> > Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
> > id <RL838W4Z>; Mon, 26 Aug 2002 13:02:44 -0400
> > Message-ID: <4D79C746863DD51197690002A52CDA00029BD8D1@zcard0kc.ca.nortel.com>
> > From: "Marc Desrosiers" <mdesros@nortelnetworks.com>
> > To: "'Radia Perlman - Boston Center for Networking'" <Radia.Perlman@sun.com>,
> > ipsec@lists.tislabs.com
> > Subject: RE: Avoiding tricking IKE v2 nodes into talking v1
> > Date: Mon, 26 Aug 2002 13:02:36 -0400
> > MIME-Version: 1.0
> > X-Mailer: Internet Mail Service (5.5.2653.19)
> > Content-Type: multipart/alternative;
> > boundary="----_=_NextPart_001_01C24D21.DCB83256"
> >
> > This message is in MIME format. Since your mail reader does not understand
> > this format, some or all of this message may not be legible.
> >
> > ------_=_NextPart_001_01C24D21.DCB83256
> > Content-Type: text/plain;
> > charset="iso-8859-1"
> >
> > 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
> > [mailto:Radia.Perlman@sun.com]
> > 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
> >
> >
> > ------_=_NextPart_001_01C24D21.DCB83256
> > Content-Type: text/html;
> > charset="iso-8859-1"
> > Content-Transfer-Encoding: quoted-printable
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > RE: Avoiding tricking IKE v2 nodes into talking v1
> >
> > It is an great idea to have the ability to state what = version you are capab
> >le of supporting, I would suggest extending the = concept to a byte level to p
> >rovide the ability to state what other = method you can support for key manage
> >ment 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 message
> >s
> > 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
> > ------_=_NextPart_001_01C24D21.DCB83256--
> >
> > --=====================_449718591==_.ALT--
> >
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
http://www.eff.org/cafe