(trimming responses to EMU) On May 22, 2024, at 5:33 PM, Heikki Vatiainen <h...@radiatorsoftware.com> wrote: > I'd say if EAP-TLS is allowed then SIM based EAP should be allowed too. A > couple of reasons follow:
Sure. My general inclination is to recommend against using things which are uncertain, unused, or unknown. It usually saves on later confusion. > First, EAP-SIM, EAP-AKA and EAP-AKA' have a bit similar privacy problem that > EAP-TLS does with TLSv1.2 and earlier. The SIM based EAPs reveal the user's > identity, the IMSI from the SIM, that is unique and can be used for tracking > a the SIM user. This happens with the first authentication. With subsequent > authentication there three EAPs have ways to use temporary identities for > privacy. > > Even with temporary identity, if an attacker can make the SIM based EAP > client to try to authenticate, the attacker can request the real identity. > This is allowed because the client can't reliably know when the server has > lost the track of temporary identity. Sure. I'll add a note to that effect. > Windows, for example Windows 11 on a laptop with a SIM slot, supports > EAP-TTLS with SIM based EAP as inner protocol. Similarly Android (WPA > supplicant) supports tunnelling SIM based EAPs over PEAP. Plain WPA > supplicant likely supports any EAP within TEAP tunnel. > > Second, considering draft-ietf-emu-aka-pfs, I'd also say this draft gives one > more reason to use a tunnelling EAP when use of plain SIM based EAP is a > concern. > > With the above being said, using SIM based EAPs with tunnelling EAP methods > is likely rare. I have never seen them used in practice. However, real > implementations exist that allow doing this. Maybe, for example, IOT experts > could say if they see use for TEAP/PEAP/EAP-TTLS used for tunnelling SIM > based EAPs? Sure. I'll update the document. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
