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 preauth and the anonymous FAST conversation is done no matter what.
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 implications.
that might be reasonable to implement as an option.
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.
We want the full OTP+password string just passed without modification.
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.
BuzzSaw Code <buzzsaw.code@gmail.com> 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 here? For the full OTP+password string to be carried over to other modules in the stack, or only the password?
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.
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.
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'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.
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.
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 ?
Greg Hudson <ghudson@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?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 219:16:28 |
Calls: | 6,621 |
Calls today: | 3 |
Files: | 12,171 |
Messages: | 5,317,854 |