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.