[cap-talk] Loss of control (was: Re: A paper on web-keys)

[Jed Donnelley]

At 08:05 AM 2/2/2008, Sandro Magi wrote:
>Jed Donnelley wrote:
> > At 07:53 PM 2/1/2008, David Hopwood wrote:
> >> I don't agree with this argument. If system A has a given set of security
> >> mechanisms, and system B has the same mechanisms plus additional ones
> >> that only act to deny some requests, then it is not valid to conclude that
> >> B is automatically no less secure than A. The reason is that the 
> effects on
> >> user behaviour must be taken into account: if users or administrators rely
> >> on the existence of the extra checks, but those checks are flawed in any
> >> way, then they will end up with weaker security than if they had been
> >> required to express a comparable policy using only the mechanisms of A.
> >
> > I agree with what you say above in the general case.
> > However, in this case Bill is referring specifically
> > to the confused deputy problem.  Since all permissions
> > are explicitly delegated as parameters (no separation
> > of designation and authority), the confused deputy
> > situation can't happen - even if sometimes, perversely,
> > the communicated "permission" (reference) yields no
> > actual authority.
>
>Unless users and/or developers start relying purely on the ACL and not
>capabilities to control access, which I believe is David's point.

I guess you are describing an extreme case where capabilities
are used in "bulk" (perhaps even as bulky as identities) and
ACLs are used for dividing up and controlling finer grained
authority?  Hmmm.  I admit that even then I don't see how
the Confused Deputy situation can arise.  A potentially
confused deputy still knows that it should only use the
communicated "bulky" authority passed in with the request
for named references that should be associated with the
request - e.g. vs. it's own or other "bulk" authority.

Even though the authorities may come in bulk, they still
must be communicated with requests (I assume - you not?),
and all access can safely (regarding deputy confusion)
proceed through them.  Even a deputy that receives
an "identity" authority in a request can still distinguish
which authority it uses on behalf of the requester and
which it uses on its own or other behalf.

If you or others still think a Confused Deputy situation
can arise in such a case, perhaps you can describe an
example?

What I thought David was getting at is the oft repeated
concern that if people can't get their job done by
delegating fine grained access (e.g. capabilities), then
they will resort to grosser grained access, like sharing
credentials (e.g. passwords) between people.  I believe
this concern isn't applicable to the Web-keys situation.
Perhaps it's worth noting, however, that this concern
does apply to many other mechanisms where capability
services provide "attenuation" of communicated authority -
such as revocation, membranes, and Horton.  In all such
situations it's of course important to not block access
delegated by capabilities so much that users feel forced
to resort to sharing credentials, not in requests, but
between people.

Might you be suggesting that if Web-keys "bulk"
up so much then people might feel forced to share
their credentials when using Web-keys?  I believe
that even in that case they could communicate their
bulky authority in requests, obviating the need for
sharing their credentials with other people,
and still avoiding the Confused Deputy problem.

Sorry if I'm just missing something.

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