Project review: OTPOverRadius

[Dmitri Pal]

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?
www.redhat.com/carveoutcosts/