[cap-talk] horton questions

[Jed Donnelley]

At 02:38 PM 6/8/2007, Peter Amstutz wrote:
>I've read the Horton paper and I'm explicitly looking at this as a
>component in designing a practical distributed object system (see my
>previous thread) so perhaps I can also help broaden the (somewhat
>contentious) discussion to more concrete issues.

Thanks very much for taking time to read the paper carefully
and comment Peter!

>One thing I found confusing about Horton was the use of "sealing",
>"unsealing", "wrapping", "unwrapping" and "getGuts".  I think the paper
>would be more accessable if it used conventional terminology from public
>key cryptography -- which I believe is how such a system will inevitably
>be implemented, even if the abstract model doesn't require public key
>crypto per se.

I agree.  I've commented to MarkM about this and suggested that
another writeup using just capabilities as data and conventional
cryptography would be very helpful.  Would you like to collaborate
on such a writeup (perhaps you are on the road alone with what
you describe below?)?

Regarding "getGuts", did you take a look at the version of Horton
that uses rights amplification:

http://www.erights.org/elib/capability/horton/amplify.html

?  It does away with "getGuts" and uses wrapping more appropriately
(if with somewhat more complexity).  Perhaps MarkM can comment
more accurately.

>Let me describe how I understand Horton (which reflects how I plan to
>implement it.)
>
>First, the goal of Horton is allow Alice to delegate to Bob a capability
>for Carol, such that Carol can track the responsible party behind each
>action, Alice cannot impersonate Bob, and Bob cannot impersonate Alice.

