Capability Protocol Taxonomy (was: Split Capabilities: ...)

[Mark S. Miller]

At 09:32 AM 7/24/00 , Karp, Alan wrote:
>Actually, you only need cryptographically secure capabilities if they are
>outside the control of the TCB.  If all the client has is a virtual address
>that points to the capability, for example, you don't need crypto or trust
>between the parties.
>
> >...
>
>We need to be explicit in how the crypto is being used.  A cryptographically
>secure link prevents tampering and eavesdropping.  A cryptographically
>secure capability prevents forging of access rights by tampering with the
>contents of the capability.  I am only discussing the latter.
>
>In e-speak DR 3.0, the capability is a bag of bits that the clients can pass
>around any way they like.  In this case, the capabilities internals are
>visible to the user and must be cryptographically secure.  In e-speak Beta
>2.2, the capabilities are handles to data structures maintained in the
>engine's address space; there is no need for crypto.

Now wait a second...

To understand Alan's claim, here's a start on a taxonomy of properties of 
secure capability protocols for the Cypherpunks Reference Scenario and its 
variations.  We now have enough such protocol proposals to flesh out some 
cases:  E/Pluribus http://www.erights.org/elib/index.html , Droplets, 
E-speak2.2, E-speak3.0/SPKI. and Unibus 
http://www.erights.org/elib/object-pluribus/unibus.html .  (Though no one 
is proposing that Unibus actually be implemented, it is a thought
provoking example.)

I don't cover Joule's distributed capability protocol, Indra, because I 
don't believe it was ever publicly disclosed.  Dean?

For mutually authenticating mutually trusting TCBs communicating over an 
SSL-like secure data pipe, they are effectively a distributed implementation 
of a single TCB, so further protocol questions would just be an internal 
implementation matter.


1) Must communications be secret in order to prevent authorized access

For E and Droplets, yes -- in order to protect the secret SwissNumbers.

For Unibus, yes, in order to protect the secret keys.

E-speak3.0 uses SPKI certificates, which transmit no secrets and are self 
authenticating.

E-speak 2.2 is the interesting case.  When VatA and VatC have a connection, 
VatC has a name space associated only with the connection to VatA.  Given 
that any object in VatA (such as Alice) has been given access to Carol, 
there will be an entry for Carol in this name space.  The name is guessable, 
since the security comes from authentication & integrity on the channel 
between VatA and VatC -- only VatA's use of names is dereferenced in this 
name space.  This is precisely role of the guessable small index numbers in 
E's Object-Pluribus protocol 
http://www.erights.org/elib/object-pluribus/index.html .  In the example, 
Carol would have an entry in the Exports table associated with VatC's side 
of the VatC-VatA connection.

So far the two protocols are morally equivalent.  Where they part company is 
in implementing the Granovetter Operator when Alice, Bob, and Carol are in 
three different vats -- which we distinguish in the next item.


2) Must offline capabilities be receiver specific?

For E and Droplets, the answer is simply no.  A URI string can be redeemed 
in any vat in order to get the corresponding capability.  

In E-speak3.0/SPKI, the answer is yes.  Alice can only manufacture offline 
data which can be used to authorize Bob to access Carol by manufacturing a 
certificate *specifically* authorizing Bob.  This property would seem to be 
implied by the property of not relying on secret communications.

Unibus cannot do offline capabilities at all.

In E-speak2.2, I don't see how to do offline capabilities.  In 
E-speak2.2, there are two forms of Granovetter introduction, which I'll call 
path-chaining and path-shortening (If you have terms for these, please let 
me know.)  

* In path-chaining, Alice would introduce Bob, not to Carol, but to a 
   forwarder for Carol hosted on VatA.  Bob would invoke "Carol" by using the 
   name for the forwarder in the VatB-VatA name space.  The forwarder would in 
   turn forward by using the name for Carol in the VatA-VatC name space.

* In path-shortening, VatA informs VatC that the object she knows by 
   whatever-name-she-call-Carol-on-this-connection is to be made accessible to 
   VatB.  I assume VatC then makes up a name under which she enters Carol in 
   the VatC-VatA name space.  VatC responds to VatA's request with this name. 
   VatA then tells VatB to go directly to VatC, and to use that name to get the 
   object in question.

If I have the path-shortening protocol approximately right, then I strongly 
disagree with your "In e-speak Beta 2.2, ... there is no need for crypto" 
statement.  Beyond having secure pairwise connections, you also require 
authenticated third-party designation.  Otherwise, how does VatA identify 
VatB to VatC or VatC to VatB?  Without such authenticated designation, you 
can *only* do path-chaining.

(E does authenticated third-party designation with a VatID -- the 
fingerprint of the public key of the designated vat.  Droplets does this (do 
this?) with https hostname, which is only as trustworthy as the CA system 
behind the various vat's https's, and assumes these CAs all agree on the DNS 
namespace.)

In any case, the above description has a subtle security flaw it's easy to 
fall into, and I'm curious if E-speak2.2 fell into it.  Since VatC's name 
for Carol in the VatB-VatC name space is guessable, if VatB already had 
access in this name space to Carol, the above protocol would allow VatA to 
appear to VatB to have sent to VatB a message containing a reference to 
Carol, even if VatA had no access to Carol.  In order to escape this trap 
with guessable names, VatC would have to have placed a reference to Carol in 
a name space associated only with "objects in VatC that VatA wishes to 
introduce to VatB."  For completely different reasons, E may very well move 
to such a protocol in the future.


3) (Closely related) Do offline capabilities require secrecy?

E & Droplets: Yes
E-speak3.0/SPKI: No
Unibus: No offline capabilities
E-speak2.2: Are there offline capabilities?  If so, how?


4) Following a Granovetter introduction, can Bob communicate directly with 
Carol?

In all, yes.  But in E-speak2.2, only using the path-shortening protocol, 
which (like all the others) requires third party authenticated designation.


5) (Closely related) Are either EQ or rights amplification supported 
sufficiently to do grant matching 
http://www.erights.org/elib/capability/grant-matcher/index.html ?

In all, yes.  But once again, in E-speak2.2, only using the path-shortening 
protocol, which (like all the others) requires third party authenticated 
designation.  Without at least this much cryptography, I doubt you can solve 
the grant-matcher puzzle.  If you can't solve this puzzle, I doubt you can 
build a generic escrow exchange agent 
http://www.erights.org/smart-contracts/exchange.html .  But I need to 
substantiate this last claim.  Some other time...


         Cheers,
         --MarkM