Kerberos: An Authentication
`Sewice for Computer Networks
`When using authentication based on cryptography, an attacker
`listening to the network gains no information that would enable it
`to falsely claim another’s identity. Kerberos is the most commonly
`used example of this type of authentication technology.
`
`B. Clifford Neuman and Theodore Ts‘o
`
`odern computer systems provide
`service to multiple users and
`require the ability to accurate-
`ly identify the user making a
`request. In traditional systems,
`the user’s identity is verified by
`checking a password typed during login; 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, itwas recent-
`ly demonstrated on a major scale with the discov-
`ery of planted password collecting programs at critical
`points on the Internet [4].
`
`Authentication, Integrity,
`Confidentiality, and
`Authorization
`A of a party who generated some data, and of the
`uthentication is the verification of the identity
`
`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.
`Dataintegrityis the 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
`at 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 otherssupport 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.
`Because these differences affect perfor-
`mance, it is important to understand the require-
`ments of an application when choosing a method.
`
`For example, authentication for electronic mail
`may require support for multiple recipients and
`non-repudiation, but can tolerate greater latency.
`In contrast, poor performance would cause prob-
`lems for authentication to a server responding to
`frequent queries.
`Other security services include confidentiality
`and authorization. Confidentiality is the protec-
`tion of information from disclosure to those not
`intended to receive it. Most strong authentication
`methods optionally provide confidentiality.
`Authorization is the process by which one deter-
`mines whether a principal is allowed to perform
`an operation. Authorization is usually performed
`after the principal has been authenticated, 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
`process is waiting for a response to a query or
`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
`T ciated with password-based authentication and,
`he introduction discussed the problems asso-
`
`in particular, how passwords can be collected by
`eavesdropping. In addition to the security con-
`cem, password based authentication is inconvenient;
`users do notwant to enter a password each time they
`access a network service. This has led to the use
`of even weaker authentication on computer 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, applications assert the identity
`of the user and the server believes it. Such authen-
`tication is easily thwarted by modifying the applica-
`
`CLIFFORD NEUMAN is a
`scient& at the Information
`Sciences Institute of the Uni-
`versity of Southem California.
`
`THEODORE TS’O leads the
`Kerberos V5 development
`effort at the Massachusetts
`Institute of Technology.
`
`IEEE Communications Magazine September 1994
`
`0163-6804/94/$04.00 1994 0 IEEE
`
`33
`
`Authorized licensed use limited to: Vishal Sharma. Downloaded on October 13,2020 at 09:46:32 UTC from IEEE Xplore. Restrictions apply.
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2023
`
`Page 1 of 6
`
`

`

`-
`
`The Kerberos
`Authentica -
`tion System
`uses a series
`of encrypted
`messages to
`prove to a
`verifier that
`a client is
`running on
`behalfof a
`particular
`usez
`
`tion. This may require privileged access to the
`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,
`addresses are themselves simply assertions.
`Stronger authentication methods based oncryp-
`tography are required. When using authentica-
`tion based on crytography, an attacker listening
`to thenetworkgainsnoinformation thatwould enable
`it to falsely claim another’s identity. Kerberos is
`the most commonly used example of this type of
`authentication technology. Unfortunately, strong
`authentication technologies are not used as often
`as they should be, although the situation is gradually
`improving.
`
`The Kerberos Authentication
`Service
`K vice that allows a process (a client), running on
`erberos is a distributed authentication ser-
`
`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
`allowanattacker or theverifiertosubsequentlyimper-
`sonate the principal. Kerberos optionally provides
`integrity and confidentiality for data sent between
`the client and server. Kerberos was developed in
`the mid-’t(Os as part of MIT’s Project Athena 121.
`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 S of Kerberos (V5) began in 1989 1111.
`Though V4 still runs at many sites, VS is consid-
`ered to be standard Kerberos [lo].
`Limitations of Kerberos
`Limitations of Kerberos have been described in the
`literature 111. Though most are a matter of pref-
`erence or apply to V4 and early drafts of V5, a few
`are fundamental and are discussed here. In par-
`ticular, Kerberos is not effective against password
`guessing attacks; if a user chooses a poor pass-
`word, then an attacker guessing that password
`can impersonate the user. Similarly, Kerberos
`requires a trusted path through which passwords
`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
`sufflcient information to impersonate theuser. Ker-
`beros can be combined with other techniques, as
`described 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 [ 141.
`
`How Kerberos Works
`
`The Kerberos Authentication System [ 181 uses a
`series of encrypted messages to prove to a verifier
`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], but 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 describes the Ker-
`beros protocol. The description is simplified for
`clarity; additional fields are present in the actual
`protocol. Readers should consult RFC 1510 1101
`for a more thorough description of the Kerberos
`protocol.
`Kerberos Encryption - Though conceptually,
`Kerberos authentication proves that a client is
`running on behalf of a particular 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.
`Encryption in the present implementation of
`Kerberos uses the data encryption standard
`(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 encryp
`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.
`The Kerberos ticket is a certificate issued by
`an authentication server, encrypted using the
`server key. Among other information, the ticket
`contains the random session key that will be used
`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
`
`34
`
`IEEE Communications Magazine September 1994
`
`Authorized licensed use limited to: Vishal Sharma. Downloaded on October 13,2020 at 09:46:32 UTC from IEEE Xplore. Restrictions apply.
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2023
`
`Page 2 of 6
`
`

`

`isnot possible fortheclient tomodify the ticketwith-
`out detection.
`
`Application Request and Response - Messages
`3 and 4 in Fig. 1 show the application request and
`response, the most basic exchange in the Ker-
`beros protocol.’ 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 t o the application request, a ticket
`(described above) and an authenticator. The authen-
`ticator includes, among other fields: the current time,
`a checksum, and an optional encryption key. all
`encrypted with the session key from the accompa-
`nying ticket.
`Upon receipt of the application request, the
`verifier decrypts the ticket, extracts the session
`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 isnot by itself sufficient for authenticationsince
`an attacker can intercept an authenticator and replay
`it later to impersonate the user. For this reason
`the verifier additionally checks the timestamp to
`makesure 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 timestamp 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 - 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-
`ular verifier, the client uses the authentication request
`and response, messages 1 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 the 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 serverreturns
`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 containingsimilar information, andwhich
`is to be forwarded to the verifier as part of the
`application rcquest. Together, the authentication
`request and response and the application request
`and response comprise the basic Kerberos authen-
`tication protc~col.
`
`IEEE Communications Magazine September 1994
`
`0 Figure 1 . Basic Kerberos authentication protocol (simplified).
`
`Obtaining Additional Tickets - The basic Ker-
`beros 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. Though a Ker-
`beros ticket and the key associated with it are
`valid for only a short time, the user’s password
`can be used to obtain tickets, and to impersonate the
`user until the password is changed. A better approach,
`and that used by Kerberos, is to cache only tickets
`and encryption keys (collectively called 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 relativeiy 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.
`Subsequently, when the user wishes to prove
`its identity to a new verifier, a new ticket is request-
`ed from the authentication server using the ticket
`granting exchange. The ticket granting exchange
`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.
`
`’Messages I and 2are
`described in thesection on
`authentication request
`and response.
`
`3s
`
`Authorized licensed use limited to: Vishal Sharma. Downloaded on October 13,2020 at 09:46:32 UTC from IEEE Xplore. Restrictions apply.
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2023
`
`Page 3 of 6
`
`

`

`-
`
`Clientlsewer
`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.
`Protecting Application Data - As described so
`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. T h e 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
`method better suited to the particular data that is
`transmitted.
`
`Additional Features - The description of Ker-
`beros just presented was greatly simplified. Addi-
`tional fields are present in the ticket, authenticator,
`and messages, to support bookkeeping and addi-
`tional functionality. Some of the features present
`in Version5 include renewable and fonvardable tick-
`ets, support for higher level authorization mecha-
`nisms, and support for multi-hop cross-realm
`authentication (described in the following sec-
`tion). Amore rigorous presentation of the Kerberos
`protocol, and a description of each field is found
`in RFC 1510 [lo].
`
`Kerberos Infrastructure and
`Cross- Realm Authentication
`I it is not appropriate for all users to be regis-
`n a system that crosses organizational boundaries,
`
`tered 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
`exchange to request a ticket for the verifier from
`the verifier’s authentication server, which detects
`that the ticket granting ticket was issued in a for-
`eign realm, looksup the cross-realm key,verifies the
`validity of ticket granting ticket, and issues a tick-
`et and session key to the client.The name ofthe client,
`embedded in the ticket, includes the name of the
`realm in which the client was registered.
`With Version 4, it was necessary for an authen-
`tication server to register with every other realm
`
`with which cross-realm authentication was required.
`This was not scalable; complete interconnection
`required the exchange of rzz 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 IS1 . EDU realm
`shares a key with the EDU realm, which also shares
`keyswithMIT.EDU,USC. EDU,andWASHINGTON. EDU.
`If no key is shared directly by ISI. EDU and
`M I T . EDU, authenticationoftheclientbcn@IsI. EDU
`to a server registered with the MIT. EDU realm
`proceeds by obtaininga ticket grantingticket for EDU
`from the ISI. EDU authentication server, using
`that ticket granting ticket to obtain a ticket grant-
`ing ticket for theMIT. EDUrealm from the ~ a u t h e n -
`tication server, and finally obtaining a ticket for the
`verifier from the MIT. EDU authentication server.
`The list of realms that are transited during
`multi-hop cross-realm 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-
`formance of the authentication process.
`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 availabilityofauthentication serversfor realms
`near the top of the hierarchy. Unfortunately,
`political and legal ambiguity has the potential toslow
`the establishment of these realms. In the mean time,
`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].
`0 b ta in in g an d Usin g Kerb e ros
`S are freely available from MIT, however, MIT
`ource code releases for V4 and Beta V5 Kerberos
`
`does not officially support these releases. Several
`companies have taken reference implementations
`from MIT and 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 t o the Usenet
`newsgroup comp .protocols. kerberos, or by
`sending a message to info-kerberos@mit . edu.
`Setting up the Authentication Server
`Since the Kerberos authentication server maintains
`adatabaseofpasswords (encryption keys) for all the
`users at a site, it is extremely important that it be
`installed on acarefully protectedand 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 regktered
`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
`adriver’slicense, passport,orotherphysicaldocument.
`
`36
`
`IEEE Communications Magazine September 1994
`
`Authorized licensed use limited to: Vishal Sharma. Downloaded on October 13,2020 at 09:46:32 UTC from IEEE Xplore. Restrictions apply.
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2023
`
`Page 4 of 6
`
`

`

`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 login program can be modified to register
`the passwords ofnon-registered users afterverifying
`that the password isvalid. 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 (kinit), destroy credentials (kdestroy),
`list credentials ( k l i s t ) , and change their Ker-
`beros password (kpasswd). Some sites choose to
`integrate the Kerberos login tool k i n i t 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.
`Using “Kerberized” Applications
`Clientiserver applications must be modified to
`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
`provisionsfor an authenticationexchange. The appli-
`cation program must generate and send a Ker-
`beros 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 clientisewer protocol. The Kerberos
`library provides routines that generate and verify
`these messages.
`More recent implementations of Kerberos pro-
`vide a Generic Security Services Application Pro-
`grammer Interface (GSSAPI)[ 121. The GSSAPI
`provides a standard programming interface which
`is authentication mechanism independent. This
`allows the application programmer to design an
`application and application protocol whichcan use
`a1 ternative authentication technologics, including
`Kerberos. The use of the GSSAPI in application pro-
`grams is recommended wherevcr possible.
`Because it is a generic authentication inter-
`face, the GSSAPI 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.
`
`Figure 2. Complete Kerberos authentication protocol (simp[@ed).
`
`Other Approaches for
`Improving Security
`K security problems. Several limitations have been
`erberos is not a complete solution to network
`
`mentioned in this article. Other tools can 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.
`
`One-Time Passcodes
`Aone-time passcode authentication mechanism uses
`a different passcode each time authentication is
`required. Kerberos does not protect against the theft
`of apassword through aTrojan horse login program
`on the user’s workstation, but if the user’s pass-
`word were to change each time it wasentered, 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 thechallenge 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 toverify 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 entry of the passcode on
`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.
`Commercial products that combine one-time
`passcodes with Kerberos are available.
`
`IEEE Communications Magazine September 1994
`
`37
`
`Authorized licensed use limited to: Vishal Sharma. Downloaded on October 13,2020 at 09:46:32 UTC from IEEE Xplore. Restrictions apply.
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2023
`
`Page 5 of 6
`
`

`

`-
`
`Work is
`underway to
`add public-
`key support
`to Kerberos,
`where it can
`be confined
`to the initial
`request for
`U ticket
`granting
`ticket.
`
`Public-Key Cryptography
`
`In public-key cryptography, encryption and
`decryption are performed using a pair of keys
`such that knowledge of one key does not provide
`knowledge of the other key in the pair [7]. One
`key is published and is called the public key, and
`theotherkey is keptprivate. Thissecond key iscalled
`the private key, not to be confused with a secret
`key, which is shared by the parties to communica-
`tion in a conventional cryptosystem (it takes two
`to share a secret, but once you tell something to
`anyone else it is no longer private). Public-key
`cryptography has several advantages over conven-
`tional cryptography when used for authentica-
`tion. These include more natural support for
`authentication to multiple recipients, support for
`non-repudiation (since the verifier does not know
`the private key, it can't generate a message that
`purports to be from the authenticated principal),
`and the elimination of secret encryption keys
`from the central authentication server.
`While public-key encryption iswell suitedfor use
`in authentication by store and forward applica-
`tions such as electronic mail [9], and it is required
`by applicationswhere a signature isverified by many
`readers [17], performance is a problem for servers
`that perform many authentication operations. With
`the RSA [ 161 algorithm, the most accepted algorithm
`for public key cryptography, the private key oper-
`ation (signingordecrypting amessage) isexpensive.
`Work is underway to add public-key support
`to Kerberos, where it can be confined to the ini-
`tial request for a ticket granting ticket, allowing users
`with registered public keys (perhaps for privacy-
`enhanced mail) to obtain Kerberos tickets for appli-
`cation servers supporting Kerberos authentication.
`Subsequent exchanges, especially the application
`request, would use conventional cryptography for
`better performance. Public-key encryption may also
`be used by authentication servers to exchange
`conventional cross realm keys on-demand between
`authentication servers, with the cost amortized over
`many requests.
`Summary
`A puter systems. Without knowledge of the iden-
`uthentication is critical for the security of com-
`
`tity of a principal requesting an operation, it is
`difficult to decide whether the operation should
`be allowed. Traditional authentication methods are
`not suitable for use in computer networks where
`attackers monit