Subject: [Sipping] New version of P2P SIP draft-bryan-sipping-p2p

From: "David A. Bryan" <[email-masked]>
Date: Mon, 18 Jul 2005 11:58:24 -0700

Cullen Jennings and I have iterated our draft on P2P registration and
resource location in SIP.  Until it is available in the archive, you
can take a look at www.p2psip.org for the latest version.

Thanks,

David Bryan

-- 
David Bryan
Please continue to send me email at the address [email-masked]

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 19 Jul 2005 15:54:03 -0500

The I-D <draft-bryan-sipping-p2p>
http://www.p2psip.org/draft-bryan-sipping-p2p-01.html is an excellent
addition to the topic of P2P SIP. 

If the IETF is going to make P2P SIP a work item, the alternate
architectural options using Chord supernodes and hybrid systems as discussed
in http://www1.cs.columbia.edu/~kns10/publication/sip-p2p-short.pdf as well
as other need to be discussed as well. See for example
http://www.softarmor.com/wgdb/docs/draft-johnston-sipping-p2p-ipcom-00.html 

A 'beer BOF' on P2P SIP is being organized by Henning Schulzrinne at the 63
IETF. Is it not time to have P2P SIP as a work item of SIPPING? 

I will propose in a companion message to
http://kevlar.softarmor.com/sipping/meets/ietf63/requests.html  a 5 minute
time slot on the SIPPING WG agenda to take a vote on this.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David A. Bryan
Sent: Monday, July 18, 2005 1:58 PM
To: [email-masked]; [email-masked]
Cc: Cullen Jennings
Subject: [Sipping] New version of P2P SIP draft-bryan-sipping-p2p

Thanks,

David Bryan

---

From: Stefan Sayer <[email-masked]>
Date: Wed, 20 Jul 2005 13:15:09 +0200

Hello,

in draft-bryan-sipping-p2p section 9.2.1 Certificate Based Protection 
you propose to exchange the certificate on the first contact, verify the 
certificates finger print by some out-of-band mechanism and warn the 
user if a certificate changes.

The problem I see here is that the user will often not have the means to 
  verify the certificates' fingerprint out of band, so a man in the 
middle attack by the node that is responsible for a user's location is 
possible.

I wonder whether this could be overcome by making up a distributed PKI, 
which would basically work the following way:
If a user signs up with the system, the public part of the certificate 
is stored in the DHT as another resource with a resource-ID made up from 
the user name but with a magic number added, so for example the public 
key of a user "sanchi" would be stored at "sanchi+<key_magic>". This way 
a different node is responsible for the users certificate than for the 
user location. By replicating the key to more than one resource-ID (e.g. 
  "sanchi+<key_magic2>", "sanchi+<key_magic3>" ...) this could be made 
more secure, a user that wants to know another users key would request 
all keys and try the one that is returned most often.

Now there is still one problem to be solved: A node responsible for the 
location of a user could try to publish a fake public key for that user, 
and giving out a fake location it could then pretend to be that user. A 
possible solution would be to protect registration of a key by a 
password, and challenge every attempt to register a key. This 
authentication would be done by the node that is responsible for the 
user name concatenated with another magic, e.g. 
"sanchi+<key_auth_magic>". The sign-up process would then have two 
steps: first sign up a public key for a name, then sign up the name itself.

I wonder whether I have overlooked something in this scheme and whether 
it would be feasible without adding too much overhead traffic and delay 
to call setup.

Stefan Sayer