[cap-talk] horton questions

[Peter Amstutz]

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.

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.

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

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.

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.

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

 * If Bob and Carol reside on different hosts, Bob may need to ask Alice 
how to contact Carol to establish a direct connection.  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.

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

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.

 * Someone mentioned the desire to avoid requiring a communication 
between Alice and Carol.  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).

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.

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20070608/81522fa1/attachment.bin