[cap-talk] Encrypted delegation via membrane [was: In Defense of Identities - not]

[Jed Donnelley]

At 10:54 PM 12/6/2006, coderman wrote:
>On 12/6/06, Jed Donnelley <jed at nersc.gov> wrote:
>...
> > [more detailed and useful description of delegation ...]
> > ...  I believe this data should suffice for
> > the server S to be able to safely determine that this is indeed
> > a permission that was delegated from A to B.  No need for
> > any handshaking!  Hurray!
>
>i think so too; with any necessary reduction of capability thus
>transferred also occurring in this handshake, and flexible (in the
>sense that the reduction could be to a read-only, or
>create/read/write, or other arbitrary capabilities associated with
>domain specific applications)

Right, the client doing the delegation just has to be able to describe
a meaningful reduction in permissions to the server.

>... and need not require delegation of all or nothing
>capability as some critics of caps seem to misunderstand)

Certainly.  The addition of the responsibility delegation
(sender doesn't have the permission that the receiver has,
at least the label) is most of the value that I've added
with this proposed mechanism.

> >  I'll also note here (described more fully
> > below) that it's helpful for revocation if A adds a
> > swiss number to this data block, "SN", that will
> > distinguish this particular delegation for possible
> > future revocation (along with all it's descendents).
>
>this seems to imply some kind of session or lease management,
>associated with a particular key exchange / delegation.

I guess you could call it that.  It's really just hopefully
unique (for the delegation/capability) identifier.  When a
revocation happens it can be used to distinguish which
delegation is being revoked.

>leases are a common way to help curb distributed resource garbage
>collection, for example, the server need only track a given delegation
>to B for a lease of 48 hours, after which A must again delegate a
>capability (renewing lease) or the existing delegation expires and the
>server can free the associated state/resources.

That's not what I'm proposing with the above.  I try very hard to
avoid timing dependent behavior.

> > ...
> > Regarding revocation:  Revocation is a bit difficult (awkward)
> > with this model.  I can see that I should have the delegator
> > add a swiss number to the delegation string.  This swiss number,
> > SN, would pass through all the derived capabilities.  The delegator
> > can create a revocation capability just by saying what it is, e.g.:
> >
> > <I won't bother to add "SN" in all the text above>
> >
> > "revoke"(SN.A->B.Suc)
> >
> > and then signing it:
> >
> > Au("revoke"(SN.A->B.Suc))
> >
> > On the server side is where the awkwardness of this scheme for
> > revocation shows up.  It works sort of like certificate revocation
> > lists and unlike most capability mechanisms for 'destroying'
> > an object where you simply remove a swiss number that was
> > originally created by the server.  If the delegated permission is
> > evoked then the server must store something like:
> >
> > "revoke"(SN.A->B.Suc)
> >
> > with the object designated by c.
>
>i'm a bit confused about how the revocation must function like a CRL
>rather than GUID lookup and delete.

The difficulty is that it's the delegator who has to make up any
identifier for the delegated permission.  When the capability comes
in the server doesn't have anything to look up but the base
object (from which the delegation happened).  Nobody told the
server that such a delegation existed prior to it's arrival, that's
the whole point of doing the delegation without needing to contact
the server (much like my mechanism in Managing Domains was intended
to communicate a permission [capability] without having to contact
the server).

>there is added overhead in
>authenticating the revocation (just as the pubkey capability
>delegation implies more computation than a password capability passing
>mechanism) but the revocation could still reference a swiss number
>associated with a delegated capability.  all delegated capabilities
>would need a pubkey pair, so perhaps this is the awkwardness you
>mention, rather than implying an inability to lookup a particular
>delegation by swiss number.

The way I was thinking of things all the metadata would be stored
where it can be found conveniently from the designation in the base
capability ("c" in the above).

> > I'll be interested to hear if others follow the discussion
> > above and perhaps if people see any holes or other
> > problems with it.
>
>i would have an easier time with a more detailed description of the
>capability delegation,

I think I've described that pretty completely in my previous message.
What do you feel is missing.

>life cycle management, and reduction steps.

I'm afraid I don't know what you mean by the above.  By "reduction steps"
are you referring to permission reduction - e.g. prior to delegation?
That has to be a protocol specified by the server.

>Are there any protocols or implementations which do this style of
>capability interaction?

No implementations that I know of, though we had some along these
lines in the NLTSS system that we ran at LLNL during the late 1980s
and early 1990s:

http://en.wikipedia.org/wiki/NLTSS

--Jed  http://www.webstart.com/jed-signature.html