OTP, deployability.

Cornelius Kölbel cornelius.koelbel at lsexperts.de
Mon Jun 20 15:01:01 EDT 2011


Am 18.06.2011 17:39, schrieb 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
>
Hi Dmitri,
I am not sure, where the journey goes. Of course using FAST/OTP pre auth
would be the best designed solution. We were talking about this
internally a while ago.
As the community is not that big yet, you can talk to me. A collegue of
mine is more into the data/database design. I would like to help and
discuss ideas.

Kind regards
Cornelius
>> 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
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20110620/a3d92e36/attachment.bin


More information about the krbdev mailing list