On 24.10.23 10:58, josh.howl...@gmail.com wrote:
It is good to see this work progressing.1. I agree with Hannes' observation that it isn't necessary to premise EAP-FIDO on the claimed weaknesses of other EAP methods. I suggest replacing paragraphs 2-5 with content summarising the proposal. In particular I am surprised that the document doesn't discuss (what I would consider to be) the main benefit of using FIDO: the ease of provisioning a credential to the supplicant.
I must confess, the text is mainly driven by my bad experience from my days as part of the eduroam administration team at the university of Bremen, and my current experience with a change in the root certificate for almost every eduroam IdP in Germany, because the self-operated CA almost every institution used stopped issuing server certificates and we are now migrating to a new CA provider.
The wording in the draft is a bit harsh, and I sincerely apologize to everyone that felt offended by that wording, that wasn't my intention. I'll adjust that for a future version of the draft.
There are several reasons to specify the EAP-TLS certificate validation the way it is specified, and it works fine if the configuration is pushed to the clients, i.e. by MDM mechanisms. The spec leaves all degrees of freedom for server operators, and does not have any external dependencies, which is great for managed devices.
But the moment you enter the BYOD world, users will get it wrong and there is no default way that is secure. Admins need to publish the information about CA and Server Name and need to rely on the user's ability to configure this correctly. And server operators have no way of verifying the configuration on client devices, unless they operate a rogue AP and log which users log in there, to give them a slap on the wrist.
And the reason that Android for a long time hat "Do not validate" as a default setting for EAP-TTLS/EAP-PEAP is a symptom of the problem here: It is much more easy to just disable the security checks than it is to configure them correctly.
2. I am not persuaded by the two arguments given in section 6.3 for not reusing existing tunnelled methods.
I'm open to discuss this with an open mind, the first draft is just the way that I imagined it, if there are reasons to do it another way, I'm not set on the current spec.
* Misconfiguration of server certificate validation parameters: perhaps I am missing something, but in terms of the UI can't this be solved by disabling the parameter options/fields if the EAP-FIDO inner method is selected?
Definitely this could be done. Maybe I'm just too pessimistic here to expect that UIs will get it wrong.
* Export of TLS material: I thought this TLS material is often required by phase 2 of other tunnelled methods? E.g. for validating cryptobindings.
I don't know exactly what you mean by that?The current spec uses exported TLS material to generate the FIDO challenge, so the FIDO-Auth is bound to the TLS tunnel. One question would be if we can achieve the opoosite, that is: binding the exported MSPPE-Keys to the FIDO auth too, not just the TLS tunnel.
I think there is an argument that defining EAP-FIDO as a method that could be used within PEAP, TTLS and TEAP could drive adoption. 3. I have unsure about tying this specification so tightly to the WebPKI. There is a tremendous convenience in using the WebPKI for validating the server certificate, but the WebPKI is not a well-defined concept. In practice, it is the bucket of CAs that my OS vendor preinstalls on my device. The conflation of protocol design (fixed in code) with operational choices taken by third-parties (so subject to change) could lead to unexpected outcomes.
I agree with your last sentence, we definitely introduce a third party that we cannot control (or even anticipate their actions). But the idea here is to build a system where we have a default way of configuration that is somewhat secure, and since we can't really establish a trusted EAP-FIDO CA that every device will trust, leveraging the WebPKI for that is the next best thing.
And we already need the WebPKI for the FIDO registration process. 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
