[cap-talk] Delegation/Proxy equivalence and limited lifespanobjects?

David Wagner daw at cs.berkeley.edu
Mon Nov 12 15:41:10 EST 2007


ROb Meijer writes:
>The argument I got back was that eventhough Carol should not have received
>authority for the file reference in the first place, the proxy version
>would limit the damage to the timeframe of the existence of Bob, while the
>delegation as you state would "remain" out of controll.
[...]
>Do you feel the abouve shows there is 'some' added security to proxying
>over delegation here (even with attenuation patterns in place), that would
>be a valid reason to implement a no-re-delegate bit ?

That argument seems pretty dubious to me.  Bob controls his own
lifetime (not the defenders).  It seems rather dubious to base your
security model upon something that's out of the defenders' control.
At best it seems like the added security would be minimal.

However, this is difficult to argue in the abstract.  Can we get
an example of a real system with some real security requirements?
I'm skeptical that there is a realistic, justifiable threat model and
application requirement that would make a no-delegate bit valid and
useful from a security standpoint (rather than just as an advisory, "I
wish you wouldn't delegate this; please be kind and don't re-delegate").
But it's always possible I'm missing something.

Two other points that might not be obvious:
 * If Alice wants, she can delegate to Bob in a way that Bob
   can re-delegate even after his lifetime expires.  Alice just
   generates a fresh crypto key, gives that crypto key to Bob, and
   promises to proxy for anyone who can prove knowledge of that key.
   Likewise, if Bob authenticates himself to the system using a
   password or crypto key, he can always give his authenticators
   to Carol, lending Carol the ability to retain access to his
   account even when he is not logged in.
 * If we're talking about leakage of secret information, then it's all
   moot: Alice can leak the secret itself to Bob, and Bob can leak
   the secret itself to Carol, and Carol will retain knowledge of that
   secret even after Bob no longer exists.  Of course Carol may not be
   able to learn new secrets (e.g., subsequent edits to a confidential
   document) after that point, but that's cold comfort: the damage that
   is possible is bad enough as it is.  So this only seems interesting
   for integrity properties; for confidentiality properties, you really
   can't prevent sharing among parties who can communicate.  Of
   course, in the commercial world, integrity properties are probably
   significantly more important than confidentiality properties, so
   the interesting case is the important case.

I'm inclined to classify a no-delegate bit in a similar category
to copy protection: it doesn't really work, but for some reason
people seem to want it.  Wishful thinking?  I don't know.


More information about the cap-talk mailing list