Hi Jan-Fred, 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. 2. I am not persuaded by the two arguments given in section 6.3 for not reusing existing tunnelled methods. * 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? * 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 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. Josh > -----Original Message----- > From: Emu <emu-boun...@ietf.org> On Behalf Of Jan-Frederik Rieckers > Sent: Monday, October 23, 2023 11:38 PM > To: emu@ietf.org > Subject: [Emu] New I-D: A new EAP method called EAP-FIDO > > 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
