Skip Menu |
 

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
KRB5_PREAUTH_FAILED.

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.
This scenario can also occur if the request enctypes list and the
client keys do not overlap, e.g.:

make testrealm
kadmin.local cpw -pw user -e aes256-cts user
kadmin.local modprinc +preauth user
in krb5.conf: [libdefaults] default_tkt_enctypes = aes128-cts
kinit user

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.