[cap-talk] Capability levels - transparent network extension, no encryption

[Jed at Webstart]

At 03:14 PM 8/16/2006, you wrote:
>On 8/16/06, Jed at Webstart <donnelley1 at webstart.com> wrote:
> > I think it's important to ask and answer questions such as:
> >
> > "What's wrong with a network level implementation?"  (e.g. password
> > capabilities like YURLs).  Whatever is wrong, can it be remedied 
> at the network
> > level?  If not, why not?
>
>If you are asking, in what way are caps-as-data weaker than
>object-caps, then please see Section 11.5 of my thesis: "The Limits of
>Decentralized Access Control".

I assume you're referring to:

http://www.cypherpunks.to/erights/talks/thesis/markm-thesis.pdf

I hadn't seen it before.  Of course I'll read it with pleasure and pay
particular attention to that section.

Let me note here a misconception I see in Section 25.3 DCCS:

"Jed Donnelley's DCCS" [Don76] is the first to realize and explain 
how the capability model
may be cryptographically stretched between mutually defensive 
machines in a decentralized
manner"

The DCCS:

http://www.webstart.com/jed/papers/DCCS/

did not depend in any way on cryptography.  It assumed that network
addresses could be relied upon.  That is, if I receive a message from
X it came from X and if I send a message to Y then at most Y will
receive it.  There are a variety of means for assuring the correctness
of network addresses, some hardware and some software, including
some using encryption and some not.  The DCCS design is agnostic in
that regard and doesn't itself include any cryptography.

At the network level what might be called the DCCS servers used an
ACL sort of mechanism to distribute local capabilities.

To save you some reading time, here's a simple statement of how it
was designed:

Each CCS server keeps a list (a c-list) of capabilities that it makes available
to other systems - according to the capability model of when capabilities
are communicated across the network.  Associated with every entry
in this c-list is an array of the network addresses for the systems that
have permission to access the capability.  Capabilities are communicated
between systems as indexes to entries in these lists.

