[cap-talk] Confused Deputies in Capability Systems

[Sandro Magi]

Toby Murray wrote:
> Here's another strong claim that could be just as incorrect: any
> exploitable failure to vet a capability can result in a confused
> deputy and vice-versa.

I don't see how that could work. The access check is performed before
sending a capability to a service, in which case the service can rely on
the parameter being authorized, unless it explicitly amplifies the
rights derived from the given capability. Capabilities implicitly carry
an authorization context with them which ACL invocations do not.

My suggestion for a "vetted" parameter wrapper for inputs carries the
same authorization context (it's pretty much a capability in fact).

> Consider the final example from
> http://www.comlab.ox.ac.uk/people/toby.murray/papers/NDA.pdf in which
> users use non-delegatable authority provided by a "credential"
> capability to access classified networks via routers who are supposed to
> check the authenticity of such credentials before relying on them.
> Suppose a router fails to authenticate a credential. Then in a very
> strict sense, it could be considered a confused deputy.

Isn't the router amplifying a credential to a stream to access the
protected network? I would consider that a rights amplification.

Analogously, the Waterken server amplifies a URL to an actual object
reference when it serves a request on that object, so it too must
authenticate the input. This is a problem with capabilities-as-data, but
not object capabilities.

Sandro