Always prompting for OTP

[Russ Allbery]

Greg Hudson <ghudson at mit.edu> writes:

> The FAST negotiation is irrelevant, except insofar as it makes the
> design of FAST OTP possible.  Client preauth modules implementing OTP
> mechanisms simply don't consider the Kerberos password to be the same as
> an OTP value, so they ask for the OTP value via the responder or
> prompter.

Oh, I think this was the bit that I was missing.  I was for some reason
assuming that the Kerberos library itself understood that part of the
thing passed in as a "password" was actually an OTP value and the other
part was a password, but it sounds like I was wrong to think this, and
instead the entire "password" is sent via RADIUS and it's the RADIUS
server that takes it apart into an OTP value and an actual password?

And therefore, because of that, the Kerberos library declines to send a
password passed in as an argument to krb5_get_init_creds_password to the
RADIUS server, and always forces a separate prompt, because it is really
designed for the case where the password and OTP are separate and entered
separately at two different prompts, the second (for the OTP) triggered by
the preauth mechanism?

If I have this right, it feels like the root problem is the combined
password mechanism that overloads the password field to carry unrelated
additional information, but unfortunately that may be forced by the number
of protocols that are entirely unable to deal with additional PAM prompts.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>