Subject: [Madinas] New version of Randomized and Changing MAC Address Use Cases was posted

From: "Lee, Yiu" <[email-masked]>
Date: Sun, 24 Oct 2021 15:29:24 +0000

Hi team,

We combed through the use cases draft document against the comments from the charter phase. Comments are welcome.

https://datatracker.ietf.org/doc/draft-henry-madinas-framework/03/

Thanks,
Jerome and Yiu

---

From: Hai Shalom <[email-masked]>
Date: Wed, 27 Oct 2021 16:34:32 -0700

Hello,

Thanks for posting the document. Here are my comments:

*Page 1:*

*Abstract:*

To limit the association between a device traffic and its user,

Missing text:
... and to protect the user from 3rd party tracking,

*Page 3:*

The
>    advantage of a universal address is that a node with such an address
>    can be attached to any Local Area Network (LAN) in the world with an
>    assurance that its address is unique.
>

Missing text:
... although the probability for a collision when using a locally
administered address is extremely low (1:2^46) and unlikely to happen.

for
>    example in the case of Authentication, Association and Accounting
>    (AAA) services authenticating the user of a machine and associating
>    the authenticated user to the device MAC address
>

How would RCM disrupt this service? An associated device does not change
its MAC address for the entire session and once the authentication is
successful, there is no disruption to the service. Additionally, if after
disconnection the device changes its MAC address and associates again, the
authentication will be successful since the client has the correct
credential.

*Page 5:*

As a device changes its network attachment (roams) from
>    one access point to another
>

... in the same Basic Service Set (BSS)

*Page 7:*

*Section 3.2:*

> networks can see their liability associated to the activity of
>    devices communicating through the networks
>
..

> As a device changes its network attachment (roams) from
>    one access point to another
>

Tieing liability to MAC addresses in a formal document is a dangerous and
incorrect assumption of trust and security. This text is incorrect and
misleading.

*Page 8:*

*Section 3.3:*

   - The discussion about trust relationship in section 3.3 completely
   ignores the whole unauthorized 3rd party sniffers which were just mentioned
   in the previous section. A device may trust the network, but it still
   cannot trust the environment, unless of course - as an extreme example -
   the network is located inside a lead cage.
   - Therefore, the conclusion about "full trust" in residential settings
   seems inappropriate (i.e. the conclusion seems to be very forced and
   unjustified).
   - Several other statements in this section about debugging/logging and
   therefore needing a stable identifier: This just proves the point why MAC
   addresses need to be rotated, as these logs are not supervised or
   guaranteed any privacy protections. Managed settings should use unique user
   credentials rather than relying on MAC addresses.
   - Section A mentions WPA3 which is completely irrelevant for the MAC
   address and does not protect it. It does not prevent a 3rd party sniffer
   located beyond the walls to detect the presence of a particular device in
   that network.
   - Section C: Legally mandated to identify devices or users - which is
   it? Without higher layer identification (when needed), a MAC address is not
   a user identifier and not a trusted device identifier (can be easily
   spoofed regardless of RCM).

*Section 3.4:*

   - Implicitly assumes that a device changes its MAC address in the middle
   of the session - which is not true and not permitted by 11aq. The examples
   of failing to decrypt traffic, selecting right keys, etc are completely out
   of context. A client device that wishes to maintain its state shall not
   change its MAC address during the session.
   - The 802.11i example is also unacceptable as it assumes repeated rapid
   rotation of MAC addresses, which looks like a DoS attack on the
   infrastructure (resource exhaustion) and needs to be detected and addressed
   regardless of RCM.
   - As devices will not rotate an address during a session, the forwarding
   example is also irrelevant, and specifically "flush of older MAC addresses,
   including for devices that did not rotate their MAC." is a bad example of
   poorly implemented solution that would flush live entries.
   - 802.1X section: Again, incorrect implicit assumptions in violation of
   11aq, mobile devices do not change their MAC address during an active
   session.
   - Very dangerous security statements about MAC address being used for
   door unlock, light and temperature). MAC address is not a trusted source of
   identity and must never be used for such operations. Mentioning this in a
   formal document must be avoided.

*Page 12:*

   - Section 3.6 finally makes it to requirements (based on very
   questionable and incorrect earlier statements): these are somewhat
   reasonable - but just a starting point for further work (e.g. "survey").

Thanks,
- Hai

On Sun, Oct 24, 2021 at 8:29 AM Lee, Yiu <Yiu_Lee=
[email-masked]> wrote:

> --
> Madinas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/madinas
>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 28 Oct 2021 07:39:34 -0400

