with his (presumably secret) private key. 2) Key distribution.

Alice can communicate a secret key to Bob by encrypting it with Bobs public key and sending him the resulting ciphertext. Bob can then recover the secret key by decrypting Alices message with his private key. 3) Digital signatures . Alice encrypts a publicly readable message with her private key. Anyone who decrypts her ciphertext with her public key and obtains the original publicly available message has verified the authenticity of Alices signature and the integrity of her message. The security of public-key Table 1 Recomended key lengths for cryptography entirely depends on various secret-key and public-key algorithms the secrecy of private keys, and Secret-key Key Length Public-key Key Length the widespread availability of algorithms algorithms their corresponding public keys DES 56 bits RSA 1024 bits in unaltered form. The later issue Triple-DES 168 bits ECC 1024 bits can be addressed by using protoRijndael 256 bits Tao Renjis Finite 4152 bits cols like X.509 (ITU-T) which Automation algorithm employ trusted Certificate Source: Schneier, B. Applied Cryptography. New York: Wiley, 1996. Authorities to manage the distrib-

ow can and why should the Kerberos authentication standard (RFC1510) be extended to support public-key cryptography? These are the questions that we explore in this article. Integrating public-key cryptography (PKC) within Kerberos shares the leading edge of proposed enhancements to the traditional Kerberos standard with initiatives like IPv6 support and hardware authentication via smart-cards. The benefits of PKC will improve scalability and security throughout the Kerberos framework. Although this enhancement has not yet completed the Internet Standards Process (RFC 2026), it has already been adopted by some companies in their products. For example, CyberSafe has included it with their TrustBroker product and Microsoft has included it with their Windows 2000, XP, and .NET platforms. Heimdal, an open-source initiative, has also included it in their implementation of Kerberos. Several recent proposals have contributed novel solutions to accomplish this task, and each has its own advantages and disadvantages. But before any proposal is fully adopted, issues like performance and security must be analyzed. Actually addressing those issues in depth is beyond the scope of this paper, but the motivation to study multiple unique solutions with those issues in mind is stimulating. We begin with overviews of PKC, and then discuss what improvements PKC can offer to Kerberos. After summarizing three different protocols for public-key enhanced Kerberos, we explain the performance penalties associated with PKC and reference qualitative results from other research which compares the response-time performance of the two fundamental approaches we describe for public-key based authentication. Finally, we look at some of the security issues associated with including public-key support in the traditional Kerberos framework.

Public-key cryptography primer

Data encrypted with a private key can only be decrypted with a public key and visa versa. Public-key cryptosystems use 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 of a message intended for receiver, Bob): 1) Encryption/decryption. A message encrypted with the Bobs public key can only be deciphered by Bob,

ution of trustworthy public keys.

Kerberos
Kerberos (RFC1510) is a security system that was developed at the Massachusetts Institute of Technology in 1988. Its purpose is to provide a secure means of communication between incorporated programs and to provide a secure means of authenticating users into a network of incorporated workstations and servers. Secure authentication is the most important achievement of the Kerberos protocol. Traditionally, authentication has focused only on verifying the identities of human users (as clients) on a network. The authenticity of the servers was presumed valid. Kerberos extends the reach of guaranteed identity by also authenticating servers in the Kerberos network (a feature called mutual authentication). This assures clients that only authorized serversnot other machines possibly masquerading as legitimate serverswill be processing their requested services. Furthermore, Kerberos never needs to transmit passwords, even in encrypted form, in order to authenticate a client user. After users have been authenticated, most Kerberos implementations also offer the following features: 1) remote logins by way of the kerberized rlogin, telnet, and ftp utilities; 2) encrypted communications with the Data Encryption Standard (DES) or Triple-DES, and 3) single sign-on capabilities, so a user can access kerberized services after only logging in once These features are available on the realm of computers that have been specifically selected by an administrator to be part of a kerberized network. (Realms are described in the next section.) The Kerberos protocol illustrated in Fig. 1 starts when user, Alice, logs into a client workstation and requests a service from application server, Bob. Alice obtains permission for that service with a service-granting ticket issued from the Ticket-Granting Server (TGS). But first Alice must prove her identity to obtain a Ticket Granting Ticket (TGT) from the Authentication Server (AS). The TGT gives a user permission to request service tickets, which grant access to application servers. The messages shown in Fig. 1 are described in more detail in Box A.

Public-key cryptography extensions into Kerberos

Ian Downnard

30

0278-6648/02/$17.00 2002 IEEE

IEEE POTENTIALS

Fig. 1 Kerberos overview

AS

_R

EQ

TG S_ pe R EQ rt yp e of TG se S_ rv ic R e EP

onc
AS KDC Database

lo per

e in s

on ssi
_R EP

User (Alice)

on

ce

pe

AP

rs

_R

er

vic

EP

AS

er

eq

TGT

Service granting ticket

AP

ue

_R

st

EQ

TGS KDC Service granting ticket

Application server (Bob)

KDC = Key Distribution Center AS = Authentication Server TGS = Ticket-Granting Server AS_REQ = Authentication Service Request AS_REP = Authentication Service Response TGS_REQ = Ticket-Granting Service Request TGS_REP = Ticket-Granting Service Response AP_REQ = Application Request AP_REP = Application Reply

What are Kerberos realms?

Kerberos realms represent a networked collection of client workstations, application servers, and a single master Key Distribution Center (KDC) with the following responsibilities: 1) maintaining a database of matching user IDs and hashed passwords for registered Kerberos users, 2) maintaining shared secret keys with each registered application server, 3) maintaining shared secret keys with remote KDCs in other realms, and 4) propagating new or changed secret keys and database updates to slave KDCs. (Slave KDCs are redundant copies of the master KDC. They increase the tolerance of a Kerberos environment to faults in the master KDC.) Typically, networks of client workstations and application servers under different administrative domains fall into different Kerberos realms. Cross-realm authentication is required when a user requests a service from an application server that resides in a remote realm.

on ce

policy, an attacker must obtain write access to a public-key repository, such as a X.509 Certificate Authority directory. Public-key cryptography improves Kerberos security because actively modifying public keys in the public-key infrastructure is much more difficult
Box A

than passively reading secret-keys in traditional Kerberos databases. Scalability . Similarly, public-key cryptography simplifies the registration of new keys into the key distribution center (KDC) since public keys can be safely communicated in the clear over

How is Kerberos improved with public-key cryptography?

Improved security . Traditionally, Kerberos Authentication Servers reply to a users TGT request with a ticket encrypted by that users secret key. Therefore, the key distribution center must remember every users secret key. If an unauthorized individual gains even read-only access to the key distribution centers database, the secrecy of user keys is violated and the security of the key distribution center is compromised. Since public-key cryptography enabled Kerberos uses public keys for encrypting TGTs, read-only access into a key distribution centers database would not compromise security at all. To violate the public-key cryptography security

AS_REQ: Alice requests a TGT from the AS message format (sent in the clear if preauthentication is not used): UserID: Alice AS_REP: The AS verifies with the Key Distribution Center (KDC) database that Alice is authorized to request tickets, then (pending authorization) the AS generates and sends to Alice a session key (SAlice) encrypted with Alices secret key (KAlice), and the TGT. message format: KAlice{use SAlice with TGS}, TGT: KTGS{use SAlice with Alice} where KAlice{X} is the encryption of X with Alices secret key, SAlice is the session key shared between the KDC and Alice, and KTGS{X} is the encryption of X with the TGSs secret key. TGS_REQ: After decrypting AS_REP and recovering SAlice, Alice requests a service-grant ing ticket from the TGS, with her authenticator (which proves her identity) and her TGT. message format: Alice is requesting Bob, Authenticator: SAlice{Alice, time1}, TGT: KTGS{use SAlice with Alice} TGS_REP: After verifying Alices authenticator, the KDC sends the service-granting ticket to Alice in a message encrypted with SAlice. message format: SAlice{use SAB with Bob}, service ticket: KBob{use SAB with Alice} where SAB is the session key shared between Alice and Bob, and KBob is Bobs secret key. AP_REQ: Once Alice recovers SAB and the service ticket from TGS_REP, she encrypts her userID with SAB to prove her identity to Bob, and sends that authenticator along with the service ticket to Bob. Optionally, she can set a flag to turn on mutual authentication so the server will subsequently prove its identity to her. message format: SAB{Alice, time2}, service ticket: KBob{use SAB with Alice} mutual authentication flag: on/off AP_REP: If Alice requested mutual authentication, then Bob extracts time2 from AP_REQ and returns it to the client encrypted using SAB. message format: SAB{time2} Subsequent messages carry information relating to the service Alice requested from Bob.
Note: The convention used by Microsoft in Microsoft Tech Net. Windows 2000 Kerberos Authentication was followed for denoting message contents.

DECEMBER 2002/JANUARY 2003

31

Fig. 2 PKINIT overview

AS_REQ: contains the client's certificate and digital signature The KDC may store symmetric keys and/or public keys for each user. KDC Database

Public-key based initial authentication Client AS_REP: contains the TGT encrypted with client's public key 3. The client validates AS_REP using the KDC's public key. 4. The client decrypts AS_REP with its private key and recovers the TGT. 5. The client proceeds with standard symmetric cryptography and secret keys (per RFC1510). KDC

TGT

1. The KDC receives AS_REQ and verifies the client's digital signature. 2. The KDC encrypts the TGT using the client's public key, and transmits it in AS_REP. This message is signed by the KDC with its private key.

a remote connection to the KDC database. Preserving the privacy of secret keys while registering them in the KDC can only be satisfied with secure communication channels or manual entries made locally on the KDC. Thus, PKC improves the scalability of KDC maintenance by affording administrators the freedom of remote access without the burden of a priori security.

Performance issues
While public-key cryptography (PKC) can improve scalability and security aspects of Kerberos, it can also hurt performance. Traditionally, Kerberos has been applied on a small enough scale that performance bottlenecks at key distribution centers did not occur. But recent systems like Microsofts .NET Passport service are implementing Kerberos in very large networks with many entities participating in the authentication process. Furthermore, the computational requirements of public-key cryptography are generally higher than for secret-key cryptography for the following reasons: 1) The calculations involved during key generation and encryption and decryption routines are computationally expensive. For example, DES uses table
Fig. 3 PKCROSS overview

lookups and XOR operations whereas the public-key RSA (Rivest, Shamir, Adleman) algorithm uses exponentiation and multiplication for encryption and decryption. In fact, hardware implementations of RSA are about 1000 times slower than DES. 2) Public-key cryptography generally requires much larger keys than conventional secret-key cryptography. Table 1 shows the recommended key lengths for various secret-key and public-key algorithms (Schneier, B. Applied Cryptography 1996). For these reasons, most proposals to include PKC in Kerberos attempt to minimize the number of public-key computations that occur. For example, once a secure channel has been setup via public-key based procedures, Kerberos can continue with traditional secret-key cryptography and still reap benefits from using PKC during its initial steps.

PKINIT and PKCROSS public-key extensions

A group of researchers from various companies in industry collaborated to design public-key extensions for Kerberos. They published their specifications in the following Internet-Drafts: Public-key cryptography for Initial

Authentication in Kerberos (PKINIT) Public-key cryptography for CrossRealm Authentication in Kerberos (PKCROSS) PKINIT is the leading specification that describes how public-key cryptography can be used in Kerberos. Microsoft, CyberSafe and Heimdal have all adopted it in their implementations of Kerberos. The specification defines how public-key cryptography can be used to secure the initial authentication procedure. The purpose of this procedure is for the Kerberos server to securely transmit credentials (a Ticket Granting Ticket (TGT) and session key) to the client user who requested it. Traditionally, the Kerberos server encrypts its response with a secret key shared between the Kerberos server and the client user, but with PKINIT (Fig. 2), public-key cryptography is used for two functions: 1. verifying the clients digital signature contained in AS_REQ, so that authentication requests made by intruders masquerading as legitimate users are ignored; 2. encrypting the TGT and session key in the server response, so that eavesdroppers cannot obtain the users credentials.

1. Traditional cross-realm request for TGT to access a remote realm

2. AS_REQ with PKCROSS flag set Public-key based initial authentication Application Servers

User

4. Traditional reply with cross-realm TGT using SKC

Cross-Realm TGT

Local KDC Remote 3. AS_REP with PKCROSS ticket PKCROSS KDC encrypted using local KDC's ticket public key

Local Realm

Remote Realm

32

IEEE POTENTIALS

Fig. 4 PKDA overview

SCRETREQ Time Client SCRETREP PKTGS_REQ PKTGS_REP AP_REQ Service Ticket Server's Public Key Application Server SCRET_REQ: The client requests the application server's public-key SCRET_REP: The server replies with its public-key, signed by a trusted Certificate Authority PKTGS_REQ: The client requests a session ticket to access the application server. This message is digitally signed with the client's private key, and encrypted with the server's public-key PKTGS_REP: Ther server returns a read-only service ticket to the client AP_REQ: The client requests a service from the application server, using the traditional secret-key procedures defined in RFC1510

Unencrypted or SKC communication PKC communication

PKCROSS
The primary benefits of PKCROSS involve simplifying the administrative burden of maintaining cross-realm keys, writes B. Tung, et al. In other words, it improves the scalability of Kerberos in large multi-realm networks where many application servers may be participating in the authentication process. This protocol is summarized in Fig. 3. The public-key extensions proposed in PKCROSS take place only between pairs of key distribution centers (i.e. KDC-to-KDC authentication). They are, thus, transparent to end-users requesting cross-realm tickets. This means the messages communicated between users and their local key distribution center during cross-realm authentication can almost exactly follow RFC 1510. The PKCROSS ticket is used to achieve mutual authentication between the local key distribution center and the remote key distribution center. The messages exchanged between the two key distribution centers closely follow the PKINIT specification, with the local key distribution center acting as the client. When the remote key distribution center issues a PKCROSS ticket to the local key distribution center, it trusts the local key distribution center to issue the remote realm TGT to its local client on behalf of the remote key distribution center. In summary, PKINIT facilitates public-key based authentication between local Kerberos clients and their local key distribution center; PKCROSS extends the public-key capabilities to crossrealm KDC-to-KDC authentication. Thus, by using PKINIT and PKCROSS together, public-key based authentication can be integrated throughout the entire Kerberos framework.

Public-key based Kerberos for Distributed Authentication (PKDA)

A pair of researchers (M. Sirbu and J. Chung-I Chuang) at Carnegie Mellon University embraced and extended the PKINIT and PKCROSS protocols to create a new protocol, called Publickey based Kerberos for Distributed Authentication (PKDA). It claims to offer enhanced privacy for Kerberos clients, as well as increased scalability and security within the Kerberos framework. Client-side privacy is increased by simply moving the client identity fields from unencrypted to encrypted portions of the authentication messages. Increased scalability and security is attempted by moving authentication procedures away from centralized key distribution centers to between the individual clients and application servers on a network. Theoretically, this move should reduce bottlenecks at key distribution centers during high volumes of authentication requests (increased scalability). It also should eliminate the single point of failure a key distribution centers centralized collection of keys imposes on the Kerberos environment (improved security). In practice, requiring lengthy public-key transactions between some clients and many application servers may not be anymore efficient than using public-key based authentication once with a key distribution center and faster secret-key cryptography for subsequent encryption with application servers. The PKDA design differs from all other proposed public-key enhancements to Kerberos by completely avoiding the centralized key distribution center in the Kerberos framework. Using public-key cryptography for every service ticket request renders the symmet-

ric key maintained in the key distribution center completely unnecessary. This includes cross-realm authentication! In fact, since PKDA doesnt rely on the key distribution center for initial authentication, specialized cross realm authentication procedures are also unnecessary. (As they can be identical to those procedures within a local realm.) The five messages illustrated in Fig. 4 describe the PKDA exchanges that occur when an unauthenticated client requests a service from an application server. PKDA accomplishes mutual client/server authentication in step 3 by digitally signing PKTGS_REQ with the clients private key and encrypting it with the servers public-key. The signature can only be verified with the clients public-key. The PKTGS_REQ message can only be decrypted with the servers private key. The client is assured of the servers authenticity since only the server can decrypt the message to construct a valid response. The server is assured of the clients authenticity by verifying the digital signature with the clients public-key. The application server replies to the client in step 4 with a service ticket for the requested service. This ticket is encrypted with a key known only to the server, so the client cannot modify it. Finally, the client continues in step 5 by accessing its requested service using the service ticket and the procedures defined in the standard secret-key based Kerberos specification.

Response-time Performance Comparisons

Determining whether it is more efficient to authenticate to a central key distribution center than to individual application servers was the topic of a paper presented by Alan Harbitter and Daniel Menasc in the 2001 IEEE Symposium

DECEMBER 2002/JANUARY 2003

33

on Security and Privacy. They modeled a multi-realm Kerberos environment in order to observe how the following parameters affected the response times of public-key based authentication transactions: 1) number of realms in the Kerberos environment, 2) number of applications servers per realm, 3) loads on applications servers and key distribution centers, and 4) network delay. Even though PKDA required fewer messages than PKCROSS during client authentication with remote application servers, PKCROSS achieved better cross-realm performance results than PKDA for networks with two or more application servers in a remote realm. Since this held true over a wide range of server and network performance levels, one can conclude that PKDA suffers from sending long public-key messages and performing expensive public-key calculations for authentication with multiple application servers. PKCROSS is more efficient because it only uses public-key cryptography once between local and remote key distribution centers. It then uses more efficient secret-key cryptography for subsequent communication with application servers. Thus, PKDA will not always achieve significantly higher scalability than other public-key cryptography proposals. (Note: Actually, their experiments used PKTAPP instead of PKDA, but PKTAPP is only a slight variation on the PKDA specification. PKTAPP was originally introduced as PKDA and follows its fundamental design approach of excluding key distribution centers from authentication procedures).

PKCROSS and PKDA can provide a trustworthy public-key infrastructure without introducing a liability into the Kerberos trust model. Another concern regards the implementation of public-key specifications and public-key infrastructures. The specifications are not simple, and deploying the enterprise-wide X.509 infrastructure can be particularly difficult. These complexities increase the likelihood of unreliable implementations.

support to Kerberos.

Read more about it

Massachusetts Institute of Technology, Kerberos: The Network Authent. Protocol. <http://web.mit.edu /kerberos/www/>, 2000. Kohl, J., The Kerberos Network Authentication Service (V5) , C. Neuman, Editor. 1993, <http://www.ietf.org/rfc/rfc1510.txt> CyberSafe TrustBroker, <http://www.cybersafe.ltd.uk> PKI Enhancements in Windows XP and .NET Server, <http://www.microsoft.com/windowsxp/pro/techinfo/planning/pkiwinxp/default.asp> Tung, B., et al ., Public Key Cryptography for Initial Authentication in Kerberos, March 12, 2002 (expiration), <http://www.ietf.org/internetdrafts/draft-ietf-cat-kerberos-pk-init16.txt>, (work in progress) Tung, B., et al ., Public Key Cryptography for Cross-Realm Authentication in Kerberos , May 8, 2002 (exp.), <http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pkcross-08.txt>, (work in progress) Microsoft TechNet. Windows 2000 Kerberos Authentication . <http://www.microsoft.com/technet/pr odtechnol/windows2000serv/deploy/co nfeat/kerberos.asp>, 1999. Sirbu, M., Chung-I Chuang, J. Distributed Authentication in Kerberos Using Public Key Cryptography . Symposium on Network and Distributed System Security, 1997. San Diego, California: IEEE Computer Society Press. Harbitter, A., Menasc, D. Performance of Public-Key-Enabled Kerberos Authentication in Large Networks. 2001 IEEE Symposium on Security and Privacy Proceedings, IEEE Computer Society Press. Schneier, B. Applied Cryptography. New York: Wiley, 1996. ITU-T (formerly CCITT) Information technologyOpen Systems InterconnectionThe Directory: Authentication Framework Recommendation X.509 ISO/IEC 9594-8

Conclusion
The public-key based protocols PKINIT, PKCROSS, and PKDAadd public-key cryptography support at different stages of the Kerberos framework. However, they all attempt to improve Kerberos scalability and security by simplifying key management and utilizing trustworthy public-key infrastructures like X.509. Together, the PKINIT and PKCROSS specifications define a public-key based authentication solution across multi-realm Kerberos networks. PKDA makes more fundamental changes to the Kerberos standard in an attempt to achieve greater improvements in scalability, security and client privacy issues. However, research by Harbitter and Menasc conclude 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 (key distribution center-to-key distribution center) authentication. So, while PKDA may achieve better security and privacy characteristics than other publickey cryptography proposals, it offers no greater improvement in scalability. Public-key cryptography enhancements to the traditional Kerberos standard incorporate a public-key infrastructure into the scope of underlying systems trusted by Kerberos. Consequently, any vulnerability in the public-key infrastructure will inherently degrade the trustworthiness of Kerberos. Although no security flaws have been associated with the PKINIT, PKCROSS or PKDA specifications, nothing can be concluded about their reliability until they have been implemented together with a public-key infrastructure and applied for widespread public review. The difficulties associated with implementing these public-key protocols on top of an enterprise-wide public-key infrastructure make this kind of qualitative analysis the critical next step in adding public-key

Security issues
The largest security issue associated with incorporating public-key cryptography in Kerberos involves expanding the scope of trusted entities to include the entire public-key infrastructure (PKI). However, assuming an already secured public-key infrastructure may not always be valid. For example, weak public-key management opens a publickey cryptosystem to man-in-the-middle attacks. In this scenario, an attacker capable of modifying the traffic between two communicating users can achieve unauthorized decryption of their public-key encrypted messages. Fortunately, using the X.509 Certificate Authorities supported by PKINIT,

About the author

Ian Downard recently graduated from the University of MissouriRolla (UMR) with a Masters in Computer Engineering. Ian is currently employed at the Naval Research Laboratory and can be reached at itd@umr.edu.

34

IEEE POTENTIALS