Re: [Emu] New I-D: A new EAP method called EAP-FIDO
Alan DeKok wrote: > Not explicitly, but implicitly. > I think the way out here is to not mandate the use of WebPKI. Instead, > we can just say that the EAP certificate should be issues by the same > (or equivalent CA) to the one which was used to provision the initial > FIDO credentials. > In practice, this means WebPKI most of the time. :) Actually, that's a stronger statement anyway. It means that the choice of CA has essentially been pinned, so you'd not be vulnerable to attacks like ComonoGate. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
On Oct 24, 2023, at 11:11 AM, wrote: > That is an interesting idea, but it might be tricky for the supplicant to > validate because provisioning is performed through a browser? All the supplicant has to know is (a) the FIDO credentials, and (b) the CA certs used for FIDO. These are usually in the web CA store. That should just be calls to the relevant APIs. > Jan-Fred and I have previously discussed the option of provisioning the > supplicant (through the browser) with a credential for the server at the > time of initial PIDO provisioning. This was also looking tricky, but I think > the idea also has merit. Shades of TEAP! Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
> From: Alan DeKok > On Oct 24, 2023, at 8:56 AM, josh.howl...@gmail.com wrote: > > To be clear, what I mean is whether there is another IETF protocol that > > *mandates* the use of WebPKI? > > All of them. > > Not explicitly, but implicitly. > > I think the way out here is to not mandate the use of WebPKI. Instead, we > can just say that the EAP certificate should be issues by the same (or > equivalent CA) to the one which was used to provision the initial FIDO > credentials. That is an interesting idea, but it might be tricky for the supplicant to validate because provisioning is performed through a browser? Jan-Fred and I have previously discussed the option of provisioning the supplicant (through the browser) with a credential for the server at the time of initial PIDO provisioning. This was also looking tricky, but I think the idea also has merit. Josh ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
On Oct 24, 2023, at 8:56 AM, josh.howl...@gmail.com wrote: > To be clear, what I mean is whether there is another IETF protocol that > *mandates* the use of WebPKI? All of them. Not explicitly, but implicitly. I think the way out here is to not mandate the use of WebPKI. Instead, we can just say that the EAP certificate should be issues by the same (or equivalent CA) to the one which was used to provision the initial FIDO credentials. In practice, this means WebPKI most of the time. :) Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
On 24.10.23 14:56, josh.howl...@gmail.com wrote: To be clear, what I mean is whether there is another IETF protocol that *mandates* the use of WebPKI? I don't know of any, I'm interested in the definitive answer too. It definitely has a lot of implications to depend on external parties for security-relevant portions of the protocol. The sentiment for the protocol design was "we have to use WebPKI anyway for the registration and there is no other good option", but to actually publish an RFC with that dependency, the implications should be discussed. Cheers, Janfred -- 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 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
> > 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. > > So (2) would be the moral equivalent of (1) inside an existing tunnelled > method where WebPKI is mandated for server cert validation? > > I have worked with organisations who run AD Certificate Services for the sole > purpose of issuing a single server certificate for their NPS cluster, so I am very > much in favour of making server certificate validation simpler. > However, I think we need to be very circumspect about out-sourcing that to > the WebPKI. Is there another IETF protocol that does this? To be clear, what I mean is whether there is another IETF protocol that *mandates* the use of WebPKI? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
> 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. So (2) would be the moral equivalent of (1) inside an existing tunnelled method where WebPKI is mandated for server cert validation? I have worked with organisations who run AD Certificate Services for the sole purpose of issuing a single server certificate for their NPS cluster, so I am very much in favour of making server certificate validation simpler. However, I think we need to be very circumspect about out-sourcing that to the WebPKI. Is there another IETF protocol that does this? Josh ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
On Oct 24, 2023, at 6:22 AM, Jan-Frederik Rieckers 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
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
> > 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. > > > * 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? > > Definitely this could be done. Maybe I'm just too pessimistic here to > expect that UIs will get it wrong. Ok -- just checking my understanding was correct :) > > * 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. Most tunnel methods bind phases 1 and 2; I don't believe this should be a problem. > 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. What would be the goal for this? > > 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. When you say "default", would this permit other user-provisioned trust anchors as well? Josh ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
Ahah! Ok. I suggest a slight rename: FIDO's got tokens and Fido's got FDO, and the two are quite separate. EAP-FIDO-TOKEN? Eliot On 24.10.2023 12:24, Jan-Frederik Rieckers wrote: On 24.10.23 09:12, Eliot Lear wrote:> Thanks for the draft. Question: Is the intent that the FDO authentication happen each and every time, or just during ownership transfer? The intent is to do a FIDO authentication every time (maybe with the exception of TLS session resumption, Text for that is still TODO). But with CTAP v2 you can trigger silent authentication, so the user does not need to touch their FIDO token every time they need to re-authenticate, the token just needs to be available (which is more complex with hardware tokens like YubiKeys, but very easy with OS-backed FIDO implementations) Cheers, Janfred ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu OpenPGP_0x87B66B46D9D27A33.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
On 24.10.23 09:12, Eliot Lear wrote:> Thanks for the draft. Question: Is the intent that the FDO authentication happen each and every time, or just during ownership transfer? The intent is to do a FIDO authentication every time (maybe with the exception of TLS session resumption, Text for that is still TODO). But with CTAP v2 you can trigger silent authentication, so the user does not need to touch their FIDO token every time they need to re-authenticate, the token just needs to be available (which is more complex with hardware tokens like YubiKeys, but very easy with OS-backed FIDO implementations) Cheers, Janfred -- 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 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
On 24.10.23 10:58, josh.howl...@gmail.com wrote: 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. 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. The wording in the draft is a bit harsh, and I sincerely apologize to everyone that felt offended by that wording, that wasn't my intention. I'll adjust that for a future version of the draft. 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. But the moment you enter the BYOD world, users will get it wrong and there is no default way that is secure. Admins need to publish the information about CA and Server Name and need to rely on the user's ability to configure this correctly. And server operators have no way of verifying the configuration on client devices, unless they operate a rogue AP and log which users log in there, to give them a slap on the wrist. 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. 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. * 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? Definitely this could be done. Maybe I'm just too pessimistic here to expect that UIs will get it wrong. * 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. 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. 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. Janfred -- 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 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
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 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
Re: [Emu] New I-D: A new EAP method called EAP-FIDO
Hi Jan-Frederik Thanks for the draft. Question: Is the intent that the FDO authentication happen each and every time, or just during ownership transfer? Thanks, eliot On 24.10.2023 00:38, Jan-Frederik Rieckers 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/ ___ 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
