Subject: [P2PSIP] P2PSIP security requirements

From: <[email-masked]>
Date: Mon, 26 Nov 2007 12:16:42 +0200

Hi all,

We submitted a new version of the security requirements draft:
http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-re
quirements-02.txt. We improved the security threats section and modified
requirements according to your comments. 

This document presents a basic set of security requirements that we
believe that each of the proposals needs to address:

P2PSIP system requirements related to security issues are summarized
   below:

   Req. 1: Dependence of reachability of a centralized server SHOULD be
   minimized.

   Req. 2: P2PSIP security SHOULD scale from a small ad-hoc network to a
   network with hundred millions of network nodes and users.

   Req. 3: Existing security mechanisms SHOULD be used as much as
   possible to protect P2PSIP functions, and avoid the need for
   standardizing new mechanisms.

   Req. 4: Security requirements on the base P2P algorithm (e.g., DHT
   implementations) used in P2PSIP SHOULD be minimized and SHOULD NOT
   limit its scalability.

   Req. 5: The registered identities in a P2PSIP overlay MUST be
   preserved.  The attacker MUST NOT be able to steal identity from
   another user.

   Req. 6: The enrollment process MUST make it difficult for an attacker
   to register many identities in a P2PSIP overlay and easily modify the
   registered identities.

   Req. 7: It MUST be difficult to select a particular peer ID e.g. peer
   ID assignment process should introduce some degree of randomness to
   peer identities.

   Req. 8: It MUST be possible to authenticate users and P2PSIP network
   entities.

   Req. 9: It MUST NOT be possible to repeat or delay valid data
   transmission during enrollment and modification of P2PSIP resource
   (user) records.

   Req. 10: The P2PSIP security MUST support integrity protection of the
   data being inserted or retrieved to/from an overlay.

   Req. 11: The P2PSIP network entities MUST be provided with an option
   to encrypt data exchanged with other P2PSIP network entities.

   Req. 12: Only authorized users and P2PSIP network entities MUST be
   able to join the P2PSIP system and insert, modify, delete or
   overwrite P2PSIP resource (user) records in the P2PSIP system.

   Req. 13: In the situations where many users or P2PSIP network
   entities register the same resource in the P2PSIP overlay, each
   entity MUST have rights only to its own part of a resource record.

   Req. 14: An owner of P2PSIP resource (user) record MAY indicate which
   users or network entities can retrieve, modify, and delete data
   stored in their P2PSIP resource (user) records.

   Req. 15: P2PSIP overlay protocols MUST be designed such a way so that
   the effect of DOS attacks on the P2PSIP overlay is minimized.

   Req. 16: It SHOULD be possible to limit the impact of badly behaving
   P2PSIP nodes on the overall system security.  There SHOULD be an
   option to identify malfunctioning or badly behaving nodes, and
   exclude or reject them from the P2PSIP system.

We would appreciate your comments!

Marcin  

>A new version of I-D, 
>draft-matuszewski-p2psip-security-requirements-02.txt has been 
>successfuly submitted by Marcin Matuszewski and posted to the 
>IETF repository.
>
>Filename:	 draft-matuszewski-p2psip-security-requirements
>Revision:	 02
>Title:		 Security requirements in P2PSIP
>Creation_date:	 2007-11-19
>WG ID:		 Independent Submission
>Number_of_pages: 23
>
>Abstract:
>This document presents main security requirements for the 
>Peer-to- Peer SIP (P2PSIP) architecture and its components.  
>This document also analyses security threats in P2PSIP.  
>Typical security ontology is used as classification for the threats.
>                                                               
>                   
>
>
>The IETF Secretariat.
>
>
>

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

---

From: Zheng Hewen <[email-masked]>
Date: Tue, 27 Nov 2007 10:32:38 +0800

Hi,

   Here are some cents after a quick look.
   (1).In Section 2.3, "Enrolment protocol" appears, is it a distinctly different protocol from peer/client protocol? Would
you give an example?
   (2).Do you think that resource records pollution is a security threat to P2PSIP overlay?  For example, some malicious
node may publish fake resource records; it will cause some negative impaction;
   (3).For "Req.7: It MUST be difficult to select a particular peer ID e.g. peer ID assignment process should introduce some
degree of randomness to peer identities", Should "e.g." be "i.e."?
   (4)."Req. 9: It MUST NOT be possible to repeat or delay valid data transmission during enrollment and modification of
P2PSIP resource (user) records". I did not understand it, why do we need it?
   (5).Req.16 says "It SHOULD be possible to limit the impact of badly behaving P2PSIP nodes on the overall system security.
There SHOULD be an option to identify malfunctioning or badly behaving nodes, and exclude or reject them from the P2PSIP
system", in my understanding, we can reject suspicious nodes through Enrollment process or some mechanism like blacklisting,
how to exclude those nodes? Explicit exclusion routing method like RSVP-TE EXO?
   Another personal opinion, for P2PSIP overlay, extra security requirements are mandatory in some scenarios such as in an
unknown Internet environment, but they are optional in some scenarios such as in an autonomous enterprise private network,
do you think so? Certainly, those requirements listed in the I-D are basic and necessary for untrusty network.
   Any comment please.

Best regards,
Hewen

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: 2007?11?26? 18:17
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [P2PSIP] P2PSIP security requirements
>
>
> Hi all,
>
> quirements-02.txt. We improved the security threats section
> and modified requirements according to your comments.
>
> This document presents a basic set of security requirements
> that we believe that each of the proposals needs to address:
>
> >successfuly submitted by Marcin Matuszewski and posted to the IETF
> >repository.
> >

---

From: <[email-masked]>
Date: Thu, 29 Nov 2007 11:15:56 +0200

Hi Hewen,

Thanks for your comments. Answers inline...
 
>From: ext Zheng Hewen [mailto:[email-masked]] 
>Sent: 27 November, 2007 04:33
>To: Matuszewski Marcin (Nokia-NRC/Helsinki); [email-masked]
>Cc: Ekberg Jan-Erik (Nokia-NRC/Helsinki); Laitinen Pekka 
>(Nokia-NRC/Helsinki)
>Subject: RE: [P2PSIP] P2PSIP security requirements
>
>Hi,
>
>   (1).In Section 2.3, "Enrolment protocol" appears, is it a 
>distinctly different protocol from peer/client protocol? Would 
>you give an example?

There are some alternatives. In my opinion the best option is PKCS#10
with HTTP Digest on top of TLS.  

>   (2).Do you think that resource records pollution is a 
>security threat to P2PSIP overlay?  For example, some 
>malicious node may publish fake resource records; it will 
>cause some negative impaction;

Yes this is a security threat. It can be mitigated using authentication
mechanisms, however the access control and authentication mechanisms may
not work if peers that are responsible for storing resource (user)
records do not act according to the overlay policies.

>   (3).For "Req.7: It MUST be difficult to select a particular 
>peer ID e.g. peer ID assignment process should introduce some 

Thanks for noticing it. I will correct it.

>   (4)."Req. 9: It MUST NOT be possible to repeat or delay 
>valid data transmission during enrollment and modification of 

This requirement is mostly about replay attacks. An example of the
replay attack: a badly behaving node take an older request sent by
another node, resend it to the overlay, and thus replace any newer data
with the old information.   

>   (5).Req.16 says "It SHOULD be possible to limit the impact 
>of badly behaving P2PSIP nodes on the overall system security.
>There SHOULD be an option to identify malfunctioning or badly 
>behaving nodes, and exclude or reject them from the P2PSIP 
>system", in my understanding, we can reject suspicious nodes 
>through Enrollment process or some mechanism like 
>blacklisting, how to exclude those nodes? Explicit exclusion 
>routing method like RSVP-TE EXO?

The enrolment process cannot fully protect against malicious nodes
joining an overlay network. For example in an enterprise domain your
peer is admitted to the network because you are an employee of the
organization. This does not guarantee that you will not try to attack
the system.
There are mechanisms to identify malfunctioning or badly behaving nodes
and reject them from the network.  

>   Another personal opinion, for P2PSIP overlay, extra 
>security requirements are mandatory in some scenarios such as 
>in an unknown Internet environment, but they are optional in 
>some scenarios such as in an autonomous enterprise private 
>network, do you think so? 

This is a good question. We were discussing this issue. 
Our current thinking is that we are going to standardize only one
protocol that will work in different scenarios. It is true that some of
the protocol functions will not be used in all of the scenarios.

Certainly, those requirements listed 
>in the I-D are basic and necessary for untrusty network.
>   Any comment please.
>
>Best regards,
>Hewen
>
>> quirements-02.txt. We improved the security threats section and 
>> modified requirements according to your comments.
>>
>>    Req. 2: P2PSIP security SHOULD scale from a small ad-hoc 
>network to 
>> a