Kerberos authentication process

When a client authenticates to a service using Kerberos, he first needs to obtain a ticket-granting ticket (TGT) from the KDC (specifically the authentication server). With the TGT, he can now request a TGS (service ticket) from the KDC (specifically the ticket-granting server). The TGS can be used to authenticate to the service and obtain a service session key.

sequenceDiagram
    participant B as KDC (AS+TGS)
    participant A as Client
    participant C as Service
    A->>B: (AS-REQ) get TGT
    B->>A: (AS-REP) sends TGT
    A->>B: (TGS-REQ) get ST (TGT + UA)
    B->>A: (TGS-REP) sends ST
    A->>C: (AP-REQ) get SA (ST + UA)
    C->>A: (AP-REP) sends SA

Kerberos authentication consists of the following requests & responses:

AS-REQ

AS-REQ: Authentication Server Request (User to KDC)

user requests TGT from KDC with encrypted timestamp (pre-authentication)

• Message 1 to AS; cleartext
  • Username / ID
  • Service name / ID
  • User IP
  • Requested lifetime for TGT (might be ignored based on policy)
• Message 2 to AS: timestamp; encrypted with client password hash
  • Kerberos requires the user to submit a timestamp for pre-authentication
  • This feature is enabled by default

Link to original

AS-REP

AS-REP: authentication server reply (KDC to User)

KDC decrypts timestamp (pre-authentication) and issues encrypted TGT

• KDC verifies timestamp
  • KDC decrypts timestamp with client password
  • A timestamp within 2 minutes of the request is fine
  • If AS cannot find the timestamp in its cache, the request is valid (not a replay) and timestamp is added to the cache
• KDC generates client secret key for later use
  • can be generated by both the server and the client
  • client_secret = hash(password + salt (user_name@realm_name) + kvno (key version #; useful for long-lived keys))
• Message 1 to client: encrypted with client secret key
  • TGS name / ID
  • Timestamp of message
  • Lifetime (same as TGT’s)
  • TGS session key
• Message 2 to client: TGT; encrypted with TGS secret key to prevent tampering by user
  • Username / ID
  • TGS name / ID
  • Timestamp of TGT
  • User IP address
  • Lifetime of TGT
  • TGS session key

Link to original

TGS-REQ

TGS-REQ: Ticket Granting Server Request (User to KDC)

User requests KDC for a service ticket using TGT. The service ticket is also called a TGS ticket, though TGS is also the name of the service which is confusing.

• Message 1 to TGS; cleartext
  • Service name / ID
  • Requested lifetime for service ticket
• Message 2 to TGS: User Authenticator; encrypted with TGS session key
  • Username / ID
  • Timestamp
• Message 3 to TGS: forwarded TGT

Link to original

TGS-REP

TGS-REP: Ticket Granting Server Reply (KDC to User)

KDC verifies TGT and its privileges then sends a session key for the user to the service

• TGS decrypts TGT with TGS secret key to obtain the TGS session key
• TGS decrypts the user authenticator with TGS session key.
• Once the two messages have been decrypted, TGS validates the messages
  • TGS compares the TGT username and the user authenticator username
  • TGS compares the TGT and user authenticator timestamp. Typically a difference between 2 minutes is fine.
  • TGS compares the IP address stored in the TGT and the IP address of the client host (who sent TGS the TGS-REP)
  • TGS checks that the TGT has not expired
  • TGS checks that the TGS Cache does not already contain a recent authenticator for this service to prevent replay attacks
• If the user is authenticated and the service exists, TGS grabs the service’s service secret key
• TGS adds this user authenticator to the TGS cache
• Message 1 to client; encrypted with TGS session key
  • Service name/ID
  • Timestamp
  • Lifetime (same as TGT’s)
  • Service Session Key
• Message 2 to client: service ticket (aka TGS); encrypted with Service Secret Key
  • Username/ID
  • Service name/ID
  • Timestamp
  • User IP address
  • Lifetime of service ticket
  • Service Session Key

Link to original

AP-REQ

AP-REQ: Application Request (User to Service)

User requests service with the session key

• Client decrypts the first message with the TGS session key to obtain service session key
• Message 1 to service: user authenticator; encrypted with service session key
• Message 2 to service: forwarded service ticket

Link to original

AP-REP

AP-REP: Application Reply (Service to User)

Service grants access

• Service decrypts service ticket to get service session key
• Service decrypts user authenticator with service session key
• Service validates the messages in the same fashion as TGS with TGT
  • Username, Timestamp, IP addresses, Lifetime/expiry
  • Checks the service name matches its own
  • Checks its own Service Cache for the same user authenticator to prevent replay attacks
  • Checks if user has access to service
  • Service adds the user authenticator to the service cache
• Message 1 to client: Service Authenticator; encrypted with Service Session Key
  • Service name/ID
  • Timestamp
• Once the client decrypts the service authenticator and verifies the service name and timestamp, the mutual authentication process is complete. The client caches the Service Ticket in the User Cache for future use.

Link to original