[cap-talk] network level designation and authorization

[coderman]

On 6/8/06, Stiegler, Marc D <marc.d.stiegler at hp.com> wrote:
> ...
> What existing infrastructure do you think this leverages? It certainly
> doesn't leverage any existing VPN technology. You're proposing inventing
> yet another wheel, when captp and YURLs already exist -- those are the
> wheels to reuse rather than reinvent :-)

specifically openvpn, openssh 4.2+ and ipsec as far as VPN tech goes
(PPTP to a lesser degree, mainly to pull windows behind a trusted
endpoint rather than peer with windows directly).  i also meant to
imply existing services or new developments which need only speak
TCP/IP (or even UDP) without having to pull in authentication and
privacy libraries/protocols to speak a particular form of secure
distributed capability impl. (or speaking VatTP in another language
would be simpler, since auth/privacy need not also be implemented)

i'll continue to dig into CapTP and httpsy implementations as i am
woefully under informed on the technical details of their
implementation.  it may be that they are a more appropriate and
lighter wrapper around existing SSL/TLS infrastructure (with self
signed certs or key centric peer to peer identities instead of
PKI/X.509) and i will discover this with use.


> So, Bob has a vpn connection to Alice through which he has access only
> to file1, i.e., he has authority to use Alice.file1. He also has a vpn
> connection to Carol through which he has access only to carol's file
> processing serviceA. He wishes to process Alice.file1 with
> Carol.serviceA. With captp, he hands the Alice.file1 reference to
> Carol.serviceA, they do the Granovetter introduction so that
> Carol.serviceA has a direct connection to Alice.file1, and performs the
> file processing. Smooth. All built into the protocol.

yes; if there is no direct route between Carol and Alice (but a
transitive introduction could provide one) then Bob must proxy.  to
some extent a proxy may be desired (that is, if you want revocability,
you want to be the proxy capable of revoking if desired).

i need to study more of the transitive introduction inherent in CapTP
before i can provide an intelligent reply.


> With vpns, first you must allow multiple vpns to run simultaneously on
> Bob's machine (which is a seriously hostile feature for vpns, you should
> come up with a different name for whatever it is you are visualizing).

agreed, still trying to find a good name.  until then i'll temporarily
call it a private virtual crossover (PVC)? to emphasize the direct
peer to peer transport between IP endpoints rather than a VPN style
perimeter defense.


> With these mini-vpns, Bob must either forward all messages back and
> forth (a problem since file1 is a big file, lots of bits moving in the
> triangle), or Bob must have additional authorities with Carol and Alice
> to create a new vpn connection between Carol and Alice.

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


> With granovetter protocols, programming over the net feels a lot like OO
> programming on a single machine. Much much easier.

this is true, although i think it has more to do with the abstractions
and patterns of cooperation on top of the communication privacy than
the way in which is implemented under the hood.  perhaps i'll see the
critical distinctions which make CapTP much easier and well integrated
as i dig into it further;  right now it seems that the VatTP and other
protocols could rely on PVC security and function as expected.

thanks again for taking the time to respond.