# EMU @ IETF115 {#emu--ietf115} Notes: Janfred ## Administrivia (5 Min) {#administrivia-5-min} No addition to the agenda. ## Certificates issues (20 Min) {#certificates-issues-20-min} Alan DeKok presenting. Had a lot of discussion about usage of certificates in EMU. Question: Where to go next? Joe: Two sides of usage (server and client side), what is the scope? Alan: Both. Anything. Joe: Authentication of server certificates often Trust-On-First-Use with no concrete information. Don't know if there is a good solution to this problem? Stefan Winter: speaking for eduroam: Pushed users to use provisioning tools. Try to make it impossible not to use them. With new WiFi-Alliance standard "Do not validate" setting in Android is now forbidden. One way to do this is to configure RADIUS/EAP-server to accept only one special outer ID, so clicking on network and entering passwords does not work -> Users then use the provisioning tool. Joe: What CA/Servername requirements are you using? Stefan W: Institutions can choose freely, many choose a commercial CA, some have a private CA, some have a self-signed user. Alan: This is a big step forward. Did a test few years back and got a lot of credentials with bogus AP. Massimiliano: In cable network, managing credentials is difficult. Different sets of credentials, one to get on the network and one for user-level actions. The first one is often forgotten. We proposed protocol EAP-CREDS to use EAP for provisioning credentials, which makes management of credentials easier. Karri: One topic: How to separate problems. Problems with RADIUS servers (e.g., expiry) can be handled with automation. But user devices are a problem, especially if not in Mobile Device Management. Finding a good way to provide client certificates to those devices is hard. Stefan W.: Problems with EAP is it is used to get online. Therefore, there's a problem between Online vs. Offline configuration. Offline configuration (e.g., with CAT tool) works well, but it is not very convenient compared to fetching a website to get your profile. Alan: Some issues are addressed in the draft: Most devices have two network devices (e.g., Mobile network for Phones or Network at home instead of corporate network access) It may be useful to define something like @eap.arpa (see ML), unauthenticated EAP-TLS as onboarding network. Feedback from Vendors: RADIUS-People don't talk to Network/DNS/Webserver people, difficult to do in some environments. Technically simple, administratively hard. Deb: Are you talking about devices or people? (capable devices?) Alan: Generally people's devices (phones/laptops), IoT is out of scope. Deb: You don't want to go down the rabbit hole of PKIX? Joe: We are in the PKIX world because of TLS. Alan: Problem: Where does the configuration come from? (e.g., SSID, EAP-Method), which is typically not part of certificate. Deb: Also what's the specification for naming? E.g., CA/B-Forum? We're not talking web? Alan: Most people use web server certificates for RADIUS servers which does not completely comply with the CA/B-Forum policies. Deb: Sounds like public/private CA mix? Alan: Yep. Deb: Both have their issues. If you do public, you don't have to deal with the trust store. Joe: This introduces new problem of how to validate certificates. Deb: Getting client certs is also a problem? Alan: Yes. It's expensive to get an intermediate CA for your own users. You can't get a certificate with NAIRealm in it, as the CA/B Forum will reject this. And you cannot get certificate with custom OIDs or specific extended key usages. Deb: What draft is this in? Alan: eap-onboarding and eap-configuration, look for my name. Josh: I heard mention of DNS/eap.arpa, what's that about? Alan: TEAP does provisioning over TEAP. I don't want to define "IP over EAP", it just smells. Instead have a onboarding network accessible with unauthenticated EAP-TLS with a specific identity. Stefan W.: for eduroam, there is a growing understanding that passwords are on the way out. The new service is with a portal where you log in with web credentials and get a TLS client certificate for EAP-TLS. When you download your client cert, you also download the whole configuration. Alan: There's also the open possibility of Passkey support (essentially raw pub/priv key pairs). Karri: Some devices have a common certificate store, if you install a custom CA it can be used for everything else es well. Most RADIUS servers use web server certificates and no one cares. If a certificate expired, devices with the wrong configuration continued to work. Alan: Additionally: Only reply on failure is "Failed." We need to improve the user feedback. Janfred: How do devices know the correct server name for certificate validation. Can't they simply use the realm of the NAI and check for that. Alan: See the configuration document. Theory: Everyone has a reasonably capable device with a cert store. The device connects to a web server and downloads a configuration file. Joe: Is there work in the Wi-Fi alliance? Stefan W: There is a long expired draft. It got no interest in the IETF; every vendor has their own thing, but Wi-Fi Alliance had no interest. Joe: Alan has a couple of drafts. It would be good to have more people to look at this. Vadim: What's suggested is that you are authenticated as aguest, then do the config, then connect again. In some places that might not be acceptable to have untrusted devices on the network, even with aseparate VLAN for onboarding. Janfred: Question to discuss: Is it safe to assume that we have a second channel or should we also provide methods for in-band provisioning. ## Update for EAP-AKA {#update-for-eap-aka} Jari Arkko presenting. From the authors' view there are no open issues. No direct 3GPP link to this but there is interest from vendors to finish the spec. Heikki: Does it interoperate with IMSI privacy extensions? Jari: Not aware, should not in general, let's talk afterwards. Could you send some links to this? Joe: Seems ready for WGLC, IMSI privacy seems not to have an impact on this. ## EAP-DIE (15 Min) {#eap-die-15-min} Josh Howlett presenting. EAP-DIE is about deprovisioning. Alan was talking about provisioning. I'm talking about the reverse. Usually two methods of management: Device Management and manual administration. No draft yet, for now just here to get feedback. Stefan W: We looked at the notification 10 years ago. This is underutilized, you will get a wide variaty of reactions from different supplicants. Vadim: Had trouble just getting on Wi-Fi. Can you use this to send debug information? Josh: No, since we don't have the cryptographic keys needed for the MAC, so you can't be sure the message came from the EAP server. Heikki: Profile lifetime is not necessary device lifetime if profiles get transferred automatically to a new device Joe: Concern with the state machine, probably some key material things to work out. Janfred: In regard to question 4 (Limit due to requirement for previous successful auth): it would be good to just disable the configuration instead of deleting it, so if the timeframe is too short and people come back, they don't have to get new credentials. Joe: Overlap with provisioning? Matthew: There are other cases when you want to send messages. Do you want to disconnect this from the message, so supplicants don't show the new expiry date every time? Vadim: Do you plan to differentiate between machine auth and user auth? Joe: Will have further discussion on the list. ## EAP-UTE (10 Min) {#eap-ute-10-min} https://datatracker.ietf.org/doc/draft-rieckers-emu-eap-ute/ Janfred presenting. Was presented in Vienna, no feedback so far. Joe: Probably an item to post to the list. People with experience may not be present here, since it is a niche-protocol. ## Bootstrapped TLS Authentication (10 Min) {#bootstrapped-tls-authentication-10-min} https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/ Dan Harkins presenting. There will be effort to have implementations of this. Joe: Will have more discussion on the list to determine how to move this forward.