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

["David A. Bryan" <[e-mail]>]

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