Figure 1. Kerberos Overview
Kerberos is an authentication service, which provides security over the network. It assumes that the messages can be read, modified and fabricated by an intruder. It does not provide any security against breaches caused by buggy software or poor passwords. The original design and implementation of Kerberos V1 through V4 was the work of three former Athena Project staff members, Steve Miller of Digital Equipment Corporation and Clifford Neuman along with Jerome Saltzer, Technical Director of Project Athena, and Jeffrey Schiller, MIT Campus Network [1], [8],[10] . It is designed to provide strong authentication for client/server applications by using secret-key cryptography. The Kerberos protocol uses Data Encryption Standard (DES) so that a client can prove its identity to a server (and vice versa) across an insecure network connection. Authentication is one of the important network security aspects nowadays in internet activity, a more secure application for authentication is fairly useful. Kerberos is an authentication service developed as part of Project Athena at MIT. In this paper, three proposed extensions to integrate public-key cryptography into Kerberos in cross realm are outlined and some basic performance comparisons are made between them and also comments were made on the major security issues related to public-key enhancements introduced to the Kerberos Authentication Protocol trust model. Here the authors have given brief introduction to Kerberos and, public-key cryptography is provided for those unfamiliar with these security systems.
The Kerberos Authentication standard (RFC1510) Protocol is extended to support public-key cryptography. The authors have explored in this paper to answer, how the kerberos works and why to use kerberos only [2]. The problem inside Kerberos protocol is addressed as follows: Assume an open distributed environment in which users at workstations wish to access services on servers distributed throughout the network. We would like the servers to be able to restrict access to authorized users and to be able to authenticate requests for services [7-10]. The paper is organized as sections including introduction about the paper, overview of the Kerberos protocol, Public key cryptography primer, Public key extensions to Kerberos, performance analysis of different protocols, and finally conclusion of the paper.
Kerberos is an authentication service developed at MIT (Massachusetts Institute of Technology), that uses symmetric key encryption techniques and a key distribution centre; it is an add-system that can be used with existing network. Kerberos provides a means of verifying the identities of principals on an open (unprotected) network. This is accomplished without relying on authentication [3] by the host operating system, without basing trust on host address, without requiring physical security of all the hosts on the network, and under the assumption that packets travelling [3] along the network can be read, modified, and inserted at will.
Figure 1. Kerberos Overview
The working procedure of Kerberos as shown in Figure 1 is as follows:
AP_REQ : User logs on the workstation and requests service on host.
AP_REP-AS : verifies user's access right in database, creates ticket-granting-ticket and session key. Results are encrypted using key derived from the user's password.
TGS_REQ : Workstation prompts users for password and uses password to decrypt incoming message, then sends ticket and authenticator that contains user's name, network address, and time to TGS.
TGS_REP, TGS : decrypts ticket and authenticator verifies request, then creates ticket for requested server.
APP_REQ : Workstation sends ticket and authenticator to server.
APP_REP : Server verifies that ticket and authenticator match, then grants access to service. If mutual authentication is required, server returns an authenticator.
Kerberos performs authentication under these conditions as a trusted third party authentication service by using conventional cryptography. It trusted in the sense that each of its clients believes Kerberos's judgement as to the identity of each of its other clients to be accurate. The problem that Kerberos addresses is this: a distributed system in which users at workstations wish to access services on servers distributed throughout the network. We would like the servers to be able to restrict access to authorized users and to be able to authenticate requests for service. In this system, the following three threats exist:
In any of these cases, an unauthorized user may be able to gain access to services of principals in a particular realm and a data that user is not authorized to access. Kerberos provides a centralized authentication server whose function is to authenticate users to servers and also servers to users. Kerberos provides the following requirements:
A private key (KR) and public key (KU) are related such that for any plaintext, x,
where DKR (Y) denotes decryption of cipher text Y with[2] KR, DKU (Y) denotes decryption of cipher text Y with KU, EKU (X) denotes encryption of plaintext X with KU, and EKR (X) denotes encryption of plaintext X with KR.
That is, data encrypted with KR can be decrypted with KU, and data encrypted with KU can only be decrypted with KR. Public key cryptographic systems use both of these two related keys to perform some type of cryptographic function. Those functions generally fall into the following three categories, (where “Alice” denotes the source system of a message intended for receiver that is destination system, “Bob”):
A message encrypted with Bob's public key can only be decrypted by Bob, with his private key.
Alice can communicate a secret key to Bob by encrypting it with Bob's public key and sending him the resulting ciphertext. Bob can then recover the secret key by decrypting Alice's message with his private key.
Alice encrypts a publicly readable message with her private key (KR). Anyone who decrypts her cipher text with her public key and obtains the original publicly available message has verified the authenticity of Alice's signature and the integrity of her message.
The security of Public Key Cryptography is entirely dependant on the secrecy of private keys (KR), and the widespread availability of their corresponding public keys (KU) in unchanged form.
There are 3 major proposals to add Public Key Cryptography to Kerberos [4]:
PKINIT describes how Public Key Cryptography can be added to Kerberos in the Initial Authentication stages. Microsoft, Cyber safe and Heimdal adopted it in their implementations of Kerberos [6]. PKINIT requires the verification of the initial request message sent by the client to the local KDC (Key Distribution Centre). Any authentication requests made by intruders masquerading as legitimate users will be denied. PKINIT also requires that the TGT (Ticket Granting Tickets) and the session key be encrypted so that the user's credentials will remain confidential. Also, PKINIT suggests the storage of the user's secret key in the KDC so as to allow the user to generate its own session key, which decreases the load on the KDC considerably.
PKCROSS is a logical extension of PKINIT. If a client wants certain services form a server, which is located remotely, then there has to be an authentication procedure, which relates the KDC of the client (Local KDC) with the KDC of the server (remote KDC). The primary reason why PKCROSS is used is to manage the Cross Realm Authentication. It simplifies the multiple realm authentications.
The user needs to request a cross realm TGT request from its Local KDC so that it can access the remote server. The messages exchanged between local and remote KDC is similar to PKINIT. Here the local KDC acts as a client. The local KDC sends a request comprising of the PKCROSS flag set to the remote KDC. The remote KDC replies with a PKCROSS ticket and trusts the local KDC to issue the remote realm TGT to its client on behalf of the remote KDC
The PKTAPP scheme is the one that looks into the performance aspects. The main aspect that can be observed from the previous two schemes is the role played by the KDC. The KDC issues all TGT and server tickets to the local KDC and also to the remote KDC. Most of the authentication transactions have to transit the KDC. This creates a performance bottleneck at the KDC. PKTAPP provides a scheme where there is only one path of communication i.e. between the client and the server. The client sends the request message that consists of the client's certificate chain and the identity of the service ticket. The server immediately responds to the request with the response signal that consists of the server's chain and the session key that is encrypted with the server's private key. The PKTAPP authentication scheme mainly reduces the number of authentication steps.
The main performance comparison is observed between the PKCROSS and PKTAPP. Closed, class-switching queuing models are used to demonstrate the quantitative performance which compares the response time performance. Close queuing networks represent each system resource with a queuing discipline and a stochastic service distribution. A multi-realm Kerberos environment is modeled to observe how the following parameters affected the throughput and response times of public key based authentication transactions:
Two assumptions were taken before all operations. Firstly, the client and KDC must present certificates for authentication. Secondly, the remote server must validate the certificate signed by the local CA (Certificate Authority) and certificate signed by the remote CA. All encryption operations are configured with 1024-bit RSA (Rivert Shamir Adelman) keys or standard DES (Data Encryption Standard).
PKCROSS and PKTAPP can be summarized that for authentication to a single application server, the number of private and public key operation for PKTAPP and PKCROSS are the same. But PKCROSS requires more secret key operations. The calibrated model performance was investigated with an increased number of application servers.
The transaction rates for both protocols were increased until the overall response time became unstable and grew rapidly. Although for client authentication with remote application servers. PKTAPP require fewer messages than PKCROSS, the cross-realm performance is better with two or more application servers in a remote realm. Under PKCROSS, the KDC remains in the saturation point regardless of the number of remote realm application servers participating in the authentication. PKTAPP suffers from sending long public-key messages and performing expensive public-key calculations for authentication with multiple application servers. PKCROSS is more efficient compared to PKTAPP[5] as it uses public key cryptography only once between local and remote key distribution centers and then it uses more efficient secret key cryptography for subsequent communication with application servers. Thus from the analysis, we can conclude that although PKTAPP is a significantly better performance choice for a single remote server, PKCROSS is significantly more stable for anything greater than two servers in the remote realm.
The three public-key based protocols we have summarized are PKINIT, PKCROSS, and PKTAPP. Each one of these three protocols add Public-Key Cryptography (PKC) support into different stages of the Kerberos cross realm framework, but they all attempt to improve Kerberos protocol scalability and security by simplifying key management and also utilizing trustworthy public-key infrastructure like X.509. PKINIT is the one in core specification to PKCROSS, and they both together couple to define a Public-Key Cryptography based authentication solution across KDC-to-KDC in Kerberos realm PKDA (Public Key based Kerberos for Distributed Authentication), which makes more fundamental changes to the Kerberos standard in an attempt to achieve greater improvements in scalability, security, and client privacy issues within the Kerberos framework. However, research by Harbitter and Menasce concluded that the complexity of public-key computations and length of its messages makes PKDA generally less efficient than the simpler PKCROSS protocol for cross-realm (KDCto- KDC) authentication. So, while PKDA may achieve better security[2] and privacy characteristics than other PKC proposals, it offers no greater improvements in scalability.
PKC enhancements to the traditional Kerberos standard incorporate a Public-Key Infrastructure (PKI) into the scope of underlying systems trusted by Kerberos. Consequently, any vulnerability in the PKI will inherently degrade the trustworthiness of Kerberos. Although no security flaws have been associated with PKINIT, PKCROSS, or PKDA specifications, nothing can be said about their reliability [2] until they have been implemented together with a PKI and applied for wide-spread public review. The difficulties associated with implementing these public-key infrastructure protocols on top of an enterprise-wide PKI make this kind of qualitative analysis the critical “nextstep” in adding public-key support to Kerberos Protocol Standard.