Student Report Guidelines Title

Kerberos Prepared for DCS835 Summer 2000 Last Updated: July 15, 2000 Presented June 24, 2000

DPS Team 1 Les Beckford Joe DeCicco Than Lam Vera Rhoads Report POC: Stephen Parshley Office: 845-938-4165 E-mail: [email protected]

Abstract

This paper provides a brief introduction to Kerberos, a network authentication protocol developed and freely distributed by the Massachusetts Institute of Technology. Kerberos is designed to provide strong authentication for client/server applications by using secret- key cryptography. The purpose of the paper is twofold: 1) to give the reader a conceptual overview of the protocol to aid understanding of how Kerberos works; 2) to offer references that answer technical questions and guide further study. Contents

1. Introduction...... 1 2. Background...... 1 2.1 History...... 2 2.2 Nomenclature...... 2 2.3 Authentication Session Concept and Terms...... 4 2.4 The Authentication Process Explained...... 5 2.5 A Simplified Model of Kerberos Version 4 Authentication Process (Tanenbaum, pp. 610-12)...... 5 2.6 An Expanded Step-by Step Model of the Kerberos Authentication Process (Oppliger, pp. 31-35)...... 7 3. Technical Description...... 9 3.1 Technical specifications...... 10 3.2 Advantages...... 10 3.3 Disadvantages...... 10 4. Evaluation...... 11 4.1 Acceptance...... 11 4.2 Cost...... 11 4.3 Alternatives...... 11 5. Conclusion...... 12 6. References...... 12 6.1 Glossary of Terms (from RFC 1510 [6])...... 14 1. Introduction

Kerberos is a network authentication protocol developed by the Massachusetts Institute of Technology (MIT), and freely distributed. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. The Kerberos protocol represents an effort to address secure network communications challenges. The current de facto standard for secure communications, especially on the Internet, is Secure Sockets Layer (SSL), developed by Netscape, Inc.. Although SSL provides for secure communications between a host and unlimited anonymous clients, it has security vulnerabilities. Kerberos addresses some of those vulnerabilities. Within this paper, we present the assumptions that underlie the Kerberos protocol, how it is implemented, and some advantages of the protocol vs. SSL. We also discuss protocol limitations. Finally, we offer a substantial list of references that readers can use to obtain technical information and to aid further research. When properly implemented, Kerberos-enabled applications can communicate efficiently and securely, without suffering some of the vulnerabilities inherent in SSL. For certain environments, such as well-controlled networks, particularly LANs, with known clients, the protocol offers distinct advantages that one should consider. For answers to general questions about Kerberos implementation, refer to the frequently asked questions (FAQ) document, which offers general information about the protocol1.

2. Background

Kerberos is a product of MIT. The protocol uses a different strategy than SSL and other security protocols to secure network communications, and is therefore an appropriate alternative for users who seek security with specific protections against SSL’s vulnerabilities. The default cipher used to implement Keberos’ private, or secret-key cryptography is Data Encryption Standard (DES), though the protocol allows for other cipher algorithms. The strategy Kerberos uses relies on a trusted third-party source for authentication of network communications, thereby eliminating the need for public keys and providing rigorous control of private keys through ticket services and expiration times. A conceptual explanation of the protocol appears later in this report. Kerberos has been sufficiently successful that several commercial applications incorporate the protocol for securing network communications and remote service calls. Two examples are Microsoft Windows NT 5, and CyberSafe TrustBroker. “`Kerberized’ versions of Telnet, FTP, POP, and Sun RPC are in general use”2 According to the MIT FAQ web

1 http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html Though an unofficial source of information about Kerberos, this FAQ document offers generally accurate and current information about the Kerberos protocol. The author is Ken Hornstein. 2 Garfinkel and Spafford, page 218. See bibliographic entries for publication data. This is an excellent text with a particularly useful comparison of encryption systems in use on the Internet.

1 site, as of the date of this report, the latest specification of the protocol is referred to as Kerberos 5-1.0.63.

2.1 History

The Keberos protocol emerged during Project Athena, begun at MIT in May 1983. MIT sought to protect communications and network services within Project Athena, “a five- year research program [that] was started to explore the uses of computers in the MIT.”4 “The aim of Kerberos was to extend the notion of authentication, authorization, and accounting to the MIT computing and networking environment.”5 Based on the Needham-Schroeder protocols6, the first three versions of Kerberos were used at MIT only. Therefore, this report addresses only Kerberos versions 4 and 5, which have been discussed and implemented publicly. Version 4’s final release was in December 1992. Version 5, begun in 1989, and published in September 1993, via RFC 1510 [7], made possible an extension of the original protocols to provide enhancements and new capabilities not provided in Kerberos V4. Although KerberosV4 has good performance, and is widely installed, it works only with IP addresses. Version 5 offers extended functionality, including cross-realm authentication, proxiable tickets, and postdateable tickets topics, details of which are beyond the scope of this paper, but the concepts are readily accessible once the Kerberos implementation process is understood. The code for both versions of Kerberos is available from MIT7. Free download is available via FTP8.

2.2 Nomenclature

The Kerberos protocol is often described with varying acronyms and naming conventions, but the concepts are the same regardless of the acronyms used. For this introduction, I try to use either simple lay terms or the terms that appear in the glossary of the RFC. Within this section, I present the etymology, nomenclature, and topological information necessary to understand how Kerberos got its name, the terms used to describe authentication transactions, and the physical activity of a complete authentication session. Since much of this information is difficult to grasp without an

3 ftp://ftp.isi.edu/in-notes/rfc1510.txt for a copy of the Internet Request For Comments, RFC-1510, dated September 1993. 4 http://www-tech.mit.edu/V119/N19/history_of_athe.19f.html This web site offers a history of MIT’s Project Athena. 5 Oppliger, page 29. Chapter 2 (29-62) offers the most concise, accessible, and objective explanation of the Kerberos protocol that I have found. I highly commend it as a starting point for those interested in researching this topic further. 6 See Needham and Schroeder. “Authentication Revisited,” Operating Systems Rev. vol. 21, p. 7, Jan. 1987. 7 [email protected] is a site to obtain the latest information on versions of the protocol. 8 ftp://athena-dist.mit.edu/pub/kerberos/README.KRB5-1.0.6 to download the current version. Check the MIT site listed above if the link does not work, as version updates may invalidate this address.

2 understanding of how Kerberos works, the reader should not labor over this section; instead glean a familiarity with terms by scanning the glossary9 at the end of this paper. Refer to terms as needed when reading the topology and implementation protocols. Etymology The etymology of the word Kerberos is interesting. An aside here is worthwhile as a fun diversion from an admittedly dry topic. Kerberos is an Anglicization of Cerberus, pronounced “Ker´ ber ous.” Cerberus is the Latin name of a fearsome beast reknowned in Greek and Roman mythology. According to authors such as Horace, Hesiod, and Appollodorus, Cerberus is a multi-headed dog (most sources say three-headed) with a coat made of writhing serpents’ heads and a dragon’s tail. Cerberus guards the entrance to Hades, the underworld of the dead. Chained to the gates of Acheron, he bays woefully and preys on the dead. In Dante’s Inferno, Cerberus guards the third level of hell, reserved for gluttons. Hence, Cerberus is infamous as an insatiable flesh-eating animal. Only three characters manage their way past the terrible creature. Bybil of Cumae sates him with honey cakes, whereupon Cerberus falls to sleep. In another legend, Orpheus soothes Cerberus with his lyre. However, nobody vanquishes Cerberus until Hercules does during the last of his famous twelve labors, assigned by his cousin, King Eurystheus of Mycanea. Hercules, after crossing the river Styx, faces Cerberus, and with his bare hands, chokes the beast into submission, then drags him successfully to the world of the living. Since even the gods of Olympus fear Cerberus, Hercules’ task is truly incredible. The ominous mythological image of Cerberus is an icon of security. The name Cerberus causes one to conjure images of fierce invincibility, and connotes the impenetrable security Kerberos aims to provide. Back to MIT and the 21st century. Nomenclature See the glossary for a list of terms. A quick introduction to some of the more important terms is useful before discussing topology. Kerberos requires a minimum of three agents (principals) to perform the authentication process: a client, a ticket granting server, and a services-providing server. The ticket-granting server (TGS) is often also the physical host for the authentication service and is called the authentication server (AS). Some explanations of the protocol distinguish the AS and TGS as not only separate processes, but physically separate computers. For conceptual clarity, I will show the AS and TGS processes as independent, as though they existed on physically separate computers10. It is important to note that authentication precedes ticket granting, regardless of the physical setup. Often, the ticket-granting server will also be referred to as a key distribution center (KDC).

9 Kerberos terminology should be readily accessible to those with a fundamental grasp of networks. A few terms are defined and used outside of conventional use, but the exceptions are few and not too bothersome. 10 Though the AS and TGS processes can be run on separate computers, both require physical security and administrative management, so combining both functions on one computers is not only reasonable, but resource-efficient. See Oppliger, pp. 32-3.

3 2.3 Authentication Session Concept and Terms

Rather than continuing with a litany of terms here, I will present terms in the order and context that they occur during an authentication session. Before doing so, it is helpful to understand the elements of the Kerberos authentication process, sometimes referred to as a center-based key distribution process. A client contacts the KDC to obtain the “keys” necessary to conduct a work session with the servicing computer in the KDC-controlled network. The requirement for the client to initiate authorization results in the idea of the client “pulling” the key from the KDC. Hence, Kerberos is an example of the pull model for center-based key distribution. In other words, the client does not “push” or give a key over the network. There are no public keys in Kerberos. Keys never appear unencrypted. Pre-registration of all potential clients, and encrypted, private key transactions are the foundation of security for Kerberos. The client identifies itself to the KDC, and if registered with the KDC, receives a key, completing authentication. See Figure 111.

Figure 1. The pull-model of center-based key distribution. Note that in this diagram the KDC is serving as both the AS and TGS. 1) the client, A, first contacts the key distribution center, KDC. We will examine the authentication process between the client and KDC more closely later in this report. For now, assume the client is registered, and authorized to receive keys. The KDC ensures the client is registered by looking up the identity of the client in the list of registered possible clients. Of course, a client who is not authenticated may not receive a ticket. The KDC 2) grants a ticket, encrypted by a session key that is encrypted by the client’s password. The client, using its private key, can get the session key with which it will subsequently encode its request for service. With its ticket, the client may 3) contact server, B. The server, B, is Kerberos enabled, and will verify the credentials of client A, as it shares a private key with KDC whereby it can decrypt the client’s request and offer credentials of its own back to the client. In this way, client A, key distribution center KDC, and server B are all known to each other as authentic Kerberos principals. With such authentication complete, client A may receive services from B. All principals interact to complete the authentication activity. Although this simplified model shows three steps, there are actually six steps in the Kerberos protocol authentication process. We will now discuss those six steps to help introduce terminology. There is no need to learn all of the terms now, as we will use these terms and see the steps repeated in the following sections.

11 This figure reproduced from Figure 1.3, Oppliger, page 22.

4 2.4 The Authentication Process Explained

In the next two sections, I offer two different diagrams and descriptions of the Kerberos authentication protocol in action. Each offers insight into how the protocol works. Together, they demonstrate how the language and diagrams used to explain Kerberos vary by reference. Regardless of the terms or diagram used, the concepts are the same. 2.5 A Simplified Model of Kerberos Version 4 Authentication Process (Tanenbaum, pp. 610-12).

Author Andrew Tanenbaum gives a concise, straightforward explanation of Kerberos version 4. The following diagram, Figure 2, taken from his text, shows the essence of the three-way handshake requirement for an authentication session, to include the final request for services.

Figure 2 Tanenbaum’s explanation of the Kerberos authentication protocol.

Of course, the diagram is difficult to follow without an explanation of the terms. Unfortunately, Tanenbaum’s description is so brief that a full definition of these elements is difficult to glean from the text12. I therefore make the definitions explicit below. The terms, defined in the order used in the diagram above, are: A The client (Alice’s) identity (name), sent to the authenticating server during user login.

AS Authenticating server, with a list of registered pre-authorized potential clients.

12 The Tanenbaum diagram is in this report specifically at Professor Blum’s request. The diagram is useful conceptually, showing the three-way handshake and separation of the AS, TGS, and server. Tanenbaum’s use of terminology is rather confusing however. For example, he uses the term “session key” to refer to both the fixed key returned by the AS as well as the nonce delivered by the TGS. For an alternative presentation, see Oppliger.

5 KA Alice’s personal key, generated by use of her password. Note that the authenticating server knows Alice’s key because Alice must be a pre-registered user.

KS Session key, generated by the AS. Note that the session key is encrypted using the client’s key.

KTGS The shared key the Ticket Granting Server uses to authenticate itself to clients.

KS (t) The session key timestamp. Note that this timestamp limits the vulnerability of the system if Alice’s password is compromised and KS is intercepted for use. B The server (Bob) identity (name), requested by the client.

KAB The session key for use between the client and server. Note that the session key is a nonce, and is, as all keys, encrypted by a shared key. In this case, the shared key is the session key granted by the AS.

KB The server’s key.

Here are some helps to read the notation above.

KX = the key for principal X, or session X.

KXY = the session key for the session between X and Y.

KX (F, G) = a ticket, allowing principal F to contact principal G.

An explanation of the six steps, a bit more explicitly than appears in Tanenbaum: 1. The user, Alice, starts Kerberos software by logging in with her identity. The Kerberos software, which acts as the client, initiates a Kerberos authentication session. The client sends Alice’s identity, A, to the authentication server as clear text. 2. The authentication server verifies that the user, A, is registered as an authorized Kerberos principal, and using the client’s own key, encrypts a session key, KS, and a “ticket granting ticket,” which is also encrypted with the client’s key. The ticket granting ticket consists of the client’s identity and the session key, both of which are encrypted with the ticket granting server’s key, KTGS. Steps 1 and 2 complete login. 3. The client decrypts the message from step 2, thereby gaining the session key. The client then forwards the ticket granting ticket to the ticket granting server, along with the name of the server desired, in this case, B.

4. The ticket-granting server produces a session key for Alice and Bob, KAB, and a ticket for the client to give to Bob. Steps 3 and 4 result in Alice having a ticket for a specific server. 5. The client sends the ticket to Bob along with a time-stamped session key.

6 6. Bob replies with a time stamped session key. Steps 5 and 6 finish the authentication process. The client and server now exchange data as necessary, using their session key, KAB, to maintain data security. 2.6 An Expanded Step-by Step Model of the Kerberos Authentication Process (Oppliger, pp. 31-35)

Another way of looking at the authentication process is to examine a diagram that Oppliger offers, which appears in the following section. Oppliger’s diagram is conceptually identical to Tanenbaum’s, though Oppliger makes clearer the distinction between user and client, and offers a much more exhaustive explanation of the protocol. Below, I repeat an explanation of the protocol, this time using Oppliger’s approach. See Figure 3. Figure 3. Oppliger’s depiction of the Kerberos authentication protocol

The relationships between client, AS, TGS, and server may appear to require substantial overhead. In fact, Kerberos protocols can be implemented with good efficiency using only modest hardware. For a detailed view of the delay times produced by Kerberos implementation, see the reference for Carlson and McEachen.

The following descriptions of the steps shown in Figure 3 are closely paraphrased from Oppliger’s text:

7 Step 1. The user logs in with a username. The login client provides the AS with the username, and the AS looks up the user’s entry in the KDC database. The user’s password (or the key that is derived from this password) is then used to encrypt a ticket granting ticket, TGT. Step 2. The AS returns the encrypted TGT to the client13. Step 3. The client seeks a ticket by sending his TGT to the ticket-granting server, TGS. The client specifies the requested service so that the TGS can prepare an appropriate session key between the client and server providing the requested service. The client’s request also includes an authenticator, explained in notes following these steps. Step 4. The TGS validates the client’s request and grants a ticket for service, which includes the session key for the service. Step 5. The client sends his service ticket to the server, along with yet another authenticator. Step 6. The server returns an authenticator to the client, completing the last of the three mutual authentication handshakes: client-AS, client-TGS, client-Server14. The Kerberos authentication is complete and the service can be performed. In summary, Kerberos implements authentication transactions through a six-step process involving three-way handshaking between four principals: the client, the authentication server, the ticket-granting server, and the service-providing server. NOTE: While the following information is not essential to understand Kerberos, some additional terminology will help if one is to understand options available in Kerberos version 5. Kerberos is based on the client/server model. All of the agents involved are principals, and as such have principal identifiers that Kerberos uses during authentication messaging. “Users, clients, and instantiated network services on particular hosts are typically considered as principals [as well as the AS and TGS].”15 The principal identifier has three component fields in Kerberos V4, each a null-terminated case- sensitive text string of up to 40 characters. Kerberos V5 genericizes the component fields and allows optional fields, but retains the capitalizing convention of Kerberos realms. The three component fields in Kerberos V4 are:  A Principal name, NAME;  An instance name, INSTANCE;  A realm name, REALM.

13 Remember that “client” here refers to the process carried out by Kerberos-implementing software. The user is the human being who logs in to the client. The client acts upon input from the user to initiate the authentication process to the AS. 14 The dotted line for step 6 in Figure 3 is Oppliger’s way of showing that the client may not require the mutual authentication completed by the server responding to the client. 15 Oppliger, 31. Throughout the entire terminology section, I quote and paraphrase chapter 2, since Oppliger’s presentation is exceptionally lucid.

8 Once the client has sent its identity and specified the service requested, the AS first checks its database of principals (users, clients, and application servers) registered in the realm. The database components for each record of principal P include:  P’s principal identifier  P’s master key Kc (or P’s password if P is a user, not a computer)  An expiration date for P’s identity  The date the record was last modified  The identity of the principal who last modified the record  The maximum lifetime of tickets to be given to the principal  Some attributes  Some implementation-related data not visible externally, such as key version, master key version, and pointers to old values of the record.

The master key, KTGS, is fixed, private, always encrypted with another key, and must be kept secret. Once the authentication lookup is successful, the AS may, if it has not already received a password, request a password from the client. The client in turns prompts the user for a password and sends it back to the AS for verification. This client encrypts the user’s password, using the common secret fixed key, KTGS. Assuming the password is verified, the AS permits the TGS to process the request for a ticket.

The TGS prepares a ticket, encrypted by the fixed secret key, KTGS, which is known to the client and TGS. The ticket is comprised of the Server name, client name, client address, IP, start and end times (validation and expiration of the ticket), and a unique session key, Ks, valid for that ticket only. A fixed secret key known only to the TGS and the Server encrypts the ticket. The ticket is returned to the client. Upon completion of this step, the client is said to have credentials (the ticket authorizing access to services). Credentials consist of a ticket and the secret session key, KS.

3. Technical Description

Kerberos is a secret (private) key cryptography protocol that relies on trusted third party key-distribution services to authenticate network communications. Kerberos’ technical implementation is documented in RFC-1510 [7]. Refer to this document for technical details beyond the scope of this paper. The vast majority of details involve formatting requirements and conventions to ensure accurate communications between principals.

3.1 Technical specifications

9 Kerberos protocol messages used during authentication sessions may vary in length, but the following gives a general idea of typical size and composition of messages.  Key = 8 bytes  Ticket = 32 bytes  Authenticator = 24 bytes  Timestamp = 8 bytes  Mean message length = 125 bytes By using DES encryption and relatively short messages, the authentication activity can be completed rapidly.16

3.2 Advantages

The primary advantages of Kerberos are low cost, flexibility, open standards, key security, and automatic key revocation. The ability to timestamp tickets and produce nonce session keys minimizes significant security vulnerabilities of alternative authentication protocols. The protocol has widespread acceptance and a substantial history of public and commercial implementation. Continued innovation to make the protocol even more robust suggests long-term viability. Lastly, the protocol can be implemented on modest hardware for the AS/TGS server, and produce good performance in small networks.

3.3 Disadvantages

The primary disadvantages of Kerberos are prerequisite resource requirements, management responsibilities, and limited applicability. Unlike other protocols that allow anonymous clients, Kerberos requires advance knowledge of clients. The protocol is therefore not applicable for environments such as on-line retail web sites. Clients must be screened, authorized and pre-registered with the TGS before Kerberos-enabled sessions are requested. Secondly, security of the trusted-third-party, the Kerberos server, is assumed; if the server is compromised, authentication and session communications are potentially compromised. Managing a TGS is labor-intensive, but not unduly cumbersome for the typical environment in which one might find Kerberos deployed. The Achille’s heel of Kerberos is the physical and electronic security of the TGS and the private fixed secret key. This is why MIT recommends that the AS/TGS host computer be a dedicated host with no other services running, thereby limiting vulnerability. Of course, since user passwords provide access to secret session keys, they are, in effect, private keys, and if compromised by improper construction or disclosure, those passwords may undermine Kerberos security.

16 For a detailed discussion of queuing delays and Kerberos authentication process modeling, see Carlson and McEachen.

10 4. Evaluation

Kerberos is an effective network authentication protocol, proven in both theory and practice, with substantial implementation in public use and commercial applications. More important, its use is widespread and growing rapidly. Though one must be careful to understand prerequisite hardware requirements and management responsibilities, Kerberos offers exceptional utility for the right environments.

4.1 Acceptance

Use of Kerberos Versions 4 and 5 is widespread, as noted earlier in the report. Kerberos is not appropriate for an unlimited or unknown client population, but it is well suited to controlled networks desiring fast, secure communications without the vulnerabilities of other authentication schema. In such environments, it is widely accepted.

4.2 Cost

Kerberos costs nothing, available free from MIT, though not officially supported. Commercial software implementing the Kerberos protocol is generally inexpensive, depending on the complexity of the application. As noted earlier, there is a significant cost to fulfill the prerequisites to implement “Kerberized” software properly. The Kerberos, or authentication/ticket-granting server must be secure, configured properly, and maintained. Additionally, implementation versions of the protocol must be synchronized to ensure successful and seamless communications.

4.3 Alternatives

Competing protocols for network authentication can generally be categorized by authentication and cipher strategies. Among common strategies are password authentication, address-based authentication, and cryptographic authentication. Within the cryptographic approach, we generally see the use of keys: public-key (plus password), public-private key, symmetric-key, and private-key. Kerberos is a symmetric, private-key strategy, employing the additional benefits of center-based key distribution, and time-stamping. The Kerberos key-distribution scheme is sometimes referred to as an instance of the pull model, since the client must request a key, authenticate, and then request a service once authenticated. The following are alternative network authentication and security protocols: PGP, S/MIME, PCT, S-HTTP, SET and CyberCash, DNSSEC, IPv6, and SSH. Encryption algorithms within these schema vary,

11 but include DES, DSA, IDEA, MD5, RC2, RC4, RCZ, RSA, Diffie-Hellman, and Blowfish17.

5. Conclusion

Kerberos is an appropriate option for some network communication environments. As an alternative authentication protocol strategy, Kerberos addresses security vulnerabilities that other protocols cannot. With a proper understanding of its strengths and vulnerabilities, one can implement the protocol with confidence, at low cost, and with high efficiency18. As a publicly shared protocol, it is likely to remain useful. In summary, the Kerberos protocol is, for some environments, a superior alternative to public-key, certificate-based authentication systems, such as SSL.

6. References

1. Bryant, B., T. Ts’o, Designing an Authentication System: a Dialogue in Four Scenes. MIT, 1988, 1997. A dramatic introduction to Kerberos. Only those who love reading plays will have the patience to pore over this document, but it is as entertaining a treatment of this subject as one is likely to find. 2. Carlson, Fred R., and John McEachen, Opnet Performance Simulation of the Kerberos Protocol in a Single Ticket Granting Server (TGS) Network, presented at the Opnetwork conference, 1999. 3. Garfinkel, Simson and Gene Spafford. Web Security & Commerce, O’Reilly and Associates, Inc., 1997. For those familiar with the O’Reilly reference series, this text has a shark on the cover. Chapters 10 ff. offer excellent insights and comparisons between Kerberos and competing protocols. 4. Kerberos FAQ, http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html. A plethora of information here is handy for specific questions. 5. Kerberos Papers and Documentation, http://web.mit.edu/kerberos/www/papers.html. This web site contains a short but useful set of citations and references to information about Kerberos and related systems. It is an excellent starting point for research. Several of the references are reproduced as separate entries here.

17 See Garfinkel and Spafford, chapter 11, for a tabular comparison of encryption systems and competing authentication protocols. 18 See Carlson and McEachen. I owe a debt of thanks to Captain Fred (Randy) Carlson for his helpful comments and excellent analysis of the Kerberos protocol via OPNET modeling. His paper demonstrates the viability of the Kerberos protocol as an efficient method to implement secure service requests. Per discussion with Randy, I noted that his model does not include the queue time for the authentication server function in Step 2; however, this omission does not detract from the conclusion that Kerberos encryption overhead has minimal impact on throughput delays in small, modest networks.

12 6. Kerberos Open Sources, http://web.mit.edu/kerberos/www/index.html. 7. Kohl, John T. and B. Clifford Neuman. and Theodore Y. T'so, “The Evolution of the Kerberos Authentication System”. In Distributed Open Systems, pages 78-94. IEEE Computer Society Press, 1994. ftp://athena-dist.mit.edu/pub/kerberos/doc/krb_evol.lpt 8. Kohl, John T. and B. Clifford Neuman. The Kerberos Network Authentication Service (Version 5). Internet Request for Comments RFC-1510. September 1993. ftp://ftp.isi.edu/in-notes/rfc1510.txt. Lengthy, but full of technical details and a robust glossary. 9. Limitations of the Kerberos Authentication System, in USENIX Conference Proceedings, pp. 253--267, Winter 1991. 10. Needham & Schroeder, “Authentication Revisited,” Operating Systems Rev. vol. 21, p. 7, Jan. 1987. 11. Oppliger, Rolf, Authentication Systems for Secure Networks, Artech House, 1996. Perhaps the best single text to serve as an entrée to this topic. Chapter 2 is concise, accessible, and fairly comprehensive. 12. M. A. Sirbu, J. C-I Chuang. Distributed Authentication in Kerberos Using Public Key Cryptography, Carnegie Mellon University, Pittsburgh, PA, http://www.ini.cmu.edu/netbill/pubs/pkda.html. 13. Tanenbaum, Andrew S. Computer Networks, 3rd Ed, Prentice Hall, 1996. Tanenbaum’s coverage of Kerberos is extremely brief, and focuses on Version 4. For more comprehensive coverage, and discussion of version 5, see Oppliger. 14. Tung, B. The Moron’s Guide to Kerberos, Version 1.2.2, http://www.isi.edu/gost/brian/security/kerberos.html. 15. Tung, B. Kerberos: A Network Authentication System. Addison-Wesley, Reading, MA, 1999.

6.1 Glossary of Terms (from RFC 1510 [6])

Authentication Verifying the claimed identity of a principal.

Authentication header A record containing a Ticket and an Authenticator to be presented to a server as part of the authentication process.

Authentication path

13 A sequence of intermediate realms transited in the authentication process when communicating from one realm to another.

Authenticator A record containing information that can be shown to have been recently generated using the session key known only by the client and server.

Authorization The process of determining whether a client may use a service, which objects the client is allowed to access, and the type of access allowed for each.

Capability A token that grants the bearer permission to access an object or service. In Kerberos, this might be a ticket whose use is restricted by the contents of the authorization data field, but which lists no network addresses, together with the session key necessary to use the ticket.

Ciphertext The output of an encryption function. Encryption transforms plaintext into ciphertext.

Client A process that makes use of a network service on behalf of a user. Note that in some cases a Server may itself be a client of some other server (e.g., a print server may be a client of a file server).

Credentials A ticket plus the secret session key necessary to successfully use that ticket in an authentication exchange.

KDC Key Distribution Center, a network service that supplies tickets and temporary session keys; or an instance of that service or the host on which it runs. The KDC services both initial ticket and ticket-granting ticket requests. The initial ticket portion is sometimes referred to as the Authentication Server (or service). The ticket-granting ticket portion is sometimes referred to as the ticket-granting server (or service).

Kerberos Aside from the 3-headed dog guarding Hades, the name given to project Athena's authentication service, the protocol used by that service, or the code used to implement the authentication service.

Nonce (entry added by author) A nonce is a unique instantiation of a cryptographic element. In the context of authentication processes, a nonce is a temporary key. For Kerberos, the term nonce refers to the session key.

14 Plaintext The input to an encryption function or the output of a decryption function. Decryption transforms ciphertext into plaintext.

Principal A uniquely named client or server instance that participates in a network communication.

Principal identifier The name used to uniquely identify each different principal.

Realm (entry added by author) Analogous to the more familiar network administration domain, a Kerberos realm is a domain of network operations with a unique identifying name. By convention, the Kerberos realm is written in all capitals, e.g. ATHENA.MIT.EDU.

Seal To encipher a record containing several fields in such a way that the fields cannot be individually replaced without either knowledge of the encryption key or leaving evidence of tampering.

Secret key An encryption key shared by a principal and the KDC, distributed outside the bounds of the system, with a long lifetime. In the case of a human user's principal, the secret key is derived from a password.

Server A particular Principal, which provides a resource to network clients. [Note that the KDC, in providing authentication and ticket services, acts as both a Principal and a Server.]

Service A resource provided to network clients, often provided by more than one server, for example, remote file service.

Session key A temporary encryption key used between two principals, with a lifetime limited to the duration of a single login "session".

Sub-session key A temporary encryption key used between two principals, selected and exchanged by the principals using the session key, and with a lifetime limited to the duration of a single association.

Ticket A record that helps a client authenticate itself to a server; it contains the client's identity, a session key, a timestamp, and other information, all sealed using the server's secret key. It only serves to authenticate a client when presented along with a fresh Authenticator.