[p2p-sip] P2PSIP, Kademlia and caching

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

Alan,

Oh, I absolutely didn't mean to imply it wouldn't be useful.  I think
it's very useful.  Key continuity is clearly useful, and the
voice-based SAS may well be the best option available for (voice) p2p
sip.  I was only observing that there are limitations to this approach
in terms of establishing initial identity and in terms of non-voice or
automatic systems that a CA system doesn't have.  (I'm basing this on
my reading of Zimmerman's FAQ and a quick read through the draft.)  I
think this is another example of it being useful to support different
authentication systems for p2p sip because different environments will
have different needs.

Bruce



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