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

[Michael Richardson]

Pascal Thubert \(pthubert\)  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. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Pascal Thubert (pthubert)]

Hello Dave and all:

So far I have not seen how the MAC randomization deals with:

- DAD - the chances of duplication seem much higher than for IPv6; maybe we can 
help by doing DAD with something like RFC 8505 on the first hop switch / AP.

- 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.

The current implementations seem to use the SSID to do something similar to RFC 
7721. When you come back to the same SSID, you get the same MAC. This helps the 
corporate network, and is detrimental to the privacy at the coffee shop and the 
highway, if the same SSID is used across the country in all coffee halts and 
highway stops.

There appears to be work to do so that:
- the node forms a privacy MAC
- with that privacy MAC the node can do local things like 1x and DAD, if they 
are available
- if the visited network is recognized, the node applies a behavior (policy) 
that depends on the visited network
- else use a default higher privacy mode that may renew the MAC more 
aggressively
- only then, form IP addresses and stuff. If the MAC address was built using 
privacy, then we could restore the old behavior of embedding it in the IPv6 IID.

Bottom line is that the separate efforts at IETF and IEEE seem to have produced 
a complex overall solution, with duplicated and somewhat misaligned efforts and 
yet, gaps. The privacy properties of L2 and L3 addresses are not aligned to a 
same policy, and is not adapted to the joined network. The impact on upper 
layers of changing the MAC address is not fully understood. Duplicate addresses 
are not properly avoided at either layer and yet we pay a high broadcast price 
on wireless for the inefficient operation of IPv6 DAD. Hopefully we will not 
replicate that at L2.

This BoF may be an opportunity for IEEE and IETF to work together and converge 
to a better overall service to the upper layers.

Keep safe

Pascal


> -Original Message-
> From: Int-area  On Behalf Of David R. Oran
> Sent: mardi 22 septembre 2020 23:27
> To: Stephen Farrell 
> Cc: Michael Richardson ; home...@ietf.org;
> captive-portals@ietf.org; int-a...@ietf.org
> Subject: Re: [Int-area] [homenet] Evaluate impact of MAC address
> randomization to IP applications
> 
> On 22 Sep 2020, at 17:18, Stephen Farrell wrote:
> 
> > Hiya,
> >
> > On 22/09/2020 22:08, Lee, Yiu wrote:
> >> Hi Stephen,
> >>
> >> Thanks for the notes. Actually, we believe that there are good
> >> privacy reasons to randomize mac-address. This BoF isn't trying to
> >> "fix" randomized mac-address. On the contrary, we want the community
> >> to embrace it. In order to ease the anxiety for transitioning, we
> >> want to document what may break and propose best practice to
> >> transition to dynamic mac-address.
> >
> > Sure, I get that. However, we've seen a number of these efforts start
> > thusly but end up being perceived to be partly trying to unwind the
> > privacy benefits, so I think a good way to avoid that mis-perception
> > is to also present the reasons for (in this case, MAC address
> > randomisation) as fully as the description of the challenges caused.
> >
> Right. it would not advance the case to introduce (or start using) something
> else bout the device that can be tracked and/or provide likability and thereby
> damage privacy in order to preserve the randomized MAC address machinery.
> 
> > Cheers,
> > S.
> >
> >
> >>
> >> Thanks, Yiu
> >>
> >>
> >> On 9/22/20, 4:51 PM, "Int-area on behalf of Stephen Farrell"
> >> 
> >> wrote:
> >>
> >>
> >> That agenda and draft seem to make the seemingly common enough
> >> mistake of only focusing on what a new privacy or security mechanism
> >> breaks and glossing over the good reasons why people introduce these
> >> mechanisms. I hope the BoF proponents fix that because otherwise they
> >> may end up giving the impression that they would prefer to not see
> >> the privacy benefits (which I'd guess is not their goal at all). One
> >> reason those good reasons need to be included is that they constrain
> >> the kinds of additions that might make sense to better handle the new
> >> mechanism.
> >>
> >> We've seen a number of these kinds of reactions and I figure it'd
> >> really be better if the reaction were not to appear purely
> >> reactionary;-)
> >>
> >> If that were fixed, then there may be a better discussion of what, if
> >> any, additional things need doing. If that is not fixed, I'd not be
> >> surprised if the putative BoF were to devolve into a "it's bad" vs.
> >> "no, it's good" bun fight that won't really take us further.

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

