Re: Fwd: Seeking Feedback on Capability URLs Draft

[+James, +Sophia]

On Thu, Jun 5, 2014 at 8:06 AM, Karp, Alan H <[email protected]> wrote:

> Rob Meijer wrote:
>
> an excellent response.  I'd like to note that
> >
> > 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.
> >
> is not a requirement.  You rarely care if the two references are to the
> same object.
>
> Like capabilities passed through a membrane, E-speak had the "problem"
> that Carol would get different capabilities in this scenario and would have
> no indication that they referred to the same object.  That worried some of
> our customers, so we implemented the Ask Bob protocol.  (Where the name
> comes from is a funny story.)  To the best of my knowledge, nobody ever
> used it.
>

"Ask Bob" was too weak to implement grant matching.

In defining the ocap model, I say

"Object-capability systems differ regarding concurrency control, storage
management, equality, typing, and the primitiveness of messages, so we
avoid these issues in our model."

and some great ocap systems, notably Joule <
http://www.erights.org/history/joule/>, have no EQ primitive. This is
weaker from a security-expressiveness perspective, but in absolute but
subtle ways <
http://www.eros-os.org/pipermail/cap-talk/2008-February/010098.html>. The
join primitive used in <http://research.google.com/pubs/pub40673.html> has
all the security-expressiveness benefits of EQ, but avoids many of the
software engineering problems caused by EQ itself.

I am curious if anyone can solve the problem posed in that paper using only
weaker primitives than join.

Regarding the main point of this thread, however, url-as-capability systems
that lack any EQ primitive of any sort are still a great improvement over
the standard web security patterns, and a great improvement over the
security recommendations in that draft. (IMO those that support join-like
eventual equality are even better, but it remains a tradeoff with pros and
cons.)


> ________________________
> Alan Karp
> Principal Scientist
> Enterprise Services, Office of the CTO
> Hewlett-Packard Company
> 1501 Page Mill Road
> Palo Alto, CA 94304
> (650) 857-3967, fax (650) 857-7029
> http://www.hpl.hp.com/personal/Alan_Karp
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:cap-talk-
> > [email protected]] On Behalf Of Rob Meijer
> > Sent: Thursday, June 05, 2014 4:12 AM
> > To: General discussions concerning capability systems.
> > Cc: [email protected]; www-tag
> > Subject: 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/
> >
> >
> > _______________________________________________
> > cap-talk mailing list
> > [email protected]
> > http://www.eros-os.org/mailman/listinfo/cap-talk
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>



-- 
    Cheers,
    --MarkM

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk