Project review: OTPOverRadius

[Greg Hudson]

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.

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

* 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.)