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

[Cullen Jennings <[e-mail]>]

Ah, I see what how you are thinking about this. I think I now  
understand why you and I had come up with different views on this.  
This basically depends on how you allocate peer ids and user id. If  
peer id are centrally allocated, then I see why you would have a peer  
certificate this but if they are locally generated then you would  
probably not want a peer certificate.

Cullen <with my individual hat on>


On Mar 19, 2007, at 7:51 AM, Bruce Lowekamp wrote:

> 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