-1

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

Tomer Schweid
  • 98
  • 1
  • 1
  • 6

1 Answers1

0

1) that seems pretty thorough, I'm not sure about all the details.

2) The user's password isn't enough because it would have to be shared between two parties, and the only two parties that share it are the KDC and the client. If you're going to send something over the wire, even encrypted, it's better if it doesn't have a long useful life. So the session key is used by the client to request the service ticket (I think). And, the KDC generates service tickets with session keys, so when a client gets a ticket for say an LDAP or HTTP service, the KDC generates a session key. That session key is in the service ticket, and also the service ticket contains an encrypted message to the service providing agent (the LDAP or HTTP server) which also includes the session key. So, now the client and the server both share an ephemeral secret that the KDC told to both of them. This key is used when there is a protocol in place to use it. So perhaps say a telnet server could encrypt traffic over the wire if it's kerberos enabled for example.

4) Including the time, and a 5 minute leeway is a way to ensure that clocks don't have to be exactly synchronized down to the millisecond, you can tolerate any normal levels of network delay or brief outages, and yet you can't replay a request later. It's no good to go get a ticket, have it snooped down the wire by the NSA and then days/weeks/years later after brute-forcing your password or decrypting using fancy mathematical attacks discovered at a later time, they go and use the ticket again. Ensuring that the ticket is recent prevents that kind of issue.

The session key isn't used all the time. For example if you connect to an https website using kerberos authentication, typically you'd use kerberos for the authentication, but the session key is negotiated using standard https methods (ie. SSL/TLS)

dlakelan
  • 86
  • 8