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