1 Kerberos Guilin Wang School of Computer Science, University of Birmingham 1 Entity Authentication and Key Exchange In the last talk, we discussed key exchange and reviewed some concrete protocols. In particular, we notice that entity authentication is also important in key exchange. For example, the famous Diffie-Hellman protocol suffers from the man-in-the-middle (MITM) attack due to the lack of authentication components. In today s lecture, we shall see that key exchange techniques can also be employed to realize entity authentication in distributed networks. In fact, the differences between key exchange and entity authentication are not very clear sometimes so that in the literature some security solutions can be reviewed as key exchange protocols or authentication protocols. On the other hand, this may be not a surprise, since the essence of these protocols is that by using some previously distributed secrets a party can authenticate itself to the other communicating party and may further agree on a session key, which could be used for their coming secure communications. Roughly speaking, key exchange usually requires authentication. Otherwise, you are not sure with whom you agreed on a session key. However, authentication does not necessarily involve key exchange. For example, after a successful authentication a client can be authorized to enjoy a public service, where encrypted communications may be not required. 2 Kerberos What is Kerberos? In Greek mythology, Kerberos is a three-headed dog, who protects the entrance of Hades. Here, of course we do not want to talk about mythology, but we do discuss the entrance guardians of computer networks. In this context, Kerberos denotes the distributed authentication protocol developed from MIT s project Athena in 1980s . Since then Kerberos has been widely accepted in industry for distributed systems authentication. For example, Kerberos has been chosen as the authentication solution in Windows 2000, and been integrated into many versions of Unix systems. The full technical specification of Kerberos Version 5 is given by a draft Internet Standard RFC 1510 . Moreover, free source codes for different releases of Kerberos are available at the Kerberos website . 2.1 Basic Ideas The motivation of Kerberos is to provide authentication service in an open distributed environment, where users at workstations routinely want to access different services offered by a number of servers distributed over the whole network. Naturally, we would like to require that only legal users can be granted to access services to which they are authorized. In this scenario, there exist at least three threats: user identity impersonation, workstation address modification, and replay attack. Originated from the symmetric Needham-Schroeder protocol, Kerberos also employs symmetric mechanisms to realize entity authentication and key exchange. Basically, Kerberos uses two kinds of credentials: tickets and authenticators. A ticket issued by a trusted administration server shows who is granted to access a specific service, while an authenticator is
2 Kerberos: A Guest Lecture, 3 Dec used to prove the identity of a communicating client. Once valid ticket and authenticator are presented to a service server, this particular client shall be allowed to access the service or resource it requested. This mechanism is similar to the immigration procedure that enables a person to enter a foreign country. First, this person gets a visa (corresponding to the ticket in Kerberos) from the embassy of the foreign country. Here, a visa specifies who is allowed to entry this country for how many days. Then, by presenting his/her visa and passport (corresponding to the authenticator in Kerberos) to an immigration officer, this particular individual is allowed to enter the country. The security of this immigration policy relies on the difficulty of forging physical travel documents. In contrast, the security of network authentication protocols depends on proper use of cryptographic techniques, since computer network environments are quite complex. Here, for example, attackers should be prevented from impersonating legal users by forging or re-using tickets or authenticators. The framework of Kerberos can be illustrated in Figure 1 and further explained as follows. In Kerberos system, there are three kind of servers: Kerberos authentication server (AS), ticket-granting servers (TGS), and usual service servers. AS is the centralized trusted server of the whole authentication system. All clients and other servers are required to be registered with AS. In Step 1, a client first requests a long time credential, called ticket-granting ticket, from the centralized authentication server. Upon receiving this ticket from Step 2, the client can authenticate itself to a TGS in Step 3. Then, in Step 4 the TGS issues a short time credential, called service ticket, to the client. Finally, using this service ticket the client can authenticate itself to a particular service server (Step 5) and then enjoy the service it requested (Step 6). For example, once a user logs on a workstation by providing his/her identity and password, the workstation will get and store a ticket-granting ticket from AS on behalf of the user. This ticket-granting ticket could be valid in a relatively long time, such as one day. During this period, without repeatedly entering his/her password the user can access different services, such as checking s, printing files, and so on. The reason is that when the user wants to access a new service (within the same logon session), the workstation can get a particular service ticket from the TGS by using the housed ticket-granting ticket. Similarly, the service ticket can be also used for multiple times to access the same service server. In addition, the codes for getting tickets could be implemented as transparent procedures, i.e., the user may not notice that authentication is taking place at all. AS TGS 3. GTS Ticket+ Authenticator 1. Request 2. TGS Ticket 4. Server Ticket Client 5. Server Ticket+Authenticator Server 6. Service Figure 1. The Framework of Kerberos
3 10 The School of Computer Science, University of Birmingham 2.2 The Kerberos Protocol We now begin to describe the technical details of Kerberos Version 5, though in a little simplified way. The whole protocol can be divided into three procedures from the view point of a client: obtaining ticket-granting ticket, obtaining service ticket, and obtaining service, which are illustrated in Figures 2a), 2b), and 2c), respectively. The notations used here are listed in Table 1. Table 1. Notations for Kerberos O Options used to request certain flags being set in the tickets. T Times used to request different time settings in a ticket. F Flags denoting the status of a ticket and the requested options. ID The identity of an entity, including its name, realm, and perhaps network address. ID c, ID tgs, ID s denotes the identities of a client C, a TGS and a server S, respectively. E A publicly known symmetric encryption algorithm, e.g., AES. K c A secret key derived from the client s password, which is shared with the authentication server (AS). K tgs A secret key shared between AS and TGS. K s A secret key shared between TGS and the server S. K 1, K 2, K 3 Three session keys. N 1, N 2 Two nonces generated by the client. Tiket tgs Ticket-granting ticket. Tiket s Service-granting ticket. A 1, A 2 Two authenticators generated by the client. T S 1, T S 2 Two timestamps generated by the client. In Kerberos, it is assumed that all users are registered with the centralized authentication server (AS) so that each user shares a password with AS. At the same time, we also require that each TGS and service server S should be registered with AS so that secret keys K tgs and K s are shared between AS and a TGS, a TGS and a server S, respectively. Notice that Kerberos is very convenient for users, since to enjoy different possible services each user only needs to remember one single password. To obtain a ticket-granting ticket, in Step 1 the client first sends its request message flow, which includes the client s identity ID c, the TGS s identity ID tgs, a nonce N 1, Options O, and Times T. More specifically, O is used to request certain flags being set in the tickets, while T is used to request different time settings in a ticket, i.e., determining the lifetime of a ticket. Then, in Step 2 AS returns the client a ticket-granting ticket Ticket tgs, which is the encryption of (F, K 1, ID c, T ) under key K tgs. Here, F denotes Flags showing the status of a ticket and the requested options, and K 1 is a session key. At the same time, AS also delivers encryption block E Kc (K 1, T, N 1, ID tgs ) to the client, where K c is a key derived from the client s password. Once receiving this block, the client can use its password to compute K c and then get the same key K 1. It is this session key K 1 that enables the client to authenticate itself to the TGS server. 1. O, ID c, ID tgs, T, N 1 Client AS 2. O, ID c, E Kc (K 1, T, N 1, ID tgs), Ticket tgs = E Ktgs (F, K 1, ID c, T ) Figure 2a). Kerberos: Obtaining ticket-granting ticket.
4 Kerberos: A Guest Lecture, 3 Dec To request a server ticket, in Step 3 the client authenticates itself to the TGS server by presenting Ticket tgs and an authenticator A 1 = E K1 (ID c, T S 1 ), which is created by using K 1. Then, the TGS server first decrypts K 1 and related information from Ticket tgs, and then uses K 1 to decrypt A 1. If the result is the concatenation of ID c and a recent timestamp T S 1, TGS accepts Ticket tgs and A 1 as a matching pair and then issues a service ticket Ticket s for the client in Step 4, together with an encryption block E K1 (K 2, T, N 2, ID s ). Ticket s = E Ks (F, K 2, ID c, T ) is created in a similar way as for Ticket tgs, where K 2 is a session key that allows the client to authenticate itself to the particular server S it wants to access. 3. O, ID s, T, N 2, Ticket tgs, A 1 = E K1 (ID c, T S 1) Client TGS 4. ID c, E K1 (K 2, T, N 2, ID s), Ticket s = E Ks (F, K 2, ID c, T ) Figure 2b). Kerberos: Obtaining service-granting ticket. To obtain the specific service, the client first decrypts K 2 from E K1 (K 2, T, N 2, ID s ) by using K 1, and then in Step 5 authenticates itself to the service server S by presenting Ticket s and an authenticator A 2, created by using K 2 as did in Step 3. If Ticket s and A 2 mach each other, the server S can authenticate itself to the client and transport a session key K 3. Finally, the client can enjoy a secure service from the service server S by using session key K 3. Client 5. O, Ticket s, A 2 = E K2 (ID c, T S 2) Server 6. E K2 (T S 2, K 3) Figure 2c). Kerberos: Obtaining service. In Microsoft s implementation  of Kerberos, each Windows domain corresponds to a Kerberos realm, while domain controller is the counterpart of Kerberos authentication server. Based on the result of authentication, Windows can enforce access control decisions. For a more detailed description and discussion on Kerberos, please refer to Stallings book , where some hypothetical dialogues are provided to explain why so many different elements are employed to build up the protocol. 2.3 Limitations of Kerberos Kerberos is an elaborate authentication protocol for distributed networks with a reasonable basic assumption, i.e., each user only needs to memorize a password. However, Kereros also has some limitations. Single Failure Problem: If the authentication server, the pivotal centre of the whole system, is down, then no user can access any network resources. This implies that Kerberos is prone to suffer denial-of-service (DoS) attacks. Naturally, one could introduce back-up or even distributed authentication servers, but maintaining such a system is not easy. Limited Scalability: Since the computing ability of the authentication server is limited, Kerberos is usually suitable for an organization (such as a university) with hundreds of thousands users. But it is not a feasible authentication solution for a super large network like the Internet, where PKIs with digital certificates are definitely preferable. Off-line Password Attacks: It is easy to see that Kerberos is vulnerable to off-line password attacks, since the protocol delivers a message which is encrypted with a key derived from the client s password.
5 12 The School of Computer Science, University of Birmingham Clock Synchronization: In Kereros, servers need to check the freshness of timestamps provided by the clients. Therefore synchronous clocks are quite important throughout the whole system. Since absolute clock synchronization is impossible, how to define a reasonable clock skew is not a trivial task. Too short clock skew may result to reject a lot of legal authentication requests, while too big clock skew can be vulnerable to replay attacks easily. In addition, Yu et al. pointed out some interesting security flaws in Kerberos Version 4, though this version is not supposed to be used in real systems anymore . 3 Summary In this handout, we briefly reviewed a practice-oriented authentication protocol: Kerberos, where symmetric techniques are exclusively and skillfully used. In particular, we illustrated the basic ideas and technical mechanisms of Kerberos. In addition, we also simply addressed the relation between entity authentication and key exchange. References 1. Keith Brown. Programming Windows Security. Addison-Wesley, Kerberos: The Network Authentication Protocol. 3. J. Kohl, C. Neuman, The Kerberos Network Authentication Service (V5). Internet proposed standard RFC 1510, September William Stallings. Cryptography and Network Security: Principles and Practice, 2nd Edition, Chapter 11: Authentication Applications. Prentice Hal International, Inc., Tom Yu, Sam Hartman, and Ken Raeburn. The Perils of Unauthenticated Encryption: Kerberos Version 4. In: Proceedings of the Network and Distributed Systems Security Symposium. The Internet Society, February