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

[Mark S. Miller]

Jed at Webstart wrote:
> At 03:14 PM 8/16/2006, you wrote:
>> 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

Yes.


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

Great, thanks! I look forward to your comments.


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

Thanks for the compact statement! It made it much easier for me to spot how 
I'd misunderstood your paper. And btw, my apologies for misunderstanding.

The key issue here is to expand on "a variety of means for assuring the 
correctness of network addresses" and to develop a taxonomy of these. I know 
of only three options:

* crypto
* mutually reliant hardware
* what I explain, in section 11.5.2, as restricted access to physical wires:

# Between mutually reliant hardware, on the one hand, and open networks
# protected only by cryptography, on the other hand, there exists an
# intermediate option: Since bits received on a particular physical wire must
# have been sent by a machine with access to that wire, this authenticates
# these bits as having come from such a machine, without needing to rely on
# that machine to behave correctly. The Client Utility [KGRB01, KK02] ties the
# bits that represent a capability to the channel over which the bits are
# received. If that channel is authenticated by means other than a secret,
# such as a physical wire, then bits cannot be used to transmit permission,
# since bits cannot transmit the ability to transmit on that wire.

If this is what you had in mind, I also owe you a second apology -- for
misattributing such authentication by physical wire to the Client Utility
rather than you.

In retrospect, I see why I misread your paper. I came across it while thinking 
about cryptography on open networks (such as the Internet) between mutually 
non-reliant machines. Once one uses crypto to create virtual secure wires 
between machines, then your DCCS protocol beautifully shows how to solve the 
rest of the problem. I think you'll find aspect of CapTP illustrated at 
<http://www.erights.org/elib/distrib/captp/DeliverOnlyOp.html> corresponds 
directly to the DCCS scenario you explain.


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

On an *open network*, when we can't trust the routing fabric. Among machines 
on an open network, and bits received by any of them may have been sent by any 
of the others. If you know of any means other than crypto to deal with this, 
I'd love to hear it.


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

Yes, if Alice, Bob, and Carol are mutually non-reliant machines plugged in to 
the Internet, Alice cannot safely make assumptions about who Bob cannot talk 
to. OTOH, within an object-capability system, if Bob is an object instantiated 
by Alice, Alice can know that Bob can talk to only those that Alice has 
enabled him to talk to. This is the difference.


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

If Alice, Bob, and Carol are CCS processes running on non mutually reliant 
hardware and speaking over DCCS, how can Alice have any confidence about who 
Bob cannot talk to?


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

Can they speak to each other? Can they impersonate each other? If you're 
assuming that "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." then either

* you are assuming crypto
* you are not talking about an open network
* you have something else in mind which I have not yet understood.


>> A related
>> distributed confinement example can be found at
>> http://www.erights.org/elib/capability/dist-confine.html
> [...]
> 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).

How is a machine on Subnet A prevented from sending a message that appears to 
originate from a machine on Subnet B. Again, I know of only three answers:

* crypto - based on knowledge of secrets
* mutually reliant hardware - such as TPMs or NGSCBs
* restricted access to physical wires - i.e., a relied upon routing fabric

Do you have some other alternative in mind?

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM