Project review: OTPOverRadius
dpal at redhat.com
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
> 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.
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
More information about the krbdev