Kerberos Authentication Protocol
This entire page is based on RFC 4120 and RFC 4556, documentation from MIT Kerberos as well as this great guide to Kerberos by Lynn Root.
The Domain Controller (DC) is responsible for security authentication requests within a network domain and controlling access to domain resources. It authenticates users, stores user account information and enforces security policy for a domain. The DC host can achieve this using Microsoft's Active Directory (AD) or an identity management software such as and FreeIPA. Both are more than capable to act as the centerpiece in a kerberized network environment.
Windows Authentication supports two authentication protocols, Kerberos and NTLM where Kerberos is vastly superior in terms of security. While Kerberos usually preferred, NTLM can still be used as a fallback. Some services, in particular legacy systems, may support Windows Authentication but only with NTLM.
Kerberos provides a means of verifying the identities of principals, which is a workstation user or a network server, on an untrusted network by relying on a trusted third party, the Key Distribution Center (KDC). The KDC itself consists of two main components, the Authentication Server (AS) and the Ticket-Granting Server (TGS). The set of AD domains (and thus services) in which the KDC has the authority to authenticate a user make up the Kerberos Realm.
The Kerberos authentication uses a shared secret symmetric-based encryption key which is known only to two entities, the KDC and the client. How the secret is made known or stored to the client or the KDC in not part of the protocol. In the simplest case an admin enters it manually.
The protocol in its entirety is designed such that the KDC and the Service never communicates directly. This is achieved trough a ticket-based authentication with two types of tickets.
- Ticket Granting Ticket (TGT) is issued by the AS and is used to authenticate the user towards the TGS.
- Service Ticket is issued by the TGS and used to authenticate the user towards services.
In order to receive these tickets, different sub-protocols or exchanges are used. In order the access the service, there are therefore three entities the user needs to interact with, the AS, TGS and the service itself. When interacting with the AS and TGS, the client receives two encrypted messages, of which only one can be decrypted using the shared secret.
Finally, Kerberos is time-sensitive since the tickets include timestamps. This means that all hosts in the Kerberos Realm needs to be time-synchronized through, for example, an NTP service.
The principal is in fact a string on the form
primary/instance@REALM and is thus divided into three parts. For a user this is <username>/<role>@<domain> with the possibility of omitting role while a service would be on the form host/<hostname>@<domain>. The secret is determined by
hash(username+password)where the username acts as a salt. Services use generated keys as passwords which are stored on the host instead of a password which would require a user-interaction to enter it.Kerberos consists of several sub-protocols/exchanges which are defined below.
Pre-requisite: The KDC must have a shared secret with the Client and another secret shared with the Service. How the Secrets are generated or distributed is out of scope.
- 1.The Client sends one message in plaintext to the AS with
Client-ID,TGS-ID. - 2.The AS checks if the user exists in the KDC DB. If the user exists, the exchange continues.
- 3.The AS creates a random-generated
TGS-Sessonkey. - 4.The AS replies with two messages, the TGT encrypted with the
TGS-Secretand another message (A) encrypted with theClient-Secret. TheTGS-Sessionis included in both. - 5.The Client receives the encrypted TGT and encrypted message (A) and decrypts (A) with its
Client-Secretto get theTGS-Session. The encrypted TGT is stored in the Client's keytab.
- 1.The Client send three messages to the TGS, one message called authenticator which is encypted with the
TGS-Session, a plaintext message withService-IDand the encrypted TGT. - 2.The TGS checks if the Service exists in the KDC DB. If the service exists, the exchange continues.
- 3.The TGS decrypts the encrypted TGT and gets the
TGS-Sessionand uses it to decrypt the encrypted autenticator message - 4.The TGS performs a series of checks. If all checks passes, the exchange continues.
- 1.The TGS checks if the TGT has expired using the
timestamp - 2.The TGS compares the
Client-IDand thetimestampin the TGT and authenticator message, the first should be identical and the second should be within the configured time-tolerence (~2 mins) - 3.The TGS checks if the authenticator with the corresponding
timestampalready exists in the KDC-cache which would indicate a replay-attack
- 5.The TGS generates a random-generated
Service-Sessonkey. - 6.The TGS replies with two messages, one message (B) that is encrypted with the
TGS-Sessionand the Service Ticket which is encrypted withService-Secret. TheService-Sessionkey is included in both. - 7.The Client receives the encrypted message (B) and the encrypted Service Ticket and decrypts (B) with the
TGS-Sessionto get theService-Session. The encrypted Service Ticket is stored in the Client's keytab.
- 1.The Client sends two messages to the Service, one message called authenticator which is encrypted with the
Service-Sessionand the encrypted Service Ticket. - 2.The Service decrypts the Service Ticket with its
Service-Secretand getsService-Sessionwhich it uses to decrypt the authenticator. - 3.The Service performs a series of checks in a similar manner as the TGS:
- 1.The Service checks if the Service Ticket has expired using the
timestamp - 2.The Service compares the
Client-IDand thetimestampin the Service Ticket and authenticator message, the first should be identical and the second should be within the configured time-tolerence (~2 mins) - 3.The Service checks if the authenticator with the corresponding
timestampalready exists in the Service-cache which would indicate a replay-attack
- 4.The Service stores the
Service-Sessionlocally and associates it with the Client. - 5.The Service replies with one message called authenticator which is encrypted with
Servce-Session - 6.The Client receives the autenticator and decrypts it with the
Service-Sessionin order to verify the identity of the Service. - 7.The Client and the Service are now authenticated against each other and shares the
Service-Sessionkey which will be used together with the Service Ticket in future requests.
[MS-KILE].pdf
3MB
PDF
Microsoft Kerberos Network Authentication Service V5 Extensions
Last modified 1yr ago