On Oct 27, 2021, at 7:34 PM, Hai Shalom <haishalom=[email-masked]> wrote:
> How would RCM disrupt this service? An associated device does not change its MAC address for the entire session and once the authentication is successful, there is no disruption to the service. Additionally, if after disconnection the device changes its MAC address and associates again, the authentication will be successful since the client has the correct credential.

  There are many, many, use-cases where networks limit device access.  For example, corporate networks where only (a) authorized users, AND (b) authorized devices can gain access.

  If the user adds their name/password into a new device, that device is not know to the administrators, and will not gain access.

  Historically people have used MAC addresses to identify unique devices.  While this is becoming less useful, it's still used.

> Page 7:
> Section 3.2:
> Tieing liability to MAC addresses in a formal document is a dangerous and incorrect assumption of trust and security. This text is incorrect and misleading.

  MAC addresses are globally unique identifiers.  In the absence of another way to identity devices, the using MAC addresses is entirely reasonable.  It's not clear to me why this practice would be labelled "dangerous".  Please supply examples as to why this is so.

> Page 8:
> 
> Section 3.3:
> 	• The discussion about trust relationship in section 3.3 completely ignores the whole unauthorized 3rd party sniffers which were just mentioned in the previous section. A device may trust the network, but it still cannot trust the environment, unless of course - as an extreme example - the network is located inside a lead cage.

  Or there's a sufficiently large corporate campus.  Or wired networks.

> 	• Therefore, the conclusion about "full trust" in residential settings seems inappropriate (i.e. the conclusion seems to be very forced and unjustified).
> 	• Several other statements in this section about debugging/logging and therefore needing a stable identifier: This just proves the point why MAC addresses need to be rotated, as these logs are not supervised or guaranteed any privacy protections. Managed settings should use unique user credentials rather than relying on MAC addresses.

  That's nice.  Please tell 10,000 different companies that they can no longer identify devices on their network.

  This blanket assertion you make is simply not practical.

> 	• Section A mentions WPA3 which is completely irrelevant for the MAC address and does not protect it. It does not prevent a 3rd party sniffer located beyond the walls to detect the presence of a particular device in that network.
> 	• Section C: Legally mandated to identify devices or users - which is it? Without higher layer identification (when needed), a MAC address is not a user identifier and not a trusted device identifier (can be easily spoofed regardless of RCM).

  In the absence of some other way to identify a device, a globally unique identifier is an entirely reasonable choice.

  The purpose of using such an identifier is not to gain perfect security.  The purpose is to gain better security.  The requirement for known users means that MAC address spoofing is not much of an issue in practice.

> Section 3.4:
> 	• Implicitly assumes that a device changes its MAC address in the middle of the session - which is not true and not permitted by 11aq. The examples of failing to decrypt traffic, selecting right keys, etc are completely out of context. A client device that wishes to maintain its state shall not change its MAC address during the session.

  I read that as the MAC address may change during re-authentication.  i.e. When doing 802.1X, the session does not last forever.  There is therefore some point where a device wishes to reauthenticate, AND also to change its MAC address.

  When this happens, the AAA server sees a "session resumption" from the EAP-TLS layer.  However, the MAC address has changed!  So what should the AAA server conclude?  Is it the "same" device?  Or maybe the device has been hacked, and the TLS resumption data has been shared with another device.

  Perhaps the text in the document could suggest that ephemeral MAC addresses should also be associated with 802.1X sessions.  So long as the "same" session is being resumed, then the MAC address SHOULD NOT change.  If the device chooses to re-authenticate from scratch, then the MAC address MAY change.

> 	• The 802.11i example is also unacceptable as it assumes repeated rapid rotation of MAC addresses, which looks like a DoS attack on the infrastructure (resource exhaustion) and needs to be detected and addressed regardless of RCM.
> 	• As devices will not rotate an address during a session, the forwarding example is also irrelevant, and specifically "flush of older MAC addresses, including for devices that did not rotate their MAC." is a bad example of poorly implemented solution that would flush live entries.
> 	• 802.1X section: Again, incorrect implicit assumptions in violation of 11aq, mobile devices do not change their MAC address during an active session.

  See above.  I don't read the text as saying that MAC addresses change during an active session.  Perhaps the text could be updated to explain the difference between a specific 802.1X session, and a related set of sessions which all use session resumption.

> 	• Very dangerous security statements about MAC address being used for door unlock, light and temperature). MAC address is not a trusted source of identity and must never be used for such operations. Mentioning this in a formal document must be avoided.

  In the absence of some other device identity...

  I read the differences here as between two different viewpoints.