Exactly.  Just for the one capability to Carol.  To clarify my
understanding for the discussion with Alan, A can act on the carol
capability with Alice's responsibility and B can act on the carol
capability with Bob's responsibility.  A may be able to act on
another capability with Bob's or Carol's or any other (e.g. Dave's)
responsibility.  There is no sense in which A can act "as Alice"
except by invoking what it has, namely P1 and P2 (which happen, for
this example, to be labeled as Alice's responsibility - and served
as Carol's responsibility).

>The two "obvious" means of delegation, where either Alice gives Bob her
>capability, or Alice asks for a capability from Carol in clear text,
>both suffer from the impersonation problem, so the contribution of
>Horton is that it provides a simple protocol by which neither Alice nor
>Bob compromise their own identities in sharing the capability.

Right on.

>Horton works by having Alice ask Carol to generate a new capability, and
>providing Bob's public key.  Carol creates a capability, attaches
>auditing information to it (who requested the capability, and who the
>capability is for), encrypts the capability using Bob's public key, and
>returns it to Alice.  Alice receives the capability intended for Bob.
>Because it is encrypted, it is inaccessable to Alice and cannot be used
>to impersonate Bob.

Right.  Great description.  Just as a point of reference, it is the
involvement of Carol (Carol's identity, her private key or unsealer)
that I find objectionable and that we are trying to eliminate - though
it remains to be seen at what cost.

>Alice passes the encrypted capability to Bob.  Bob uses his private key
>to decrypt it and extract the capability to access Carol.  He can now
>use that capability; on Carol's side any actions performed using that
>capability will be logged as coming from Bob rather than Alice.

Exactly.

>Assumptions:
>  * Alice, Bob and Carol are "self identifying" in that fundamental
>identity is derived from a public/private key pair.

Right.  As a fine point, it's important to note that in Horton
A, B, and C do not have access to the unsealers (private keys)
of Alice, Bob, or Carol.  Those unsealers are closely held
inside the stubs that constitute the Horton protocol.

>  * If Bob and Carol reside on different hosts, Bob may need to ask Alice
>how to contact Carol to establish a direct connection.

B receives what it needs to contact C in the message from A.  B
receives the "stub" P3 that is a capability to the stub (S3) that
C can receive requests on (I'm getting in a bit deep here and
may make a mistake or two in trying to clarify some fine
distinctions - I think you have the big picture just right).

Note that to deal with the different systems case the Horton
implementation can be serialized (like DCCS) using MarkM's
vat implementation.  However, I agree that a capabilities
as data implementation (e.g. along the lines of Tyler's
Waterken Web Calculus or Widewords or even Amoeba or NLTSS ;-)
seems natural for the network case - though you lose
confinement.

>Alice provides a
>connection string which is digitally signed by Carol (so the connection
>string and public identity are tied) and Bob performs a
>challenge/response protocol on connection to verify that Carol is
>actually on the other side of the connection.

When you say "Bob performs a challenge/response protocol on connection
to verify that Carol is actually on the other side of the
connection" I believe you are adding an element that is not
in Horton and may (should) not be needed.  Before that your words
sound right to me.

>  * This may be beyond the scope of discussion about capabilities, but
>what are the implications of allowing Alice to volunteer to proxy
>between Carol and Bob?

A (not Alice) is merely in a position to invoke capabilities
P1 and P2 - by the initial conditions.  A by volition wishes
to invoke P1 and pass the capability (object) P2 in the
invocation as an argument.  The fact that the Horton mechanism
(protocol) goes on under the covers is invisible (or at least
can be invisible - as in this scenario) to both A and B
(and C I believe).

>Man-in-the-middle attacks traditionally work by
>assuming the user is using a less-secure form of identifier (IP addresse
>or domain name) that can be taken over and inject their own public key
>in place of the party they are spoofing.  If the primary identifier is
>the public key (and the network address is treated as secondary) then I
>believe this would defeat that sort of attack.

I believe that's correct.  What comes with the capability (in the
Horton code what's in [available to] the stubs, P1, P2, and ultimately P3)
is only the sealer (public key analog) of the remote identity, though it
has access to the unsealer (private key analog) for the local identity.

>A couple other questions:
>  * One aspect of the Horton paper I don't quite understand is the need
>for an extra interaction between Bob and Carol to fetch the actual
>capability.  As you can see I omitted it in my description above in
>favor of encrypting the capability directly, but I would like to know
>why that was considered necessary.

I don't know what "interaction" you are referring to.  Once Bob's
stub S1 unwraps (I could have the wrong term here) the P3 object,
it is that object that is available to it as it's version of the
'c' capability labeled as Bob's responsibility.  Note that it
takes on Bob's responsibility because Bob's identity is responsible
for the remote (serving) side of the P1 capability - not in any
sense because Bob may have created the B active object (process).
There is a difficult and fine line here between trying to
simplify things for pedagogical purposes (e.g. matching A with
Alice, B with Bob, and C with Carol) and going too far so as
to actually cause more confusion than clarification (e.g. if
people come to think of A as being fully and only Alice's
responsibility - as it happens in this example - with no other
possibility).

>  * Someone mentioned the desire to avoid requiring a communication
>between Alice and Carol.

Me.  MarkM and I have discussed this.  We've both worked on it some,
me publicly on the list and MarkM indicated he would address it as
time allowed in a telephone conversation we had.  Any input is
of course welcome (more on this below).

>How about this: Alice creates a message
>containing her capability and Bob's public key, and is signed using
>Alice's private key.  This is in turn encrypted using Carol's public
>key, and passed to Bob.  Bob can turn in this message to Carol to get a
>capability back at his leasure (provided Alice's capability isn't
>revoked in the mean time).

The above is along the lines of what we've been pursuing.
The way I've put it is that for the capability to be
communicated from Alice to Bob (jumping up a level for
simpler discourse) Alice signs a message to the effect
of "I Alice delegate this capability 'c' for use by Bob".
This message then is effectively a capability as data
that Bob can use in communication with Carol.

But ...  There are some difficulties as I see them.
In the situation where the capabilities are as descriptors
(e.g. the E implementation, many others) and are bound
to the permission and delegation of a communication
channel, how does Alice convey the permission to
communicate to Carol?  It might seem that Alice can
send over to Bob the capability that Alice had, but
then of course that would be the capability that was
labeled as Alice's responsibility.

To me it seems that we are inevitably forced to separate
what amount to the capability as data from the permission
to communicate - to achieve our goal of eliminating the
use of Carol's beCarol (unsealer, private key) from the
communication from A to B.  I guess that in the context
of an E implementation like Horton this will be awkward.

I find this situation (forced separation of the communication
permission from the capability as data) particularly interesting
because I have to admit to having one foot in each of the
worlds - capabilities as descriptors (from my work on the
RATS operating system) and capabilities as data (from my
work on the NLTSS operating system).  I'm very sympathetic
to the value of the binding of the permission to communicate
in terms of permitting effective management of confinement,
but I also feel that for networks (where I believe the
POLA concerns are most relevant) the capabilities as
data model is most 'natural' (though of course I understand
and appreciate serializations of capabilities as
descriptors such as my DCCS, Mach's network server,
and MarkM's vats).

In a capabilities as data implementation I don't believe
the issue of communicating the permission to communicate
arises and so you can proceed essentially as you have
outlined, though without the confinement value.

>On a side note, it occurs to me that Horton provides a nice way to
>better support implementing groups -- when a user asks for a capability
>from a shared group keyring (as discussed the previous thread), it can
>use Horton or something similar to ensure that the entire group isn't
>blamed (and revoked) for the actions of a specific user.

I agree.  This is the idea that I was trying to get at when
I was referring to the "give and take" directory structure
that we had at LLNL for some 20 years (but without the sort
of Horton responsibility tracking).  With that system
any user could create a new directory out of whole cloth.
There was then a centrally managed directory structure
available that allowed any one user to "give" any capability
to any other user (through an insert only capability
to a directory that the user given to had full access to).

I could make a new "group" directory and then give it
to the others in the group that I wished to create.
If I wanted I could reduce the access of the directory I
gave out to read-only, with me keeping a read-write
instance.  In that case I could write into the directory
but others couldn't.

If my shared directory was read/write then everybody
in the 'group' had the same full access to it.

With the LLNL mechanism (which was very useful for many
years and definitely a real world example used by
thousands of scientists) as you say there was no
mechanism available to assign individual responsibility
for actions on the directory.  I believe a mechanism
like Horton would have been quite a useful addition
to that facility.

Thanks again for taking time for the careful reading Peter.
I hope MarkM has time to read and respond to your questions.
The implementation is fully MarkM's.  He has walked me
through both the version in the paper and the fuller
version with rights amplification.  I believe I
understand them and I've been able to make some minor
mods with my test code, but MarkM is certainly much more
facile with the implementations.

I hope we (I'm happy to be excluded - referring to
the community) are able to come up with reference
implementations that are based on simple cryptographic
transformations of capabilities as data that have the
basic responsibility (as private keys) transformation
property that you described in your goal statement
that Horton addresses.

If you have the time, you might find it helpful to
refer to MarkM's reference implementation in E of his
understanding of the Mailkey mechanism to solve
the Horton problem:

http://www.erights.org/elib/capability/horton/mailkeys.html

as it may be closer to something that can be used
effectively for the capabilities as data case.

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