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

[Alan DeKok <[e-mail]>]

On Oct 30, 2023, at 7:20 AM, Hannes Tschofenig <[e-mail]> wrote:
> 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.

  I don't think that the proposal is to remove TLS, so we can put that concern to rest.

> 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.

  Unfortunately that hasn't been my experience.  We've had HTTPS and user authentication over the web for decades.  Yet that hasn't made it trivial to deploy credentials for EAP.

  It's almost 2024, and MDM is still difficult.  There are a large number of companies who are happy to charge recurring monthly fees, per user, for MDM solutions.  That's bad for everyone but them.

> 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.

  The benefit I see is that EAP-FIDO can require the use of web CAs for EAP.  That is largely the practice anyways.  But it's difficult to do, because of the previously mentioned difficulty with deploying credentials.

  Having pre-configured credentials means that EAP-FIDO is essentially just "use pre-configured web CAs with pre-configured FIDO credentials".  That requirement means that EAP-FIDO should be enormously easier to configure than previous TLS-based EAP methods.

> 
> 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.

  We can use the NAI realm here.

  i.e. for the web "I want to authenticate to example.com".

  For EAP. "I want to authenticate to @example.com"

  There is little practical difference between the two.  The main difference is things like DNS CAA records.  But those can be checked when the user is online (and FIDO is provisioned).  The resulting information can be cached for offline use with EAP.

  So EAP-FIDO involves taking pre-existing practices / credentials, and describing how supplicant authors can implement the protocol.  The end user configuration is then little more than "use FIDO on SSID X, with credentials for domain Y".

  That is simple enough that the end user can configure it manually.  And critically, cannot configure it *incorrectly*.  It's either secure and it works, or it's insecure and it doesn't work.

  We've had ~20+ years of relying on end users to carry the burden of supplicant configuration.  That practice is a failure, and should be replaced with something better,

  Alan DeKok.