On Oct 30, 2024, at 1:13 PM, Jan-Frederik Rieckers <rieck...@dfn.de> wrote: > The problem I have with this approach: > This could make cross-protocol attacks possible.
Sure. If we want EAP-FIDO to have the same workflow as normal web FIDO, then we need to have the server generate the challenge. There are a lot of benefits to this approach. > I think/suspect that the available FIDO servers are fixed on the clientData > structure expected from WebAuthn (JSON-like structure with static strings > "webauthn.get" or "webauthn.create", base64-encoded challenges, etc) > If we would allow the use of FIDO servers without including the protocol > context, attacks could be possible where a wifi authentication could be > intercepted and used for web authentication or vice versa. Yes. > The precondition for an attack would be: > either one of the parties involved is acting malicious (i.e. forwarding > things only intended for itself via a different protocol) > or > an attacker is able to gain access to the data sent through the TLS tunnel. > > If we choose to work under the assumption that the TLS tunnel is secure and > cannot be broken, then we can simply get a challenge from the FIDO server, > send the challenge over to the EAP client and have them sign it. We should assume that the TLS tunnel is secure. Any cross-protocol forwarding attack is severely limited by the fact that the EAP server cert (a) is issued from the web PKI, and (b) has the correct domain information. So the attack is that we have two TLS servers (EAP and web). Both have certs issued by the web PKI. Both have the same RFC 9525 server identity (or at least identities from the same domain). i.e. My EAP server can forward FIDO traffic to my web server. But your EAP server can't forward traffic to my web server. So is this an attack we care about? It may be sufficient to say "attacks within your organization are possible, but the solution to that is to police your organization". But cross-organization attacks aren't possible. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
