OTP, deployability.

[Dmitri Pal]

On 06/18/2011 07:13 AM, Cornelius Kölbel wrote:
>
> Am 17.06.2011 22:45, schrieb Dmitri Pal:
>> I would agree with you in general but we live in the world where there
>> is no open source OTP server yet that can be capable of what you ask. At
>> least I could not find one ready enough.
>> There are a lot of proprietary vendors though. We can't ask or force
>> them to do what they do not have incentives to do.
>>
>> So what are our options?
>>
>> 1) Create a standard for the exchange so that vendors can implement the
>> interface. Paves a way but does not add a lot of incentive.
>> 2) Develop and OTP server using open standards (HOTP/TOTP) that would be
>> integrated with KDC.
>>
>> Both options go to the same goal and IMO can be executed in parallel. I
>> suspect the first one would take more time than the second.
>> I am all for the second one though. We plan to invest into it when we
>> are done with the framework covered in Authentication Hub project.
>> We looked at the following code base as something to start with
>> http://code.google.com/p/otpd/
>> But even with the existing code base it is a many man/month project.
>>
>> Would be nice to be able to work out the architecture of such server if
>> it is embedded into KDC and uses same data store to store tokens.
>> The scope of work would be:
>> 0) Work out the high level architecture
>> 1) Define the data model
>> 2) Implement the library to read the token XML file (RFC6030)
>> 3) Define interface to manipulate token data (import; read during auth;
>> save things like last used interval or count, drift/offset, number of
>> failures etc.)
>> 4) Think about replication issues and especially attacks that try to
>> play same code against different KDCs. Might require some sort of fast
>> replication/locking mechanism between servers.
>> 5) Implement the OTP processing as plugin to the KDC (assumes that the
>> plugin framework is ready becuase you really want to have async
>> processing in place first)
>>
>> May be more... I have not dived into a lot of details of such
>> evaluation, just did a rough assessment. But if anyone wants to help and
>> speed it up - sure!
>>
>>  
> Hi Dmitri,
> <advertisement>
> did you ever take a look at LinOTP, which is an opensource otp server,
> which has HOTP support, which will have TOTP support in the upcoming
> release and will import files according to RFC6030?
> It is modular enough to get user information form whatever user store
> you wish to.
> Well, the token information is stored in "some" sql database.
> Plus: It is capable of supporting other kind of tokens.
> </advertisement>
>
Cornelius,

I scanned it briefly in the past. As an external server - sure it is
interesting and we would love to make sure that Authentication Hub
solution works with LinOTP.
If you can point to someone from the LinOTP community that we can work
with on the integration and testing we are all for it.

But if we are talking about really embedded solution then it should be
written in C and be a plugin into the KDC itself.
Do not take me wrong that it must be an embedded solution written in C.
Authentication Hub design assumes that all the pluggable OTP servers are
external but it also assumes that FAST with OTP pre auth is used based
on the http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-17. If
we want to have a plugin that would use non FAST it has to be directly
plugged into the KDC or the OTP server should expose the "future OTPs
list" interface. It seems easier to have one written in C like OTPD to
turn into such plugin. But I am not sure. We have not dived into the
details yet. We have a lot to accomplish before so we have some time to
think about it. We are just starting and this thread is very helpful.
We are open to ideas and suggestions.

Thank you
Dmitri

> I personally still think, that it would be much nicer to make the OTP
> server pluggable. Maybe it would be possible to not transfer OTP data to
> the KDC but rather pass some KDC tasks to the OTP server?

Or make OTP server access same datastore as KDC via the same KDB
interface or if it is an LDAP back end (as in our case) then probably
just directly...

> Kind regards
> Corneilus
>
>
>
>
> _______________________________________________
> 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/