Proxy-Based Authorization and Accounting for Distributed Systems

Proxy-Based Authorization and Accounting
                             for Distributed Systems
                                            B. Cli ord Neuman
                                       Information Sciences Institute
                                      University of Southern California

                     Abstract                                      This paper presents a uni ed model for authentica-
                                                                tion, authorization, and accounting that is based on
   Despite recent widespread interest in the secure au-         proxies. Section 2 de nes the term proxy and brie y
thentication of principals across computer networks             describes how proxies can be supported by existing
there has been considerably less discussion of dis-             authentication mechanisms. The use of proxies for au-
tributed mechanisms to support authorization and ac-            thorization is demonstrated in Section 3. The proxy
counting. By generalizing the authentication model to           model strikes a balance between access-control-list and
support restricted proxies, both authorization and ac-          capability-based mechanisms allowing each to be used
counting can be easily supported. This paper presents           where appropriate and allowing their use in combi-
the proxy model for authorization and shows how the             nation. Section 4 discusses the necessary features of a
model can be used to support a wide range of au-                distributed accounting service and shows how account-
thorization and accounting mechanisms. The proxy                ing ts the model. Section 5 discusses related work on
model strikes a balance between access-control-list and         distributed authorization and accounting. Integration
capability-based mechanisms allowing each to be used            of the described mechanisms with existing authentica-
where appropriate and allowing their use in combina-            tion systems is discussed in Section 6, and Section 7
tion. The paper describes how restricted proxies can            discusses some of the more useful restrictions that can
be supported using existing authentication methods.             be supported. Section 9 draws conclusions.

1 Introduction                                                  2 Restricted proxies
   The problem of authentication across computer                   A proxy is a token that allows one to operate with
networks has received much attention in recent years.           the rights and privileges of the principal that granted
Authentication is often only a step in the process of           the proxy. Naturally, it must be possible to verify that
authorization or accounting. The goal is to verify that         a proxy was granted by the principal that it names.
the individual making a request is authorized to do so,         This is an authentication problem. In fact a principal
or to guarantee that the correct individual is charged          with the credentials1 needed to authenticate itself can
for an operation. Despite the close ties among these            often grant a proxy to another principal simply by
problems, little progress has been made in providing            passing on those credentials.
secure, widespread, distributed mechanisms for autho-              Implementing proxies in this manner has several
rization and accounting. To date, authorization and             shortcomings. First, the proxy can be used by anyone
accounting have most often been supported locally by            that gets hold of it. This won't always be a prob-
a server, instead of by the use of distributed autho-           lem, but in many cases one should be able to specify
rization or accounting services. Such authorization             the principal that is to act on one's behalf. Second, a
and accounting services will be critical as the network         proxy is all or nothing. The individual who has been
is used more and more for electronic commerce and               granted the proxy can do anything that the grantor
other applications where clients and servers not previ-         could do on any service to which the original creden-
ously known to one another must interact. By gener-             tials applied.
alizing the authentication model to support restricted
proxies, distributed authorization and accounting can              1Credentials consist of an encrypted certi cate together with
be easily supported.                                            information needed to use the certi cate.

         Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, May 1993.
Certi cate: [    restrictions; Kproxy     ]grantor
   Proxy-key: proxy
                  K                                                                                  Accounting

              Figure 1: A restricted proxy
    A restricted proxy is a proxy that has had condi-




tions placed on its use. A principal possessing au-
thentication or authorization credentials can generate
a restricted proxy, a new set of credentials which are
more restricted than the original credentials; it is not                             Restricted Proxies
possible to remove restrictions. It must be possible                           Base Authorization Mechanism
for the server to which a restricted proxy will be pre-
sented (the end-server) to verify that the restrictions
have not been tampered with. Among the restrictions                                Authentication Infrastructure
that are often speci ed are that the proxy may only be
used by a designated principal, or that the operations                     Figure 2: Relationship of security services
that may be performed are to be restricted.                         a separate encryption (or integrity) key. When a re-
    When a principal issues a restricted proxy to an-               stricted proxy is transferred from the grantor to the
