Always prompting for OTP

[Greg Hudson]

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 to explain again.

The Kerberos protocol was designed to be somewhat resistant to phishing.
 If I set up a rogue KDC and somehow convince clients to authenticate,
the clients do not simply send me their passwords.  This resistance
isn't perfect; by asking for encrypted timestamp I can probably get the
client to send a ciphertext that I can use to conduct an offline attack,
and I can probably influence the client to use a fast string-to-key
function by pretending to only support an older encryption type.  But
it's still a goal.

FAST OTP does not have any phishing resistance, at least in the mode
that is used in practice.  Whatever the user types in as the OTP value
is simply sent to the KDC to be inspected raw.  On the positive side,
FAST OTP can only work over FAST, and one can presume that the FAST
armor key was obtained in a way that authenticates the KDC to the
client.  So it's not as easy to receive client authentications as a
rogue KDC as it would be in the original protocol.  But depending on the
scenario it might still be possible.  pam_krb5 has some idea of the
authentication scenario (it's a system login of some kind), but libkrb5
does not.

If an OTP client preauth module used the password as the OTP value, that
would make it easier for a KDC to completely subvert the phishing
resistance of the original Kerberos protocol.  Again, prompting
separately isn't a perfect solution as users confronted with an "Enter
OTP Token Value" prompt are as likely as not to simply re-enter the
password.  But it would still be worrisome.

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