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

[Cullen Jennings <[e-mail]>]

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