Project review: OTPOverRadius

[Dmitri Pal]

>> If user password is actually the PIN we need to split it. It should be
>> possible to send the code to radius server and validate the password
>> inside KDC from the initial implementation.
>> Is it not possible? I assume it should be possible to extrac tthe
>> password and pass to the KDB to do do the matching.
> It wouldn't be a good idea.
>
> The KDB doesn't keep a simple hash of the user's password; it keeps a
> set of keys derived from the user's password through an operation called
> string-to-key.  For AES, the string-to-key operation is deliberately
> slow, requiring 4096 iterations of SHA-1.  If the KDC had to to do this
> operation on every preauth attempt, it would perform very poorly and be
> easily DOS'd.


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?
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.

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?

>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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