FAST-OTP project proposal

[Sumit Bose]

On Mon, Mar 14, 2011 at 06:45:51PM -0400, Dmitri Pal wrote:
> On 03/12/2011 11:47 AM, Linus Nordberg wrote:
> > Hi,
> >
> > I'd like to implement FAST-OTP as described in
> > draft-ietf-krb-wg-otp-preauth, see attached proposal.
> >
> > In an attempt to make porting to Heimdal as painless as possible I'll
> > seek feedback from the Heimdal list too in a short while.
> >
> > Grateful for any input from you.  I should add that I haven't hacked on
> > any Kerberos implementation before.  No explanation or question is too
> > stupid for me so please bring them on.
> >
> 
> Hi Linus,
> 
> I am in the middle of setting up an Fedora project to do a pretty
> similar thing.
> It will be here: https://fedorahosted.org/AuthHub/
> I have not had a chance to customize it but it is the question of couple
> days.
> And we also have some rough prototype that works with Yubiko that we
> will publish as soon as we sort out access control issues to the project.

I have uploaded what we have so far to
http://git.fedorahosted.org/git/?p=AuthHub.git . You can find packages
for Fedora 14 at http://sbose.fedorapeople.org/otp-demo/ . Fell free to
join https://fedorahosted.org/mailman/listinfo/authhub-devel mailing
list to continue the discussion.

bye,
Sumit

> Hopefully we will get an RSA prototype going pretty soon.
> 
> We just needed a good place to put the code and a list to share the
> ideas and not spam Krbdev list at the same time.
> So I requested the project and just got it several hours ago.
> We just made our first baby steps.
> Sumit will publish the code at his earliest convenience.
> 
> On the RSA conference I have had a chance to work with different OTP
> vendors and get their interest around a joint venture like this.
> I think we are looking towards a very common set of goals.
> 
> Would you be interested to join forces and work together on this project?
> 
> A little bit more thoughts and specific details that I will put on the
> site as soon as I would be able to edit it:
> 1) We want to support not only OTP vendors by other authentication
> schemes that can be implemented over the OTP spec. If down the road it
> means to create a spec for a different plugin so be it. But we will
> start with this one and see how it goes.
> 2) Having a unified client side plugin that works for multiple vendors
> is a goal. It is a deployment nightmare if for each vendor you have to
> build and distribute client side plugin. It will be a big barrier for
> adoption. We think it should be embedded into the platform solution. We
> plan to have it as a part of SSSD which is already a part of several
> distributions.
> 3) On the server side the ultimate goal would be to allow different
> groups of people have different external authentication policies defined
> for them. Plugin framework allows different vendors to coexist but there
> is no solution around the policy data. This needs to be designed. There
> should be a common set of data that the KDC would be in charge of
> storing and passing back to the plugin. Based on this data the KDC
> itself or the plugin would select which external method needs to be
> used. More discussions are needed...
> 4) The external authentication would lead to potential delays in the
> processing. AFAIK the timeout is not easily configurable. The code
> changes would be needed to help with this. Also for scalability it would
> make sense to add acync processing to the KDC. We have some plans to
> dedicate resources to this effort.
> 5) The licensing might be one of the major barriers for the vendors. One
> of the ideas that we had and definitely need more thought and deign
> around is to have a generic plugin inside KDC that will dispatch the
> requests to the vendor provided demons running on the KDC. In this case
> there will be one plugin that will talk to several back end services
> that would actually implement the client API for specific vendor. That
> will keep the Kerberos code very clean and allow vendors to implement
> back ends at their own pace.
> 6) Implementing PIN support will probably be a requirement.
> 
> I think there is a lot in common.
> What do you think?
>  
> 
> 
> Thank you,
> Dmitri
> 
>   
> 
> >
> >
> >
> > _______________________________________________
> > krbdev mailing list             krbdev at mit.edu
> > https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 
> -- 
> Thank you,
> Dmitri Pal
> 
> Sr. Engineering Manager IPA project,
> Red Hat Inc.
> 
> 
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
> 
> 
>