Project review: OTPOverRadius

[Greg Hudson]

I forgot to call out one thing in the project page:

> However, if one or more valid token types are defined in the
> configuration, the first valid configuration defined will be considered
> the default token type.

I don't think order of subsections has ever been important in the krb5
profile, and it's slightly awkward to get at via the libprofile
interface.  But it does seem convenient in this context, so I'm willing
to let it slide.  I'm raising it now in case anyone else thinks it's a
problem.

Nathaniel wrote:
>> You are mostly correct, but we need to support the OTP protocol for
>> interoperability.

Being interoperable doesn't necessarily mean implementing everything in
a spec.  We want to (a) conform to the spec, and (b) implement enough to
interop with other known implementations (of which I don't think there
are any).  But if we think an optional field won't be useful in
practice, it's okay to leave it out of the initial implementation, as
long as it would be easy to add later.

On 12/14/2012 04:20 PM, Dmitri Pal wrote:
> Strip_realm should be yes by default.

One of the goals (which ought to be stated explicitly on the project
page) is that with zero configuration apart from setting
+requires_hwauth on principals, the KDC will authenticate via a
co-hosted RADIUS-over-Unix-domain-sockets proxy.  This won't work, at
least for more than one realm, if the realm is stripped by default.

I agree that strip_realm would probably be set more often than not when
authenticating directly to a RADIUS server containing the vendor's OTP
implementation.  That seems unfortunate.  Perhaps strip_realm=false
should only be the default for the zero-configuration token type.

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