The Evolution of the Kerberos Authentication Service John T Kohl Digital Equipment Corporation B Clifford Neuman Information Sciences Institute University of Southern California Theodore Y Ts o Massachusetts Institute of Technology ABSTRACT The Kerberos Authentication Service developed at MIT has been widely adopted by other organizations to identify clients of network services across an insecure network and to protect the privacy and integrity of communication with those services While Version 4 was a step up from traditional security in networked systems extensions were needed to allow its wider application in environments with different characteristics than that at MIT This paper discusses some of the limitations of Version 4 of Kerberos and presents the solutions provided by Version 5 1 Introduction The Kerberos Authentication Service was developed by the Massachusetts Institute of Technology MIT to protect the emerging network services provided by Project Athena Versions 1 through 3 were used internally Although designed primarily for use by Project Athena Version 4 of the protocol has achieved widespread use beyond MIT Models for administration and use of computer services differ from site to site and some environments require support that isn t present in Version 4 Version 5 of the Kerberos protocol incorporates new features suggested by experience with Version 4 making it useful in more situations Version 5 was based in part upon input from many contributors familiar with Version 4 This paper begins by describing the Kerberos model and basic protocol exchanges Section 3 discusses the limitations of Version 4 of Kerberos The fourth section reviews new features found in Version 5 Section 5 describes the implementation of Version 5 and support for converting existing applications from Version 4 The paper concludes with status and plans for future work Terminology and conventions A principal is the basic entity that participates in authentication In most cases a principal represents a user or an instantiation of a network service on a particular host Each principal is uniquely named by its principal identifier Encryption is the process of transforming data into a form that cannot be understood without applying a second transformation The transformation is affected by an encryption key in such a manner that the This paper is a revision of a paper presented at the Spring 1991 EurOpen Conference in Troms Norway and will appear in an upcoming IEEE Computer Society Press book edited by Frances Brazier and Dag Johansen The work described here was done while Kohl was at MIT and in part while Neuman was at the University of Washington 2second transformation can only be applied by someone in possession of the corresponding decryption key A secret key cryptosystem such as that defined by the Data Encryption Standard DES FIPS46 uses a single key for both encryption and decryption Such an encryption key is called a secret key A public key cryptosystem such as RSA Riv78 uses different keys for encryption and decryption One of the keys in the pair can be publicly known while the other must be kept private These keys are referred to as public and private keys respectively Plaintext is a message in its unencrypted form either before the encryption transformation has been applied or after the corresponding decryption transformation is complete Ciphertext is the encrypted form of a message the output of the encryption transformation In figures encryption is denoted by showing the plaintext surrounded by curly braces followed by a key K whose subscript denotes the principals who possess or have access to that key Thus abc encrypted under c s key is represented as abc Kc 2 The Kerberos Model Kerberos was developed to enable network applications to securely identify their peers To achieve this the client initiating party conducts a three party message exchange to prove its identity to the server the contacted party The client proves its identity by presenting to the server a ticket shown in figures as Tc s which identifies a principal and establishes a temporary encryption key that may be used to communicate with that principal and an authenticator shown in figures as Ac s which proves that the client is in possession of the temporary encryption key that was assigned to the principal identified by the ticket The authenticator prevents an intruder from replaying the same ticket to the server in a future session Tickets are issued by a trusted third party Key Distribution Center KDC The KDC proposed by Needham and Schroeder Nee78 is trusted to hold in confidence secret keys known by each client and server on the network the secret keys are established out of band or through an encrypted channel The key shared with the KDC forms the basis upon which a client or server believes the authenticity of the tickets it receives A Kerberos ticket is valid for a finite interval called its lifetime When the interval ends the ticket expires any later authentication exchanges require a new ticket from the KDC Each installation comprises an autonomously administered realm and establishes its own KDC Most currently operating sites have chosen realm names that parallel their names under the Internet domain name system e g Project Athena s realm is ATHENA MIT EDU Clients in separate realms can authenticate to each other if the administrators of those realms have previously arranged a shared secret 2 1 The initial ticket exchange Figure 1 shows the messages required for a client to prove its identity to a server The basic messages are the same for Versions 4 and 5 of Kerberos though the details of the encoding differ A typical application uses this exchange when it first establishes a connection to a server Subsequent connections to the same server require only the final message in the exchange client caching eliminates the need for the first two messages until the ticket expires In the first message the client contacts the KDC identifies itself presents a nonce a timestamp or other non repeating identifier for the request and requests credentials for use with a particular server Upon receipt of the message the KDC selects a random encryption key Kc s called the session key and generates the requested ticket The ticket identifies the client specifies the session key Kc s lists the start and expiration times and is encrypted in the key Ks shared by the KDC and the server Because the ticket is encrypted in a key
View Full Document
Unlocking...