Re: [P2PSIP] Re: Comments on draft-jennings-p2psip-security-00

["Bruce Lowekamp" <[e-mail]>]

I definitely agree that you always want to be able to associate a
"real" identity with a peer, but there are still times when you don't
want to base the peerids on that one identity.  For example, if a
service provider is providing 5 peers to provision a network with,
those should probably be evenly distributed around the ID space,
whereas the multiple devices of a single regular user should be in one
spot in ID space to protect against certain attacks.

You can obviously accomplish the same thing with names like
[e-mail] so whether the problem is solved with separate
peer certificates or through synthentic email addresses isn't that
important, but peer id certificates (that still have to reference
[e-mail]) strike me as a bit less of a hack.

Bruce

On 3/18/07, Turner, Jim (NBC Universal) <[e-mail]> wrote:
>
> I would be interested to know a scenario where a device isn't operating as a "proxy"
> for a real user? In my experience, even set-top boxes are associated with "customers".
>
> It's easy to think of a device as being "detached", but in practice, if the device is
> attempting to access a "service", it is usually associated with some user "entity".
>
> Jim
>
>
>
> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]]
> Sent: Sun 3/18/2007 6:56 PM
> To: David Bryan
> Cc: Philip Matthews; P2PSIP Mailing List
> Subject: Re: [P2PSIP] Re: Comments on draft-jennings-p2psip-security-00
>
>
> I think one of the key consideration here has to do with what you are
> using the peer certificate for. In the end it has to do with
> assigning some trust and traceability about the operator of the
> device. A device ID is sort of lousy for this - what you actually
> want to know is something more about the user that is operating the
> device. Think about, what do you think might end up being more
> useful, "the MAC address of the machine that is hijacking your calls
> is 123456" or "the operator of the machine that is hijacking your
> calls is [e-mail]". What I am suggesting here is that all
> peer software is operated and run by some users. And that user has to
> has to be enrolled on the DHT and the uses that users credentials for
> describing what user that devices is operating the device. I
> understand that you could have a device with no users, but why? It
> greatly complicates making assertion about the device if you have to
> be able to do that independent of any user. Even a bootstrap node is
> run by some user.
>
> Let me flip the questions around, what security feature can you
> provide by having two types of certificates?
>
> Cullen <with my individual hat on>
>
>
>
> On Mar 18, 2007, at 7:57 PM, David A. Bryan wrote:
>
> > Forgot to reply this...also possibly the wrong thread for this, should
> > maybe have posted in the other thread about certificates.
> >
> > There may be cases where we need a separate peerID in the sense that
> > the device has no associated user. I'm thinking things like gateways,
> > or even a bootstrap if you have a persistent box somewhere to help you
> > bootstrap on.
> >
> > May only be corner cases, however. Maybe a user "bootstrap" or
> > something...
> >
> > David
> >
> > On 3/9/07, Cullen Jennings <[e-mail]> wrote:
> > >
> > > On Mar 8, 2007, at 4:37 PM, Philip Matthews wrote:
> > >
> > > > Hi Cullen:
> > > >
> > > > I read your draft on security draft-jennings-p2psip-security-00.
> > > > and thought it had some interesting ideas.
> > > > Here are some comments and questions that I have.
> > > > I have adopted Spencer's style of mixing paragraphs from the
> > document
> > > > with embedded comments prefixed by "Philip:"
> > > >
> > > > - Philip
> > > >
> > > > ------------
> > > > [snip]
> > > >    When a client wants to store some information in a record, they
> > > > sent
> > > >    a request that has:  their AOR, the record type name, the
> > time, the
> > > >    data to store in the record, and MUST include a signature
> > over all
> > > >    that information.  When a peer goes to store the
> > information, it
> > > > MUST
> > > >
> > > > Philip: When you say "client" and "peer", are you using these
> > terms as
> > > > defined in the P2PSIP Concepts document? My guess is that you
> > > > are using the word "client" in the SIP meaning, not in the P2PSIP
> > > > meaning.
> > >
> > > I was trying to stay consistent with the Concepts document but I'm
> > > sure I messed up in places. Any help fixing up my terminology would
> > > be much appreciated.
> > >
> > > >
> > > >    check that the signature is correct.  It SHOULD also check
> > that the
> > > >    data looks appropriate for this type of record given by
> > checking
> > > >    things like the size of the data is in an appropriate range.
> > > > When a
> > > >    client retrieves data out of the DHT, it retrieves all the
> > > >    information that was signed and SHOULD verify the signature
> > on the
> > > >    data.
> > > >
> > > > Philip: This seems similar to the proposal in draft-singh-p2p-
> > sip-01.
> > > > Can you comment on this?
> > > Uh, no comment :-) seriously - I have not read latest version of
> > > singh yet but I will read it  before the meeting - I'm not at all
> > > surprised that they would have same thing - we talked about this at
> > > some of the prior meetings
> > >
> > > >
> > > >    Open Issue:  how do we want to deal with checking time and also
> > > > does
> > > >    the data have a Time To Live (TTL).
> > > >
> > > >    Open Issue:  do we pass the certificate with the signature
> > or do we
> > > >    provide some alternative scheme to get the certificates.  I am
> > > >    leaning towards pass the certificate along with the
> > signature.  A
> > > >    problem with this is the message size.  A possible problem
> > with not
> > > >
> > > > Philip: Are your worried about size in sending the message or in
> > > > storing
> > > > the data?  That is, if we used for example TCP transport (i.e.,
> > not
> > > > UDP),
> > > > then would your concerns go away?
> > >
> > > Well there are many ways we could skin this cat - in the end I
> > > suspect that the what works best for NAT traversal will be the
> > > dominating factor for choosing the design.
> > >
> > > >
> > > >    doing it is that the signature are used to verify the
> > constructions
> > > >    of the routing architecture and assuming that the routing
> > > >    architecture is in place before a signature can be checked
> > may lead
> > > >    to problems.
> > > >
> > > >
> > > > 4.  Routing Protection Architecture
> > > >
> > > >    The goal of protecting the routing is stopping attacker from
> > > >    performing a DOS attack on they system by misrouting
> > requests in
> > > > the
> > > >    DHT.  The data is already protected by the data protection
> > scheme
> > > >    above so an attacker can't tamper with the data in a way the
> > user
> > > >    can't detect but an attacker can make it look like no data is
> > > >    available.  There are a few obvious observation to make
> > about this.
> > > >    First, it is easy to ensure that attacker at least has to
> > have an
> > > >    valid enrollment with this particular DHT.  Second, this is
> > a DOS
> > > >    attack and the value of successfully executing it is fairly
> > low.
> > > >    Third, if a larger percentage of the peers on the DHT are
> > > > controlled
> > > >    by the attacker, it is probably impossible to perfectly secure
> > > > this.
> > > >
> > > >    When a peer sends a request that modifies the routing in the
> > > > DHT, it
> > > >    MUST sign the request on behalf of a user that is currently
> > > >    responsible for the peer using that users certificate.  A
> > peer that
> > > >    is changing the routing state based on this request to check
> > the
> > > >    signature before performing the request.
> > > >
> > > > Philip: There are a number of things I don't understand here.
> > > yah - it is poorly written
> > >
> > > > Can you give some examples of what you mean by
> > > > "a request that modified the routing"?  For example, do you mean
> > > > "setting up a new Peer Protocol connection"?
> > > I mean a peer protocol messages that changes the finger table (or
> > > whatever that's DHTs equivalent is for the things the DHT uses to
> > > decide how to route requests and DHT update messages)
> > >
> > > > And how does signing such requests help prevent DOS attacks?
> > > > I can see how it might help us catch the peer that did the attack,
> > > > but this is very much after the fact.
> > > I think the after the fact sill has significant value - particularly
> > > if you have a way of slowly revoking the account. You can also do
> > > things where nodes can detect one user trying to be many things at
> > > once when it actually should only be one things and this makes it
> > > harder to hijack large portions of the DHT search space.
> > >
> > > > Finally, why sign this with a user's certificate? Why not sign
> > this
> > > > with the certificate of the peer? (As documented in Concepts-04,
> > > > we have already agreed that peers must have certificates to
> > > > join the overlay.)
> > >
> > > Uh agree and disagree here. I have not heard anyone explain why we
> > > need both peer and users certificates so I am assuming that where
> > you
> > > need a peer certificate, you just use the user certificate for some
> > > users that is authorizing the peer to use it. The problem with peer
> > > certificates has to do do with what their names are.  If we don't
> > > need to introduce a whole new security namespace for peers, it is
> > > easier to just have users certificates.
> > >
> > > >
> > > >
> > > >    To reduce attacks on routing, the design tries to limit the
> > ability
> > > >    of an attacker to place peers at arbitrary locations in the
> > DHT.
> > > >    Some possible ways to do this are:
> > > >
> > > >    L1:  Limiting IP addresses:  Other systems have done this by
> > > > forcing
> > > >         the peer id to be a hash of a combination of the peers
> > IP and
> > > >         port however this approach does not work with IPv6
> > where the
> > > >         users have an arbitrary number of IP addresses and the
> > > > scheme is
> > > >         also difficult to make work with IPv4 and NATs.
> > > >    L2:  Limiting by AOR:  The first step to doing this is
> > limiting the
> > > >         number of AORs an attacker can enroll in the system.  How
> > > > to do
> > > >         this is out of scope.  The next step would be forcing a
> > > > peer ID
> > > >         to have the high order bits formed from an hash of the
> > AOR and
> > > >         some low order bits chosen randomly or hashed from the IP
> > > >         address and port.  Peers would check the Peer ID was
> > > > appropriate
> > > >         for the given users that signed the request.
> > > >
> > > > Philip: What do you see as the AOR of a peer?
> > > I have no idea which is exactly one of the reason I would rather not
> > > have peer certificates if we don't need them.
> > >
> > > > Are you thinking of
> > > > the scheme you, Bruce, and David are using in the dSIP draft?
> > > no - I don't see that as consistent with this draft (it could easily
> > > be changed to be consistent with this but I don't think it is yet).
> > >
> > > > If so, I don't quite see how this would work.
> > > (uh, yah, I don't see how having the peers have AOR will work
> > either :-)
> > >
> > > > It seems that your peer-id
> > > > would depend on itself.
> > > > [For other readers of this message, those URIs look like:
> > > >           peer@<hostport>; peer-id=<peerid>
> > > > where <hostport> is an IP address and port and <peerid> is a
> > peer-id].
> > > > Moreover, the other unique part is the <hostport>, so this falls
> > > > back to
> > > > option L1.
> > > >
> > > >    L3:  Limited by assignment at enrollment:  When enrolling,
> > the user
> > > >         would be given a small set of peer IDs for their use.
> > This is
> > > >         effectively equivalent to Limited by AOR but has the
> > addition
> > > >         complexity of the certificates become more complex as a
> > peer
> > > >         would need to sign with the appropriate peer id as well
> > as the
> > > >         AOR.
> > > >
> > > >
> > > >
> > > > 5.  Mapping to SIP
> > > >
> > > >    There are several ways this could be mapped to SIP.
> > > >
> > > > Philip: Is this section making the assumption that the Peer
> > Protocol
> > > > is SIP? Otherwise, I don't understand what this has to do with
> > SIP.
> > >
> > > I should have made this clearer - the whole document before this
> > > section apples to any peer protocol. This section only applies if
> > the
> > > peer protocol is SIP.
> > >
> > > _______________________________________________
> > > P2PSIP mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/p2psip
> > >
> >
> >
> > --
> > David A. Bryan
> > [e-mail]
> > +1.757.565.0101 x101
> > +1.757.565.0088 (fax)
> > www.SIPeerior.com
> >
>
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
>

_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip