Every time I have read about the Kerberos protocol in the past, I have just passed through the section that talks about the “Authenticator” and have never thought about its role in the authentication process. For some reason I decided to know more about it today so this post explains what it does and why we need it.
** As you may know, the Kerberos protocol is based on the concept of key distribution and a number of keys are involved in the authentication process so I have used color coding to simplify correlation. Items in the same colour are referring to the same key. **
When a Kerberos client wants to interact with a service (like a secured WCF service), it needs a service ticket to pass its credentials to the service and prove its identity. The client obtains this service ticket by sending a request to the Key Distribution Center (KDC). After verifying the user credentials, the KDC creates and returns the following items back to the client:
- A session key for the client to use with the service, encrypted with the user’s logon session key (which is kept securely by the client).
- The same session key mentioned above along with the user’s authorisation data, encrypted with the service’s long-term key (only known to the KDC and the service).
The session key and the service ticket are stored in the user credential cache on the client. From this point, the client sends the service ticket to the service when creating a new connection. Since the service ticket is encrypted with the service’s long-term key (which is only known to the KDC and the service), the service can trust the contents of the ticket and safely assumes that the ticket was created by the KDC. But what it can’t do is to make sure that the message was sent by the client specified in the service ticket as the ticket could have been stolen and played by a malicious node. This is where the “Authenticator” comes to the rescue.
Before sending the service ticket to the service, the client creates the authenticator, which includes the user name and the current time on the client. It then encrypts the authenticator with the session key created by the KDC for the client to use with the service. The client and the service are the only nodes who know this session key (the KDC encrypted the first copy with the user’s logon session key and the other copy with the service’s long-term key) so if the service can decrypt the authenticator successfully, we know that the client who is trying to access the service is not malicious. The service performs this verification by decrypting the service ticket (it knows its own long-term key), extracting the session key, decrypting the authenticator using the session key and comparing the user name in the authenticator to the user name in the service ticket.
We mentioned that the authenticator has another data element too: the current time on the client. This timestamp helps in preventing message replay by malicious parties on the network. The server does this by comparing the client timestamp embedded in the authenticator with its own time when the message is received. Now the question is, how can we make sure that a minor time difference caused by network latency and/or clock skew on either of the nodes does result in rejection of all messages by the server? There are two mechanisms to prevent this from happening:
- An error margin for the clock skew. As long as the time on the client is within few minutes (the default is 5 and is defined using a domain-wide group policy) of the server’s time, the service will ignore the difference and will accept the message.
- Time synchronisation. This is one of the major reasons why Active Directory controllers provide a time synchronisation service. If the time on the client computer goes out-of-sync (outside the defined range), it may experience problems when logging onto the domain and/or using the services on the domain.
To prevent replay attacks, the service keeps a log of the authenticators it receives in a replay cache and only accepts the authenticator if it can’t find it in its replay cache. Since the authenticators are valid only for few minutes, the service can purge the older items from its replay cache as those authenticators with an older timestamp will be rejected anyway.
So the authenticator plays two major roles in Kerberos and Active Directory:
- Enabling the service to verify that the sender of the service ticket is the client the service ticket was created for.
- Helping the service in preventing replay attacks by rejecting duplicate authenticators or those authenticators whose timestamp is out-of-sync.
If you want to know more about this topic, then go and read this TechNet article.
