[39093] in Kerberos
Re: Always prompting for OTP
daemon@ATHENA.MIT.EDU (BuzzSaw Code)
Tue May 10 15:01:32 2022
MIME-Version: 1.0
In-Reply-To: <87pmklql3g.fsf@hope.eyrie.org>
From: BuzzSaw Code <buzzsaw.code@gmail.com>
Date: Tue, 10 May 2022 14:57:53 -0400
Message-ID: <CAJhaRZ+06Z5HQ1YBv_-7qLv83i=o8xT3KeWYqVDjTuF1KUPRzg@mail.gmail.com>
To: Russ Allbery <eagle@eyrie.org>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Tue, May 10, 2022 at 2:49 PM Russ Allbery <eagle@eyrie.org> wrote:
> BuzzSaw Code <buzzsaw.code@gmail.com> writes:
>
> > We want the full OTP+password string just passed without modification.
>
> Ah, okay, so then in theory the problem could be solved entirely within
> the Kerberos libraries, although I haven't wrapped my mind around the
> problem Greg identified.
>
Same - I started walking through the code but haven't tracked down the
point where it tosses the original creds.
>
> > It would also be nice if when we use
> > try_first_pass/use_first_pass/force_first_pass options with pam_krb5
> > that it actually did that in the OTP case without the extra prompt.
> > no_prompt doesn't help as the password doesn't stay on the stack.
>
> I'm assuming this is because the Kerberos library doesn't think that the
> passed-in password can be sent after the FAST negotiation and therefore
> re-prompts internally? I'm not sure I entirely understand the logic flow
> here.
Me either - haven't been able to fullyl grasp the flow.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
