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 <mcr+i...@sandelman.ca> wrote: > > Pascal Thubert \(pthubert\) <pthubert=40cisco....@dmarc.ietf.org> 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > Int-area mailing list > int-a...@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
