Delegation of Responsibilities

Abstract

ivered to the person accountable for it. We cannot technically establish who is going to be legally, morally or socially liable for an action. Our goal is, more modestly but still quite difficult, to determine who, technically, performed a specific action. Delegation of responsibility takes place everytime a principal has to rely upon some other party to complete a transaction. He relies upon an other principal but he does not trust him. Following we describe a couple of examples where this new form of delegation is needed. Let suppose to have a service provider that offers a set of services to his customers. The customers demand for a new service. The service provider finds more convenient to delegate this service to an other party rather than to provide it by himself. Customers do not want to see this delegation, i.e. the new service has to have the usual interface of all the other services. The responsible for all the services for the customers it is always the service provider (

Full text

Delegation of Responsibilities
B. Crispo
1
,
2
1
University of Cambridge
Computer Laboratory
England
2
Department of Computer Science
University of Turin
Italy
1 Delegation of Responsibility
Delegation is usually seen [1{3, 8, 11] as delegation of rights, where the
term
delegation
is used to refer the process whereby a principal authorises
an agent to act on his behalf, by transfering a set of rights to the agent
for a specic perio d of time.
Here we would like to propose an other form of delegation:
delegation of
responsibility
with the following denition that is slightly dierent from
the previous one:
delegation
is used to refer the process whereby a princi-
pal authorises an agent to act on his behalf, by transfering a set of rights
to the agent for a specic period of time - during which the principal can
no longer excercise these rights.
Delegation of rights assumes that a principal, A, has a set of rights
G
and she delegates a subset of them,
G
0
, to an other principal B who can
act on behalf of A to excercise that particular set of rights
G
0
. A is always
responsible for
G
0
, but with delegation she shares these responsibilities
with B.
To whom a principle is responsible for his rights depend on the security
policy. Usually the grantee is responsible to the grantor about the rights
he got from him, but there could be cases where the grantee is responsible
to a third party or many other more complex agreements.
There are a lot of situations where this sharing of responsibilities, that
introduces uncertainty for auditing purposes, is not desired.
We use the term responsibility to mean something dierent from what
the term is most commonly used for. We won't determine who is going to
pay a bill, but rather to make sure that the bill will be delivered to the
person accountable for it. We cannot technically establish who is going
to be legally, morally or socially liable for an action. Our goal is, more

modestly but still quite dicult, to determine who, technically, performed
a specic action.
Delegation of responsibility takes place everytime a principal has to
rely upon some other party to complete a transaction. He relies upon an
other principal but he do es not trust him.
Following we describe a couple of examples where this new form of
delegation is needed.
Let suppose to have a service provider that oers a set of services
to his customers. The customers demand for a new service. The service
provider nds more convenient to delegate this service to an other party
rather than to provide it by himself. Customers do not want to see this
delegation, i.e. the new service has to have the usual interface of all the
other services. The responsible for all the services for the customers it is
always the service provider (grantor).
Anyway the service provider wants to b e able to distinguish if a disruption
of the new service is its repsonsability or the other party (grantee) one.
In order to do this we propose a new form of delegation:
delegation of
responsibility
. What it is delegated are not only the rights but the right
with the attached responsibilities.
An other practical example how delegation of responsibilities diers
from delegation of rights occurs in the banking system.
Suppose the case of a customer applying for a credit card to his bank.
The bank, after the appropriate verication pro cedures, will issue the
credit card to the customer. This issuance is equivalent to delegate to the
customer the capability to use the card. Only the bank can issue the card,
so its authorization is necessary. On the other hand the bank, during the
procedure to issue the card, never knows the customer PIN number
1
;
even if it chosen and issued by the bank, for security reason, is never
revealed to any employees of the bank. The customer is the only one that
knows about his PIN, thus he is the only one that can use the card and
more interesting is the only one that is responsible for the transactions
carried out using that card. He does not share any responsibility with the
issuer bank. Merchants, anyway, accept that card because issued by the
bank.
This is a typical example of delegation of responsibilities and not
of rights. In the banking practice there are a lot of examples where for
security and auditing purposes more than one independent parties cannot
1
Here we assume that the bank is completely honest and competent for the issuance
of PIN numbers.
2

execute themselves a transaction but their authorization is necessary for
the execution of the transaction by one or more responsible party.
We are not saying that delegation of responsibility must substitute the
concept of delegation of rights, which is useful and appropriate for many
situations, but rather we p ointed out that both meanings of delegations
are necessary to provides mechanisms to solve a wider variety of problems.
2 Critics to the Existing Works
We use the following terminology: the principal that delegates is said to
be the
grantor
. The principal that is authorised by the grantor to use some
rights is said to be the
grantee
. The target that accepts the last operation
invocation of a cascaded operations chain is called the
end-point
.
In this section we will show what are the assumptions that need to
be redened in some of the existing works on this subject, [1] and [2], in
order to be able to represent delegation of responsibility.
We will refer mainly to those two papers because, for what we know, they
are the most complete examples of theoretical framework about delega-
tion. In security literature there are relatively few papers investigating
delegation issues, and most of them [3,5, 6, 9, 10] focus only on mecha-
nisms to implement delegation without critically consider the concepts
underlaying delegation.
2.1 Relation
\speaks for"
Relatively to [2], our rst observation is concerned with the denition of
the relation `sp eaks for' and the statement `says' given in that pap er:
There is a fundamental relation between principals that we call
the `speaks for' relation. A speaks for B if the fact that principal
A says something means we can believe that principal B says the
same things. .......
We use `speaks for' to formalize indirection; since any problem in
computing can be solved by adding another level of indirection..
This denition of `speaks for' is too strong. Implicit in this denition
is the assumption that `speak for' contain also the `says' concept in it. If
A speaks for B than B says what A says.
3

We would like to emphasise that this could be true but it is not nec-
essarily true and with this denition of `speaks for' it is imp ossible to
dierentiate the two cases.
This problem is explained even better looking at the formal denition
of the relation `speak for':
(A
)
B)

(A = A
^
B)
and from that
A says S = (A
^
B) says S = (A says S)
^
(B says S)
Thus `speaks for' implies that all what B says is said also by A. This
is true when only rights are delegated but it is not when resp onsibility is
delegated.
2.2 Operator
\for"
In [2] delegation is expressed with the operator
for
, that it is axiomised
as following:
A
^
B
j
A
)
Bf or A
(1)
for
is monotonic and distributed ov er
^
(2)
Af or
(
Bf or C
)
)
(
Af orB
)
f orC
(3)
(
Af orB
)
asR
=
Af or
(
BasR
) (4)
A to delegate to B it makes (5) A
says
B
j
A
)
B
for
A. Then B
must accept the delegation by making (6) B
j
A
says
B
j
A
)
B
for
A.
This explicit action by B is needed because when B
for
A says something,
the intended meaning is that both A and B contribute, and hence both
must consent.
Given (5) and (6), B can speak for B
for
A by quoting A.
(A
^
B
j
A) says B
j
A
)
B for A
B
j
A
)
B for A
Those axioms are too strong to represent delegation of resp onsibility.
A and B not only do not need to both contribute to a statement but they
have not to. Or more precisely their contribute must be well dened and
not shared between them.
4

Delegation of rights allows a principal to delegate some of all his au-
thority to an other principal. In order to do that the grantor requires a
level of trust in the grantee while in delegation of responsibility this trust
not only is not required but in many cases grantor and grantee have con-
icting interests on the rights excercised by the grantee and at the same
time both of them are interested on the fact that delegation takes place,
e.g. bank and customer in the case of issuance of a credit card.
Thus in delegation of responsibility the grantor hands o the rights
with all the responsibilities attached to them to the grantee.
The grantor has simply to rely upon the grantee but not to trust him.
This is a crucial dierence because reliance can b e monitored and veried
while trust cannot.
A trust relationship can be only interrupted (by revocation) but during its
validity cannot be veried by a third party. This is an essential property
for non-repudiation for example.
Revocation may reect also those dierences. With delegation of rights
it is reasonable to assume that the grantor excercises the right to re-
voke a delegation token, previously issued, because he retains responsi-
bilities. With delegation of resp onsibility because all the responsibilities
are handed o also the responsibility to revoke a delegation token can
be delegated by a third party dierent from grantor and grantee. This
suits very well the principle of separation of duties that should b e always
enforced where possible in security system design [4].
We note a divergence between delegation of rights and how delegation
is performed in real world. In most of the practical case, and almost alway
in business practice, when a grantor delegates some of his rights to a
grantee, then the grantee to excercise those rights is usually requested
to sign with his handwritten signature. Thus even if responsibilities are
often shared between grantor and grantee the real world seems to employ
always mechanisms to allow to recognize if the grantor or the grantee
excercise a delegated right.
On the other hand the delegation of rights, as it described in almost
all the security literature does not seem to allow this distinction. The
delegation key, key used to excercise the delegated right, is known by
both grantor and grantee, leaving room to undetectable misbehaviour,
also in case that proper audit trail are maintained.
An example of delegation of rights in the real world practice is the case
where a manager gives a copy of his oce's key to his secretary, delegating
her the right to enter in his oce in his absence. Here, as in the electronic
5

case, there may be situations where it cannot be distinguished who, the
manager or the secretary, got into the oce.
It is also worth to note that in the real world this situation can be
easily xed putting a video camera in the room pointing at the door,
while in the electronic case the camera cannot be implemented because
bit patterns by themselves do not prove authentication.
To be precise in this analogy, we have also to mention the containment
problem. Mechanisms that electronically implement delegation of rights in
order to prevent the grantee to delegate, to some unauthorized party, the
rights she got, usually require that the grantor species the name of the
grantee in the delegation token. The end-p oint will accept the delegation
token only if presented by the principal specied in the relative token.
It is interesting to note that implementing containment of delegation
of rights in the real world is far from be straightforward.
The logic presented in [1] and [2] does not seems to capture the dier-
ences between symmetric key and public-key cryptosystems with respect
of delegation. Let's suppose A and B two principals and S a trusted server.
A and B share a key with S, respectively
K
AS
and
K
BS
.
According with that logic we can write that:
f
K
AB
; A
g
K
BS
means
that
K
BS
says
K
AB
)
A
. With symmetric key,
K
AB
is a secret key, then
`speaks for' and `says' coincide. Using the same notation for public-key
can lead to some subtle mistakes. If we write
f
K
A
+
; A
g
K
CA
?
as equivalent
of
K
CA
?
says
K
A
+
)
A, we have to remember that is
K
A
?
that `says'
and not
K
A
+
Thus the certication authority CA says that
K
A
+
`speak
for' A while actually A `says' with a dierent key:
K
A
?
, unknown to the
CA.
2.3 Passive principal and active principal
Finally the logic in [1] does not catch the dierences, between delegating
a passive entity (e.g. a key) or an active one (e.g a principal).
Writing B
)
A, where A and B are principal, from the denition
of `speaks for' this means that whatever B says implies that A says the
same. This requirement is dicult to be satised, because requires A to
completely trusts B, in the sense that she trusts the fact that B will
say only things she will say, or B must have restricted capabilities, in
particular he can say only things that A will say. This is a bit unrealistic
if A and B are acive principals.
6

While if we write
K
AS
)
A
, where
K
AS
is A's secret key shared with
the grantor S, than it is much more natural to assume that the key that
speaks for A will say only thing that A will say.
2.4 Roles
Some pap ers [2, 3] introduces
roles
, as mechanism used by a grantor to
limit its authority that he delagates to the grantee. Using the notation
in [1], A
as
R, meaning the principal A acting as the role R, is a weaker
principal than A because it has only a subset of the whole rights A has.
So writing B
)
A
as
R, its a weaker statement than B
)
A, because
it means that whatever B says implies that A in the role R says the same,
but B cannot say things that A can say acting outside the role R.
This is not the only possible denition of role. A role can also b e
dened as a set of responsibilities that a grantor cannot excercise but
can delegate. The latter rather than the former is more appropriate with
delegation of responsibility.
Roles do not solve all the problems. In fact, where principals and not
passive object are involved, there could be situations where two dierent
pincipals
A
1
and
A
2
with dierent security policies (e.g.
A
1
must always
terminate operations before
A
2
starts his), delegate two dierent roles to
the same principal B: B
for
A
1
as
R
1
and B
for
A
2
as
R
2
. It is easy to
see how B can break the grantors' security policy or how dicult is for
the grantors to enforce their security policy. This delegation mechanism
could lead to an even worse situation in case
A
1
; A
2
and B have conict-
ing interests. It is also not easy to detect when situations like this may
happen, because there could be chains of delegations.
Suppose to have the following two independent chains of delegations:
B
for
A
as
R and C
for
B
as
R
1
is the rst chain while C
for
A
1
as
R
2
is the second one.
The independent grantors A and
A
1
cannot determine or detect if
the delegated rights of C acting as
R
2
are in somehow inuenced by the
delegated rights of C acting as
R
1
. Sometimes just the knowledge of the
existence of those rights could be enough to leak condential information.
Moreover C himself may take advantage about this situation and surely
he is not strongly motivated to report this anomaly situation.
A cross checking of all the roles delegated by a grantor is not only
an expensive procedure but sometimes it may not be possible b ecause it
may require access to restricted information.
7

We wish also to point out that also the validity period of the delegation
token is worth to be discussed more carefully. The usual assumption is
that the lifespan of the token is shorter than the grantor's life. There are
a lot of applications [7] where this is not the case.
3 Conclusion
We wish to remark the imp ortance of this novel denition of delegation
and its importance in designing security systems that may oer services
as non-repudiation.
We are actually working to redene the denition of the logic that we
criticised here in order to represent delegation of responsibilities. We are
also implementing this concept using dierent cryptographic mechanisms.
Our suspect is that there is not a particular cryptosystem that can of-
fer solutions or features that other cryptosystem cannot provide. It is
rather question of system constraints and sp ecic application require-
ments which cryptosystem to use.
Acknowledgement:
The author would like to thank Microsoft Re-
search Ltd. for supporting his research at the University of Cambridge.
He would like also to thank: Bruce Christianson, Roger Needham and
William Harbison that were at the origin of many ideas discussed here.
Simon Fowley, Francesco Bergadano and Geraint Price for the useful dis-
cussions and suggestions to improve the presentation of this paper.
References
1. M. Abadi, M. Burrows, B. Lampson, and G. Plotkin. A Calculus for Access Con-
trol in Distibuted Systems.
ACM Transaction on Programming Languages and
Systems
, (15):706{734, September 1993.
2. M. Burrows B. Lampson, M. Abadi and E. Wobber. Authentication in Distributed
System: Theory and Practice.
ACM Transaction on Computer Systems
, (10):265{
310, November 1992.
3. B.C.Neuman. Proxy-Based Authorization and Accounting for Distributed System.
In
Proceedings of the 13th International Conference on Distributed Systems
, May
1993.
4. B. Crispo and M. Lomas. A Certication Scheme for Electronic Commerce. In
Security Protocol Workshop
, volume LNCS series vol. 1189. Springer-Verlag, 1997.
5. Y. Ding, P. Horster, and H. Petersen. A New Approach for Delegation Using
Hierarchical Delegation Token. In
Proceedings of the 2nd Conference on Computer
and Communications Security
. Chapman and Hall, 1996.
6. M.R. Low and B. Christianson. Self Authenticating Proxies.
The Computer Jour-
nal
, 37:422{427, 1994.
8

7. C.P. Martin and K.Ramamritham. Delegation: Eciently Rewriting History. In
Proceedings of the 14th International Conference on Data Engineering
, pages 266{
275, April 1997.
8. M.Mambo, K.Usuda, and E. Okamoto. Proxy Signature for Delegating Signing
Operation. In
Proceedings of the 3rd ACM Conference on Computer and Commu-
nications Security
, 1996.
9. M.Mambo, K. Usuda, and E. Okamoto. Proxy Cryptosystems: Delegation of the
Power to Decrypt Cyphertext.
IEICE Transaction on Fundamentals
, E80-A, Jan-
uary, 1997.
10. M.Mambo, K. Usuda, and E. Okamoto. Proxy Signatures: Delegation of the Power
to Sign Messages.
IEICE Transaction on Fundamentals
, E79-A, September, 1996.
11. V.Varadharajan, P. Allen, and S. Black. An Analysis of the Proxy Problem in Dis-
tributed System. In
Proceedings of the IEEE Symposium on Security and Privacy
,
1991.
9