P2PSIP Working Group K. Birkos INTERNET-DRAFT C. Papageorgiou Intended Status: Experimental P. Galiotos Expires: September 2010 (University of Patras) T. Dagiuklas (TEI of Mesolonghi) C. Tselios S. Kotsopoulos (University of Patras) March 1, 2010 Security Mechanisms and Key Refresh for P2PSIP Overlays draft-birkos-p2psip-security-key-refresh-00 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 contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 Birkos et al. Expires September 2010 [Page 1] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 Copyright and License Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Birkos et al. Expires September 2010 [Page 2] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 Abstract This document proposes security extensions that are applicable to P2PSIP overlays that follow the base protocol described in the WG leading drafts. The proposed extensions exploit symmetric/asymmetric cryptography and a key refresh mechanism to protect the signaling exchanged between the participating peers in order to enhance the robustness of the system against several types of attacks that are common to peer-to-peer networks. The refresh mechanism is either supervised by higher-level trusted peers or exclusively controlled by the members of the overlay. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Super Peers . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Security Credentials . . . . . . . . . . . . . . . . . . . 5 3 Securing Basic Overlay Operations . . . . . . . . . . . . . . . 5 3.1 Securing Join Process . . . . . . . . . . . . . . . . . . . 6 3.2 Securing Updates . . . . . . . . . . . . . . . . . . . . . 6 3.3 General Encryption Rules . . . . . . . . . . . . . . . . . 6 4 Refresh Mechanism . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Key Refresh Supervised by Super Peers . . . . . . . . . . . 7 4.2 Key Refresh Handled by Peers . . . . . . . . . . . . . . . 9 5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 7 Security Considerations . . . . . . . . . . . . . . . . . . . 11 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1 Normative References . . . . . . . . . . . . . . . . . . 11 9.2 Informative References . . . . . . . . . . . . . . . . . 11 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Birkos et al. Expires September 2010 [Page 3] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 1 Introduction This document defines security mechanisms that can be used as optional features in P2PSIP overlays. REsource LOcation And Discovery (RELOAD) [I-D.reload] already includes security features based on TLS and public key certificates. The certificates are digitally signed by a Certificate Authority (CA) during the Enrollment and Authentication phase described in the base protocol. In small-scale overlays between trusted users with no strict security requirements, the use of self- signed certificates is an alternative [I-D.reload]. Other WG drafts have also discussed security considerations [I-D.sec-ext][I-D.sec- mech]. Peer-to-peer networks are prone to several types of attacks due to their distributed nature. Attacks can target the structure of the overlay, overlay routing and/or stored information. Protecting signaling is necessary in order to hide the exchanged information between peers during peers' joining/leaving the overlay and also during maintenance and stabilization [I-D.sip-usage]. Apart from that, refreshment of the used security credentials is a practice that can enhance the robustness of the system against malicious activities and remove any detected compromised peer. This document aims at describing a basic protection strategy through encryption using symmetric and asymmetric cryptography and defines other uses of keys already included in the base protocol. In addition, a key refresh mechanism is defined. According to this mechanism, the keying material of the participating peers is periodically refreshed and new certificates are generated so that the binding between peer IDs and the new public keys can be verified. The process can be supervised by higher-level peers called super peers. [I-D.hierarchical] defines how a P2PSIP overlay based on peers that belong to different levels of hierarchy should operate. In the absence of super peers, each member of the overlay is responsible for guaranteeing the validity of its new security credentials. 1.1 Terminology 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]. Terms and definitions from the Concepts and Terminology for Peer to Peer SIP [I-D.concepts] and the REsource LOcation And Discovery (RELOAD) Base Protocol [I-D.reload] are extensively used in this document. New terms that are introduced are presented below. Super Peer: A higher-level peer with extensive computational Birkos et al. Expires September 2010 [Page 4] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 capabilities which is responsible for monitoring peer joining activities, overlay maintenance and refreshment of the security credentials. Master Key (MSK): A network-wide shared secret key used for authentication and for identity protection purposes when a new peer joins the overlay and also during the refreshment of the security credentials. It is equivalent to the key used in the Shared-Secret Security subsection as appeared in [I-D.reload]. Public/Private Key pair (PPK pair) : The pair of keys used in the asymmetric cryptography. The sender encrypts a message using the receiver's public key and the receiver uses its own private key to decrypt the message. 2 Prerequisites The security extensions described in this document depend on symmetric and asymmetric cryptography and also on the existence of super peers, which monitor certain activities regarding security during the Refresh process. The Refresh process is described later in this document. 2.1 Super Peers Super peers are higher-level peers with extensive responsibilities regarding the security of the P2PSIP overlay. Super peers are in charge of signing public-key certificates and they consist a second line of trust apart from the trusted certificate authority which initially issues the certificates to peers that wish to join the overlay. A bootstrap node MAY include super peer functionality. 2.2 Security Credentials As in the original protocol, each node possesses a shared secret key. In this I-D, this key is called MSK. The difference is that the MSK does not only serve at the formation of TLS connections but also in the authentication that takes place during the joining process and in the protection of peer identities. In addition, each peer generates a PPK pair prior to the Enrollment and Authentication phase. The validity of the public key is proved by the usage of the public key certificate which binds the node's public key with the node's identity. 3 Securing Basic Overlay Operations In the following, the usage of the security credentials is defined in Birkos et al. Expires September 2010 [Page 5] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 order to protect the signaling. 3.1 Securing Join Process According to [I-D.reload], at the beginning of the joining process, the joining peer (JP) sends a JoinReq message to the admitting peer (AP). The body of the JoinReq message SHOULD be encrypted with the MSK. This practice has two advantages. At first, it strengthens authentication since the MSK serves as a secondary authentication credential complementary to public key certificate that binds JP's public key with JP's identity. The fact that a JP holds MSK enforce the fact that a legitimate peer tries to become member of the overlay. Secondly, encrypting the body of the JoinReq message with the MSK ensures that the identity of JP remain secret to attackers that would possibly try to impersonate JP. Upon reception of a JoinReq message, AP verifies the signature of the CA and consequently the validity of the public key of JP that was included in the certificate. Thus, from now on AP MAY encrypt the body of every message destined to JP with JP's public key. 3.2 Securing Updates Update messages are overlay-specific and are exchanged between peers whenever a peer joins/leaves the overlay or during maintenance and stabilization. Since UpdateReq messages carry information that might be exploited by an attacker to disrupt connectivity at the overlay level or to launch overlay routing attacks, the body of UpdateReq messages SHOULD be encrypted with the public key of the recipient. 3.3 General Encryption Rules In general, the body of every message that carries information that should be protected against eavesdropping SHOULD be encrypted with the recipient's public key. These messages include StoreReq, FetchAns, FindAns and RouteQueryAns. Of course, encrypting additional message types should be an OPTIONAL feature. An UpdateReq message that designates a renewal of the security credentials SHOULD be encrypted with the MSK as explained in section 5.1. The following table summarizes the basic encryption rules that SHOULD be followed by a P2PSIP system. PK denotes the public key of the recipient. Birkos et al. Expires September 2010 [Page 6] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 +------------------+--------------+ |Message Code Name |Encrypted with| +------------------+--------------+ |join_req | MSK | |update_req | MSK/PK | |store_req | PK | |fetch_ans | PK | |find_ans | PK | |route_query_ans | PK | +------------------+--------------+ 4 Refresh Mechanism The refresh mechanism specifies all the necessary procedures and the series of actions in order to deliver fresh keying material to the participating peers. The keying material that needs to be refreshed is the PPK pairs of the participating peers. The refreshment of the PPK pairs serves two distinct purposes. The main goal is to limit the period during which the system is vulnerable in case an attacker or a malicious user obtains the private key of a peer. A secondary goal is to limit the amount of time available to attackers that may be using cryptanalysis in order to reveal private keys. In the proposed system, the validity of the PPK pairs is timely bounded. Consequently, the validity of the corresponding public key certificates is timely bounded as well. Peers generate their own PPK pairs after having received an explicit request from a super peer. A new certificate has to be produced. This certificate will verify the binding between the peer ID and the new public key. In the absence of a CA, the new certificate can either be self-signed or signed by the super peer that issued the order for refreshment. Additionally, the new certificate has to be stored in the overlay as described in [I- D.sip-usage] and the neighbors of the peer with the refreshed PPK pair need to obtain the new public key. These issues are addressed next. 4.1 Key Refresh Supervised by Super Peers In each P2PSIP overlay, many super peers may exist. Otherwise, the reliance on a single super peer would consist a single point of failure. Super peers are charged with supervising the refresh process. Each super peer is responsible for the key refresh of a portion of the participating peers according to the peers' position in the identity space. For example, different super peers supervise different sectors in the Chord ring in case Chord is used in the Topology Plugin. For improved scalability and granularity, these sectors should not be static. In other words, super peers should be Birkos et al. Expires September 2010 [Page 7] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 responsible for sets of peers that are already connected to the overlay based on the information disseminated via the Update messages. When the CA issues a certificate to a peer, it includes the validity period in the certificate. A super peer periodically checks the certificates of the peers in its jurisdiction. A time margin before a certificate expires, called refresh margin, the super peer sends a RefreshReq message to the owner of the certificate, i.e. to the peer of which the PPK pair needs to be refreshed. We denote this peer as Refreshed Peer (RP). RP checks whether the validity period of the certificate justifies a refresh action and decides whether it will proceed with the refresh process. RP generates a new PPK pair by means of an asymmetric key generation algorithm. The chosen algorithm as well as the required input to produce the new keying material is beyond the scope of this draft but RSA could be an option. RP sends the new public key to the super peer via a RefreshAns message. The RefreshAns message is signed with the old private key of RP and encrypted with the MSK. Signing the RefreshAns with the old private key enables the super peer to verify the identity of the creator of the new PPK pair. The super peer verifies that RP has indeed created the PPK pair and not some other malicious peer that tried to impersonate RP. Encrypting RefreshAns with the MSK further protects the delivery of the new public key, especially in case an attacker has retrieved RP's private key. The super peer then creates a certificate that binds RP's ID to RP's new public key. The super peer signs the certificate and stores it in the DHT. At the same time it sends a copy of the certificate to RP via an UpdateReq message. RP responds with an UpdateAns to the super peer. Finally, RP informs its neighbors about the refreshed public key via UpdateReq messages. An UpdateReq message contains the certificate signed by the super peer. RP's neighbors that receive the UpdateReq verify super peer's signature and designate the acceptance of the new public key by sending an UpdateAns to RP. Alternatively, it can be RP the peer that sends the StoreReq message in order to store the new certificate in the DHT. The following figure depicts the exchanges messages. SP is the super peer, RP is the peer being refreshed, NRP is a neighbor of RP and CRP is the peer that stores RP's certificates (according to the Certificate Store Usage [I- D.reload]). Birkos et al. Expires September 2010 [Page 8] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 CRP SP RP NRP | | | | | | RefreshReq | | | |----------->| | | | RefreshAns | | | StoreReq |<-----------| | |<-----------| UpdateReq | | | StoreAns |----------->| | |----------->| UpdateAns | | | |<-----------| UpdateReq | | | |----------->| | | | UpdateAns | | | |<-----------| | | | | The Refresh process must guarantee the unobstructed operation of the overlay regardless of impairments of lower layers. In case super peer does not receive a RefreshAns by RP within a certain time limit, it resends the RefreshReq message to RP. The time limit and the maximum number of attempts after an unsuccessful refresh attempt are parameters of the system. When the maximum number of trials has been reached, the RP is considered disconnected. RP has to pass through the Enrollment and Authentication phase in order to re-join the overlay. The super peers may participate in a distributed Intrusion Detection System (IDS) and monitor peers' behavior in the overlay. Consequently, the decision of a super peer to request refreshed PPK pairs by a peer, depends on whether the activities of this peer justify the fact that the peer should continue to be a member of the overlay. The definition of an IDS suitable for a P2PSIP overlay is beyond the scope of this document. 4.2 Key Refresh Handled by Peers In this case, all the participating peers belong to the same level of hierarchy and there are no online entities that can supervise key refresh. Thus, the certificates containing the new public keys must be self-signed by the peers even if the original certificates were signed by the CA during Enrollment and Authentication. Moreover, each peer has the responsibility to initiate the refresh process. When RP's certificate is about to expire, RP generates a new PPK pair. RP also generates a certificate that contains its new public key bound to its ID. RP signs the certificate with its old private key and stores it in the DHT. After that, RP sends the new certificate to its neighbors via an UpdateReq message. The message is encrypted with the MSK. Birkos et al. Expires September 2010 [Page 9] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 Again, an unsuccessful refresh attempt results in RP disconnecting from the overlay and trying to receive a valid and updated certificate through Enrollment and Authentication. The following figure presents the refresh process handled by peers. CRP RP NRP | | | | StoreReq | | |<-----------| | | StoreAns | | |----------->| | | | UpdateReq | | |----------->| | | UpdateAns | | |<-----------| | | | The refresh method described in this subsection is more lightweight, produces less overhead and does not rely on any kind of online trusted third parties. However, the offered security level is reduced due to the use of self-signed certificates. 5 Conclusions This memo describes an additional usage of security credentials for enhancing the security levels of a P2PSIP overlay. Moreover, it introduces a refresh process via which the keying material of the peers is periodically renewed. The proposed solutions are designed to adapt to the requirements and the characteristics as defined in the leading WG drafts. Birkos et al. Expires September 2010 [Page 10] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 6 Acknowledgement The authors wish to acknowledge the support of the ICT European Research Programme and all the partners in PEACE: PDMF&C, Instituto de Telecomunicaciones, FhG Fokus, Kingston University, Thales, Telefonica, Pale Blue. 7 Security Considerations There are no security considerations at this time. 8 IANA Considerations This draft includes no request to IANA at this time. Considerations regarding the RefreshReq and RefreshAns messages defined in this document will be included in future versions of the draft, after proper discussion within the Working Group. 9 References 9.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2 Informative References [I-D.reload] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S. and Schulzrinne, H., "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-06, (work in progress), November 2009. [I-D.sip-usage] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S. and Schulzrinne, "A SIP Usage for RELOAD", draft-ietf- p2psip-sip-03, (work in progress), October 2009. [I-D.concepts] Bryan, D., Matthews, P., Shim, E., Willis, D. and Dawkins, S., "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-02, (work in progress), July 2008. [I-D.sec-ext] Jennings, C. and Deverick, J., "Security Extensions for RELOAD", draft-lowekamp-p2psip-reload-security-01, (work in progress), July 2007. Birkos et al. Expires September 2010 [Page 11] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 [I-D.sec-mech] Jennings, C., "Security Mechanisms for Peer to Peer SIP",draft-jennings-p2psip-security-00, (work in progress), February 2007. [I-D.hierarchical] Lifeng, L., "Hierarchical P2PSIP Overlay", draft- le-p2psip-hierachical-p2psip-overlay-00, (work in progress), July 2009. Author's Addresses Konstantinos Birkos University of Patras 26500 Patras, Greece Phone: +30 2610 996465 EMail: kmpirkos@ece.upatras.gr Christos Papageorgiou University of Patras 26500 Patras, Greece Phone: +30 2610 996465 EMail: xpapageo@ceid.upatras.gr Panagiotis Galiotos University of Patras 26500 Patras, Greece Phone: +30 2610 996465 EMail: pgaliot@upatras.gr Tasos Dagiuklas TEI of Mesolonghi 30300 Nafpaktos, Greece Phone: +30 26310 58486 EMail: ntan@teimes.gr Christos Tselios University of Patras 26500 Patras, Greece Birkos et al. Expires September 2010 [Page 12] INTERNET DRAFT Security Mechanisms and Key Refresh March 2010 Phone: +30 2610 996465 EMail: tselios@ece.upatras.gr Stavros Kotsopoulos University of Patras 26500 Patras, Greece Phone: +30 2610 996466 EMail: kotsop@ece.upatras.gr Birkos et al. Expires September 2010 [Page 13]