On 25.10.23 17:31, Michael Richardson wrote:
> Since the credential is not necessarily used on the same device that the FIDO > credential was registered (example: YubiKeys that are registered by the admin > and then issued to the user), the information needs to be stored in the > registration information somehow. I'm not sure if that is possible and/or > manageable.It seems to me that this can be solved, but I agree that it isn't solved yet. So we probably need a configuration knob here. One thing that I know a few people have talked about is having a standard configuration format for clients.
For general EAP methods - yes, definitely.For the current use case with FIDO keys, I don't know if we had different viewpoints, so I'll just clarify my point: Since FIDO tokens are basically "transferable" between devices (either by pulling the hardware token out and plugging it into a different computer or by some Vendor-magic with software FIDO token to share them between devices of the same person), how do we ensure that the CA pinning is transferred too? It is a valid use-case to have a FIDO token for your login and use a different device every time, i.e. a pool of company laptops with standardized logins, but for network access you need a YubiKey and then you can do EAP-FIDO.
> But we don't have this in BYOD environments like education institutions.
And probably in fewer and fewer enterprises given BYOD.
As a goal, we need to migrate to more use of EAP-TLS in home environments.
RCM requires it in the end.
I don't think that EAP-TLS (EAP-Type 13) is really a goal we should try to move everybody to. Client certificates expire and we have the bootstrapping problem, which is still not solved satisfactorily. And the current EAP-TLS based methods like TTLS and PEAP have a bootstrapping problem that's circumvented by choosing "Do not validate".
If we solve the bootstrapping problem, then we can also provision all the security parameters easily. It's definitely worth the effort to try that, but to actually have a reliable and secure way to do that, every device needs to be able to understand ONE standardized format. Currently we have a patch-work of different file formats or APIs (that may not even have a stable definition) and this is the root cause for so many problems in eduroam provisioning.
With EAP-FIDO, the amount of configuration needed is significantly reduced, so the user acceptance to type in the last few config options should be there. The bootstrapping will be much easier, especially if the Passkey that should be used with WiFi is already registered with the institution. Then it's really just "Hey Phone, I want to use this WiFi with EAP-FIDO, and my realm is example.com".
Cheers, Janfred -- Herr Jan-Frederik Rieckers Security, Trust & Identity Services E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370 Pronomen: er/sein | Pronouns: he/him __________________________________________________________________________________DFN - Deutsches Forschungsnetz | German National Research and Education Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V. Alexanderplatz 1 | 10178 Berlin www.dfn.deVorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
