Project review: OTPOverRadius

[Dmitri Pal]

On 12/14/2012 10:08 PM, Nathaniel McCallum wrote:
> On Fri, 2012-12-14 at 21:45 -0500, Dmitri Pal wrote:
>> 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?
> Yes
>
>>>> 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.
> I'm not sure I understand the desire to have the KDC check the PIN. What
> advantage does it have versus sending the PIN/token to the RADIUS server
> which can validate both? Particularly in the LDAP case, the RADIUS
> server will already have a connection to LDAP, so the hashing is much
> easier there...

The desire is based on the wrong assumption that it is easy to hash a
pin and match to the Kerberos hash.
It is not a requirement. What you described above would work too. Just
was not that obvious that it is the only simple solution.


>
> Nathaniel
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/