Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol



On 11/20/14, 6:10 PM, "Christian Huitema" <huitema@xxxxxxxxxxxxx> wrote:

>> Basically a MAC address can be constructed as:
>>
>> MAC_i_t = H(cipher_suite, public_key, time_t, nonce_i)[0:6]
>>
>>     With H being a cryptographic secure hash like SHA256
>
>You can do that, but I would not claim much security from the construct.
>When it comes to cryptography, 48 bits make really small numbers.

48-bits is only the address.  The above constructs assume that all devices
have a longer term Id (128 bits) and public key that is used as part of
the authentication process.

It is possible for a malicious device to create a public key and nonces
that would hit a particular 48-bit MAC address.  Once authenticated it
would be clearly identified as a different device than expected by it¹s
having a different public key.  Collisions would be expected, but rare and
would be clearly identifiable.

>Attackers who want to target a specific MAC could search 2^48
>combinations of key, time and nonce and find collisions reasonably
>rapidly. In fact, they could probably pre-compile dictionaries.

Yes - but the MAC addresses change fairly often and are not used for
identification.
>
>I am worried about the potential of denial of service with address
>collision detection. Protocols like IPv6 duplicate address detection can
>trivially be hacked that way. Upon broadcast of "does anyone use address
>X" message, the attacker quickly proceeds to install that address on
>their NIC, and responds "yes." And yes, and yes, and yes. The target
>never manages to get a validated address.

Yes, if based on unauthenticated broadcast messages.  If you tie the
duplicate detection to the authentication process it becomes much harder
to prove that you have a conflict since you could be made to show the
forced collision.

Paul


>
>The hash constructs provide some protection against such attacks, but it
>is not a very strong protection. In the absence of such strong
>protection, we are probably better off with no conflict detection at all,
>if the probability of collision is low enough and the concern with DOS
>attacks high enough.
>
>-- Christian Huitema