Subject: replay attack issue in locator updates ?

From: Sébastien Barré <[email-masked]>
Date: Thu, 11 Sep 2008 15:59:25 +0200

Hi,

While reading rfc4218, I realized that I'm not sure that locator update 
messages in the Shim6 protocol are protected against replay attacks 
(section 4.1.4 of rfc 4218).
What I observed is that a nonce mechanism is used (successfully) to 
protect session initiation messages. Next, the same kind of mechanism is 
used to protect locator updates, but it seems to me that it cannot work 
in that case.

The principle used in the Shim6 protocol regarding the use of nonce, in 
a request/response scheme, is that the requester picks a random number 
that is copied back by the responder inside the answer. This protects 
the answer against replay attacks, not the request. And it is completely 
right so (usually), since the answer is the one that contains critical 
information.

Here comes the difference between initiation messages and locator 
updates. During initiation locators are sent as responses (with a copied 
nonce). But during locator updates, locators are sent during the 
request, which opens the following attack scenario IMO :

* A starts a Shim6 exchange with B
* Some time later it sends a locator update to B. This works well, 
except that the update is simply remembered by X, an attacker.
* even later, a second update is sent from A to B, which invalidates all 
previous locators, and announces others. This also works well.
* Now X decides to replay its remembered locator update. B has no reason 
to reject that packet, thus it will update it's locator set back to the 
invalid locator set. It can thus not talk to A anymore.
Because the packet was accepted by B, B will send back an ack to A, but 
A will either not receive it, or receive it and ignore it, because the 
ack *is* protected by the nonce, and the nonce is not longer valid.

Now, looking further at the mechanisms, I found that there is some 
possible protection available without modifying the protocol, and that 
is due to a good side effect of locator list generation number. This one 
is incrementally updated for each new list, and it is part of the CGA 
signature. Thus if the receiver of an update request (B above) simply 
checks that the received generation number is greater than it's previous 
one (and within some reasonable window), it will be able to drop 
replayed messages.

Note that this does not work if HBA is used. In that case, no signature 
is present and the attacker simply needs to replace the generation 
number before to send it. But this does not seem a too big concern, 
since the user has the option between more efficiency (hba) or more 
security(cga).

Thus, maybe I missed something, but if i didn't it may be worth adding 
some paragraph in the draft (section 10.4 - receiving update request 
messages) telling that in case the request holds a locator list, the 
generation number MUST be checked to be greater than the previously 
stored one and within some window (size of which to be thought about). 
If the provided generation number does not fall into that window, then 
it is probably a replay and the packet MUST be silently dropped (or an 
error message sent ?).

Can anybody here (still up and following the list :-) ) give some 
opinion about this ?

thanks,

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 11 Sep 2008 17:00:02 +0200

Hi Seb,

from the security considerations section of the shim6 proto spec

   o  Every control message of the Shim6 protocol, past the context
      establishment, carry the context tag assigned to the particular
      context.  This implies that an attacker needs to discover that
      context tag before being able to spoof any Shim6 control message
      as described in section 4.4 of [15].  Such discovery probably
      requires to be along the path in order to be sniff the context tag
      value.  The result is that through this technique, the Shim6
      protocol is protected against off-path attackers.

So, i agree with you, an on path attacker can launch such attack, but 
this has been a design tradeoff
The protocol is not designed to provide protection against on path 
attackers for this case

Regards, marcelo

Sébastien Barré escribió:
> Hi,
>
> While reading rfc4218, I realized that I'm not sure that locator 
> update messages in the Shim6 protocol are protected against replay 
> attacks (section 4.1.4 of rfc 4218).
> protect session initiation messages. Next, the same kind of mechanism 
> is used to protect locator updates, but it seems to me that it cannot 
> work in that case.
>
> The principle used in the Shim6 protocol regarding the use of nonce, 
> in a request/response scheme, is that the requester picks a random 
> number that is copied back by the responder inside the answer. This 
> protects the answer against replay attacks, not the request. And it is 
> completely right so (usually), since the answer is the one that 
> contains critical information.
>
> updates. During initiation locators are sent as responses (with a 
> copied nonce). But during locator updates, locators are sent during 
> the request, which opens the following attack scenario IMO :
>
> * even later, a second update is sent from A to B, which invalidates 
> all previous locators, and announces others. This also works well.
> * Now X decides to replay its remembered locator update. B has no 
> reason to reject that packet, thus it will update it's locator set 
> back to the invalid locator set. It can thus not talk to A anymore.
> Because the packet was accepted by B, B will send back an ack to A, 
> but A will either not receive it, or receive it and ignore it, because 
> the ack *is* protected by the nonce, and the nonce is not longer valid.
>
> is due to a good side effect of locator list generation number. This 
> one is incrementally updated for each new list, and it is part of the 
> CGA signature. Thus if the receiver of an update request (B above) 
> simply checks that the received generation number is greater than it's 
> previous one (and within some reasonable window), it will be able to 
> drop replayed messages.
>
> Note that this does not work if HBA is used. In that case, no 
> signature is present and the attacker simply needs to replace the 
> generation number before to send it. But this does not seem a too big 
> concern, since the user has the option between more efficiency (hba) 
> or more security(cga).
>

