[cap-talk] We met at the Cornerstones of Trust conference and...

[Karp, Alan H]

David Chadwick wrote:
> 
> So turning to your example, there are two ways I would address this
> depending upon whether you use a data push or data pull model.
> 
> With data push, Alice subscribes for a backup service from Bob, and does
> not care how Bob fulfils it. She pushes her file to Bob and he responds
> telling her that her backup copy is in Outref and giving her a role
> which allows her to read it. Alice is allowed to delegate this role to
> anyone she chooses, allowing anyone to read her copy stored by Bob. The
> fact that Bob subcontracts to Carol is hidden from Alice and Alice does
> not care. She pays Bob for the service and Bob provides it in the best
> way he sees fit. This is how most services operate today, using
> encapsulation, and I think this is the best model to use from a user
> perspective. I dont care when I take my shoes to a shop to be repaired,
> who does the repair. The shop could send the shoes to India for all I
> care, but I hold the shop responsible for the job and for the repair of
> my shoes.

The push model illustrates the futility of trying to block Bob from delegating in the pull model.  If Bob has permission to read the data, Bob can forward it to whomever he pleases, and there's nothing Alice can do about it.

There are issues with the push model.  

o Bob may end up copying several GB of data just to forward it to Carol.  

o Bob must be online when the copy is done, continually for streaming data.

o The audit log will show that Bob read the data, forcing him to defend himself if something is leaked.  On the pull model, Bob only needs to prove that Carol is not his sock puppet.

> 
> With data pull, which is the model you are using in your paper, Alice
> delegates to Bob a role which allows Bob to read her file, and she
> allows Bob to delegate this to anyone. Now this in itself is a dodgy
> thing to do, and I dont think that Alice would normally be prepared to
> do this. But since Alice does not know about Carol she cannot control
> the delegations made by Bob. So she has to trust Bob to only delegate
> this role to someone he trusts. Bob then delegates this role to Carol,
> which allows Carol to read Alice's file. (Its a bit like me asking Fedex
> to deliver a parcel for me, and someone from UPS turns up to collect it
> from my house.) Carol on the other hand issues Bob with a role which
> allows him to run the copy service, and it is Bob who invokes the
> service, passing the name of Alice's file and the delegated credential
> to Carol which allows her to retrieve it. Bob internally will have
> granted Carol permission to write to his filestore, but he does not need
> to have given her a credential for this, he could simply record this
> internally.

As I said, Alice doesn't know what Bob does with copies of her data in the push model, so there's no security loss.  In fact, there might be a gain, because Alice will know that Carol read the data, not Bob.  If Alice has knowledge of Carol independent of Bob, she might choose to exercise control.  If Alice doesn't, she's no worse off than in the pull model.  She'll continue to hold Bob responsible.

Another issue with roles is granularity.  Roles can authorize multiple permissions, so Alice needs to exercise care in what roles she delegates to Bob.  Also, as I noted in a previous reply, Carol needs extra care to avoid applying the wrong role to the operations in the copy process.  These issues don't arise with capabilities.  Each capability both designates a specific resource and authorizes access to it.
> 
> Are these models in line with your thoughts about this use case?
>
Yes.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp