[cap-talk] request for comments on capability design

[Peter Amstutz]

On Wed, May 16, 2007 at 06:41:20PM -0700, Jed Donnelley wrote:

> Just working a bit on terminology - in the above when you say an 
> object is "replicated" from the server to a client, do you mean that a 
> reference (pointer, capability, ...) is communicated to the client?  
> Can clients communicate such references (capabilities) among 
> themselves?  If so then you are describing a capability system.  If 
> not then I think I need more clarification.

Well, both.  But yes, I am communicating references, and those 
references can be passed around among clients.  The reason I use the 
term "replication" is that the client may keep a cached copy of the data 
so that local process requests are serviced immediately.  I am also 
working on a design that provides for replication of computation so that 
the client optimistically computes results locally (in addition to 
sending a message) in cases where responsiveness is important and/or 
global consistancy doesn't matter.

> > Also, for caching purposes 
> > it should be possible to store and retrieve object replications to 
> > persistant storage, so objects have a version, timestamp, and digital 
> > signature that it can use to verify what version it has, and if the data 
> > is authentic.
> >   
> Objects or references to objects?  I'm still a little bit puzzled by 
> your terminology.

A replication would be a (reference, contents) pair.  So you have a copy 
of some data that is owned remotely, but you're trying to avoid 
downloading it again if it hasn't changed.

> > So, there are two types of authority in this system.  There is the 
> > authority to issue updates to a replicated object, and the authority to 
> > ask an object on another site to be changed.
> >   
> How do these differ?  (still trying to reach understanding).

If we have Alice, Bob and Carol, where Alice is the server, Bob is the 
client and Carol is a third party then:

The first authority is:
A (object is signed) --> publishes change --> B (accepts change)
C (object is not signed) --> publishes change --> B (rejects change)

The second authority is:

B (has capability key) --> requests change --> A (applies change)
C (doesn't have cap key) --> requests change --> A (ignores change)

The difference is in the first case, generally only one entity (the 
owning site) can issue updates.  In the second case, multiple entities 
should be able to request changes (which would then cause a signed 
update to be issued going back to the first case).

I should probably mention that one goal is that this protocol be useful 
when in a broadcast environment, or doing multihop store-and-forward 
routing.  Data integrity and who has authority to change that data is 
important, but securing the actual contents is optional.

> > Knowing 
> > the private key used to sign the communications is a very literal 
> > implementation of the notion of capability.
> >   
> makes no sense to me.  I typically think of the private key as being 
> owned by the object
> server (e.g. see:
>
> http://www.webstart.com/jed/papers/Managing-Domains/#s13
> ) for one system I worked on in this area.  E.g. this:
> 
> If c is the identification information for the resource, then any 
> process able to obtain the data ServerSign(c) is assumed to have the 
> right to access the resource. That is, if a process can produce a 
> capability description "signed" by the server, then the capability is 
> assumed to be valid.

Ah!  Just the sort of idea I was hoping to get by posting to this list 
:-)  Yes, signing a sort of certificate of authority is certainly 
another possible approach I had not considered.  That neatly solves a 
couple problems (it avoids unbounded growth of per-object capability 
tables I envisioned and also permits capability reflection without 
requiring you go to the server) but how do you handle revocation with 
that model?

> Are you familiar with Tyler Close's web-calculus services model:
> 
> http://www.waterken.com/
>
> ?  Perhaps you could explain how what you are working on differs?

This looks very interesting.  I'll have to study web-calculus to be able 
to answer that question properly -- I certainly could be treading over 
similar ground.  But the easy answer is that I'm not designing a web 
system, and web-calculus seems to be at least web-oriented, so at most I 
would borrow their ideas to use in the context of my own system.

> > The second type of authority is more complex, and where I'd like some 
> > advice.  Just to get it out of the way, for reasons of efficiency and 
> > concurrency, I believe this requires a distict approach from the first 
> > type of authority, as distributing private keys on a per-object basis 
> > (granting authority to publish a change to the object) creates as many 
> > problems as it solves.
> >   
> Distributing private keys to communicate permissions seems a very bad 
> idea to me in any case.

Agreed.  It was just a strawman argument.

> Well ...  Generally it sounds to me like there is some substantial 
> reinventing of the wheel going on here.  You can see from my questions 
> above that I'm not really sure what you are trying to do or how.

Okay, to briefly explain what I am working on, I am designing the next 
iteration of the Virtual Object System (VOS, http://interreality.org).  
VOS which is a free software distributed object system designed to serve 
as a platform for multiuser 3D virtual worlds.  Virtual worlds have a 
peculiar set of requirements that tends to cut across a lot of fields, 
of which robust security is often overlooked.

> Capability systems (now generally 'object/capability' systems for 
> clarity) are quite simple.
> 
> 1.  Active elements (processes, active objects) can only access 
> objects if they have a "capability" reference to the object.

Yes, that is true in my design.  I think the main fudge factor in what I 
described is that it includes a public object id that may be guessable, 
but that only gets you as far as the default security policy.  My 
interpretation of capability systems (E specifically) was that you have 
a single unguessable identifier, and you can't even compare two 
capabilities to see if they refered to the same logical underlying 
object without going to the object server.

> 2.  In so far as communication is enabled by #1, active elements can 
> send and receive capabilities across their existing capability 
> references.

Yes, that is also part of my design.

> Regarding how user, group, and role-based abstractions in capability 
> systems - you happened to catch "us" (the capability community) at an 
> interesting transition point.

What can I say, good timing.

> I would say that in the past the notion of a "user" in capability 
> systems has generally been a bootstrapping mechanism to access a bunch 
> of capabilities - e.g. in a directory dedicated to the "user".  That 
> is, a "user" logs in (e.g. username/password or whatever), the system 
> finds that user's bag of capabilities and gives it to some program 
> (e.g. a shell) acting on the user's behalf.  Generally I believe 
> that's been it.  After that point the user can send his/her 
> capabilities anywhere that's permitted by their existing capabilities, 
> building up and sharing from there. When a capability is invoked there 
> is no notion of what "user" invoked it.  "Groups" when they've existed 
> in my experience have been directories shared between some set of 
> users.  Send a capability to the directory to a process acting on the 
> behalf of another user, and that new user has been added to the 
> "group."  Regarding "role-based" abstractions - I really don't know.

Hmm, interesting.  Have any significant multiuser systems been built 
using this security paradigm?  What is the user experience like, in 
practice?

> One of the things that just happened (and so in the 40 year history
> of capability systems must be considered just a recent blip) is that
> some of us have described a mechanism for supporting the notion
> of an "identity" (who did what?) in pure and simple object/capability
> systems - a draft:
> 
>          Delegating Responsibility in Digital Systems:
>                    Horton's "Who Done It?"
> 
> found at <http://www.erights.org/download/horton/document.pdf>
> 
> Of course you're welcome to consider that mechanism, but I would have to say
> that it's still quite "raw" at this point.

Interesting.  I'll have to take a look at it.

> Good luck with your development!
>
> --Jed

Thanks for taking the time to reply!

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20070516/0be306e8/attachment.bin