Hi Yukiko, thanks for your comments. It's much appreciated.
I will definitely look up the possibility. I wasn't aware that there is a specification for FIDO servers, if you have a link for that I'll definitely look that up and see if we can modify the draft.
The reasoning behind the current design of the EAP method and the handling of the FIDO challenge has two main thoughts:
First, we want to facilitate a cryptographic binding between the FIDO authentication and the TLS tunnel. This way we rule out cross-protocol-attacks. If we would rely on a challenge generated by the server, we would probably loose this channel binding, which could lead to attacks. For example: A malicious server could use the authentication it received via WiFi login for a WebAuthn login, by just proxying the challenge from WebAuthn through to the client trying to log in to wifi. Or in a middle-person attack an attacker that manages to gain a proxy-position where it poses as TLS server to the client and as client to the TLS server, the attacker could use the FIDO authentication for themself because they just proxy the authentication requests through, but would export the WiFi keying material from their TLS connection with the real server, and would gain access.
I would need some time to assess whether or not these attacks are in fact possible and what exactly it would need to prevent these types of attacks with the missing TLS export included in the FIDO challenge.
I already have the possibility in the EAP method that a FIDO server can provide an additional challenge part, so that the challenge is not completely generated from the TLS export material. But until I can verify that cross-protocol attacks and middle-person attacks are not possible, I want to keep the TLS keying material in there.
The second reasoning is with regard to the current way the clientData is generated. The WebAuthn document specifies a JSON-like structure with Base64 encoded fields for binary data, static strings like "webauthn.get" or "webauthn.create" and so on. This works for well for webbrowsers I suppose, they support JSON out of the box I guess.
We don't want to use this in our EAP method for multiple reasons.First, using "webauthn.get" and "webauthn.create" would again lead to cross-protocol attacks. We are not doing WebAuthn. We're doing something different. The structure of the clientData is not specified in CTAP, and that's what I was looking at (at least in the early development)
In any case, the FIDO servers would have to be updated to accommodate for the new authentication mechanism, where it does not use the static strings "webauthn.<something>", so we could just define a new message structure, which also gets rid of the Base64 encoding. For the current proof-of-concept implementation, we simply use a concatenated binary input string as clientData. For future versions of this draft I could imagine that we switch to a CBOR structure.
In my personal opinion (and maybe as a suggestion for any FIDO folks reading this list):
The FIDO alliance (or W3C, I'm not sure who is better suited) should define a common message format (preferably both in binary and in ascii format) for the clientData, so that new protocols on top of the FIDO architecture can evolve, without having to put in efforts to avoid cross-protocol attacks. With such a message format you could have a field in the beginning that states the protocol name (with a public registry for protocol names).
This would open up the FIDO world to other use cases than the Web. (Few examples: SSH-Login, Mail with SMTP/IMAP, ...)I think the openSSH FIDO implementation also used a custom clientData format based on their internal message format. The format is so different from WebAuthn that cross-protocol attacks are very unlikely, but when more and more protocols emerge that use FIDO specs in the background, at some point we will have an overlap with unintended consequences.
That all being said, I'm not that familiar with the whole FIDO world yet, and if you or anyone else can give more insight, I'd be happy for pointers/explanations/contacts to people involved in the specification/...
And the current method specification is not set in stone, I'm happy to adjust it to make it more usable.
Cheers, Janfred On 16.10.24 07:13, Yukiko MINAMIE wrote:
Hi Jan-Frederik Thanks for the draft. The draft states that the FIDO2 challenge is derived from the TLS keying material, and that the EAP-FIDO server verifies the FIDO signature using the public key stored in the database. I am afraid these specifications will limit the wider adoption of EAP-FIDO. The FIDO Alliance has defined the specification of FIDO2 server (which is part of WebAuthn Relying Party's server function), and FIDO2 servers operate as the backend for the WebAuthn Relying Party. Therefore, I would like to suggest reconsidering the EAP-FIDO specification to enable the use of FIDO2 server. Since FIDO2 servers that have passed the FIDO Alliance's conformance self-validation possess a common REST API, it is possible to delegate challenge generation and signature verification to the FIDO2 server using this REST API. FIDO2 servers are designed to generate their own FIDO2 challenges, which means that the current EAP-FIDO specification, using FIDO2 challenges derived from TLS keying material, does not allow for the use of existing FIDO2 servers. Could you consider alternative methods to using FIDO2 challenges derived from the TLS keying material to bind the TLS handshake phase to the FIDO-exchange phase? Any feedback or comments on this matter would be appreciated. Thanks,
-- 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 https://www.dfn.deVorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
