[16907] in Kerberos_V5_Development
Re: OTP, deployability.
daemon@ATHENA.MIT.EDU (Roland C. Dowdeswell)
Thu Jun 16 14:10:53 2011
Date: Thu, 16 Jun 2011 19:10:50 +0100
From: "Roland C. Dowdeswell" <elric@imrryr.org>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20110616181050.GG12572@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1308247243.2281.270.camel@t410>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