other principal, the second principal is authorized to              grantee, care must be taken to protect the proxy key
perform all operations for which the rst principal is               from disclosure.
authorized on the server or servers for which the proxy                There are two classes of proxies: bearer proxies and
is applicable, subject to any restrictions recorded in              delegate proxies. A bearer proxy may be used by any-
the proxy. In the discussion that follows, the grantor              one. A delegate proxy may only be used by a principal
is the principal on whose behalf a proxy allows access.             named in a list of delegates (encoded as a restriction),
The grantee is the principal designated to act on behalf            or by someone with a suitable additional proxy issued
of the grantor. The end-server is the server to which               by a named delegate.
the proxy must be presented to perform an operation.                   To present a bearer proxy to an end-server, the
    The implementation of restricted proxies relies on              grantee sends the certi cate to the server and uses the
the use of encryption-based authentication of the orig-             proxy key to partake in an authentication exchange
inal grantor of the proxy. Either conventional or                   with the end-server using the underlying authentica-
public-key cryptography may be used. In this section                tion mechanism. Usually this exchange involves send-
I describe the implementation at a high level, inde-                ing a signed or encrypted timestamp or server chal-
pendent of the authentication mechanism in use. The                 lenge, proving possession of the proxy key.
description assumes that the infrastructure needed to
authenticate the original grantor of a proxy is in place               To present a delegate proxy, the grantee sends the
and messages required by the underlying authentica-                 certi cate to the end-server and then authenticates
tion protocol (e.g., for key distribution) are omitted              itself to the end-server under its own identity. The
for clarity. These details, which are speci c to the un-            end-server validates the certi cate and veri es that
derlying authentication mechanism, are described in                 the client is included in the list of delegates speci ed
Section 6.                                                          by the proxy.
    A restricted proxy has two parts: 1) a certi cate
signed by the grantor establishing the proxy, enumer-
ating any restrictions, and establishing an encryption              3 Authorization
(or integrity) key2 to be used by the end-server to ver-
ify that the proxy was properly issued to the bearer,                  Restricted proxies provide the vehicle for imple-
and 2) a proxy key, an encryption (or integrity) key                menting a wide range of authorization mechanisms in
corresponding to the key embedded in the certi cate,                distributed systems. In this section I describe sev-
that will be used by the grantee to prove proper pos-               eral such mechanisms and show how they can be sup-
session of the proxy. Figure 1 shows the contents of a              ported. Accounting mechanisms are described in Sec-
restricted proxy; square brackets indicate a signature              tion 4 and build upon the authorization mechanisms
by the principal indicated in the subscript, or under               described here. Figure 2 shows the relationship of such
  2 Depending on the authentication mechanisms in use, this         mechanisms to restricted proxies and to the authenti-
key may require additional protection from disclosure.              cation infrastructure on which they depend.

         Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, May 1993.
3.1 Capabilities                                                                                    R
    A capability can be thought of as a bearer proxy
that is restricted to limit the operations that can be
performed and the objects that can be accessed. No                                        2
restrictions are placed on the identity of the grantee                                          1
who is free to pass the capability to others. When
presented to the end-server, the grantor's rights (as
limited by the restrictions) are available to the bearer.                    0
    For example, to create a read capability for a par-
ticular le, a user authorized to read that le requests            1. Authenticated authorization request (operation X)
a restricted proxy for use at the le server containing            2. [operation X only]R, {Kproxy}Ksession
the le (the end-server), but with the restriction that            3. [operation X only]R, authentication using Kproxy
it can only be used to read the named le. The ca-
pability is then passed to others who can themselves                       Figure 3: The authorization protocol
pass it on. To use a capability, the bearer presents              requested by an authorized client, the authorization
it to the le server in place of (or in addition to) the           server grants a restricted proxy allowing the autho-
bearer's own credentials. If the request is to read the           rized client (the grantee) to act as the authorization
  le named in the capability, the operation is performed          server for the purpose of asserting the client's rights
with the rights of the grantor of the proxy.                      to access particular objects. The restrictions in the
    A capability as described above di ers from tradi-            proxy (in this case a list of authorized actions) are
tional capabilities in several ways. One of the most              determined by consulting the authorization server's
important distinctions is that in presenting a capa-              database or applying other suitable heuristics.
bility (restricted proxy) to the end-server, the bearer              Figure 3 shows the messages involved when client C
does not send the entire proxy across the network. In-            uses authorization server R for authorization to end-
stead, the bearer sends the certi cate part of the proxy          server S. The solid lines represent messages in the au-
and proves possession by taking part in an authentica-            thorization protocol. The initial request for autho-
tion exchange using the proxy key as described earlier.           rization is authenticated using the underlying authen-
The result is that an attacker can not obtain such a              tication protocol. The authorization credentials (a re-
capability by tapping the network to observe the pre-             stricted proxy) returned in 2 consist of a certi cate
sentation of capabilities by legitimate users.                    and a proxy key. The proxy key is returned protected
    A second distinction is that, as described above,             from disclosure by encrypting it under the session key
