propose relies on TLS. The TLS-based authentication is an essential part of the FIDO solution. Without TLS it is completely insecure.
I don't complain about TLS or EAP-TLS itself.I complain about the way certificate checks are implemented in EAP-TLS based methods.
To put it in an analogy:We have a wobbly bridge (our TLS tunnel) to cross the dangerous river (the untrusted world). You can cross the river any time, but if someone shakes the bridge, we fall off (the attacker can intercept and modify all traffic, because they intercepted the TLS traffic). We have a safety rope, that keeps us from falling (the certificate check). But we need to put on a harness and hook into the safety rope (configure expected Server Name and trusted CA) in order to safely cross the bridge.
And as long as no one shakes the bridge, you can cross it and nothing happens, even if you're not attached to the safety rope.
Of course we can now say: "But we have security measures, just hook yourself into the safety rope", but the users are used to have all that taken care of (i.e. if you use a browser, the browser puts on the harness for you and hooks you into the safety rope). They have no idea how to put on the harness. And it's tricky, if you do it wrong, you can't even cross the bridge any more because the hook blocks the moment you hook into the safety rope (the certificate check fails because of wrong parameters).
So it is easier to just leave the harness off.For the current EAP-TLS based methods, the "service" of putting on the harness and hooking you in is not provided. And that is exactly what I want to achieve with the TLS part of EAP-FIDO. The users shoulnd't see any of the certificate check parameters, it should be implicit and that is where we improve the security of the EAP-TLS based method (Details: see last paragraph of this mail)
Regarding the key extractor use you describe below: I don't remember this technique being used by FIDO. I have worked in the FIDO Alliance in the early days on U2F / UAF but might have missed some more recent developments.
I don't understand what exactly you are referencing here. Do you mean the idea to export the FIDO challenge from the TLS context?I haven't yet had the time to completely and fully read through the FIDO specification to analyze if the current protocol specification has weaknesses in regard to the clientDataHash that is to be signed by the FIDO token. It does not have the same format as specified by WebAuthn, but maybe there are some aspects that need to be addressed.
Regarding the benefit of FIDO: I don't think the "main benefit of using FIDO is the ease of provisioning a credential to the supplicant". Once you have an authenticated channel, it is trivial to provision new credentials. There are hundreds of protocols that do that.
And yet we have an app to set up eduroam, because we don't have a working provisioning protocol for EAP configurations. Every vendor has their own format and a different configuration API (that sometimes drastically changes between OS versions).
On the security front I am wondering whether the introduction of this use case weakens the use of FIDO for the web. In the web case, an important aspect is to perform authentication and authorization of the domain name with which the credentials are later utilized. For network access authentication the domain authentication and authorization is, as you have been mentioning in the draft and also in your emails, rather weak. Have you looked into this aspect? Attacks that result from cross-protocol use isn't uncommon.
The possibility for cross-protocol attacks is definitely a thing that needs to be addressed in the security considerations section.
The idea is to have a similar strong bind to the server certificate in EAP-FIDO as we have in WebAuthn. How exactly this is achieved is still TODO, as outlined in the "Open Questions" section in the I-D.
But this strong binding is essential. 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
