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