Minutes IETF109: madinas
minutes-109-madinas-01

IETF-109 MADINAS BoF Agenda

MAC Address Device Identification for Network and Application Services

Wednesday, November 18, 2020 (+07)
12:00-14:00 Wednesday Session I

Jabber log: https://www.ietf.org/jabber/logs/madinas/2020-11-18.html
Jabeer scribe: Alex Petrescu
Minuter taker(s): Yiu Lee + others on codimd

* Welcome, Scope & Agenda Review (BoF Chairs) – 10 mins
(12:00)

Juan-Carlos Zuniga, Sigfox, j.c.zuniga@ieee.org
Carlos J. Bernardos, Universidad Carlos III de Madrid, cjbc@it.uc3m.es

JCZ is Juan Carlos Zuniga.
JC opened the meeting with the agenda. He explained this is a Non-WG forming
BoF.
In this meeting, we will discuss the background, mac-address randomization
implementation in Windows 10 and some use cases. Then we will open for
discussion this is something that IETF can work on.

Eric Vyncke is EV.
EV: I am responsible AD for this BoF and would like to thank Yiu, Jason, and
Jason for initiated this effort.
EV: Jari and Steve have also helped in shaping this BoF.
EV: with IEEE coordination, people from IEEE like JCZ are here too.

* Background – 25 mins
(12:10)

Background and status about MAC address randomization work in IEEE 802 and WBA -
Amelia Andersdotter, CENTR
https://datatracker.ietf.org/doc/html/draft-zuniga-mac-address-randomization-00

