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

Re: replay attack issue in locator updates ?

Hi Seb

sorry for the delay

Sébastien Barré escribió:

Hi Marcelo,

Thanks for your fast answer ! See my comments below.

marcelo bagnulo braun schreef:

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

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). 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. 
I think
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.