[2270] in Kerberos
Clarifying preauthentication
daemon@ATHENA.MIT.EDU (John Linn. LKG1-2/A19. {(508)-486 )
Thu Oct 8 12:40:46 1992
Date: Thu, 8 Oct 92 11:45:10 EDT
From: John Linn. LKG1-2/A19. {(508)-486 or DTN 226}-7384. 08-Oct-1992 1147 <linn@albeit.enet.dec.com>
To: kerberos@Athena.MIT.EDU
Cc: linn@albeit.enet.dec.com
Apparently-To: kerberos@athena.mit.edu
Ted Ts'o said in announcing Kerberos 5 Beta 2: "This version also
supports preauthentication, so that the KDC can pre-validate a AS request
before it sends you its response containing the encrypted ticket. This
prevents off-line password attacks which are otherwise possible. Each
principal has an flag indicating whether or not preauthentication is required;
you may choose to set that flag for all your users."
As I understand the scheme, it doesn't directly prevent off-line password
attacks. Rather, its real value (and it is real value) is indirect, making it
harder for an attacker to actively acquire the necessary basis against which to
attempt such attacks. Leaving the hand-held authenticator support hooks aside,
the approach takes a timestamp, encrypts it under the client's key, and
encloses the result in a KRB_AS_REQ message's pa_data. The KDC returns a
KRB_AS_REP with a TGT if and only if the decrypted timestamp is correct, given
some allowance for clock skew. This means that it's no longer possible for
someone lacking the proper key to get a corresponding KRB_AS_REP and
incorporated TGT from the KDC "just for the asking".
If an attacker somehow manages to intercept the KRB_AS_REP which is returned in
response to a valid KRB_AS_REQ, however, it still appears possible for the
attacker to run off-line tests of that KRB_AS_REP (the content of which hasn't
been changed by the advent of preauthentication) against a password dictionary
to find the ill-chosen client key which might have encrypted it. Am I missing
something here?
--jl
