Greg Hudson <ghud...@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 (ea...@eyrie.org) <https://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
