[p2p-sip] P2PSIP, Kademlia and caching

[lowekamp at cs.wm.edu (Bruce Lowekamp)]

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
>
>
>