saikat at cs.cornell.edu
Sun Jun 25 18:37:18 UTC 2006
On Thu, 2006-06-22 at 04:13 +0530, K.S.Sreeram wrote:
> I'm working on a server-less secure communication platform, which
> provides a simple primitive.... 'connect(user,service)'
> where users are identified by their RSA public keys.
Interesting. We have been looking at similar enhancements to IP
addressing, though more at the broader problem of connection
establishment, not just naming.
In particular, yes, ip:port is inadequate; and "user":"service" is more
stable an identifier over the long-term. But also, that the old notion
of being able to _unilaterally_ request to connect to someone (for
example by sending a TCP SYN out of the blue) is:
a) no longer possible because of NAT/firewalls
b) no longer desired because the recipient may want to have a say in
who can use the service and who cannot before it spends computational
and network resources to service the connection.
So in addition to user:service naming, it is useful to have _mediated_
connection establishment. By mediated I mean having an off-path
signaling channel that endpoints can use to communicate specific bits of
information indirectly with each other under the vigilance of mediating
agents. Specific bits of information like public keys, ephemeral IP
address and ports, etc. See  for details.
 S. Guha and P. Francis. "Towards a Secure Internet Architecture
Through Signaling," Under submission. Apr 2005. [Available online:
> I'm also keen to know if there are any other existing/on-going projects
> which provide a similar server-less secure communication mechanism?
Our implementation is quite similar to yours in that we allow existing
applications to use user:service naming, and establish secure
connections. We, however, use user at domain as global identifiers, use SIP
as our signaling channel (which can either be distributed like DNS, or
can run on top of a DHT -- see P2PSIP), distribute keys over this
signaling channel, and support unmodified applications by hijacking
calls into the OS's socket functions. It is still work-in-progress (see
the implementation section in the paper above).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060625/df5ca11a/attachment.pgp
More information about the P2p-hackers