Re: [Int-area] [Captive-portals] [homenet] Evaluate impact of MAC address randomization to IP applications

[Malay Vadher <[e-mail]>]

Hi Yiu

Plume is supportive of this topic and would like to help with BoF
consensus. We are willing to present a couple of concepts with respect to
current MAC based device-to-user or group association predicaments and
propose non-MAC based expositions to enable policy control on devices while
allowing for MAC randomization.

This topic interests us immensely as while we would like to respect and
promote privacy of the users who could be tracked in public WiFi networks
outside of their home, we believe they would also like to opt-in to
personalize their own and their family member's experience in their home
network. This personalization includes traffic prioritization, content
filtering, cyber security protection and other advanced parental and
digital well being controls. Having this addressed in the IETF environment
and potentially standardizing it would help drive adoption of such features
across the industry. We look forward to working on it together.

Malay Vadher
Plume Design Inc

On Wed, Sep 23, 2020 at 5:53 AM Michael Richardson <[e-mail]>
wrote:

>
> Pascal Thubert \(pthubert\) <pthubert=[e-mail]> wrote:
>     > Hello Dave and all:
>
>     > So far I have not seen how the MAC randomization deals with:
>
>     > - differentiated environments - the preferred behavior on a highway
> or
>     > at a coffee shop may differ from that at in a corporate or a DC
>     > network. In the corporate network, we can expect something like .1x
> to
>     > undo the privacy, for good reasons. And we can expect state to be
>     > maintained for each IP and each MAC. When a MAC changes, there can be
>     > unwanted state created and remaining in the DHCP server, LISP MSMR,
>     > SAVI switch,  etc... Privacy MAC is only an additional hassle that we
>     > want to minimize.
>
> If we can assume 802.1X using an Enterprise scheme, and using a TLS1.3
> substrate, then if the identity resides in a (Client) TLS Certificate, it
> will not been by a passive attacker.
>
> The MAC address is outside of the WEP encryption, so it is always seen,
> even
> if the traffic is otherwise encrypted.
>
> An EAP-*TLS based upon TLS1.2 would reveal the identity, at least the first
> time.  Perhaps this is a reason to support resumption tokens in EAP-TLS!
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>