[cap-talk] - Karp - Capabilities - tracking responsibility (Was: Bellizzomi - Users in object/capability systems (was: MLS gone bad, Lampson))

Rob J Meijer rmeijer at xs4all.nl
Fri Dec 1 02:47:04 CST 2006


>>> >I am assuming that when Tyler uses the capability it is over a
>>channel
>>> >to Jed authenticated as Tyler.  Bob uses the capability over a
>>channel
>>> >authenticated as Bob.  Since Tyler can't set up a channel to Jed
>>> >pretending to be Bob, there is no way Tyler can blame Bob for Tyler's
>>> >actions.
>>>
>>> Are we talking about "non-repudiation" here ?
>>>
>>No, audit for assigning responsibility.  Non-repudiation assures Jed
>>that Bob cannot deny having taken an action that he actually took.
>>Audit for assigning responsibility assures Tyler that Jed won't blame
>>Tyler for actions taken by Bob, even if Bob uses a capability that Tyler
>>gave him.
>
> I don't see where is the difference with non-repudiation, if Bob can't
> deny having taken an action that he actually took, how can Jed blame Tyler
> for an action taken by Bob?
>
> val
>

The difference is that accountability for the action may not actually lay
with the entity that took the action but with one of the entities in the
preceding delegation chain.  Thus appropriate incident response may focus
on the zone of influence of the entity that apparently is violating policy.
Lets for clarity of policy take a human example.

* Alice delegates a capability to her co-worker Bob
* Bob re-delegates to his sister Carrol
* Carrol re-delegates to her friend Mallet
* Mallet uses the capability in a way that constitutes an incident.

As you can clearly see from this example, an effective incident response
should focus on Bob and on any other capabilities granted to Bob.
Alice her delegation would be according to policy as Alice would have no
reason to assume her co-worker to be untrustworthy.
Carrol will have no knowledge of or binding to company policy so her
delegation to Mallet so she is not even able to violate policy by re
delegating. The fact that eventually Mallet uses the capability is also
outside the scope of any company policy but is an essential point where
an incident could be registered.
The question thus becomes, how can we from the incident (Mallets access)
get to the accountable entity/person (Bob) in a way that would make
delegation and proxy effectively the same (incident response wise that is).
I believe the answer involves several aspects:

* entity bound 'explicitly' delegable capabilities
* authenticated channels (kerberos,x509)
* 'trusted' delegation-recording membranes or signature-chain capabilities.

I feel that 'trusted' delegation-recording membranes would be quite a
challenge, but signature-chains for caps are quite expensive and thus
limited in applicability.

Rob



More information about the cap-talk mailing list