P2PSIP Working Group J. Zhu Internet Draft M. Qi Intended status: Informational China Mobile Expires: January 2010 July 12, 2009 P2PSIP Security Requirements draft-zhu-p2psip-securityrequirements-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Judy Expires January 12, 2010 [Page 1] Internet-Draft P2PSIP Security Requirements March 2009 Abstract This draft discusses the security requirements in Peer-to-Peer (P2P) SIP system. As the P2P SIP is distributed and each peer is equal in it, it should face the extra security threat from traditional system. This draft introduces these security threats at first. After that, the security requirements of P2P SIP system were brought up. Judy Expires January 12, 2010 [Page 2] Internet-Draft P2PSIP Security Requirements July 2009 Table of Contents 1. Introduction................................................4 2. Definition..................................................5 2.1. General................................................5 2.2. Network Entities.......................................5 2.3. Network Architecture...................................5 3. Security Scenarios..........................................7 3.1. VoIP...................................................7 4. Security Threats...........................................10 4.1. Weak Security Protection Caused by no trust...........10 4.2. Routing Modification..................................10 4.3. Malicious Code Spreading..............................11 5. Security Requirements......................................12 5.1. Trust Model...........................................12 5.2. Authentication Infrastructure.........................13 5.2.1. Centralized Authentication Infrastructure........13 5.2.2. Distributed Authentication Infrastructure........13 5.3. Protection against Malicious Code Spreading...........14 6. Security Considerations....................................16 7. IANA Considerations........................................17 8. Conclusions................................................18 9. References.................................................19 9.1. Normative References..................................19 Judy Expires January 12, 2010 [Page 3] Internet-Draft P2PSIP Security Requirements July 2009 1. Introduction This draft introduce the main security concerns and security requirements in Peer-to-Peer SIP architecture [1]. SIP will be used in a peer-to-peer environment with the network development. The traditional mechanism used in SIP should be replaced by distributed mechanism to fit for the P2P network system. As a result, P2P SIP architecture should face new security threats and new security requirements. The purpose of this draft is to list the security requirements and make references for the future security solution study. Judy Expires January 12, 2010 [Page 4] Internet-Draft P2PSIP Security Requirements July 2009 2. Definition To study the security of P2P SIP system, there must be a security model to describe the system. 2.1. General The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2. Network Entities The network entities are peers, clients or other functional nodes which are defined in reference [1]. There SHOULD be a special kind of functional nodes named enrollment server to perform authentication/enrollment service for others. 2.3. Network Architecture The following feature shows a P2P SIP network architecture based on reference model from reference [1]. In this study, three kinds of nodes mentioned above are to be considered. The peer node is basic node which constructs the body of network. A peer can connect to several nodes no matter what kind of these nodes are. A client will be connected directly to peer except enrollment server which can act as a normal peer. The enrollment server will be connected with several peers. Judy Expires January 9, 2010 [Page 5] Internet-Draft P2PSIP Security Requirements July 2009 +------------------------------------------------+ | | | +-------+ +----------------+ | | |Client | V V | | +-------+ +----+ +----------+ | | ^ +------->|Peer|<--+ |Enrollment| | | | | +----+ | | Server | | | | | ^ | +----------+ | | | | | | | | | | | | | | | | | | | | V V V | | | +----+ +----+ | +----+ +------+ | | |Peer|<----->|Peer|<---->|Peer|<-->|Client| | | +----+ +----+ | +----+ +------+ | | ^ ^ ^ | ^^ | | | | | V || | | | | | +----+ || | | | | +->|Peer|<-+| | | | V +----+ | | | V +--------_-+ | | | +------+ |Enrollment| | | | |Client| | Server |<--------+ | | +------+ +----------+ | +------------------------------------------------+ Figure 1 P2P SIP Network Architecture Judy Expires January 12, 2010 [Page 6] Internet-Draft P2PSIP Security Requirements July 2009 3. Security Scenarios To determine the security issues in P2P SIP system, there should be some application scenarios in P2P SIP environment. We will describe these security scenarios first and turn to discussion about security problems and security requirements. 3.1. VoIP VoIP is an important application scenario in P2P SIP system. In this scenario, client node is the VoIP end user. It will be authenticated by the peer, which is directly connected to, with the authentication vector from enrollment server and in the same time it shall authenticate the peer, and the client can communicate with another client through the security path set up by peers. Peer node is responsible for authenticating fresh VoIP client on behalf of enrolment server and support to negotiate and then provide security link between the peer and the client. Peer is also responsible for locating the other end client and also responsible for establishing a secure link between the peers and transferring data for end to end clients' communication. If a new peer enters the network or old peer exits, the secure link will be changed because the network topology is changed with the new peer. Enrollment server generates authentication vectors based on the authentication request received from the peer who is directly connected to the client and sends vectors to the peer in response. In this scenario, security association should be established between peer and peer/enrollment server for integrity, confidentiality and anti-replay about the signaling and user data. The following figure shows how a client (named client A) calls another client (named client B) by through the P2P SIP network. Judy Expires January 9, 2010 [Page 7] Internet-Draft P2PSIP Security Requirements July 2009 +-------------------------------------------------+ | | | +-------+ +----------------+ | | |Client | V V | | +-------+ +----+ +----------+ | | ^ +------->|Peer|<--+ |Enrollment| | | | | +----+ | | Server | | | | | ^ | +----------+ | | | | | | | | | | | | | | | | | | | | V V V | 4 | | +----+ 3 +----+ | +----+--->+-------+ | | |Peer|<=====>|Peer|<====>|Peer| |ClientB| | | +----+ +----+ | +----+<---+-------+ | | ^ +-----+ ^ ^ | ^^ 5 | | | | 1 | | | V || | | 2| | | | | +----+ || | | | | | | +->|Peer|<-+| | | | | V V +----+ | | | V | +--------_-+ | | | +-------+ |Enrollment| | | | |ClientA| | Server |<--------+ | | +-------+ +----------+ | +-------------------------------------------------+ Figure 2 VoIP in P2P SIP system 1. The client should be authenticated firstly. The peer should send authentication request to the client which it directly connects to. The peer will forward this session request to enrollment server. When the enrollment server received request, it generates authentication vector for the client A and sends it back to the peer. 2. The peer will authenticate client by using the authentication vectors. At the same time, the client A should authenticate the peer too. Then this way, the peer and client performs the mutual authentication. It is shown as step 2 in the figure. This process MUST be done just because it is the basic of security environment. Besides this authentication function, the other security protection between peer and client such as integrity and confidentiality will be provided after the security mode negotiation between them. 3. The peer with client A will establish SA with the peer with client B. so the security link will be set up between the related peers. Judy Expires January 12, 2010 [Page 8] Internet-Draft P2PSIP Security Requirements July 2009 4. In this step, the peer with the client B termination will authenticate the client B by using the authentication vectors from the enrollment server. 5. Client B performs the authentication for the peer as well. And then they negotiate the security association to provide the security transfer on the communication between them. At the end of this procedure, hop-by-hop security link has been performed in the communication from the end to end user such as client A to client B. Judy Expires January 12, 2010 [Page 9] Internet-Draft P2PSIP Security Requirements July 2009 4. Security Threats This section analyzes the security threats about P2P-SIP system. 4.1. Weak Security Protection Caused by no trust In P2P SIP network, the traditional security mechanism is not used to this network because of the network is distributed and has no centralized point. As the topology of P2P SIP network is different between traditional C/S networks, it will cause some problems mentioned as following: o Security domain will be very difficult to be divided clearly o Acceleration of the security threats and make the attacks easy and impact much more wide areas than before The first bullet point describes that in the P2P SIP network, security domain changes along with new nodes enter the system and/or old nodes leave the system. The traditional security domain division function is no longer fit for P2P SIP network. No node can guarantee the node that had same security domain still can be trust when the network topology changes. The second bullet point describes that nodes will suffer less punishment for malicious action in P2P SIP networks. So nodes will suffer more attacking in the system and will reduce the trust level to other nodes. As mentioned above, P2P SIP nodes have less trust with other nodes. So the network security protection is weakened. 4.2. Routing Modification Routing protocol is the key protocol and core security mechanism for P2P SIP architecture. It provides some mechanisms, such as adding/deleting peers into system, locating specific peer, updating network status, searching source and the failure management. This will affect the network robust, reduce efficiency of the network. If the routing message is not protected, it will cause problem described as following: o Attacker can spread fake information in the network. It will result peers modify their routing information and make a wrong way path to connect an unavailable peer or to achieve a wrong position. Judy Expires January 12, 2010 [Page 10] Internet-Draft P2PSIP Security Requirements July 2009 4.3. Malicious Code Spreading In the P2P SIP environment, malicious code such as worm and Trojan horse can spread in the system easily because of the convenient sharing and routing mechanism. Malicious code will cause severe disaster because of what we pointed out as following. o In the P2P SIP environment, each peer has ability to get information about its neighbor node. So malicious code can make attack based on the existed information. This will reduce the difficulty to launch an attack. o In the P2P SIP environment, peers make communication with each other directly and don't need to be transferred by servers. Peers have different security levels and will suffer attacking more easily. In this situation, one node will be infected with malicious code by several other peers and will infect many other peers as the malicious resource. o As the logical-adjacent peers may be far away in geographical in the p2p sip network, the malicious code can affect a larger scope, and this will cause great damage for the system. Judy Expires January 9, 2010 [Page 11] Internet-Draft P2PSIP Security Requirements July 2009 5. Security Requirements With the security threats analysis, we can find out what the security requirements the P2P SIP system really needs. 5.1. Trust Model The section 4.1 analyzes the problems and influences in situation that P2P SIP system lack of trust. It MUST need to create a trust model in the light of the trust architecture in the real world. P2P SIP network will benefit from trust incentive system. There are some reasons described as following: o Trust mechanism can be an effective mechanism to measure the security status of nodes. o Security domain can be made and updated dynamically with trust mechanism. P2P SIP network can be divided into some security domains depend on the corresponding trust levels. The unique security policy can be made for a security domain as nodes in the same domain have the same trust level. Moreover, if the network changes, the trust level of related nodes will change as well. It will cause the security domain update. o Trust mechanism can effectively inhibit malicious motivation for the attacking. Each node can get information about another node's trust information so it can judge the possibility of launching malicious attack the node is. With the information, it can determine whether the node should be connected. So trust mechanism can encourage nodes to reduce the malicious motivation and actions and enhance network security level. For example, for the different kinds of nodes, it should set three kinds of measure function for the three kinds of nodes as following: o Enrollment server is a key node in the network for authentication and authorization. It will be provided the highest level security protection and suffer lest attack. So initial trust level of enrollment server can be set highest level trusted. But if malicious action is detected with specific enrollment server, its trust level should be reduced rapidly and greatly to limit the influence of its malicious attack. Judy Expires January 12, 2010 [Page 12] Internet-Draft P2PSIP Security Requirements July 2009 o Peer is the basic node to construct P2P SIP network. Peers have the most complex security requirements. Each peer should be initiated with middle level of trust and adjust trust level by peer information such as link information, peer action, activity ability or any other information. o Client is the end of P2P SIP network. It was controlled by end user and can enter and exit network at any time. So the initiating trust level should be low. It can be updated by client behaviors and information as client actions, resource occupancy and any others. 5.2. Authentication Infrastructure In the traditional network, a client who wants to use service from server must be authenticated and authorized by related server. But P2P SIP system is a distributed network. This network has no centralized nodes. Each peer can provide services for other entities. When a node sends service request to networks, but peer cannot do the authentication process. It should be enrollment responsibility. As a result, a special kind of nodes SHOULD be made for providing authentication service for other entities. These nodes are enrollment servers. For this authentication mechanism, enrollment servers can be organized as two options as following. 5.2.1. Centralized Authentication Infrastructure In P2P SIP network, a centralized authentication infrastructure MAY be implemented. In this scenario, there is a super peer in P2P SIP network, act as enrollment server. It SHOULD stores all enrollment information about each node, either peer or client. Every node who wants to join this network SHOULD be authenticated and authorized by this server. If it is joining peer, it SHOULD make authentication process with enrollment server directly. Or it SHOULD make authentication process with proxy peer indirectly if not. 5.2.2. Distributed Authentication Infrastructure As P2P SIP system is a distributed network, a distributed authentication infrastructure which will fit for the system better MAY be implemented. As distributed authentication infrastructure is set, there are two problems should be considered: o The credentials storage on the distributed servers. Judy Expires January 12, 2010 [Page 13] Internet-Draft P2PSIP Security Requirements July 2009 o The procedure how a new visitor makes mutual authentication with network. For the first problem, the credential for all nodes can be divided into some categories. After that, the credentials should be placed into selected enrollment server by specific algorithm. The DHT algorithm is preferred because it will benefit when a new visitor find out where its credential is in authentication procedure. For example, to deal with the mutual authentication, it should divide base on whether the new visitor is client or not. o If the new visitor is peer, it should find the nearest enrollment server based on the algorithm like DHT and send authentication request to the enrollment server. Enrollment server will search peer's credential in local database after it received authentication request. If peer's credential is not in the database, server should get credential from other enrollment servers and stores it temporarily. Then it will generate authentication vector and make normal authentication procedure between peer and enrollment server. If the credential is stored temporarily in the enrollment server, it MUST be deleted after the peer exits this network. o If the new visitor is a client. It should send authentication request to nearest enrollment server through the peer it is directly connected. Enrollment server will generate authentication vector and send it to peer. Peer on behalf of enrollment server make authentication procedure with client. After the duplex authentication between client and peer, it should send result to enrollment server no matter it succeeded or failed. 5.3. Protection against Malicious Code Spreading In P2P SIP system every nodes are equal. Each peer has ability to share and spread information it has. So if malicious code infects a weak security peer, it will spread rapidly. For this reason, there SHOULD be a mechanism or some technology to prevent and diminish malicious code spreading. Some protection policy can be defined as: o The unnecessary port and application server should be closed in each node to reduce the possibility of suffering malicious attack. Judy Expires January 12, 2010 [Page 14] Internet-Draft P2PSIP Security Requirements July 2009 o The protection will benefit from the trust mechanism. It is because the trust mechanism marks nodes with high attacking possibility in low trust level so that few of nodes will connect to the low trust level nodes. Moreover, attacking source should be fast located and identified. The earlier attacker was located, the less lost in the P2P system was suffered. To achieve this goal, for example, some mechanisms can be considered here. o Undeniable mechanism. Undeniable mechanism forces each node in the network to be responsible for its behavior. When the mechanism is deployed, proofs of malicious attacking can be collected easily. So the location and identification of attacker can be got fast and exact based on these proofs. o Responsibility Chaining. A responsibility chaining is used as an attachment of the packets transferred in the network. It can inform receiver where the packet is sent out and which node it has passed. With information provided by this chaining, it is easy to find out where and what identity the attacker is by tracing back step by step. Judy Expires January 12, 2010 [Page 15] Internet-Draft P2PSIP Security Requirements July 2009 6. Security Considerations This memo considers the security concerns and security requirements about P2P SIP system. So it would not introduce any additional security problems. Judy Expires January 12, 2010 [Page 16] Internet-Draft P2PSIP Security Requirements July 2009 7. IANA Considerations There are no IANA considerations associated to this memo. Judy Expires January 12, 2010 [Page 17] Internet-Draft P2PSIP Security Requirements July 2009 8. Conclusions This memo describes variety of security threats in P2P SIP system first. According these security threats, P2P SIP security requirements is brought up. Judy Expires January 12, 2010 [Page 18] Internet-Draft P2PSIP Security Requirements July 2009 9. References 9.1. Normative References [1] Bryan, D., Matthews, P., Shim, P., and D. Willis, "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts- 02.txt (work in progress), July 2008. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:Session Initiation Protocol", RFC 3261, June 2002. [3] Matuszewski, M., Ekberg, J-E. and Laitinen, P., "Security requirements in Peer-to-Peer Session Initiation Protocol", draft-matuszewski-p2psip-security-requirements-04.txt (work-in-progress), November 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Author's Addresses Judy Zhu China Mobile Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China Email: zhuhongru@chinamobile.com Minpeng Qi China Mobile Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China Email: qiminpeng@chinamobile.com Judy Expires January 12, 2010 [Page 19]