1) we have a MAC address which is globally unique.  We can use it for some purposes, which are imperfect, but which are better than anything else.  Because we have no other device identification method

2) MAC addresses aren't intended to be used that way.

  I lean towards the first viewpoint.  If I have to hammer a nail into a board, and the only tool I have is a rock, I'll use the rock.  Yes, a hammer is better.  But it might not be available.

  The IETF is a standards body, and can update standards to either explain why certain use-cases are wrong, or it can create new standards which explain better ways to do things.

  Alan DeKok.

---

From: Mathieu Cunche <[email-masked]>
Date: Thu, 28 Oct 2021 15:23:56 +0200

Hi,

Thanks Jerome and Lee for this very insightful draft.

You did a great job at presenting the type of collateral damage caused 
by RCM as well as the requirements to prevent or mitigate them.

Please find my comments below.

My first general comment is about the structure of section 3. After 
listing the various element of the network in Section 3.1, the 
document moves to the concept of  Human-related Entities (Section 
3.2). I believe this section 3.2 section is more about describing the 
threat model with the different adversaries, their capabilities and 
their motivations. Therefore, I suggest changing the title of this 
Section. Maybe "Threat model", or something similar ?

My second general comment is about the terminology. Some terms are not 
clearly introduced and in some cases, I have the feeling that two 
different words are used to describe a single concept. In particular, 
the concept of stability/persistence deserves to be introduced/defined 
the same way the unicity is defined in the first part of the document.

More specific comments:

"To limit the association between a device traffic and its user, 
client vendors have started implementing MAC address rotation" I 
believe one of the main motivation was to prevent the tracking of the 
user's physical location. Physical location can be as general as:  in 
range of a given AP or can be more specific coordinates derived from 
measurements (RSSI, RTT ...)

    "where other machine identifiers may expose the user privacy" The 
term “privacy” might be too generic. In the context of this document, 
these identifier could help re-identify the user or recover the 
identity of the user.

I believe there are two main privacy threat here:
1) tracking the physical location of the device / user
2) infer all kind of PII from the network traffic

"By randomizing the MAC address, the association between a given 
traffic flow and a single device is made more difficult" At a given 
time, the traffic can still be linked to a single device (identified 
by its current address). What RCM ensures, is that the association 
between traffic (and other information such as location), cannot be 
done for a duration exceeding the lifetime of the address.

"However, other network devices on the same LAN  implementing a MAC 
layer also expect the unicity of the MAC address." I think the 
expected property here is the stability over time of this MAC address 
rather than its unicity. Overall in the document, it seems that 
stability  is the main issue with other layers.

Remark regarding trust model in Section 3.5 : Although I'd like to 
believe that Home network can be fully trusted, I don't think this 
will always be the case. Intrusive mobile applications are already 
collecting all kind of network identifiers to profile users [1].

[1] Reardon, Joel, et al. "50 ways to leak your data: An exploration 
of apps' circumvention of the android permissions system." 28th 
{USENIX} Security Symposium ({USENIX} Security 19). 2019. 
https://www.usenix.org/system/files/sec19-reardon.pdf

Section 3.6: Is address "persistence" the same thing as address 
"stability" ?

It looks like section 3.6 mixes Requirements (REQ1,2,5,6...) with 
Actions (REQ 3,4).

Potential typos :

"The 802 Standard recognized that some devices may never travel and
    thus, always attaching to the same network," ->  attached ?

   "and change the address in a fashion that prevents a temporal 
association between one MAC address and some PII to be maintained 
fruitfully. " -> I don't understand the end of this sentence

   " However, the plurality of actors involved in the exchanges  tends 
to blurry the boundaries" -> tends to blur ?

   "...  or that can be temporal if an identity is required for a 
service in an environment    where trust has not been established." 
temporal -> temporary ?

  "require imple Internet" -> simple

   "REQ2  During duration of the services, the device shoud not change 
  the identity" -> its identity ?

"prior to update the MAC address." -> prior to rotation ?

-- 
Mathieu Cunche,
Associate Professor
University of Lyon | INSA-Lyon, CITI Lab. | Inria Privatics
Email: [email-masked] | PGP: 0x488B8CD3
Web: http://perso.citi-lab.fr/mcunche/index.html | Phone: (+33) 4 72 
43 73 15

On 24/10/2021 17:29, Lee, Yiu wrote:
> Hi team,
> 
> We combed through the use cases draft document against the comments 
> from the charter phase. Comments are welcome.
> 
> <https://datatracker.ietf.org/doc/draft-henry-madinas-framework/03/>
> 
> Thanks,
> 
> Jerome and Yiu
> 
>