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

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 2 Nov 2021 16:52:59 +0000

Hi Hai,

Thanks for reviewing the draft. Comments inline.

Thanks,
Yiu

From: Hai Shalom <haishalom=[email-masked]>
Date: Wednesday, October 27, 2021 at 19:35
To: "Lee, Yiu" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Madinas] New version of Randomized and Changing MAC Address Use Cases was posted

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,

[YL] Ok

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.

[YL] True. Will revise the test.

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.

[YL] Strictly speaking, RCM doesn’t impact AAA from the protocol perspective. That being said, many AAA implementations do create an association of the device and the mac-address after successful authentication. If the device decided to change the mac-address w/o properly signalling the AAA server, this would potentially trigger a challenge for authentication.  We can further this in the ML to refine the text.

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.

[YL] How about changing “liability” to “legal responsibility”?

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).
[YL] What we try to discuss here is the “risk” associated to an environment. For example: the likelihood of the mac-address being tapped over WiFi at home is less likely compared to standing in bus-station. We didn’t suggest that the mac-address must stay static. MAC-Address is fundamental for communication. In theory, a device could use a new mac-address for every new connection. That being said, this will break many current use cases. This draft tries to capture the current use cases and assumptions. We should debate in the working group whether we should consider to revise the current use cases in the world where mac-address will periodically be randomized and the best practice to handle this new world.
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.
[YL] Thx for the input. Weill discuss with the authors and adjust the text accordingly.
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]<mailto:[email-masked]>> 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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-henry-madinas-framework/03/__;!!CQl3mcHX2A!VmVPWHad-PiohY-QjH0oqCZ7VKBlZddDGfw3zKFIOUv9JpItIYcpaXc9wZu6i60$>

Thanks,
Jerome and Yiu

--
Madinas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/madinas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/madinas__;!!CQl3mcHX2A!VmVPWHad-PiohY-QjH0oqCZ7VKBlZddDGfw3zKFIOUv9JpItIYcpaXc93fua3RM$>

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 3 Nov 2021 20:06:24 +0000

HI Mathieu,

Best,
Yiu

On 10/28/21, 09:24, "Madinas on behalf of Mathieu Cunche" <[email-masked] on behalf of [email-masked]> wrote:

    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 ?

[YL.] Like what you said, 3,2 describes various parties who would have interests to mac-address before RCM. This is not limited to "Thread Model". But I do admit the section title isn't clear. Will clarify it in next version.

    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.

[YL] Indeed. Will clean up in next version.

    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

[YL] For privacy, we refer to the static entity of a device (i.e., static mac-address) that can be used to identify a device and further infer to a person so that the observer can track the device location and activities if no encryption technology was used. I think we are aligned.

    "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://urldefense.com/v3/__https://www.usenix.org/system/files/sec19-reardon.pdf__;!!CQl3mcHX2A!XjdI_MmQWBu9Ny50UUV74ZrWyw2DtbNR1o87i4M6jPQC2ECoEuaADaL9j2YnT4U$

[YL] This is something the WG should discuss. This is true that we can't 100% guarantee no eavesdropper in close proximity even we are at home. That being said, we need to define a way that users can continue using home services. In the end, the requirement is about how a network can securely identify a device and associate to a user profile, then provide the services at line rate.

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

[YL] After reading your comment, I think we need a clear definition. We use "stable", "static" and "persistent" interchangeably in our discussion but didn't define the actual meaning. In Madinas context, "persistence" means that the mac-address of a device will "never" change in a given network. The device may still use different mac-address per network. That being said, the mac-address is "stable/static/persistent" per network. In the RCM world, the network can no longer make the same assumption that a device will use the same mac-address.

    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 ?

Thanks for the catches. Will update them in the next version.

    --
    Mathieu Cunche,
    Associate Professor
    University of Lyon | INSA-Lyon, CITI Lab. | Inria Privatics
    Email: [email-masked] | PGP: 0x488B8CD3
    Web: https://urldefense.com/v3/__http://perso.citi-lab.fr/mcunche/index.html__;!!CQl3mcHX2A!XjdI_MmQWBu9Ny50UUV74ZrWyw2DtbNR1o87i4M6jPQC2ECoEuaADaL9QbvB3_8$  | 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-henry-madinas-framework/03/__;!!CQl3mcHX2A!XjdI_MmQWBu9Ny50UUV74ZrWyw2DtbNR1o87i4M6jPQC2ECoEuaADaL9GakJ5vg$
    > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-henry-madinas-framework/03/__;!!CQl3mcHX2A!XjdI_MmQWBu9Ny50UUV74ZrWyw2DtbNR1o87i4M6jPQC2ECoEuaADaL9GakJ5vg$ >
    >
    > Thanks,
    >
    > Jerome and Yiu
    >
    >

    --
    Madinas mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/madinas__;!!CQl3mcHX2A!XjdI_MmQWBu9Ny50UUV74ZrWyw2DtbNR1o87i4M6jPQC2ECoEuaADaL9jJp4tW8$