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

[Karp, Alan]

Mea culpa, mea culpa, mea culpa.  Crypto is wonderful.  Crypto is grand.
It's even needed in some situations.  I'd just like to minimize the number
of places it's needed.  When I said that crypto wasn't needed, I meant only
to protect the capability.

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Monday, July 24, 2000 1:50 PM
> To: Karp, Alan
> Cc: 'Jonathan S. Shapiro'; e-lang@eros-os.org
> Subject: Capability Protocol Taxonomy (was: Split Capabilities: ...)
>
>			(snip)
> 
> 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.

Exactly.

> 
> 
> 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.

Let's leave the link out of the picture.  Just assume that I can
authenticate who I'm talking to and that our communication is safe from
tampering and eavesdroppers.  As long as the two Vats don't trust each other
to the extent that they share local refs, they are separate TCBs.  I think
that's the problem you want to address. 

Now, let's talk about e-speak Beta 2.2.  I think you've got it right,
almost.  When the vats first connect, they each set up a proxy to act on
behalf of users on the other machine.  In the simplest case, the proxy for B
on vat A will have a protection domain that includes a name space containing
entries for all objects to be made accessible to users on B.  

Now, where does name guessing come in?  If B is also connected to vat C,
then the proxy on B for C will have its own protection domain and name
space.  Any name specified by C has no meaning outside of this name space.
If you are talking about two users on A, then guessing is not only possible
but encouraged.  If I want to restrict the access to particular users on A
from accessing the resources, vat B will authenticate the individual users
and set up a separate protection domain and name space for each.  Now,
there's no name guessing attack.  A guess by user 1 on A of a name available
to user 2 on A is doomed to failure because the names are interpreted in
different name spaces.  The only guessing attack that might work is someone
tapping into the communications link, and there I should have encrypted on
the link.

Why did we do things this way?  Originally, we did not have separate PDs for
separate users on a remote machine.  The reasoning is straightforward.  Does
A trust B?  If it does, then A can expect B to enforce A's policies on which
users should be allowed to access which of A's resources.  If A doesn't
trust B, then A can't trust B not to steal the private keys of B's users.
If A can't trust the identity of a user on B, there's no point in trying to
separate access rights by identity.  We added the ability to provide
separate PDs for remote users when it was pointed out that B might be able
to violate A's policies but not steal private keys.

> 
> 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.

Of course, you need authentication and secure communication.  I meant that
the capabilities need no crpyto.  However, e-speak has no off-line
capabilities (if by that you mean capabilities that can be transmitted out
of band, like publishing them in the newspaper or sending them via e-mail).

You have the introducer correct, but there's a missing feature.  Alice, in
the introdution, can tell Carol the list of things Alice would do on Bob's
behalf.  Thus, Carol need know nothing of Bob's trustworthiness.  Carol
might as well grant these privileges to Bob, because Alice can always act as
a proxy for them.  If we leave out this information, Carol would have to
assess how much to trust Bob, a difficult if not impossible task in a
large-scale environment.

> 
> (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.
> 

Nope.  The proxy for A on B has a namespace that doesn't have a name bound
to Carol.  The vatb-vatc namespace is only accessible through the proxy on B
for C.  Hence, there is no name guessing attack.

The e-speak Beta 2.2 naming system is an example of how we liked to do
access control.  We felt that it was better to make an attack inexpressible
than to try to prevent it.  Interpreting names in a name space associated
with a particular authentication makes name guessing inexpressible.

> 
> 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?
> 

E-speak Beta 2.2 does not have offline capabilities.  Split capabilities are
resources that have entries in the e-speak repository.  Other resources have
repository entries containing references to these capabilities.

> 
> 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.

Actually, this is a strength.  Alice and Bob can authenticate each other; so
can Alice and Carol.  By introducing Bob and Carol, Alice allows them to
communicate without needing to be able to mutually authenticate other than
the identity Alice provides to each for use with the other.

> 
> 
> 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
> 

_________________________
Alan Karp
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278