OTP, deployability.

[Henry B. Hotz]

On Jun 16, 2011, at 11:00 AM, krbdev-request at mit.edu wrote:

> Date: Thu, 16 Jun 2011 14:00:43 -0400
> From: Greg Hudson <ghudson at MIT.EDU>
> Subject: Re: OTP, deployability.
> To: "Roland C. Dowdeswell" <elric at imrryr.org>
> Cc: "krbdev at mit.edu" <krbdev at mit.edu>
> Message-ID: <1308247243.2281.270.camel at t410>
> Content-Type: text/plain; charset="UTF-8"
> 
> 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.

The way RSA does it is to try the current-time value, the previous, and the next values.

I doubt that RSA will ever provide a public API to export those values on the server side.  They might provide an API to get some hash value(s) which depend(s) on the token value, if the hash were defined in a standard which had a significant market.  I really don't know, but I believe that is the intended approach for the RSA/Cybersafe collaboration.

I do wonder how that work is weathering their current problems.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu