On 24.10.23 19:43, Michael Richardson wrote:
Alan DeKok <al...@deployingradius.com> 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.
I think I actually want to be vulnerable to this kind of attack.
- Wait, bear with me, I have a reason for saying that: -
Some of the operational problems that we currently have, especially in
the eduroam world:
Administrators don't fully understand the EAP methods, and they usually
don't have time to dig into that. They just want it to work.
And some don't understand that it is a big deal for the Client if the CA
changes, since it does not cause problems if they change the web server
certificate. And when they change it they quickly realize that it works
again if they choose "Do not validate" on their device, so they advise
that the users configure their devices this way.
With the suggested way to pin the PKI to the one used to provision the
credential I see several problems:
* How to store?
Since the credential is not necessarily used on the same device that the
FIDO credential was registered (example: YubiKeys that are registered by
the admin and then issued to the user), the information needs to be
stored in the registration information somehow. I'm not sure if that is
possible and/or manageable.
And another question remains: What exactly do I store? "I used WebPKI"
or "The trust anchor was the ISRG Root X1" or "My cert was issued by
Let'sEncrypt R3" or "the SHA256-FP of the CA cert that issued the server
cert was ...."
* How do I change the CA?
Certificates expire. This can be seen as bug, and therefore FIDO has an
advantage over using client certificates, since FIDO credentials don't
expire at an arbitrary point in time.
For the server side, the certificates also expire and they need to be
exchanged regularly.
Now the question is: What type of certificate do I use? Since some OSes
add the CA used for wifi to their OS-wide trust store, I don't want to
have a small institution with a part-time admin operating its own CA
with the CA's private key stored with chmod 777 on a dubiously secured
web server.
So using a private self-operated CA, where the validity time is
somewhere in the area of 100 years, is a bad idea.
The alternative: We use a certificate provider from the webPKI. But here
we have options and if the provider that was active at the time of FIDO
registration has now decided to increase their prices by factor 20, and
we want to move to a different CA provider, then we don't want to have
the factor "is this CA from the same root" to be a decision point that
narrows our options. But more importantly: The eduroam use case is only
a tiny thing that is a byproduct of the other PKI use cases (mainly
Web). So it is unlikely that the decision makers are willing to add a
zero to the amount of money they spend on PKI, just because we need this
for this one use case of WiFi login.
So now the admins need to have a certificate roll-over, and with BYOD
deployments that means: Endlessly chasing after users that have not yet
reconfigured their device, and some VIP users complaining why the WiFi
again does not work, because they never had such problems at their home
wifi.
So the intent is to completely get rid of CA pinning (at least by
default). It only causes problems, especially for admins that do not do
the admin task full-time, and there are a lot of those.
This is not to say that there aren't use cases out there where CA
pinning is useful and the spec should not forbid that possibility, but I
don't want to specify a protocol, where, 20 years from now, people say
"Why do we need an external configuration tool again to configure the
trust parameters?"
For MDM environments like company wifi, where you have your
well-maintained private CA and (more or less) complete control over your
end-devices, CA pinning is ok.
But we don't have this in BYOD environments like education institutions.
Because the cert parameters are not implicit from information that the
user is willing to configure (usually username and password), the
eduroam folks developed a tool that helps with the secure setup of the
Wifi. And having experienced the First-Level-Support, many people
complain about "Why is it so difficult to get on the wifi at the
university, can't you just give me the wifi password and everything
works like at home? What do I need this app for?"
So - to quickly summarize it and come back to the ComodoGate attack:
The possibility of a Rogue CA is always there.
For the webPKI, the CA/B forum mandates mechanisms to at least detect
such rogue behavior and the affected CA won't be in trust stores much
longer.
In my opinion, the danger of having a dubious private CA is much higher.
And pinning the CA in BYOD environments causes a lot of problems in the
future, that are likely to wander out of sight and only re-surface -- in
the best case a short time before, in the worst case at the time --
things break and now the admins need to act quickly. And this reaction
also involves the end-users, that need to reconfigure their devices and
that's never a good idea, because the latency of end-user action is
immense (esp. if they are not technically versed)
--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
--
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