Here's a walk through of simple example: If Alice on system A sends
a message to Bob on system B that includes a capability to Carol
(let's assume for this example that Carol is serviced on A - if
the Carol service is elsewhere then the example has another twist),
then the Carol capability necessarily goes up to the network server
(as the only way for Alice to communicate to Bob) which of course
realizes that it's internal representation of the Carol capability would
make no sense on system B (even if it could access that internal
representation - which it can't as an ordinary process).  The network
server adds this capability to it's list (if necessary - first entry),
adds address "B" to the ACL for this capability (if necessary - first
reference for B) and then communicates the index in the invoke
message to B.

I hope the above explains the basic mechanism.  No cryptography
is used.  There seems to be some idea that cryptography is the
only means available for distributing capabilities to a network.
I seem to recall Tyler making such a statement also.  While
cryptography may be an effective way to distribute capabilities
on a network, I don't believe it is required and I believe the DCCS
is an example of where it isn't used.  This approach shows up
again in the ACL mechanism in the Managing Domains paper:

http://www.webstart.com/jed/papers/Managing-Domains/

(where a bug in the DCCS mechanism is corrected) though again
remember that this just describes a mechanism for distributing
capabilities - the mechanism is process based and uses no
"ambient authority".

> > If not, then doesn't that mean that any capability mechanism
> > implemented at a lower level that remedies a perceived deficiency at the
> > network level CAN'T be extended to the network level?
>
>Yes, object-caps can't be extended transparently to open networks.
>However, they can be extended non-transparently, as the remote
>confinement example in section 11.5.1 illustrates.

Hmmm.  In some sense I regard the terms "confinement" and
"open network" as opposites.  That is, confinement specifically
deals with limiting communication to a least number of authorized
channels while the term "open network" suggests a model
where active objects (processes) can communicate anywhere
on the network.

However, I think the DCCS mechanism is a good example for
this situation in that I do regard it as a transparent extension
of an object capability mechanism across a network.  If you
believe that it fails either as an extension mechanism or in
it's transparency, I'd be interested to know how you believe
it fails.  I believe the DCCS supports full confinement across
a network.  Perhaps you regard the CCS described in the
paper (a somewhat simplified representation of DVH/RATS)
as inadequate in terms of the "object-capability" model?  If
so, how?

One can regard the network as "open" to the DCCS implementation.
That is, it's network server can communicate to any system on
the network.  However, all the systems on the network can agree
to play the transparent object-capability game and thus to make
transparent object-capabilities from distributed systems available
across the network.

One could ask what the network looks like to a system (e.g.
perhaps malicious) that chooses not to properly play the
object-capability game/protocol.  The answer is that it can
see bits with c-list indices coming to it across it's interface.
It can access any objects that come to it across the network
(somebody trusts an apparent object that it appears to
service with some capability), but it can't reach outside
the object capability model for any additional access.

>A related
>distributed confinement example can be found at
>http://www.erights.org/elib/capability/dist-confine.html

I hope we can clarify what I view of as a misconception
that distributing capabilities must necessarily depend on
encryption.

I would also say, regarding this (from section 11.5):

"Our model <the object-capability model> implicitly assumes a
mutually relied upon platform, which is therefore a central point
of failure. ... if these machines rely on each other's attestations,
then they each remain a central point of failure for the collection
as a whole..."

that I don't agree that the object capability model must either
rely on encryption or have a central point of failure.  A simple
network like:

                   _______________
                   |              |
                   |   Subnet A   |
                   |              |
                   ----------------
                  /                 \
                 /                   \
------------------            ----------------
|                |             |              |
|  Subnet B      | ------------|   Subnet C   |
|                |             |              |
------------------            ----------------

where each subnet has it's own address range, each
knows the range of the others, and within each system
they run CCS systems with a DCCS distribution mechanism
on top seems to me to provide transparent network capability
distribution with no single point of failure (for the whole network).
That is, the subnet A can fail or even become malicious and
all the systems on subnet B and C continue to function properly
except perhaps for any induced load coming from A (which can
of course be filtered in the interfaces to subnets B and C.

Perhaps I'm interpreting your statements at an inappropriate
level or something.  I'm sorry if I seem to be dragging you into
a long exchange MarkM.  Perhaps somebody else can speak
for your position.  I do think there are some important points
here that need to be clarified - even if it's only for me (apologies
if so).

One other thing I'd like to clean up if possible is what I
perceive as the "bad rap" that cryptography seems to
get in the object-capability world.  While the DCCS
mechanism didn't use any cryptographic technology,
it could have and still provide an equally transparent
and effective extension of the base CCS capabilities.
In that case a system (possibly malicious) on the network
would indeed be able to try to break the cryptographic
protections and to claim to have access to a capability
that wasn't properly delegated to the system.  In this
case one is making a design/implementation trade-off.
One can use an ACL mechanism that requires a message
exchange with the server every time the capability is
delegated from one system to another and avoid encryption
or one can use encryption and allow capabilities serviced
by C to be delegated from A to B without notifying C at the
processing cost and threat cost of the encryption algorithms.
This is exactly the trade-off that the Managing Domains paper:

http://www.webstart.com/jed/papers/Managing-Domains/

was addressing as it was the implementation trade-off
that we faced in NLTSS, though for us the application level
processes were full participants in the network protocol - not
protected and restricted by a "network server" that distributed
capabilities.  I now believe that having at least the communication
system sufficiently capability aware to limit communication
to those channels enabled by capabilities is a more effective
model as it provides for confinement.  As I demonstrate above,
however, even such an object-capability model with confinement
can be distributed in a transparent way across an "open" (not to
the application level processes) network with no single point
of failure.

So ... I ask again, "What's wrong with a network level implementation?"
(e.g. password capabilities like YURLs).  Whatever is wrong, can it be
remedied at the network level?  If not, why not?"

--Jed http://www.webstart.com/jed/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20060816/9cc75639/attachment-0001.html