Subject: KDC can emit PREAUTH_REQUIRED error with useless hint list
Right now if you set +requires_hwauth on a principal without setting up
securid-sam2, the KDC will generate a PREAUTH_REQUIRED error with
preauth types 133 and 136 ("here's a cookie" and "I support FAST").
Older MIT krb5 clients will react to that by retransmitting the request
until the loop count is exceeded; newer clients will notice that they
could not generate any real preauthentication and fail with
The KDC should notice that it failed to propose any real preauth mechs
and should return a failure rather than a preauth-required error.
There's a lot of latitude for producing better or worse error codes in
different scenarios, but almost anything would be better than "please
preauthenticate with one of the following 0 mechanisms:".
Right now this is a marginal concern because the hwauth bit is rarely
used outside of MIT itself, and we don't yet have an admin-facing way to
disable encrypted timestamp/challenge for a principal. The problem will
get worse if we implement a way to have principals with no long-term
keys or actual per-principal preauth configuration.
Download (untitled) 1k
This scenario can also occur if the request enctypes list and the
client keys do not overlap, e.g.:
kadmin.local cpw -pw user -e aes256-cts user
kadmin.local modprinc +preauth user
in krb5.conf: [libdefaults] default_tkt_enctypes = aes128-cts
We tolerate the lack of a client key in case we can use PKINIT or OTP,
but when we can't offer one of those we offer the same meaningless
133/136 hint list as in the +hwauth case.
Download (untitled) 463b