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)
Link to original
- 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-derived key
- Kerberos requires the user to submit a timestamp for pre-authentication
- This feature is enabled by default
AS-REP
AS-REP: authentication server reply (KDC to User)
KDC decrypts timestamp (pre-authentication) and issues encrypted TGT
Link to original
- 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
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.
Link to original
- 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
TGS-REP
TGS-REP: Ticket Granting Server Reply (KDC to User)
Link to original
- 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
AP-REQ
AP-REQ: Application Request (User to Service)
User requests service with the session key
Link to original
- 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
AP-REP
AP-REP: Application Reply (Service to User)
Service grants access
Link to original
- 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.