Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Norman Hardy [mailto:norm@netcom.com]
> Sent: Monday, July 24, 2000 1:53 PM
> To: Karp, Alan; 'Jonathan S. Shapiro'; 'Mark S. Miller'
> Cc: e-lang@eros-os.org
> Subject: RE: Split Capabilities: Making Capabilities Scale
> 
> 
> At 9:32 -0700 00/07/24, Karp, Alan wrote:
> >> -----Original Message-----
> >> From: Jonathan S. Shapiro [mailto:shap@eros-os.org]
> >> Sent: Sunday, July 23, 2000 10:25 AM
> >> To: Karp, Alan; 'Mark S. Miller'
> >> Cc: e-lang@eros-os.org
> >> Subject: Re: Split Capabilities: Making Capabilities Scale
> >>
> >>
> ...
> 
> >> We need to be careful about this assumption. Clearly,
> >> cryptography is the
> >> only technique we have right now for security over unsecured
> >> wires. It does
> >> not follow that cryptographic capabilities are required. A 
> sufficient
> >> alternative would be unsecured capabilities transmitted
> >> between mutually
> >> trusting runtimes over a more generically encrypted link.
> >
> >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.
> 
> I agree with both of the above except that I am unsure of the 
> meaning of
> the hypothesis of Alan's last sentence. Is having the address 
> of something
> more or less than having the thing in this case? Or is it an 
> address that
> the client cannot dereference? If so, I presume that this is 
> what Jonathan
> calls partitioned capabilities (citing literature) and that I call
> abstracted capabilities.

In the example, a virtual address is intended to be meaningful only within
the context of a process.  I can tell you my virtual address for something,
but you can't use that address to access the thing.  Perhaps I should have
used a local ref in E as an example.

>			(snip)
> 
> In <http://www.mediacity.com/~norm/CapTheory/Dist/Glass.html> 
> I describe a
> network discipline based on message authentication codes, 
> that are a bit
> cheaper than crypto. I show (sort of) how one can build 
> capability security
> on top of that without secrecy. Secrecy can be imposed 
> selectively later
> (higher) as required. As in E, an application built at this level is
> vulnerable to corruption only in those nodes that it elects to trust.

I'd like to separate the issue of link integrity from that of client
integrity.  I will assume that links can always be made secure in the sense
that information can be made private and/or that tampering can be detected.
I am making a distinction between those capabilities that need to be
cryptographically secure, as are remote refs in E, from those that don't,
e.g., local refs in E.  No trust is needed with a local ref because the
capability is not visible to the user.

> 
> This may be only a curiosity but the method of third party 
> handoff has a
> peculiar solution that I have not seen before and that might have
> application elsewhere.
> 
> The note is dense and, as usual, I would appriciate any feedback on
> inpenatrable parts. If this crowd can't get it then I have a problem!
> Norman Hardy  <http://www.mediacity.com/~norm>
> 

I figured it out, but I did have to use a paper and pencil.  Of course, we
did nearly the same thing in e-speak, so that helped.  We called the travel
agent the "connection factory", and the OB's created by the travel agent
Remote Resource Handlers.  We, too, recognized the fact that an  object
reference obtained from two paths was viewed as two separate objects.  This
distinction is an important one because the access rights granted might be
path dependent.  At any rate, these two could be put in touch with each
other using the same introducer that we used for introducing any two
parties.

_________________________
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