[p2p-sip] P2PSIP, Kademlia and caching

[slavitch at gmail.com (Michael Slavitch)]

It does exactly that.  It replaces certs with humans, which are more
trustworthy.

If P2P can also mean H2H (Human to Human) there is nothing stopping this
approach from being valid.

We have to step back sometimes and remember that humans are part of the
equation,  we underestimate ourselves.

M

On 5/25/06, Alan Johnston <alan at sipstation.com> wrote:
>
> 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
> >
> >
> >
> >
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>



-- 
Michael Slavitch
Ottawa, Ontario Canada

"Yet another P2PSIP Henchman"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060525/62e78ea3/attachment-0001.html