---

From: Sébastien Barré <[email-masked]>
Date: Thu, 11 Sep 2008 17:54:49 +0200

Hi Marcelo,

Thanks for your fast answer ! See my comments below.

> The protocol is not designed to provide protection against on path 
Yes I understand that it was a non-goal to get protected against MITM 
attacks. But looking at the draft, I thought that it was a goal to 
protect against replay attacks. In particular, there is this paragraph :
 o  The context establishment messages use nonces to prevent replay
      attacks as described in section 4.1.4 of [15], and to prevent off-
      path attackers from interfering with the establishment.

Of course a replay attack can be performed by the end-host itself or by 
some external attacker. But it seems like section 4.1.4 of rfc4218([15]) 
makes more sense if the attacker is not the end host, because if he 
were, his attack would be against himself.

I see this kind of replay attack as weaker than pure MITM in that the 
attacker only needs to see one packet. For example, in a wireless 
environment, it may be easy to catch some or many packets, but not to 
actively enter in the middle of the communication between A and B.

Furthermore in several places, it seems like the protocol *is* protected 
against replays, in particular the establishment is well protected 
against replays thanks to nonces (as stated in the paragraph). This is 
what questioned me about why the locator updates would not benefit from 
the same protection as the establishment, especially if it costs only 
three assembly instructions or so to implement (as described in my 
previous mail).

Did I misunderstand something ?

Thanks,

Sébastien.

(small editorial note for the above paragraph : to be sniff -> to sniff. 
more can be found in mail from 12/2/08, entitled 'Draft reviews')
>> I think
>> protects the answer against replay attacks, not the request. And it 
>> is completely right so (usually), since the answer is the one that 
>> but A will either not receive it, or receive it and ignore it, 
>> because the ack *is* protected by the nonce, and the nonce is not 
>> longer valid.
>>
>> possible protection available without modifying the protocol, and 
>> that is due to a good side effect of locator list generation number. 
>> This one is incrementally updated for each new list, and it is part 
>> of the CGA signature. Thus if the receiver of an update request (B 
>> above) simply checks that the received generation number is greater 
>> than it's previous one (and within some reasonable window), it will 
>> be able to drop replayed messages.
>>
>> Thus, maybe I missed something, but if i didn't it may be worth 
>> adding some paragraph in the draft (section 10.4 - receiving update 
>> request messages) telling that in case the request holds a locator 
>> list, the generation number MUST be checked to be greater than the 
>> previously stored one and within some window (size of which to be 
>> thought about). If the provided generation number does not fall into 
>> that window, then it is probably a replay and the packet MUST be 
>> silently dropped (or an error message sent ?).
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 25 Sep 2008 16:48:49 +0200

Hi Seb

sorry for the delay

>      path attackers from interfering with the establishment.

but the point is that the session establishement is a critical part, 
while the locator update seems less critical
I mean, suppose your host leave the location and a new host gets 
attached to that address, it could then using a replay attack, hijack 
the host identity.

Other way to see t would be this one:
suppose you are on path, and you can see the shim6 exchange, is there 
anything you can do? since they are protected by HBA CGA you can't 
change the locators nor the identifier
All you can do is a replay attack

Suppose you are an on path attacker, and you see the update message flying
Actually, if you see that, the replay attack is the less interesting 
thing you can do as an attacker sicne once you learn the CT you don't 
need to reply, you can generate the updates you want. the point is that 
that attack is not something that was deemed critical to secure, since 
the assumption is that we are not protecting against on path attackers

