On Tue, May 10, 2022 at 4:54 PM Russ Allbery <ea...@eyrie.org> wrote:
> 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? > > But that prompt is a callback to the prompter routine in pam_krb5 passed in so I could bypass that prompt by just force feeding the "password" into the response structure right ? ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos