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, 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
_______________________________________________
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