Makes sense?

regards, marcelo

> Of course a replay attack can be performed by the end-host itself or 
> by some external attacker. But it seems like section 4.1.4 of 
> rfc4218([15]) makes more sense if the attacker is not the end host, 
> because if he were, his attack would be against himself.
>
> Furthermore in several places, it seems like the protocol *is* 
> protected against replays, in particular the establishment is well 
> protected against replays thanks to nonces (as stated in the 
> paragraph). This is what questioned me about why the locator updates 
> would not benefit from the same protection as the establishment, 
> especially if it costs only three assembly instructions or so to 
> implement (as described in my previous mail).
>
> (small editorial note for the above paragraph : to be sniff -> to 
> sniff. more can be found in mail from 12/2/08, entitled 'Draft reviews')
>>
>> Regards, marcelo
>>
>>
>>> protect session initiation messages. Next, the same kind of 
>>> mechanism is used to protect locator updates, but it seems to me 
>>> that it cannot work in that case.
>>> I think
>>> generation number before to send it. But this does not seem a too 
>>> big concern, since the user has the option between more efficiency 
>>> (hba) or more security(cga).
>>>

Delivery-date: Thu, 25 Sep 2008 14:50:58 +0000
Date: Thu, 25 Sep 2008 16:48:49 +0200
From: marcelo bagnulo braun <[email-masked]>
To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
CC: [email-masked]
Subject: Re: replay attack issue in locator updates ?

Hi Seb

sorry for the delay

>      path attackers from interfering with the establishment.

but the point is that the session establishement is a critical part, 
while the locator update seems less critical
I mean, suppose your host leave the location and a new host gets 
attached to that address, it could then using a replay attack, hijack 
the host identity.

Other way to see t would be this one:
suppose you are on path, and you can see the shim6 exchange, is there 
anything you can do? since they are protected by HBA CGA you can't 
change the locators nor the identifier
All you can do is a replay attack

Suppose you are an on path attacker, and you see the update message flying
Actually, if you see that, the replay attack is the less interesting 
thing you can do as an attacker sicne once you learn the CT you don't 
need to reply, you can generate the updates you want. the point is that 
that attack is not something that was deemed critical to secure, since 
the assumption is that we are not protecting against on path attackers

Makes sense?

regards, marcelo

> Of course a replay attack can be performed by the end-host itself or 
> by some external attacker. But it seems like section 4.1.4 of 
> rfc4218([15]) makes more sense if the attacker is not the end host, 
> because if he were, his attack would be against himself.
>
> Furthermore in several places, it seems like the protocol *is* 
> protected against replays, in particular the establishment is well 
> protected against replays thanks to nonces (as stated in the 
> paragraph). This is what questioned me about why the locator updates 
> would not benefit from the same protection as the establishment, 
> especially if it costs only three assembly instructions or so to 
> implement (as described in my previous mail).
>
> (small editorial note for the above paragraph : to be sniff -> to 
> sniff. more can be found in mail from 12/2/08, entitled 'Draft reviews')
>>
>> Regards, marcelo
>>
>>
>>> protect session initiation messages. Next, the same kind of 
>>> mechanism is used to protect locator updates, but it seems to me 
>>> that it cannot work in that case.
>>> I think
>>> generation number before to send it. But this does not seem a too 
>>> big concern, since the user has the option between more efficiency 
>>> (hba) or more security(cga).
>>>

Delivery-date: Thu, 11 Sep 2008 15:55:32 +0000
Date: Thu, 11 Sep 2008 17:54:49 +0200
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked]
Subject: Re: replay attack issue in locator updates ?

Hi Marcelo,

Thanks,

Sébastien.

Delivery-date: Thu, 11 Sep 2008 15:01:02 +0000
Date: Thu, 11 Sep 2008 17:00:02 +0200
From: marcelo bagnulo braun <[email-masked]>
To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
CC: [email-masked]
Subject: Re: replay attack issue in locator updates ?

Hi Seb,

Regards, marcelo

> Can anybody here (still up and following the list :-) ) give some 

Delivery-date: Thu, 11 Sep 2008 14:01:01 +0000
Date: Thu, 11 Sep 2008 15:59:25 +0200
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To: [email-masked]
Subject: replay attack issue in locator updates ?

Hi,

thanks,

Sébastien.