[p2p-sip] P2PSIP, Kademlia and caching

[alan at sipstation.com (Alan Johnston)]

Bruce,

I think Henry's point was that ZRTP provides confidentiality and 
authentication services without certificates or a PKI. 

In simple terms, it uses key continuity similar to (but not the same as) 
SSH across subsequent media sessions between two endpoints.

This type of architecture could be a useful for P2P SIP.

Thanks,
Alan

Bruce Lowekamp wrote:

>Henry,
>
>I haven't looked at ZRTP much, but doesn't he explicitly say he
>doesn't do this in the last FAQ at
>http://www.philzimmermann.com/EN/zfone/index-faq.html
>?
>
>I'm not entirely sure I agree with this argument, BTW.  I mean, he's
>right about the current PSTN security model, but I really think that a
>system that supports instant messaging needs a bit
>more---impersonation is much easier there.
>
>Bruce
>
>
>On 5/25/06, Henry Sinnreich <henry at pulver.com> wrote:
>  
>
>>>have some way of verifying the key when you first acquire it.
>>>      
>>>
>>Yes, this is exactly what ZRTP and the Zfone are doing.
>>
>>http://www.philzimmermann.com/EN/zfone/index.html
>>
>>Thanks, Henry
>>
>>-----Original Message-----
>>From: p2p-sip-bounces at cs.columbia.edu
>>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Bruce Lowekamp
>>Sent: Thursday, May 25, 2006 10:43 AM
>>To: Stefan Sayer
>>Cc: p2p-sip at cs.columbia.edu
>>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching
>>
>>I think one of the lessons from working on the use-cases draft is that
>>there are a wide range of scenarios with differing levels of trust and
>>authorities that make good scenarios for p2psip.  What exactly we'll
>>attempt to standardize will come out of the WG charter and
>>requirements drafts.
>>
>>Personally, I'm a big fan of having a protocol that supports several
>>identity authentication options, since I don't think there will be a
>>single one-size-fits-all solution for the different use-cases.  The
>>scenario you propose is easily solvable if you allow for the existence
>>of loosely-connected CAs and use the DHT to store certificates.  I
>>think there are ideas for how to do it in a more distributed manner,
>>but I don't know that they are at the level of something we could
>>write a standard for, whereas certificate chains are well-understood.
>>
>>There are other variations, though---if you don't have CAs, then
>>everyone can generate and publish their own public keys.  I couldn't
>>prevent someone else from claiming to be lowekamp at cs.wm.edu, but they
>>couldn't fake signing my messages with my key (they could confuse the
>>situation because there would be multiple lowekamp at cs.wm.edu
>>identities with different keys).    What you have then is basically
>>the same as the current pgp keyserver system, which works as long as
>>you have some way of verifying the key when you first acquire it.
>>
>>Bruce
>>
>>
>>
>>
>>On 5/24/06, Stefan Sayer <sayer at cs.tu-berlin.de> wrote:
>>    
>>
>>>Hello,
>>>Bruce Lowekamp wrote:
>>>      
>>>
>>>>I don't think caching adds any complexities for authentication---if
>>>>you're working in an open P2P system you're probably assuming you have
>>>>an untrusted network to begin with and will be trying to validate any
>>>>registration, regardless of whether it's cached or not.
>>>>        
>>>>
>>>'validate' means for me in this context that the one who wants to
>>>register really is the one that has on sign-up reserved that name.
>>>
>>>What I don't understand: If every node is admitted to publish or
>>>update a record (which is true for a system that does caching), for
>>>example my location record, how can identity theft be prevented?
>>>
>>>* if every node is admitted to change a value associated to a key then
>>>anyone can steal the identity very easily
>>>
>>>* if every node is admitted to republish a <key,value> pair (be it at
>>>cache places or some original root of the key), regardless of whether
>>>it is the original publisher of the pair, then an attacker could still
>>>litter the overlay with corrupted values
>>>
>>>So I would see the requirement as follows:
>>>   The overlay MUST support binding a credential to a key, in order to
>>>   authenticate the original publisher of a <key,value> pair in update
>>>   and remove operations.
>>>
>>>On the API level, for example starting from the definition in
>>>draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials
>>>directly as parameter to the functions add, update, and remove:
>>>get(in overlay_id, in key, out records, out error)
>>>add(in overlay_id, in key, in record, in lifetime, in option,
>>>     in credential, out error)
>>>update(in overlay_id, in key, in record, in lifetime, in option,
>>>        in credential, out error)
>>>remove(in overlay_id, in key, in credential, out error)
>>>
>>>As much as I like Kademlia, as I understand it at the moment without
>>>modifications it does not support this. But I might very well have
>>>overlooked something.
>>>
>>>Regards
>>>Stefan
>>>
>>>      
>>>
>>>>Bruce
>>>>        
>>>>
>>>      
>>>
>>_______________________________________________
>>p2p-sip mailing list
>>p2p-sip at cs.columbia.edu
>>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>
>>
>>
>>    
>>
>
>_______________________________________________
>p2p-sip mailing list
>p2p-sip at cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>
>  
>