On Oct 24, 2023, at 6:22 AM, Jan-Frederik Rieckers <rieck...@dfn.de> wrote: > 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.
Configuring CAs is hard. Configuring a CA for each application is harder. Starting up a new public CA just for one protocol is impossible. The reality is that outside of private CAs, the phrase "CA" is equivalent to "web CA". The web CA certificates are used for pretty much every protocol: SMTP, XMPP, Jabber, etc. We might as well use them for EAP, too. > 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. We can say that the default is to use web CAs. But nothing prevents one particular site from using a private CA for its domain. Both uses should be explained and permitted. > 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. Agreed. The solution here is to require secure behavior through better protocol design. >> 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. I think defining a new TLS-based method is needed. For the simple reason that we need to require that the default CAs for this method are the web CAs. We can't add that requirement to TTLS / PEAP. >> * 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. This is already done for TTLS: https://datatracker.ietf.org/doc/html/rfc5281#section-11.2.2 A "tunnelled FIDO" method could define something similar for the FIDO challenges. The tunnelled FIDO method would still need to define how the server certificate was validated, and strongly tie the server identity to the FIDO process. But that's just text to be added to a TTLS / PEAP section. > 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. That can be done. For similar calculations, see TEAP. It isn't trivial, but it's possible. https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-14#name-intermediate-compound-key-d I think this binding is simpler to do for a new TLS-based EAP-FIDO. It's more difficult to do for TTLS, and I suspect it's not needed. >> 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. Exactly. So I see this as two new methods: 1) tunnelled FIDO - for use in TTLS, PEAP, or other TLS-based EAP methods. 2) TLS-based method with tunnelled FIDO - it can make new / stronger requirements on CA validation, server identity, etc. We could just ban the use of tunnelled FIDO in TTLS / PEAP. But I'm not sure that's practical. It's likely safer to just define TTLS + tunnelled FIDO. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
