Extensible Pre-Authentication in Kerberos ∗ Phillip L. Hellewell, Timothy W. van der Horst, and Kent E. Seamons Internet Security Research Lab Brigham Young University Provo, UT, USA {sshock, timv, seamons}@cs.byu.edu Abstract One trend that has sparked the development of new au- thentication methods is the increasing need for organiza- Kerberos is a well-established authentication system. As tions to provide services to those outside their local security new authentication methods arise, incorporating them into domain. It can be expensive to provision each outside user Kerberos is desirable. However, extending Kerberos poses into a local security domain. Open systems allow the au- challenges due to a lack of source code availability for some thentication of users who are outside the local security do- implementations and a lengthy standardization process. main and do not have a direct pre-existing relationship with This paper presents Extensible Pre-Authentication in the authentication server [12, 1]. Kerberos was not origi- Kerberos (EPAK), a Kerberos extension that enables many nally designed to support open systems. authentication methods to be loosely coupled with Ker- This paper presents Extensible Pre-Authentication in beros, without further modification to Kerberos. To demon- Kerberos (EPAK), a Kerberos extension that enables many strate the utility of the framework, two authentication meth- authentication methods to be loosely coupled with Ker- ods for open systems are presented that have been imple- beros, without further modification to Kerberos. Two au- mented as Kerberos extensions using EPAK. These exten- thentication methods for open systems have been integrated sions illustrate the flexibility EPAK brings to Kerberos while into Kerberos using EPAK to demonstrate the power and maintaining backwards compatibility. flexibility of the framework design. As a motivating example, suppose Company A creates 1 Introduction a collaborative file-sharing service to be fully accessible to the employees of Company B, but provide read-only access Kerberos [7] is a distributed, identity-based authentica- to employees at Company C. Rather than manage accounts tion system that allows a user to authenticate once and then for each partner’s employees, Company A would like to connect to application servers within the Kerberos realm group them into local users employeeB and employeeC. without authenticating again for a period of time. Kerberos Company A would also like to leverage its existing security is time-tested and widely used. Version 5 was standardized infrastructure to manage users. over a decade ago, and is used in business, government, mil- Suppose employees from Company B and C could be itary, and educational institutions. authenticated to Company A’s domain merely by proving Adopting new authentication methods to replace Ker- ownership of their email address. Company A could grant beros is prohibitive because access control systems and ap- and remove access to outsiders simply by mapping an email plications are often built up around the Kerberos infras- address to a local user name without having to establish tructure. For example, Microsoft Active Directory is a a shared secret. For scalability, the mapping could allow well-established, enterprise-level authorization system built wildcards (e.g.,*@companyB.com) to map a group of out- around Kerberos. Extending Kerberos provides an attractive siders to a single local name. solution that allows systems like Active Directory to remain The remainder of the paper is organized as follows. Sec- intact. However, adding extensions poses challenges due to tion 2 gives a background of Kerberos. Then Sections 3 a lack of source code availability for some implementations to 5 describe the design and implementation of EPAK and and a lengthy standardization process. two EPAK-based protocols that enable Kerberos to operate as an open system. Section 6 contains a threat analysis of ∗This research was supported by funding from the National Science Foundation under grant no. CCR-0325951, prime cooperative agreement EPAK and Sections 7 and 8 give related work, conclusions, no. IIS-0331707, and The Regents of the University of California. and future work. AS TGS used to encrypt the SGT returned in step 2b. A credential cache on a client machine stores tickets ob- KDC tained by a user, such as the TGT and SGTs. Each creden- tial includes a client principal, server principal, encrypted ticket (opaque to the user) and a session key that matches 2a the session key hidden inside the ticket. The credential 1a 1b cache must be secured to prevent impersonation. Heim- 2b dal Kerberos secures credentials by storing them in a tem- 3a porary file, /tmp/krb5cc $UID, which has read/write permissions only for the user who obtained the credential. 3b Other implementations, e.g., Microsoft’s, store credentials Client Application Server in memory for greater security. Users and servers have names called principals [10]. Figure 1. The three-phase Kerberos protocol Server principals are composed of a primary name, in- stance, and realm (name/instance@REALM), while client principals do not have an instance (name@REALM). 2 Kerberos Pre-authentication, introduced in Kerberos version 5, al- lows a client to prove its authenticity before being issued a The Kerberos server consists of an Authentication Server TGT. A pre-authentication data (padata) field in the AS (AS) and a Ticket-Granting Server (TGS). The AS and TGS request proves the client’s authenticity, such as a timestamp are responsible for creating and issuing tickets to the clients encrypted with the user’s password-based key or the user’s upon request. The AS and TGS usually run on the same private key in PKINIT [13]. Pre-authentication prevents an computer, and are collectively known as the Key Distribu- attacker from impersonating a user by obtaining an AS re- tion Center (KDC). ply and performing an offline dictionary attack against the The Kerberos authentication process consists of three encrypted data. phases (see Figure 1). In the first phase, the client makes Kerberos provides a mechanism whereby authorization a request for a ticket-granting ticket (TGT) from the AS. information can be embedded into a Kerberos ticket in an The AS responds with a TGT, and an encrypted session key authorization-data field [7], but not all implementations needed for the next phase. The session key can be decrypted support this field. Since this data is server specific, a lack of only by a client that possesses the user’s password, which is interoperability may arise between Kerberos authentication never communicated over the network. In the second phase, servers and application servers that do not understand the the client presents the TGT to the TGS, which responds same authorization data. The Windows 2000 implementa- with a service-granting ticket (SGT) and a second session tion of Kerberos suffers from this incompatibility [5]. Our key encrypted with the first session key. In the final phase, goal is to pursue a design that will not obligate changes to the SGT is presented to the application server, which then authorization mechanisms. grants access to the service. Kerberos provides a mechanism for cross-realm authen- Kerberos is stateless [2], which increases scalability. tication that enables an authenticated user in one realm to Session keys are not maintained by Kerberos servers, but obtain services in another realm, but it does not scale well are included in the TGT and SGT so that the client can com- because each realm must establish a shared key with every municate securely with the TGS and application servers. other realm it trusts. Public key extensions to Kerberos im- Single sign-on (SSO) is an important feature of Ker- prove scalability by eliminating the need to establish shared beros. With SSO, a user’s password must only be entered secrets [2]. In practice, however, a user in one realm is usu- once per session. The TGT and session key obtained in ally provisioned explicitly in another realm. phase 1 are saved, so each time the user wants to gain ac- 2.1 Limitations cess to a service, only phases 2 and 3 are performed. The tickets contain start/end times indicating a valid time period Conventional Kerberos does not operate as an open sys- when they can be used. SSO provides convenience, effi- tem because every user must be known a priori. A shared ciency, and added security. secret between the AS and the user (a password-derived A Kerberos server (KDC) maintains several secret keys. key) must be maintained by the AS, and each user has a A single key, Ktgs, is used to encrypt the TGT returned 1-to-1 mapping with a principal name. in step 1b (see Figure 1). Several keys, Kcx , one for each Most Kerberos extensions are not designed to make Ker- client, are used to encrypt the session key, also returned in beros operate as an open system. PKINIT [13] and other step 1b. Finally, several keys, Kvx , one for each server, are public-key extensions (see Chapter 7) extend credential management to third parties (trusted CAs), but the third par- PAS AS TGS ties usually cooperate directly with the Kerberos adminis- trator in creating certificates with principal names that exist KDC in the database. Our goal is to extend Kerberos to be an open authentica- tion system, but modifying Kerberos for each new authen- 0b 2a 1a 1b tication type is burdensome. New authentication types are 0a 2b subject to approval by a standards committee. Once defined, extensions are often rigid and cannot be updated without be- 3a ing re-approved and assigned new pre-auth type numbers. PKINIT has undergone this process. 3b Client One might wish to incorporate a proprietary extension Application Server into Kerberos without involving the standardization pro- cess, but this can be difficult or even impossible when the Figure 2.