FAST-OTP project proposal

[Dmitri Pal]

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