On Oct 30, 2023, at 7:20 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> 
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.

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Reply via email to