Project review: OTPOverRadius

Dmitri Pal dpal at
Fri Dec 14 21:45:21 EST 2012

On 12/14/2012 06:22 PM, Greg Hudson wrote:
> On 12/14/2012 05:33 PM, Dmitri Pal wrote:
>> So if this is not an option are you saying that it is the responsibility
>> of the client to split user input and stick it into two different parts
>> of the reply OTP + password preauth mechanisms (sorry if I use the
>> incorrect terminology) so that the server then would not have to
>> calculate hashes?
> Yes, to use the Kerberos long-term key for preauth, the client pretty
> much has to be the party which computes it from the password, which
> means the client has to know what part of the user input is the password.
>> But this is the functionality that server does not currently support
>> AFAIU. This is so called "sets" that we talked about earlier. I was
>> hoping to avoid the need for sets if we can split the user input on the
>> server.
> I don't see that as a good workaround.  In addition to placing the
> expensive computation burden on the KDC, you also don't get mutual auth
> to the user like you do in the usual Kerberos long-term key
> architecture, and you increase the risk of phishing-type attacks by
> transmitting the password.  Both of these concerns are mitigated by the
> FAST tunnel (which authenticates the KDC to the host), though.
Isn't FAST tunnel a requirement for OTP preauth method?

>> What are out options here? If we are going to split user input and
>> calculate hashes in the RADIUS server located on the same host we will
>> face the same computation problem just not inside KDC. Or you invisioned
>> that PIN to the token is not the password or something else? But then
>> how it is stored and matched?
> I only see these options for two-factor auth:
> * Use PINs with hashes (not string-to-key results) stored in the OTP
> server.  Do not use KDB long-term keys.

We can potentially store another hash of the password, not only the
kerberos one. I think we already have the LDAP password hash in case of
IPA. We can just match that one.
> * Implement preauth sets, and combine encrypted challenge with FAST OTP.
>  (This combination would unfortunately replace the reply key
> unnecessarily and lose some security properties as a result, but I don't
> think it would be a showstopper.)
I would prefer to avoid that.


Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

Looking to carve out IT costs?

More information about the krbdev mailing list