It looks good as a first draft. Some first draft comments: I would suggest that the default should be to using the Web PKI for server authentication, unless there's a client configuration which says to use a different CA. This behavior means that configuring EAP-FIDO for a domain is simple:
* somehow provision FIDO using public net access * associate that domain + FIDO + keys + SSID. Note that there's no "configure trusted CA" or "configure trusted server cert". We can instead leverage the web PKI. The client needs to signal which server it's authenticating to (RPID). Since EAP-FIDO is likely to be proxied, the only safe choice here is an anonymous NAI. Other choices are possible, but since they can't be proxied, they're much less useful. This choice means that each SSID can be associated with only one domain, but that's an existing limitation so it's not all that terrible. The requirement for EAP packets to be proxied means that the client must supply a domain for authentication, which pretty much prevents it from using other domains. CBOR wouldn't be my first choice. But it's 2023, so whatever. I like the idea of deprovisioning as part of specification. Ideally it could be driven by either end of the conversation. i.e. the user should be able to say "I don't want to talk to this domain any more", and the authenticator should be able to say "I've deleted your user account". Deprovisioning user credentials could be part of a non-EAP FIDO process, too. But there definitely needs to be a way to deprovision the *EAP* configuration portion. > On Oct 23, 2023, at 6:38 PM, Jan-Frederik Rieckers <rieck...@dfn.de> wrote: > > Hi emu folks, > > as already teased at the last IETF, we finally have a first I-D ready for > EAP-FIDO.[1] > > The basic idea: > Password-based network authentication is not really state-of-the-art any more > and, due to failure to verify the server certificate, sometimes even > completely broken. > Almost every device nowadays has a TPM chip or something similar, that is > able to speak FIDO, either with the help of the OS or generically. > So, why not use FIDO to log in to networks? > > There is a proof-of-concept implementation (not compatible with the spec in > the draft yet, just to show that "It works™") that was used to perform an > eduroam login at a conference with an EAP-FIDO key. > > We will hold a side-meeting on Monday evening, 18:00 in Room Karlin 4, to > discuss some of the open design questions and to gather feedback on what else > may be needed in the specification. > > We have also requested a time slot at the emu session on Tuesday, to shortly > present the work. > > Any feedback is welcome. > > Cheers > Janfred > > [1]: https://datatracker.ietf.org/doc/draft-janfred-eap-fido/ > > -- > 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.de > > Vorstand: 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 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
