[cap-talk] Webkeys vs. the web

[Sandro Magi]

Chip issued a good challenge, as turning a Waterken-style capability
system for web service interactions into a usable user-facing website is
still an open question.

I'll take my turn at it: I think we need to distinguish public objects
from authority bearing objects differently in the URL, and provide a
Monash-style transformation such that the authority bearing portion of
the URL is user-specific; thus, even if a URL is shared, the authority
bearing portions of the URL are not useful or meaningful to any recipients.

For instance, using Chip's example of a public mailing list page:

http://host.com/lists/public-list-1

As a logged in user, my URL would consist of something like:

http://host.com/lists/public-list-1?key=akd834jm9d7h2js58jkf0c7j2

Unlike in Waterken, the above URL is not a capability, but an encrypted
(nonce, object id) pair. The nonce is a user-specific swiss number used
to encode the underlying object id, ie. URL object id = encode(nonce,
object capability).

The encrypted nonce is also stored in an authenticated user's cookies.
The cookie nonce and URL nonce must match for the object id to be valid.
Another user visiting my logged in URL will not have a matching nonce,
and so get only the public portion of the page with a login link instead
of an account link (the account being the object id). Logging in
extracts the user nonce from storage.

I believe this is immune to CSRF and clickjacking since the URL is still
unguessable, unless the attacker knows both the nonce, the server
encryption key, and the object id.

It's unclear whether the underlying object id must itself be
unguessable, as without knowledge of the nonce and encryption key, I
don't see how a CSRF and clickjacking attack could succeed. The nonce
can then be viewed as a sort of directory capability via which all
objects are resolved.

I have a few possible simplifications of this scheme, but I'm not yet
satisfied they handle all the corner cases I've come up with. Please
poke holes in this one!

Sandro

Chip Morningstar wrote:
> "Karp, Alan H" <alan.karp at hp.com> wrote:
> 
>>>> But if this was a webkey system, it wouldn't *have* that link.
>>>>
>>> It *shouldn't* have that link.
>> Your comment got me thinking.  That link was probably on the page because the
>> page was constructed dynamically based on context.  If I had sent the URL for
>> the page to you, the link wouldn't have been there because you wouldn't have
>> been logged in to my account.  In fact, if you were logged into your account,
>> then maybe the link to your account would have appeared where I saw the link
>> to mine.
>>
>> That observation may lead to the solution to Chip's problem.  If what appears
>> on a page can be tied to the path used to reach it, it should be safe to put
>> on a page a link to any page that the user traversed on the path to that page.
> 
> That's true as long as the user has traversed through a chain of non-public
> links to a page with an unguessable URL.  However, the particular problem I was
> posing had to do with the transition from a page whose URL could be expected to
> be known.
> 
> Chip
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk