OTP, deployability.

Nico Williams nico at cryptonector.com
Thu Jun 16 16:13:59 EDT 2011


On Thu, Jun 16, 2011 at 12:35 PM, Roland C. Dowdeswell <elric at imrryr.org> 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.  This is certainly
> not possible for all OTP mechanisms, e.g. if there is a challenge
> response, well, obviously you must deliver the challenge in some
> fashion.  But for event-based or time-based OTP systems where there
> is no challenge, it should be possible to deploy them by simply
> modifying the KDC and user behaviour but not the client libraries.

This requires tokens that are a) key-generating (by which I mean that
the OTP server can either output the currently-valid OTP values to the
KDC, or it can validate the PA-ENC-TIMESTAMP for the KDC and give it
the reply key), b) not challenge/response type tokens.

This is perfectly fine with me.  I would very much like to see support for this.

> The reasons that you might like to be able to do this are many but
> the most important ones that spring to mind are:

Indeed.  Some old systems can't handle arbitrary prompt even though
they use PAM.  Upgrading them is a slow process, because it always is.
 The internal apps problem is worse.  The LDAP w/ SIMPLE/PLAIN auth
problem might be possible to handle if either you could specia-case it
so it uses just a password and no OTP, or if the server-side krb5
client knew where to split the password + OTP into password and OTP
(and PIN).

In any case, the problem is that there's too many of these problems,
each of which might be tractable in one or two years, but which
altogether form a problem that is intractable.

> These sorts of issues could take years to resolve at a large company.

Yes.

> None of what I am saying should be interpreted to mean that I think
> that new preauth mechanisms shouldn't be developed, but rather, I
> think that it would be quite useful to a number of environments if
> there were an option or two to deploy OTP without changing the
> current AS_REQ exchanges---especially in the short term---because
> rolling out new pre-auth mechanisms might take many years at many
> established institutions.

+1.

Nico
--




More information about the krbdev mailing list