NASA-CR-Z03049
`
`bD/_
`
`ISI Research
`
`Report
`
`ISI/RS-94-399
`
`September
`
`1994
`
`Kerberos: An Authentication
`Service
`for Computer Networks
`
`B. Clifford Neuman
`
`and Theodore Ts'o
`
`ISI/RS-94-399
`
`September
`
`1994
`
`University
`
`of Southern
`
`California
`
`Information
`
`Science
`
`Institute
`
`4676 Admiralty
`
`Way, Marina
`
`del Rey, CA 90292-6695
`
`310-822-1511
`
`and IBM. Neuman's
`of Project Athena were Digital Equipment
`are
`efforts
`security
`Corporation
`sponsors
`The major
`in part by the Advance
`and
`NCC-2-539
`funded
`Research
`Projects Agency
`under NASA Cooperative
`Agreement
`other awards,
`and by CyberSAFE
`Corporation
`(formerly Open Computing
`Security Group).
`The views
`and conclu-
`sions contained
`in this paper
`and should not be interpreted
`as representing
`the official
`are those of the authors
`poli-
`cies, either expressed
`Figures
`or implied,
`of any of
`the funding
`organizations.
`and descriptions
`in this paper were
`by the authors
`provided
`and are used with permission.
`
`© 1994 Institute
`Magazine, Volume
`
`of Electrical
`32, Number
`
`Engineers.
`and Electronics
`9, pages 33-38, September
`
`Reprinted, with permission,
`1994.
`
`from IEEE Communications
`
`1
`
`USAA 1012
`
`

`
`Kerberos : An Authentication
`Service for Computer Networks
`
`an attacker
`on cryptography,
`using authentication
`based
`When
`gains no information
`that would
`enable
`to the network
`listening
`to falsely
`identity. Kerberos
`is the most
`commonly
`claim another's
`used example
`of this
`type of authentication
`technology.
`
`it
`
`B. Clifford Neuman
`
`and Theodore
`
`7"$'0
`
`_
`
`users and
`to multiple
`service
`require the ability to accurate-
`ly identify
`the user making a
`odern computer systems provide
`request.
`In traditional
`systems,
`the user's identity is verified by
`checking a password typed during iogin;
`the sys-
`tem records
`the identity and uses it to determine
`what operations may be performed. The process
`of verifying the user's identity is called authenti-
`cation. Password-based authentication is not suitable
`for use on computer networks. Passwords sent across
`the network can be intercepted and subsequently
`used by eavesdroppers to impersonate the user. While
`thisvulnerability has been long known,
`it was recent-
`ly demonstrated
`on a major
`scale with the discov-
`eryof planted password collecting programs at critical
`points on the Internet
`[4].
`
`Authentication,
`Confidentiafity,
`Authorization
`
`Integrity,
`and
`
`uthentication is the verification of the identity
`of a party who generated some data, and of the
`integrity of the data. A principal
`is the party whose
`identity is verified. The verifier is the party who
`demands
`assurance
`of the principal's
`identity.
`Data integrity isthe assurance that the data received
`is the same as generated. Authentication mecha-
`nisms differ in the assurances
`they provide: some
`indicate that data was generated by the principal
`aI some point
`in the past, a few indicate that the prin-
`cipal was present when the data was sent, and
`others indicate that the data received was freshly
`generated by the principal. Mechanisms
`also dif-
`fer in the number of verifiers: some support a sin-
`gle verifier per message, while others support multiple
`verifiers. A third difference
`is whether the mecha-
`nism supports non-repudiation,
`the ability of the ver-
`ifier to prove
`to a third party that
`the message
`originated with the principal.
`perfor-
`affect
`Because
`these
`differences
`mance,
`it is important
`to understand the require-
`ments of an application when choosing a method.
`
`for electronic mail
`authentication
`For example,
`may require support
`for multiple
`and
`recipients
`but can tolerate greater
`latency.
`non-repudiation,
`In contrast,
`poor performance
`would cause prob-
`lems for authentication
`to a server responding to
`frequent queries.
`include confidentiality
`security services
`Other
`is the protec-
`and authorization.
`Confidentiality
`tion of information
`from disclosure
`to those not
`intended to receive it. Most strong authentication
`methods
`optionally
`provide
`confidentiality.
`is the process
`by which one deter-
`Authorization
`is allowed to perform
`mines whether
`a principal
`an operation. Authorization
`is usually performed
`the principal
`has been authenticated,
`after
`and
`may be based on information local to the verifier,
`or based on authenticated
`statements by others.
`The remainder
`of this article will concentrate
`on authentication
`for real-time,
`interactive
`ser-
`vices that are offered on computer networks. We use
`the term real-time
`loosely to mean that a client
`is waiting
`for a response
`to a query or
`process
`command so that it can display the results to the user,
`or otherwise continue performing
`its intended
`func-
`tion. This class of services includes remote login, file
`system reads and writes, and information
`retrieval
`for applications
`like Mosaic.
`
`Why Kerberos
`
`he introduction discussedthe problems asso-
`ciatedwith password-based authentication and,
`in particular, how passwords
`can be collected
`by
`eavesdropping.
`to the security con-
`In addition
`cern, password based authentication
`is inconvenient;
`users do not want to enter a password each time they
`access a network
`service. This has led to the use
`of even weaker
`on computer
`authentication
`net-
`works: authentication
`by assertion.
`While more convenient
`for the user, authenti-
`cation by assertion hardly qualifies as authentication
`at all. Examples include
`the Berkeley R-command
`suite and the IDENT protocol. With authentica-
`tion by assertion,
`the identity
`applications
`assert
`of the user and the server believes
`it. Such authen-
`tication is easily thwarted
`by modifying the applica-
`
`CLIFFORD NEUM.AN is a
`
`_ientist
`
`at the lnfmmation
`Institute of the Uni-
`$ciences
`of $out_m
`Cak'fomia.
`_sity
`
`THEODORE 75'0
`
`leads the
`
`goberos V$ development
`effort at the Massachusetts
`
`Inside of Technolo_..
`
`IEEE Communications
`
`Magazine
`
`• September
`
`1994
`
`0163-6804/94/$04.00
`
`1994 © IEEE
`
`33
`
`2
`
`

`
`to the
`access
`tion. This may require privileged
`system, which is easily obtained on PCs and per-
`sonal workstations. While most uses of authenti-
`cation by assertion require that a connection originate
`from a "trusted" network address, on many networks,
`are themselves
`simply assertions.
`addresses
`Stronger authentication methods based on cryp-
`tography are required. When using authentica-
`tion based on crytography,
`an attacker listening
`to the networkgains no information thatwould enable
`it to falsely claim another's
`identity. Kerberos
`is
`the most commonly used example of this type of
`technology. Unfortunately,
`strong
`authentication
`technologies
`are not used as often
`authentication
`as they should be, although the situation isgradually
`improving.
`
`The Kerberos
`Service
`
`Authentication
`
`ser-
`authentication
`is a distributed
`erberos
`vice that allows a process (a client), running on
`behalf of a principal
`(a user), to prove its identity
`to a verifier (an application server, or just server)
`without sending data across the network that might
`allowan attacker or the verifier to subsequently imper-
`sonate the principal. Kerberos optionally provides
`integrity and confidentiality
`for data sent between
`the client and server. Kerberos was developed in
`the mid-'80s
`as part of MIT's Project Athena
`[2].
`As use of Kerberos
`spread to other environments,
`changes were needed to support new policies and
`patterns of use. To address
`these needs, design
`of Version 5 of Kerberos (VS) began in 1989 [11].
`Though V4 still runs at many sites, V5 is consid-
`ered to be standard Kerberos [113].
`
`of gerberos
`IJmitations
`of Kerberos have been described in the
`Limitations
`of pref-
`[1]. Though most are a matter
`literature
`erence or apply to V4 and early drafts of VS, a few
`are fundamental
`and are discussed
`here.
`In par-
`is not effective against password
`ticular, Kerberos
`if a user chooses
`a poor pass-
`guessing
`attacks;
`word,
`then an attacker
`guessing
`that password
`can impersonate
`the user. Similarly, Kerberos
`a trusted path through which passwords
`requires
`are entered.
`If the user enters
`a password
`to a
`program that has already been modified by an
`attacker (a Trojan horse), or if the path between
`the user and the initial authentication
`program
`can be monitored,
`then an attacker may obtain
`sufficient
`information to impersonate
`the user. Ker-
`heros can be combined with other techniques,
`as
`descnl_..d later, to address these limitations.
`To be useful, Kerberos must be integrated
`with other parts of the system. It does not protect
`all messages
`sent between two computers;
`it only
`protects
`the messages
`from software
`that has
`been written or modified to use it. While it may
`be used to exchange
`encryption keys when estab-
`lishing link encryption and network level security
`services,
`this would require
`changes
`to the net-
`work software of the hosts involved.
`Kerberos does not itself provide authorization,
`but V5 Kerberos passes authorization information
`generated by other services.
`In this manner, Ker-
`beros can be used as a base for building separate
`distributed authorization services [14].
`
`How Kerberos Works
`
`System [18] uses a
`The Kerberos Authentication
`to prove to a verifier
`series of encrypted messages
`that a client is running on behalf of a particular user.
`The Kerberos
`protocol
`is based in part on the
`Needham and Schroeder authentication
`protocol
`[13], hut with changes to support
`the needs of the
`environment
`for which it was developed. Among
`these changes are the use of timestamps
`to reduce
`the number of messages needed for basic authen-
`tication [6], the addition of a "ticket-granting"
`service
`to support
`subsequent
`authentication
`without re-entry of a principal's password, and a
`different approach to cross-realm authentication
`(authentication
`of a principal
`registered with a
`different authentication server than the verifier).
`The remainder of this section descn3_s
`the Ker-
`beros protocol. The description
`is simplified for
`clarity; additional
`fields are present
`in the actual
`protocol. Readers
`should consult RFC 1510 [10]
`for a more thorough description of the Kerberos
`protocol.
`
`gerberos Encryption
`-- Though conceptually,
`proves
`that a client
`authentication
`is
`Kerberos
`on behalf
`of a particular
`running
`user,
`a more
`precise
`statement
`is that the client has knowl-
`edge of an encryption
`key that is known by only
`the user and the authentication
`server.
`In Ker-
`beros,
`the user's encryption
`key is derived from
`and should be thought of as a password; we will
`refer to it as such in this article. Similarly,
`each
`application
`server shares an encryption
`key with
`the authentication
`server; we will call this key the
`server key.
`of
`implementation
`in the present
`Encryption
`the data encryption
`standard
`Kerberos
`uses
`(DES).
`It is a property of DES that if ciphertext
`(encrypted data)
`is decrypted with the same key
`used to encrypt
`it, the plaintext
`(original
`data)
`appears.
`If different
`encryption keys are used for
`encryption
`and decryption,
`or if the ciphertext
`is
`modified,
`the result will be unintelligible,
`and
`the checksum in the Kerberos message will not
`match the data. This combination
`of encryption
`and the checksum provides
`integrity and confi-
`dentiality for encrypted Kerberos messages.
`
`The Kerberos Ticket-- The client and server do
`not initially share an encryption
`key. Whenever a
`client authenticates
`itself to a new verifier it relies
`on the authentication server to generate a new encry_
`tion key and distribute it securely to both parties.
`This new encryption
`key is called a session key
`and the Kerberos
`ticket is used to to distribute
`it
`to the verifier.
`issued by
`is a certificate
`ticket
`The Kerberos
`using the
`server,
`encrypted
`an authentication
`the ticket
`server key, Among other information,
`the random session key that will be used
`contains
`for authentication
`of the principal
`to the verifier,
`the name of the principal
`to whom the session
`key was issued,
`and an expiration
`time after
`which the session key is no longer valid. The ticket
`is not sent directly to the verifier, but is instead
`sent to the client who forwards it to the verifier as
`part of the application request. Because
`the tick-
`et is encrypted in the server key, known only by
`the authentication
`server and intended verifier,
`it
`
`m T
`
`he Kerberos
`
`Authentica-
`
`tion System
`
`uses a series
`
`of encrypted
`
`messages
`
`to
`
`prove to a
`
`verifier that
`
`a client
`
`is
`
`running on
`
`behalf of a
`
`particular
`
`user.
`
`34
`
`IEEE Communications
`
`Magazine
`
`* September
`
`1994
`
`3
`
`

`
`is not possible for the client to modify the ticket with-
`out detection.
`
`and Response--Messages
`Request
`Application
`3 and 4 in Fig. 1 show the application request and
`response,
`the most basic exchange
`in the Ker-
`beros protocol. I It is through
`this exchange
`that a
`client proves to a verifier that it knows the session
`key embedded
`in a Kerberos
`ticket. There are
`two parts to the application
`request,
`a ticket
`(described above) and an authenticator. The authen-
`ticator includes, among otherfieids:thecurrent
`time,
`a checksum,
`and an optional
`encryption
`key, all
`encrypted with the session key from the accompa-
`nying ticket.
`the
`request,
`Upon receipt of the application
`the session
`verifier decrypts
`the ticket, extracts
`key, and uses
`the session
`key to decrypt
`the
`authenticator.
`If the same key was used to encrypt
`the authenticator as used to decrypt it, the checksum
`will match and the verifier can assume the authen-
`ticator was generated
`by the principal named in
`the ticket and to whom the session key was issued.
`This is not byitselfsufficient
`for authentication since
`an attacker can intercept an authenticator and replay
`it later to impersonate
`the user. For this reason
`the verifier additionally
`checks
`the timestamp to
`make sure that the authenticator is fresh. If the times-
`tamp is within a specified window (typically
`five
`minutes)
`centered
`around the current
`time on
`the verifier,
`and if the timnestamp has not been
`seen on other requests within that window,
`the
`verifier accepts
`the request as authentic. A dis-
`cussion of the benefits and drawbacks
`to the use
`of timestamps
`in authentication
`protocols
`can be
`found in [15].
`At this point the identity of the client has been
`verified by the server. For some applications
`the
`client also wants to be sure of the server's identity.
`If such mutual authentication
`is required,
`the
`server generates an application response by extract-
`ing the client's
`time from the authenticator,
`and
`returns it to the client
`together with other infor-
`mation, all encrypted
`using the session key.
`
`Authentication Request and Response m The
`client requires a separate
`ticket and session key
`for each verifier with which it communicates. When
`a client wishes to create an association with a partic-
`ularverifier, the client uses the authentication request
`and response, messages
`I and 2 from Fig. 1, to
`obtain a ticket and session key from the authenti-
`cation server. In the request,
`the client
`sends the
`authentication
`server
`its claimed
`identity,
`the
`name of th e verifier, a requested expiration time
`for the ticket, and a random number that will be
`used to match the authentication
`response with
`the request.
`In its response, the authentication server returns
`the session key,
`the assigned expiration time, the
`random number
`from the request,
`the name of
`the verifier, and other information
`from the tick-
`et, all encrypted with the user's password regis-
`tered with the authentication
`server,
`together
`with a ticket containing similar information, and which
`is to be forwarded
`to the verifier
`as part of the
`application request. Together,
`the authentication
`request and response and the application request
`and response comprise the basic Kerberos authen-
`tication protocol.
`
`1
`
`.:.
`
`..
`
`.
`
`:
`
`:i:•! i ii:ii
`
`"_......:
`
`
`
`::i:•::•¸:=¸/ 3•'::_=_:::/_:!i•=/_iii/__ •i
`
`....
`
`• Figure 1. BasicKerberosauthentic_n
`
`protocol
`
`(simphfied).
`
`Obtaining Additional Tickets -- The basicKer-
`heros authentication protocol allows a client with
`knowledge of the user's password to obtain a tick-
`et and session key for and to prove its identity to
`any verifier
`registered with the authentication
`server. The user's password must be presented
`each time the user performs authentication with a
`new verifier. This can be cumbersome;
`instead, a
`system should support single sign-on, where the user
`logs in to the system once, providing
`the pass-
`word at that time, and with subsequent
`authenti-
`cation occurring automatically. The obvious way
`to support
`this, caching the user's password on
`the workstation,
`is dangerous.
`a Ker-
`Though
`beros
`ticket and the key associated with it are
`valid for only a short
`time,
`the user's password
`can be used toobtain tickets, and to impersonate the
`user until the password is changed. Abetter approach,
`and that used by Kerberos,
`is to cache only tickets
`and encryption keys (collectivelycalled
`credentials)
`that will work for a limited period.
`The ticket granting exchange of the Kerberos
`protocol
`allows
`a user
`to obtain
`tickets
`and
`encryption
`keys using such short-lived
`creden-
`tials, without
`re-entry
`of
`the user's password.
`When the user first
`logs in, an authentication
`request
`is issued and a ticket and session key for
`the ticket granting
`service
`is returned
`by the
`authentication
`server. This ticket, called a ticket
`granting ticket, has a relatively short life (typically
`on the order of eight hours). The response
`is
`decrypted,
`the ticket and session key saved, and
`the user's password forgotten.
`to prove
`when the user wishes
`Subsequently,
`is request-
`its identity to a new verifier, a new ticket
`ed from the authentication
`server using the ticket
`exchange. The ticket granting exchange
`granting
`is identical
`to the authentication
`exchange except
`that the ticket granting
`request has embedded
`within it an application
`request, authenticating
`the client
`to the authentication
`server, and the
`ticket granting response
`is encrypted using the
`session key from the ticket granting ticket, rather
`than the user's password.
`
`lMessages I and 2 are
`described in thesection on
`authentication request
`and response.
`
`IEEE Communications Magazine * September 1994
`
`35
`
`4
`
`

`
`Client(cid:0)server
`
`applications
`must be
`
`modified to
`use Kerberos
`
`for authenti-
`cation; such
`Kerberos-
`
`aware
`
`applications
`are said to be
`Kerberized.
`
`Figure 2 shows the complete Kerberos authen-
`tication protocol. Messages
`1 and 2 are used only
`when the user first
`logs in to the system, messages
`3 and 4 whenever
`a user authenticates
`to a new
`verifier, and message 5 is used each time the user
`authenticates
`itself. Message
`6 is optional
`and
`used only when the user requires mutual-authen-
`tication by the verifier.
`
`Date -- As descn'bed so
`Protecting
`Aop;/cat/on
`far, Kerberos provides only authentication: assur-
`ance that
`the authenticated
`principal
`is an active
`participant
`in an exchange. A by-product
`of the
`Kerberos authentication
`protocol
`is the exchange
`of the session key between the client and the serv-
`er. The session key may subsequently
`be used by
`the application to protect
`the integrity and priva-
`cy of communications.
`The Kerberos
`system
`defines
`two message
`types,
`the safe message and
`the private message
`to encapsulate data that must
`be protected,
`but the application is free to use a
`suited to the particular data that
`is
`method
`better
`transmitted.
`
`Features -- The description of Ker-
`Additional
`beros just presented was greatly simplified. Addi-
`fields are present in the ticket, authenticator,
`tional
`and messages,
`to support bookkeeping
`and addi-
`tional
`functionality. Some of the features present
`in Version 5 include renewable and forwardable tick-
`ets, support for higher level authorization mecha-
`nisms,
`and support
`for multi-hop
`cross-realm
`authentication
`(described
`in the following
`sec-
`tion). A more rigorous presentation of the Kerberos
`protocol,
`and a description of each field is found
`in RFC 1510 [10].
`
`and
`Infrastructure
`Kerberos
`Cross-Realm Authentication
`
`n a system that crosses organizational boundaries,
`it is not appropriate
`for all users to be regis-
`feted with a single authentication
`server. Instead,
`multiple
`authentication
`servers will exist, each
`responsible
`for a subset of the users or servers in
`the system. The subset of the users and servers
`registered with a particular authentication
`server
`is called a realm (if a realm is replicated,
`users
`will be registered with more than one authentication
`server). Cross-realm authentication allows a prin-
`cipal to prove its identity to a server registered in
`a different realm.
`To prove
`its identity to a server in a remote
`realm, a Kerberos principal obtains a ticket grant-
`ing ticket
`for the remote
`realm from its local
`authentication
`server. This requires
`the princi-
`pals's local authentication
`server to share a cross-
`realm key with the verifier's
`authentication
`server. The principal next uses the ticket granting
`to request a ticket for the verifier from
`exchange
`the verifier's authentication
`server, which detects
`that the ticket granting
`ticket was issued in a for-
`eign realm, looks up the cross-realm key, verifies the
`validity of ticket granting ticket, and issues a tick-
`et and session key to the client. The name of the client,
`embedded in the ticket,
`the name of the
`includes
`realm in which the client was registered.
`With Version 4, it was necessary for an authen-
`server to register with every other realm
`tication
`
`with which cross-realm authentication was required.
`This was not scalable;
`complete
`interconnection
`required the exchange of n2 keys where n was the
`number of realms.
`In contrast, Version 5 supports multi-hop cross-
`realm authentication,
`allowing keys to be shared
`hierarchically. With V5, each realm shares a key
`with its children and parent, i.e. the Tsz.m3o
`realm
`shares a key with the Imo realm, which also shares
`keyswithrtIT, m_o, o_e_2,t._u, and_.
`Ea3u.
`If no key is shared directly
`by zsz.
`r.DtJ and
`m"r. m_o, autbentication of the client ben@ I SI. m_u
`to a server registered with the Mr?. _Du realm
`proceeds byobtaining a ticket granting ticket for EI:XJ
`from the ISI. EDU authentication
`server, using
`ticket to obtain a ticket grant-
`that
`ticket granting
`mg ticket for thel_'T,
`l_U realm from the l._rJauthen-
`tication server, and finally obtaining a ticket
`for the
`verifier from the _T.
`_.J authentication
`server.
`The list of realms
`that are transited
`during
`multi-hop cross-reaim authentication is recorded in
`the ticket and the verifier accepting the authenti-
`cation makes
`the final determination
`about
`whether
`the path that was followed
`should be
`trusted. Shortcuts
`through the hierarchy are sup-
`ported and can improve both the trust in and the per-
`of the authentication process.
`formance
`This hierarchical organization of realms is sim-
`ilar to the hierarchical
`organization
`of certifica-
`tion authorities and certificate servers for public-key
`cryptography [3]. Aswith the public key certification
`hierarchy,
`the utility of the authentication
`infra-
`structure supporting authentication between parties
`not previously known to one another depends in part
`on the availability of authentication servers for realms
`near the top of the hierarchy. Unfortunately,
`political and legal ambiguity has the potential
`to slow
`of these realms. In the mean time,
`the establishment
`pairwise
`relationships
`between
`regions
`of the
`hierarchy (shortcuts) are important. A discussion of
`the tradeoffs available when establishing
`realms
`for large organizations
`can be found in [5].
`
`Obtaining
`
`and Using Kerberos
`
`ource code releases for V4 and Beta V5 Kerberos
`are freely available
`from MIT, however, MIT
`does not officially support
`these releases. Several
`companies have taken reference implementations
`from MITand provide commercially supported prod-
`ucts. Information
`on the free releases
`and the
`supported
`versions
`can be obtained
`by reading
`the "Kerberos Frequently Asked Questions" doc-
`ument
`[8] periodically
`posted
`to the Usenet
`newsgroup ¢omp.pz-ol:ocols.
`kerberos,
`or by
`sending a message to £nfo-kerberos@mit.
`edu.
`
`Server
`up the Authentication
`Setting
`Since the Kerberos authentication server maintains
`a database of passwords(encryption keys) for all the
`users at a site,
`it is extremely important
`it be
`that
`installed on a carefully protected and physically secure
`machine. If possible,
`the machine should be ded-
`icated to running the authentication server and the
`number of users with access should be limited.
`Initial passwords for a site's users must be registered
`with the authentication server. If the number of users
`is small, initial registration is best achieved in person
`in front of an accounts administrator who can check
`a driver's license, passport, or otherphysical document.
`
`36
`
`IEEE Communications Magazine • September 1994
`
`5
`
`

