[00:35:08] metricamerica leaves the room
[00:36:08] mjenkins joins the room
[04:16:16] behcet joins the room
[04:18:02] behcet leaves the room
[04:49:15] Meetecho joins the room
[04:50:03] Marc Portoles-Comeras joins the room
[04:50:03] Glenn Parsons joins the room
[04:50:03] Carlos Bernardos joins the room
[04:50:03] laxmi mukund joins the room
[04:50:03] Nalini Elkins joins the room
[04:50:03] Michael Jenkins joins the room
[04:50:03] Paolo Saviano joins the room
[04:50:03] Chunshan Xiong joins the room
[04:50:03] Sun Kj joins the room
[04:50:03] Stephen Farrell joins the room
[04:50:03] Dave Thaler joins the room
[04:50:03] Tobia Castaldi joins the room
[04:50:28] Bob Hinden joins the room
[04:50:32] Dan Harkins joins the room
[04:50:42] Cullen Jennings joins the room
[04:50:51] Peter van Dijk joins the room
[04:50:52] Jason Weil joins the room
[04:51:08] behcet joins the room
[04:51:11] <Peter van Dijk> very good very morning!
[04:51:22] Michael Richardson joins the room
[04:51:23] Yiu Lee joins the room
[04:51:27] Erik Kline joins the room
[04:51:28] Alexandre Petrescu joins the room
[04:51:34] <Dan Harkins> and a good evening to you sir!
[04:51:47] <Peter van Dijk> good evening :)
[04:51:53] Deb Cooley joins the room
[04:52:02] Kirsty P joins the room
[04:52:25] Deb Cooley leaves the room
[04:52:30] Deb Cooley joins the room
[04:52:38] Mohamed Boucadair joins the room
[04:52:40] <Jason Weil> I guess technically it will be morning here when we begin at 12 :)
[04:52:47] Mark McFadden joins the room
[04:52:48] Alister Winfield joins the room
[04:52:49] Kirsty P leaves the room
[04:53:02] tim costello joins the room
[04:53:06] Kirsty P joins the room
[04:53:09] <Peter van Dijk> hah yes
[04:53:19] <Peter van Dijk> will be 6AM here then :)
[04:53:22] Adam Wiethuechter joins the room
[04:53:26] Mohamed Boucadair leaves the room
[04:53:30] Deb Cooley leaves the room
[04:53:40] Yoshifumi Atarashi joins the room
[04:53:49] Tommy Pauly joins the room
[04:53:52] Mohamed Boucadair joins the room
[04:54:12] David Luu joins the room
[04:54:15] David Luu leaves the room
[04:54:17] Rohit Abhishek joins the room
[04:54:18] David Luu joins the room
[04:54:45] Mohamed Boucadair leaves the room
[04:54:52] <Jason Weil> Ah you will get to see the sunrise during the meeting
[04:55:09] Malay Vadher joins the room
[04:55:19] Marco Liebsch joins the room
[04:55:30] Behcet Sarikaya joins the room
[04:55:46] <Cullen Jennings> thanks
[04:55:48] <Peter van Dijk> 'technical' sunrise is at 8:08 here, so just after, but practically, yes, the sun will peek in
[04:55:55] Robert Moskowitz joins the room
[04:55:56] Jerome Henry joins the room
[04:56:02] alex-meetecho joins the room
[04:56:06] Juan-Carlos Zúñiga joins the room
[04:56:18] Chris Box joins the room
[04:56:29] Bob Moskowitz joins the room
[04:56:48] Deb Cooley joins the room
[04:57:41] Éric Vyncke joins the room
[04:57:42] Phillip Hallam-Baker joins the room
[04:57:45] Pascal Thubert joins the room
[04:57:45] <Carlos Bernardos> good morning guys!
[04: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.
[04:57:51] Mohit Sethi joins the room
[04:57:52] Shuai Zhao joins the room
[04:57:55] Alissa Cooper joins the room
[04:57:58] Mohamed Boucadair joins the room
[04:57:59] Joseph Salowey joins the room
[04:58:03] Timothy Winters joins the room
[04:58:05] <Bob Hinden> Yes it is, it's part of the datatacker login.
[04:58:07] <Éric Vyncke> Yes, BoF are as WG meetings
[04:58:09] ko-isobe joins the room
[04:58:09] Kohei Isobe joins the room
[04:58:14] Russ Housley joins the room
[04:58:30] Kirsty P leaves the room
[04:58:31] Brian Dickson joins the room
[04:58:34] Kirsty P joins the room
[04:58:38] Donald Eastlake joins the room
[04:58:40] mcr joins the room
[04:58:49] Valery Smyslov joins the room
[04:58:52] Timothy Winters leaves the room
[04:58:56] Chi-Jiun Su joins the room
[04:59:00] Stuart Card joins the room
[04:59:07] Junyu Lai joins the room
[04:59:10] Timothy Winters joins the room
[04:59:28] Mohamed Boucadair leaves the room
[04:59:31] Mohamed Boucadair joins the room
[04:59:48] Yutaka Oiwa joins the room
[04:59:52] Peter Koch joins the room
[04:59:52] Bin-Yeong Yoon joins the room
[04:59:53] Julien Maisonneuve joins the room
[05:00:17] glennparsons joins the room
[05:00:19] Mohamed Boucadair leaves the room
[05:00:21] sftcd joins the room
[05:00:35] Jie Yang joins the room
[05:00:36] Hermin Anggawijaya joins the room
[05:00:40] mackermann@bcbsm.com joins the room
[05:00:49] Joey Salazar joins the room
[05:01:10] David joins the room
[05:01:15] Diego Lopez joins the room
[05:01:28] Stephen McQuistin joins the room
[05:01:33] Kannan Jayaraman joins the room
[05:01:39] Tim Cappalli joins the room
[05:01:42] Ben Campbell joins the room
[05:01:48] Monika Ermert joins the room
[05:01:54] Luis Contreras joins the room
[05:01:57] Taiji Kimura joins the room
[05:01:57] Mohamed Boucadair joins the room
[05:02:00] Richard Wilhelm joins the room
[05:02:01] Wei Pan joins the room
[05:02:04] Daniel Gillmor joins the room
[05:02:19] <behcet> No audio?
[05:02:19] glennparsons leaves the room
[05:02:24] Victor Kuarsingh joins the room
[05:02:29] <Alexandre Petrescu> I hear well
[05:02:30] Richard Wilhelm leaves the room
[05:02:32] <Peter van Dijk> i have audio
[05:02:32] <Bob Hinden> OK for me
[05:02:43] Jen Linkova joins the room
[05:02:48] Olaf Kolkman joins the room
[05:03:19] <behcet> Now I hear
[05:03:29] Zhuangyan joins the room
[05:03:46] Ralf Weber joins the room
[05:04:04] Glenn Deen joins the room
[05:04:05] Andrew Campling joins the room
[05:04:12] Mohamed Boucadair leaves the room
[05:04:15] Mohamed Boucadair joins the room
[05:04:15] David leaves the room: Disconnected: BOSH client silent for over 60 seconds
[05:04:19] Stephanie Ifayemi joins the room
[05:04:23] Tim Cappalli leaves the room
[05:04:26] Francois Ortolan joins the room
[05:04:29] Tim Cappalli joins the room
[05:04:39] Kazunori Fujiwara joins the room
[05:04:59] Mohamed Boucadair leaves the room
[05:05:02] Mohamed Boucadair joins the room
[05:05:05] Colin Perkins joins the room
[05:05:05] Ram Ranganathan joins the room
[05:05:07] Hugo Kobayashi joins the room
[05:05:13] Paolo Volpato joins the room
[05:05:17] Diego Lopez leaves the room
[05:05:20] Diego Lopez joins the room
[05:05:28] Philip Eardley joins the room
[05:05:35] dkg joins the room
[05:05:51] Ralf Weber leaves the room
[05:05:54] Ram Ranganathan leaves the room
[05:05:55] Ralf Weber joins the room
[05:05:58] Ram Ranganathan joins the room
[05:06:03] Hugo Kobayashi leaves the room
[05:07:35] <Éric Vyncke> I do not see any Amelia in the list of participants :(
[05:07:43] Jari Arkko joins the room
[05:07:46] <mcr> she forgot?
[05:07:47] Luigi Iannone joins the room
[05:08:03] <mcr> not in gather.town either.
[05:08:06] Pyung-Soo Kim joins the room
[05:08:27] <sftcd> it is v. early in many places to be fair;-)
[05:08:45] <Éric Vyncke> It is 6 AM in Belgium where Amelia lives AFAIK
[05:09:01] <sftcd> that's beyond early in my universe:-)
[05:09:07] <Peter van Dijk> it is 6AM in Belgium, yes :)
[05:09:14] <dkg> it's always very early in many places though :)
[05:09:33] <sftcd> well, breakfast at local 11am is the ideal, that's true
[05:09:35] <Éric Vyncke> @Peter so at least two Belgian people are here and awake ;-)
[05:09:49] <Peter van Dijk> well I'm one country to the north
[05:09:57] <Éric Vyncke> :-o
[05:09:59] <Peter van Dijk> I thought somebody mentioned there were slides with this? I'm not seeing any
[05:10:12] <Éric Vyncke> There are slides shown right now
[05:10:13] <Peter van Dijk> sorry, my bad
[05:10:16] <Peter van Dijk> wrong view :)
[05:10:17] <mcr> It's always dark. What's 6am vs 6pm? Same thing.
[05:10:35] <Adam Wiethuechter> Hello darkness my old friend....
[05:10:37] <Deb Cooley> both are better than midnight
[05:10:41] Juliana Guerra joins the room
[05:11:04] Eric Levy-Abegnoli joins the room
[05:11:38] <Éric Vyncke> Looking for Sun raise at the end of the BoF: let the light shine after this BoF
[05:12:16] Mohamed Boucadair leaves the room
[05:12:22] Mohamed Boucadair joins the room
[05:12:29] Yuexia Fu joins the room
[05:12:33] Robert Moskowitz leaves the room
[05:12:36] Robert Moskowitz joins the room
[05:13:09] Mohamed Boucadair leaves the room
[05:13:18] <Bob Moskowitz> Lost the slides.
[05:13:31] Kirsty P leaves the room
[05:13:32] <Peter van Dijk> still works here
[05:13:35] Kirsty P joins the room
[05:13:35] Mohamed Boucadair joins the room
[05:13:36] Mohamed Boucadair leaves the room
[05:13:38] <Adam Wiethuechter> Still here for me
[05:13:39] Mohamed Boucadair joins the room
[05:13:46] <sftcd> https://datatracker.ietf.org/meeting/109/materials/slides-109-madinas-background-and-status-about-mac-address-randomization-in-ieee802-and-wba-00
[05:13:57] <Tim Cappalli> Android 11 allows per connection via developer options. That probably should be reflected in the table.
[05:14:04] Robert Moskowitz leaves the room
[05:14:09] Kirsty P leaves the room
[05:14:10] <Alexandre Petrescu> (version of Windows on PC and on smartphone do MAC address rand'zation)
[05:14:12] Kirsty P joins the room
[05:14:21] <Éric Vyncke> @Tim please be sure to mention this on the mailing list as well
[05:14:24] <sftcd> I had an IEEE question: any idea when to expect a new thing from them? I'm assuming 3-4 years or something?
[05:14:26] Robert Moskowitz joins the room
[05:14:39] <Adam Wiethuechter> All good!
[05:14:45] <Shuai Zhao> yes
[05:14:48] <Olaf Kolkman> yes we can
[05:14:59] Kirsty P leaves the room
[05:15:15] <dkg> can the folks who aren't speaking stop sending video?  dave's video doesn't fit on screen for me
[05:15:16] Tirumaleswar Reddy.K joins the room
[05:15:20] <Jerome Henry> @sftcd: yes 3 to 4 years is typical and expected here as well
[05:15:21] Kirsty P joins the room
[05:15:29] <sftcd> @jerome: ta
[05:15:33] Yuexia Fu leaves the room
[05:15:40] Yuexia Fu joins the room
[05:15:48] <dkg> it's also nicer for folks who don't have a lot of bandwidth
[05:16:18] <sftcd> these ones are https://datatracker.ietf.org/meeting/109/materials/slides-109-madinas-mac-address-randomization-in-windows-10-00
[05:16:21] <Éric Vyncke> @dkg: please accept my apologies, forgot to turn video off
[05:16:45] Juliana Guerra leaves the room
[05:16:50] Juliana Guerra joins the room
[05:16:53] Kirsty P leaves the room
[05:17:04] Kirsty P joins the room
[05:17:27] Mohamed Boucadair leaves the room
[05:17:42] dee3@hot-chilli.net joins the room
[05:17:43] <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 %
[05:17:54] Mohamed Boucadair joins the room
[05:17:55] Mohamed Boucadair leaves the room
[05:17:56] Tadahiko Ito joins the room
[05:17:58] Mohamed Boucadair joins the room
[05:18:03] Rick Taylor joins the room
[05:18:15] Tadahiko Ito leaves the room
[05:18:37] <Tim Cappalli> Most users don't click that deep into the network settings
[05:18:37] Kirsty P leaves the room
[05:18:38] Tadahiko Ito joins the room
[05:18:47] <Deb Cooley> small, unless Windows prompt for it.
[05:18:54] <Andrew Campling> Good to hear about the usability / privacy tradeoff here, this is often ignored
[05:18:56] <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?
[05:19:14] <Tim Cappalli> the MAC doesn't change regularly
[05:19:22] <Tim Cappalli> so it is not an issue
[05:19:31] Mohamed Boucadair leaves the room
[05:19:31] <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
[05:19:37] Mohamed Boucadair joins the room
[05:20:01] <Dan Harkins> Does windows 10 only randomize wifi MAC addresses or does it also do it for wired?
[05:20:04] <Peter van Dijk> with iOS apparently re-randomising periodically, the overall % will be big anyway
[05:20:04] <Shuai Zhao> @tim but here in the slide saying there is an optional to random change mac address..
[05:20:17] Yuexia Fu leaves the room
[05:20:20] <Tim Cappalli> Shuai, yes but the most aggresive is daily.
[05:20:21] <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.
[05:20:25] Yuexia Fu joins the room
[05:20:26] <dkg> Tim: "daily" == "regularly" , but i agree with you it's not that frequent
[05:20:27] Mohamed Boucadair leaves the room
[05:20:28] <Tim Cappalli> MAC tables age much faster than that
[05:20:34] <Tim Cappalli> Daily != regularly in my book
[05:20:40] <dkg> well, it is regular :)
[05:20:44] <Tim Cappalli> Regularly would be like hourly
[05:20:47] <Peter van Dijk> also MAC tables learn immediately when you send out a frame from the new MAC
[05:20:49] <Tim Cappalli> or per session
[05:20:56] <dkg> i mean, yearly would also be regular :)
[05:21:00] <Jerome Henry> iOS does not rotate the MAC periodically, this was the beta intent, but the final is sticky per SSID
[05:21:09] <Peter van Dijk> Jerome, ah!
[05:21:10] <Tim Cappalli> Android 11 has the most aggresive option (per session) but it is currently buried in a developer option
[05:21:11] <Alexandre Petrescu> (win10 for PC - only for WiFi MAC, absent from Ethernet)
[05:21:20] <dkg> Jerome, that's not what the table we saw in the previous slide said
[05:21:21] <mcr> so, many base stations can have the same SSID, but would have different BSSID?
[05:21:32] <Tim Cappalli> Jerome is correct re: iOS
[05:21:34] <Peter van Dijk> mcr, yes
[05:21:35] <Tommy Pauly> Right, iOS uses a stable MAC address for each network
[05:21:52] <Tommy Pauly> The behavior changed from the beta, which probably is where the confusion comes from
[05:21:55] <mcr> at the IETF, we have network "IETF", which is the SSID.
[05:21:59] <dkg> Tommy, stable even across "forgetting" the network?
[05:22:02] <Dan Harkins> @mcr, yes each AP has its own BSSID.
[05:22:02] <Shuai Zhao> so there will be initial delays everytime you have to send out a ARP right?
[05:22:17] Pyung-Soo Kim leaves the room
[05:22:21] <mcr> was there some devices which randomize between BSSID then?
[05:22:28] Mohamed Boucadair joins the room
[05:22:36] <Cullen Jennings> what does OSX do ?
[05:22:37] <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)
[05:22:38] <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;-)
[05:22:41] <Tim Cappalli> It is per ESS, not BSS
[05:22:45] <Dan Harkins> APs don't randomize, that would cause problems.
[05:23:01] <Jerome Henry> OS X does not randomize as for now
[05:23:52] <Éric Vyncke> @Jerome you may want to say it at the mike but also on the mailing list
[05:23:54] <mcr> and it sounds like it stores the MAC-address in a database if it wants to keep it.
[05:24:29] <Jerome Henry> @Eric thank you, I'll mention it in the Q&amp;A part
[05:24:43] Pyung-Soo Kim joins the room
[05:24:54] <Cullen Jennings> @Jerome - Thanks
[05:25:12] Yutaka Oiwa leaves the room
[05:25:23] <Joey Salazar> the setting says it applies for new connections, I guess it's generated only once per new connection?
[05:25:27] Yutaka Oiwa joins the room
[05:27:19] Kirsty P joins the room
[05:27:35] Andrew S joins the room
[05:27:45] Colin Perkins leaves the room
[05:28:28] <sftcd> typical thaler: a good answer incl. a thing I didn't know:-) (the probe stuff in my case)
[05:28:28] Loren McIntyre joins the room
[05:28:48] Pyung-Soo Kim leaves the room
[05:28:59] <Éric Vyncke> @stephen: typical indeed, detailed + concise ;-)
[05:28:59] <mcr> I worry that we disparage Starbucks unfairly: did they actually ever track people by mac address?
[05:29:15] Li Yizhou joins the room
[05:29:16] <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
[05:29:25] <Cullen Jennings> This is a great example of "last person 'to touch it is the person that broke it
[05:29:25] <Tim Cappalli> ^ Correct
[05:29:28] <Adam Wiethuechter> I don't trust them to even make a coffee right @mcr
[05:29:38] glennparsons joins the room
[05:29:50] <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.
[05:30:16] <Tim Cappalli> This is a typical case of not keeping up with the times
[05:30:38] <Tim Cappalli> Organizations that make their money on captive portals are upset because their revenue stream is going away
[05:30:41] <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)
[05:31:01] glennparsons leaves the room
[05:31:53] <Tim Cappalli> How do you determine it is an untrusted network without a prompt?
[05:32:17] behcet leaves the room
[05:32:20] <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)
[05:32:41] Behcet Sarikaya leaves the room
[05:32:44] <Tim Cappalli> @sftcd, its not necessarily about ephemeral, its more about protected identifiers
[05:32:54] <sftcd> fair point too
[05:32:54] <Tim Cappalli> aka, inside a tunneled EAP method
[05:33:12] <Stuart Card> captive portal revenue probably is mostly a thing of the past, but for some operators, alternative means of preserving it will emerge
[05:33:20] <dkg> i share Andrew's concern, fwiw -- but still think it's worthwhile to pursue this
[05:33:28] <Tim Cappalli> @Stuart, you would think so, but honestly, that's not the case
[05:33:30] Quang-Huy Nguyen joins the room
[05:33:31] <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?)
[05:34:26] <Dave Thaler> good questions all, and yes it stores the MAC address with the SSID on the local machine until you "forget" the SSID
[05:34:30] <Erik Kline> @Jari: In Android's case it remembers whether the captive portal check detected a portal.
[05:34:36] <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.
[05:35:02] Lucy Lynch joins the room
[05:35:02] Nancy Cam-Winget joins the room
[05:35:06] <sftcd> https://datatracker.ietf.org/meeting/109/materials/slides-109-madinas-madinas-use-cases-00
[05:35:07] <dkg> mcr: who has revealed what?
[05:35:22] Nancy Cam-Winget leaves the room
[05:35:25] Nancy Cam-Winget joins the room
[05:35:27] <dkg> are you saying that they identify their vendor b choice of canary probe?
[05:35:35] <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
[05:35:50] <mcr> @dkg, so they've picked a mac address, dhcp ID, and yes, canary probe choice reveals vendor.
[05:36:08] <Tirumaleswar Reddy.K> how does the ISP know the MAC address of devices in the home network ?
[05:36:10] <dkg> mcr: right, makes sense
[05:36:22] <Tim Cappalli> If you use the ISP's router/gateway, they know everything
[05:36:33] <Mohamed Boucadair> @Tiru: it does not know. This is local to the CPE
[05:36:34] <sftcd> doesn't DHCP itself let me ask for the same IP the 2nd time?
[05:36:38] Lucy Lynch leaves the room
[05:36:45] <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)
[05:36:53] <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)
[05:37:18] <dkg> Mohamed: lots of ISP deploments have detailed control over the CPE
[05:37:18] <Tim Cappalli> ^ yep
[05:37:23] <Tim Cappalli> (@mcr)
[05:37:39] <Stuart Card> MCR yes that is a standard WiFi Pineapple attack
[05:37:43] <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
[05:37:50] <mcr> TR-069 features in non-pure-openwrt routers have mucho features about mac address diagnostics.
[05:38:05] <Tim Cappalli> @Dave, a majority of public Wi-Fi networks are open
[05:38:08] <dkg> my home wifi network is named "Starbucks WiFi" ☺
[05:38:18] <sftcd> @mcr: much unused features, or? ...
[05:38:21] <Cullen Jennings> I'm curios about the DHCP lifetimes in use for this running out of IP address use case
[05:38:25] <mcr> no wonder Adam can't get good coffee from your starbucks.
[05:38:30] <sftcd> @dkg: send coffee!
[05:38:47] <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.
[05:38:53] <Éric Vyncke> * * * please be sure to also have this discussion over the mailing list
[05:38:54] <Mohamed Boucadair> @cullen: that one can be solved typically by tweaking the implem to align with the lease times
[05:38:58] <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.
[05:39:04] <Andrew Campling> Either Jason has a very fast fan or is that a strobing light?  
[05:39:34] <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.
[05:39:37] <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
[05:40:35] <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.
[05:41:10] <sftcd> "stored in the cloud" ? by whom for what?
[05:41:20] Toerless Eckert joins the room
[05:41:23] <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.
[05:41:49] <Éric Vyncke> @stephen possible a hot spot operator ? or roaming operator based on MAC ?
[05:41:53] <Jason Weil> sorry for the fan strobe
[05:41:53] <sftcd> @mcr: right, so the relative importance is locale dependent
[05:42:16] <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.
[05:42:17] <dkg> 30× a few 6 octets is still just 180 octets
[05:42:18] glennparsons joins the room
[05:42:31] <Bob Hinden> That sounds odd, grows "astronomically" when there are 30 mac addresses in a month.   Sounds broken.
[05:42:38] <Tim Cappalli> +1 Dan
[05:42:49] <Cullen Jennings> pretty skeptical that this database size is very relevant for a SP with less that a trillion users
[05: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 :-)
[05:42:50] <Tim Cappalli> MAC-based authorization has been a ridiculous excuse to be lazy
[05:43:04] <Tirumaleswar Reddy.K> +1 Tim
[05:43:07] <Tim Cappalli> there are more options than ever to solve this but OS vendors won't implement them
[05: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?
[05:43:13] <Tim Cappalli> WPA3 SAE Password ID is the best example
[05:43:24] <Tim Cappalli> Yes Jen!!!
[05:43:26] <Bob Hinden> Jen:  +1
[05:43:28] <Tirumaleswar Reddy.K> Attacker can easily spoof MAC addresses
[05:43:32] <Tim Cappalli> It should NEVER have been used in the first place
[05:43:39] <Tim Cappalli> Laziness instead of addressing the problem as an industry
[05:43:44] <Tirumaleswar Reddy.K> MAC is a weak identity for policy enforcement
[05:43:48] <Erik Kline> hence this BoF...
[05:43:52] <mcr> @Jen, really it comes down to: we don't have another hammer.  I hope that this BOF will give us some new hammers.
[05: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.
[05:43:54] <dkg> i also want to know which cloud provider is storing this stuff
[05:44:01] <sftcd> that last slide also assumed "identity" == "MAC addr" which is part of the dodginess
[05:44:01] <Tim Cappalli> The lack of consistent onboarding across operating systems is the #1 problem for enterprise.
[05:44:15] glennparsons leaves the room
[05:44:21] <Peter van Dijk> speaker is Malay Vadher of plume.com
[05:44:41] <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)
[05:45:11] <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
[05:45:25] <mcr> clearly, that's something people would want to outsource.
[05:45:30] <dkg> mcr: yeah that doesn't work well for those of us without SMS :/
[05:45:34] <sftcd> @thaler: ta, must try see what happens with linux sometime (probably not during this call though:-)
[05:45:34] <Andrew Campling> Stating why people shouldn't do x doesn't mean that it doesn't happen and isn't common practice
[05:45:40] <Tim Cappalli> @dkg, hence the captive portal vendors who are pissed off ;)
[05:46:01] <Bob Hinden> It's not like they didn't have a lot of warning.
[05:46:09] <Tim Cappalli> ^ Exactly.
[05:46:12] <Dan Harkins> @bob +1
[05: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.
[05:46:19] <dkg> (fwiw, i think data retention laws like the ones mcr describes are really problematic on their own)
[05:46:33] <sftcd> @AndrewC: that's true, is it also true that some in-store advertising (ab)use MAC addrs too?
[05:46:41] <dkg> @mcr, s/password/passport/ ?
[05:46:46] <mcr> @dkg, sure.  Of course we can complain about evil countries that insist on stuff.
[05:47:00] <sftcd> what's MBO?
[05:47:05] <mcr> nope, @dkg, passport. I have to give them an identity to which they could link my activity.
[05:47:20] <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
[05:47:25] <Peter van Dijk> multi band operation (2.4ghz, 5ghz, etc.) i think
[05:47:33] <Tim Cappalli> Multi Band Operation
[05:47:34] <sftcd> ta
[05:47:42] <dkg> @mcr: that's what i thought -- you said "password" so i was a bit confused :)
[05:47:43] <Adam Wiethuechter> or rather granted based on policy
[05:47:45] <Tim Cappalli> +1 Adam
[05:47:50] <Tim Cappalli> MAC should be ephemeral like IP
[05:48:12] <mcr> oh. sorry. I see. yes, my typo. I thought you were saying the opposite.
[05:48:29] <dkg> i know how to use sed! 😛
[05:48:39] <Adam Wiethuechter> I don't want to say this but its the ID/Loc problem all over again, just lower down the stack
[05:48:44] <Tim Cappalli> same argument about IP-based access lists / firewall policies. Identity should be driving policy, not ephemeral identifiers
[05:48:48] <mcr> But, when the Swiss police want to see my password, I always ask to see their password first.
[05:48:55] <dkg> Adam, we have this problem up and down the stack
[05:49:05] <Stuart Card> +1 @adamW
[05:49:10] <sftcd> MBO and reasonably persistent - surely that'd only be for seconds? if not I don't get why
[05:49:13] <Adam Wiethuechter> This is true and a shame @dkg
[05:49:27] <sftcd> how many is many?
[05:49:32] <Adam Wiethuechter> Many
[05:49:42] <sftcd> is many > most?
[05:49:47] <dkg> sftcd, what do you think we are, engineers?
[05:49:51] <Éric Vyncke> This MBO issue looks limited to layer-2 and should probably be better handled by IEEE
[05:49:51] <Adam Wiethuechter> Sorry I couldn't resist :p
[05:50:02] <Tim Cappalli> I don't see how MBO would be impacted
[05:50:03] <Dan Harkins> MBO is definitely an IEEE 802.11 issue.
[05:50:30] <Dan Harkins> 11bh and/or 11bi will deal with that.
[05:50:41] <Éric Vyncke> thx Dan
[05:50:49] <Tim Cappalli> Depends on who you ask. Bunch of folks are convinced this will be reverted.
[05:51:31] <Andrew Campling> @Dan what about the many legacy devices?
[05:51:35] Chenhe Ji joins the room
[05:51:45] <Ben Campbell> My search-fu is weak. Can someone expand "MBO"?
[05:51:46] <Dan Harkins> what about them?
[05:51:56] <Tim Cappalli> https://wi-fi.org/discover-wi-fi/wi-fi-agile-multiband
[05:51:57] <Dan Harkins> Multi-Band Operations....
[05:52:04] <Ben Campbell> thanks!
[05:52:05] Bhavit Shah joins the room
[05:52:19] <Cullen Jennings> plume.com
[05:52:22] <Peter van Dijk> plume.com
[05:52:46] <sftcd> yeah, I've never heard of 'em
[05:52:48] <sftcd> sorry;-)
[05:52:49] <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
[05:53:08] <Tim Cappalli> Every kid over the age of 5 knows how to bypass that
[05:53:19] <Tim Cappalli> Sigh
[05:53:27] <Jason Weil> over 9 I would agree
[05:53:32] <Bob Hinden> Tim:  Yes!!!!
[05:53:38] <Dan Harkins> kids pray their idiot parents buy software that restricts by MAC address.
[05:53:45] HAIGUANG Wang joins the room
[05:53:47] <Tim Cappalli> We really need to bring reality into this conversation IMO
[05:53:57] <sftcd> if there's a blocker locally I don't get why MACs need to goto anyone's "cloud"
[05:54:02] <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
[05:54:05] <Cullen Jennings> But this does has an upside, this is how 9 year ;-)old kids are learning networking
[05:54:15] <Peter van Dijk> we're educating tomorrow's hackers ;)
[05:54:41] <mcr> @sftcd, so as a higher-level thing, see: https://www.ripe.net/ripe/mail/archives/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!
[05:54:46] Monika Ermert leaves the room
[05:54:47] <Jen Linkova> Parents ;))) AFAIR one of New York airports was providing first 30mins of WiFI free of charge...
[05:54:48] <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.
[05:54:54] <Ben Campbell> @Jerome: Thanks, got it. Was just having a moment of ADC (Acronym Database Corruption)
[05:54:54] <Jen Linkova> based on MAC...
[05:55:04] <Dan Harkins> it's a problem but it's very specific to 802.11
[05:55:13] sftcd did try look at plume.com's web page but NoScript means I get a blank black page;-)
[05:55:48] Nancy Cam-Winget leaves the room
[05:55:53] Nancy Cam-Winget joins the room
[05:56:14] <Tim Cappalli> Exactly!!!
[05:56:16] Bin-Yeong Yoon leaves the room
[05:56:17] <Tim Cappalli> You just proved the point.
[05:56:27] <Tim Cappalli> There are so many other places in the stack to worry about this
[05:56:41] <Tim Cappalli> Unless you MDM your kids phone, its pointless
[05:56:42] <dkg> so the lesson i'm hearing is that these parental controls don't work against a marginally-competent adversary
[05:56:42] Monika Ermert joins the room
[05:56:54] <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.
[05:56:57] <sftcd> @dkg: hardly a surprise
[05:57:09] <Tim Cappalli> Not to mention all these kids have unlimited data plans (in the US at least)
[05:57:24] <sftcd> @mcr: IMO the "right" answer is to educate the kids, but I accept that many people do go for the net nanny thing
[05:58:04] <Tim Cappalli> There is no impact to secure authentication methods
[05:58:06] Oliver Borchert joins the room
[05:58:13] <Tim Cappalli> OpenRoaming is an implementation of Passpoint which uses 802.1X
[05:58:21] Marco Liebsch leaves the room
[05:58:35] <Alissa Cooper> Ok
[05:58:37] <Tim Cappalli> When deployed properly, a device or user identity is protected inside a TLS session
[05:58:44] <Tim Cappalli> *channel
[05:58:57] Marco Liebsch joins the room
[05:59:10] <Tim Cappalli> Right now, the only secure deployment method that works across all operating systems is EAP-TTLS/PAP or EAP-TTLS/MSCHAPv2
[05:59:20] <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)?
[05:59:22] <Tim Cappalli> TEAP Is a close second but isn't supported in the Apple ecosystem unfortunately
[05:59:49] <dkg> "trust between client and network" should be bidirectional
[05:59:54] <Dan Harkins> identifiers are not provided pre-association....
[05:59:57] <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.
[05:59:57] <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
[05:59:58] <Adam Wiethuechter> +1 dkg
[06:00:04] <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
[06:00:18] <dkg> the text here implies that that client is obliged to prove itself to the network, but doesn't mention the other way around
[06:00:31] <Tim Cappalli> @Jerome, anonymity can only be guaranteed with a tunneled EAP method.
[06:00:43] <Stuart Card> former EU research project ABC4trust: Attribute Based Credentials, selectively revealed, with selective linkability
[06:00:48] <Jerome Henry> @Tim agree
[06:00:48] <Mohamed Boucadair> @dkg: the list is not exhaustive
[06:00:51] <Tim Cappalli> As of right now, while EAP-TLS is the most secure, it is not privacy preserving
[06:01:02] <Dan Harkins> @dkg, that's because this is coming from the point of view of the network providers.
[06:01:20] <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.
[06:01:20] <Dan Harkins> all these guys want to get an identifier for clients
[06:01:23] <mcr> EAP-TLS1.3 would be better.
[06:01:31] <Dan Harkins> they don't care about providing anything _TO_ the clients
[06:01:33] <Jen Linkova> "another reason to move to Ipv6: no DHCP pool exhaustion anymore" ;-)
[06:01:38] <dkg> Dan: you'd think that they'd want to also prevent other people from impersonating their networks
[06:01:40] <Tim Cappalli> Yes, 1.3 would eliminate the privacy concerns
[06:01:48] <Stuart Card> Does the identifier even need to be presented in cleartext for all uses?
[06:01:51] <dkg> i mean, i can name my home wifi network "xfinity WiFi" too
[06:01:53] <Tim Cappalli> but that atrocious onboarding experience on operating systems is the current problem
[06:02:07] <Dan Harkins> that can be done in the security handshaking (802.1X or SAE).
[06:02:07] <Tim Cappalli> with no end in sight
[06:02:16] <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
[06:02:21] Toerless Eckert leaves the room
[06:02:26] Kannan Jayaraman leaves the room
[06:02:35] <Jerome Henry> but that identity part needs to be secure and protected indeed
[06:02:39] Toerless Eckert joins the room
[06:02:48] <Alissa Cooper> I think framing this as "the identifier" maybe isn't a great place to start given the diversity of uses here.
[06:02:56] <Tim Cappalli> There is very little value in home IoT / headless devices randomizing MACs
[06:02:57] <Mohamed Boucadair> Fair point from Cullen
[06:02:58] <dkg> +1 Alissa
[06:02:59] <sftcd> +1 to alissa
[06:03:01] <Dave Thaler> +1 Alissa
[06:03:02] <Tim Cappalli> today, I'm not aware of a single one that does
[06:03:05] <Dan Harkins> you can say you're "xfiniti wifi" but if there's a credential needed for access then the rogue should be detected.
[06: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?
[06:03:16] <Dave Thaler> say at mic alissa :)
[06:03:27] <dkg> Dan Harkins: whose credential is needed?
[06:03:36] <Tim Cappalli> @Bob, the key is that it is not clear OTA
[06:03:42] <Adam Wiethuechter> +1 Alissa - we can probably never attain the "golden identifier"
[06:03:49] <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.
[06:03:50] <dkg> i can just spoof any login prompt that xfinity typically offers, and then accept all credentials supplied
[06:04:04] <Dan Harkins> either a verifiable cert or a shared PSK/password.
[06:04:18] <dkg> Dan: you mean that the client provides those things?
[06:04:30] <Mohamed Boucadair> @Adam: That is why the slide says "different use cases have different ..."
[06:04:44] <dkg> or you mean the client OS somehow enforces that the network proves posession of those things first?
[06:04:46] <Dan Harkins> I mean the client will get a cert for the network it is trying to connect to.
[06:05:02] <Toerless Eckert> limited number of identifiers ?
[06:05:02] <Tim Cappalli> The level of friction is the #1 problem right now
[06:05:03] <dkg> not on the xfinity APs i see near me :/
[06:05:06] <Adam Wiethuechter> @Mohamed - fair point
[06:05:22] <Tim Cappalli> there is TOO much friction
[06:05:56] <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.
[06:06:36] <dkg> that would be an interesting experiment to run if we ever have an in-person IETF again
[06:06:55] <Tim Cappalli> @ Dan, a properly configured supplicant wouldn't have that issue
[06:08:08] <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.
[06:08:43] <Dan Harkins> @tim, where is this properly configured supplicant of which you speak?
[06:08:46] <Alister Winfield> hahaha... properly configured is such a big assumption
[06:08:48] <Adam Wiethuechter> Love what you said Tim!
[06:08:50] <Dan Harkins> :-)
[06:08:55] <dkg> no true scotsman
[06:09:04] <Stuart Card> I stand by my point. Think about DoS.
[06:09:19] <Tim Cappalli> @Dan, "It used to be that clients just ignored server cert validation. " this is not accurate at all
[06:09:43] <Tim Cappalli> behaviors have changed, yes, but no user-centric client blatantly ignores EAP server identity without being confifured to do so
[06:09:46] <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
[06:09:47] <Tim Cappalli> *configured
[06:10:50] <dkg> Dave Thaler: thanks for looking into that.  i'd be interested to read followup about it.  maybe on madinas@ietf.org ?
[06:10:51] <Dave Thaler> and the hash is just for perf since it's faster than generating a new cryptographically random secret
[06:11:31] Bing Liu joins the room
[06:11:33] <Mohamed Boucadair> @Stephen: fair point. This is captured in the last bullet of slide 12
[06:11:36] Shuai Zhao leaves the room
[06:12:02] <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
[06:12:16] <dkg> i don't know of such a use case in this domain though
[06:12:23] <Tim Cappalli> @Tommy, that's why its important to distinguish OTA vs encapsulated in another exchange
[06:12:25] <Dave Thaler> ack
[06:12:48] <Stuart Card> +1 Tommy Pauly
[06:12:48] <dkg> +1 Tommy
[06:12:50] Tirumaleswar Reddy.K leaves the room
[06:12:56] Tirumaleswar Reddy.K joins the room
[06:13:10] <Adam Wiethuechter> Maybe out of scope (or over reaching) but what about client trusting others on the network (aka its peers)?
[06:13:18] <sftcd> +1 to Tommy too (though /me thinks about Mr. Schrems:-)
[06:13:20] <Cullen Jennings> Listening to Tommy and thinking about what I am seeing on mdns right now
[06:13:30] <mcr> I like the idea of showing up on a network, and just BLASTING my identity.  Disaster Area style.
[06:13:32] <Adam Wiethuechter> Probably inherited from the network trust, but might be different?
[06:13:33] <Ben Campbell> +1 to all the people +1'ing Tommy
[06:13:39] <Peter van Dijk> Cullen, do you have a two line summary of what's happening on mdns?
[06:14:26] <dkg> Peter: i think he might mean "i'm scanning my local network's mdns traffic"
[06:14:27] <Tim Cappalli> +1000 Jari. Everything is available to solve this problem today. We just need people to implement it, consistently.
[06:14:44] <Bob Hinden> I am wondering if this is actually something the IETF can solve.
[06:14:56] <Tim Cappalli> @Bob, I don't think so. It is an adoption problem
[06:14:58] <Cullen Jennings> yah a tone of apple devices in the hotel is sending me data that identify them with a stable indetifier
[06:15:21] <dkg> Cullen, but i thought "what happens on your iPhone stays on your iPhone"
[06:15:26] <Tim Cappalli> Wi-Fi Alliance + Network Vendors + OS Vendors are who can solve this
[06:15:30] <Tommy Pauly> @Cullen yeah, that's a thing we need to work on...
[06:15:30] <mcr> Cullen, what's a hotel?
[06:15:43] <Dave Thaler> hotel: a quaint concept
[06:15:45] <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
[06:15:49] <sftcd> @mcr: it's a thing with closed doors
[06:15:56] <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)
[06:16:27] <Adam Wiethuechter> Its probably going to be a slow process :/
[06:16:34] <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....]
[06:16:57] <Peter van Dijk> mcr, maybe send the rest of your household to the airbnb instead :)
[06:17:03] <Deb Cooley> you just needed one close to home.
[06:17:14] <Deb Cooley> commute home to work, to the hotel to sleep.
[06:17:38] <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.
[06:18:08] <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)
[06:18:10] <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?
[06:19:03] <mcr> it does seem like the place for some kind of zero-knowledge proof.
[06:19:39] <Phillip Hallam-Baker> User identifiers are things that should really only be created at application level.
[06:19:48] <sftcd> @jari: I doubt anything near all the people who want better privacy know the HOWTO
[06:19:52] <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...)
[06:19:55] Diego Lopez leaves the room
[06:21:55] <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).
[06:22:14] Carles Gomez joins the room
[06:22:30] <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.  :(
[06:22:56] <Toerless Eckert> +1 on Bob
[06:23:15] <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?
[06:23:16] <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
[06:23:23] <Tim Cappalli> @Erik, certainly possible but the goal should be to get rid of captive portals, not keep them alive
[06:23:23] <Bob Hinden> I agree with Bob too
[06:23:50] <Adam Wiethuechter> +1 Bob and +1 Stu
[06:23:51] <Erik Kline> @Tim a capport API doesn't mean the network restricts your access
[06:24:03] <Erik Kline> (we ran an experiment on IETF 106 network)
[06:24:06] <sftcd> @jari: I didn't mean to suggest some new tech would "solve" this stuff, but fair point
[06:24:12] <Tim Cappalli> @Erik, but it does mean you have existing L3 access
[06:24:22] <Erik Kline> yup
[06:24:31] <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.
[06:24:34] <Erik Kline> (hence some TOFU)
[06:25:15] Jerome Henry leaves the room
[06:25:21] Jerome Henry joins the room
[06:25:52] Jerome Henry leaves the room
[06:25:57] Jerome Henry joins the room
[06:26:17] <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 ..
[06:26:24] Monika Ermert leaves the room
[06:26:24] <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
[06:26:30] Monika Ermert joins the room
[06:26:55] Jerome Henry leaves the room
[06:26:58] Jerome Henry joins the room
[06:27:18] Carles Gomez leaves the room
[06:27:28] <Erik Kline> The TLS cert in the capport API can be used to identify the network
[06:27:54] <sftcd> I guess https://tools.ietf.org/html/rfc7824 as well
[06:28:01] <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.
[06:28:05] <Tim Cappalli> @Erik, its a weak binding though
[06:28:16] <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.
[06:28:32] <Stuart Card> @mcr: identity is neither solely in the subject nor solely in the object, but in their relationship? I am feeling mystical...
[06:28:38] <Mohamed Boucadair> @sftcd: https://tools.ietf.org/html/rfc7844?
[06:28:40] <Carlos Bernardos> https://tools.ietf.org/html/rfc7844 as well I think
[06:28:46] <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
[06:28:52] <sftcd> that's it thanks
[06:29:05] <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
[06:29:07] <Andrew Campling> @Simon a quantum identity?  
[06:29:17] <Tim Cappalli> an SSID can't be bound to a web server
[06:30:00] <mcr> the SSID can't be bound to anything really.  It's a disaster.
[06:30:11] <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?
[06:30:16] <Tim Cappalli> Yep. But the auth session can be (aka EAP)
[06:30:19] <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
[06:30:36] <dkg> the trouble is that the general public *only* sees the SSID -- so that's the thing to bind to
[06:30:38] <sftcd> @andrew: work on to do what? not clear to me
[06:30:43] <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...
[06:30:57] <dkg> just like how domain name is really the only thing that we bind to in the web context
[06:31:10] <Éric Vyncke> JC is right, the BoF purpose is not to design a new identifier
[06:31:12] <Tim Cappalli> @dkg, and Passpoint improves that by adding an organizatin name. in the same way that EV certs enhance domain presentation
[06:31:14] <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
[06:31:28] <Tim Cappalli> (well, did)
[06:31:30] <dkg> Tim Cappalli: and look what happened to EV certs
[06:31:32] <sftcd> @Tim: /me disparages EV certs - they add $1000 or so is all:-)
[06:31:46] <Tim Cappalli> Just because browsers decided against EV certs, doesn't make them wrong for other use cases
[06:31:55] <sftcd> nor does it make 'em right
[06:32:02] <dkg> sure, but it's worth understanding why they failed
[06:32:04] Ram Ranganathan leaves the room
[06:32:11] <Erik Kline> non-SSID identifiers for networks could help client figure out that CoffeeShop-5GHz and CoffeeShop-2.4GHz are the same network
[06:32:11] <Tim Cappalli> Sure, but it works pretty damn well today with Passpoint R2
[06:32:16] <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"?
[06:32:28] Ram Ranganathan joins the room
[06:32:37] <Tim Cappalli> and that is why Passpoint is valuable. There is no SSID binding
[06:32:41] <Tim Cappalli> Its an identity binding
[06:32:43] <Andrew Campling> @sftcd to agree and then solve the agreed use case requirements in a reliable manner that works at all layers as appropriate
[06:32:49] <Dan Harkins> validating a cert for a web server makes sense. Validating a web server for an SSID doesn't really.
[06:33:23] <Dan Harkins> I meant, validating a cert for an SSID doesn't make sense.
[06:33:27] <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)
[06:33:31] Zhen Cao joins the room
[06:33:37] Nalini Elkins leaves the room
[06:33:58] <Stuart Card> @DanH why not?
[06:35:27] Huaru Yang joins the room
[06:35:46] <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
[06:36:31] <Dan Harkins> because what is the validation step the CA would go through for an SSID?
[06:36:34] <Tim Cappalli> It should ONLY apply at L4 and higher
[06:36:35] <sftcd> @andrew: what I'm not seeing is the IETF's role in trying to "solve" those but I may be wrong
[06:36:56] <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).
[06:37:29] <Tim Cappalli> Well, it depends on whether we consider adding support for existing protocols to "tweaking the implementations" ;)
[06:37:42] <Mohamed Boucadair> that is not excluded :-)
[06:38:02] <Tim Cappalli> I have yet to hear a use case on this call that wouldn't be solved by an existing authentication method
[06:38:27] <Tim Cappalli> Home is being held back by lack of support for WPA3 SAE Password ID by OS vendors
[06:38:35] <Alissa Cooper> maybe would be good to catalogue the existing auth methods and map them to these use cases on the list
[06:38:43] <Tim Cappalli> Good idea @Alissa
[06:38:52] <Mohamed Boucadair> agree
[06:38:54] <Stuart Card> @Andrew CA hierarchy is not the only way of doing certificates
[06:38:55] <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.
[06:39:33] <Stuart Card> sorry meant @DanH
[06:39:57] <Alissa Cooper> Alister that would be a useful analysis to have as well
[06:40:01] <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.
[06:40:05] Philip Eardley leaves the room
[06:40:08] Philip Eardley joins the room
[06:40:29] <Adam Wiethuechter> Agreed @mcr
[06:40:43] <Andrew Campling> This is better than the virtual hum!
[06:40:43] <Tim Cappalli> Hehe, that's my favorite feature
[06:41:58] <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;-)
[06:42:08] <Dan Harkins> @stuart what are you suggesting?
[06:42:40] <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"
[06:42:43] <Kirsty P> Why are there 111 participants in this meeting but only 100 on the voting hands tool?
[06:42:43] <Alissa Cooper> I think more discussion is needed before q2 can be ansswered
[06:42:48] <sftcd> the lack of a "need more info" option is clear here
[06:42:49] <Peter van Dijk> @dkg i was just typing that
[06:42:56] <Bob Hinden> I agree with Alissa
[06:43:02] <dkg> Alissa +1
[06:43:04] <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
[06:43:06] <Bob Moskowitz> I am looking at draft-huque-dane-client-cert-04.txt as an alternative to traditional CA
[06:43:08] <Peter van Dijk> i have no idea if action is required but i the conversation is important to me
[06:43:21] <Alissa Cooper> @Kirsty the roster double-counts people who are logged in via jabber separate from Meetecho, the raise-hands tool does not
[06:43:42] <mcr> @Bob, so if you feel that there is NO IETF action, then you could vote no.
[06:43:43] Yiu Lee leaves the room
[06:43:56] <mcr> If the majority said that, then that would mean something.
[06:44:01] <Adam Wiethuechter> I'd argue having a deeper conversation is an action in some capacity
[06:44:04] <Bob Hinden> But what?
[06:44:07] <Jari Arkko> I think "more research needed" is the right answer here, but "action required by the IETF" is way way too early
[06:44:07] <Bob Moskowitz> I tried logging in to Jabber as "Robert Moskowitz" and got an auth failure as already logged in (via Meetecho).
[06:44:09] Philip Eardley leaves the room
[06:44:12] Philip Eardley joins the room
[06:44:17] <Dan Harkins> @stuart but you are you day after day regardless of SSID.
[06:44:24] <Stuart Card> I submit that many of us already _are_ working on "this topic", which is an elephant with many aspects.
[06:44:30] Junyu Lai leaves the room
[06:44:44] <Glenn Deen> There clearly is an operator need here.
[06:44:45] <Peter van Dijk> @stuart well put, yes
[06:44:51] Yiu Lee joins the room
[06:44:58] <Alissa Cooper> sorry, double-counts was not the right word, the roster includes people who are jabber-only
[06:45:05] <Andrew Campling> I assume that "some work" here may be to continue the discussion and understand the issues better
[06:45:21] <dkg> Alissa, that is indeed a double-count for many of us though
[06:45:25] <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?
[06:45:30] <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?
[06:45:31] <mcr> @Moskowitz you need to pick a different nick/resource.
[06:45:34] <Jason Weil> I think that is fair @Andrew
[06:45:54] <Glenn Deen> +1  AC
[06:46:03] <Glenn Deen> (campling)
[06:46:08] <Bob Moskowitz> Pidgin
[06:46:09] <sftcd> FWIW, I wouldn't put much weight on the numbers resulting from those questions at all
[06:46:21] glennparsons joins the room
[06:46:23] Yuexia Fu leaves the room
[06:46:26] Yuexia Fu joins the room
[06:46:40] <sftcd> about the most I'd get is "keep at it on the mailing list"
[06:46:43] <Joey Salazar> +1 dkg
[06:46:49] <mcr> @dkg, I have a whole folder full of bad ideas, if you have time.
[06:46:58] Andrei Gurtov joins the room
[06:47:04] <dkg> mcr: ha ha
[06:47:11] <dkg> it can't be bigger than my folder of bad ideas!
[06:47:16] <mcr> WBA?
[06:47:27] <sftcd> something to do with boxing
[06:47:33] <mcr> WFA?
[06:47:35] glennparsons leaves the room
[06:47:37] <Tim Cappalli> Wireless Broadband Alliance
[06:47:41] <Tim Cappalli> Wi-Fi Alliance
[06:47:58] <Tim Cappalli> https://wballiance.com/
[06:48:06] Junyu Lai joins the room
[06:48:12] <Jason Weil> Do we have a liaison with either of those orgs?
[06:48:14] <Tim Cappalli> https://www.wi-fi.org/
[06:48:16] <Andrew Campling> @dkg I suspect that participants here (me included) could probably fill the agenda for IETF 110 with bad ideas
[06:48:30] Junyu Lai leaves the room
[06:48:33] <sftcd> @jason: don't believe we liaise with 'em, but informal is better when possible mostly
[06:48:37] <HAIGUANG Wang> Maybe I just type here
[06:49:20] <Jason Weil> sounds good, I see a few people here involved with WFA so that shouldn't be a problem
[06:49:22] <HAIGUANG Wang> I suggest we send a liasion statement to IEEE 802.11 group to get their opnion.
[06:49:43] <Jerome Henry> @Haiguang fully agree
[06:49:44] <Tim Cappalli> WFA has already. created all the solutions
[06:49:54] <Tim Cappalli> WBA is already telling people to deploy the solutions :)
[06:49:55] <mcr> oh, yes, the Wireless Broadband Alliance.. They took some interest in CAPPORT, but not really that much.
[06:50:25] Brian Dickson leaves the room
[06:50:32] <mcr> I got none of that. Maybe just me. Yup, probably just me.
[06:50:33] <Yiu Lee> We should also investigate whether BBF is working on similar problem or not.
[06:50:37] Michael Richardson leaves the room
[06:50:44] Michael Richardson joins the room
[06:50:55] Luigi Iannone leaves the room
[06:50:55] Peter Koch leaves the room
[06:50:56] Michael Richardson leaves the room
[06:50:56] <Peter van Dijk> thank you all
[06:50:57] Ram Ranganathan leaves the room
[06:50:57] <Éric Vyncke> thank you all
[06:50:57] Rohit Abhishek leaves the room
[06:50:57] Mohamed Boucadair leaves the room
[06:50:57] Pascal Thubert leaves the room
[06:50:58] Jen Linkova leaves the room
[06:50:59] Jerome Henry leaves the room
[06:50:59] Bing Liu leaves the room
[06:51:00] Luis Contreras leaves the room
[06:51:00] Dan Harkins leaves the room
[06:51:00] Dave Thaler leaves the room
[06:51:01] Deb Cooley leaves the room
[06:51:01] <Tim Cappalli> thanks all
[06:51:01] Jari Arkko leaves the room
[06:51:02] HAIGUANG Wang leaves the room
[06:51:02] Alissa Cooper leaves the room
[06:51:02] Robert Moskowitz leaves the room
[06:51:03] Timothy Winters leaves the room
[06:51:03] Chenhe Ji leaves the room
[06:51:03] Joey Salazar leaves the room
[06:51:04] Ben Campbell leaves the room
[06:51:04] Victor Kuarsingh leaves the room
[06:51:04] Mark McFadden leaves the room
[06:51:04] Chunshan Xiong leaves the room
[06:51:05] Eric Levy-Abegnoli leaves the room
[06:51:05] Malay Vadher leaves the room
[06:51:05] mcr leaves the room
[06:51:06] Joseph Salowey leaves the room
[06:51:06] Peter van Dijk leaves the room
[06:51:06] <Jason Weil> Thanks all
[06:51:06] Olaf Kolkman leaves the room
[06:51:06] Yoshifumi Atarashi leaves the room
[06:51:06] Nancy Cam-Winget leaves the room
[06:51:06] <Glenn Deen> cheers all
[06:51:06] Juliana Guerra leaves the room
[06:51:07] Kirsty P leaves the room
[06:51:07] Ralf Weber leaves the room
[06:51:08] <Bob Hinden> Good night
[06:51:09] Andrew Campling leaves the room
[06:51:09] Paolo Volpato leaves the room
[06:51:10] Tim Cappalli leaves the room
[06:51:10] Chris Box leaves the room
[06:51:11] Loren McIntyre leaves the room
[06:51:12] Stephen Farrell leaves the room
[06:51:12] Zhuangyan leaves the room
[06:51:13] Cullen Jennings leaves the room
[06:51:15] Li Yizhou leaves the room
[06:51:15] Hermin Anggawijaya leaves the room
[06:51:16] <Éric Vyncke> Coffee time !
[06:51:16] Toerless Eckert leaves the room
[06:51:16] Adam Wiethuechter leaves the room
[06:51:16] Tommy Pauly leaves the room
[06:51:16] laxmi mukund leaves the room
[06:51:16] Francois Ortolan leaves the room
[06:51:17] Stephen McQuistin leaves the room
[06:51:18] Bob Hinden leaves the room
[06:51:20] <Yiu Lee> Thanks for the Chairs and AD, and everybody who joined. Nice BoF!
[06:51:20] Toerless Eckert joins the room
[06:51:20] Marc Portoles-Comeras leaves the room
[06:51:24] Glenn Deen leaves the room
[06:51:25] Erik Kline leaves the room
[06:51:27] Marco Liebsch leaves the room
[06:51:30] Phillip Hallam-Baker leaves the room
[06:51:33] Sun Kj leaves the room
[06:51:33] Oliver Borchert leaves the room
[06:51:35] Russ Housley leaves the room
[06:51:36] Jason Weil leaves the room
[06:51:37] Yiu Lee leaves the room
[06:51:40] Michael Jenkins leaves the room
[06:51:44] Yuexia Fu leaves the room
[06:51:46] Alister Winfield leaves the room
[06:51:49] Kohei Isobe leaves the room
[06:51:51] David Luu leaves the room
[06:52:00] Stuart Card leaves the room
[06:52:05] Taiji Kimura leaves the room
[06:52:11] Toerless Eckert leaves the room
[06:52:13] Éric Vyncke leaves the room
[06:52:19] Rick Taylor leaves the room
[06:52:26] <Juan-Carlos Zúñiga> Thanks to the note takers and jabber scribe!
[06:52:33] tim costello leaves the room
[06:52:57] Mohit Sethi leaves the room
[06:53:08] Jie Yang leaves the room
[06:53:39] Andrei Gurtov leaves the room
[06:55:19] Kazunori Fujiwara leaves the room
[06:56:01] Valery Smyslov leaves the room
[06:56:05] Wei Pan leaves the room
[06:57:26] Chi-Jiun Su leaves the room
[06:57:53] Eliot Lear joins the room
[06:58:10] Eliot Lear leaves the room
[06:58:29] Philip Eardley leaves the room
[06:58:29] Tobia Castaldi leaves the room
[06:58:29] Donald Eastlake leaves the room
[06:58:29] Alexandre Petrescu leaves the room
[06:58:29] Carlos Bernardos leaves the room
[06:58:29] Daniel Gillmor leaves the room
[06:58:29] Julien Maisonneuve leaves the room
[06:58:29] Monika Ermert leaves the room
[06:58:29] mackermann@bcbsm.com leaves the room
[06:58:29] Tirumaleswar Reddy.K leaves the room
[06:58:29] Quang-Huy Nguyen leaves the room
[06:58:29] Zhen Cao leaves the room
[06:58:29] Tadahiko Ito leaves the room
[06:58:29] Yutaka Oiwa leaves the room
[06:58:29] Juan-Carlos Zúñiga leaves the room
[06:58:29] Bhavit Shah leaves the room
[06:58:29] Huaru Yang leaves the room
[06:58:29] Stephanie Ifayemi leaves the room
[06:58:29] Andrew S leaves the room
[06:58:29] Paolo Saviano leaves the room
[06:58:29] Glenn Parsons leaves the room
[06:58:33] Bob Moskowitz leaves the room
[07:01:08] Meetecho leaves the room
[07:10:53] glennparsons joins the room
[07:12:14] dee3@hot-chilli.net leaves the room
[07:13:22] glennparsons leaves the room
[07:17:03] sftcd leaves the room
[07:21:00] mjenkins leaves the room
[07:25:57] alex-meetecho leaves the room
[11:23:51] dkg leaves the room
[17:23:28] ko-isobe leaves the room