1

In Kerberos, the KDC (Key Distribution Center) creates a TGT and sends it back to the client. The client cannot open it and is not supposed to be opened.

What if someone is eavesdropping and they steal the TGT and then sends it to the KDC for tickets?

CodingYoshi
  • 121
  • 3

2 Answers2

1

After doing some more digging, I think I have found the answer. When the TGT is returned to the client, it has 2 main parts as shown below:

enter image description here

The key point to note is that the whole entire TGT is encrypted with the client's (Alice's) private key (Alice's password) but within this TGT is a sealed ticket and that ticket is encrypted with the Ticket Granting Service (TGS, the service which created the TGT).

Once this entire TGT arrives at the client, the client decrypts it and the result is

  1. A Sealed Ticket (TFS Encrypted and it will stay encrypted).
  2. A session key

After now, whenever the client needs a ticket for a service (not a TGT but just a ticket), the client has to send the sealed ticket part of the (TGT) within all requests and the request has to be encrypted with the Session Key as shown below:

enter image description here

Thus if a man-in-the-middle gets a hold of the original TGT as shown again below:

enter image description here

, they cannot decrypt it to it's individual parts. If they were to send it for a ticket, it will NOT only contain the Sealed Ticket but the entire thing and the request will NOT be encrypted with the Session Key. Thus when the server decrypts it, it will NOT be only the Sealed Ticket, and it will not be encrypted with the session key (How could it be? The attacker could not decrypt to get the session key) and thus it will reject it.

Even another precaution is that the original client's IP is within the ticket so only requests from that same IP will be able to use the ticket; this, however, is just another precaution.

See here for more info.

CodingYoshi
  • 121
  • 3
  • The article you link to describes that first diagram as a "message" which is sent to the client. I don't think it is correct to describe it as "the TGT". Curiously, your article disagrees with the Wikipedia article I quoted as to whether the entire message or just the session key is encrypted with Alice's key, but either way the eavesdropper can't get any useful information. – Harry Johnston Feb 07 '19 at 02:13
  • ... actually, looking at that diagram again, I think it is clear that the message as a whole is *not* encrypted with Alice's key, just the second part with the session key. The relevant sentence in the article is just confusingly written. – Harry Johnston Feb 07 '19 at 02:16
0

The protocol is described in the Wikipedia article on Kerberos.

When the authentication server provides the TGT to the client, it also provides a Client/TGS session key, encrypted with a secret key generated from the user's password so that the client can decrypt it.

The eavesdropper does not have the user's password, and therefore cannot decrypt the Client/TGS session key. Without it, the TGT is useless.

Harry Johnston
  • 5,875
  • 4
  • 35
  • 52
  • I doubt wikipedia is accurate because of this sentence *the AS generates the secret key by hashing the password of the user found at the database*, I doubt passwords are stored as plain text to hash it. There are some flaws in the wikipedia article so I steered away from it. But your answer about the session key is correct, but, subsequent requests need the TGT also. So it is useless without session key and TGT (sealed ticket part). – CodingYoshi Feb 07 '19 at 02:40