Re: [Iotops] [Madinas] advice on IoT MAC address randomization (or not)

[Juan Carlos Zuniga <[e-mail]>]

We have added some information about OS current practices in the latest version of:

https://datatracker.ietf.org/doc/html/draft-zuniga-mac-address-randomization-01

Juan Carlos

From: Madinas <[e-mail]> On Behalf Of Tim Cappalli
Sent: July 15, 2021 1:10 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [Madinas] advice on IoT MAC address randomization (or not)

Just a clarification: Apple does not rotate MAC addresses every 24 hours (as of iOS 14 and macOS 12). They assign a MAC address on initlal connection to an ESSID, the same as Google implemented in Android 10.

Windows has the option for daily rotation, but it is an opt in feature.

________________________________
From: Michael Richardson <[e-mail]<mailto:[e-mail]>>
Sent: 2021-07-15 10:42
To: Alan DeKok <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Madinas] advice on IoT MAC address randomization (or not)


Alan DeKok <[e-mail]<mailto:[e-mail]>> wrote:
    > On Jul 14, 2021, at 3:24 PM, Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:
    >> I think that a BCP document on IoT devices, including routers,
    >> switches and other infrastructure would be good.

    > I agree.

    >> The short of it, for me, is that
    >> a) wired interfaces for non-movable things (home gateways, fridges,
    >> furnaces) should not change their MAC address.  (Whether they use
    >> OUI derived addresses is a second question)
    >>
    >> b) Until WPA-Enterprise aka EAP-TLS,.. is ubiquitous among wifi IoT
    >> devices, that they should always use the same MAC address for the
    >> same ESSID.

    > It's probably fine to change it periodically.  Right now, IIRC it's 24
    > hours for most vendors.

No, just Apple rotates on 24hr basis at this point.  Others could start.
The reason they do this has to do with the visibility of the MAC address,
even when encrypted (see below).

Others have said that they support the same MAC on the same ESSID.
See the madinas slides from the BOF.

    >> Combining (a) and (b), I'm fine if wired devices that do 802.1x want to do
    >> RCM.  That would apply to many security paranoid enterprise
    >> desktops/laptops.  But, I don't think that the IDS systems will be ready for
    >> a long time, as they mostly haven't caught up to IPv6 Temporary addresses yet.

    > If devices do 802.1X, then the authenticator can already identify the
    > device.  The question then is which part of the network should be seen
    > as untrusted?

If they are doing 802.1X, then the authenticator, when it authenticates the
device, already knows how to tell the network about the policy for the MAC
address (whether permanent or dujour).
That's the point we need to get to for all devices that wish to do RCM.
Networks that aren't using 802.1X do not necessarily have that mechanism.
This means 95% of home networks.

    > If the device is roaming, then it makes sense to hide it's identity
    > from the visited network.  It's also useful to hide the device identity
    > on public WiFi frames.  But once 802.1X is done, the link to the AP is
    > secure.  And the device usually might as well use it's own, physical
    > MAC address.

No, that's not true.

The MAC address part of the frame is not encrypted by wifi, only the payload.
In many encryption modes, the MAC address is used as part of the input to the
CTR, Nonce or IV (depending upon mode), such that two devices with the same
(WEP) key don't produce packets that are identical when encrypted.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]<mailto:[e-mail]>  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Ctim.cappalli%40microsoft.com%7C88a1636683ac467bbe6c08d9479ec449%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637619569525845289%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ApBsRqrPLeOiPK38EfXrt%2BJK2A7TWzkhZfD734Mv3uo%3D&amp;reserved=0<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&data=04%7C01%7Cjuancarlos.zuniga%40sigfox.com%7C04bc5353ada646b2891c08d947b374d9%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637619658353488841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ln9mXdmHiMMH38vFm06fkDJ92iJACOs8bIZNrPJ%2BBHo%3D&reserved=0>        |   ruby on rails    [




--
Michael Richardson <[e-mail]<mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide