From: "Tyler Close" <tyler@...>
>
> On Friday 02 May 2003 14:36, Seairth Jacobs wrote:
> > Why is the recipient forced to access the resource? The decision to
access
> > the resource is 100% under the control of the recipient (and recipient's
> > application). No external source can force the resource to be
retrieved.
> > It is certainly possible that a recipient could carelessly believe a
> > legitimate notification, but I'm not aware of *any* security model that
can
> > stop a recipient from being careless.
>
> The problem is that the ACL model makes it very difficult to not
> be careless with your authority.
>
> Assume the recipient has the authority to read a large number of
> resources on some server. Further assume that the recipient does
> not want his own credentials to be associated with a request to
> some of those resources. If the recipient makes a request using a
> URL taken from a notification, then the producer of the
> notification is deciding which resource the receiver will access.
> The receiver has delegated control over his ability to make
> requests to the notification producer.

Okay. I agree with this.

> The problem is that the receiver is making the request using the
> URL specified by the attacker and the receiver's own credentials.
>
> This type of attack is not possible in a capability-based design
> because the resource identifier and the authority to access the
> resource are bound together. If the notification delivered a
> capability URL, then the receiver would access the resource using
> the credentials provided by the notification producer, and not the
> receiver's credentials. In this case, the resource request would
> be associated with the notification producer, not the recipient.

But this *is* the scenario right now, if I understand you correctly. The
recipient receives a notification that looks like:

<notification>
<from uri="http://seairth.com/rna">
<resource uri="http://user:pwd@seairth.com/rna/msg/1234" />
</notification>

The recipient is using only credentials given to him via the notification.
Any person in the world could, given knowledge of the value of the "uri"
attribute, access the resource. At the same time, it would be possible for
a sender to use the same user/pwd for several recipients. However, this is
up to the discretion of the creator of the resource (who may or may not be
the same as the sender of the notification). From the client's perspective,
all of this is opaque.

Also, the reason I suggest using user/pwd instead of a random, unguessable
token in the URI is because I think the user/pwd is more in line with the
REST philosophy. This ensures that a single uri (sans the "user:pwd@ part")
identifies the same representation of the resource regardless of which
authentication credentials are provided, which is important for things like
caching proxies, etc...

As I understand it, the sender has a resource he want's to make available to
a recipient. The sender assigns a capability (URI + user/pwd, in this
case) and gives it to the recipient. Now, maybe I am not understanding the
subtleties of a "capability URI". If I have got it wrong, can you given an
example (possibly in context of RNA) that would make the difference more
clear?

> The attack is not so much targeted at RNA, as it is at how RNA is
> used. In the previous emails, you were indicating that the RNA
> client would provide a stored username/password in a request for a
> received notification URL. Doing this opens you up to a Confused
> Deputy attack.

I think there may be some miscommunication here (on my part). Those
statements were made with the assumption that the examples at
http://www.seairth.com/web/rna were read. Any stored user/password pairs
were provided by the sender of the notification, not by the recipient. I
had meant "stored" only in terms of the user/password that was kept by the
recipient from the notification.

>
> I think I've explained things more clearly this time. Do you
> understand now?

This conversation has certainly helped. Thank you. I do have some
questions, however. I believe that the above approach effectively uses
capabilities, but I still do not understand how any additional protection
can be afforded to the sender than there already is by using capabilities.
When I went and looked up information on the Confused Deputy attack, I did
not see how it applied to this situation. If you still see problems what
capabilities was applied wrong, please let me know.

---
Seairth Jacobs
seairth@...