Project review: OTPOverRadius

[Nathaniel McCallum]

On Fri, 2012-12-14 at 16:56 -0500, Greg Hudson wrote:
> 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.

I don't like it either. However, following the no-config theme of this
proposal, how do we get a default by default? That is, the only
alternative seems to me that if a user doesn't set a default, than the
no-configuration option is broken.

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

I agree. I'm just worried about other clients out there (I'm not aware
of any, but that doesn't mean they don't exist). If we remove all the
fields (vendor, length, format, algorithm and id), we can just send a
single generic challenge. But as soon as we need one, the cost to add
the others isn't huge. If everyone is comfortable with this option, I am
too.

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

I like the idea of defaulting strip_realm=false in RoUS mode, but
strip_realm=true for standard UDP/IP mode. If this is not sane, then I
always prefer more information by default than less information by
default.

Nathaniel