[3665] in Kerberos
S/KEY integrated with Kerberos?
daemon@ATHENA.MIT.EDU (James R. Hendrick)
Mon Aug 8 12:49:40 1994
Date: Mon, 8 Aug 1994 12:32:19 -0400
From: "James R. Hendrick" <hendrick@ctron.com>
To: bcn@ISI.EDU
Cc: kerberos@MIT.EDU
In-Reply-To: Clifford Neuman's message of Mon, 8 Aug 1994 07:46:14 -0700 <199408081446.AA02561@cym.isi.edu>
Date: Mon, 8 Aug 1994 07:46:14 -0700
Posted-Date: Mon, 8 Aug 1994 07:46:14 -0700
From: Clifford Neuman <bcn@ISI.EDU>
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.
If I am missing something here, please help me understand. Why can't the KDC
store the user's S/Key (keyinit) passphrase similarly to how a standalone
machine does so it can derive the proper sequence of passphrases on demand.
This would require keeping an additional database of S/Key (initial)
passphrases and sequence IDs (aka /etc/skeykeys) but shouldn't that be there
(on the KDC) anyway so the user can generate his/her sequence of one-time keys
from any Kerberized client machine? If keyinit used an existing session key
for encrypting the S/Key passphrase when sending to the KDC, isn't this as
secure as the current kpasswd?
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).
Excuse my ignorance here. Isn't this risk already present in Kerberos? If
the attacker has access to any principal's password, (whether by watching,
capturing keystrokes, or however), they have broken the system since they
*are* the user as far as Kerberos can tell. I thought the goal here (at least
mine :-) was to allow establishing a TGT from a non-trusted outside world
using a one-time key. Once "inside", the user then can access other machines
without sending anything useful to an attacker (like their normal Kerberos
password to run a standard kinit or the S/Key initial passphrase ) across
the wire.
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
^^^^^^^^^^
If you mean the one-time passphrase.
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.
Yes. Encrypting the response from the KDC to the client with the one-time-key
would not send anything useful across the wire, and allow the client machine
to prompt the user for this key to perform authentication. Thus the user
only types this one-time password and anyone watching the wire/keybord/whatever
would not get anything useful. My concern is that of the client's login program
not knowing the proper sequence number initially. Should the login program
on each client be made a registered principal so it can use it's own
"password" to encrypt the whole sesion with the KDC? Or wouldn't the
sending of a sequence number unencrypted outside the TGTGT be a problem?
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.
Actually, I hadn't thought of using public-key techniques here. This is great!
If the KDC serves as a certifier also, the whole session from client machine
to KDC can be encrypted via the KDC's public key as you say. But the
response to the client would still need to contain something that only the
proper one-time key could decipher. Otherwise the goal of not needing to
type any long-term password is not met.
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
Thanks for your reply!
Jim
P. S. Has anyone thought about how to keep the sequence numbers in-sync across
multiple KDCs ??
