Re: [krbdev.mit.edu #9046] requires_hwauth can cause a preauth loop with PKINIT

On 1/19/22 10:07 PM, Ken Hornstein via krbdev wrote:
> This touches a larger issue that I've run into, in that the client-side
> preauth loop is ... kind of a mess.

Some of this is a natural product of having multiple authentication
mechanisms.  Lots of us probably have the experience of troubleshooting
ssh configurations by poring through ssh -v and sshd -d output, for
instance.

Some of this comes from using a plugin framework for preauthentication,
which other Kerberos implementations haven't done.  This framework has
paid off somewhat; it has allowed people (including Ken) to use an
alternative PKINIT implementation on the KDC, and is allowing Red Hat to
ship an OAuth2 mechanism.  But it also makes it harder to reason about
the user experience.

On the topic of fallback, I have some previous thoughts here:

https://mailman.mit.edu/pipermail/krbdev/2018-April/012914.html
https://krbdev.mit.edu/rt/Ticket/Display.html?id=8654 (see comments)

The summary is that while it's important to fall back if the client
can't generate an authenticated request (e.g. for partial PKINIT
deployments), once the client has sent an authenticated request it's a
tough decision and sometimes has a security impact.

The topic of preauth configuration came up last April:

https://mailman.mit.edu/pipermail/krbdev/2021-April/013448.html

where we sort of arrived at the idea of adding a client-side option to
force the use of a particular preauth mechanism (and display the error
if it fails).

On the KDC side, we have coarse properties which allow the right set of
preauth mechanisms to be offered in many circumstances, but no
comprehensive method.  PKINIT can be offered globally or not at all;
usually this isn't a problem since clients will just skip if it they
don't have a client cert.  Password-based mechs (encrypted timestamp,
SPAKE, etc.) can be turned off by removing the client's long-term keys,
but they can't be turned off individually and turning them off this way
precludes authentication via keytab.
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev