On Saturday 03 May 2003 13:58, Seairth Jacobs wrote:
> From: "Tyler Close" <tyler@...>
> > 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.

Yes, using this type of construction, you avoid a Confused Deputy
attack on the notification receiver.

Does this mean that you are dropping authorization methods 2 and
5, from Michael Day's list of 5 authorization methods?

Does this mean that you are rescinding your opinion that:
"Generating URLs containing authentication tokens seems like a Bad
Idea"?

If the answer to both of these questions is yes, then this is a
big step in the right direction.

Taking this step raises a question about another part of the RNA
design. If the resource identifier and the authority to access the
resource are always transferred as a single unit, why does RNA
contain a mechanism to authenticate the source of a notification?
What attack does this authentication mechanism defeat?

> 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.

Please explain.

> 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...

But given the decisions you've made above, the same authentication
credentials are always provided. If you start mixing and matching
authentication credentials and URLs, then you once again open
yourself up to a Confused Deputy attack.

A cache is perfectly happy with a URL that contains a secret in
the path.

> 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?

Assuming you mean a unique "user/pwd" for each resource, and that
the combined URI is passed using a secure communications channel,
then the URI is a "capability URI".

I think the only subtlety you are missing is that there is no
advantage to using a "user/pwd" instead of a nonce in the URI
path. On the other hand there are disadvantages to using HTTP
Auth. You are doubling your network round trips, for no useful
purpose.

> I think there may be some miscommunication here (on my part).

I also made some mistakes in the email using examples from the RNA
spec. I confused the purpose of the authentication mechanism
described there. I think I get it now, but now that I understand
it, I no longer see what value it provides. See the question
above.

> 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.

Given the assumptions that I listed above, your approach does use
capabilities and there is no additional protection that can be
afforded. Thus my question about the purpose of your
authentication mechanism.

It's great that you've moved so quickly to using capability-based
security.

Tyler