Administrivia (5 minutes) scribe selection / NOTE WELL Agenda revision Joe presenting the chair slides Scribe: Alan & Others WG draft updates TLS-based EAP types and TLS 1.3(10 Minutes) Alan Dekok: Not a lot of changes. Aligned with TLS 1.3. Session ticket not valid until inner authentication complete comment from vendors that we should use anonymous identifiers in the inner tunnel Joe: what is bad with anonymous id in the inner layer Alan: real username inside. cannot meaningfully anyone if anonymous identifier is also used in inner authentication Sean/Mohit: would not work without real identity for inner authentication Alan: Exactly Jan-Frederik: some rare cases where outer and inner identities have different realms Alan: take it to list for technical discussion, it's not clear where the use-cases are for that situation Joe: couple of things to resolve. How many have read a recent version of the draft? Sean and Jorge have read Need a couple of more people to review. Would feel better. Anybody wants to commit to reading/reviewing this draft? Bernard volunteers Mohit volunteers Additional Topics EAP Usability(20 Min) Alan Dekok: a bit of a monster draft. Just under 60 pages and getting bigger. EAP is hard to use. People make random changes to everything. Initial focus is end user devices NAI from username -> DNS lookup -> verify web cert -> Cert verification -> certs can include SSID lots of details in the draft about various cases. may require some limited initial network access. possibility to use unauthenticated EAP-TLS. works with captive portals there's running code no need for trust on first use. seems simple enough. can be deployed as an extra utility Dan: Alice doing DNS lookup for Bob's certificate. But doesn't require IP connectivity Alan: does require some network connectivity. 2 ways to do this: LTE/4G/5G backhaul for lookup. not in document yet: just connect to the SSID with unauthenticated EAP-TLS. EAP server puts in captive portal. Bring it back up with new configuration. Sean: does this require a web trust anchor, or can anything else be used? Alan: this is just a trust anchor. key thing is to leverage pre-existing trust and pre-existing connectivity. Web is just an example Joe: web pki to authenticate web server. from there you get trust roots for EAP connection? Alan: Loke EST there is ./well-known/est/ca. If you trust that CA then you trust that server to give you the EAP server cert. lot of discusion in draft. Alan: no idea whether cer tificate is okay. user has no way of telling that it is okay to enter username/pass Mohit: captive portals? Alan: enter credit card in captive portals. user can avoid web pages. put in walled garden. hope is to take the person out of the process. EAP-DPP(15 Min) Dan: Owen and I working on it for a while Bootstrap client into a Wi-fi network Base64 encoded ASN.1 seq right in the middle of psk and full certificate using the same public key for both device identification and network access use DPP to authentication a TEAP exchange, and then use that to provision a certificate on the device minor additions to TLS, no changes to existing RFCs has been presented to TLS WG. No comments there for the TLS approach. Can it be adopted in EMU as a solution to the IoT problem? Joe: call for who has read it? (Sean, Alan, Dan) Will need a few more in order to have enough for reviews Roman: can we get some volunteers who are interested Joe: something we need to work on. little more discussion on the list Jorge will do his best to provide a review EAP-TLS-IBS(10 Min) Meiling: Already presented at IETF 109. We just use IBS. have running code. based on eap-tls1.2 and ECCSI. No cross scope with IOT ops Key distribution is out of scope Updates made to IANA considerations and abstract Added a round trip when compared to emu-eap-tls13 get a new EAP type and use it in the key derivation comments? Joe: has anyone read the draft. No answers Sean: I am not a lover of IBS. I am okay with people exploring. WG or AD sponsor is okay for me. Joe: Need people interested and working on this draft. Possible to take it through individual mechanisms. get some more people interested in this use case. Additional discussion on the list will be useful. End of session