In this article I would like to introduce you to a Microsoft protocol – Kerberos Key Distribution Center Proxy. KKDCP is an open specification by Microsoft that enables Kerberos clients outside the organisation’s premises to use the Kerberos Authentication Protocol.

Kerberos

Short Introduction to Kerberos

Kerberos is defined in RFC 4120 and is based on the Needham-Schroeder trusted-third party authentication protocol. Simply put, the goal of Kerberos is to mutually authenticate the client and server, and check if the client is authorized to connect to the requested server.

In a Kerberos environment at least four entities exist:

• Client
• Authentication Server (AS)
• Ticket Granting Server (TGS)
• Server

The Kerberos authentication runs as follows:

First, the client authenticates to the AS and is issued a Ticket Granting Ticket (TGT). The AS is authenticated by returning an encrypted random value sent by the client. The client itself is not explicitly authenticated to AS, but its identity is implied by as the AS encrypts the answer with a key only known to the client. Any further communication requires the correct key.

Next, the client sends the TGT to the TGS along with his service request to the server. The TGS checks if the client is authorized to access the requested service and if so, issues a Service Ticket (ST) and sends it back to the client.

Lastly, the client sends the ST along with his request to the server. The server and client mutually authenticate each other by exchanging encrypted time-stamps. In case of successful authentication, the client is able to use the service provided by the server.

Pitfalls of Kerberos

For a successful Kerberos authentication the AS and TGS must be available on the client’s authentication request. Each issued ticket (TGT and ST) has a distinct validity and cannot be revoked before time runs out. Time synchronisation is a key issue with Kerberos as timestamps are used for authentication challenges. It is thus important to have synchronized clocks. Additionally the client has to secure a long-term secret (shared with the AS) and the AS as well as TGS are trusted not to misuse their functionality.

An attack on the Kerberos protocol is possible if the attacker is able to get a hold of the session key K (created by the AS and used by the client and the server to secure their communication) and the server is offline. The server does not have to be online during the first interaction between the client and the AS/TGS. An attacker could masquerade as server and respond to the client’s service request with a valid reply as he has knowledge of the session key K. He could further authenticate as server to the client.

Kerberos Key Distribution Center Proxy

The goal of this Microsoft open specification is to enlarge the usage of Kerberos into the internet, where the Kerberos System within an organisation’s private network is unreachable.

The KKDCP server is located in a Demilitarized Zone (DMZ) as a standalone system listening on the Kerberos messages from the client on the internet to authenticate at the AS.

Client to Proxy Communication

The client has knowledge where to locate the proxy server, this is done via an URL (KKDCPServerURL). For communication, either HTTP or HTTPS are allowed by the specification. For security reasons it seems obvious to use HTTPS in order to protect the Kerberos messages in transit. HTTPS is also the default foreseen by the specification.

Both, the client and the server send each other messages from type KDC_PROXY_MESSAGE. This is a newly specified message type containing the original Kerberos message and some additional information.

The proxy is used for all requests until the TGS has returned the Service Ticket to the client. The communication with the server is done directly.

Example Protocol Run

The image displays an example protocol run.

1. The client calls the ProxyMessage() method containing the KRB_AS_REQ message.
2. The KKDCP client establishes a secure channel via TLS with the KKDCP proxy server.
3. Afterwards the KDC_PROXY_MESSAGE (containing the KRB_AS_REQ message) is sent.
4. Upon receiving the KDC_PROXY_MESSAGE, the KKDCP server extracts the KRB_AS_REQ message and forwards it to the KDC server.
5. The KDC server sends the KRB_AS_REP to the KKDCP proxy server.
6. The KKDCP proxy server wraps the KRB_AS_REP message in a KDC_PROXY_MESSAGE and sends it to the KKDC client.
7. After receiving the KDC_PROXY_MESSAGE, the KKDCP client hands over KRB_AS_REP message to the Kerberos client.
8. The Kerberos client calls the ProxyMessage() method initiates the KRB_TGS_REQ message.
9. The KKDCP client sends the KDC_PROXY_MESSAGE containing the KRB_TGS_REQ message.
10. After receiving the KKDCP server extracts the KRB_TGS_REQ and forwards it to the KDC server.
11. The KDC server generates the TGT and sends the KRB_TGS_REP message to the KKDCP server
12. The KKDCP proxy server wraps the KDC servers’ message in a KDC_PROXY_MESSAGE and forwards it to the KKDCP client.
13. The KKDCP client hands over the KRB_TGS_REQ message to the Kerberos client
14. The Kerberos client sends the KRB_APS_REQ message to the application server to request the service.
15. The application server returns the KRB_AP_REP message.

This description is somewhat shortened, the recipients have to check the validity, integrity, authentication etc. in all the steps. Plus: It is assumed everything runs flawlessly and the client is authorized to use the requested service from the application server.

Security Implications

Expanding Kerberos authentication into the Internet has its advantages. However there are some risks to keep in mind.

Security of Kerberos Messages

General issue with publicly available services are Denial of Service (DoS) attacks. A malicious client could establish a connection to the KKDC proxy server and present fake, fraudulent and most likely not well-formed Kerberos requests. The proxy will have to process them. Needless to say, the resources of any server are limited. However, the specification says that a KKDCP proxy server validates the Kerberos message encapsulated in a KRB_KDC_PROXY_MESSAGE and should drop the connection and stop the processing if it is not well-formed. This probably should prevent the elevation of a DoS to internal Kerberos elements and thus limiting the negative effects to outside clients only.

The important question is: What is being validated in the KKDCP proxy server? Does the proxy server keep an acceptance window for nonces and timestamps to check for replayed packages? If not, then the proxy server is forwarding a replayed Kerberos message into the network and the internal Kerberos systems have to deal with them. This is because a replayed Kerberos message will always be well-formed. As a consequence, illegitimate traffic is forwarded behind the firewall. The KKDCP proxy would only be able to check for replayed messages when it has knowledge of the keys used to encrypt the Kerberos messages. This should not be the case as it would increase an attacker’s ability upon compromising of the proxy.

Although the default in Microsoft’s specification is HTTPS, the option to use it in HTTP implies the risk of message integrity violation and information disclosure. Should an attacker be able to intercept and manipulate the traffic, he could learn the following:

• The identity of the client, the server and the TGS
• The validity time of a TGT or ST

Apart from learning that information, he could also manipulate the traffic and:

• Change the identities of whom the client would like to talk to
• Change the validity time in a way so that the client is never authenticated
• Change any encrypted Kerberos message so that it could not be understood by the AS, TGS or server

All three scenarios would disturb the client’s activities and effectively result in a Denial of Service.

If somehow the KKDCP proxy server gets compromised, an attacker doesn’t gain much. As the proxy has no knowledge of the keys used to encrypt the Kerberos messages, he cannot learn more as in the scenario with HTTP-only traffic. In terms of the DoS, he is in an advantageous situation. He can drop all communication or just for some specific clients.

Conclusion

It is understandable that Kerberos authentication is of great value for organisations if it’s on the Internet. I came across KKDCP while analysing MobileIron version 6.0. It enables the organisations authentication into the outside, but care must be taken as information about the internal network could be leaked. Not just in the case where HTTP-only is used. With SSL/TLS faux-pas which became public earlier this year (goto-fail and Heartbleed) HTTPS doesn’t have to be a silver bullet per se. Care must be taken in configuration and maintenance of SSL/TLS and/or clients could be affected with denial of service. Adding more key knowledge to the proxy would increase the possible damage in case of a compromising dramatically, but could be used to decrease the risk of Denial of Service of the internal infrastructure.

About the Author

Oliver Kunz has been in information security since 2010. Mainly, he deals with incident response, forensics and the security of mobile devices.

Links

• http://msdn.microsoft.com/en-us/library/hh553774.aspx
• http://tools.ietf.org/html/rfc4120
• https://vuldb.com/?id.12370
• https://vuldb.com/?id.12819