At 12:26 PM 11/1/99 , shapj@us.ibm.com wrote:
>Droplets is not the first system to use this kind of mechanism. While the
>specific encodings are different, the Lotus Domino server uses an
>essentially similar mechanism for naming Notes objects in web-based
>presentation -- even the format of the URL is highly similar. The Domino
>server, however, is not using swiss numbers; it's capabilities are purely
>object identifiers. Permission checking in Domino is done based on the
>session (and therefore on the user identity).
What are object identifiers? (I know too many definition to have any confidence I know which one you mean.) Is Domino implementing a capability system or an ACL system? Notes was (is?) heavily ACL oriented. If Domino is doing capabilities without swiss numbers, how do they do three-party handoff (the Granovetter diagram when Alice, Bob, and Carol are on 3 separate machines)?
>It is not clear to me if Domino has session-only capabilities. If anybody
>cares I will try to find out.
I care, though more for curiosity than anything else. ;)
>Here I find that my initial impression of Droplets is correct, though I
>think my concerns could readily be addressed. Droplet capabilities are
>unforgeable, but they are not partitioned. Because they are simply data,
>there is no way to restrict their transfer once they escape into the world.
This is all exactly true for E/Pluribus's capabilities as well. My falsifiable claim: any inter-machine "partitioning" protocol does not enhance any actual security. These kinds of unpartitionable data-capabilities implement the most capability security that can be implemented in the distributed context. Machines cannot be confined http://www.erights.org/elib/capability/dist-confine.html , hence, if I understand what you mean by "partitioned", they cannot be constrained to live in a partition either.
However, as explained by the above URL, computation (including distributed computation) hosted on such machines can be confined, given the cooperation of their hosting machine. To do this, you need a secure computing platform, which E provides and Droplets currently does not, but none of this requires or benefits from changes in the protocol.
It is crucially important for us to examine this claim well, and vigorously try to falsify it, as it is a premise of E's security as well as Droplets. A great way to attempt a falsification may be to propose a protocol that claims to provide partitioning *in the protocol*, and see if it actually provides any extra security.
> From my reading of the description at
>http://www.waterken.com/Droplet/index.html (which I may have understood
>incompletely), the session-independent capabilities remain valid
>independent of any particular session.
I will just speak for E/Pluribus here. Yes.
>On the one hand the droplet
>capabilities cannot be forged, but on the other they cannot be trusted as a
>means of security because there is no way to constrain their propagation.
>Once they are out in the world, one may safely attribute to them only those
>qualities normally attributed to object identifiers.
This sounds like the old capability-delegation argument all over again. If I hand you my car key, you might duplicate it and distribute duplicates, but that doesn't mean I can no longer have trust about who uses it or what it may be used for. I can trust that it can only be used by entities and for purposes that you enabled it to be used for. Therefore 1) I can trust it to the extent that I trust you, and 2) I can hold you responsible for the use made of it.
>I want to emphasize that this is a general problem in distributed systems,
>and that I am not aware of a satisfactory solution in the absence of a
>trusted operating system.
Depends what you mean by satisfactory. If satisfactory means confining machines (or enclosing them in a partition), then you are correct. However, a vast number of useful secure patterns of cooperation without vulnerability, including most of the institutions needed to build computational markets, can be done without confinement.
>Droplet's session-only capabilities, when running over an SSL link, provide
>a kind of partitioning for droplet capabilities, though hostile programs
>might still act from the client side by piggybacking on the session.
I didn't get this. Maybe I don't understand what you mean by "partitioning"?
>This
>is a significant narrowing of exposure, and potentially very valuable.
>This is the part of Droplet that most appeals to me. The piece that seems
>to be missing is a private transform that will let me translate a new type
>of sessionless capability (let's call it an unauthenticated capability)
>into a session-local capability, and a corresponding public transform that
>will let me turn the session-local capability back into an unauthenticated
>capability.
Dropping the qualifier "unauthenticated", E/Pluribus does have such a transform. However, we think of it purely as a performance optimization, and not something that contributes to any security properties. Of course, I can't be sure that E's transform, though it fits the above words, is the kind of thing you have in mind. How would such a transform provide any better security?
>In its current form, Droplets has some potentially very useful properties:
If 128 bits isn't big enough for any other reason, then it probably isn't
big enough for security. If 128 bits is big enough to make a random
collision infeasible, then what other problems might it have?
>
>+ It can be used to selectively publish things on a server that otherwise
>contains private information (this is because of the swiss numbering)
>+ It can be used to extend the web URL space to generalized object
>identifiers (128 bits might be too small, but not because of security).
Cheers,
--MarkM