Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt

[Sten Carlsen <[e-mail]>]

On 27/06/14 14:25, Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>>  > => synchronization allows to offer a smaller window.
>> On the contrary. Synchronisation allows me(the attacker) to change
>> the victim's time to suit my replay.
> 
> => I don't follow you again. What is the victim (client or server)?
> And BTW can you detail one attack example?
Ok, let me be more explicit (or try).

The way I understand this is:

- In order to make communication more secure, time settings in the two
ends need to be "close enough"
- To make sure the time settings are synchronised, you want to introduce
a synchronisation step at the beginning of the communication, then time
settings will be close enough
- Now communication can proceed using time as part of the transaction


If I want to attack the end that needs to be synced, here is my plan:
- Start the synchronisation procedure, but set time to fit the replay
attack I have in mind. This could be weeks away from today's time
(depending on the synchronising procedure)
- After this step, the remote end has a completely different time than
what it should be.
- Now I should have a much easier task making a replay attack, any
reference to the time set will be correct as I have set the clock in the
victim to match my attack.

This is not a specific attack as I don't have one at hand, what I see is
that the fact that I can set the time in my victim to be exactly what I
like it to be, must offer me a broader choice of attack options. This is
what I don't like about the proposal.

I possibly missed something here, please help me understand why it helps
communication but does not help attacks to be able to set any
"appropriate" time in the victim.

I would see this as one more tool in my hand.

> 
> Regards
> 
> [e-mail]
> 

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"