Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Hannes Tschofenig <[e-mail]>]

Hi Jan,


you cannot complain about the use of TLS in EAP when the EAP method you
propose relies on TLS. The TLS-based authentication is an essential part
of the FIDO solution. Without TLS it is completely insecure.


Regarding the key extractor use you describe below: I don't remember
this technique being used by FIDO. I have worked in the FIDO Alliance in
the early days on U2F / UAF but might have missed some more recent
developments.


Regarding the benefit of FIDO: I don't think the "main benefit of using
FIDO is the ease of provisioning a credential to the supplicant". Once
you have an authenticated channel, it is trivial to provision new
credentials. There are hundreds of protocols that do that. IMHO the
benefit of FIDO is that you have an installed base of hardware tokens
that allow you to store these newly minted credentials.


On the security front I am wondering whether the introduction of this
use case weakens the use of FIDO for the web. In the web case, an
important aspect is to perform authentication and authorization of the
domain name with which the credentials are later utilized. For network
access authentication the domain authentication and authorization is, as
you have been mentioning in the draft and also in your emails, rather
weak. Have you looked into this aspect? Attacks that result from
cross-protocol use isn't uncommon.


Ciao

Hannes



Am 24.10.2023 um 12:22 schrieb Jan-Frederik Rieckers:
> On 24.10.23 10:58, [e-mail] 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
>
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu