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

[<[e-mail]>]

Hi,

I agree with Cullen. Every device has an owner (an individual person or
an organization). A device typically do not behave maliciously. This is
the owner that may try to attack a system using the device. And even if
there are many admins, they typically belong to the same organization
(they represent the organization).

Can a peerID change? If the peerID is based on an IP address then the
peerID changes when the device moves from one subnet to another.

PeerID can also be designed so it includes location information.

Marcin

>-----Original Message-----
>From: ext Cullen Jennings [mailto:[e-mail]] 
>Sent: 19 March, 2007 00:57
>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