See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/261081172

Public-Key Cryptography Enabled Kerberos Authentication

Conference Paper · December 2011

DOI: 10.1109/DeSE.2011.16

CITATIONS READS

23 1,860

2 authors, including:

Sufyan T. Faraj Al-Janabi

University of Anbar
122 PUBLICATIONS   218 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Artificial Intelligence in Information Security View project

Towards National Cybersecurity Open Testbed View project

All content following this page was uploaded by Sufyan T. Faraj Al-Janabi on 24 December 2015.

The user has requested enhancement of the downloaded file.

 2011 Developments in E-systems Engineering

Public-Key Cryptography Enabled Kerberos

Authentication
Sufyan T. Faraj Al-Janabi and Mayada Abdul-salam Rasheed
College of Computer
University of Anbar
Ramadi, Iraq
[email protected]

Abstract—Kerberos is a trusted third party authentication Some of the authentication protocols use symmetric
protocol based on symmetric key cryptography. This paper cryptography techniques while the other uses public key
studies how Kerberos authentication standard can be extended to cryptography techniques. In the authentication protocols that
support public key cryptography. The paper aims to do this by use symmetric cryptographic techniques both the encryption
implementing the most important public-key cryptography and decryption process need the same key, so the
extension specifications to the traditional Kerberos standard communication entities need to share a secret key.
which incorporate public-key infrastructure (PKI) into the scope Authentication based on public key cryptography has an
of underlying systems trusted by Kerberos. Thus, qualitative advantage over many other authentication schemes because no
experimental measurements can be performed to study and
secret information has to be shared by the entities involved in
compare various extensions. Although public key crypto-system
requires calculations that are computationally expensive, it is
the exchange. A user (claimant) attempting to authenticate
well believed that they can eliminate some of Kerberos protocol oneself must use a private key to digitally sign a random
limitations. The public-key based protocols PKINIT, PKCROSS, number challenge issued by the verifying entity. If the verifier
and PKTAPP add public-key cryptography support at different can successfully verify the signed response using the claimant's
stages of the Kerberos framework. They all attempt to improve public key, then the claimant has been successfully
Kerberos scalability and security by simplifying key management authenticated [3].
and utilizing trustworthy public-key infrastructures Together. In recent years, some researchers have shared a belief that
The PKINIT and PKCROSS specifications define a public key
using a hybrid approach that combines both types of
based authentication solution across multi-realm Kerberos
networks. PKTAPP makes more fundamental changes to the
cryptographic systems can be beneficial. Through this
Kerberos standard in an attempt to achieve greater approach, the key management advantages of public key
improvements in scalability, security and client privacy issues. cryptography are combined with the use of symmetric key
Analysis and evaluation have been performed based on our own ciphers to encrypt the bulk of messages, leveraging the better
developed prototype implementations of PKINIT, PKCROSS, speed of the symmetric key cipher. There have been numerous
and PKTAPP. proposals to integrate public key cryptography into Kerberos.
These proposals address various concerns of Kerberos in
Keywords-authentication; Kerberos; public-key cryptography; distributed networks, for instance, security, scalability, and
PKINIT; PKCROSS; PKTAPP portability.
In 1996, Neuman et al 1993 proposed Public-Key
I. INTRODUCTION Cryptography for Initial Authentication in Kerberos (PKINIT)
Authentication is a fundamental building block for a secure [4]. Then, a group of researchers from industry collaborated in
network environment. In modern computer systems designing public-key extensions for Kerberos and published
authentication provides service to multiple users and provides their specifications in other two internet drafts. The first is a
the ability to accurately identify the user making a request. revised version of PKINIT, while the second is the Public-Key
Today, more common in computer network architecture is a Cryptography for Cross-Realm Authentication in Kerberos
distributed architecture consisting of dedicated user (PKCROSS). PKINIT represents the leading specification that
workstations (clients) and distributed or centralized servers in defines how public-key cryptography can be integrated within
this environment. Thus, we need to protect user information Kerberos. PKINIT enables the use of public key cryptography
and resources housed at the server [1]. This environment must for an initial authentication between the client and its local
provide means to ensure that a workstation can identify its KDC (Key Distribution Center). PKCROSS proposes the
users properly. A communication procedure runs between two public key extensions for KDC-to-KDC authentication [5], [6].
or more cooperative principals in this environment is called a In 1997, Sirbu and Chuang described a method for fully
protocol. Authentication protocol is a series of steps and distributed authentication using public key cryptography within
message exchanges between multiple entities in order to the Kerberos ticket framework [7]. By distributing most of the
achieve authentication objective. These protocols are usually a authentication workload away from the trusted intermediary
combination of cryptographic techniques and other means[2].

