[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