a capability allows a restricted impersonation of the             exchanged during authentication with R (encryption
grantor, not direct access to the named object. This              is represented by curly braces fg). To use the proxy,
means that one can revoke a capability by changing                the client presents the proxy to the end-server, par-
the access rights available to the grantor of the ca-             taking in an authentication exchange as described in
pability. Such a change would a ect all capabilities              Section 2. Message 0, the dashed line in the gure,
that had been issued by that grantor (as well as any              represents a priori knowledge about the authoriza-
copies), but not those that had been issued by others.            tion credentials needed for server S. This information
If the only principal with a priori access to an object           might be speci ed as part of the application protocol,
is its owner, this distinction disappears as there can            retrieved from a name server, or obtained from the
be only one original grantor.                                     end-server directly.
    A nal distinction, as implemented on most authen-                An end-server wishing to use the services of an au-
tication systems, is that the resulting capability would          thorization server would grant full or the maximum
have an expiration time. This is a feature. If a non-             desired access to the authorization server (this is de-
expiring capability is desired, the expiration time can           scribed in detail in Section 3.5).
be set suciently far in the future.                              3.3 A group server
3.2 An authorization server                                          A group server implemented using restricted prox-
                                                                  ies grants proxies that delegate the right to assert
   An authorization server implemented using re-                  membership in a particular group. The protocol is
stricted proxies does not directly specify that a par-            the same as that for the authorization server in g-
ticular principal is authorized to use a particular ser-          ure 3; the authorized operation is the assertion of
vice or access a particular object. Instead, when                 group membership.

         Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, May 1993.
Certi cate: [                  1
                 restrictions ; Kproxy    1]grantor                 Cascaded authorization is a little di erent for del-
 Certi cate: [   restrictions   2; Kproxy 2 ]Kproxy 1            egate proxies. To pass a delegate proxy to a subordi-
                                                                 nate, an intermediate server provides the subordinate
 Certi cate: [   restrictions   3; Kproxy 3 ]Kproxy 2
                                                                 with the certi cate from the original proxy. Because
 Proxy-key: proxy3
                K                                                the intermediate server is explicitly named in the orig-
                                                                 inal proxy, it also grants the subordinate a new proxy
               Figure 4: Cascaded proxies                        allowing the subordinate to act as the intermediate
    A group server might maintain more than one                  server for the purpose of executing the original proxy.
group. The name of a group as asserted by the group              Instead of signing the new proxy with the proxy key
server is unique only for a particular group server (or          from the original proxy, it is signed directly by the
a small set of servers). As such, a global name of a             intermediate server. An important di erence between
group is composed of the name of the group server,               the two approaches to cascaded authorization is that
and the name of the group on that server.                        the use of a delegate proxy leaves an audit trail since
                                                                 the new proxy identi es the intermediate server.
    It should be possible for the name of a group to                A distinct di erence between the cascaded authen-
appear in authorization databases anywhere that the              tication approach described by Sollins and the ap-
name of any other principal might appear. This might             proach described here is that in Sollins's approach the
be on the end-server, or in an authorization server, or          end-server has to contact the authentication server to
even on another group server. An end-server wishing              verify the authenticity of a chain of proxies.
to use a group server would include the name of a
group in its authorization database. A client would              3.5 Access-control-lists and capabilities
obtain a group proxy from the group server and send
it to the end-server when requesting an operation. The               By basing authorization on the proxy model, ap-
end-server would verify the authenticity of the proxy            plication servers can easily combine the bene ts of
and the identity of the client, and if valid perform the         access-control-lists and capability-based authorization
operation.                                                       mechanisms. Application servers would be designed
    If the end-server's authorization database is main-          to base authorization on a local access-control-list.
tained by an authorization server, then the client               Where a capability-based approach is required, the
would present the group proxy to the authorization               access-control-list would contain a single entry naming
server, and if all checks out, the authorization server          the principal (perhaps the server itself) authorized to
would return an authorization proxy to be used by the            grant capabilities for server operations.
client as described in the previous subsection.                      Similarly, when appropriate to hand o the autho-
3.4 Cascaded authorization                                       rization function to a centrally maintained authoriza-
                                                                 tion or group server, the name of the authorization
   In a paper on cascaded authentication [11], Sollins           or group server would be added to the local access-
