FYI - IETF group on confining bearer tokens

====== Forwarded Message ======
Date: 2/11/15 11:06 AM
Received: 2/11/15 2:06 PM -0500
From: [email protected] (Tony Arcieri)
CC: lcryptography-of7zbby7T3pWk0Htik3J/[email protected] (Crypto), et.al.

... there's a new IETF working group dedicated to confining bearer tokens:

https://datatracker.ietf.org/wg/tokbind/charter/
====== End Forwarded Message ======

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, CA 95032

On Wed, Feb 11, 2015 at 10:03 AM, Nico Williams <nico-AXk4VldLy5iz/[email protected] > wrote:

Well, but capability tokens can be passed around, no?

It depends!

Impersonation happens to be a common mechanism. So now we need to express policy

about who can be given authorization to do any particular thing to any

particular resource, and this begins to resemble ACLs. And/or you can

audit the state of a running system (which is difficult).

Revocability and confinement are two popular topics with capabilities, and yes, there are many solutions (especially with Macaroons). I suggest reading Mark Miller's paper "Capability Myths Demolished":

http://zesty.ca/capmyths/usenix.pdf

CapTP specifically supported "SturdyRefs" which are opaque (sealed) in distributed contexts:

http://erights.org/elib/distrib/captp/SturdyRef.html

Macaroons specifically support "contextual confinement" that can bind them to mechanisms like TLS channel ID so they aren't transferrable.

Also there's a new IETF working group dedicated to confining bearer tokens:

https://datatracker.ietf.org/wg/tokbind/charter/

--

Tony Arcieri

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