On Sep 29, 2005, at 14:32, NetSteady wrote:
I'm actually speaking about the enc-part of the Kerberos packet
itself,
not in the ticket. Is this the part you were speaking of?
Any EncryptedData object. The specs in RFC 3961 specify how
encryption is done. For all (I believe) currently defined encryption
systems, one block of random data is stuck on the front before CBC-
mode encryption is done.
Our problem is that we're trying to validate the password for the user
when we receive the AS-REP packet, but for some reason, we cannot find
where to get the encryption key for the enc-part. We've read the RFCs
(many many times) and are still having issues finding this.
(1) RFC 4120 section 5.4.2 says that the ciphertext is encrypted
using the user's long-term key, which (we specify elsewhere) is
generally derived from the password.
(2) Simply decrypting the AS-REP isn't sufficient to validate the
password if you're going to grant access to important resources based
on it, unless you've got an unspoofable connection to the KDC (say,
you're already running on the box with the KDC in it). Check Google
for "Zanarotti attack"; basically, an attacker could spoof the KDC
response and provide a password chosen by the attacker, and the
decryption would succeed. You would need a service key on the device
doing the verification, and a TGS-REQ exchange to get a ticket for
that service, as part of a possible validation process.
Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
