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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
