[cap-talk] Another "core" principle - Brinkmann

[Jed Donnelley]

At 08:32 PM 12/22/2006, Marcus Brinkmann wrote:
>Hi,
>
>I think I see now what you want to achieve.  I think you can achieve
>all of this in a pure capability model, assuming revocable delegation
>(without any identity tracking) and a MyCap? operation.  No extension
>to the capability model seems to be necessary.

I want to make clear that I never suggested any extension to the
pure object-capability model.  I've stated this many times during this
discussion.

>Here is a very rough sketch of what needs to happen, I can expand on 
>this if necessary,
>although it seems rather standard to me.

I agree that it is "rather standard".  You are describing nearly
exactly what I've tried to describe several times during this
discussion.  The power of email ;-).  If others like this
description better or see what appear to be any substantive
difference, I'd like to hear about it/them.

Perhaps I can ask again for any thoughts pro or con on the
basic model and the value (or not) that it provides.

One aspect of things that's different in your discussion
is the "emergency capability" that you suggest that Carol keep (get
somehow?) to the server.  I don't see a need for such a capability if
we're assuming that the subjects are people.  In that case Carol
can call or email Alice (or R) and ask that her capabilities delegated
through Bob be restored.  Alice (or R) must make a policy decision,
based on other information (e.g. an independent introduction to
Carol) and choose to either request the bypass or not.  I believe
Alice can do her bypass call simply on P_A, or what I've referred
to as the capability labeled R->A.  Your introduction of P
might suggest syntax like P:R->A.

One other thing that I want to make clear that I think is important
(and as I recall shows up in the Horton protocol) is that the
capability exchange must (for responsibility tracking) be such
that (at least initially) only Carol possesses what you refer to
as P_C and I label R->A->B->C.  None of R or A or B can have access
to this capability unless explicitly communicated from Carol.  This
is the aspect of things that can assure responsibility for logged
actions - non repudiation.

>I will pick up on your scenario that there is a system service S, an
>administrator R, and users Alice, Bob and Carol.
>
>Access to S by means of a capability P is delegated initially to R
>(initial configuration), then to Alice as P_A.
>
>1. Step: Revocable delegation with identity binding.
>
>Alice creates a new capability P_B, derived from P_A, which is bound
>to an identity "Bob".  The quotes indicate that this is a name for Bob
>which is now shared between Alice and S.  A name can be a fingerprint,
>a capability, whatever.  If this name should be good enough for R to
>know who "Bob" is, Alice and S and R need to agree on a common name
>service.  Weakening this requirement seems useful in the case where
>arbitrary users want to introduce new identifiers for their own sake.
>
>P_A->Bind_Identity ("Bob") => P_B
>
>The binding is stored in the server S for later reference.
>
>The capability P_B is then delegated to Bob by Alice.  Bob can repeat
>this step for a delegation to Carol, yielding a capability P_C, bound
>to "Carol", delegated to Carol.

While you refer to the capabilities as P_A, P_B, and P_C, I think of
them as more P_R, P_R_A, P_R_A_B, and P_R_A_B_C where not I've used
your "_" as the delegates to rather than the "->" that I've used
previously.

>2. Step: Emergency capabilities
>
>Presumably, Carol wants to be able to use the capability even if Bob
>revokes it, assuming that Alice or R will agree.  To establish this
>possibility, she needs to retain a communication channel with S (or
>some equivalent service) that has a lifetime beyond Bob's delegations.
>You assumed such a channel when describing the example to me, where
>Carol gets a message to some effect like: "Go ask Alice".
>
>So Carol requests an "emergency capability" from S by means of her
>capability P_C, for example:
>
>P_C->GetEmergencyCap () -> E_P_C
>
>This capability will be directly delegated from S to C.  It will be
>associated with the same internal object as P_C, but as a weak
>reference and providing a different interface (more details below).
>
>Now bad things happen, and "Bob" is revoked (the identity, not the
>person :)
>
>
>3. Step: Revocation of identities
>
>Somehow "Bob" is removed from the equation, and all capabilities
>delegated by Bob are lost.  This affects Carol, and only Carol, at
>this point.  P_C is now a dead capability.

Where we see that it must have included it's dependence on Bob.

>4. Step: Appeal for Resurrection
>
>Carol notices that P_C is dead, for example by invoking it.  Now she
>can use the emergency capability E_P_C to query the object status, for
>example the delegation chain as in your example interface output.
>
>C can now appeal at R or Alice, or whatever.
>
>E_P_C->WhatsGoingOn () => "Bob's identity was lost..."
>
>E_P_C->Resurrect () => New P_C     ; (*) Returns later, see below.
>
>Note that the last call may not return yet.  First, something else
>needs to happen:
>
>
>5. Step: Bypass and Reclamation
>
>Say Alice complies with Carols request.  Then she makes a call to S,
>granting Carol access.  While she is at it, she can also clean up the
>resources occupied by the identity "Bob":
>
>P_A->Bypass (P_B, "Carol") => void  ; SIDE-EFFECT: (*) above returns
>
>P_B->Destroy ();
>
>
>Many details are wrong with this, but probably none you care about
>(resource management, etc).  Also, again we ignored matters of how to
>establish identities across parties.  Apart from a ton of other
>problems I see with this scenario I think it (or some variation of it)
>achieves roughly what you asked for.

Exactly, though perhaps I don't consider the "details" as serious
as you seem to suggest above.

After the above discussion I would say that you and I are on
almost exactly the same page.

Given the above, do you see value in a mechanism like that?
Once again let me note (since apparently there's been some
misunderstanding) that all the above is pure object-capability.
However, what it achieves is I believe the meaningful part of
identity based access control that ACLs attempt to achieve.
ACLs fail to deliver even simple delegation, but do succeed
in a kind of identity based access control.  With this
sort of pure object-capability approach we provide for
delegation that can be used in a POLA manner, while still
including identities for responsibility tracking and for
access management.

Seems like a win - win situation to me.  In particular it
seems to me to answer the substantive objections to
"traditional capability" systems given in:

http://www.webstart.com/jed/papers/P-1935/

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