[cap-talk] Confusing deputies with SAML assertions (was: Re: Confused Deputies in Capability Systems)

[Jed Donnelley]

At 02:51 PM 2/9/2009, Karp, Alan H wrote:
>David-Sarah Hopwood wrote:
> >
> > > Validating capabilities does make sense in other environments.  Tyler
> > > pointed out a vulnerability in our Zebra Copy implementation.  In that
> > > work, capabilities are SAML authorization assertions.  Each service
> > > reference passed as an argument is represented by a SAML authorization
> > > assertion delegating to the service being invoked the right in the
> > > assertion.  We neglected to verify that the invoker had the right being
> > > delegated, which allowed a confused deputy attack.
> >
> > This is not a confused deputy attack. It's a mistake in the implementation
> > of the capability system TCB. (It's also not a particularly subtle mistake,
> > since it directly violates an assertion of the system design.)
>
>The attack is possible even with a correctly implemented TCB.  SAML 
>certificates are assumed to be public documents.

So far I'm with you.

>Alice can include a copy of a delegation from Carol to Bob in a 
>request Alice makes of Bob, and Bob may use Carol's permission on 
>behalf of Alice. If Carol is the powerbox for the person running 
>Bob, then we have a classic confused deputy.  If not, it's a 
>different form of confused deputy, but the result is that the 
>attacker gains an authority.  Bob can protect himself by making sure 
>the submitter of the request has the rights being delegated.

I'm afraid I'm a bit lost in the above.  When you say that Bob can 
protect himself by making sure that the submitter of the request has 
the rights being delegated, I thought 'that' (the fact that rights 
received in a message were rights the sender had) was a property of 
all capability communication systems.  If Alice was somehow able to 
include a 'delegation from Carol to Bob in a request Alice makes of 
Bob', then didn't Alice have the authority represented by that 
"delegation" before sending it to Bob?  If not then it doesn't sound 
to me like we're discussing a "capability" communication system.

My first impression is to agree with David-Sarah Hopwood.  Perhaps I 
need to learn more about SAML assertions as "capabilities".  In what 
sense are they capabilities if they violate this seemingly basic 
tenant of capability communication?

Perhaps this is another terminology issue.  What do we mean by a 
"capability communication system"?  As you can see in my Managing 
Domains paper:

http://www.webstart.com/jed/papers/Managing-Domains/

I use the term "capability" to refer to a representation of object 
access (access authority) that:

1.  can be validated when used as authorization for a service request, and

2.  can be communicated between any two processes that can communicate data.

What I mean(t) by "communicated" is that, as with data, if Alice 
sends a capability in a message to Bob, then Bob knows that Alice had 
the capability (the authority to make a service request on the 
capability) before sending it to Bob and that Bob can make use of the 
authority for service requests after the communication as Alice could 
before the communication.  Whether or not Bob had the authority 
before the communication (just as with data), Bob does have the 
authority after receiving the message and Bob knows that it came from 
Alice (Alice had it to begin with).

Sorry for being somewhat repetitive in the above.  I'm hoping that by 
using slightly different terms in the definition of a "capability" 
and the level at which the definition seems to me to apply then I'll 
be able to communicate the concept/definition more clearly.  These 
semantics for capability communication seems pretty fundamental/basic to me.

In the above (Managing Domains) paper I describe a number of 
implementations of capabilities, including two based on ACLs, one of 
which meets the criteria above and one that fails to ("Reflection 
Problem" - a variation on a Confused Deputy).  For me the concept of 
a "capability" is something that meets this basic intuitive notion of 
being able to communicate an authority like one can communicate data.

This definition is why I've always been uncomfortable with the 
concept of "Rights Amplification" in capability systems.  If a 
receiver can get more authority from a received capability than the 
sender had (the receiver is able to "amplify" the capability), then 
in what sense was the capability communicated from the sender to the receiver?

Do SAML assertions meet the above criteria (#1, #2) for "capabilities"?

--Jed  http://www.webstart.com/jed-signature.html