OTP, deployability.

[Dmitri Pal]

On 06/17/2011 02:46 AM, Cornelius Kölbel wrote:
> Am 16.06.2011 20:10, schrieb Roland C. Dowdeswell:
>> On Thu, Jun 16, 2011 at 02:00:43PM -0400, Greg Hudson wrote:
>>> On Thu, 2011-06-16 at 13:35 -0400, Roland C. Dowdeswell wrote:
>>>> If one has a large deployed Kerberos infrastructure, it would be
>>>> much easier to deploy it if it did not involve the addition of
>>>> pre-authentication mechanisms but rather was able to work with
>>>> PA-ENC-TIMESTAMP using a single password prompt.
>>> PA-ENC-TIMESTAMP doesn't deliver the password to the KDC; it encrypts
>>> the client's current time in the password.  Is your proposed design that
>>> the KDC just tries decrypting the token in every acceptable OTP value
>>> (or password + OTP value where applicable) and see if one works?  I
>>> don't know if commercial OTP APIs allow the KDC to construct a list of
>>> acceptable OTP values.
>> Yes, that's my proposal.  I do not think that APIs allow the KDC
>> to obtain a list of acceptable tokens for many of the commercial
>> products but at least in the case where there is an open specification
>> this would be straight--forward to program.
>>
>> It might be worthwhile to ask commercial OTP vendors to consider
>> adding the appropriate APIs to enable the KDC to do this.  There
>> might be interest.
>>
>> --
>>     Roland Dowdeswell                      http://Imrryr.ORG/~elric/
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
> Hi there,
>
> a similar problem arises, when you want to do RADIUS with mschapv2.
> We provide an OTP solution called LinOTP and we are just about adding
> such a functionality: Of course it sounds really evil to ask the otp
> server for the users or the tokens valid OTP values, but as said there
> are several scenarios, where this can be handy.
> Besides mschapv2 and kerberos it could also be an offline scenario,
> where the end device would like to take some OTP values on the journey.

Yes.

> There are time based and event based otp algorithms. In case of time
> based otp algorithms this can be rather easy. The otp server knows the
> time drift of the otp token and can respond to the KDC with the real
> current password+otp_value combination.
> As far as event based otp algorithms (like the HMAC-OTP, OATH) it is a
> bit more tricky, because of the synchronization. As the user might have
> pressed the button on the otp token more than once without having
> authenticated, the user might use the otp value with the counter #115
> while the otp server still thinks that the counter would be #100.
> Thus the otp server needs to provide a list of the next valid otp_values
> to the KDC and the KDC would have to verify if one of these values in
> this list will lead to a successful authentication. (I don't know all
> the kerberos side effects)
> As the KDC does not know, if the user will authenticate with a time
> based or and event based OTP token, the KDC will always expect a list of
> (password+otp_value)s. And even in case of time based otp it might also
> make sense for the otp backend to provide about 2 values to  cope with a
> potential time drift of the time otp token.
> Finally there needs to be some response to the otp backend, since the
> information, which OTP value succeeded in authenticating the user needs
> to be passed to the otp server, so that the counter (or time drift) can
> be synchronized/updated.
>
> Anyway, since most parts of our solution are AGPLv3 I would really like
> to have it working with MIT kerberos.
> But I think the most sensible way would be to implement some API on
> kerberos side, to be able to plugin modules for several different otp
> backends.
>
> Such a module should provide a function like:
>
>    get_otp_list( user )
>    return:
>             { tokenid1 : [ otp1a, otp2a, otp3a, otp4a .... ],
>                tokenid2:  [ otp2b, otp2b ] }
>
> As a user might have more than one otp token! and the KDC does not know,
> which token the user uses, the module should return values for all
> tokens owned by the user.
>
> Then the KDC should return the information on either success or failure:
>
>   set_otp_success( tokenidX, otpYz )
>
> with the input data, which token succeeded to authenticate and with
> which OTP value.
>
> ...just my very fist ideas! ;-)
>
> Kind regards
> Cornelius
>
>

Providing a list of the valid OTPs to an external client would never be
implemented by any vendor.
We have talked about this at length when I was a part of one of such
vendors.
Exposing valid future OTPs to a remote party is very dangerous.
How you are going to protect it?
With what? Password, cert? Static key?
This can be confined to a specific use case (potentially) but it is too
costly and too risky to implement such interface.

Here the only thing we can do is evolve Kerberos and related standards.

The only solution that seems to make sense is the embedded HOTP/TOTP
server on top of kerberos KDC.
This is the next step in our plan after we do the changes we are working
on in the authentiaction hub project.
Please see the plan and diagrams:
https://fedorahosted.org/AuthHub/wiki/ProjectGoals
https://fedorahosted.org/AuthHub/wiki/ArchitectureDiagrams

As soon as the pluggable framework is ready one of the things that we
would be able to do is create a back end that would have access to the
Kerberos data storage as well as token info and would be able to handle
to generate the codes and match the hashes internally. It is not clear
whether it would be needed though as we base the code on the
implementation of the OTP preauth draft. Potentially we would be able to
handle the case when the FAST is not used but that would require more
policies around what to assume about the authentication token that
client sent. 

But we are not there yet...
Help is welcome though.


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