[3662] in Kerberos
S/KEY integrated with Kerberos?
daemon@ATHENA.MIT.EDU (Clifford Neuman)
Mon Aug 8 10:57:40 1994
Date: Mon, 8 Aug 1994 07:46:14 -0700
From: Clifford Neuman <bcn@ISI.EDU>
To: hendrick@ctron.com
Cc: tls@panix.com, tytso@MIT.EDU, kerberos@MIT.EDU
In-Reply-To: "James R. Hendrick"'s message of Mon, 8 Aug 1994 10:16:27 -0400 <199408081416.KAA00610@marlins.ctron.com>
Date: Mon, 8 Aug 1994 10:16:27 -0400
From: "James R. Hendrick" <hendrick@ctron.com>
I have also spent a few minutes thinking about the issues of having the KDC
hand out TGTs using an S/Key password. Here are a few of the thoughts
that have fallen out of my head on the subject:
+ Making the KDC recognize skeys is not very difficult. It simply
needs to keep track of the initial skey password and a sequence number
and return a TGT encrypted with the proper sequence key. This is
basically what it does now for normal passwords.
Not quite. The KDC can not derive on its own the passphrase to be
used. Instead, the passphrase typed by the user can be verified, but
must be received by the KDC from the user in a form that can be
recovered. Public key cryptography is needed to send the passphrase
to the KDC in a recoverable form without requesting any other "secret"
information from the user.
Note that if you combine S/Key, with the normal Kerberos password
using conventional cryptography, you still have problems. The attack
one is trying to prevent is one where the attacker has managed to
obtain secret information (the password) by modifying kinit on some
system the user has used in the past (or otherwise watched the user
type). At the time the user ran kinit, the secret information was
disclosed (and perhaps also the S/Key phrase, but since the S/Key
phrase changes it isn't very useful beyond the current session).
The response from the KDC to the client would have to be encrypted
using the passphrase, since to return it encrypted only in the user's
password would make it available to the attacker that is assumed to
already know the password. But, if the passphrase was sent to the KDC
encrypted in the password, the attacker would be able to decrypt it,
recover the passphrase, and use it to decrypt the response, obtaining
tickets for the user.
That is why you have to use public key cryptography to integrate S/Key
with Kerberos. The passphrase would be sent to the KDC in a
pre-authentication data field, encrypted using the public key of the
KDC. The KDC would extract the passphrase, verify it, update the
database, generate a DES key from the passphrase, and use it to
encrypt the response with Kerberos tickets.
You might also want to combine this with proof of knowledge of the
password based DES key, but doing so does not significantly increase
the security of the approach. In any event, you need to use public
key to send the passphrase to the KDC.
~ Cliff
