Always prompting for OTP

BuzzSaw Code buzzsaw.code at gmail.com
Tue May 10 16:58:17 EDT 2022


On Tue, May 10, 2022 at 4:54 PM Russ Allbery <eagle at eyrie.org> wrote:

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


More information about the Kerberos mailing list