proposed a method to pass authorization from party               control-list. In fact, if local autonomy is desired, local
to party when a task involves cascaded operations by             users might appear directly in the access-control-list
parties that do not completely trust one another. A              together with the name of an authorization server to
similar mechanism is supported more eciently by re-             which the function of authorizing remote users has
stricted proxies.                                                been assigned.
   By its de nition, a proxy allows one principal to                 Since the same access-control-list abstraction
perform an operation on behalf of another. An inter-             should be used on the authorization servers as on other
mediate server that has been granted a bearer proxy              servers, access-control-list entries can support an asso-
can pass that proxy to a subordinate server (the next            ciated list of restrictions. On an authorization server,
server in the pipeline) with additional restrictions ap-         the restrictions eld of a matching access-control-list
plied. Restrictions are added by signing a new proxy             entry can be copied to the restrictions eld of the re-
with the proxy key from the original proxy. The new              sulting proxy. These would be in addition to restric-
proxy speci es any additional restrictions and a new             tions transferred from any proxies presented to the
proxy key. The certi cates from both proxies are pro-            authorization server or those imposed by the server
vided to the subordinate server, but only the proxy              itself.
key from the nal proxy in the chain is provided. Fig-                Finally, by supporting compound principal identi-
ure 4 shows a chain of proxies that might be provided              ers in access-control-list entries, it becomes possible
to a subordinate server.                                         to require the concurrence of multiple principals for

         Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, May 1993.
certain operations. Among other things, this func-                                              E2
tionality allows one to specify the need for both user                          $1                            $2
and host credentials for certain operations as well as
the separation of privilege so that a single user can't
act alone. Proxy-based authorization allows a user to                               E1

obtain proxies from more than one grantor for a par-                                        check
ticular operation, providing the mechanism by which                             S                              C
the user would assert such concurrence.
4 Accounting                                                       check: [ckno,amount,S]C
                                                                      E1: [ckno,amount,S]C [dep ckno to $1]S
    Section 3 showed how restricted proxies support a                 E2: [ckno,amount,S]C [dep ckno to $1]S [dep ckno to $2]$1
wide range of authorization mechanisms. Accounting                               Figure 5: Processing a check
is closely tied to authorization; in fact, the two are in-
terdependent. Authorization depends on accounting                      Figure 5 shows the messages involved in issuing and
when a server veri es that a client has been allocated             clearing such a check. In the gure, accounting servers
sucient resources (e.g, quota) to perform an opera-               are labeled by $s. The rst message represents a check
tion. Conversely, accounting depends on authorization              signed by C drawn on C's accounting server $2 made
to control the transfer of resources from one account              payable to server S. Upon completion of C's request, S
to another.                                                        endorses the check and deposits it with its accounting
    In our design, accounts are maintained on account-             server in message E1. The endorsement is a restricted
ing servers. At a minimum, each account contains                   proxy that will be used for cascaded authorization. A
a unique name, an access-control-list, and a collec-               restricted endorsement (e.g. for deposit only) is a del-
tion of records, each record specifying a currency and             egate proxy, an unrestricted endorsement is a bearer
a balance. Accounting servers support multiple cur-                proxy.
rencies, either monetary (dollars, pounds, or yen) or                  In this case, C and S do not share the same ac-
resource speci c (disk blocks, cpu cycles, or printer              counting server, so $1 marks the resources added to
pages). Quotas are implemented by transferring funds               S's account as uncollected, adds its own endorsement
of the appropriate currency out of an account when the             and forwards the check to $2 in message E2. If nec-
resource is allocated and transferring the funds back
when the resource is released. Accounts are identi-                essary, such endorsements can be repeated until the
  ed as the composition of the principal identi er for             check reaches the client's accounting server, but in this
the accounting server and the name of the account on               case only one additional step is necessary. This dis-
the server. It is possible to transfer resources from an           tributed method for accounting requires out-of-band
account on one server to one on another.                           mechanisms to deal with checks returned for insuf-
    The transfer of resources can be accomplished                    cient resources, or because they are forged or mis-
through two distinct mechanisms. The simplest mech-                drawn, but the same is true in the real world.
anism is used when no guarantee is required that suf-                  The second approach for transferring resources is
  cient resources exist. A principal authorized to debit           used when a server requires a guarantee that sucient
