<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
FWIW, this is exactly how I do it - my architecture is hybrid, the only
non p2p resources are some secure database servers for a special class
of data and a CA. Every "registered" user gets any X.509 cert and has
to store their own private keys. Just make sure your root cert keys
are _really_ safe - if you want new users to be able to automatically
obtain certs, that implies network access to the CA. Make sure you
firewall well, scrub the incoming CSRs, and have some DDOS resistant
proxies in front of it (client puzzles work great for that aspect.)
Using an HSM instead of a normal server helps, but they're expensive...<br>
<br>
Another nice thing about certs is that you don't have to use SSL - if
you still want a UDP based protocol, just use the cert to sign your key
exchange, then use a stream cipher that can live w/ dropped packets.
I've got a simple protocol for this I need to turn into an RFC and
publish as open source, just too many other items in front of it at the
moment...<br>
<br>
Davide Carboni wrote:
<blockquote
cite="mid71b79fa90510250723w8048f26w8cb126bd4274a6da@mail.gmail.com"
type="cite">
<pre wrap="">On 10/25/05, Frank Moore <a class="moz-txt-link-rfc2396E" href="mailto:francis.moore@rawflow.com"><francis.moore@rawflow.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I have the following problem:
I'm working on a hybrid p2p network where there is a central server and
lots of clients (peers). I need a way for clients to authenticate
themselves when they join the network. I've looked at doing a challenge
response type thing using Challenge Handshake Authentication Protocol
(CHAP) but that means putting a shared secret key in each client and
the server.
It seems entirely possible that someone could reverse engineer the
client executable to get hold of the shared secret key and then write a
'rogue' client (or server) to subvert the network?
Is there a standard (or any) way of authenticating peers in p2p
networks that doesn't require secret shared keys?
</pre>
</blockquote>
<pre wrap=""><!---->
I have a similar problem. Currently I'm thinking to use socket over
SSL to establish a connection between peers. So my idea is:
(1) a unique certification authority CA for the community issues
certificates to participants who are entitled to join
(2) once p1 connects to p2, ssl authentication via certificate is
requested both for the 'client' and for the 'server'. If both
certificates are issued by CA the connection is up otherwise the
connection fails.
This way, there is no need to connect to a central DB and there are
not shared secrets but each node must keep secret its private key.
I'm just concerned about performances.
D.
--
I lose control 'cause I'm a creature of the night (Bruce and Bongo)
--
<a class="moz-txt-link-freetext" href="http://people.crs4.it/dcarboni">http://people.crs4.it/dcarboni</a>
_______________________________________________
p2p-hackers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:p2p-hackers@zgp.org">p2p-hackers@zgp.org</a>
<a class="moz-txt-link-freetext" href="http://zgp.org/mailman/listinfo/p2p-hackers">http://zgp.org/mailman/listinfo/p2p-hackers</a>
_______________________________________________
Here is a web page listing P2P Conferences:
<a class="moz-txt-link-freetext" href="http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences">http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences</a>
</pre>
</blockquote>
<br>
</body>
</html>