[16910] in Kerberos_V5_Development
Re: OTP, deployability.
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Jun 16 16:14:10 2011
MIME-Version: 1.0
In-Reply-To: <20110616173538.GF12572@mournblade.imrryr.org>
Date: Thu, 16 Jun 2011 15:13:59 -0500
Message-ID: <BANLkTi=wxfxTZR2oe=SaDK_wzYw-uKQPSA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Roland C. Dowdeswell" <elric@imrryr.org>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, Jun 16, 2011 at 12:35 PM, Roland C. Dowdeswell <elric@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 thatthe OTP server can either output the currently-valid OTP values to theKDC, or it can validate the PA-ENC-TIMESTAMP for the KDC and give itthe 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 thoughthey use PAM. Upgrading them is a slow process, because it always is. The internal apps problem is worse. The LDAP w/ SIMPLE/PLAIN authproblem might be possible to handle if either you could specia-case itso it uses just a password and no OTP, or if the server-side krb5client 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 whichaltogether 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--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
