[cap-talk] capabilities (network and non), "server", etc.

[Karp, Alan H]

Jed Donnelley wrote:
> 
> What don't you like about the word "server"?
> 
It smacks too much of client-server.  Capabilities are naturally P2P in
that whether a particular party is a client or a server varies from
request to request.  However, I can agree to use the term client for the
invoker of the capability and server for the responder.
> 
> What you refer to then as an "explicit introduction" is
> part of the capability communication mechanism that
> you've implemented.  Just for my curiosity, is that
> introduction handled by the application lever server or
> at a lower level?
> 
It was done at the application level.  Our feeling was that only the
application had the information needed to make the decision.  (I don't
know how well the protocol worked.  The implementation was never
completed because we switched to SPKI certificates.)
> 
> I was mostly asking whether you would consider it
> "capabilities as data" or "capabilities as descriptor".
> To me it seems to have some aspects of both.
 
I think I missed something on my first reading of your papers.  Let me
see if I've got it right.  The capability data block contains the memory
address of the resource and some means of validation.  This data can be
transmitted within a machine or between machines.  When transmitting
across the network, the address part of the capability data block must
be augmented with the network address of the server's machine, but other
than that, it's the same.  I would call this "capabilities as data".
With the protection mechanisms you describe, I would not call them
"password capabilities".  For some reason, I mistakenly thought your
scheme worked like E, which uses the data sent from the remote machine
as an index into a table to find the object reference.  I would call
that approach "capabilities as descriptor".
> 
> What do you consider the advantages of the explicit
> introduction?  I saw some value in avoiding the computational
> cost of the encryption and threats to the encryption algorithm.
> However, after that the costs seems to me to be mostly
> on the "access list"  model side, particularly where
> messages are required (introductions) whenever a
> capability is moved from one process to another.
>
We saw a number of advantages.  First of all, it fit in nicely with our
overall model.  (See the split capabilities paper to see why, or I can
explain later.)  Secondly, we liked the control it gave.  Alice could
give a capability to Bob.  Bob could forward it to anyone he pleased,
but Alice didn't have to expend any additional resources, primarily
associated with connections, unless she wanted to.  We also worried
about opening up Alice to attack.  Alice might forward a capaility to
Bob after vetting him in some way.  If Bob passed that capability to
David, Alice could choose to vet him before accepting the introduction.
If she didn't accept the introduction, David would have no direct
connection to Alice, limiting the attacks he could mount.
> 
> I'm also curious if you read the section about the
> "Reflection Problem" in:
> 
> http://www.webstart.com/jed/papers/Managing-Domains/#s11
 
Yes, that's the attack that you discussed that I mentioned in an
earlier.
 
> 
> and whether any analogy to that problem exists or existed
> in your rights communication mechanism.  As you can
> see there I found in the mechanism that I flow charted
> that it wasn't sufficient for A (Alice) to introduce B
> (Bob) as now having the right and then send a message
> to Bob saying, in effect, "here is this capability".  The
> danger is that Bob might have already had the right
> and might mistakenly think that it had been received
> from Alice when Alice was just playing a sneaky game
> to make Bob think she had sent him the right.
> 
> In the mechanism there the server (or a part of the
> capability communication mechanism fronting the
> server) must let Bob know that the right actually
> did arrive from Alice.
> 
> Did you ever run into a situation like that?
> 
I don't think we had that problem.  The main difference was that when
Alice introduced Bob to the Server, Bob got the capability from the
Server, not from Alice.  In our scheme, Bob then had two capabilities
that referred to the same resource, one invoked directly to the Server
and one via Alice. 
> 
> Perhaps it may be a terminology problem again, but I think
> there is no such c-list on the server side.  When the capability
> arrives in the server it does so in a clear text form with all
> the rights spelled out.
> 
A misunderstanding on my part.
> 
> I remember hearing about this mechanism somewhere.  To me it
> just seems not to scale.  Clearly the higher the network latency
> and the more nodes involved the higher the overhead.  All the
> capability communication mechanisms that I worked on from
> DCCS through NLTSS and those discussed in the Managing
> Domains paper had the property that once a capability was
> communicated its use was just as direct and efficient as if
> it was passed the capability directly.  Of course any process
> that has a capability could proxy it and communicate the proxy
> instead of the direct capability.  That choice in my opinion is
> one that the application should have control of.  Once a
> capability is proxied then of course that proxied capability
> should be able to be passed directly and not be forced
> into again being proxied by the capability communication
> mechanism.
> 
I see it as a choice of default behavior.  We chose explicit
introduction; you chose introduction by default.

The extra latency was a problem we worried about, but we liked the extra
control.  In actual use, paths rarely exceeded two or three hops.  When
they were longer, people could shorten them by introduction.  Often the
introduction wasn't all the way back to the Server, but to some other
intermediary.  The end result was that the system worked as well as we
had hoped in deployed systems.
 	
________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 433 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20041026/d185f105/KarpAlanH.vcf