an account (the payor) issues a numbered delegate                  resources have been allocated to the client, as is often
proxy (a check) authorizing the payee to transfer funds            the case when maintaining quotas. The approach is
from the payor's account to that of the payee. This                analogous to that of a certi ed check. The client draws
check limits the resources that can be transferred, and            a check and provides the details (the check number,
the payee transfers up to that limit. If the payor uses            the party to be paid, and the amount) to the account-
a di erent accounting server than the payee, the payee             ing server. The accounting server places a hold on the
grants its own accounting server a cascaded proxy                  resources and returns an authorization proxy to the
(endorsement) for the check allowing the accounting                client certifying that the client has sucient resources
server to collect the resources on its behalf. Subse-              to cover the check. The client presents the authoriza-
quent accounting servers repeat the process until the              tion proxy and the check to the end-server along with
payor's accounting server is reached. Once a check is              its application request.
paid, the accounting server keeps track of the check                   Once the requested operation is performed, the end-
number until the expiration time on the check. If,                 server negotiates the check as described earlier. When
within that period, another check with the same num-               the check reaches the client's accounting server, the
ber is seen, it is rejected.                                       accounting server looks for the check in its list of

         Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, May 1993.
outstanding certi ed checks, and if found, makes the                Certi cate: f                           g ,1
                                                                                    restrictions; Kproxy Kgrantor
transfer. Cashier's checks are also easily supported                              ,1
                                                                    Proxy-key: proxy
by this accounting model; the details are left as an                              K

exercise for the reader.                                                 Figure 6: A public-key restricted proxy
5 Related work                                                   or when granting access to individual objects. Roles
                                                                 can not be used to implement the authorization server
   This section describes other work that has been               described in Section 3.2.
done on authorization and accounting for distributed                Functionality similar to that of the authorization
systems. Some of the earliest work in the area is found          and group services of Sections 3.2 and 3.3 has been
in Grapevine [2] where end-servers query registration            proposed as part of the European Computer Man-
servers to determine whether a client is a member of             ufacturers Association standard for security in open
a particular group. A similar approach is employed in            systems [1]. The ECMA standard de nes Privilege
Sun's Yellow Pages where centrally maintained les                Attributed Certi cates (PACs) signed by an author-
such as /etc/group are consulted for authorization               ity and certifying that the bearer or a named principal
purposes. In both approaches, the authorization de-              possess certain privileges.
cision remains with the local system. With the dis-                 Work is underway for the Open Software Founda-
tributed authorization and group services supported              tion's Distributed Computing Environment that uses
by restricted proxies, the authorization decision can            restricted proxies as supported by Kerberos to pass au-
be delegated to a remote server.                                 thorization information. In particular, they have im-
   There have been several proposals concerning for-             plemented a privilege attribute server that signs cer-
warding and delegation of authentication in dis-                 ti cates asserting a principal's unique identi er and
tributed systems. Karger [6] proposed a server that              a set of user groups to which the principal belongs.
keeps track of special passwords that are established            Plans are in place to extend their mechanism to sup-
when a user logs in. These passwords are passed to               port delegation [3].
other systems which act on the user's behalf for opera-             Surprisingly little attention has been paid to the
tions that require the cascaded use of multiple servers.         issue of accounting in distributed systems. Sentry [9]
This scheme is not encryption-based, but relies on se-           lays the groundwork for accounting by describing a
cure channels for passing the special passwords. These           mechanism that would be co-located with an authenti-
channels might be implemented on top of an end-to-               cation and authorization server. Although they share
end encryption mechanism.                                        a common mechanism, it seems apparent now that
   A mechanism that comes close to restricted proxies            there is little to be gained by requiring all three ser-
is the cascaded authentication mechanism described               vices to be co-located. Like the accounting mechanism
by Sollins [11] in which restrictions can be added as            described here, Sentry pointed out the need to support
credentials are passed from system to system. The                multiple currencies.
di erences between Sollins' approach and proxy-based                Amoeba [8] supports a distributed bank server iden-
cascaded authorization was described in Section 3.4.             tical in purpose to the accounting server based on re-
   The proxy model described by this paper was de-               stricted proxies. The protocol used by Amoeba's bank
signed for use in Version 5 of the Kerberos authentica-          server is signi cantly di erent, however. In Amoeba,
tion system. Support for proxies was rst included in             a client must contact the bank and transfer funds into
the Kerberos protocol speci cation in mid 1989 [7]. At           the server's account before it contacts the server. The
about the same time, another mechanisms for delega-              server will then provide services until the pre-paid
tion was developed as part of the Digital Distributed            funds have been exhausted. Like the mechanism de-
System Security Architecture [4, 5]. In the DSSA,                scribed here, Amoeba supports multiple currencies.
principals generate and sign delegation certi cates to
allow intermediate systems to act on their behalf. An            6 Integration with existing systems
important di erence is that in the DSSA, restrictions               It is straightforward to implement restricted prox-
are supported only by creating separate principals,              ies using encryption-based authentication mechanisms
called roles, and by generating a delegation certi -             based on either public-key or conventional cryptogra-
cate for one of the roles instead of for the original            phy. This section shows how proxies can be imple-
principal. The delegation then supports only access              mented with either approach and describes the speci c
speci cally authorized for that role. The creation of            details of their support in Version 5 of the Kerberos
a new role is cumbersome when delegating on the y                authentication system.

         Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, May 1993.
6.1 Public-key cryptography                                      tains the name of the authenticated principal and a
   The certi cate for a public-key proxy contains a              session key. It is encrypted using the secret key shared
proxy key generated by the grantor, the expiration               by the end-server and the Kerberos server. The ses-
time of the proxy, and the restrictions imposed its use.         sion key is never sent across the network in the clear.
The proxy key embedded in the proxy certi cate is a              The session key is returned to the client encrypted in
public key from a public/private key pair. The proxy             the session key shared by the client and the Kerberos
key provided to the grantee is the other key from that           server.
pair. All elds are signed by encrypting them with the               To prove its identity, a client sends the ticket to the
grantor's private key. Figure 6 shows a proxy gener-             end-server along with an authenticator which has been
ated in this manner. The signed proxy is additionally            encrypted using the session key. The authenticator
tagged with the name of the grantor to enable those              proves that the client actually possesses the session key
needing to verify the proxy to select the correct key.           included in the ticket. Without this step an attacker
                                                                 would be able to reuse a ticket that it obtained by
   If the authentication system is purely public-key,            eavesdropping on an earlier exchange.
a public-key digital signature algorithm can be used                Kerberos has been in use at MIT since Fall of 1986,
in place of the encryption system and the encryption             and it has been used elsewhere since then. Version 5 of
step would be replaced by the sealing of the certi cate          Kerberos [7] is the rst major revision of the protocol
with a cryptographic checksum. If a hybrid authenti-             since its original release and contains several new fea-
cation system is used, where subsequent keys are from            tures important for the practical support of restricted
a conventional cryptosystem, then the proxy key is               proxies. The inclusion of explicit support for prox-
a conventional key generated by the grantor and the              ies in Version 5 makes their use more transparent to
proxy key must be additionally encrypted in the public           applications which have already been modi ed to use
key of the end-server to protect it from disclosure.             Kerberos.
   The proxy is returned to the grantee. When the                   The Version 5 ticket and authenticator each have
grantee presents the proxy to an end-server, the end-            a new eld called authorization-data. This eld con-
server decrypts the proxy using the public key of                sists of an arbitrary number of typed sub- elds, each of
the grantor (obtained from an authentication/name                which places restrictions on the use of the ticket. The
server), veri es the authenticity of the proxy, accepts          Kerberos protocol does not specify how the sub- elds
additional authentication from the grantee (either per-          are to be interpreted except to stress that restrictions
sonal authentication for a delegate proxy or proof that          must be additive. Each sub eld places additional re-
it knows the proxy key for a bearer proxy), checks               strictions on the use of credentials, never removing
the restrictions, and if all checks out, performs the            restrictions or granting additional privileges.
requested operation.                                                When tickets are requested, the requesting princi-
6.2 Restricted proxies in Kerberos                               pal can specify that restrictions be placed on their use.
                                                                 When new tickets are issued based on existing creden-
   A proxy implemented using an authentication sys-              tials, restrictions may be added, but not removed. To
tem based on conventional cryptography is identical              add restrictions to an existing ticket, a client gener-
to that in gure 6 except that the proxy is accompa-              ates an authenticator specifying a proxy key in the
nied by credentials authenticating the grantor to the            subkey eld and specifying additional restrictions in
end-server. The proxy certi cate is encrypted using              the authorization-data eld. The ticket and authenti-
the session key generated by an authentication server,           cator are treated as the new proxy and provided with
the session key also having been earlier sealed in the           the new proxy key to the grantee. Once obtained, the
credentials. The proxy key is a secret key generated             grantee can use such a proxy the same way it uses any
by the grantor. This key is both sealed in the proxy             other credentials issued by the authentication system.
certi cate and securely passed to the grantee. The re-
mainder of this section describes the integration of re-         6.3 Discussion
stricted proxies with Kerberos [12], an authentication              Supporting proxies within an authentication mech-
system based on conventional cryptography developed              anism has several advantages. Transparency is one ad-
as part of MIT's Project Athena.                                 vantage; a second is that the initial authentication of a
   Kerberos credentials are issued by an authentica-             user can itself be thought of as the granting of a proxy
tion server and presented by a client to prove its iden-         and restrictions can be placed on the credentials based
tity to a particular end-server. Credentials consist of          on the characteristics of the initial exchange with the
two parts: a ticket, and a session key. The ticket con-          authentication server.

         Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, May 1993.
A disadvantage of using conventional cryptography              7.5 Authorized
to implement proxies is that each proxy can be used at                The authorized restriction speci es a complete list
only a particular end-server. This is o set by imple-             of those objects which may be accessed using the rights
menting proxies within Kerberos itself since it is possi-         granted by a proxy and optionally a list of operations
ble to issue a proxy for the Kerberos \ticket-granting"           that may be performed on each object. This restric-
service. Such a proxy allows the grantee to obtain                tion usually appears in proxies used as capabilities.
proxies with identical restrictions for additional end-           It also appears in proxies returned by an authoriza-
servers as needed.                                                tion server. There are no constraints on the form of
7 Common restrictions                                             the object names or the list of operations other than
   The restrictions eld of a proxy should be inter-               that the grantor and the end-server must agree. These
preted as a collection of typed sub elds, each type                 elds are to be interpreted by the end-server.
corresponding to a di erent restriction. This section             7.6 Group-membership
describes several of the more useful restrictions and                This restriction speci es that the grantee is a mem-
some that demonstrate the exibility of the model.                 ber of only the listed groups. It would be included in
Additional restrictions are described in [10]. Neither            a proxy issued by a group server to limit the groups to
should be construed as a complete list.                           which one is a member. Without this restriction, the
7.1 Grantee                                                       grantee would be considered a member of all groups
   This restriction speci es a list of principals autho-          maintained by the group server granting the proxy.
rized to use a proxy and the number of principals from            7.7 Accept-once
the list needed to exercise the proxy (usually one). To
use such a proxy a principal must present the authenti-              The accept-once restriction tells an end-server
cation credentials of a named grantee, or an additional           that it is only to accept a proxy one time. This re-
proxy granted by a named grantee, to the end-server               striction takes an identi er as an argument. Any sub-
along with the proxy. If the grantee restriction is               sequent proxy from the same grantor bearing the same
missing, the proxy is a bearer proxy and may be used              identi er and received by the end-server within the ex-
by anyone possessing it. To exercise a bearer proxy the           piration time of the rst proxy is rejected. A real life
bearer must take part in an authentication exchange               example of such an identi er is a check number.
proving possession of the proxy key thus preventing an            7.8 Limit-restriction
attacker from using a proxy obtained by eavesdropping                Restrictions that are de ned only for particular
on the network.                                                   end-servers are sometimes needed. If a proxy can be
7.2 For-use-by-group                                              used on a server to which some restrictions do not
   The for-use-by-group restriction speci es the list             apply, those restrictions must be associated with the
of groups authorized to use a proxy and the number                name of the server to which they do apply. This is
of groups from the list required. To use such a proxy,            accomplished with the limit-restriction restriction
the bearer presents the proxy along with additional               which takes a list of servers and a list of other restric-
proxies from appropriate group servers. One way to                tions. The restrictions embedded within this restric-
implement separation of privilege is to require asser-            tion will be enforced by the named servers and ignored
tion of membership in multiple groups with disjoint               by others.
7.3 Issued-for                                                    7.9 The propagation of restrictions
   The issued-for restriction speci es a list of servers             Authentication, authorization, and group servers
authorized to accept the proxy. This restriction is im-           accept proxies and issue proxies. If a proxy is issued
portant for public-key proxies which are otherwise ver-           based upon a proxy that includes restrictions, those
i able by and exercisable on all servers.                         restrictions should be passed on to the proxy to be is-
                                                                  sued. If a restriction is limited (see limit-restriction)
7.4 Quota                                                         then the restriction may be left out if it can be guar-
   The quota restriction speci es a currency and a                anteed that the proxy to be issued, and any proxies
limit. It limits the quantity of a resource that can be           that might later be derived from it, can not be used
consumed or obtained. It will most often be found in              for any of the servers listed in the limited restriction.
a proxy issued by an accounting server.

         Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, May 1993.
