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

[Michael Richardson]

Ralf Weber  wrote:
>> 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.

> I of course don’t know Apples intentions, but what you are describing is 
the
> behaviour of early iOS 14 beta versions. However this behaviour has 
changed
> in later beta versions and the released iOS 14.0 version to have a random 
Mac
> per ESSID and not change that over the lifetime of the device (at least 
no so
> far on my devices at home), which I think is more in line what the rest of
> the industry does.

That's interesting news.
Why did they try something different in the beta?  Maybe they thought that
the industry was ready for this, but were wrong?
I heard about this change from Tiru Reddy.

It would be great if this BOF elicited public statements and/or public policies 
about
Google and Apple's intentions in this space.  If it's their goal to go in the
direction I outlined, then it would be good to know.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [Int-area] 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 ; homenet@ietf.org;
> captive-port...@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 r

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

[Ralf Weber]

Moin!

On 22 Sep 2020, at 22:34, Michael Richardson wrote:


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.
I of course don’t know Apples intentions, but what you are describing 
is the behaviour of early iOS 14 beta versions. However this behaviour 
has changed in later beta versions and the released iOS 14.0 version to 
have a random Mac per ESSID and not change that over the lifetime of the 
device (at least no so far on my devices at home), which I think is more 
in line what the rest of the industry does.


So long
-Ralf
——-
Ralf Weber

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Michael Richardson]

Brian Dickson  wrote:
>> I don't get the NAPT issue though.
>> The NAPT issues are because DHCP gave the device a different IP(v4), 
right?
>> If you solve persistent DHCP, then you solve those, don't you?
>>

> I think there are some environments where that isn't technically accurate,
> or might not be 100% accurate.
> E.g. The difference between DHCP6 and that other wacky thing that is doing
> random self-assigned IPv6 addresses.

Sure.  If there is a port mapping (or PCP created incoming ACL for IPv6),
which is bound to a particular IPv6 (however assigned), and that the IPv6
changes, then the mapping will break right?
This is independant of MAC address randomization right?
If we changed the MAC address, and then kept the IP address involved, then ND
would fix things up, and things would continue just fine.

> (E.g. maintaining the IP address when the MAC changes, defeats at least 
one
> possible purpose of changing the MAC.)

I strongly disagree here.
We use privacy IPv6 addresses in order to keep legitimate distant end points
(and their associated snoops) from tracking one for place to place.

We use different MAC addresses for different networks to keep from being
tracked by a federation of local snoops from place to place.

We change our MAC address at the same network to hide our time of use and
presence from local snoops.  But, also to deal with malicious attackers who
put up a common ESSID ("Starbucks").   We can, and do encrypt our IPv6
address on those networks.  But, we can't encrypt our MAC address, because as
you say, it used for media access control.

> I sense a potential rat-hole, but also the possibility of finding common
> ground to fix a bunch of things that are problematic to some degree or
> another.

I hope so too.

> I'm hopeful that something like 802.1x can be made use of effectively, but
> again a lot depends on the use cases and will likely require pretty deep
> dives on each of the relevant technologies and implementations.

> IMNSHO, MACs should be relegated to the role reflected in their name: 
Media
> Access Control, basically a disambiguator, not an identity.

> Maybe MACs should be used the way the initial values selected by the two
> parties doing DH key exchange are used, just as a stepping stone in
> establishing a cryptographically-strong "thing" that only they know.
> I.e. use the initial MAC (regardless of what it is) as an initial layer-2
> communications things, during the set-up of {whatever the BOF/WG output
> is}, after which the MAC gets changed to {something else}.

An interesting idea.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Stephen Farrell]

Hiya,

On 23/09/2020 01:13, Brian Dickson wrote:
> IMNSHO, MACs should be relegated to the role reflected in their name: Media
> Access Control, basically a disambiguator, not an identity.

With s/disambiguator/local disambiguator/ I would entirely
agree I think.

> The work being done by the exposure notification may be a good reference
> model.
> (Google Apple Exposure Notification, aka GAEN, for the SARS-CoV-2 aka
> Covid-19 protocols for privacy-first automatic exposure notification over
> BLE).
> That too uses identifiers that are non-linkable and rotate periodically (on
> the order of 10 minutes IIRC).

I don't think the GAEN system is a good example.

Mainly because, despite what I think are the good
intentions of all involved (that I've talked to anyway),
I doubt it could ever work reliably (and so is to some
extent theatre) but also because it's inherently vulnerable
to replay attacks, implementations can be very privacy
unfriendly, and the governance part is pretty sucky. It
also turns out that integrating GAEN into a real contact
tracing system seems quite failure prone too. (Apologies
for the self-references but our reports at [1] cover all
the above and more.)

That said, some of the protocol constructs used by GAEN may
well be good things to re-use though - there are some good
ideas there, in addition to the unjustified optimism. (*)

Cheers,
S.

[1] https://down.dsg.cs.tcd.ie/tact/

(*) "unjustified optimism" isn't quite right - I figure
it was more a case of "something must be done;  is
something that is less bad than , therefore 
will be done."


> 
> Brian
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Brian Dickson]

On Tue, Sep 22, 2020 at 4:25 PM Michael Richardson 
wrote:

>
> Bob Hinden  wrote:
> > I have read the emails and the draft
> .   I am not clear what the goal of the
> BOF is.
>
> > Could the proponents state it clearly?
>
> I can't speak for the proponents, but at the simplest, one could add:
>   "how can we do X if the MAC cannot be used as identity"
>
> > • LAN gateway NAPT forwarding - (PRESENTER TBD)
> > • Static NAPT policies - (PRESENTER TBD)
> > • Persistent DHCP IP address assignments - (PRESENTER TBD)
> > • Device-to-user or group association for malware protection -
> (PRESENTER TBD)
> > • Device-to-user or group association for parental controls -
> (PRESENTER TBD)
> > • Device-to-user or group association to restrict or authorize
> unwanted
> > or unverified device connections to the LAN - (PRESENTER TBD)
>
> I don't get the NAPT issue though.
> The NAPT issues are because DHCP gave the device a different IP(v4), right?
> If you solve persistent DHCP, then you solve those, don't you?
>

I think there are some environments where that isn't technically accurate,
or might not be 100% accurate.
E.g. The difference between DHCP6 and that other wacky thing that is doing
random self-assigned IPv6 addresses.

Basically if MAC addresses change during the lifetime of any assignment
(externally provided or self-assigned), the L3/L2 mapping itself also needs
to be updated or redone.

And how that is done can break security and/or connectivity and/or privacy,
or possibly all three.

(E.g. maintaining the IP address when the MAC changes, defeats at least one
possible purpose of changing the MAC.)

I sense a potential rat-hole, but also the possibility of finding common
ground to fix a bunch of things that are problematic to some degree or
another.

I'm hopeful that something like 802.1x can be made use of effectively, but
again a lot depends on the use cases and will likely require pretty deep
dives on each of the relevant technologies and implementations.

IMNSHO, MACs should be relegated to the role reflected in their name: Media
Access Control, basically a disambiguator, not an identity.

Maybe MACs should be used the way the initial values selected by the two
parties doing DH key exchange are used, just as a stepping stone in
establishing a cryptographically-strong "thing" that only they know.
I.e. use the initial MAC (regardless of what it is) as an initial layer-2
communications things, during the set-up of {whatever the BOF/WG output
is}, after which the MAC gets changed to {something else}.

The work being done by the exposure notification may be a good reference
model.
(Google Apple Exposure Notification, aka GAEN, for the SARS-CoV-2 aka
Covid-19 protocols for privacy-first automatic exposure notification over
BLE).
That too uses identifiers that are non-linkable and rotate periodically (on
the order of 10 minutes IIRC).

Brian
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Michael Richardson]

Bob Hinden  wrote:
> I have read the emails and the draft 
.   I am not clear what the goal of the BOF 
is.

