Kerberos Authentication System â A Public Key Extension

POSTER PAPER International Journal of Recent Trends in Engineering, Vol. 1, No. 2, May 2009

Kerberos Authentication System – A Public Key Extension Mr. S. K. Pathan1, Mr. S. N. Deshmukh2, Dr. R. R. Deshmukh3 1. Smt. Kashibai Navale College of Engineering, Pune , India Email: [email protected] 2. Dr. BAM University, Aurangabad, India Email: [email protected] 3. Dr. BAM University, Aurangabad, India Email: [email protected] Abstract - Kerberos has become a mature, reliable, secure network authentication protocol. Kerberos is based on secret key encryption technology. It is the native network authentication protocol in the Microsoft Windows 2000 operating system and may be a candidate for use as a general-purpose authentication protocol for large user communities on the Internet. Several proposals have been developed that add public key cryptography to various stages of Kerberos to make the protocol work with large user communities and Public Key Infrastructures. But the computational requirements of public key cryptography are higher than those of secret key cryptography. As a result, the substitution of public key encryption algorithms for secret key algorithms impacts performance. As main disadvantage of Secret cryptography is that key is transferred over open system In this paper we provide alternative approach as Public crypto system in which private key is not shared

second phase, the client sends a TGS-REQ with the TGT from phase 1 to the TGS, which responds with a servicegranting ticket (SGT) in the TGS-REP. In the final phase, the SGT is presented to the application server, which then grants the service.

Index Terms—Authentication server, Ticket granting server, Key distribution center, Secure socket layer protocol.

I. INTRODUCTION Figure 1: The Kerberos protocol.

Kerberos is a distributed, identity-based authentication system that provides a method for a user to gain access to an application server. Kerberos allows a user to authenticate once and then connect to servers within the realm of the Kerberos network, without authenticating again for a period of time. Kerberos is time-tested and widely used. Version 5 was standardized over a decade ago [1], and is in use by many enterprises today. It is used in business, government, military, and educational institutions, including those that use Microsoft Windows Server as a domain controller [2]. The Kerberos server consists of an Authentication Server (AS) and a TicketGranting Server (TGS). The AS and TGS are responsible for creating and issuing tickets to the clients upon request. The AS and TGS usually run on the same computer, and are collectively known as the Key Distribution Center (KDC). The Kerberos authentication process works in three phases as shown in Figure 1. In the first phase, the client sends an AS-REQ with the user name to the AS, which responds with an AS-REP that includes a ticket-granting ticket (TGT) and a session key. The session key can only be unlocked by the user’s password, and is required for the second phase. In the

Users and servers have names called principals [3]. Server principals are composed of a primary name, instance, and a realm, written as name / instance@REALM. Client principals, e.g., name@REALM, do not have an instance.A Kerberos server (KDC) must maintain several secret keys. A single key, Ktgs, is used to encrypt the TGT returned in step 1b (see Figure 1). Several keys, Kcx, one for each client, are used to encrypt the session key, also returned in step 1b. Finally, several keys, Kvx, one for each server, are used to encrypt the SGT returned in step 2b. When the AS and TGS are combined, Ktgs can be stored in a private database used only by the KDC. The client keys, Kcx can also be stored in the private database, because only the AS needs direct access to them (clients derive the key from their password). However, the server keys must be shared between the Kerberos server and application servers. For example, an ftp daemon service will need access to the ftp/fqdn@REALM key so that it can decrypt the SGT sent in step 3a, encrypted by the TGS in step 2b. In Heimdal and MIT Kerberos, popular opensource implementations of Kerberos, shared keys are

15 © 2009 ACADEMY PUBLISHER


stored in a keytab file called krb5.keytab, which has strict permissions for read/write access to the admin (root) user only. A credential cache on a client machine stores tickets obtained by a user, such as the TGT and SGTs. Each credential includes a client principal, server principal, encrypted ticket (opaque to the user) and a session key that matches the session key hidden inside the ticket. The credential cache must be secured to prevent impersonation. Heimdal Kerberos secures credentials by storing them in a temporary file, /tmp/krb5cc $UID, which has read/write permissions only for the user who obtained the credential. Other implementations, e.g., Microsoft’s, store credentials in memory for greater security.

Key revocation must be accomplished either by sending revocation certificates to all relevant servers or by having a centralized, available "Revocation Server" against which all certificates would be compared. This removes one of the key benefits of SSL - its independence from trusted third parties. Certificates sit on a users hard drive (even if they are encrypted) where they are subject to being cracked. Uses patented material, so the service is not free. Netscape has a profit motive in wide acceptance of the standard.

II. LIMITATIONS Conventional Kerberos fails to operate as an open system because every user must be known a priori. A shared secret between the AS and the user (a password derived key) must be maintained by the AS, and each user has a 1-to-1 mapping with a principal name. Most Kerberos extensions are not designed to make Kerberos operate as an open system. Extensions such as PKINIT [4] and other public-key extensions extend credential management to third parties (trusted CAS), but the third parties usually cooperate directly with the Kerberos administrator in creating certificates with principal names that exist in the Kerberos database. Our goal is to extend Kerberos to be an open authentication system, but modifying Kerberos for each new authentication type is burdensome. Traditionally, new authentication types go through an approval process by the standardizing committee. Once defined, extensions are often rigid and cannot be updated without being reapproved and assigned new pre-auth type numbers. PKINIT has undergone this process.

Kerberos has always been open source and freely available. Kerberos is open source and platform independent, It can be used on Unix, Windows, Macintosh, and AFS.

Internet drafts exist for three alternatives: (1) Public Key Cryptography for Initial Authentication in Kerberos [5] (2) Public Key Cryptography for Cross- Realm Authentication in Kerberos (PKCROSS) [6] (3) Public Key Utilizing Tickets for Application Servers (PKTAPP) [7]. PKINIT is the core specification. Both PKCROSS and PKTAPP use variations of PKINIT message types and data structures to apply public key cryptography to different Kerberos authentication steps. PKINIT. The PKINIT Internet draft specifies that considerable message content must be added to the initial Kerberos Version 5 exchanges to replace the user secret key authentication with public key authentication. Figure 2 illustrates the flow of the PKINIT protocol. The client must send a public key certificate and a chain of certificates (“userCert” in the PKINIT specification) to establish trust between the user and the KDC and relay the user’s public key. The client must also send an authenticating data structure (“SignedAuthPack”) signed with the client’s private key. This information is included in the Kerberos pre-authentication fields-defined in the specification to support extensions to the protocol. The KDC verifies the client’s identity by verifying the digital signature in the SignedAuthPack. The KDC replies to the client with a chain of certificates for the KDC’s public key (“kdccert”), the KDC’s digital signature (“SignedReplyKeyPack”), and the session key

Kerberos' main competition is SSL, an authentication technology developed by Netscape which uses certificates issued by Verisign to vouch for the client's identity. The two are really suited for different purposes. It is a worthwhile exercise, however, to compare the two. Table 1. Comparison of Kerberos and SSL

Kerberos Uses private key encryption Relies on a trusted third party (synchronous) Ideal for networked environments where all services and users are known in advance. However, authentication and ticket granting services become a bottleneck as network requests increase. (This is


Passwords reside in users' minds where they are usually not subject to secret attack.

IV. IMPLEMENTATION

III. KERBEROS VERSUS SSL

SSL Uses public key encryption Is certificate based (asynchronous) Ideal for secure communications with a large, variable user base that is not known in advance

known as cross realm authentication.) Key revocation can be accomplished by disabling a user at the Key Distribution Center. Once again, the extent of an attack is limited to the remaining time on any outstanding tickets.


access to a server in a remote realm. Its local KDC initiates a PKCROSS transaction with the appropriate remote KDC. With a few minor variations, the KDC-toKDC authentication is performed using the PKINIT protocol. One variation is that the remote KDC is responsible for generating a “special symmetric key it uses for PKCROSS requests” [8]. The local KDC can skip the has an active, valid TGT sealed with a special symmetric key. Once the client possesses a remote TGT, it may request additional service tickets in the remote realm without involving the local KDC. PKTAPP. In Kerberos, the KDC issues all TGS, remote KDC, and server tickets in its realm. Since most authentication transactions have to transit the KDC, it can become a performance bottleneck. Although secondary KDCs can be included in the system, they are typically used as backups in the event of a primary KDC failure. The PKTAPP Internet draft seeks to eliminate this potential bottleneck and reduce communications traffic by implementing the authentication exchange directly between the client and the application server. This variation was originally introduced as the Publickeybased Kerberos for Distributed Authentication (PKDA). PKTAPP proposes to implement PKDA using the PKINIT-specified message definitions and exchanges. PKTAPP is a more efficient protocol than traditional Kerberos from a message exchange perspective. The client may deal directly with the application server

(“encTmpKeyPack”) encrypted with the client’s public key. The client can confirm KDC identity by verifying its digital signature.

Figure 2. PKINIT transaction flow

Mandatory variations allow the substitution of a certificate serial number for the certificate chain (assuming that the KDC already has a trusted copy of the user’s certificate) and the use of Diffe-Hellman to establish a session key. PKINIT drafts have included several interesting options such as storing the user’s private key on the KDC and allowing the user to generate the session key. Allowing the user to generate the session key would reduce load on the KDC and potentially change scaling characteristics. PKCROSS. While PKINIT addresses the issue of managing secret keys for a large number of clients, it does not address the issue of key management among a large number of realms. A logical extension of PKINIT is the use of public key encryption for multiple-realm, KDC-to-KDC authentications. This is the subject of the PKCROSS Internet draft specification. Figure 3 illustrates a possible flow for PKCROSS authentication.

V. SOFTWARE SKELETON The primary purpose of the skeleton software on the client is to issue requests, quickly confirm the validity of the response, and timestamp the transaction to report response time statistics. The client side processing has been simplified to focus on the shared resources: KDCs and Application Servers.

Figure 3 . The PKCROSS transaction flow

PKCROSS picks up the multiple realm authentication at the point at which the client has already obtained a TGT. The client may or may not have authenticated to its local KDC using PKINIT (Figure 3 shows a secret-keybased TGT request). Assume that the client has requested

Figure 4. The PK-enabled Kerberos skeleton software architecture



[4] Computer Emergency Response Team, Ongoing network monitoring attacks, CERT Advisory CA-94:01,F eb. 3, 2004. [5] CyberSAFE Corporation. Deploying Kerberos for large organizations. Technical Report 94-47. CyberSAFE Corporation, 2443 152 and Avenue NE, Redmond WA 98052 USA; [email protected]. [6] D. E. Denning and G. M. Sacco, Timestamps in key distribution protocols, Commun. of the ACM. vol. 24, no. 8. pp. 533-536,A ug. 1981. [7] W Diffleand M. E. Hellman. New directions in cryptography.lEEE Trans. on Info. Theory, vol. 22, no. 6, pp. 644-654, Nov. 2001. [8] B. Jarpan, Kerberos users'frequentlyasked questions, periodically posted to Usenet newsgroup comp.protoco1s.kerberos. April 2004.

The client process will loop through many transactions for the purpose of reporting average response time statistics A single process runs on the local KDC to accept client requests in UDP datagrams and crossauthenticate with the remote KDC using PKINIT. Two processes run on the remote KDC: one waits for standard Kerberos requests arriving as UDP datagrams, and the other opens a TCP listening socket and waits for PKINIT transactions. All KDC and Application Server processes are multi-threaded-when they receive a message, they . dispatch a thread to process and respond to the request. In the final step of the transaction, the client authenticates to the Application Server using a ticket received from the remote KDC. In the PKTAPP transaction, the client process has the same role and interacts with two server processes. It conducts, a PICINIT exchange over a TCP connection to a mu1tithreaded process and' obtains a sewice ricker. The client completes. the authentication by sending a UDP' datagram (a, Kerberos Version' 5; APREQ message)' KO a multi-threaded process running on the same' physical server VI. CONCLUSION Authentication is critical for the security Computer systems. Without knowledge of a principal requesting an operation, it is difficult to decide whether the operation should be allowed. Traditional authentication methods are not suitable for use in computer networks where attackers monitor network traffic to intercept passwords. The use of strong authentication methods that do not disclose passwords is imperative. The Kerberos authentication system is well suited for authentication of users in such environments. 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 publickey infrastructure make this kind of qualitative analysis the critical “next step” in adding public-key support to Kerberos. References [1] M. BellovinandM. Merritt, Limitations of the Kerberos authentication system, Computer Commun. Rev., vol. 20, no. 5, pp. 1 19-1 32, Oct. 1994. [2] G. A. Champine, D. E. Geer, Jr.. and William N. Ruh. Project Athena as a distributed computer system, IEEE Computer, vol. 23, no. 9, pp. 40-51,S ept. 2003. [3] S. Chokhani. Toward a national public key infrastructure. IEEE Commun. Mag.in this issue.


Kerberos Authentication System â A Public Key Extension - CiteSeerX

Kerberos Authentication System â A Public Key Extension - CiteSeerX

Suggest Documents