Subject: Re: possibility of a MAC randomization algorithm (was: Discussion of default-iids and MAC address randomization and RFC4941)

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Jun 2016 11:09:14 +0200

Hi,

About the possibility of a MAC randomization algorithm, regardless of 
being used in an IP address:

> we do not control whether MAC addr randomization algorithm is
> appropriate or if it is actually possible.

The algorithm output should be checked against the authoritative 
oui.txt, and not generate an existing OUI (organizationally unique id).

Is such an algorithm documented somewhere?

Alex

> is appropriate or if it is actually possible. Not true - or rather,
> it's mostly not true. The exact level of incorrectness depends on who
> "we" is. If "we" = "Apple", then that statement is completely false.
> If "we" = "Windows" or "we" = "Android" then it is only mostly false.
> If "we" = "Linux" it is almost certainly false unless the host is
> using binary-only drivers. * Wastes 18 bits of entropy: "wastes" how?
> What's the downside? * Interoperability problems: depends heavily on
> the link layer. It's not true that you can't recover from DAD
> failures using SLAAC, you can just pick another number and try
> again.
>
> Of course, there's nothing new in my position, just like there's
> nothing new in yours. I'd just like to make sure that nobody can
> later state that the people who objected to the document are no
> longer objecting :-)
>
> Cheers, Lorenzo
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 3 Jun 2016 18:55:33 +0000

On Friday, June 3, 2016 2:09 AM, Alexandre Petrescu wrote:
> 
> About the possibility of a MAC randomization algorithm, regardless of being
> used in an IP address:
> 

It is certainly possible, since it is shipping in Windows 10.

> The algorithm output should be checked against the authoritative oui.txt, and
> not generate an existing OUI (organizationally unique id).

There is a potential debate about that. What we are doing in Windows 10 is set the "local" bit to true, which means that the OUI does not apply.

> Is such an algorithm documented somewhere?

Mathy Vanhoef, PhD Student Computer Security at KU Leuven, wrote a nice blog containing such a description: http://www.mathyvanhoef.com/2016/03/how-mac-address-randomization-works-on.html

-- Christian Huitema

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 6 Jun 2016 15:44:58 +0200

Le 03/06/2016 à 20:55, Christian Huitema a écrit :
>> About the possibility of a MAC randomization algorithm, regardless
>> of being used in an IP address:
>>
> There is a potential debate about that. What we are doing in Windows
> 10 is set the "local" bit to true, which means that the OUI does not
> apply.

But, I understand the use of the u/l bit is no more desirable - it is 
part of an IID and the IID is opaque: RFC 7136 "Significance of IPv6 IIDs".

> Mathy Vanhoef, PhD Student Computer Security at KU Leuven, wrote a
> nice blog containing such a description:
> http://www.mathyvanhoef.com/2016/03/how-mac-address-randomization-works-on.html

Thanks for the pointer, that's useful indeed.

Whereas it does present an analysis on the algorithm, it could further 
be improved with the following aspects:

- it should work not only on WiFi but also on other links which dont
   have SSID but do have 48bit MAC addresses (e.g. cellular, USB,
   802.11p, others).  The described algorithm uses SSID in the SHA
   calculation.
- it should check a generated random MAC address does not clash with
   existing oui.txt assignments, otherwise it may involuntarily attack
   others (pretent to be someone else).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 Jun 2016 14:05:07 +0200

Hi,

Private discussion clarified a few points to me.

The referred to 'local' bit is the one in the MAC address, not the one
in the Interface ID.  So yes, I think that 'locally-administered' bit of
the MAC address should be set.  In IEEE speak, this means it's not
globally-unique.

1. in my oppinion, it is good that the Windows 10 sets that bit
    'locally-administered' while generating randomly the other 47bits.

