Proxy-Based Authorization and Accounting for Distributed Systems
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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.
283
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-
Capabilities
Service
Authorization
Delegation
Service
Group
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.
284
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
C
3
S
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.
285
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
286
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
287
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.
288
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.
289
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.
members.
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.
290
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 info-kerberos@mit.edu. 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. bcn@isi.edu.
291
Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, May 1993.You can also read