[Lee, Yiu]

Hi Stephen,

Thanks for the notes. Actually, we believe that there are good privacy reasons 
to randomize mac-address. This BoF isn't trying to "fix" randomized 
mac-address. On the contrary, we want the community to embrace it. In order to 
ease the anxiety for transitioning, we want to document what may break and 
propose best practice to transition to dynamic mac-address.

Thanks,
Yiu


On 9/22/20, 4:51 PM, "Int-area on behalf of Stephen Farrell" 
 wrote:


That agenda and draft seem to make the seemingly common
enough mistake of only focusing on what a new privacy or
security mechanism breaks and glossing over the good
reasons why people introduce these mechanisms. I hope the
BoF proponents fix that because otherwise they may end up
giving the impression that they would prefer to not see
the privacy benefits (which I'd guess is not their goal
at all). One reason those good reasons need to be included
is that they constrain the kinds of additions that might
make sense to better handle the new mechanism.

We've seen a number of these kinds of reactions and I
figure it'd really be better if the reaction were not to
appear purely reactionary;-)

If that were fixed, then there may be a better discussion
of what, if any, additional things need doing. If that is
not fixed, I'd not be surprised if the putative BoF were
to devolve into a "it's bad" vs. "no, it's good" bun fight
that won't really take us further.

Cheers,
S.

On 22/09/2020 21:40, Michael Richardson wrote:
>
> Damn. Spelt captive-portal without the s again.  Reposting, sorry for 
duplicates.
> I hate when WG names and list names do not match, and that we can't have 
aliases.
> And I think that reply-to gets filtered.
>
> Archived-At: 

> To: int-a...@ietf.org, captive-por...@ietf.org, home...@ietf.org
> From: Michael Richardson 
> Date: Tue, 22 Sep 2020 16:34:33 -0400
>
> This thread was started today on the INTAREA WG ML.
>
> While I don't object to a BOF, I don't know where it goes.
> What I see is that much of this problem needs to be resolved through
> increased use of 802.1X: making WPA-Enterprise easier to use and setup, 
this
> changing core identity from MAC Address to IDevID.
>
> My understanding is that Apple intends to randomize MAC every 12 hours, 
even
> on the same "LAN" (ESSID), and that they will just repeat the WPA
> authentication afterwards to get back on the network.   If the per-device
> unique policy (including CAPPORT authorization) can be tied to the device
> better, than the MAC address based "physical" exception can be updated.
>
> But, WPA-PSK doesn't work, because it does not, in general, distinguish
> between different devices.
>
> It can be made to work if every device is given a unique PSK, and there 
are
> some successful experiments doing exactly that.  Mostly it just works, but
> the challenge is communicating the unique PSK through an unreliable human.
> BRSKI can certainly do this, and it can leverage that unencrypted ESSID
> present at most hospitality locations to get onto the encrypted
> WPA-Enterprise.  Or BRSKI-TEEP, or some other BRSKI-EAP method.  The
> unencrypted SSID is not going away at those locations.
>
> Thus QR-code based methods are best, yet those do not work for many IoT
> devices.   EMU's EAP-NOOB can help in certain cases, but we, as a 
community
> need be clear on what direction we want to go.  One answer is that IoT
> devices have little reason to randomize their MAC if they are not 
generally
> ported.
>
>
> On 2020-09-22 3:49 p.m., Lee, Yiu wrote:
>> Hi team,
>>
>> We proposed a BoF. The agenda is in
>> 
https://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_e7alyc8U$
  and the
>> proposal is in
>> 
https://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_eNfKGqkE$
 . You
>> can also find the draft here
>> 
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01__;!!CQl3mcHX2A!Q0pEjWrLTcmcryUR2EMbSc6uWBNU-xJadaznxWvwmDk2-ARoR0DYYq_erhCF3-A$
 .
>>
>> At this stage, we are looking for inputs for more use cases and interests
>> of working together in this domain. Please post your comments in the
>> mailing list.
>>
>> Thanks
>>
>
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software W