978-0-7695-4593-6/11 $26.00 © 2011 IEEE 205

209
DOI 10.1109/DeSE.2011.16
and to the communicating parties, significant enhancements to for client/server applications by using secret key cryptography
security and scalability were expected to be achieved. They [11]. Kerberos originally was built based on symmetric key
called their proposal: “Public key based Kerberos for cryptography and requires a trusted third party. Extensions to
Distributed Authentication” (PKDA). The PKDA design Kerberos can provide for the use of public key cryptography
completely avoided the centralized key distribution center in during certain phases of authentication.
the Kerberos framework through the use of public-key
cryptography for every service ticket request. Public Key The client needs to be authenticated to the resource server
Utilizing Tickets for Application Servers (PKTAPP) is an and requests a session key from the KDC. The KDC will
internet draft that proposes to implement PKDA using the generate the session key and distribute it to both entities. After
PKINIT-specified message definitions and exchanges [8]. the KDC has generated the session key, it must communicate it
to both the client and the resource server. To secure the
In 2001, Harbitter and Menascé used closed class-switching transport of the session key to a particular entity, Kerberos
queuing models to demonstrate the quantitative performance encrypts it with the master key of that entity. Thus, two
differences between PKCROSS and PKTAPP. Their work encrypted versions of the session key must be generated: One
showed that PKTAPP is more efficient for authenticating to a is encrypted with client’s master key, and the other is encrypted
single server, while PKCROSS is better if there are two or with the master key of the resource server.
more remote servers per remote realm [9].
In Kerberos terminology, the session key encrypted with
These three public-key extensions (PKINIT, PKCROSS, the resource server’s master key is known as a “ticket.” A
and PKTAPP) proposes the use of public-key cryptography Kerberos ticket provides a way to transport a Kerberos session
support at different stages of the Kerberos framework. The key securely across the network. Only the destination resource
expected improvement in Kerberos scalability and security is server decrypts it. Whenever a client and a resource server
mainly due to the simplification of key management. As this want to communicate securely using Kerberos, the process can
depends on utilizing the public-key infrastructure (PKI), any proceed as follows (see Fig. 1) [12], [13]:
vulnerability in the PKI will represent a security degradation
for the public key-enabled Kerberos. As far as the available 1- AS _request: The client enters his/her username and
literature is indicating, there are no actual security flaws password to the workstation. The client authors a request for
associated with the PKINIT, PKCROSS or PKTAPP the authentication server (AS) to issue a ticket-granting-ticket
specifications. However, it was argued that "nothing can be (TGT) for the ticket-granting server (TGS). It includes the
concluded about their reliability until they have been user name in plaintext but not the password. The client
implemented together with a PKI and applied for widespread performs a one way hash function on the entered password
public review" [10]. and this becomes the secret master key of the client. The client
sends the request to the AS.
In this work, we propose experimental prototype
implementations for the public key-enabled Kerberos. This 2-AS_Replay: When the AS receives the TGT request, it
paper reports our software implementations of PKINIT, extracts the username from the request and fetches the
PKCROSS, and PKTAPP. We believe that our work is a basic corresponding password from its internal database and
step towards performing the required qualitative analysis generates the master key of the client by hashing the
related to the deployment of these public-key extensions on top password. The AS then authors a TGT and wraps the TGT in a
of an enterprise-wide PKI. The remaining of this paper is reply message. The TGT contains a plaintext part and an
organized as follows: Section 2 introduces the required encrypted part. The AS uses a cryptographic key derived from
Kerberos background. Our prototype implementations of the the user's password to encrypt the ciphertext part of the TGT.
three public key protocols are described in Section 3. Then, Thus, only the user who knows the password can decrypt the
some experimental results and discussions are presented in
encrypted part, which also contains a cryptographic key,
Section 4. Finally, the paper is concluded in Section 5..
known as a session key. The AS sends the reply message to
the requesting client.
II. KERBEROS BACKGROUND
Kerberos is an authentication protocol that has been built to
a system that provides network wide security services. It is a
distributed authentication system that allows a client to prove
its identity to a server without sending data across the network
that might allow an attacker to subsequently impersonate that
principal. Kerberos can solve many of the security problems of
large, heterogeneous networks, including mutual authentication
between clients and servers. The basic idea behind Kerberos is
that a trusted third party (the Kerberos security server) provides
a means by which constituents of the network can trust each
other.
Kerberos was designed and implemented by Massachusetts
Institute of Technology (MIT) in mid 1980's as a solution to
the network security problems to provide strong authentication Figure 1. Kerberos overview.

210
206
3-TGS_request: The client receives the reply message, Utilizing Tickets for Application Servers (PKTAPP) [15]. In
extracts the TGT, and then decrypts the TGT encrypted part. order to do a large scale qualitative analysis for the public key-
Next, the client authors a request for a service ticket. The enabled Kerberos and compare the pros and cons in relative to
request will wrap the TGT and an encrypted structure known traditional Kerberos, we have started by developing our own
as an authenticator. The client encrypts the authenticator using software prototypes for the three public key specifications
the session key that it is extracted from the TGT. The mentioned above. The following subsections describes the
authenticator certifies the client's knowledge of the session details of the developed software prototypes.
key. The service ticket request also specifies the name of the
resource server. The client sends the service ticket request to A. PKINIT Prototype
the TGS. Public-key cryptography can be used to secure the initial
authentication procedure. The purpose of this procedure is for
4-TGS_replay: Upon receipt of the service ticket request, the the Kerberos server to securely transmit credentials (TGT and
TGS extracts the name of the server for whom the client is session key) to the client user who requested it. In PKINIT,
requesting the service ticket. Then, it authors a service ticket. public-key cryptography is used for two functions [10]:
The TGS encrypts the ciphertext part of the service ticket with
the server's secret key, so that only the server can decrypt this 1. Verifying the client’s digital signature contained in
part. Also, the TGS includes a new cryptographic key in the AS_REQ, so that to avoid requests from masquerading
ciphertext part of the service ticket called a sub-session key. intruders.
The TGS sends the response message to the client. 2. Encrypting the TGT and session key in the server
response, so that an eavesdropper cannot obtain the user's
5- APP_Request: Upon receipt of the TGS response, the client credentials.
decrypts its ciphertext part using the session key in order to
extract the sub-session key. The client also extracts the service PKINIT modifies the AS exchange but not other parts of
ticket. Then, the client authors a message for the resource the basic Kerberos protocol. The main programming steps for
server and wraps the service ticket in the message. This developing the PKINIT prototype are described by the
flowchart shown in Fig. 2.
message represents a request to the server for establishing a
new secure session with the client. The client sends the
message to the resource server. B. PKCROSS Prototype
The public-key extensions proposed in PKCROSS take
6-APP_Peplay: The resource server extracts the service ticket place only between pairs of key distribution centers. This kind
from the request, decrypts its ciphertext part, and then fetches of communication will be transparent to end-users requesting
the session key. Thus, this key becomes known at both the cross-realm tickets. The PKCROSS ticket is used to achieve
client and the server. Next, the resource server sends a positive mutual authentication between the local KDC and the remote
acknowledgement to the client. The client and resource server KDC. The messages exchanged between the two KDCs closely
can now securely communicate with each other using this follow the PKINIT specification, with the local KDC acting as
session key. the client. When the remote KDC issues a PKCROSS ticket to
the local KDC, the local KDC can in sequence issue a remote
III. IMPLEMENTED PUBLIC-KEY EXTENSIONS PROTOTYPES realm TGT to its local client on behalf of the remote KDC [10].
The basic programming steps for developing the PKCROSS
Basic Kerberos relies on conventional or symmetric prototype are described by the flowchart shown in Fig. 3.
cryptography, in which the keys used for encryption and
decryption are the same. As a result, the key must be kept C. PKTAPP Prototype
secret between the user and the KDC. If anyone else knew it,
he/she could impersonate the user to any service. Indeed, in In traditional Kerberos system, the KDC issues all TGS,
order for a user to use Kerberos at all, user must already be remote KDC, and server tickets in its realm. Thus, most
registered with a KDC. Such a requirement can be authentication transactions should transit the KDC. Therefore,
circumvented with the use of public-key cryptography, in it can become a performance bottleneck. Although secondary
which there are two separate keys, a public key and a private KDCs can be included in the system, their typical use is just as
key. These two keys are related but there is no known efficient backups in the event of a primary KDC failure. The aim of
way to derive one of them from the other. When any one of PKTAPP specification is to eliminate this potential bottleneck
them is used for encryption, the other can be used for and reduce communications traffic by enabling the
decryption [14] . authentication exchange to be directly performed between the
client and the application server.
Several Kerberos-based authentication techniques using
public-key cryptography have been proposed in the last decade. This extension was originally proposed PKDA [7]. From a
The use of public-key cryptography is to eliminate the problem message exchange perspective, PKTAPP can be more efficient
of a single point failure in a KDC, and achieve better than traditional Kerberos as the client may deal directly with
scalability. Among them, the three notable techniques are the application server. There are three messages exchange
Public Key Cryptography for initial authentication in Kerberos between the client and application server. The first message
(PKINIT), Public Key Cryptography for Cross Realm initiated by the client (the AS-REQ message) contains the
Authentication in Kerberos (PKCROSS) and Public Key client’s certificate and the identity of the service ticket

211
207
requested. Accordingly, the server responds with an AS-REP
message that contains the server’s certificate and the session
key encrypted with the server’s private key. After
authentication being achieved, the client can request an
application service ticket using a traditional Kerberos Version
5 request. Hence, the entire authentication process is reduced to
a total of two message pairs.
In PKTAPP, there is no explicit requirement for pre-
knowledge of identity between the client and the KDC or
between the two KDCs. Furthermore, there is no need to pre-
establish shared secrets or store a user records in a Kerberos
database. The only requirement for building trust between
entities is PKI certificates (e.g. X.509). However, due to the
additional processing requirements, a performance price is paid
each time a public key calculation is substituted for a
symmetric key calculation [9]. PKTAPP is assumed to improve
the distribution in two ways [7]:

Figure 3. Flowchart of the PKCROSS prototype.

1. Bypassing the initial ticket granting procedure between a

client and an AS by using a long live public key
certificate issued by Certificate Authority (CA).
2. Combining the TGS with regular server.
Fig. 4 contains a flowchart that represents the basic
programming steps used in implementing the PKTAPP
prototype.

IV. IMPLEMENTATION RESULTS AND DISCUSSION

The system prototypes have been developed using Visual
C# 2008 under Windows environment. The authentication
system simulation includes three main entities: client entity,
KDC entity, and application server entity. The client is the
entity that requests the services. The KDC entity is the one that
issues the services of tickets to the clients to enable them to get
the required service. Finally, the application server entity is the
Figure 2. Flowchart of the PKINIT prototype. one that offers a service to the client. The Authentication

212
208
system software contains several classes for representing like encrypting session keys (used by secret key cryptography)
entities interacted with each other to authenticate the client and and/or to sign messages.
provide secure communication between client and server. The
simulation considers all cases public-key extensions (PKINIT,
PKCROSS, and PKTAPP) along with the traditional Kerberos
case. In the current implementation, RSA is used as the public-
key algorithm, while symmetric encryption is performed using
AES. Furthermore, the X.509 certification is assumed to be
used with this implementation. The simulation includes the
development of a friendly GUI for all entities and public-key
extensions considered. A sample interface window for the
simulation software is shown in Fig. 5. There are several
interface and dialog windows for the client, the Kerberos
server, and the application server.
The main purpose of the building Authentication system is
to provide the Authentication. Designing the Authentication
system mostly requires combination among three basic criteria,
which are security, scalability, and performance. Scalability
enhancement represents the main advantage of public-key
extensions to Kerberos. Public key cryptography simplifies the
distribution of keys in the Kerberos environment because
secret-key cryptography requires a separate secret key to be
shared between every pair of users. Hence, for a traditional
Kerberos environment including C clients and S application
servers, the total number of shared keys which must be
maintained throughout the network is C*S session keys (shared
between communicating clients and application servers) and
C+S private keys (shared between each client or server and the
KDC). On the other hand, public key-enabled Kerberos only
requires users to share a single public key with each of their
peers. Thus, the same network of C clients and S application
servers in the latter case needs only to maintain C+S shared
(public) keys. Of course, the private keys associated with
public-key cryptography do not cause additional overhead
because they are not required to be transmitted.
Concerning the security issue, in traditional Kerberos
environment, the KDC must remember every user’s secret key.
Thus, if an unauthorized individual gains even read-only access Figure 4. Flowchart of the PKTAPP prototype.
to the KDC’s database, the security of the KDC is completely
compromised. Alternatively, as public key-enabled Kerberos
uses public keys for encrypting TGTs, read-only access into a
KDC’s database would not compromise security at all. The
only way for a attacker to violate the public key-enabled
Kerberos security is by obtaining a write access to the X.509
Certificate Authority directory. This is much more difficult
than just passively reading secret-keys in traditional Kerberos
databases.
The issue that needs more study and analysis is the issue of
performance of Kerberos and its public-key extensions in real
large-scale applications. The developed prototypes in this work
combine between the use of symmetric key cryptography and
public key cryptography. This combination provides easy way
to distribute the session key and ticket using the public key and
eliminate the use stored key used in the traditional Kerberos. In
spite that public key cryptography does not require users to
share a common key, it is much slower than secret key
cryptography. Thus, to maintain the speed advantage of secret
key cryptography, AES has been used for encrypting data.
Figure 5. Typical interface window.
Public key cryptography (RSA) has been used for application

213
209
 One of the most important measures that must be taken into [4] B. Neuman, B. Tung, J. Wray, and J. Trostle, "Public key cryptography
account is the time required to accomplish the authentication for initial authentication in Kerberos," Internet Draft, October 1996,
(ftp://ietf.org/internetdrafts/draft-ietf-cat-kerberos-pk-init-02.txt).
process, which starts and ends in client side. For our current
[5] B. Tung et al., "Public key cryptography for initial authentication in
prototype implementation, a comparison has been carried out Kerberos," March 12, 2002 (expiration),
among traditional Kerberos, PKINIT, PKCROSS, and http://www.ietf.org/internetdrafts/ draft-ietf-cat-kerberos-pk-init-16.txt.
PKTAPP. Fig. 6 shows the execution time required to perform [6] B. Tung et al., "Public key cryptography for cross-realm authentication
AS exchange, TGS exchange, and application server (AP) in Kerberos," May 8, 2002 (exp.), http://www.ietf.org/internet-
exchange for each case respectively. In PKINIT, the AS drafts/draft-ietf-cat-kerberos-pkcross-08.txt.
request takes more time than in Kerberos because the use of [7] M. Sirbu and J. Chuang, "Distributed authentication in Kerberos using
public key, public key cryptography has a heavy operation public key cryptography," In IEEE Symposium On Network and
Distributed System Security (NDSS’97), pp. 134-141, 1997.
(exponentiation) in PKCROSS AS exchange between client
and AS and communication between two KDC implements [8] A. Medvinsky et al., "Public key utilizing tickets for application servers
(PKTAPP)," 1997, http://www.ietf.org/internet-drafts/draft-ietf-cat-
using RSA both of them take time more than in traditional kerberospk-tapp-03.txt.
Kerberos, in PKTAPP the AS server request between the client [9] A. Harbitter and D. Menasce, "Perofrmance of public-key-enabled
and server is implemented using public key cryptography, no Kerberos authentication in large networks," In Proceedings of 2001
TGS request implemented so the PKTAPP has less exchange IEEE Symposium on Security and Privacy, Oakland, California, IEEE
than other extensions. Computer Society Press, 2001.
[10] I. Downard, "Public-key cryptography extensions into Kerberos," IEEE
The total time required to implement authentication in each Potentials, pp. 30-34, December 2002- January 2003.
case in our prototype system is illustrated in Fig. 7. As depicted [11] Massachusetts Institute of Technology, Kerberos: The Network
in this figure, PKCROSS takes more time than other types Authentication Protocol. http://web.mit.edu/kerberos/www/ , 2000.
because of the use of public-key cryptography in two steps. [12] J. De Clercq, Windows Server 2003 Security Infrastructures, Chapter5:
The first when the client is authenticated to the local TGS, and Kerberos, Elsevier Digital Press, 2004.
the second when local TGS is authenticated to the Remote [13] F. Khan, Lock Down J2ME Applications with Kerberos, IBM Developer
TGS. Works, Part 1: Introducing Kerberos Data Formats, October 2003.
[14] B. Tung , "The Moron's guide to Kerberos," Version 2.0, Online
Document, Last modified: 25-4-2008.
V. CONCLUSION [15] K. Xiong, "Resource optimization and security in distributed
This paper focuses on the public-key based extensions computing," Doctoral Thesis, North Carolina State University, 2007.
PKINIT, PKCROSS, and PKTAPP, which adds public-key
cryptography support at different stages of the Kerberos
framework. The resultant enhancements in both of security and
scalability are justifiable. However, there is performance
penalty to be paid due to heavy public-key operations. In
PKCROSS the local KDC of the client issues all short-lived
TGTs and all session tickets in its realm. Indeed it
communicates with a remote KDC. Hence, it can easily
become a performance bottleneck. On the other hand, PKTAPP
makes more fundamental changes to standard Kerberos. It
makes less message exchange than PKCROSS. However, the
study of performance costs needs more real life large-scale
implementations. We consider this work as a basic step
towards this aim. Indeed, our prototype implementation can be
enhanced and developed in many directions. One of them is to
consider other cryptographic algorithms (e.g. elliptic curve
cryptography or identity-based cryptography) and study their Figure 6. Message exchange time in the system.
performance and scalability consequences.

REFERENCES
[1] E. El-Emam, M. Koutb, H. Kelash, and O. Farag-Allah, "A network
authentication protocol based on Kerberos," IJCSNS International
Journal of Computer Science and Network Security, Vol.9, No.8,
August 2009.
[2] G. Schafer, Introduction to Network Security, Telecommunications
Network Group, Technische Universitat Berlin, Germany, 2005.
[3] National Institute of Standards and Technology, Entity Authentication
Using Public Key Cryptography, Federal Information Processing
Standards Publication 196, February 1997.
Figure 7. Total authentication time in the system.

214
210

View publication stats