`
`|
`
`At sites with a large number of users and lim-
`ited staff devoted to system administration,
`less
`cumbersome and less secure procedures
`for initial
`registration may present an acceptable tradeoff. For
`example,
`if users regularly
`log on to a trusted sys-
`tem, the loon program can be modified to register
`the passwordsofnon-registerod
`users afterverifying
`that the password is valid. While simpler than in-per-
`son registration, such bootstrapping techniques must
`be used with caution since
`they rely initially on
`the security of a weaker authentication
`system.
`
`Kerberos
`
`Utilities
`
`Several utility programs must be installed on the
`workstation
`to allow users
`to obtain Kerberos
`credentials(_nit),destroycredendals
`(kdesUroy),
`list credentials
`(klist),
`and change
`their Ker-
`beros password (kpassv_).
`Some sites choose
`to
`integrate
`the Kerberos
`iogin tool kinit
`with the
`workstation login program so that users do not need
`to type their password twice. This makes
`the use
`of Kerberos
`nearly transparent;
`users may not
`even be aware they are using Kerberos.
`
`Applications
`Using "Kerberized"
`to
`applications must be modified
`Client/server
`use Kerberos for authentication; such Kerberos-
`aware applications
`are said to be Kerberized.
`Kerberizing
`an application
`is the most difficult
`part of installing Kerberos. Fortunately,
`the MIT
`reference
`implementation
`includes
`versions
`of
`popular applications
`(the Berkeley R-commands,
`telnet, and POP)with support for Kerberos already
`added. Other applications
`have been Kerberized
`by vendors and are included in their supported prod-
`ucts. The availability of Kerberos-aware applications
`has improved
`with time,
`and is expected
`to
`improve further. However,
`a site would have to
`arrange
`itself
`to add Kerberos
`support
`to any
`application developed in-house.
`It is generally necessary
`to modify the client/
`server protocol when Kerberizing
`an application
`unless
`the protocol
`designer
`has already made
`provisions for an authentication exchange. The appli-
`cation program must generate
`and send a Ker-
`heros
`application
`request
`to the application
`server during the protocol
`initialization
`phase,
`and the server must verify the Kerberos authenti-
`cation information.
`The request must be trans-
`mitted within the client/server protocol. The Kerberos
`library provides routines
`that generate and verify
`these messages.
`of Kerberos pro-
`More recent implementations
`vide a Generic Security Services Application Pro-
`grammer Interface
`(GSSAPI)[12].
`The OSSAPI
`provides a standard programming
`interface which
`is authentication mechanism independent.
`This
`allows the application
`programmer
`to design an
`application and application protocol which can use
`alternative authentication
`technologies,
`including
`Kerberos.The use of the GSSAPI in application pro-
`grams is recommended wherever poss_le.
`inter-
`Because
`it is a generic
`authentication
`face,
`the OSSAPI
`does not support
`all of
`the
`functionality provided by Kerberos. For example,
`Kerberos's notion of user-to-user
`authentication
`is not currently supported. Hence, an application
`programmer will not always be able to use the
`GSSAPI
`in all cases,
`and may have to use the
`Kerberos API in order to use some features.
`
`II Figure 2. Complete Kerberos authentication protocol
`
`(simph'fied).
`
`Other Approaches
`Improving
`Security
`
`for
`
`solution to network
`erberos is not a complete
`security problems. Several limitations have been
`mentioned in this article. Other toobcan also provide
`partial solutions to network security problems, and
`when combined with Kerberos, stronger security can
`be attained. Among
`these other tools are one-
`time passcodes and public-key cryptography.
`
`Passcodes
`On_Time
`Aone-time passcode authentication mechanism uses
`a different passcode
`each time authentication
`is
`required. Kerberos does not protect against the theft
`of a password through a Trojan horse Iogin program
`on the user's workstation,
`but if the user's pass-
`word were to change each timeit was entered,a pass-
`word stolen in this manner would be useless
`to an
`attacker. One-time
`passcode
`authentication
`methods
`typically use a credit card sized device
`that either displays
`a time varying password
`(called a passcode),
`or returns a passcode when a
`challenge
`is entered
`on a small keypad. Some
`methods use a printed list of passcodes
`that can
`be used one after another. When a user logs in
`using one of these devices,
`the user is prompted
`for the passcode. Depending on the style, the prompt
`may include the challenge that is to be typed into the
`device. The user enters the passcode from the device
`in much the same way as a normal password.
`One-time passcode devices are not by themselves
`sufficient
`for securing distributed systems because
`the information needed to verify the passcode might
`not be present on all servers with which the client
`interacts during a session,
`and because
`it is not
`practical
`to require
`of
`the passcode
`on
`entry
`every server access. However, one-time passcode
`methods
`can be combined with Kerberos
`so that
`knowledge
`of both the passcode and a password-
`based encryption
`key are required to successfully
`complete
`the initial authentication
`exchange.
`products
`that combine
`one-time
`Commercial
`passcodes with Kerberos are available.
`
`IEEE Communications Magazine • September 1994
`
`37
`
`6
`
`

`
`of Ker-
`tributed to the design and implementation
`beros. Celeste Anderson, Ravi Oanesan, Virgil Glig-
`or, Sridhar Gullapalli,
`Charlie Lai, Gennady
`Medvinsky, Stuart Stubblebine, and Peter Will com-
`mented on drafts of this paper.
`The major sponsors
`of Project Athena were
`Digital Equipment Corporation
`and IBM. Neu-
`man's security efforts are funded in part by the
`Advance Research Projects Agency under NASA
`Cooperative Agreement
`NCC-2-539
`and other
`awards, and by CyberSAFE Corporation
`(former-
`!3, Open Computing
`Security Group). The views
`and conclusions
`in this paper are those
`contained
`of the authors and should not be interpreted
`as
`representing
`the official policies, either expressed
`or implied,
`of any of the funding
`organizations.
`Figures and descriptions in this article were provided
`by the authors and are used with permission.
`
`References
`
`public key infrastructure,
`
`IEEE
`
`monitor-
`
`of the kerbaros m_her_.ation
`111S. M. SMIoviflmd M. Iderflst. _
`Rev., vol. 20, no. S,pp. 119-132, Oct 1990.
`_Aim.
`_Conwnu_
`121 G. A. Champine, D. E. Gear, Jr, and William N. Ruh, Project Athena
`es a distril_ted
`computer
`IEEE Computer,
`voI. 23. no. 9,
`system,
`pp. 40-51. Sept.
`1990.
`a national
`[3] S. Chokhani,
`Toward
`Commun.
`It/t_.tn tt_
`issue.
`141 Computer Emergency Responce Team, Ongoing mmvork
`ing attacks, CERT Adviso_¢ CA-94:01, Fd). 3, 1994.
`IS! C_erSAFE _,.
`D*pk)y_g
`Kerbams for brge or_nis_ons.
`Technical Report 94-47, CyberSAFE Corporation,
`2443
`lS2nd
`Avenue NE, Redmond WA 98052 USA; tr-tlquest@ocsg.com.
`Tromps
`in key distribution proto-
`16] n. E. Denning and G. M,
`.f_co,
`(l_, Commun. oftheACM,
`vol. 24, no. S, Pl). S33-536, Aug. 1981.
`17]W. Diflle and M. E.Hellnwn. New (_
`in oylr/tography,
`l_E Tran_
`on Info. Theory, vol. 22, no. 6, pp, 644-654,
`Nov. 1976.
`ISle. J_,n,
`Kerbarus ram'
`fteq_m_
`_
`_,
`peaod_tb/post-
`ed to Usenot
`Alm'11994.
`nowsgroup
`comp.protocob.kerpems,
`[9] S. r. Kent.
`Internet
`privacy enhanced mail, Commun. of the ACM,
`vol. 3S. no. S, pp. 48-60, Aug. 1993.
`I10] J. T. Kohl and B. C Neuman, The Ked)tm_s nc,twork _
`Intemet RFC 1510, September
`sefvica.
`1993.
`[11| J. T. Kohl, B. C. Neunum.
`and T. Y. T'so. The evolution of the Ker-
`heros authentication
`system, Distributed
`Open Systems.
`(IEEE
`Sociely Press, 1994), PP. 78-94.
`Computer
`1121J. Unn, Generic security service application
`net RFC 1508, Sept. 1993.
`113] R. M. Needham and M. D. Schroeder,
`iniarge netwod_ of co_,
`_
`rot. 21. no. 12. pp. 993-999. Des. 1978.
`for dis-
`end accounting
`1141B. C. Neuman, Proxy-based
`authorizatlofl
`tributed
`systems. Proc. 13th Int'l Conf. on Distributed Computing
`Systems, PP. 283-291, May 1993.
`[1 S] B. C. Neuman and S. G. Stubblebine, A note on the use of times-
`tamps as nonces, Operating
`5y$. Rev., voh 27, no. 2, pp. 10-14.
`April 1993.
`116] R. L. Rarest. A. Shamir, and L. Adleman, A method for obtaining
`digital signatures and public
`key cryptosystems, Commun, of the
`AOM, v