Re: [cap-talk] Fwd: Seeking Feedback on Capability URLs Draft

Some more concrete feedback:

Intro: '2' in the case of an 'unguessable' URL is in fact an example of
'1', 'the correct token'. If you want to talk about the scenario's in
terms of security tokens, I thing the best distinction is:

1) The use of 'authentication' tokens. Passwords are an example of these.
2) The use of 'authorization' tokens.
   A) The use of non designating authorization tokens.
   B) The use of designating authorization tokens.

If we take the standpoint that all security tokens should be
'unguessable', than the use of capability URLs is an example of 2B. Some
uses of cookies can be seen as examples of 2A.

Regarding section 3:

I believe the whole section 3 is rather biased towards the use of identity
in applications. There are many issues with the undue use of identity in
many forms and there are many security issues that can arise from the use
of identity and/or the lock-in to a granularity of individual users.
If using capability URL reduces the undue use of privacy sensitive and/or
decreases the use of granularity locked access control, than its use has a
major positive impact on the overall security properties of the system(s)
involved. There are major gains to had from the use of multi granular
access control models that don't yield any special lock-in to a single
granularity, that of the user account. And this is still very much
separate from the issues with federated identity management. Issues that I
think the Zebra Copy paper shows that even in situations where identity is
relevant, the separation of authentication and authorization yields
important properties that benefit the manageability of distributed
security attributes.

A further issue comes with the idea that a client should always
authenticate, and that the end of session should mean the capability
should get automatically revoked. A useful pattern of use is for example
that a user might authenticate herself in order to than delegate some
authority to a client by giving that client a revocable capability that it
can use until for example it is explicitly revoked. There are two
important properties to
the use of authorization tokens over authentication tokens:
Authority can be decomposed and/or attenuated. If I grant attenuated
decomposed access to a resource to a client by delegating a capability to
it, that client will only ever have access to the delegated attenuated
chunk of the  decomposed authority. If I grant the client access to my log
in credentials, I'm effectively delegating all the authority tied to the
account to the client. Hardly a secure idea.

As for the recomendations:

1) The base recommendation is simply horrific and anti-productive. In the
sentence 'The use of capability URLs should not be the default choice in
the design of a web application because they are only secure in tightly
controlled circumstances', you could replace 'capability URLs' with any of
the following concepts and end up with a stronger case:

* passwords
* cookies
* log-in credentials
* identity
* unattenuated authority
* single granularity abstractions

Given the alternatives, IMHO the use of capability URLs "SHOULD" be the
default choice in the design of a web application.



2) Capability URLs should expire. This one is tricky. If the capability
implies very limited attenuated authority, than the act of re-authorizing
a client using a much more powerfull capability or using log-in
credentials may in many cases constitute a much larger risk than allowing
the capability to remain valid.

3) There are quite some good practices missing, ,ost notably the use of
fragments for encoding the unguessable part of the URL.


http://waterken.sourceforge.net/web-key/


4) Regarding the canonical URL, there is the issue that there may be
multiple paths to derive a capability to a resource that grants attenuated
access.For example a file-system tree shaped graph may allow decomposition
and for example read-only attenuation. If Alice decomposes the tree,
delegates a branch to Bob who than creates a read only attenuation of the
branch and gives this to Carol. Alice also creates a read-only attenuation
of the whole tree and delegates that to Dave. Now Dave decomposes the
attenuated full tree, delegating it to Carol.  If Carol is to determine
that the authority that Bob delegated to her is exactly the same as what
Dave delegated, that means that attenuation of decomposition should yield
the same capability URL as the decomposition of attenuation.

http://minorfs.wordpress.com/2014/03/21/rumpelstiltskin-and-his-children-part-2/

Received on Friday, 6 June 2014 07:59:35 UTC