Project review: OTPOverRadius

[Nathaniel McCallum]

On Fri, 2012-12-14 at 15:38 -0500, Nathaniel McCallum wrote:
> On Fri, 2012-12-14 at 14:47 -0500, Dmitri Pal wrote:
> > On 12/14/2012 11:21 AM, ghudson at MIT.EDU wrote:
> > > Here is a writeup of a project to implement KDC-side OTP support by
> > > delegating to a RADIUS server:
> > >
> > > http://k5wiki.kerberos.org/wiki/Projects/OTPOverRADIUS
> > >
> > > Comments are appreciated.
> > > _______________________________________________
> > > krbdev mailing list             krbdev at mit.edu
> > > https://mailman.mit.edu/mailman/listinfo/krbdev
> > >
> > >
> > Couple comments:
> > 
> > 1) This seems confusing
> > [otp]
> >  <name> = {
> >   vendor = <string>
> >   length = <integer>
> >   format = <enum: decimal|hexadecimal|alphanumeric|binary|base64>
> >   algorithm  = <string>
> >   server = <string>
> >   secret = <string>
> >   strip_realm = <boolean>
> >   attributes = <name_or_number>:<value>
> >  }
> >
> > Are a part of the token info. I suspect you are including it here to be able to use in the challenge to the client kerberos client. Does not make sense much to me frankly because this information would not be known from the external vendor. One would have to sync it. It just would not fly asking people to sync it. I think you mentioned that you want it for testing purposes but IMO even for testing purposes it does not make much sense. Why test something that no one would use?
> 
> You are mostly correct, but we need to support the OTP protocol for
> interoperability. They will only be added by the admin when they are
> needed for this purpose, and I think we should support them.

I need to add something here. In SSSD, we use length/format (if present)
to do client side verification of typos.