Jan-Frederik Rieckers <rieck...@dfn.de> wrote:
> 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.
I agree that we have problems.
> 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.
It seems to me that this can be solved, but I agree that it isn't solved yet.
So we probably need a configuration knob here.
One thing that I know a few people have talked about is having a standard
configuration format for clients.
> 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 ...."
I think this is something we should actually answer.
> 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.
+1
> But we don't have this in BYOD environments like education institutions.
And probably in fewer and fewer enterprises given BYOD.
As a goal, we need to migrate to more use of EAP-TLS in home environments.
RCM requires it in the end.
> 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?"
Yeah. It doesn't need to be so hard.
But, PSK is just not actually secure at home.
It's just that on-path attacks at your home are often not worth the effort.
> 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)
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
