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

[Jed at Webstart]

At 12:19 PM 8/17/2006, Mark S. Miller wrote:
>Jed at Webstart wrote:
>>At 03:14 PM 8/16/2006, you wrote:
>
>>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.

I admit the writing was a bit - odd.  That sort of pseudo code with 
flowcharts and such
seems a bit peculiar to me now.  I'm not sure why it seemed the best 
way to communicate
that design at the time.  I think I was trying to show that I had 
really thought through the
design to a pretty low level, even though we didn't implement it, at 
least partly because of
the problem with the inability to extend/proxy the RATS file 
capability due to the "attach"
function (e.g. see:

http://www.webstart.com/jed/papers/RATS/RATS.pdf
[that I recently scanned in], page 9).  That "attach" function needed to be an
invocation on a process capability - not on a file 
capability.  Oops.  That's an
example of where I think considering extension all the way up to 
serialization is
important in any capability design.

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

Heh.  No, you should feel free to claim any such mechanism.  In the DCCS
mechanism (and actually in the Managing Domains paper at a later time
when the question of validity of network addresses was just about to
get serious) it simply assumed that some means - hardware or
software - was used to correctly process network addresses.  The DCCS
made no attempt to map such addresses into capabilities or anything
like that.  It simply used an access list mechanism with addresses being
on the lists for remote access to capabilities.  From that viewpoint it
separated the protection of the network address from the 'higher' level
capability communication mechanisms.

When you consider the environment of the time (e.g. our own home grown
"Octopus" network hardware, Aloha and very early "Ethernet" hardware on
the horizon [e.g. "Hyperchannel" that I did extensive simulation studies
of], and the early ARPAnet - with single vendor nodes from BBN), it's
not surprising that one would think of the network address as something
that could be trusted.

There are of course many variations on the sort of mechanism where you can
know which addresses should be properly be able to be received from which
channels - and how far you trust hardware and/or software to validate network
addresses.

In any network scheme like YURLs or Amoeba or NLTSS it's natural to
include the network address in some form in the capability, but this didn't
happen in the DCCS as it built the remote network address and the
remote index into the extended (slave entry in RATS sense) capability
that it made up for remote access - for convenience.  It just needed enough
information in the slave to retrieve the information (index, network address)
that the remote system told it could be used to remotely access the
capability.  As far as I know the DCCS mechanism was fully (except of
course for timing) transparent.

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

It is certainly very similar.  There is also a Mach paper from the 
middle to late 1980s that I
think describes essentially the same scheme.  I think of it as a 
pretty elegant and basically
simple mechanism, so it's not surprising to me that it would come up 
in different contexts.
I do think there can be relevant details in such schemes, but to a 
high level they are the same.
I was sure excited about it when I discovered it.  At the time on the 
ARPA net we were working
on various resource sharing protocols like file transfer, telnet, 
remote job entry, etc., etc.
I thought of a mechanism like the DCCS as a way to share "object"s 
over the network,
independent of their internal semantics.  That's why I published RFC 
712 - essentially
an earlier version of the DCCS description (2/76).  I was pretty 
disappointed as it finally
dawned on me that I was unlikely to ever be able to "sell" this 
concept to the ARPA
net community.

This is partly why this discussion is of particular interest to 
me.  If you look at the
network protocol that results from something like the DCCS and don't 
think of it in
terms of a specific CCS component system, then it looks a bit 
peculiar.  If you were
to consider such a protocol for, say, Unix or Tenex, I don't think it 
would have much
value and wouldn't be implemented.  On the other hand, a protocol 
like the conventions
associated with Tyler's YURLs or widewords do seem to me to make some sense
at the network level even on non "CCS" sorts of systems.  I also 
believe that adapting
(trying to get another word - I hope you take my meaning) such 
network capabilities
(objects) to lower levels (e.g. making CCS capabilities for YURLs or 
E capabilities
for CCS capabilities) does seem to have some validity.  The tricky 
part seems to me
to come in when you try to communicate lower (r.e. the DHopwood 
discussion) level
capabilities 'up' through the representation of a higher level capability that
appears at their level.

To be specific about what I'm getting at, suppose RATS didn't have the problem
with the file capability (actually I suppose it doesn't matter) and we had
implemented the DCCS over the Internet.  Suppose that also in parallel
somebody (maybe Tyler ;-) had implemented YURLs for the Internet.
CCS systems can perfectly happily and transparently send their capabilities
to other CCS systems over the Internet and can communicate as a
single larger CCS system.

Now suppose somebody in one of those CCS systems says, hey, I'd like
to get access to this  "YURL" capability:

https://wideword.net/doc/i%2Bej6NZzbDWtc2k444Nk%2FQ%3D%3D

(sorry, all my actual YURLs seem to have expired, but you get the idea).

How would that work?  One approach would be to allow some processes
in a CCS to communicate with the open network.  They could play the
whole YURL game.  However, if they do so they of course lose any sense
of confinement.  They also find themselves dealing with "object"s through
two distinct mechanisms - awkward.

Another approach would be to have some service process (sort of along
the lines of the network extension mechanism in the DCCS or your
"Vat" mechanism noted above) that would turn YURLs into CCS
accessible capabilities.  I hope you can see some of the difficulties
in such a scheme.  There could easily be problems in translating
any requests - getting the data back and forth.  In principle I can see
how that might be worked out.  However, consider the situation with
communicated (delegated) capabilities.  If the capability being
delegated happened to be one that was a local representation of
a YURL, then presumably this could be worked out.  In that case
I think the 'only' issues are variations on the data mapping issues
noted above.

What about the case, though, when the capability being sent "up"
to go out on the network is a local CCS capability that isn't a local
representation of a network capability?  In that case it would seem
that the network extension service must store the local CCS capability
for remote access and make up some sort of a YURL that it can
communicate through the existing YURL to allow the desired delegation
to happen.  Even beyond the data formatting issues (how do YURLs
show up in 'invocations' on other YURLs?) this business of turning
a CCS capability (e.g. consider CapDesk or E) into a network capability
of the YURL sort seems a bit problematic.  You may be thinking it's
problematic in terms of the trust relationships (POLA).  That isn't the
aspect that concerns me.  From the viewpoint of POLA, we have to
assume that the process (active object) that communicated the local
CCS (CapDesk, KeyKOS, etc.) capability out through the local
representation of the YURL knew what it was doing.  It needed to get
a job done and this was the POLA way to do so.  Worth the risk.

What I'm concerned about is how this local CCS capability will
be accessed once it shows up as a YURL?  Now we've really
got a mess on our hands in terms of data formats and protocols.
It's basically that problem that I'm most interested in solving.
That is, coming up with a scheme that allows generic "objects"
to have their permissions communicated and then be accessed
('invoked') at any level in such a scheme for capability extension
and adaptation.

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

I think we have the same understanding of this situation - though I 
think there are a number of variations
that are worth considering.  I'll mention just one:

Suppose you have a LAN with hardware that you trust and you also have
a connection to the Internet where IP addresses come in that in general
you don't trust.  You can have your gateway router check to insure that
local addresses never come in from the outside.

At that point suppose you implement something like the DCCS on top of those
network addresses.  As far as mutual suspicion goes between processes in
your LAN (e.g. consider CCS processes), you can depend on the separation
completely.  As far as mutual suspicion goes with regard to the "processes"
(whatever they might actually be) outside your LAN they all seem to be in
one large munged together domain - even if they appear to have separate
network addresses.

One example that I've found helpful in this regard is to consider 
extraterrestrial
intelligences.  Suppose we have light communication and no other.  We really
have no idea what's "actually" out there.  If at some point we were to try to
separate addresses and develop separate trust for different entities out there,
we could use some means like cryptography to do so (e.g. public key to get
started).  However, having done so, what trust could/should we really place in
any such separation?  For all we know it could be one big entity out there
pretending to be many smaller ones and playing some sort of good guy/bad
guy game to try to get us to trust in some of the entities to lead us on.

I see what you seem to describe as the "open" Internet in similar 
terms.  I really
have no idea what's actually out there unless I tie it into some sort 
of physical
reality.  Lacking any sort of binding to a physical reality (e.g. as 
I would say
I don't have for some useful services - Amazon, Yahoo, PayPal, Google, etc.
that I've no physical connection with except when the occasional package
arrives - even from extraterrestrials we could get information 
"packages") I think
I really have to develop trust on a pretty ad hoc, first principles basis.

There I do think cryptography is the only means for developing such separation,
but any trust in such separation must be built up from first principles IMO.
I'm not as concerned with building up such first principles trust as 
you seem to
be.  To me it's just part of life.

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

I understand.  Now consider a situation where Bob is a process on
a separate CCS on the other side of an "open" network, but where
the two CCS systems communicate over an encrypted link (e.g. latest
KGx) and then use something like the DCCS mechanism to distribute
capabilities between the systems.  Under this scenario Alice creates a
remote "Bob" and initializes it with the limited capabilities that Bob
should have.  I.e. Bob is confined by the remote CCS system much
like Bob could be confined locally.  In that case can one trust the
confinement across the 'open' network?  I suggest the answer is yes.
Perhaps we agree on the extent of that "yes".  I think this gets back
to what we mean by "open" regarding networks.

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

I was thinking about the situation I described above.  Do we agree?
In general when communicating any process should apply POLA
and should of course be aware of any potential for information
'leakage' that may be a concern at the remote end of a request.

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

I think this is a matter of terminology.  Even if I have a network 
(e.g. hardware Ethernet)
where I believe I can trust the network addresses, I can still 
consider it an "open"
network in terms of the permissions that systems connected to the network have.
I was considering that "open" term to mean that all the systems on the network
can communicate freely (e.g. no firewalls) with any other systems on 
the network.
This notion of "openness" I believe is orthogonal to any concerns about the
correctness of network addresses.  Perhaps there is another term I should
be using to avoid confusing this notion of "open" from the way you seem to
be using the term (can't trust network addresses)?

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

No.  In the above I was considering the physical wires.  That is, 
when packets are received
at Subnet C, they are checked to insure that only the addresses known 
to be on Subnet A
arrive on the channel from Subnet A and similarly for Subnet B.  From 
the perspective of
C, anything internal to Subnets A or B are like extraterrestrials - 
unless or until C has some
reason to trust more in the internal separation on Subnet A or B.

--Jed http://www.webstart.com/jed/