[16908] in Kerberos_V5_Development
Re: OTP, deployability.
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Jun 16 15:45:10 2011
MIME-Version: 1.0
In-Reply-To: <20110616181050.GG12572@mournblade.imrryr.org>
Date: Thu, 16 Jun 2011 14:45:04 -0500
Message-ID: <BANLkTim=QJo54C2O3FMxvku5U5mJN=sWjA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Roland C. Dowdeswell" <elric@imrryr.org>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Right, we need OTP tokens to be key-generating for this. But we want
that anyways, so we can use the OTPs as keys or as part of key
derivation.
PA-ENC-TIMESTAMP with password + OTP (and PIN, but since the PIN
becomes, effectively, a part of the password, it may not add very
much) would be hard to crack with an offline dictionary attack. The
password would contribute, say, some 32 bits of entropy to the
keyspace search, while the OTP would contribute some, say, 20 bits.
52 + a high enough PBKDF2 iteration count + frequent password changes
(every 90 days will probably do) would be plenty good enough for now.
Plus PA-ENC-TIMESTAMP could be used this way inside a FAST tunnel, in
which case the main value of doing this password + OTP thing is that
it is less disruptive than a new pre-auth type would be.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
