# IETF 114 -- EMU {#ietf-114--emu} ## Administrivia (5 Min) {#administrivia-5-min} * Mohit has stepped down as Chair, we thank Mohit for his work. Peter is the new Co-Chair of EMU ## Working Group Documents (40 Min) {#working-group-documents-40-min} ### TLS-based EAP types and TLS 1.3 (20 Min) {#tls-based-eap-types-and-tls-13-20-min} https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/ * Document seems to be good to go. No known implementation issues. * Some questionably implementation choices for one major implementation, but not a blocker * Bunch of reviews, all addressed in the latest version. * Ready for a Last Call. * Joe: Probably no need for another WGLC. ### EAP-AKA' FS (20 Min) {#eap-aka-fs-20-min} https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/ * Protocol has been ready for some time. * Request for WGLC * Discussion about the encoding of P-256 * Same encoding is used in 3GPP 5G spec * Given this, want to keep it this way and move forward * **No objections in the room** * Joe: We'll start the WGLC soon. ## Non-Working group Items (40 Min) {#non-working-group-items-40-min} ### EAP-DPP (15 Min) {#eap-dpp-15-min} https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/ * Idea: Reuse the DPP mechanism to onboard devices on wired networks * Changes from IETF 113 -04 * Use of tls-external-psk-importer instead of tls-extensible-psks * DPP uses TEAP and after authentication use PKCS#10 to provision the credentials * Running code existent, received reviews from tls wg * request Consensus call for WG adoption * John Mattson: Concerned about privacy. Are bootstrapping keys used only once? * Yes, after bootstrapping the bootstrapping keys are never used again. * Hazel Smith: By 'not used again' do you mean "until it needs to re-pair to the network" or once ever? * May be after reset to factory defaults, but basically a one-time key. * Ira: tls-external-psk-importer is already published as RFC 9258 * Joe: Should start adoption call after this IETF. ### EAP-EDHOC (15 Min) {#eap-edhoc-15-min} https://datatracker.ietf.org/doc/html/draft-ingles-eap-edhoc-01 * Reviews/Comments from ML have been addressed, no major changes expected. * Request Call for adoption * Joe: Want to see more discussion on the list, also need to evaluate if this falls into the charter, may need to amend the charter for the WG. Maybe see first if there is support/interest for this draft. ### EAP onboarding(10 Min) {#eap-onboarding10-min} https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/ * Presented in anima on Monday. Question if this is for anima or emu, there is an overlap. * Wants to solve problem of device onboarding for BRSKI. * First do unauthenticated EAP-TLS handshake, join a captive portal network, then do BRSKI * Avoids stuffing BRSKI in EAP, instead uses existing captive portal infrastructure * Something like this already in use by Hotspot 2.0 * Paul: If based on Wi-Fi Alliance, maybe IPR concerns? * Alan: Don't know if Wi-Fi Alliance has IPRs, but given RFC 5216 defines unauthenticated TLS, there should not be any IPRs * Dan: for "CA root is good enough for browsing" maybe not good to show you're the correct owner for a network. CAs give out certs for web browsing, not for onbording. If you want to reuse a cert, maybe come up with a better reason * Alan: Additional bootstrapping problem: when authenticating to a network, it would be good to authenticate it. CAs don't issue certs for onboarding or EAP, CAB Forum only allows issuing for HTTPS; this is a general problem. * Bernard: Uncomfortable with eap.arpa * Alan: eap.arpa is a signal from the supplicant that it wants a captive portal network. If not using this, there might be confusion. "eap.arpa" is to signal 'I don't know who I am', so the server knows the device wants to bootstrap. * Dan: For choosing the network: Round-robin through all visible networks? * Alan: Perhaps, also an issue for BRSKI. IEEE 802.11u allows to broadcast domains. eap.arpa should be advertised. Other than that, there is no other choice then to do round-robin. * Hendrik B: BRSKI has methods build in to determine which network to connect to. MASA-Voucher-Connection provides means to authenticate the network. * Alan: This proposal is only to get connectivity, once you have connectivity you can do anything you want. You should not throw anything in EAP. * Jari: Is there some means/need to corellate information about the server to the network? (e.g., SSID example, cert for bla.com) * Alan: It would be good to have a channel binding. * In terms of Web-PKI: This is what people do now. * Joe: What is your intention? * Alan: Current draft is just a line in the sand. We'll address the issues raised. Question: since this is intended to support BRSKI: Should this go to anima or emu? This draft is more EAP and BRSKI is just the second step you can run after the connectivity is there, so probably more an item for emu. * Dan: Coming back to BRSKI, BRSKI has a mechanism to determine if you are in the correct network, this should resolve the issues with choosing the correct network. The draft could just ignore the authentication of the network the device connects to, BRSKI will do the rest. ## Future of EMU (15 Min) {#future-of-emu-15-min} * We are getting through with the Charter items. * Had some discussions on EAP in general. * We have to make a decision up to the next IETF on what to do in EMU next. * Alan: Still have another EAP document on EAP configuration. Something similar in the Wi-Fi Alliance. * Theory: Based on DNS/Webserver lookups you can get your EAP-Configuration (e.g., EAP-Method, CA-Certs, ...) * Dan: Any progress for password-based EAP-Methods? EAP-PWD has issues, maybe define a new EAP method that uses CPACE. * John: Alan's drafts show there is a need for more guidance for usage of certificates. * Joe: Maybe need for a recharter, give it some more thought and discuss on the ML. * Janfred: Heads up, there will be a new version of EAP-UTE soon; I did not managed to get it in before IETF 114. Happy to receive feedback on this.