Project review: OTPOverRadius

[Nathaniel McCallum]

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

Nathaniel