[cap-talk] Another "core" principle

[David Hopwood]

Jed at Webstart wrote:
> In the message above you seem to suggest that if a revocation
> happens and it stops somebody from doing their work, that's
> OK.  If the revocation is as intended and the person should no
> longer have access, then of course it is more than OK, it's
> what should happen.
> 
> However, in the case we've been discussing (
> 
> 1.  Alice -> Bob -> Carol -> Dave  ("->" indicates delegates to),
> 
> 2.  Bob's access is revoked,
> 
> 3.  Carol is introduced to Alice and Alice decides that Carol
> should be trusted with the authority delegated to her from
> Alice via Bob.
> 
> ) this is not the intent and I regard it as very far from OK.
> Because of #3 both Carol and Dave should continue to be
> able to exercise the authority granted to them from Alice
> by Bob.

But should Carol continue to have access *via the same reference as before*?
I claim not: indeed, I think it is essential to security (and intended by
Alice) that Carol should lose access via that reference.

While it may be seen as convenient that Carol continues to have access via
the same reference, this is absolutely the wrong thing from the point of view
of preventing confused deputy attacks. Bob (for example) may still be in a
position to provoke Carol into using that reference in a way that is no longer
intended, after the revocation.


(Note that Carol is a process, not a human user, and therefore is fundamentally
incapable of understanding the reasons why it may have been requested to
perform any given operation. This is also true if Carol happens to be a
"user agent" process. The only way we can avoid confused deputy attacks is to
ensure that processes do not need any intelligence to determine when they can
use a particular reference. This requires distinguishing between references that
eventually give access to the same object, but could be revoked under different
circumstances. In this case, the only way for Carol to behave correctly after
the revocation is for it to have two references, and lose access via only one
of them.)

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>