(Amelia might be not reaching on time - JCZ presenting on Amelia's behalf)

EV: maybe go through the slides until she joins.

JCZ presents.

Tim Capalli in the chat: “Android 11 allows per connection via developer
options. That probably should be reflected in the table” (seconded by Jérôme
Henry).

JCZ: comments and questions will be taken after the next presentation.

MAC address randomization in Windows 10 - Dave Thaler, Microsoft

Dave Thaler is DT is presenting.

* Clarification Q&A

Daniel Gilmor is DKG.
DKG: address calc is has of secret SSID and connection SSI - is that stable or
new secret every time?
DT: not person best am I to answer; but everytime it uses crypto API, I believe
one time entropy, but not sure, but I can get you to the person.
DKG: if new entropy then why need of hashing?
DT: right, could be same secret, I'd have to check, didn't implement it, but I
report, but I get your point.

Glenn Parsons is GP.
GP: from Ericsson I am; I note one particular activity named IEEE 802.1AEdk -
MAC privacy protection, MAC security standard amendment, defines an encap
format, carry confidential protected data in header, hide some things such as
MAC address and frame size (padding to max or even random size). it’s a project
under way, note that.

Stephen Farrell is SF.
SF: what kinds of toggles do you consider? before going on by default.
DT: each of these applicable to a kind of net.
applicable to enterprise
maybe for inventory mgmt
maybe IT admin for some cases sets it off, maybe a BYOD (bring your own device)
then register maybe ahead of time; if so then randomization blocks something
that should be working.
issues I know off : public hotspot.
eg existing hw that does not work right, that uses Probes then that would not
work.
if change default, or upgrade OS, change behaviour, people might think that’s
broken because not work as before; but once you connect something we store the
MAC address you use.
Starbucks use case also.
Mobile OSs might be different behaviour than laptops.

JCZ: more questions?

Dan Harkins is DH.
DH: on Windows 10 and on other 802.1q implementing computers, does this reset a
particular seqence number?
DT: not sure, change things. Not sure on this particular, but I work with them.
For example, when we change MAC address we also change IP adddress, not because
derived from, but change related things to it.
DH: this question is not for things at layer 2, but layer 2 point 5, such as
dhcp client id - change that as well?
DT: not sure off-hand, maybe Christian Huitema would know (link to blog on
presentation) - my belief is Microsoft and us spent lots of time on privacy,
tried hard to make sure when turning it on that it works, so, I hope it does so.
DH: tnx.

Tinulaleswar Reddy.k is TRK.
TRK: how make sure enable in untrusted networks (shop) but not enable in auth
nets such as home network - how end user enables this on a per net basis?
DT: on Christian’s blog, linked somewhere here, screenshots; but is it easy?
more for advanced users. Easiyl discovered? not hidden but not in your face, but
is is there when y ou connect to an ESSID it pops up.
TRK: tnx.

Michael Richardson is MR.
MR: on enterprise same MAC address? how do you really know which net you connect
to?
DT: not sure on that particular answer, I present on her behalf.

* Use Cases – 55 mins
(12:35)

Jason Weil - Charter; Malay Vadher - Plume; Chris Box - BT

(Jason Weil is JW is presenting)

Home Network Use Cases
Use case for diagonstic and customer support
Use case for Wi-Fi band and AP steering
Use case to setup a server at home
Use case to protect DDoS mitigation
Use case for access controls / parental controls
Use case for service policy based on device identity

Community Wi-Fi and Hospitality Use Cases
Use case for auto-authentication for Open SSID
Use case for UE mobility in Wi-Fi
Use case for DHCP Table Exhaustion

Cloud Resource Management Use Cases
(Malay Vadher is MV is presenting)

Use case for resource management when mac-address is randomized

(Chris Box is CB is presenting a slide titled Legacy Client Steering and
Pre-Association Steering; and subsequent slides)

JCZ: these usecases are highlighting issues people saw in the network; the idea
is not to claim back fixed MAC address; hopefully it’s understood the new normal
is random MAC; but certainly there are problems we have seen with that; before
moving on, stop here a moment, take clarification questions.

* Clarification Q&A

Stepen Farrell SF
SF: store MAC address, what for and for whom? in a particular slide.
MV: we have a database for all device supports, by managing all policies in the
cloud; does this help?
SF: who is ‘we’?
MV: I work for (‘bloom, as i’), for managing devices,
SF; please a link
SF: it might be dangerous to store that, but clarify.
MV: think of it like this: you have an app, you use to manage all your home
devices, assign devices and home to a particular profile, assign a profile to
devices and kids and tablets at home; eg designate Internet at night, and
probably content protection; communication between E.P.Is and the cloud.
SF: ok, (doubtful)

TRK : but still possible to spoof MAC address? Could spoof a MAC address, it
would get into the database - how do you handle? How do y ou diffrentiate
between OS doing it or an attacker doing it every milliseconds or so?
MV: while we move away from… the attacker would get the password and ESSID? By
spoofing the MAC address the attacker gaians profile info? And gaining access to
that particular network? No particular advantage I think
TRK: but maybe bypass some policies? Quite easy, there are some tools to spoof,
then I make restrictions of no Internet access, any kid could do that
MV: provided parent enabled it, but...
TRK: sure.

Victor Kuarsingh is VK.
VK: comment on a privacy perspective.
out of profile behaviour? these attackers could be detected and isolated; that
use case does exist; that shows a significant pattern that could be isolated.

Alissa Cooper is AC.
AC: you mentioned ‘open roaming’? anyone could speak as to the implications of
this activity to open roaming; maybe the implications of how a more robust
(technology?) could be realized.
JCZ: I used slides from Amelia, hofepllly she can help clarifying; but maybe let
us get on the email list and discuss there.

Chris Box is CB presents slide Use Case-derived Requirements.

JCZ: this is food for thought to start the open discussion.

* Discussion

Yiu Lee is YL

YL: are you referring to identifier of upper app layer or to the id of the
packet level, similar to MAC address now doing today.
CB: who knows what right solution is? essentially we try to preserve MAC addr
randomization; in order to meet these use cases maybe we need several forms of
ids, maybe at different layers, not trying to predict what solution is, but yes,
some ids are needed, they will appear different, let us figure out what is the
right level of form.

Cullen Jennings is CJ.
CJ: is there a requirement for user input on the device? Eg if we talk
about802.1x we traditional VoIP phone? issue? Requirement is there about end
user input is present or not?
CB: I’d agree.

Stuart Card is SC.
SC: there are usecases in which provisioning of a new ID should be intentionally
costly for end user, so that it is not trivial to make large numbers of id, and
also facilitate constantly new identity to spam over or whatever.
CB: maybe better phrase, consideration how the new identity ought to be
achieved.
SC: if we need a means to achieve a low friction, but we need a means to achieve
a low level of friction. (s difference is there).

AC: multiple different ids?
AC: but the id?
AC: there is a greater variety of uses of this info, in some caseswhat is needed
is a dev id, but in some cases you might just wanto prove you ar epart of a
group, I think some of consideration on right hand side on chart (slide USe case
derive deqquiremnts) are… IT sounds there might be a whole API surface of this;
but likvely reveal different info to different sides.

(presenter answers)

(The meetecho freezes I think, I cant see the blue growing bubbles indicating
who speaks.)

SC(?): a human centric device, dont get these secure ids into a home; the
shortest path to enroll is ten taps, n the longest path is 27 on other devices;
no way; I fudneamentally disagree. At the end of the day separate from dev id,
and what directory is that bounnd to. Again, less friction, not more.
SF is Stephen Farrell.
SF: reqs derived for people who suffer from issues of MAC address randomiwation;
if there is something going fwd, but what is a more complete set of reqs?
Privacy consider. The reqsd should not be derived only from what’s on the slide.

CB I assumed we all agree Privacy is the aim for randomization; that’s the
reason why not listed. But yes, propserly it shoul be listed. There is
requrimetnet, it is the default position.

SC: understood, but to do a good job, but want to consider what are the usecase
- trackers for advertising purposes? Does that change well or bad for things you
dont want to happen(?).

Tommy Pauly is TP.
TP: show table slide.
TP: following Steven’s point, would be useful to add more of privacy in this
list, and specifically, but form Apple client side: any id that is going to be
shared, should be based on trusting the identity of the network, oand f the
particulaer entity int he entwork. How confident the cliennt is in the net id.
How is the client confident on the network entity receiving? Sharing metadata
should be done with explicit client intent to move forward, and not just blasted
into the network. Put on this table, for any piece of data, exactly what net
entity needs to see that? what are the ntransport and esccirutiy.

CB: agree client needs tto have trust of the network.

Jari Arkkko is JA.
JA: I agre with Tommy, but also we went down to this quite quickly. I was
strugglin to make a decision at the higher level - what do we really need.=? We
already haveve defaults, user configs, ids at many levels, randomization, non
random, EAP ids, and so on; I am trying to see what do we really need? Not clear
the solution is a new id. Some people in some netowrks, enterprise, differnet
ways; why there is default? Some info I advertise… instead of introducing a new
identifier system. Always worried about new identifier systems.

CB: anyone contributor other would like to respond? Not immersed am I into IEEE
to answer.

JL (Lee)
JL: what we say, I think, not a new id; we look for guidance, on use cases,
which use cases , wht breaks. How the device can trust the network; hey if I
know who you re, if I go for hotel, hotel network, in the stay time, give me
persistent data, that service, contract, might expire by time. That is something
especially for h ome users who dont havae tech background, pre-change of
identity, a ‘preta’, try to help the users; the Chairs already menntioned thi
sis not a WG forming, how should we feel to push energy in maybe a aBCP, or
committee, to ease the friction (fixture) of the challenge in the future.

JA: this is about detials in the reqs; I am asking why is not defaults and
settings enough for the market. We have the people inthe mindset of privacy, and
people in the coprporate network, and smaller fractions of market; but why these
people need these new techs? Why not enough to just set the things correctly, or
just use the defaults. But lets move on.

JCZ: as a reminder: a mailling list we have for this, please discuss also there.

Toerless(person): reduction friction does not reduce... friction-less
identity... what is my user experience? What is done here is to understand from
the persepctive of the provider, but not from the users. Whom do I need to
trust, the user experience aspects competing to what the provider of the use
case wants to get.

Andrew Campling is AC.
AC: developers, and net operators, dont udnerstand user needs well. Observe, At
least help bridge that gap a little; instead of saying how people should not be
doing things; not ignore the reality; discussion is helpful in getting
implementers and network operators talking to each other.

Jerome Henry is JH.
JH: from layer standpoint; multiple OSs, no consistency across OSs, MAC
addresses.
JH: iOS does not retain something.
JH: IMHO this is more an IEEE problem rather than IETF
JH: I look into 802.11 context; but interesting is to triage a bit.

JCZ: yes it is part of q we would like to answer. Work happened at IEEE and
happening also now. Please feel free to let people know on the email list.

Tim Cappalli is TC.
TC: Tommy started this a bit, I do not think IETF Is the right place; but if
continue, then step further back; I am concerned that something passpoint and
secure wifi is an option, but that des not stop the operator to see the traffic,
and users dont know that; the venues (mcdo) do see the traffic; how many device
names are taken; this is ‘John’s iphone’ is yelled to the network. Hwat ki d of
user consent is the user giving; we have to address these together, otherwise
loops. There is no break aay; network has no means to prove who it is. There are
things, but not perfect. Would one buy a domain name and put in an SSID? Thus
the user is sure when connecting into it, and ... trffic sniffed.

JCZ: we dont want to step on other org’s grounds; we do coordinate with IEEE
802. However we still want to understand the problem. Even if this is something
not for IETF to solve, it could be useful to informing other SDOs if id’s are
being misused or causing issues. This could be an important action for IETF.

Joey Salazar is JS.
JS: I agree with Tim, but lack of end user knowledge should not prevent us efrom
working on parts of use cases; BoF is to come up with new id? Users might not
use MAC rndm, for thhose, we should try to establiish a baseline. MAke sure we
make them understand with informed consent. Informational documents address if
new ids become... targets of user tracking.

JCZ: Clarifying that purpose of BoF is not to come with new ids. It’s happening
elsewhere, we dont want to duplicte.
Purpose of BoF is to inform about the new activities.
We want to understand - do we need identifiers?
What are the ways to achieve means to provide services?
ids also have different purposes - there is a devices view, a network view, a
user view.
We want to see what is happening in terms of solutions and issues, so we can
take a decision on how to move forward.

JS: should IETF get involved? an INFO document? Yes I think it should.

Chundshan Xiong is CX
CX: MAC address and IP address mostly used in consumer devices and industry
business; if we need change on MAC address, then we need many changes, like when
changing from IPv4 to IPv6.
CX: must consider client device does not support address change?
CX: need to id who you are? maybe need to detect duplicate MAC address; we
usually assume never dup, but... interrupt comms. Keep service continuity. MAC
address is used in lots of standards, even in 3GPP it is used to emulate, for
auth, routing; IETF is probably not the only SDO for this job, maybe we need
coordination between these SDOs.

JCZ: thanks.

Bob Hinden is BH.

BH: not sure this is something IETF should do, or what exaclty should do? Some
of examples in slides is bad implementation, like DHCP servers not having enough
tables; MAC were used for many things not intended for, for a long time; some of
the issues are not just MAC addresses; in IPv6 we sort of built support for rand
MAC, and multiple IP addresses, but some of same issues apply at the IP layer
too, not just MAC; this needs to be thought about broader than what happens at
the link layer; there is a lot of work. But first, is there a problem the IETF
could solve? It is a sort of boundary - not exactly IETF, not IEEE; need to be
careful we can actually do and succeed, rather than just write a bunch of drafts
without any effect in the industry.

Li Yizhou is LY

LY: this relates to a bunch of SDO; if IETF, how is it related to DHCP? in the
fixed net access, there are lots of impl, like DHCP snooping and other, try to
filter the traffic. That could be a possibile solid case that could be solved at
IETF. I thought so.

* Interest & Next Steps (BoF Chairs w/AD Support) – 30 mins
(13:30)

JCZ: I will formulate some questions, that are now shown on slides.

“Is there communty interest in this topic?”
53 Raised Hand vs 5 Not Raising Hand for total participants 100.

“Are there any actions required at the IETF?”
36 Raised Hand vs 10 Not Raising Hand out of 100

Commenter BH: it’s hard to answer, its way too open ended (the 2nd question)

JCZ: this is non forming WG, so intentionally left open ended, so we get a
feeling from the community and then see what next steps we should do.

JCZ: “is this a topic of interest for people to actually use / do some work”
39 Raised Hand vs 10 Not Raising Hand out of 98.

JCZ: this gives us good feedback, very interesting points, we need to look at
all this info, and see how we can consider it it.

JA (Jari): maybe I would like to work, if there was a market need. We’d need to
explain that, and more research is needed, not just new identifiers, but rather.

David Gilomr DG.
DG: I'm interested if there is an interesting proposal, if bad proposal, I am
interesting in working to make it less bad.

Alissa: action item might be after this, got a good overview from IEEE, but also
need from WBA and WFA. That would be valuable.

JCZ: as informational draft co-author - we tried to put as much info as we
could, but if you have some pointers or name to make it better it would be
appreciated

Hanguang Wang is HW.
HW: (could not hear)

Eric Vyncke is EV.
EV: thanks for runnign this BoF. It is pretty clear many are interested in the
topic; a lot of info is in the Chat, link the chat log in the minutes; so we
could see the useful info there.
EV: do we need to do something? We dont have an ideal view right now; maybe INFO
and maybe BCP for either operators or for IETF communicty (or for other, maybe
layer2). Clearly not a decision now and here, but we need to discuss it more.

JCZ: yes it is a good reminder, please poeple interested please join the madinas
mailing list, it is thus a good way to decide what are the required next steps.

JCZ: (adjourns).

* MEETECHO CHAT LOG

This is a copy/paste of the chat log:

Dan Harkins
and a good evening to you sir!
05:51:35
Peter van Dijk
good evening :)
05:51:47
Jason Weil
I guess technically it will be morning here when we begin at 12 :)
05:52:40
Peter van Dijk
hah yes
05:53:09
will be 6AM here then :)
05:53:19
Jason Weil
Ah you will get to see the sunrise during the meeting
05:54:53
Cullen Jennings
thanks
05:55:46
Peter van Dijk
‘technical’ sunrise is at 8:08 here, so just after, but practically, yes, the
sun will peek in
05:55:49
Carlos Bernardos
good morning guys!
05:57:46
Alexandre Petrescu
in earlier meetings some people said that the blue sheet is automatic somehow; I
just would like to make sure the bluesheet is automatic here too.
05:57:47
Bob Hinden
Yes it is, it’s part of the datatacker login.
05:58:06
Éric Vyncke
Yes, BoF are as WG meetings
05:58:07
behcet
No audio?
06:02:19
Alexandre Petrescu
I hear well
06:02:29
Peter van Dijk
i have audio
06:02:32
Bob Hinden
OK for me
06:02:32
behcet
Now I hear
06:03:19
Éric Vyncke
I do not see any Amelia in the list of participants :(
06:07:36
mcr
she forgot?
06:07:46
not in gather.town either.
06:08:03
sftcd
it is v. early in many places to be fair;-)
06:08:27
Éric Vyncke
It is 6 AM in Belgium where Amelia lives AFAIK
06:08:45
sftcd
that’s beyond early in my universe:-)
06:09:01
Peter van Dijk
it is 6AM in Belgium, yes :)
06:09:07
dkg
it’s always very early in many places though :)
06:09:14
sftcd
well, breakfast at local 11am is the ideal, that’s true
06:09:33
Éric Vyncke
@Peter so at least two Belgian people are here and awake ;-)
06:09:35
Peter van Dijk
well I’m one country to the north
06:09:49
Éric Vyncke
:-o
06:09:57
Peter van Dijk
I thought somebody mentioned there were slides with this? I’m not seeing any
06:09:59
Éric Vyncke
There are slides shown right now
06:10:12
Peter van Dijk
sorry, my bad
06:10:13
wrong view :)
06:10:16
mcr
It’s always dark. What’s 6am vs 6pm? Same thing.
06:10:17
Adam Wiethuechter
Hello darkness my old friend…
06:10:35
Deb Cooley
both are better than midnight
06:10:37
Éric Vyncke
Looking for Sun raise at the end of the BoF: let the light shine after this BoF
06:11:38
Bob Moskowitz
Lost the slides.
06:13:19
Peter van Dijk
still works here
06:13:32
Adam Wiethuechter
Still here for me
06:13:38
sftcd
https://datatracker.ietf.org/meetin…randomization-in-ieee802-and-wba-00
06:13:46
Tim Cappalli
Android 11 allows per connection via developer options. That probably should be
reflected in the table.
06:13:58
Alexandre Petrescu
(version of Windows on PC and on smartphone do MAC address rand’zation)
06:14:10
Éric Vyncke
@Tim please be sure to mention this on the mailing list as well
06:14:21
sftcd
I had an IEEE question: any idea when to expect a new thing from them? I’m
assuming 3-4 years or something?
06:14:24
Adam Wiethuechter
All good!
06:14:40
Shuai Zhao
yes
06:14:46
Olaf Kolkman
yes we can
06:14:48
dkg
can the folks who aren’t speaking stop sending video? dave’s video doesn’t fit
on screen for me
06:15:16
Jerome Henry
@sftcd: yes 3 to 4 years is typical and expected here as well
06:15:20
sftcd
@jerome: ta
06:15:29
dkg
it’s also nicer for folks who don’t have a lot of bandwidth
06:15:48
sftcd
these ones are
https://datatracker.ietf.org/meetin…ress-randomization-in-windows-10-00
06:16:19
Éric Vyncke
@dkg: please accept my apologies, forgot to turn video off
06:16:21
sftcd
I also had a windows question: anyone know how many people tweak any of those
settings away from default? I’d guess a small %
06:17:43
Tim Cappalli
Most users don’t click that deep into the network settings
06:18:38
Deb Cooley
small, unless Windows prompt for it.
06:18:47
Andrew Campling
Good to hear about the usability / privacy tradeoff here, this is often ignored
06:18:54
Shuai Zhao
back to network 101, if a MAC address of a device keeps changing, how does the
network device mostly switch handle the extra work to match up a host and mac
address?
06:18:56
Tim Cappalli
the MAC doesn’t change regularly
06:19:14
so it is not an issue
06:19:22
sftcd
that’d be my guess too (“small %” that is), I was struck by the lack of numbers
on more or less all the slides
06:19:31
Dan Harkins
Does windows 10 only randomize wifi MAC addresses or does it also do it for
wired?
06:20:01
Peter van Dijk
with iOS apparently re-randomising periodically, the overall % will be big
anyway
06:20:04
Shuai Zhao
@tim but here in the slide saying there is an optional to random change mac
address...
06:20:05
Tim Cappalli
Shuai, yes but the most aggresive is daily.
06:20:20
Alexandre Petrescu
In settings for Windows for PC there is one setting ‘MAC addresses random’
‘Activated’/'Desactivateed which is off by default. I dont see other settiings.
06:20:21
dkg
Tim: “daily” == “regularly” , but i agree with you it’s not that frequent
06:20:26
Tim Cappalli
MAC tables age much faster than that
06:20:28
Daily != regularly in my book
06:20:34
dkg
well, it is regular :)
06:20:41
Tim Cappalli
Regularly would be like hourly
06:20:45
Peter van Dijk
also MAC tables learn immediately when you send out a frame from the new MAC
06:20:47
Tim Cappalli
or per session
06:20:50
dkg
i mean, yearly would also be regular :)
06:20:56
Jerome Henry
iOS does not rotate the MAC periodically, this was the beta intent, but the
final is sticky per SSID
06:21:00
Peter van Dijk
Jerome, ah!
06:21:10
Tim Cappalli
Android 11 has the most aggresive option (per session) but it is currently
buried in a developer option
06:21:11
Alexandre Petrescu
(win10 for PC - only for WiFi MAC, absent from Ethernet)
06:21:11
dkg
Jerome, that’s not what the table we saw in the previous slide said
06:21:20
mcr
so, many base stations can have the same SSID, but would have different BSSID?
06:21:22
Tim Cappalli
Jerome is correct re: iOS
06:21:32
Peter van Dijk
mcr, yes
06:21:34
Tommy Pauly
Right, iOS uses a stable MAC address for each network
06:21:35
The behavior changed from the beta, which probably is where the confusion comes
from
06:21:53
mcr
at the IETF, we have network “IETF”, which is the SSID.
06:21:55
dkg
Tommy, stable even across “forgetting” the network?
06:21:59
Dan Harkins
@mcr, yes each AP has its own BSSID.
06:22:02
Shuai Zhao
so there will be initial delays everytime you have to send out a ARP right?
06:22:02
mcr
was there some devices which randomize between BSSID then?
06:22:21
Cullen Jennings
what does OSX do ?
06:22:36
Jerome Henry
@dkg: the table is from a site that reports the beta behavior, but this is not
the final behavior (the table may need be corrected)
06:22:37
sftcd
my home router mails me when a new MAC shows up - I see an apple one every maybe
few weeks (same device, same DHCP name;-)
06:22:38
Tim Cappalli
It is per ESS, not BSS
06:22:42
Dan Harkins
APs don’t randomize, that would cause problems.
06:22:45
Jerome Henry
OS X does not randomize as for now
06:23:01
Éric Vyncke
@Jerome you may want to say it at the mike but also on the mailing list
06:23:52
mcr
and it sounds like it stores the MAC-address in a database if it wants to keep
it.
06:23:55
Jerome Henry
@Eric thank you, I’ll mention it in the Q&A part
06:24:29
Cullen Jennings
@Jerome - Thanks
06:24:54
Joey Salazar
the setting says it applies for new connections, I guess it’s generated only
once per new connection?
06:25:24
sftcd
typical thaler: a good answer incl. a thing I didn’t know:-) (the probe stuff in
my case)
06:28:28
Éric Vyncke
@stephen: typical indeed, detailed + concise ;-)
06:28:59
mcr
I worry that we disparage Starbucks unfairly: did they actually ever track
people by mac address?
06:29:00
Andrew Campling
There seem to be plenty of scenarios where a move to full MAC randomization
would simply see the implementation of a different form of persistent identifier
instead
06:29:17
Cullen Jennings
This is a great example of "last person 'to touch it is the person that broke it
06:29:25
Tim Cappalli
^ Correct
06:29:26
Adam Wiethuechter
I don’t trust them to even make a coffee right @mcr
06:29:28
Tim Cappalli
and these have been available for years. Using a MAC for a device identifier is
a self-inflicted problem and we shouldn’t be trying to engineer around it.
06:29:50
This is a typical case of not keeping up with the times
06:30:17
Organizations that make their money on captive portals are upset because their
revenue stream is going away
06:30:38
sftcd
so I take from Dave’s answer that it might be possible for someone (more IEEE
probably) to try figure some (probe/traffic) metric that’d help know when to
goto default on (for layer 2 stuff anyway)
06:30:41
Tim Cappalli
How do you determine it is an untrusted network without a prompt?
06:31:53
sftcd
@andrewC: I guess a question is whether one can move to emphemeral identifiers
for what currently uses static MACs, (my bet is one could if one wanted in some
cases)
06:32:21
Tim Cappalli
@sftcd, its not necessarily about ephemeral, its more about protected
identifiers 06:32:45 sftcd fair point too 06:32:54 Tim Cappalli aka, inside a
tunneled EAP method 06:32:54 Stuart Card captive portal revenue probably is
mostly a thing of the past, but for some operators, alternative means of
preserving it will emerge 06:33:12 dkg i share Andrew’s concern, fwiw – but
still think it’s worthwhile to pursue this 06:33:20 Tim Cappalli @Stuart, you
would think so, but honestly, that’s not the case 06:33:28 Jari Arkko Dave:
Thanks for this. One more question, taking it to the jabber only. OSes often
know about WiFi networks that demand web-page login. Is the logic for
recognising that connected to the randomization behaviour in any way? (Or could
it be?) 06:33:31 Dave Thaler good questions all, and yes it stores the MAC
address with the SSID on the local machine until you “forget” the SSID 06:34:27
Erik Kline @Jari: In Android’s case it remembers whether the captive portal
check detected a portal. 06:34:30 mcr Jari, they mostly get an IP address and
try to download from known http:// and if they don’t get the right answer,
present the captive browser. So at that point, they have already revealed
themselves. 06:34:37 sftcd
https://datatracker.ietf.org/meetin…es-109-madinas-madinas-use-cases-00
06:35:06 dkg mcr: who has revealed what? 06:35:07 are you saying that they
identify their vendor b choice of canary probe? 06:35:28 sftcd general comment
on these slides: the lack of numbers here is an issue for me when it says
things like “many” quite a few times - makes it hard to grok the reality
06:35:35 mcr @dkg, so they’ve picked a mac address, dhcp ID, and yes, canary
probe choice reveals vendor. 06:35:50 Tirumaleswar Reddy.K how does the ISP
know the MAC address of devices in the home network ? 06:36:08 dkg mcr: right,
makes sense 06:36:10 Tim Cappalli If you use the ISP’s router/gateway, they
know everything 06:36:22 Mohamed Boucadair @Tiru: it does not know. This is
local to the CPE 06:36:33 sftcd doesn’t DHCP itself let me ask for the same IP
the 2nd time? 06:36:35 Dave Thaler @sftcd yes a metric like that would be
useful (Microsoft probably has an internal metric but having a public metric
would be useful) 06:36:46 mcr So if I think you’ve been to Starbucks, and I put
up a “STARBUCKS” SSID, I think that you’ll tell me the your saved STARBUCKs mac
address when you reach out to talk to my portal. (leaving a notify on my phone
about logging in) 06:36:53 dkg Mohamed: lots of ISP deploments have detailed
control over the CPE 06:37:18 Tim Cappalli ^ yep 06:37:18 (@mcr) 06:37:24
Stuart Card MCR yes that is a standard WiFi Pineapple attack 06:37:39 Dave
Thaler @mcr I believe the “SSID” is actually associated with a key. So unless
you have a open wifi (don’t do that…) then it won’t connect if you claim to be
Starbucks 06:37:43 mcr TR-069 features in non-pure-openwrt routers have mucho
features about mac address diagnostics. 06:37:50 Tim Cappalli @Dave, a majority
of public Wi-Fi networks are open 06:38:06 dkg my home wifi network is named
“Starbucks WiFi” ☺ 06:38:08 sftcd @mcr: much unused features, or? … 06:38:19
Cullen Jennings I’m curios about the DHCP lifetimes in use for this running out
of IP address use case 06:38:21 mcr no wonder Adam can’t get good coffee from
your starbucks. 06:38:26 sftcd @dkg: send coffee! 06:38:30 Dave Thaler yes
public wifi would have no key and yes you could get the MAC used at Starbucks,
which is why the “Change daily” setting is designed for that case. You can only
get the MAC of the day. 06:38:47 Éric Vyncke

please be sure to also have this discussion over the mailing list
06:38:53
Mohamed Boucadair
@cullen: that one can be solved typically by tweaking the implem to align with
the lease times
06:38:55
Tirumaleswar Reddy.K
This is the same problem if a extender is used in the home network, CPE will see
actual MAC of the endpoint.
06:38:58
Andrew Campling
Either Jason has a very fast fan or is that a strobing light?
06:39:04
mcr
@sftcd, I don’t know how often ISPs use the features to help users figure out
what’s broken in their home. I’ve seen the demo, consulted for a company that
built TR-069 stuff, but not recently. Phil Stanhope would have more data about
how often this stuff is used/demanded by ISPs. For sure comcast has that stuff.
06:39:34
sftcd
in my locale open wifi with no key is v. rare in hotels etc. and mostly people
use their mobile data anyway these days, I’d guess it’s nowhere as big a deal as
>5 years ago
06:39:37
Jari Arkko
@mcr yes you would reveal yourself if you were testing for the need for the web
page login, but of course you could also play tricks, like remembering the
nature of this network (so you won’t do it the next time), or probe with a
random address on the first attempt, etc. But it is also possible that such
tricks could interact with some enterprise network practices (e.g., getting to a
“unregistered device, go away” page of the network.
06:40:35
sftcd
“stored in the cloud” ? by whom for what?
06:41:10
mcr
@sftcd, open wifi (no key) is ubiquitos here: mcdonalds, tim hortons [at the end
of every block in Canada],… poorer students actually depend upon it (having
limited to no data plans, because we suck in Canada), and it proved an eye
opener during pandemic.
06:41:24
Éric Vyncke
@stephen possible a hot spot operator ? or roaming operator based on MAC ?
06:41:49
Jason Weil
sorry for the fan strobe
06:41:53
sftcd
@mcr: right, so the relative importance is locale dependent
06:41:54
Dan Harkins
MAC randomization is actually a blessing for the parental controls/content
access use case because any product that attempted to provide that service based
on a MAC is a POS and it would be a matter of days until all the neighbor kids
all knew how to get around it. Randomization will force these people to make a
more robust product.
06:42:16
dkg
30× a few 6 octets is still just 180 octets
06:42:17
Bob Hinden
That sounds odd, grows “astronomically” when there are 30 mac addresses in a
month. Sounds broken.
06:42:32
Tim Cappalli
+1 Dan
06:42:38
Cullen Jennings
pretty skeptical that this database size is very relevant for a SP with less
that a trillion users
06:42:49
sftcd
I’m still unclear as to whose cloud for what on that last slide (maybe I’ll
remember to ask @ the end :-)
06:42:50
Tim Cappalli
MAC-based authorization has been a ridiculous excuse to be lazy
06:42:51
Tirumaleswar Reddy.K
+1 Tim
06:43:04
Tim Cappalli
there are more options than ever to solve this but OS vendors won’t implement
them 06:43:08 Jen Linkova Maybe it’s a time to stop using a MAC address as a
device ID? MAC address has a link-local significance, why would cloud-based
management system care? 06:43:08 Tim Cappalli WPA3 SAE Password ID is the best
example 06:43:13 Yes Jen!!! 06:43:24 Bob Hinden Jen: +1 06:43:26 Tirumaleswar
Reddy.K Attacker can easily spoof MAC addresses 06:43:28 Tim Cappalli It should
NEVER have been used in the first place 06:43:33 Laziness instead of addressing
the problem as an industry 06:43:40 Tirumaleswar Reddy.K MAC is a weak identity
for policy enforcement 06:43:44 Erik Kline hence this BoF… 06:43:49 mcr @Jen,
really it comes down to: we don’t have another hammer. I hope that this BOF
will give us some new hammers. 06:43:52 Alister Winfield I might agree but
alternatives haven’t been wonderfully supported by IOT and are or at least were
a pain for non-techs. 06:43:52 dkg i also want to know which cloud provider is
storing this stuff 06:43:54 sftcd that last slide also assumed “identity” ==
“MAC addr” which is part of the dodginess 06:44:01 Tim Cappalli The lack of
consistent onboarding across operating systems is the #1 problem for
enterprise. 06:44:02 Peter van Dijk speaker is Malay Vadher of plume.com
06:44:21 Dave Thaler @sftcd “doesn’t DHCP itself let me ask for the same IP the
2nd time?” just found your question. Yes, it does. (And that’s one thing you
clear when changing your MAC) 06:44:41 mcr @dkg, anyone running any kind of
hotel/pub in any of the many countries (like Switzerland), which have to keep
records for all Internet use. This is why they SMS you a login key at, e.g. the
Zurich. Prague,etc. airport 06:45:11 clearly, that’s something people would
want to outsource. 06:45:25 dkg mcr: yeah that doesn’t work well for those of
us without SMS :/ 06:45:30 sftcd @thaler: ta, must try see what happens with
linux sometime (probably not during this call though:-) 06:45:34 Andrew
Campling Stating why people shouldn’t do x doesn’t mean that it doesn’t happen
and isn’t common practice 06:45:34 Tim Cappalli @dkg, hence the captive portal
vendors who are pissed off ;) 06:45:40 Bob Hinden It’s not like they didn’t
have a lot of warning. 06:46:02 Tim Cappalli ^ Exactly. 06:46:09 Dan Harkins
@bob +1 06:46:12 mcr @dkg, yeah, so at least in one airport, I went to the info
booth, and they understand, and I show them my password, and they give me a
code from a printer that they have there just for this purpose. 06:46:12 dkg
(fwiw, i think data retention laws like the ones mcr describes are really
problematic on their own) 06:46:20 sftcd @AndrewC: that’s true, is it also true
that some in-store advertising (ab)use MAC addrs too? 06:46:33 dkg @mcr,
s/password/passport/ ? 06:46:41 mcr @dkg, sure. Of course we can complain about
evil countries that insist on stuff. 06:46:46 sftcd what’s MBO? 06:47:00 mcr
nope, @dkg, passport. I have to give them an identity to which they could link
my activity. 06:47:05 Adam Wiethuechter MAC address and/or IP address should be
a localized scope and granted (on a limited time basis) to an device using
Identity with a clear chain of ownership and way to prove it. – just my
opinion. It seems this is the promised land we want to get as close to as
possible 06:47:20 Peter van Dijk multi band operation (2.4ghz, 5ghz, etc.) i
think 06:47:25 Tim Cappalli Multi Band Operation 06:47:33 sftcd ta 06:47:35 dkg
@mcr: that’s what i thought – you said “password” so i was a bit confused :)
06:47:42 Adam Wiethuechter or rather granted based on policy 06:47:44 Tim
Cappalli +1 Adam 06:47:45 MAC should be ephemeral like IP 06:47:51 mcr oh.
sorry. I see. yes, my typo. I thought you were saying the opposite. 06:48:12
dkg i know how to use sed! 😛 06:48:29 Adam Wiethuechter I don’t want to say
this but its the ID/Loc problem all over again, just lower down the stack
06:48:40 Tim Cappalli same argument about IP-based access lists / firewall
policies. Identity should be driving policy, not ephemeral identifiers 06:48:44
mcr But, when the Swiss police want to see my password, I always ask to see
their password first. 06:48:49 dkg Adam, we have this problem up and down the
stack 06:48:55 Stuart Card +1 @adamW 06:49:05 sftcd MBO and reasonably
persistent - surely that’d only be for seconds? if not I don’t get why 06:49:10
Adam Wiethuechter This is true and a shame @dkg 06:49:13 sftcd how many is
many? 06:49:28 Adam Wiethuechter Many 06:49:32 sftcd is many > most? 06:49:42
dkg sftcd, what do you think we are, engineers? 06:49:48 Éric Vyncke This MBO
issue looks limited to layer-2 and should probably be better handled by IEEE
06:49:51 Adam Wiethuechter Sorry I couldn’t resist :p 06:49:51 Tim Cappalli I
don’t see how MBO would be impacted 06:50:03 Dan Harkins MBO is definitely an
IEEE 802.11 issue. 06:50:04 11bh and/or 11bi will deal with that. 06:50:31 Éric
Vyncke thx Dan 06:50:41 Tim Cappalli Depends on who you ask. Bunch of folks are
convinced this will be reverted. 06:50:49 Andrew Campling @Dan what about the
many legacy devices? 06:51:32 Ben Campbell My search-fu is weak. Can someone
expand “MBO”? 06:51:45 Dan Harkins what about them? 06:51:46 Tim Cappalli
https://wi-fi.org/discover-wi-fi/wi-fi-agile-multiband 06:51:57 Dan Harkins
Multi-Band Operations… 06:51:58 Ben Campbell thanks! 06:52:04 Cullen Jennings
plume.com 06:52:19 Peter van Dijk plume.com 06:52:22 sftcd yeah, I’ve never
heard of 'em 06:52:46 sorry;-) 06:52:48 Kannan Jayaraman aren’t there
implications for overlay routing such as vxlan evpn… they deal with MAC moves
but this scenario needs to be handled as well I guess 06:52:49 Tim Cappalli
Every kid over the age of 5 knows how to bypass that 06:53:08 Sigh 06:53:19
Jason Weil over 9 I would agree 06:53:28 Bob Hinden Tim: Yes!!! 06:53:33 Dan
Harkins kids pray their idiot parents buy software that restricts by MAC
address. 06:53:38 Tim Cappalli We really need to bring reality into this
conversation IMO 06:53:48 sftcd if there’s a blocker locally I don’t get why
MACs need to goto anyone’s “cloud” 06:53:57 Jerome Henry @Ben MBO exists in 2
names, Multi Band Operations (MBO) is somewhat of an internal code name at the
WiFI Alliance, while Agile Multiband that Tim pointed to is the public name of
the group/project 06:54:02 Cullen Jennings But this does has an upside, this is
how 9 year ;-)old kids are learning networking 06:54:05 Peter van Dijk we’re
educating tomorrow’s hackers ;) 06:54:15 mcr @sftcd, so as a higher-level
thing, see:
https://www.ripe.net/ripe/mail/arch…ves/iot-wg/2020-October/000537.html They
are among those doing proprietary APIs into home routers. This is a place where
the IETF needs to do something, and this (replacing MAC address as identifier)
might be the leverage we need bring these efforts into the fold! 06:54:41 Jen
Linkova Parents ;))) AFAIR one of New York airports was providing first 30mins
of WiFI free of charge… 06:54:47 Dan Harkins the MBO issue is that an AP may
have lots of clients one one band and wants to steer clients that are able to a
different band. 06:54:48 Ben Campbell @Jerome: Thanks, got it. Was just having
a moment of ADC (Acronym Database Corruption) 06:54:54 Jen Linkova based on
MAC… 06:54:55 Dan Harkins it’s a problem but it’s very specific to 802.11
06:55:04 sftcd /me did try look at plume.com’s web page but NoScript means I
get a blank black page;-) 06:55:13 Tim Cappalli Exactly!!! 06:56:14 You just
proved the point. 06:56:17 There are so many other places in the stack to worry
about this 06:56:27 Unless you MDM your kids phone, its pointless 06:56:41 dkg
so the lesson i’m hearing is that these parental controls don’t work against a
marginally-competent adversary 06:56:42 mcr The right answer is that the parent
device has to be clearly identified (with a unique PSK or WPA-Enterprise), so
that it can’t be spoofed. We had a thread on the ML about this. We can’t
denylist devices (because they change identity), we have to acceptlist devices.
06:56:54 sftcd @dkg: hardly a surprise 06:56:58 Tim Cappalli Not to mention all
these kids have unlimited data plans (in the US at least) 06:57:09 sftcd @mcr:
IMO the “right” answer is to educate the kids, but I accept that many people do
go for the net nanny thing 06:57:24 Tim Cappalli There is no impact to secure
authentication methods 06:58:04 OpenRoaming is an implementation of Passpoint
which uses 802.1X 06:58:14 Alissa Cooper Ok 06:58:35 Tim Cappalli When deployed
properly, a device or user identity is protected inside a TLS session 06:58:37
*channel 06:58:44 Right now, the only secure deployment method that works
across all operating systems is EAP-TTLS/PAP or EAP-TTLS/MSCHAPv2 06:59:10 Adam
Wiethuechter @Tim - if this kind of problem is all over the stack (which we
know it is - if you are referring to the problem I mentioned early) I guess the
next question is what are the minimum piece(s) we can change to undo the damage
caused by it existing for so long (and being worked around by the lazy)?
06:59:20 Tim Cappalli TEAP Is a close second but isn’t supported in the Apple
ecosystem unfortunately 06:59:22 dkg “trust between client and network” should
be bidirectional 06:59:49 Dan Harkins identifiers are not provided
pre-association… 06:59:54 mcr @Tim, this is the harder problem in my house. I
could go check to see if my kid really went to bed without his phone when he
said he did… I don’t have much in the way of netnanny, but I don’t like getting
overage bills (because he doesn’t have unlimited, and he thought he was on
wifi. My kid is (unfortunately) not motivated like this. [Maybe I should setup
netnanny so he’ll learn to hack more.]. BUT, I’m more concerned about
mild-malware on various devices which my kid does not recognize. 06:59:58 Tim
Cappalli @Adam, OS vendors need to implement consistent onboarding for secure
networks and add support for things like WPA3 SAE Password ID for home use
06:59:58 Adam Wiethuechter +1 dkg 06:59:59 Jerome Henry OR has this ability to
allow anonymity at the access while still ensuring authentication to the IdP,
so it is a good form to complement RCM intent 07:00:05 dkg the text here
implies that that client is obliged to prove itself to the network, but doesn’t
mention the other way around 07:00:18 Tim Cappalli @Jerome, anonymity can only
be guaranteed with a tunneled EAP method. 07:00:31 Stuart Card former EU
research project ABC4trust: Attribute Based Credentials, selectively revealed,
with selective linkability 07:00:43 Jerome Henry @Tim agree 07:00:48 Mohamed
Boucadair @dkg: the list is not exhaustive 07:00:49 Tim Cappalli As of right
now, while EAP-TLS is the most secure, it is not privacy preserving 07:00:51
Dan Harkins @dkg, that’s because this is coming from the point of view of the
network providers. 07:01:02 Malay Vadher Also, the percentage of kids bypassing
the network to get their way out is way less than the ones managed. Ofcourse,
it is sensitive topic and should managed tactfully. 07:01:20 Dan Harkins all
these guys want to get an identifier for clients 07:01:20 mcr EAP-TLS1.3 would
be better. 07:01:23 Dan Harkins they don’t care about providing anything TO the
clients 07:01:31 Jen Linkova “another reason to move to Ipv6: no DHCP pool
exhaustion anymore” ;-) 07:01:34 dkg Dan: you’d think that they’d want to also
prevent other people from impersonating their networks 07:01:39 Tim Cappalli
Yes, 1.3 would eliminate the privacy concerns 07:01:40 Stuart Card Does the
identifier even need to be presented in cleartext for all uses? 07:01:48 dkg i
mean, i can name my home wifi network “xfinity WiFi” too 07:01:52 Tim Cappalli
but that atrocious onboarding experience on operating systems is the current
problem 07:01:54 Dan Harkins that can be done in the security handshaking
(802.1X or SAE). 07:02:07 Tim Cappalli with no end in sight 07:02:07 Jerome
Henry The interesting part of OR in this context is that it allows the STA to
‘not’ prove its identity to the access network 07:02:16 but that identity part
needs to be secure and protected indeed 07:02:36 Alissa Cooper I think framing
this as “the identifier” maybe isn’t a great place to start given the diversity
of uses here. 07:02:48 Tim Cappalli There is very little value in home IoT /
headless devices randomizing MACs 07:02:56 Mohamed Boucadair Fair point from
Cullen 07:02:57 dkg +1 Alissa 07:02:59 sftcd +1 to alissa 07:03:00 Dave Thaler
+1 Alissa 07:03:02 Tim Cappalli today, I’m not aware of a single one that does
07:03:02 Dan Harkins you can say you’re “xfiniti wifi” but if there’s a
credential needed for access then the rogue should be detected. 07:03:06 Bob
Hinden Are they saying that since Mac addresses are changing frequently, there
is a need for a stable identifier that defeats the purpose of random mac
addresses? 07:03:06 Dave Thaler say at mic alissa :) 07:03:16 dkg Dan Harkins:
whose credential is needed? 07:03:28 Tim Cappalli @Bob, the key is that it is
not clear OTA 07:03:37 Adam Wiethuechter +1 Alissa - we can probably never
attain the “golden identifier” 07:03:43 Andrew Campling @Dan this is another
example of developers and network operators not understanding each other’s
needs and ways of working well. The BOF seems to be helping bridge that gap a
little. 07:03:49 dkg i can just spoof any login prompt that xfinity typically
offers, and then accept all credentials supplied 07:03:50 Dan Harkins either a
verifiable cert or a shared PSK/password. 07:04:04 dkg Dan: you mean that the
client provides those things? 07:04:19 Mohamed Boucadair @Adam: That is why the
slide says “different use cases have different …” 07:04:31 dkg or you mean the
client OS somehow enforces that the network proves posession of those things
first? 07:04:45 Dan Harkins I mean the client will get a cert for the network
it is trying to connect to. 07:04:46 Toerless Eckert limited number of
identifiers ? 07:05:02 Tim Cappalli The level of friction is the #1 problem
right now 07:05:02 dkg not on the xfinity APs i see near me :/ 07:05:03 Adam
Wiethuechter @Mohamed - fair point 07:05:06 Tim Cappalli there is TOO much
friction 07:05:23 Dan Harkins Given how whacked EAP policy is, though, it is
not inconceivable that having a public CA signed certificate (for a web server)
used in an EAP server could authenticated basically any SSID.I could be “cisco”
with a letsencrypt cert for my personal domain. 07:05:56 dkg that would be an
interesting experiment to run if we ever have an in-person IETF again 07:06:36
Tim Cappalli @ Dan, a properly configured supplicant wouldn’t have that issue
07:06:55 Dan Harkins It used to be that clients just ignored server cert
validation. But OS vendors turned that on by default. So providers just got any
old cert (for a use that it was not provided for) and used it for an EAP
server. 07:08:08 @tim, where is this properly configured supplicant of which
you speak? 07:08:43 Alister Winfield hahaha… properly configured is such a big
assumption 07:08:46 Adam Wiethuechter Love what you said Tim! 07:08:48 Dan
Harkins :-) 07:08:50 dkg no true scotsman 07:08:55 Stuart Card I stand by my
point. Think about DoS. 07:09:04 Tim Cappalli @Dan, "It used to be that clients
just ignored server cert validation. " this is not accurate at all 07:09:20
behaviors have changed, yes, but no user-centric client blatantly ignores EAP
server identity without being confifured to do so 07:09:43 Dave Thaler @dkg
going back to your question about the hash, I suspect the answer is the secret
is a secret-of-the-day so it’s not generated per SSID but rather 1 per day, but
need to verify 07:09:46 Tim Cappalli *configured 07:09:47 dkg Dave Thaler:
thanks for looking into that. i’d be interested to read followup about it.
maybe on madinas@ietf.org ? 07:10:51 Dave Thaler and the hash is just for perf
since it’s faster than generating a new cryptographically random secret
07:10:51 Mohamed Boucadair @Stephen: fair point. This is captured in the last
bullet of slide 12 07:11:33 dkg Dave Thaler: the other reason to use a hash
here would be if the public identifier is treated as some sort of “commitment”
– where they want to be able to reveal the secret later to prove commitment to
the other data 07:12:02 i don’t know of such a use case in this domain though
07:12:16 Tim Cappalli @Tommy, that’s why its important to distinguish OTA vs
encapsulated in another exchange 07:12:23 Dave Thaler ack 07:12:25 Stuart Card
+1 Tommy Pauly 07:12:48 dkg +1 Tommy 07:12:48 Adam Wiethuechter Maybe out of
scope (or over reaching) but what about client trusting others on the network
(aka its peers)? 07:13:10 sftcd +1 to Tommy too (though /me thinks about Mr.
Schrems:-) 07:13:19 Cullen Jennings Listening to Tommy and thinking about what
I am seeing on mdns right now 07:13:20 mcr I like the idea of showing up on a
network, and just BLASTING my identity. Disaster Area style. 07:13:31 Adam
Wiethuechter Probably inherited from the network trust, but might be different?
07:13:32 Ben Campbell +1 to all the people +1’ing Tommy 07:13:34 Peter van Dijk
Cullen, do you have a two line summary of what’s happening on mdns? 07:13:39
dkg Peter: i think he might mean “i’m scanning my local network’s mdns traffic”
07:14:26 Tim Cappalli +1000 Jari. Everything is available to solve this problem
today. We just need people to implement it, consistently. 07:14:27 Bob Hinden I
am wondering if this is actually something the IETF can solve. 07:14:45 Tim
Cappalli @Bob, I don’t think so. It is an adoption problem 07:14:57 Cullen
Jennings yah a tone of apple devices in the hotel is sending me data that
identify them with a stable indetifier 07:14:59 dkg Cullen, but i thought “what
happens on your iPhone stays on your iPhone” 07:15:21 Tim Cappalli Wi-Fi
Alliance + Network Vendors + OS Vendors are who can solve this 07:15:27 Tommy
Pauly @Cullen yeah, that’s a thing we need to work on… 07:15:30 mcr Cullen,
what’s a hotel? 07:15:31 Dave Thaler hotel: a quaint concept 07:15:43 Jason
Weil +1 Tommy mic comment, some way for the end user to attest to the
trustability of the network they are joining is important as is the network
admin’s ability to trust the person coming on the network 07:15:45 sftcd @mcr:
it’s a thing with closed doors 07:15:49 Adam Wiethuechter +1 to Tim and to add
to the answer Tim gave Bob - its getting others to adopt and consistently
implement these things but have the IETF start to find the gaps and weakness
that are still there (some which we can solve, or point out to other SDOs)
07:15:57 Its probably going to be a slow process :/ 07:16:28 mcr [I considered
a hotel/airbnb for the week, so I could sleep during the “day”, but then
realized that I’d have crappy wifi, and wouldn’t have my two monitors, desk…]
07:16:34 Peter van Dijk mcr, maybe send the rest of your household to the
airbnb instead :) 07:16:58 Deb Cooley you just needed one close to home.
07:17:03 commute home to work, to the hotel to sleep. 07:17:14 Dave Thaler I
almost had to use a hotel for this meeting when my internet/cable/phone went
down a couple hours before this meeting. Fortunately it came back just in time.
07:17:38 Cullen Jennings @tommy - agree on all your points. And MDNS has made
it so I no longer have to explain to relatives how to set up their printer so
it’s a good thing (at least for printers) 07:18:08 mcr [yes, I thought about
commuting.] Hey... hotel user... for you my friend! Special Deal! You tell me
digits 5 and 9 of your CC, and I’ll give you IPv6? 07:18:11 it does seem like
the place for some kind of zero-knowledge proof. 07:19:03 Phillip Hallam-Baker
User identifiers are things that should really only be created at application
level. 07:19:40 sftcd @jari: I doubt anything near all the people who want
better privacy know the HOWTO 07:19:48 mcr ... and we have the people who don’t
know what they need to use, because they aren’t competent to know (kids, IoT
devices, grandparents...) 07:19:52 Erik Kline It would still be relying on
TOFU, but we could extend the capport API with some link to/means to install a
network-generated cert for the client to use for the network (and a cert to
expect for the network when attaching to the same ESSID regardless of BSSID).
07:21:55 Bob Moskowitz As we have covered in DRIP, any text stream is totally
spoofable and unreliable. If you want to do anything reliable, you need to add
some level of cryptographic operation. 802.1AE has done this for 802.3 and of
course 802.11 has its various versions of authenticated frames. We are
basically doomed to failure just working within the framework of MAC addresses.
It will take a major tech lift to change the game. :( 07:22:30 Toerless Eckert
+1 on Bob 07:22:56 Jari Arkko @sftcd and @mcr: yes but would new technology
help them in some fashion? Shouldn’t you be setting the configuration properly
already for your IoT devices and kids? And if there’s a case where you don’t
know what the right answer is, do we know that new option would help find the
right answer? Wouldn’t that just be a new option that can’t be turned in all
networks, making your configuration decision a bit harder, not easier? 07:23:15
Stuart Card I coined a word years ago – “varinymity” – a knob from strongly
protect anonymity, to strongly verified meat identity, through a spectrum of
pseudonyms – negotiable between peers before a transaction begins 07:23:16 Tim
Cappalli @Erik, certainly possible but the goal should be to get rid of captive
portals, not keep them alive 07:23:23 Bob Hinden I agree with Bob too 07:23:23
Adam Wiethuechter +1 Bob and +1 Stu 07:23:50 Erik Kline @Tim a capport API
doesn’t mean the network restricts your access 07:23:51 (we ran an experiment
on IETF 106 network) 07:24:03 sftcd @jari: I didn’t mean to suggest some new
tech would “solve” this stuff, but fair point 07:24:06 Tim Cappalli @Erik, but
it does mean you have existing L3 access 07:24:12 Erik Kline yup 07:24:22 mcr
@jari, in order for me to setup the configurationf or the IoT device, then I
need a standard protocol to interact with them. So yes, I’d like that. 07:24:31
Erik Kline (hence some TOFU) 07:24:34 mcr I totally disagree: only the IETF can
deal with this, because the L2 SDOs have never gotten identity, and they don’t
own EAP or portals or ... 07:26:18 sftcd In terms of possible IETF stuff, I
guess https://tools.ietf.org/html/rfc7819 covers some of the ground - I think
there was another DHCP privacy RFC that Christian H helped with but didn’t find
it yet 07:26:25 Erik Kline The TLS cert in the capport API can be used to
identify the network 07:27:28 sftcd I guess https://tools.ietf.org/html/rfc7824
as well 07:27:55 dkg Tim’s right that these other questions are relevant – but
that means that we have to work on it in the IETF (because pieces of the
problem are touched here) as well as working on it with other SDOs. 07:28:02
Tim Cappalli @Erik, its a weak binding though 07:28:05 Jason Weil The IEEE,
WBA, WFA are all working on it. But upper layer protocols developed here need
to stay in sync and design at the app layer when needed. 07:28:17 Stuart Card
@mcr: identity is neither solely in the subject nor solely in the object, but
in their relationship? I am feeling mystical... 07:28:32 Mohamed Boucadair
@sftcd: https://tools.ietf.org/html/rfc7844? 07:28:39 Carlos Bernardos
https://tools.ietf.org/html/rfc7844 as well I think 07:28:41 Tommy Pauly We can
use the CAPPORT or PvD binding to at least have some consistent TLS identity
for a network entity from time to time 07:28:46 sftcd that’s it thanks 07:28:52
Erik Kline @Tim: many devices to make-before-break now so it’s okay to “join
the network” and do some dance before turning the device over to regular
applications 07:29:06 Andrew Campling @Simon a quantum identity? 07:29:07 Tim
Cappalli an SSID can’t be bound to a web server 07:29:17 mcr the SSID can’t be
bound to anything really. It’s a disaster. 07:30:01 Tommy Pauly Do I need to
bind to the SSID? What if instead I bind to the TLS identity of the PvD or
CAPPORT API? 07:30:11 Tim Cappalli Yep. But the auth session can be (aka EAP)
07:30:16 Andrew Campling This does seem to be a problem that the IETF should
work on, probably with some liaison with other SDOs along the way 07:30:19 dkg
the trouble is that the general public only sees the SSID – so that’s the thing
to bind to 07:30:37 sftcd @andrew: work on to do what? not clear to me 07:30:39
Stuart Card @andrew: although your comment looks partly tongue in cheek, I
share what I think is your intuition that there is something deep here... e.g.
quantum coherence time seems a parallel with some of these issues... 07:30:43
dkg just like how domain name is really the only thing that we bind to in the
web context 07:30:57 Éric Vyncke JC is right, the BoF purpose is not to design
a new identifier 07:31:10 Tim Cappalli @dkg, and Passpoint improves that by
adding an organizatin name. in the same way that EV certs enhance domain
presentation 07:31:12 Tommy Pauly @dkg Agreed, but it’s possible to change
that. Ultimately if I can have some other name to show (a domain name) for
network owner, that can end up supplanting SSID 07:31:14 Tim Cappalli (well,
did) 07:31:28 dkg Tim Cappalli: and look what happened to EV certs 07:31:30
sftcd @Tim: /me disparages EV certs - they add $1000 or so is all:-) 07:31:32
Tim Cappalli Just because browsers decided against EV certs, doesn’t make them
wrong for other use cases 07:31:46 sftcd nor does it make 'em right 07:31:55
dkg sure, but it’s worth understanding why they failed 07:32:02 Erik Kline
non-SSID identifiers for networks could help client figure out that
CoffeeShop-5GHz and CoffeeShop-2.4GHz are the same network 07:32:11 Tim
Cappalli Sure, but it works pretty damn well today with Passpoint R2 07:32:11
Dan Harkins in the web context the client is getting a page served from a
particular domain. But with an SSID it’s… what? “my temporary connection to the
Internet”? 07:32:16 Tim Cappalli and that is why Passpoint is valuable. There
is no SSID binding 07:32:37 Its an identity binding 07:32:41 Andrew Campling
@sftcd to agree and then solve the agreed use case requirements in a reliable
manner that works at all layers as appropriate 07:32:43 Dan Harkins validating
a cert for a web server makes sense. Validating a web server for an SSID
doesn’t really. 07:32:49 I meant, validating a cert for an SSID doesn’t make
sense. 07:33:24 sftcd @andrew: not trying to be obtuse, but I’m not seeing it
(maybe list discussion will turn up something but for now I don’t get what the
IETF can usefully do here other than chat) 07:33:27 Stuart Card @DanH why not?
07:33:59 Andrew Campling @sftcd My take from the discussion so far is that
there is evidence of problems to solve to facilitate better functioning of the
Internet experience for users 07:35:46 Dan Harkins because what is the
validation step the CA would go through for an SSID? 07:36:32 Tim Cappalli It
should ONLY apply at L4 and higher 07:36:34 sftcd @andrew: what I’m not seeing
is the IETF’s role in trying to “solve” those but I may be wrong 07:36:35
Mohamed Boucadair Agree wit Bob. This is why slide 12 says that some use cases
can be solved by tweaking the implementations, but this is not easy/feasible
for all of them (especially, within the home). 07:36:56 Tim Cappalli Well, it
depends on whether we consider adding support for existing protocols to
“tweaking the implementations” ;) 07:37:29 Mohamed Boucadair that is not
excluded :-) 07:37:42 Tim Cappalli I have yet to hear a use case on this call
that wouldn’t be solved by an existing authentication method 07:38:03 Home is
being held back by lack of support for WPA3 SAE Password ID by OS vendors
07:38:28 Alissa Cooper maybe would be good to catalogue the existing auth
methods and map them to these use cases on the list 07:38:35 Tim Cappalli Good
idea @Alissa 07:38:43 Mohamed Boucadair agree 07:38:52 Stuart Card @Andrew CA
hierarchy is not the only way of doing certificates 07:38:54 Alister Winfield
But I suspect that most of those authentication methods would fail badly in the
case of the technical ability of common users and OS implementations. 07:38:56
Stuart Card sorry meant @DanH 07:39:34 Alissa Cooper Alister that would be a
useful analysis to have as well 07:39:58 mcr tied up in ace, but I think that
this work has to get done at the IETF (with liason), but we need to lead it,
because the identity technologies that we need to adapt are ours. I am
interested. 07:40:01 Adam Wiethuechter Agreed @mcr 07:40:29 Andrew Campling
This is better than the virtual hum! 07:40:43 Tim Cappalli Hehe, that’s my
favorite feature 07:40:44 sftcd If this were f2f I’d quibble with the question:
I’m interested but not in the use-cases presented as needing work, my interest
would be in attempted solutions for those not being horrible;-) 07:41:59 Dan
Harkins @stuart what are you suggesting? 07:42:08 dkg it would be nice to have
an option to explicitly say “don’t know” as a way to distinguish from “i’m
actually asleep but my browser is connected” 07:42:40 Kirsty P Why are there
111 participants in this meeting but only 100 on the voting hands tool?
07:42:43 Alissa Cooper I think more discussion is needed before q2 can be
ansswered 07:42:44 sftcd the lack of a “need more info” option is clear here
07:42:48 Peter van Dijk @dkg i was just typing that 07:42:50 Bob Hinden I agree
with Alissa 07:42:56 dkg Alissa +1 07:43:03 Stuart Card @DanH: often, I do not
need to prove that I am Stu, merely that I am the same guy you saw yesterday,
and/or that I have certain attributes 07:43:04 Bob Moskowitz I am looking at
draft-huque-dane-client-cert-04.txt as an alternative to traditional CA
07:43:06 Peter van Dijk i have no idea if action is required but i the
conversation is important to me 07:43:08 Alissa Cooper @Kirsty the roster
double-counts people who are logged in via jabber separate from Meetecho, the
raise-hands tool does not 07:43:21 mcr @Bob, so if you feel that there is NO
IETF action, then you could vote no. 07:43:43 If the majority said that, then
that would mean something. 07:43:56 Adam Wiethuechter I’d argue having a deeper
conversation is an action in some capacity 07:44:01 Bob Hinden But what?
07:44:04 Jari Arkko I think “more research needed” is the right answer here,
but “action required by the IETF” is way way too early 07:44:07 Bob Moskowitz I
tried logging in to Jabber as “Robert Moskowitz” and got an auth failure as
already logged in (via Meetecho). 07:44:08 Dan Harkins @stuart but you are you
day after day regardless of SSID. 07:44:18 Stuart Card I submit that many of us
already are working on “this topic”, which is an elephant with many aspects.
07:44:25 Glenn Deen There clearly is an operator need here. 07:44:44 Peter van
Dijk @stuart well put, yes 07:44:45 Alissa Cooper sorry, double-counts was not
the right word, the roster includes people who are jabber-only 07:44:58 Andrew
Campling I assume that “some work” here may be to continue the discussion and
understand the issues better 07:45:05 dkg Alissa, that is indeed a double-count
for many of us though 07:45:22 Stuart Card @DanH perhaps I would like to know
that the SSID to which I am connecting today is the same SSID to which I
connected yesterday, and still has the same attributes? 07:45:25 Meetecho Bob
Moskowitz: you cannot join a jabber room more than once with the same display
name at the same time. Possibly your jabber client is not handling the conflict
gracefully? 07:45:31 mcr @Moskowitz you need to pick a different nick/resource.
07:45:32 Jason Weil I think that is fair @Andrew 07:45:34 Glenn Deen +1 AC
07:45:54 (campling) 07:46:03 Bob Moskowitz Pidgin 07:46:08 sftcd FWIW, I
wouldn’t put much weight on the numbers resulting from those questions at all
07:46:09 about the most I’d get is “keep at it on the mailing list” 07:46:40
Joey Salazar +1 dkg 07:46:44 mcr @dkg, I have a whole folder full of bad ideas,
if you have time. 07:46:49 dkg mcr: ha ha 07:47:04 it can’t be bigger than my
folder of bad ideas! 07:47:12 mcr WBA? 07:47:16 sftcd something to do with
boxing 07:47:27 mcr WFA? 07:47:33 Tim Cappalli Wireless Broadband Alliance
07:47:37 Wi-Fi Alliance 07:47:41 https://wballiance.com/ 07:47:58 Jason Weil Do
we have a liaison with either of those orgs? 07:48:12 Tim Cappalli
https://www.wi-fi.org/ 07:48:14 Andrew Campling @dkg I suspect that
participants here (me included) could probably fill the agenda for IETF 110
with bad ideas 07:48:16 sftcd @jason: don’t believe we liaise with 'em, but
informal is better when possible mostly 07:48:34 HAIGUANG Wang Maybe I just
type here 07:48:37 Jason Weil sounds good, I see a few people here involved
with WFA so that shouldn’t be a problem 07:49:20 HAIGUANG Wang I suggest we
send a liasion statement to IEEE 802.11 group to get their opnion. 07:49:22
Jerome Henry @Haiguang fully agree 07:49:44 Tim Cappalli WFA has already.
created all the solutions 07:49:44 WBA is already telling people to deploy the
solutions :) 07:49:54 mcr oh, yes, the Wireless Broadband Alliance… They took
some interest in CAPPORT, but not really that much. 07:49:56 I got none of
that. Maybe just me. Yup, probably just me. 07:50:33 Yiu Lee We should also
investigate whether BBF is working on similar problem or not. 07:50:33 Peter
van Dijk thank you all 07:50:57 Éric Vyncke thank you all 07:50:57 Tim Cappalli
thanks all 07:51:01 Jason Weil Thanks all 07:51:06 Glenn Deen cheers all
07:51:07 Bob Hinden Good night 07:51:08 Éric Vyncke Coffee time ! 07:51:16 Yiu
Lee Thanks for the Chairs and AD, and everybody who joined. Nice BoF! 07:51:20
Slides

Chairs' Intro Slides
Background and status about MAC address randomization in IEEE802 and WBA
MAC address randomization in Windows 10
MADINAS use cases
Chairs' Final Slide