OTPs as Second Factor
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 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:
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.
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.
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.
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.
The image displays an example protocol run.
ProxyMessage()method containing the
KRB_AS_REQmessage) is sent.
KDC_PROXY_MESSAGE, the KKDCP server extracts the
KRB_AS_REQmessage and forwards it to the KDC server.
KRB_AS_REPto the KKDCP proxy server.
KRB_AS_REPmessage in a
KDC_PROXY_MESSAGEand sends it to the KKDC client.
KDC_PROXY_MESSAGE, the KKDCP client hands over
KRB_AS_REPmessage to the Kerberos client.
ProxyMessage()method initiates the
KRB_TGS_REQand forwards it to the KDC server.
KRB_TGS_REPmessage to the KKDCP server
KDC_PROXY_MESSAGEand forwards it to the KKDCP client.
KRB_TGS_REQmessage to the Kerberos client
KRB_APS_REQmessage to the application server to request the service.
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.
Expanding Kerberos authentication into the Internet has its advantages. However there are some risks to keep in mind.
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:
Apart from learning that information, he could also manipulate the traffic and:
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.
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.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here