Subject: [Madinas] comments on draft-henry-madinas-framework-03

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Oct 2021 09:41:43 -0400

First, I would encourage the WG to please adopt the documents ASAP.
I see no reason to defer.

> It has become easier for attackers to track the activity of a personal
> device, particularly when traffic is sent over a wireless link.

Why has it become easier?
Has it really?  I'm unaware of any technology change in wifi to make this so.

Or is it that, more and more traffic is now sent over wireless links?
Maybe say:

+As wireless links have become ubiquitous, person-specific devices like
+smartphones and tablets have come to rely upon wireless communications
+exclusively.
+This has made it easier for attackers to track the activity of a personal devices.

I can't say a lot about the intervening sections.  They seem fine to me, but
in other ways, if you deleted them, I probably wouldn't notice.

I think that:

>3.6.  Requirements Formulation

is probably the meat of the document.

>   The section describes the requirements for Randomized MAC-Address
>   Changes:

+The section describes new requirements on services and networks due to
+Randomized and Changing MAC-address:

(IEEE calls it RCM, right?  so Address must be lowercase?)

Suggested changes:
+   REQ1  The network must not make any assumption about client MAC
+         address persistence between connection establishments.

>         MAC address change must happen while
>         allowing for service continuity.  If a service is interrupted
>         during the RCM process, there must be a formal mechanism for
>         the client and the network to exchange about the interruption.

I don't know how this second part is actionable.  The only tool we have today
is EAP-TLS / WPA-Enterprise.

Update:
+   REQ2  During duration of the services, the device shoud not change
+         its identity.
+         Any change of identity will require re-authentication and interrupt
+         of the current network services.

>   REQ3  Survey the current standards that use MAC address as a device
>         identifier in the protocol.  Make recommendation to the working
>         groups to remove the dependency.

This is not a requirement on a protocol, but rather it seems like it's a
charter statement.

>   REQ4  Work as liaison with external standard bodies such as IEEE, BBF
>         and WBA to align with use cases and requirements.

>   REQ5  Identify a secure mechanism to authenticate and exchange
>         network identity to the device.

>   REQ6  Identify a secure mechanism to inform the device about the type
>         of network the device is connecting to (e.g. public Wi-Fi,
>         enterprise, home), allowing the user to select the device
>         identity (or identities) accordingly.

>   REQ7  Identify a secure mechanism for the network to request device
>         identity.  Upon successful authentication, the network may
>         provide the device a temporary network-based marker to use the
>         network services.

>   REQ8  Identify a secure mechanism for the device to notify the
>         network prior to update the MAC address.

These all seem to be about a single milestone statement.
I don't understand why they are here in a framework document.

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 27 Oct 2021 20:20:26 +0000

Hi Michael,

Comments inline.

Thanks,
Yiu

On 10/27/21, 09:41, "Madinas on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

[YL]  I hear your point. I think it is better to delete this line.

    Suggested changes:

[YL] This is open for discussion. I think we have two questions:

1. Should we require client not to change mac-address while there are active sessions? (Stated in your updated REQ2)
2. Do we need a mechanism for the client device to notify the network when it is about to change the mac-address?

    Update:

[YL] Make sense. Will update this in next version.

[YL] Make sense too. Will update in next version.