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

[Valerio Bellizzomi]

On 01/12/2006, at 9.47, Rob J Meijer wrote:

>>>> >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 guess we have to walk-back the delegation chain from Mallet up to Bob,
but how to do it is an open issue.

>
>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
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk