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

Re: Avoiding tricking IKE v2 nodes into talking v1



  KINK should be using a different port than IKEv* 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--
>