How kerberos authentication works

Question

I've tried to figure out how kerberos authentication works, the information which I found was always missing something as if a part of it was taken for granted. I am aware of the process in general but missing some details.

Getting TGT:

1. First a user should get a TGT (Ticket Granting Tickets) from the KDC - the user sends a request with only it's user name (UPN) and without it's password. Some extra information is given to prevent a resent of the request such as ip address and a timestamp. If preauthentication is required then the time is hashed with the user's password.

2. The KDC is sending the user back the following: A. TGT - with a timestamp, user name, ip address and a session key - the TGT is encrypted with a secret only the KDC knows and therefore cannot be changed by anyone.
   B. Session key for the user and the KDC to be used in later communication.
   Those things are encrypted using the users password (a basic shared secret amongst the KDC and the user). In case a preauthentication was used the server will check if the timestamp was valid before sending the information back.

3. The users receive the information and decrypt it using it's password - and then stores it in it's memory (kerberos tray).

Getting TGS:

1. When the user is requested to authenticate itself from a service he sends a request to the KDC for a TGS (Ticket Granting Service), the request contains the TGT, UPN and the SPN (Service Principal Name - say, the URI of a webpage).

2. The KDC then decrypts the TGT and validate it's authenticity, that it is corresponds with the UPN, from the same IP address and still valid (the ticket has an effective time period).

3. The KDC sends a TGS to the user encrypted with the service password.

4. The user presents the TGS to the service - which decrypts it using it's own password.

5. The authentication is complete since the service counts on the fact that it's password is only shared between it and the KDC so it trusts that the KDC authenticated the user earlier.

A few questions:

1. Am I missing something or that's it?

2. When does the user and the KDC ever use the session key? At what point? Why is it necessary? Why does the user password isn't enough?

3. There should also be a session key between the user and the service (to the best of my knowledge) - when and why is it used (same as the last question)?

4. Kerberos has a 5 minute gap limitation between all parties - I understand why keeping the time in sync is important since it is used as something that we encrypt and decrypt so how come any gap is OK? Why 5 minutes?

I'll be glad for any corrections if you have.

Thanks in advance, Tomer

Answer 1

So, I think I've found the answer.

I'll make a few corrections since the question has some inaccuracies.

Getting TGT:

1. First a user should get a TGT (Ticket Granting Tickets) from the KDC - the user sends a request with only it's user name (UPN) and without it's password. Some extra information is given to prevent a resent of the request such as ip address and a timestamp. If preauthentication is required then the time is hashed with the user's password.
2. The KDC is sending the user back the following:

A. TGT - with a timestamp, user name, ip address and a session key - the TGT is encrypted with a secret only the KDC knows and therefore cannot be changed by anyone.

All of this are simply called an "authenticator".

B. Session key for the user and the KDC to be used in later communication. Those things are encrypted using the users password (a basic shared secret amongst the KDC and the user). In case a preauthentication was used the server will check if the timestamp was valid before sending the information back.

The TGT itself is only hashed by the KDC's secret and not also at the user's password.

3. The users receive the information and decrypt it using it's password - and then stores it in it's memory (kerberos tray).

Getting TGS:

1. When the user is requested to authenticate itself from a service he sends a request to the KDC for a TGS (Ticket Granting Service), the request contains the TGT, UPN and the SPN

The request also include a fresh authenticator (instead of the UPN mentioned) which the KDC will check against the one that is in the TGT. The authenticator is encrypted using the session key of the user and the KDC. The KDC will decrypt the TGT using it's password and then extracts the session key from it (it does not saves the information on it) and next decrypts the authenticator using the session key.

(Service Principal Name - say, the URI of a webpage).

An SPN doesn't contain a URI - it contains the host, the service and a port - something like that: HTTP/localhost:80 Or ldap/localdc. port number could be omitted if default port is used (such as 80 for HTTP or 389 for ldap).

2. The KDC then decrypts the TGT and validate it's authenticity, that it is corresponds with the UPN, from the same IP address and still valid (the ticket has an effective time period). 3. The KDC sends a TGS to the user encrypted with the service password.

The KDC also sends a session key for the client and the user to use later on. it sends it encrypted in the session key of the KDC and the user from earlier - another copy of the session key (of client and the server) is inside the TGS itself, inside the TGS also resides an authenticator of the client.

4. The user presents the TGS to the service - which decrypts it using it's own password. 5. The authentication is complete since the service counts on the fact that it's password is only shared between it and the KDC so it trusts that the KDC authenticated the user earlier.

The user also sends an authenticator encrypted with the session key of the client and the server. The server then decrypts the TGS using it's password - extracts the session key from the TGS and uses it to decrypt the authenticator and compares it to the one in the TGS. If valid then the authentication of the client is complete. Kerberos also features an option for the client to authenticate the server (called mutual authentication) - if a flag of mutual authentication is sent by the client then there is another step.

6. The server sends a timestamp to the client that is encrypted using their shared session key. The server proves it's authenticity by manipulating the data that the client sent (means it could've decrypted it) so it means it knows the servers password which only it and the KDC should know.

A few questions:

1. Am I missing something or that's it?
2. When does the user and the KDC ever use the session key? At what point? Why is it necessary? Why does the user password isn't enough?
3. There should also be a session key between the user and the service (to the best of my knowledge) - when and why is it used (same as the last question)?
4. Kerberos has a 5 minute gap limitation between all parties - I understand why keeping the time in sync is important since it is used as something that we encrypt and decrypt so how come any gap is OK? Why 5 minutes?

1. Yes.
2. Answered on the when, as to the why - the motive is to give an optional attacker a fewer samples of data which is created using the password so it would be harder to crack the password from the encrypted data. the session key changes all the time (each logon or after the expiration of the TGT) and by the time an attacker could crack it it will not be useful.
3. Answered.
4. Well, some gap has to be ok since the synchronization is not complete. I have a guess about the 5 minutes here - The KDC and the server should keep in memory the last 5 minutes of requests in order that an attacker won't resend a valid request and will get authenticated (called replay attack). So each time a request is made the server or KDC has to look in memory to see if it's not a resented request. Obviously there is a trade-off since the bigger the time gap the more memory the server needs to allocate to this task. By the way - the time period is only 5 minutes by default and is configurable.

Hoped it helps.

All of the things are in this link (very repetitive if one is reading the whole thing from the start to the end - you should read only the part that you want to understand) - Https://Technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx

And I also read a bit of the RFC - https://www.rfc-editor.org/rfc/rfc1510

And two less detailed links:

https://technet.microsoft.com/en-us/library/cc961976.aspx

https://technet.microsoft.com/en-us/library/aa480475.aspx (deals with IIS authentication - there is a part where kerberos is mentioned and explained a bit).