8 Status                                                         [4] M. Gasser, A. Goldstein, C. Kaufman, and
   A beta release of Kerberos Version 5 is avail-                    B. Lampson. The Digital distributed system secu-
able. The release includes support for restricted prox-              rity architecture. In Proceedings of the 1989 Na-
ies. Information on the Kerberos release is available                tional Computer Security Conference, pages 305{
from Authorization and                        319, October 1989.
accounting services built with restricted proxies are            [5] M. Gasser and E. McDermott. An architecture
being developed at the Information Sciences Institute                for practical delegation in a distributed system.
of the University of Southern California.                            In Proceedings of the 1990 IEEE Symposium on
                                                                     Security and Privacy, pages 20{30, May 1990.
9 Discussion and conclusions                                     [6] Paul A. Karger. Authentication and discretionary
   The problems of authentication, authorization, and                access control in computer networks. Computer
accounting are closely related. By subtly changing the               Networks and ISDN Systems, 10(1):27{37, 1985.
way one thinks about the problems, the similarities be-
come apparent. By extending an authentication sys-               [7] John T. Kohl and B. Cli ord Neuman. The Ker-
tem to support restricted proxies, it becomes possible               beros network authentication service: Version 5
to support exible distributed authorization and ac-                  draft protocol speci cation. August 1989. Re-
counting mechanisms. The proxy model strikes a bal-                  vised November 1989, October 1990, December
ance between access-control-list and capability-based                1990, June 1991, September 1992, April 1993.
mechanisms allowing each to be used where appropri-              [8] S. J. Mullender and A. S. Tanenbaum. The de-
ate and allowing their use in combination.                           sign of a capability-based distributed operating
   This paper has shown how restricted proxies can be                system. The Computer Journal, 29(4):289{299,
supported using existing authentication systems and                  1986.
how they are used for authorization and accounting.
The resulting mechanisms scale and appear natural                [9] B. Cli ord Neuman. Sentry: A discretionary
when compared with their analogues in society.                       access control server. Bachelor's Thesis, Mas-
                                                                     sachusetts Institute of Technology, June 1985.
Acknowledgments                                                 [10] B. Cli ord Neuman. Proxy-based authorization
   I would like to thank Celeste Anderson, Steven Au-                and accounting for distributed systems. Technical
gart, Steve Bellovin, Deborah Estrin, David Keppel,                  Report 91-02-01, Department of Computer Sci-
John Kohl, Ed Lazowska, Joe Pato, Karen Sollins, Bill                ence and Engineering, University of Washington,
Sommerfeld, Stuart Stubblebine, and Prasad Upasani                   March 1991.
for discussions of restricted proxies and comments on
drafts of this paper.                                           [11] Karen R. Sollins. Cascaded authentication. In
                                                                     Proceedings of the 1988 IEEE Symposium on Re-
                                                                     search in Security and Privacy, pages 156{163,
References                                                           April 1988.
                                                                [12] J. G. Steiner, B. C. Neuman, and J. I. Schiller.
 [1] European Computer Manufacturers Association.                    Kerberos: An authentication service for open
     Security in open systems: Data elements and                     network systems. In Proceedings of the Winter
     service de nitions, December 1989. Standard                     1988 Usenix Conference, pages 191{201, Febru-
     ECMA-138.                                                       ary 1988.
 [2] Andrew D. Birrell, Roy Levin, Roger M. Need-
     ham, and Michael D. Schroeder. Grapevine: An               This research was supported in part by the National Science
                                                                Foundation (Grant No. CCR-8619663), the Washington Tech-
     exercise in distributed computing. Communica-              nology Centers, Digital Equipment Corporation, and the De-
     tions of the ACM, 25(4):260{274, April 1982.               fense Advance Research Projects Agency under NASA Cooper-
                                                                ative Agreement NCC-2-539. The views and conclusions con-
 [3] Marlena E. Erdos and Joseph N. Pato. Extending             tained in this paper are those of the author and should not
     the OSF DCE authorization system to support                be interpreted as representing the ocial policies, either ex-
     practical delegation. In Proceedings of the PSRG           pressed or implied, of any of the funding agencies. The author
                                                                may be reached at USC/ISI, 4676 Admiralty Way, Marina del
    Workshop on Network and Distributed System                  Rey, CA 90292-6695, USA. Telephone +1 (310) 822-1511, email
    Security, pages 93{100, February 1993.            

         Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, May 1993.
You can also read
NEXT SLIDES ... Cancel