Scalable Distributed Security with Bearer Certificates

Frank O'Dwyer fod@brd.ie
Wed, 10 Feb 1999 23:23:07 +0000


"Mark S. Miller" wrote:
> At 08:39 AM 2/10/99 , Frank O'Dwyer wrote:
> >... To begin with this will only provide
> >datagram communication (although the underlying comms will be TCP),
> >... However a stream protocol could in principle be built atop this.
> 
> E requires such a stream protocol.  Post handshake, we run an SSL-like
> secure data pipe on top of it.  See "Pluribus Protocol: Data Comm Layer" at
> http://www.erights.org/elib/index.html

Well, so long as a connection can be successfully established and
maintained, and no one on the path is a disruptor, the basic stream
characteristics are there, since the underlying comms would be TCP. In
my case the datagram characteristics arise from the fact that
participants can go on and offline, and also a node on the path might be
hostile and simply drop packets on the floor. AFAIK there is also a need
to transmit fixed size packets at a fixed rate in order to make a strong
mix, which could lead to inefficiencies for a stream. Having said that I
think it would be fairly straightforward to provide a stream interface,
albeit one that may require multiple connection attempts (if hostile
participants are a concern), and where disconnects are more common (if
partipants can crash or go offline, or if participants try to disrupt
connections).

[...]
> The essential step of capability computation, and therefore the central
> problem for a secure protocol for E to solve, is the three party handoff,
> explained in http://www.erights.org/elib/elibmanual.pdf
> 
> In order for your mix to appear to be a compatible socket library, I take
> it that Alice would know Bob and Carol by what appear to Alice to be Bob
> and Carol's TCP/IP addresses?  In you system, how would Alice introduce Bob
> to Carol?  If Alice tells Bob the alleged TCP/IP address by which Alice
> knows Carol, can Bob contact Carol by using this address?  Don't worry
> about authenticating that it actually is Carol once the contact is made --
> we got that one covered.  I'm concerned about routing.

I am looking at Wei Dai's PipeNet, MixMaster, NRLs Onion Routing, etc,
for
ideas. These systems give sender anonymity pretty readily, but the
receiver is not anonymous. This means if you initiate a connection, you
know the (real) destination IP address, but the sender IP address is
obscured. With this basis, Alice could only introduce Bob to Carol by
forwarding messages for them, or if either Bob or Carol did not mind
revealing their real IP. This semi-anonymity is probably as much as the
socket replacement would provide, at least initially, but it's a good
building block.

Obscuring both ends of a connection is possible but more complex. I
think this would require two parties to initiate a connection to a 3rd
party, and splice those connections together. I don't think a
transparent socket interface to that would be easy, but something like
sockets but requiring a few extra method calls might be possible. It
might be easier in your case to have well-known (or discovered?) proxy
objects which existed to provide the rendezvous point and the forwarding
functionality, using half-anonymous connections as a basis. The 3rd
party would be in a position to inspect content, though, so if that's a
problem another layer of encryption is needed, and some higher level
means of authenticating the endpoints.

> If, pre-introduction, none of the three parties could determine the
> location of the other two, would this still be true post-introduction?  

In the half-anonymous case, initiators would need to know the location
of responders--so depending on how your introduction is done, somebody
needs to reveal their location. In the fully anonymous case, the
location of the 3rd party needs to be known, but the other partipants
locations remain hidden.

[...]
> And what if Firewalls are in the
> way?  (E doesn't yet route through Firewalls, but see
> http://www.erights.org/to-be-sorted/DataCommThruFirewalls.html for a plan
> to handle the bad cases.)

>From a firewall's perspective this is just TCP, so you could either
proxy it, or tunnel it through HTTP.

> Is your open source license compatible with Mozilla?  Most are, including
> LGPL, but GPL is not.

Yes, BSD-style.

> If it works out, it would be truly superbly wonderful to have a working mix
> underneath Pluribus.

Yes, it would be interesting from my angle too. I think I could use E
for my project if it hid location.

Cheers,
Frank O'Dwyer.