Kerberos Authentication (again… but better)
An authentication protocol aims to ensure that a person, a program or an entity that is trying to access to a resource, an information or a system, it is truly it and not an intruder.
One of the most known authentication protocol in Windows environment is Kerberos (RFC 1510 for the V5).
Initially the protocol was developed by the MIT in the late ’80s but is still used by Windows as the default authentication protocol on Active Directory environments replacing the old NTLM protocol (old but widely used an active in many AD environments).
At the base of Kerberos there are the simple cryptographic concepts of symmetric key and trusted third-party.
A symmetric key is just a word/string used by the parties to encrypt or decrypt a message.
A trusted third-party is an entity other than the owner and verifier that is trusted by the owner, the verifier or both to provide certain services. In the case of Kerberos the trusted third-party provide the authentication services: that’s the Domain Controller generally speaking.
For the Kerberos authentication the most known keyword is: ticket.
A ticket is just a “pass” to access a cinema, a concert or a Windows service in this case.
When a user wants to access any service (i.e. his Windows workstation) in a Windows domain, it needs a Service Ticket.
To get a Service Ticket, the client needs to talk to the Ticket-Granting Server (TGS), and to talk to the TGS, it needs a special Service Ticket. The Service Ticket for the TGS is known as the Ticket-Granting Ticket (TGT).
In a real world example to enter a concert you need a ticket (TGT) and on entrance a part of it is torn by the staff after being validate using a scanner; the remaining part is the TGS that allows you to access the seats, the backstage, etc.
Entities
The Kerberos protocol includes the following 3 entities in the authentication process:
- Client: a user or a service that want to access a resource
- Key Distribution Center (KDC): a trusted third-party authentication service that is supported by the Authentication Service (AS) and that issues the “tickets” (TGTs).
- Application Server (AP): offers the service required by the user
Flow
The authentication protocol flow is the one described in the following picture; the next paragraphs will explode every steps.
- The client sends a KRB_AS_REQ to the key distribution center (the Domain Controller) requesting a TGT.
The request includes the following data:
- Timestamp: encrypted with the client password hash(symmetric key)
– to authenticate the client and prevents replay attacks - Username: the KDC must know which user want a TGT
- the SPN service for the krbtgt account
– this is an “hardcoded” string since first of all the client needs to speak to the m̶a̶n̶a̶g̶e̶r Kerberos service. - a nonce generated by the user
– used by the user and KDC to detect replay attacks
2. The Key Distribution Center verify the user identity by decrypting the timestamp and, if it is correct (the decryption is possible), respond with a KRB_AS_REP message:
The response includes the following data:
- Username
- Ticket-Grant Ticket (TGT)
– the TGT is readable only by the KDC since it’s encrypted with the password hash of the krbtgt account an it used for the following requests
– the krbtgt account is the key master of the Kerberos protocol and can access all users and services password hashes stored in the Domain Controller - Encrypted data with the hash of the user password hash
– these data can be read only the user and are used to validate the nonce (identical to the one sent by the user) and to keep notes of the session and duration of the ticket
3. Now the use has the TGT an can be used to request a TGS to access the service using the provided TGT sending a KRB_TGS_REQ message:
The message includes the following data:
- Encrypted data with the session key (only known to KDC and user, symmetric key)
– this is used to validate the user asking for the TGS since the TGT contains the same session key used by the user to encrypt the information; if the decryption fails something is wrong and an intruder may be tampering the traffic - the TGT previously gained by the KDC as “warranty”
- the SPN of the request service (i.e. the logon for the workstation, a SMB share, etc.)
- another nonce generated by the user
4. The KDC validates the request and the TGT and then returns a TGS inside a KRB_TGS_REP message:
The response contains:
- The username
- The TGS encrypted with the service password hash (the KDC knows all the users/services password hashes, it’s the Domain Controller)
– the TGS is readable only by the KDC and the service since it’s encrypted with the password hash of the SPN an it used for the following requests to actually access the service and to maintain the session - Encrypted data with the hash of the session key
– these data can be read only the user and are used to validate the nonce (identical to the one sent by the user) and to keep notes of the session and duration of the ticket to access the service
5. The user can finally send the TGS to interact with the service (AP) using a KRB_AP_REQ message:
The message contains:
- the TGS previously sent by the KDC
– since it is encrypted with the service password hash the AP can decrypt the ticket and validate the message and session - Encrypted data wit the session key of the service
– the service session key is known to the user since it is sent, encrypted, by the KDC, and the service itself since it is inside the TGS; if all the decryption are correct the request is validated
For further security verification (this steps is optional) the AP can send a KERB_VERIFY_PAC request to the KDC to validate the PAC message content. The Privileged Attribute Certificate (PAC) is an extension to Kerberos tickets that contains useful information about a user’s privileges; if the KDC validates (if not vulnerable to MS14–068) the user permissions; the access is granted.
References:
