OTP, deployability.

[Cornelius Kölbel]

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.

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



-------------- 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/20110617/f7bf7b16/attachment.bin