> Could the proponents state it clearly?

I can't speak for the proponents, but at the simplest, one could add:
  "how can we do X if the MAC cannot be used as identity"

> • LAN gateway NAPT forwarding - (PRESENTER TBD)
> • Static NAPT policies - (PRESENTER TBD)
> • Persistent DHCP IP address assignments - (PRESENTER TBD)
> • Device-to-user or group association for malware protection - (PRESENTER 
TBD)
> • Device-to-user or group association for parental controls - (PRESENTER 
TBD)
> • Device-to-user or group association to restrict or authorize unwanted
> or unverified device connections to the LAN - (PRESENTER TBD)

I don't get the NAPT issue though.
The NAPT issues are because DHCP gave the device a different IP(v4), right?
If you solve persistent DHCP, then you solve those, don't you?

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide



signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Bob Hinden]

I have read the emails and the draft .   I 
am not clear what the goal of the BOF is.

Could the proponents state it clearly?

From the agenda, Use Cases:

• LAN gateway NAPT forwarding - (PRESENTER TBD)
• Static NAPT policies - (PRESENTER TBD)
• Persistent DHCP IP address assignments - (PRESENTER TBD)
• Device-to-user or group association for malware protection - 
(PRESENTER TBD)
• Device-to-user or group association for parental controls - 
(PRESENTER TBD)
• Device-to-user or group association to restrict or authorize unwanted 
or unverified device connections to the LAN - (PRESENTER TBD)

It seems like this is a list of topics where randomized MAC addresses might 
break things, so I wonder what the intent is here.   No mention of the privacy 
benefits, or what the tradeoff are.

I note that while MAC addresses are commonly used for things like this, it’s 
never been very secure as it is easy on most devices to change the MAC address. 
  Like when some cable modems locked on to a specific MAC address, and the way 
to get around this was to change to a different MAC address in the device.

I also wonder how much of this is an IETF issue, vs. IEEE.

Bob




> On Sep 22, 2020, at 1:51 PM, 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, homenet@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://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and the
>>> proposal is in
>>> https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md.
>>>  You
>>> can also find the draft here
>>> https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01.
>>> 
>>> At this stage, we are looking for inputs for more use cases and interests
>>> of working together in 

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

[David R. Oran]

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.

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:

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

[Lee, Yiu]

Hi Michael,

Thanks for the notes. At this stage, our #1 objective is to document the use 
cases that may broke and propose best practice to transition to dynamic 
mac-address. We don't have the full picture of the impact. We think IETF is a 
good platform to gather more information.

Thanks,
Yiu


On 9/22/20, 4:34 PM, "Int-area on behalf of Michael Richardson" 
 wrote:

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!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgWZ_LjWDQ$
  and
> the proposal is in
> 
https://urldefense.com/v3/__https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md__;!!CQl3mcHX2A!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgWZbxZn_w$
 .
> You can also find the draft here
> 
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01__;!!CQl3mcHX2A!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgWBEXWl54$
 .
>
> 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
>

___
Int-area mailing list
int-a...@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!!CQl3mcHX2A!Q_PTTc2RNhOPB-gus0u3ooXdg-Iikb-pUUpLp51UR3uOG41s6to-KpgW20rPBDw$

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Stephen Farrell]

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.

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.
> 
> 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, homenet@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

Re: [homenet] [Int-area] 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, homenet@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 

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

[Stephen Farrell]

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, homenet@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://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and the
>> proposal is in
>> https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md.
>>  You
>> can also find the draft here
>> https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01.
>>
>> 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 Works Inc, Ottawa and Worldwide
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Michael Richardson]

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, homenet@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://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and the
> proposal is in
> https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md.
>  You
> can also find the draft here
> https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01.
>
> 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 Works Inc, Ottawa and Worldwide



signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Michael Richardson]

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://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and 
the proposal is in 
https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md. 
You can also find the draft here 
https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01.


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



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet