Authentication in Network Systems using the Kerberos Framework

Authentication in Network Systems using the Kerberos Framework Punit Agrawal Masters in Computer Science Washington State University Pullman, WA Abstract

Authentication is the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the subject are true. Humans have this ability, by birth. Our senses allow us to percieve patterns in our surroundings and distinguish or authenticate people, that we know. Computers lack these senses and hence have to device other ways for authentication. The most common approach has been the use of passwords or a shared-secret. There are several problems associated with the use of passwords. We, as humans, are not very good at remembering long, complex, alphanumeric string of characters and end up using simple dictionary-based words or some personal information as passwords, which makes me easy for an attacker to guess/crack the password.

Another reason is that the password needs to be sent over the network. If the password is sent as plaintext, then anyone eavesdropping the network can get hold of the password. Some systems encrypt the password before sending it, but the encryption is not really secure. Kerberos is a authentication framework developed at the Massachusetts Institute of Technology (MIT) as part of Project Athena in the 1980s and can provide a possible solution to these two issues. Firstly, it reduces the number of passwords to be used from n passowrds for n-network services to one. Secondly, it never sends the password over the network and uses secure encrption and message integrity combined with timestamp information to send other sensitive data, so as to minimize the threat of eavesdropping and Manin-the-middle attacks. This paper specifically discusses the V4 Kerberos framework in a distributed network environment and gives an indepth explanation of how it provides a secure computing environment.

Introduction This paper gives an overview of the Kerberos authentication framework developed at MIT by Miller and Nueman [3]. Section 1 starts with describing the need of a robust authentication service specifically in an open networking environment[5]. Section 2 describes the version 4 of the Kerberos framework, discussing the entities involved and how mutual authentication is provided. Section 3 deals with the problems with version 4 and how these are resolved in version 5 of the framework are discussed in the next section.

Finally, Section 5 details some of the systems which have been kerberized.

1

The need for Kerberos

In the last decade, with the advent and rise of distributed systems, The use of networked system resources has become trite in most organizations. The motivation has been to reduce the expenditure on hardware resources as well as promote a thin-client environment by the use of shared processing power.

However, the more the systems become distributed, the more complex the security related issues become.

Specifically, access to the shared and networked resources need to be restricted to only authorized and eligible users. In a personal computing environment, this can be done easily by introducing authentication mechanisms in the operating layer. The administrator can be sure of the fact that the computer resources will be used by only a single user. Hence in this case, one-time authentication at the time of login is good enough. However, in a distributed network, requests for services such as a networked printer service may come from any computer connected to the network.

Before the resource can be granted, proper authentication needs to be done whether the application which requested the service, is in fact the actual requester

and also the request has not been tampered with. Authentication in such a system can be provided in two ways. Either the resource can trust the host system from where the request comes or the service can authenticate each and every request it recieves on its own. The first approach is discouraged since in a networked environment, wire-tapping and fabrication of requests is trivial. The second approach, however requires the user to provide its authentication information, everytime it wants to use the service. A typical user may end up using a networked service such as Mail more than 20 times a day. Each time the authentication information travels over the network which makes it susceptible to an attacker. Kerberos can help in this case by providing a one-time authentication model. When a user first logins into her/his system, a one-time authentication is done and this is enough to prove his/her identity for all the networked services. This is done by the use of authentication servers on which the actual security of the Kerberos framework depends.

2

Kerberos

The Kerberos authentication is based in part on the Needham and Schroeder Symmetric Key authentication protocol, which aims to establish a session key between two parties on a network to protect further communication.

In Kerberos, all the communicating parties use single-DES keys as the symmetric keys [6]. The various abbreviations used in the figures are as follows:

C: Client workstation on which the end-user does login for the first time. addr: IP address of client workstation timex : timestamp at x when the ticket is issued lifetime: time after which the ticket will expire TGS: ticket-granting server ticketx : ticket-for entity x authx : authenticator that extablishes the identity of entity x Kx : private key of x Kx ,y : short-term session key between x and y E[abc,Kx ]: abc encrypted in x’s key KDC: Key Distribution Center IDx : Service Id of the service x The Kerberos authentication establishes the identity of the client using multiple messages.

Figure 1: Initial TGS Ticket Allocation

2.1

Initial TGS Ticket Allocation

When a client first does a login into his/her workstation, the kinit program is executed which does the job of initial ticket exchange between the client and the Key Distribution Center (KDC). This initial exchange consists of two messages. The first message is sent by the client and it includes the Id of the client usually the userid IDC , the Id of the Ticket Granting Server IDTGS and the timestamp timeC at the client side. This message is encrypted using the key KC which is generated dynamically using the password entered by the user. This is illustrated in Figure 1. The KDC has secure and exclusive access to a database where all the keys shared between each Client and Ticket Granting Server(TGS) are stored. It also access to the password of each Client so that it can generate the key Kc .

When the KDC recieves the first message, it decrypts it again using the key KC and subsequently identifies the client. It then prepares a ticket which contains the Client Id IDC , the address of the workstation addrC , the session key KC,TGS and the timestamp timeKDC along with the lifetime of the ticket and is encrypted using the key KTGS which is shared between the KDC and the TGS. Since the key KTGS is known only by the KDC and TGS, modification of the ticket contents is not possible. This ticket is sent as part of the second message from the KDC to the client, and this message also includes the session key KC,TGS , the TGS Id IDTGS and the timestamp timeKDC and the lifetime. This second message is encrypted again using the key KC so that only the client can decrypt the message.

2.2

Obtaining a Service Ticket

The TGS is usually colocated with the KDC and has access to the same database as KDC. TGS was introduced to avoid the need of sending the secret key KC each time a service needs to be used. After decrypting the second message, the client caches the ticket ticketTGS and this cached ticket is used for subsequent service requests. The third message is sent

Figure 3: Obtaining the Service

Figure 2: Obtaining a Service Ticket

2.3 from the client to the TGS and it contains the Id of the desired serviceV , the cached ticket ticketTGS and an authenticator. The authenticator is a message that establishes the identity of the client and also the fact that the client knows a particulat key. In this case, the authenticator contains the Id of the client IDC , the workstation address addrC and timestamp timeC and is encrypted using the key KC,TGS obtained by decrypting the second message. After recieving the third message, the TGS decrypts it using its shared key with the KDC and extracts the client Id and workstation address from it. To verify these, the TGS decrypts the recieved authenticator using the key KC,TGS and checks the values. The timestamp information is also checked to make sure the ticket has not expired. If the verification of authentication succeeds, then it proves the identity of the client. This is because it means that the client knows the key KC,TGS which it could have obtained only through the KDC by successfully decrpyting the second message. The second message was encrpted using the key KC so it implies that the client knows this key and thereby knows the secret password.

The TGS then prepares a ticketV which contains the Client Id IDC , the address of the workstation addrC , the session key KC,V and the timestamp timeTGS and is encrypted using the key KV which is shared between the server and the KDC. Since the key KV is known only by the KDC and TGS, modification of the ticket contents by others is not possible. This ticket is sent as part of the forth message from the TGS to the client, and this message also includes the session key KC,V , the service Id IDV and the timestamp timeTGS . This message is encrypted again using the key KC,TGS so that only the client can decrypt the message. This message serves to authenticate the TGS to the client since it proves that the server knows the session key KC,TGS and the only way to know this to decypt the ticket ticketTGS . Since the ticket can be decrpted only by a genuine TGS since only that entity and the KDC know the key KTGS , the client can be sure that the TGS he is communicating with, is genuine.

Obtaining the Service

To obtain a service, the client sends a message to the server which contains the ticketV which was received in the fourth messsage and a freshly–generated authenticator. This authenticator contains the same info as the one generated for the third message.

However, this time, the authenticator is encrypted with the key kC,V . When the server receives the message, it checks whether the identity of the client in ticketV and the authenticator authC match. If they match, the identity of the client is established. This is because it means that the client knows the key KC,V which it could have obtained only through the KDC by successfully decrpyting the fourth message. From the server’s perspective, the client has been authenticated. However, for the Client to be sure that it is interacting with a genuine Server, the server sends back a reply message which includes the incremented client timestamp timeC encrypted using the key KC,V .

On receipt of the message, the client verifies that it matches with the one it sent. If it does, then it implies that the server knows the key KC,V and since the only way for the server to know this is through the TGS, it confirms the authenticity of the server.

Thus as a result of six messages transferred between the client, the TGS, the KDC and the server, mutual authentication between the server and the client is achieved.

2.4

Subsequent Service Requests

After the client sucessfully logins into his/her system, he/she can start using the network services without providing the password each time. This is possible because the ticketTGS received in the second message is cached by the system and is used for subsequent service requests. This also implies that the KDC need not be contacted each time, since the commumnication proceeds with the TGS directly. As and when the the client logs out of his/her system, the stored

tickets are destroyed so that they cannot be used by an attacker to do a replay attack.

3

Shortcomings of Kerberos V4

The various shortcomings of the version 4 of the Kerberos Framework have been discussed in detail in the article on Kerberos in the ”Distributed Open Systems” book by Frances [1] and also by Ken Raeburn in his paper[7].

We will discuss some of the important shortcomings in short here.

DES Encrption: The version 4 of the framwework uses the Data Encrption Standard (DES) to do the encrption of messages between the communicatind entities. However, the US government laws restrict the export of the DES algorithm. Hence, the use of version 4 of the framework is not widespread.

Clock Synchroniztion: The framework takes the assumption that the clocks of the various communicating entities are synchronized closely.

For instance, if the clock of the client workstation is not synchronized with that of the server and the difference is greater than the lifetime of the ticket, then the server will treat the service request as a replay attack and deny the request.

Inter-Realm authentication: It can be fairly obvious from the discussion of the framewok above that the KDC can easily become a bottleneck in the system. To prevent this, the network is split up into realms and a KDC is setup for each realm. The KDCs in different realms work on different databases. So to access a service located in a different realm than the client’s , the client should first acquire a ticket for the home-realm TGS from its home-realm KDC. Then from the home-realm TGS, it should acquire a ticket for the remote-realm TGS in the same way as it acquires a ticket for a particular service. Finally, the client needs to contact the remote-realm TGS to get a ticket for the remote-service and then use this ticket to acquire the service from the remote server. This is illustrated in Figure 4. This pairwise communication is easy to implement, however, for N-realms, upto N(N-1) key exchanges are required, making this process highly network intensive.

Extraneous Double Encryption : As seen from the figure 1, the ticketTGS issued by the KDC is encrypted twice, once with the key kTGS and then again with the key KC . This second encryp-

Figure 4: Inter-realm authentication tion with KC is unnecessary since the key kTGS is known only to the KDC and the TGS and hence nobody else can decrypt the ticket. Double encrption not only increases the processing time, but also might introduce some errors if not used properly.

No ticket delegation: Since the ticket contains the information regarding the address of the client workstation, ticket delegation from one client to another becomes a problem and cannot be done directly using the version 4 of the framework.

Password attacks on client keys: An attacker can easily intercept the messages one and two transferred between the client and the KDC. These messages are encrypted using the key KC generated from the client’s password. Both the messages contain plaintext like the address of the client workstation which can be trivially acquired by the attacker and then using the known plaintext attack and brute-force mechanism, the attacker can try and find the client’s password.

Dependence on IP addresses : As we seen in the previous section, the ip-address of the client workstation is passed in the authenticator. This information is mandatory and cannot be omitted, which makes this version highly dependent on the use of ip-addresess and hence unsuitable for some environments.

4

Kerberos Framework - Version 5

Because of the several limitations of the version 4 of the framework as discussed above, the support for it was discontnued in 2006 following an announcement [2]. The new version 5 of the framework addresses most of the shortcomings of its predecessor and introduces some additional features.

Encryption Changes: The version 5 of the Kerberos framework includes support for multiple encryption schemes adn not just DES for

the messages. Whenever a message is encrypted, the type of algorithm used is indicated in the ciphertext so that the recipient can know which decryption scheme to use to interpret the ciphertext.

Network Addresses: The dependence on the ip-addresses is reduced by associating a type and length field with the addresses in the messages so that the recipient knows how to handle the addresses.

This allows the use of multiple network protocols to suit different kinds of network environments.

Other features that have been added in version 5 include the addition of Realm hierarchies for interrealm authentication thereby reducing the number of messages, Richer ticket functionality, Authentication forwarding and others.

5

Practical Applications

Since its introduction in 1988, the Kerberos framework has been used for authentication in a wide array of applications. Email, FTP, Network File Systems and many other applications have been kerberized since then. The benefit of using Kerberos for authentication is that its use is virtually transparent to the end user and this tranparency is vital for distributed applications. The local authentication in the OpenBSD operating system is based on Kerberos ,so is the authentication for network protocols like rlogin, rsh, telnet, etc. Secure Windowing Systems like xdm and kx use Kerberos for their authentication too. A number of authorization mechanisms based on the proxy based approach [4] suggested by Nueman, have also been under research.

6

Conclusion

As we have seen above, Kerberos has been incorporated into many different products for several reasons.

The most important reasons being the flexibility of the version 5 protocol to support different network architectures and secondly the framework by itself has very less or no inherent flaws. Recently, there has been a lot of ongoing development and the Kerberos 5 Release 1.8.3 is the current stable release. Current focus of the development is on improving the overall speed and providing transparent end-user authentication.

References [1] Frances Brazier and Dag Johansen. Distributed Open Systems. IEEE Computer Society Press, 1994.

[2] MIT Kerberos. Kerberos version 4 end of life announcement, Oct 2006.

[3] S. P. Miller, J. I. Schiller B. C. Neuman, and J. H. Saltzer. Kerberos authentication and authorization system. Technical report, M.I.T. Project Athena, Cambridge, Massachusetts, December 21, 1987.

[4] B. Clifford Neuman. Proxy-based authorization and accounting for distributed systems. In Proceedings of the 13th International Conference on Distributed Computing Systems, pages 283–291, May 1993.

[5] B. Clifford Neuman and Theodore Ts’o. Kerberos: An authentication service for computer networks.

IEEE Communications, 32(9):33–38, 1994.

[6] Sean Smith and John Marchesini. The Craft of System Security. Addison-Wesley, first edition, 2007.

[7] Tom Yua, Sam Hartman, and Ken Raeburn. The perils of unauthenticated encryption: Kerberos version 4. In Proceedings of the Network and Distributed Systems Security Symposium, February 2004. (http://web.mit.edu/tlyu/papers/krb4perilndss04.pdf).