2. However, I have seen recently a freely-available packet capture in
    which the source MAC address has the bit 'locally-administered'
    reset (so it's 'globally-unique'), and the OUI in that MAC address
    is absent from the oui.txt file.  Oui.txt is centralized and freely
    available on the web at IEEE.  I think the capture was on a computer
    that is not Windows, because of other reasons.

Should all MAC randomization algorithm implementations take the Windows
10 implementation as an example?

Other questions are:
- should one (re)set the unicast/multicast bit when generating a
   locally-administered (random) MAC address?  Or there is no
   relationship between the two?
- should one use something else than the ESSID in the generation
   algorithm? ESSID is found only on wifi, not on cellular and some
   cellular interfaces do have IEEE-assigned MAC addresses.
- should the MAC randomization algorithm check its output against the
   globally-unique OUIs in oui.txt to make sure there is no clash?

Yours,

Alex

Le 06/06/2016 à 15:44, Alexandre Petrescu a écrit :
>>> About the possibility of a MAC randomization algorithm,
>>> regardless of being used in an IP address:
>>>
>> There is a potential debate about that. What we are doing in
>> Windows 10 is set the "local" bit to true, which means that the OUI
>> does not apply.
>
> But, I understand the use of the u/l bit is no more desirable - it
> is part of an IID and the IID is opaque: RFC 7136 "Significance of
> IPv6 IIDs".
>
> Whereas it does present an analysis on the algorithm, it could
> further be improved with the following aspects:
>
> calculation. - it should check a generated random MAC address does
> not clash with existing oui.txt assignments, otherwise it may
> involuntarily attack others (pretent to be someone else).
>
> Alex
>
>>
>> -- Christian Huitema
>>
>>
>>
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 Jun 2016 19:03:12 +0000

On Monday, June 6, 2016 6:45 AM, Alexandre Petrescu wrote:
> But, I understand the use of the u/l bit is no more desirable - it is part of an IID
> and the IID is opaque: RFC 7136 "Significance of IPv6 IIDs".

RFC 7136 relates to IPv6 IIDs. We are looking at the MAC level addresses, and RFC 7136 does not really apply there -- IEEE 802 standards do. As of now, these IEEE 802 standards do not imply that the OUI is valid for locally administered addresses.

> ... 
> Whereas it does present an analysis on the algorithm, it could further be
> improved with the following aspects:
> 

Clearly, we started with Wi-Fi because it was the low hanging fruit. The algorithm is specific to Wi-Fi, in good parts because there are specific Wi-Fi requirements, such as not forcing your customers to buy a new hotel Wi-Fi connection every other day. Other media would have different requirements.

Cellular is a special case. Cellular connections are tied to cellular identities, e.g. IMEI. If you want randomization there, you have to do the equivalent of "replacing a SIM card". That's possible if you have a stack of valid SIM cards and pick one of them at random, but it is clearly not the same algorithm as slapping 48 random bits in a MAC address.

I do not know the constraints about 802.11p. There can very well be some severe constraints there, such as not changing the MAC Address when driving. That would require a separate study.

>    others (pretent to be someone else).

No. The local bit prevents that.

-- Christian Huitema

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Jun 2016 10:58:56 +0200

Le 07/06/2016 à 21:03, Christian Huitema a écrit :
>>>>> we do not control whether MAC addr randomization algorithm
>>>>> is appropriate or if it is actually possible.
>>>
>>>> The algorithm output should be checked against the
>>>> authoritative oui.txt, and not generate an existing OUI
>>>> (organizationally unique id).
>>>
>>> Windows 10 is set the "local" bit to true, which means that the
>>> OUI does not apply.
>>
> RFC 7136 relates to IPv6 IIDs. We are looking at the MAC level
> addresses, and RFC 7136 does not really apply there -- IEEE 802
> standards do. As of now, these IEEE 802 standards do not imply that
> the OUI is valid for locally administered addresses.

Yes, I agree.

If the bit locally-administered bit is set then the output may not
necessarily need to be checked against oui.txt.

The question is for MAC randomization algorithms which dont set that
bit.  The MAC randomization algorithm in Windows 10 algorithm does set it.

There are MAC randomization algorithms (non Windows) which dont set the 
local bit.

>> ... Whereas it does present an analysis on the algorithm, it could
>> - it should work not only on WiFi but also on other links which
>> dont have SSID but do have 48bit MAC addresses (e.g. cellular,
>> USB, 802.11p, others).  The described algorithm uses SSID in the
>> SHA calculation.
>
> Clearly, we started with Wi-Fi because it was the low hanging fruit.
>  The algorithm is specific to Wi-Fi, in good parts because there are
>  specific Wi-Fi requirements, such as not forcing your customers to
> buy a new hotel Wi-Fi connection every other day. Other media would
> have different requirements.

It makes sense.

> Cellular is a special case. Cellular connections are tied to cellular
> identities, e.g. IMEI.

YEs, but some cellular connections make use a MAC address assigned by
IEEE.  For example a USB LTE dongle from a particular manufacturer does
use a MAC address assigned by IEEE, in addition to the IMEI.

> If you want randomization there, you have to do the equivalent of
> "replacing a SIM card". That's possible if you have a stack of valid
> SIM cards and pick one of them at random,

Hmm, right.  But I am not proposing to randomize the IMEI and use a
stack of SIM cards - too expensive :-)

> but it is clearly not the same algorithm as slapping 48 random bits
> in a MAC address.

I think the same MAC randomization algorithm can be used for the MAC 
address on the cellular link (on cellular links which work with MAC 
addresses).

But it should use something else than SSID in the parameters of the 
function to generate the random number.  Maybe some parameter specific 
to the cellular link, similar to SSID.

> I do not know the constraints about 802.11p. There can very well be
> some severe constraints there, such as not changing the MAC Address
> when driving. That would require a separate study.

Hm, yes there are some specific requirements there.

Not changing the MAC address while driving could be a good requirement too.

But here I am thinking about the privacy requirement.

For example, the freely-available "Status of the DSRC Technology and 
Applications: Report to Congress", year 2015, says on its page 26 that 
"the BSM [a vehicle-specific message on top of 802.11p beaconed by every 
vehicle] contains no personally identifying information or information 
that could link a message directly to a driver, motor vehicle owner or 
the motor vehicle itself (such as VIN or license plate)".

The OUI in a globally-administered MAC address could be such 
information, because it reveals the manufacturer of the 802.11p card. 
And, this could help identify the brand of the motor vehicle, by means 
of various associations common in the car industry: e.g. because all 
Fords use Huawei cards (as they all use Bridgestone tyres) this BSM 
message means there is a Ford at this coordinate at this time.

So the requirement would be to use a random (although stable) MAC 
address in these BSM messages.

The other peculiarity in 802.11p is that there _is_ an SSID but it's 
always "ff:ff:ff:ff:ff:ff" - it's called the 'wildcard' SSID.  So, in 
this sense, the SSID would always be the same in the SHA-256 function 
parameter of your MAC randomization function.  This may be ok, or 
irrelevant, or superfluos, I dont know.

>> - it should check a generated random MAC address does not clash
>> with existing oui.txt assignments, otherwise it may involuntarily
>> attack others (pretent to be someone else).
>

I agree.

So the algorithm should set the local bit.  Algorithms who dont could 
check oui.txt.

Alex