Re: Always prompting for OTP

BuzzSaw Code <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.general
Message-ID <CAJhaRZJYY9X_090X7job_gh-R4bcXqgRhTzAEMgkcxYROfM0tA@mail.gmail.com>
On Tue, May 10, 2022 at 4:54 PM Russ Allbery <[email protected]> wrote:

> Greg Hudson <[email protected]> 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           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.