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