[cap-talk] network level designation and authorization, meta
Jed at Webstart
donnelley1 at webstart.com
Mon Jun 19 18:00:57 EDT 2006
At 04:05 PM 6/7/2006, coderman wrote:
>On 6/5/06, Jed at Webstart <donnelley1 at webstart.com> wrote:
> > ...
> > So ... where to go from here? I still believe that doing the right thing
> > (POLA, communicable authority tokens) at the network level (e.g.
> > YURLs, widewords, etc.), demonstrating its viability (e.g. for
> > resource sharing - perhaps like with Google's new spreadsheet
> > application), and then driving that paradigm down to the OS level
> > is the most likely approach to succeed.
> > ... What's really
> > needed is a practical path to change the basic authority paradigm
> > for computing. To me starting at the level of the network is the best
> > hope.
>what about virtual private networks for network level designation
<many contributions by others in a tight flurry>
>Coderman (full name??): > yes, resource discovery and transitive
> > introduction is something i'll have to read up on in CapTP before
> > I can say what essential differences might be encountered in a
> > PVC vs. CapTP interaction.
> > again, i think in some cases this proxy requirement might be desired
> > (revocability) and in others it might not (transitive
> > introduction for direct peering).
>Mark Stiegler: You are correct, proxying is sometimes desirable and
>sometimes not. The
>key to victory is to support all the variations on this 3-person
>scenario easily. A good exercise
Whew. I finally caught up (I think) on the "network level
designation and authorization"
thread and it's fork.
Partly because it was my quote referred to in the initial message
above and partly
because I believe I have something to contribute at what's a bit of a meta
level, I'd like to summarize and hopefully contribute something.
As I read the whole discussion, the focus is on protecting data on the
wire (air). I have to admit that I think of this topic as pretty much a
solved problem (e.g. SSL). I'm afraid I don't know enough about
CapTP to comment intelligently. If somebody thinks there are
important unsolved problems in this area (e.g. especially important
for capability communication), then I'd like to hear about it so I can
investigate further. I wonder if somebody might be able to give me
a summary of what CapTP contributes to this area and where I might
best read more about it?
Here's my meta level comment:
All this discussion applies (I believe) as well to protecting data as it
does to protecting capabilities (generalized authority tokens) during
I would like to mention in this context the problem of protecting
capabilities (authority tokens) in the memory of programs. Some
forms of capabilities (e.g. "password" capabilities, sometimes
confused with the more general case of capabilities as data)
are vulnerable to authority theft if their representations can be
stolen (sniffed, etc.). I would like to point out that for such
vulnerable capability representations, there is more than just
vulnerability on the wire (air) to consider, but also vulnerability
in memory. E.g. in process dumps, system dumps, on disks,
I developed a potential solution to this problem many years ago:
that incidentally also protects capabilities if communicated
over un encrypted channels (though of course not protecting
the data which is considered less sensitive, but likely should
also be protected - as this thread addresses). I've discussed
this issue and the above implementation with others personally,
but I think not in this broad context on the list before.
I believe this is an important issue, at least for capabilities
as data that are used for network communication of capabilities.
Some people seem to feel that such capabilities are necessarily
vulnerable to memory/buffer theft. This isn't so. Others believe
this isn't a substantive problem (e.g. Tannenbaum) as the
data is equally as sensitive as the capabilities and need to
be protected equally (e.g. the data could contain a password).
I disagree with this position. Data such as passwords are properly
given special protections. I believe capabilities as data deserve
such specially enhanced protection as well. This is mostly true
because in some cases a single capability (e.g. to a directory)
can transitively be used to expand to considerable and sensitive
While it's true that capability communication mechanisms and
a capability model of authority used by programs provide tools
to utilize and communicate very limited authorities (one of the
primary values of the object capability model, POLA), I believe it's
important to build a capability communication infrastructure that
is robust enough to deal with the most sensitive of capabilities.
I believe this issue is independent of the topic of cryptographic
protection of process to process communication (the focus of
this thread to this point I believe). I also believe, however, that
appropriate protection of communicated authorities requires
protection for them in memory (unlike data in general) in addition
to protection on the wire (air).
I'll just leave my proposed solution (public key based) out there
as referred to above, but I'd be happy to discuss this topic if
others are interested.
More information about the cap-talk