BuzzSaw Code writes:
> 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 ?
Yes, you can intercept it inside pam_krb5. It's really ugly from a
pam-krb5 architecture
On Tue, May 10, 2022 at 4:54 PM Russ Allbery wrote:
> Greg Hudson 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 a
Greg Hudson 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 respond
On 5/10/22 14:49, Russ Allbery wrote:
>> 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.
I will try
On Tue, May 10, 2022 at 2:49 PM Russ Allbery wrote:
> BuzzSaw Code 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
BuzzSaw Code 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.
> It would also be nice if when we
On Tue, May 10, 2022 at 2:05 PM Russ Allbery wrote:
> BuzzSaw Code writes:
>
> > A bad side effect of this behavior is that the calling PAM module never
> > gets that OTP value so it isn't available for other modules in the
> > stack, so they too prompt for credentials because they think the
> >
BuzzSaw Code writes:
> A bad side effect of this behavior is that the calling PAM module never
> gets that OTP value so it isn't available for other modules in the
> stack, so they too prompt for credentials because they think the
> password has not been entered yet.
What behavior do you expect
>
>
> This is by design. The basic Kerberos protocol does not reveal the
> password to the KDC, but FAST OTP does reveal the OTP value (encrypted
> within the FAST channel). So for libkrb5 to transparently send the
> password to the KDC when the KDC asks for FAST OTP would have security
> implica
On 5/10/22 11:47, BuzzSaw Code wrote:
> I'm trying to understand if the behavior I'm seeing is by design or a bug.
[...]
> It seems like the original credentials that were passed in, which is the
> valid OTP "pin+password", are tossed by the krb5 library routines once the
> KDC responds asking for
I'm trying to understand if the behavior I'm seeing is by design or a bug.
Using the 1.19.3 release along with Russ Allbery's pam_krb5, no matter what
options are set for pam_krb5, when using one of our accounts setup for
RadiusOverOTP, the krb5 library prompter asks for the OTP token.
Tracing t
11 matches
Mail list logo
