SPPSP Z. Lei Internet Draft ASTRI Intended status: BCP April 28, 2010 Expires: October 2010 The Secure P2P Streaming Protocol (SPPSP) draft-lei-sppsp-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted 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. This Internet-Draft is submitted 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, except to publish it as an RFC and to translate it into languages other than English. 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 Lei, et al. Expires October 28, 2010 [Page 1] Internet-Draft Secure P2P Streaming Protocol April 2010 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 October 28, 2010. Copyright 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. Abstract This document describes the Secure Peer-to-Peer Streaming Protocol (SPPSP), an extension of the Peer-to-Peer Streaming Protocol (PPSP), which can provide confidentiality, message authentication, and content protection to the PPSP traffic. Table of Contents Lei, et al. Expires October 28, 2010 [Page 2] Internet-Draft Secure P2P Streaming Protocol April 2010 1. Introduction................................................3 2. Terminology.................................................4 3. Goals and Features..........................................5 3.1. Features...............................................6 4. SPPSP Framework.............................................7 4.1. Secure PPSP...........................................10 4.2. SPPSP Cryptographic Contexts...........................11 4.3. SPPSP Packet Processing................................11 5. Pre-Defined Cryptographic Transforms........................12 5.1. Encryption............................................12 5.2. Null Cipher...........................................12 5.3. Message Authentication and Integrity...................12 6. Default and mandatory-to-implement transforms...............13 6.1. Encryption............................................13 6.2. Message Authentication / Integrity.....................13 7. Key Management Considerations...............................13 8. Security Considerations.....................................13 9. Application Scenarios.......................................13 9.1. Secure P2P Real Time Streaming.........................13 9.2. Message Authentication / Integrity.....................13 10. IANA Considerations........................................13 11. References................................................13 11.1. Normative References..................................13 11.2. Informative References................................14 12. Acknowledgments...........................................15 1. Introduction Peer-to-Peer streaming becomes popular in recent years because on the one hand it doesn't rely on the deployment of IP-multicast protocol, and on the other hand the data transmission among peers significantly reduce the bandwidth cost of the server, high scalability could then be achieved. Peer-to-Peer Streaming Protocol (PPSP) [1] is proposed to standardize this effort. Just as the Secure Real-time Transport Protocol (SRTP) [1] provides security and protection for RTP and RTCP traffic, the Secure Peer-to- Peer Streaming Protocol (SPPSP), an extension of the Peer-to-Peer Streaming Protocol (PPSP), provides confidentiality, message authentication, and content protection to the PPSP traffic. SPPSP provides a framework for encryption and message authentication of PPSP streams. SPPSP defines a set of default group key cryptographic protocols (Sections 4), and it allows new cryptographic protocols to be introduced in the future. With appropriate key Lei, et al. Expires October 28, 2010 [Page 3] Internet-Draft Secure P2P Streaming Protocol April 2010 management, SPPSP is secure (Section 9) for P2P real time streaming and P2P video on demand applications. SPPSP can achieve high throughput and low packet expansion. SPPSP provides suitable protection for heterogeneous environments in Layered P2P streaming [15](for example, with mobile phones, STB, and PC on the wired and wireless networks). A challenge for secure P2P streaming lies in the fact that streaming data comes from many different peers of dynamic nature and server (tracker server) who responds to a peer request for streaming content with only a list of peers. It does not guarantee either the security or the performance of the peers. Hence, secure P2P streaming has two important parts: 1) the communication between peer and tracker server; 2) the communication among the peers. The secure communication between peer and tracker server follows standard secure client server communication framework (e.g. reference framework RFC 2401 - Security Architecture for the Internet Protocol [8], and RFCs describing the Authentication Header (AH) [10] and Encapsulating Security Payload (ESP)[11] protocols. Key management for the tracker/peer communication may use existing standards, for example, RFCs on "The Internet Key Exchange (IKE)" [12], "Internet Security Association and Key Management Protocol (ISAKMP)" [13], and "The OAKLEY Key Determination Protocol" [14]. In addition to the secure client server communication, SPPSP adds the important secure group communications among the peers. For simplicity, we assume that each peer uses the same private key for peer communication, as well as communication with tracker server. 2. 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 [1]. Secure P2P Streaming: Secure Peer-to-Peer Streaming Protocol (SPPSP), a profile of the Peer-to-Peer Streaming Protocol (PPSP), provides confidentiality, message authentication, and content protection to the PPSP traffic; Public Key (PK): see Asymmetric Key Algorithm; Private Key (pi): see Asymmetric Key Algorithm; Lei, et al. Expires October 28, 2010 [Page 4] Internet-Draft Secure P2P Streaming Protocol April 2010 Group Key: a cryptographic key that is shared between a group of users. Typically, group keys are distributed by sending them to individual users, either physically, or encrypted individually for each user using either that user's pre-distributed private key; Group Mask: mask out the intended recipients among a group that a peer tries to send messages to; Symmetric Key Algorithm (SKA): use a single secret key shared by sender and receiver for both encryption and decryption. The sender and receiver must securely share a key in advance; Asymmetric Key Algorithm (AKA): does not require a secure initial exchange of secret keys to both sender and receiver. AKA creates a cryptographically related key pair: a secret private key and a published public key. Use of these keys allows protection of the authenticity of a message by creating a digital signature of a message using the private key, which can be verified using the public key. It also allows protection of the confidentiality and integrity of a message, by public key encryption, encrypting the message using the public key, which can only be decrypted using the private key; Group Asymmetric Key Cryptographic (GAKC): Asymmetric Key Cryptographic algorithm for a group of users to exchange messages securely and confidentially. 3. Goals and Features The security goals for SPPSP are to ensure: 1) the confidentiality of the PPSP payloads, and 2) authentication of the peer users. These security services are optional and independent from each other. Some may be more important than others. For example, SPPSP authentication and integrity protection may be mandatory for communications between tracker server and peers (as malicious or erroneous alteration of tracker messages could otherwise disrupt the whole P2P system). Other functional goals for the protocol include: - A framework that permits upgrading with new cryptographic algorithms - Low bandwidth cost, i.e., a framework preserving PPSP header compression efficiency - Low computational cost (for standardized part) Lei, et al. Expires October 28, 2010 [Page 5] Internet-Draft Secure P2P Streaming Protocol April 2010 - Small footprint (i.e., small code size and data memory) - Limited packet expansion to support the bandwidth efficiency - Independence from the underlying transport, network, and physical layers used by PPSP, in particular high tolerance to packet loss, delay, and re-ordering These properties follow closely to those specified in RFC 3711 Secure Real Time Transport Protocol [5] to ensure that SPPSP is a suitable protection scheme for P2P streaming under heterogeneous environment [15]. 3.1. Features In addition to those goals introduced in SRTP, by nature of P2P communication, SPPSP will need to address Group Asymmetric Key Cryptographic, i.e., the secure communications among a peer group who are exchanging control messages and content data. They include: - A single "private key" can be used for confidentiality and integrity protection, both for tracker-peer and peer-peer communications. This is achieved with a key derivation function, providing "session keys" for the respective payload of the communication session, securely derived from Group Asymmetric Key Cryptographic (GAKC) using cryptographic primitives including public key, group mask and GAKC parameters. - In addition, the key derivation can be configured to periodically refresh the session keys, which limits the amount of ciphertext produced by a fixed key, available for an adversary to cryptanalyze. - On the fly revoking or suspending access rights of one or any number of peers by updating the GAKC parameters at the tracker server, for example, update Group Mask (GM) so that certain peers can be mask in or mask out on the fly. Lei, et al. Expires October 28, 2010 [Page 6] Internet-Draft Secure P2P Streaming Protocol April 2010 4. SPPSP Framework A common use of group keys is to allow a group of users to decrypt a broadcast message that is intended for that entire group of users, and no-one else. In many applications, group keys are commonly used in conditional access systems, where the key is the common key used to decrypt the broadcast signal, and the group in question is the group of all paying subscribers. In this case, the group key is typically distributed to the subscribers' receivers using a combination of a physically-distributed secure cryptoprocessor in the form of a smartcard and encrypted over-the-air messages. This document does not cover the key distribution mechanism, which assumes that such key infrastructure has been established before the actual P2P streaming session. For example, in a commercial deployment, a dedicated private Key (pi) can be assigned to each STB at the factory floor. At the time the paid service is activated, such private Key can be enabled by the service provider. Similarly, for PC users and mobile phone users, they are uniquely assigned via secure key-exchange infrastructure. The specific methods are beyond the scope of the SPPSP protocol. We assume that a cryptographic pairing of public Key (PK) and a list of private Keys (pi) where i=1,...,N for some large natural number N. A Group Mask (S) with dimension N indicating a membership of (pi)s with i-th index having value 1 for members and 0 for non-members. It is clear that GM S can easily mask-in or mark-out one or any number of members by changing its values at the corresponding index positions. A Group Asymmetric Key Cryptographic (GAKC) transform can encrypt a "session key" using PK, pi, S and GAKC parameters into a "ciphertext" such that only peers who are members in S can decrypt the "session key" from the received "ciphertext". Non-members cannot decrypt the "session key" even if they receive the same data. "Session Key" GAKC PK Encrypt {pi}i=1,...,N ==========> "ciphertext" GAKC Group Mask S PK Decrypt GAKC parameters {pi} =======> "session key" GAKC parameters Fig 1 Group Asymmetric Key Cryptographic (GAKC) transformation Lei, et al. Expires October 28, 2010 [Page 7] Internet-Draft Secure P2P Streaming Protocol April 2010 "Session key" will be used to encrypt the message "payload", which will be sent to peers together with "ciphertext" using the standard PPSP data format. Encrypt Decrypt Data Payload =========> Data Encryption ======> Data Payload Fig 2 Symmetric key cryptographic (e.g. AES) for data payload SPPSP can be defined as an extension of PPSP. Except where explicitly noted, all aspects of PPSP apply, with the addition of the SPPSP security features. Conceptually, we can consider SPPSP to be a "bump in the stack" implementation which resides between the PPSP application and the transport layer. SPPSP intercepts PPSP packets and then forwards an equivalent SPPSP packet on the sending side, and intercepts SPPSP packets and passes an equivalent PPSP packet up the stack on the receiving side. Secure P2P architecture is extended from the P2P streaming (PPSP)[3] with modification of adding public key PK, private keys {pi}, Group Mask S, and GAKC parameters to meet the secure P2P streaming requirement. Application Layer ======================================================== Communication Layer Peer +-------------------+ |peer signaling |-------------------+ | |Data management | | | +===============+ |-+--------------+ | +===============+ | |Swarm ID | | |Secure GAKC | | | JOIN/LEAVE/ | | | - Chunk ID | | | - PK_ID | | | KEEPALIVE/PUT/| | | - peer list | | | - pi | | | GET | | | - Buffer map| | | - S | | +===============+ | +===============+ | | - GAKC paras| +-------------------+ | | - etc. | +---------------------+ +==============+ ^ -------------------*---------------------------------------------- Tracker V +-------------------+ |tracker signaling | Lei, et al. Expires October 28, 2010 [Page 8] Internet-Draft Secure P2P Streaming Protocol April 2010 | | | (JOIN/LEAVE/ | | KEEPALIVE/PUT/ | | GET/STATISTICS) | +-------------------+ +----------------------------------------------------------+ | Data management on Tracker | | | | +======================+ +======================+ | | |peer status | |content status | | | | peer ID | | +---------------+ | | | | - online time | | | Swarm ID | | | | | - peer property | | | - Chunk ID | | | | | - link status | | | - peer list| | | | | - etc. | | +---------------+ | | | | - | | +---------------+ | | | +======================+ +======================+ | | | +======================+ | | |Secure GAKC | | | |- PK list | | | | - pi list | | | | - S list | | | | - GAKC parameters | | | | - etc. | | | +======================+ | +----------------------------------------------------------+ ================================================================== Transport Layer Fig 3 SPPSP extends the function entities of PPSP Tracker Communication[3] For communications between tracker server and peer, each content with its unique Swarm ID will have corresponding public key PK_ID, {pi} list, and GAKC parameters, which have been pre-computed via a GAKC transformation. If tracker communicates with peer_i directly, Group Mask S by default can be S_i which is 1 at i-th index and 0 for other index places. Peers joining content with Swarm ID can use its corresponding PK_ID and GAKC parameters for encrypt/decrypt the "session key". Such session keys are used to encrypt the actual content (in this case, returned peer list or any other messages exchanged between tracker and peers) using any existing symmetric cryptographic key algorithm, e.g. AES [6]; Similarly, for communications between peers, all peers on the content Swarm ID will use the corresponding public key PK_ID and the corresponding GAKC parameters, which have been pre-computed via a GAKC transformation and distributed properly beforehand. Peers will Lei, et al. Expires October 28, 2010 [Page 9] Internet-Draft Secure P2P Streaming Protocol April 2010 use this PK_ID, group mask S for intended peers, and GAKC parameters for encrypt/decrypt the "session key". Such session keys are used to encrypt the actual content (in this case, the data payload, buffer map and/or any other messages exchanged among the peers) using any existing symmetric cryptographic key algorithm, e.g. AES [6]; 4.1. Secure PPSP The format of an SPPSP packet is illustrated below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Peer | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Destination Peer | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Payload . . . | | | | | | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | ~ Ciphertext (option) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : PK_ID (option) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | | +- Encrypted Payload Encrypted Session Key ---+ Fig 4 The format of an SPPSP packet. The "Encrypted Payload" of an SPPSP packet consists of the encryption of the PPSP payload of the equivalent PPSP packet. The Encrypted Session Key portion may not be present in every SPPSP packet. For example, session key contained in previous packets can be reused. This will save the cost. For a session update (or re-keying) Lei, et al. Expires October 28, 2010 [Page 10] Internet-Draft Secure P2P Streaming Protocol April 2010 for example serve disabling certain peers by update the mask, Encrypted Session Key portion will have to be sent. 4.2. SPPSP Cryptographic Contexts Each SPPSP stream session requires all the participating parties (including tracker and all peers) to maintain the cryptographic state information corresponding to the content Swarm ID. This information is called the "cryptographic context". For example, the PK_ID, all potential peers' private key {pi} list, group mask S, and GAKC parameters. SPPSP uses two types of keys: session keys and private keys. By a "session key", we mean a key which is used directly in a cryptographic transform (e.g., encryption of data payload or messages). It can be changed on the fly. The "private key" for a peer is fixed via GAKC pre-computation and stored for the given peer. Tracker server or other peers use asymmetric cryptographic transformation to encrypt the "session key". Whether or not a certain peer has the capability to decrypt the ciphertext to get the "session key" is dictated by the Group Mask S. For example, if peer i subscribes to a certain content (be a paid customer), index i will have value 1 in S, hence peer i can obtain the session key using its private key and the GAKC parameters. This is very important because peers have no way of knowing if other peers have the rights to view the content or not, only server has such knowledge. With SPPSP, peers need not care about who has rights to view what content, because all the accessibility information is built into each SPPSP packet. 4.3. SPPSP Packet Processing The sender peer SHALL do the following to construct an SPPSP packet: - Determine which cryptographic context to use. Lei, et al. Expires October 28, 2010 [Page 11] Internet-Draft Secure P2P Streaming Protocol April 2010 - Construct PPSP packet as specified in PPSP protocol, and determine the payload data. - Determine the PK_ID - Determine the session key to be used. - Encrypt the PPSP payload to produce the Encrypted Portion of the packet using AES (or any symmetric key algorithm). - Determine the group mask S - Encrypt the session key to generate the ciphertext portion of the packet. To decrypt an SPPSP packet, the receiver peer SHALL do the reverse of the above steps. 5. Pre-Defined Cryptographic Transforms 5.1. Encryption The default cipher is the Advanced Encryption Standard (AES)[6]. 5.2. Null Cipher The NULL cipher means no confidentiality is needed. The SPPSP packet becomes the same as PPSP packet with no encryption for the payload. For example, this can be the case for free content with access to all the peers. 5.3. Message Authentication and Integrity Authentication is needed when receiving peer needs to make sure the packets are from the right source (right peers or tracker server). And it shall be supported by the GAKC mechanism. Lei, et al. Expires October 28, 2010 [Page 12] Internet-Draft Secure P2P Streaming Protocol April 2010 6. Default and mandatory-to-implement transforms 6.1. Encryption 6.2. Message Authentication / Integrity 7. Key Management Considerations 8. Security Considerations 9. Application Scenarios 9.1. Secure P2P Real Time Streaming 9.2. Message Authentication / Integrity 10. IANA Considerations Todo: The content of this section need further input. 11. References 11.1. Normative References [1] Y. Zhang, et. al. "Problem Statement of PPSP", draft April 2009 Lei, et al. Expires October 28, 2010 [Page 13] Internet-Draft Secure P2P Streaming Protocol April 2010 [2] N. Zong, et. al. "P2P Streaming Protocol (PPSP) Requirements", draft March 2009 [3] Yingjie Gu, et. al. Tracker Protocol, PPSP (drafting). [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [5] M. Baugher, et. al. The Secure Real-time Transport Protocol (SRTP), RFC 3711, March 2004 [6] NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197, http://www.nist.gov/aes/ [7] H. Krawczyk, et. al. "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 [8] S. Kent, et. al. "Security Architecture for Internet Protocol", RFC 2401, November 1998. [9] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998 [10] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [11] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [12] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [13] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998 [14] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998 [15] K. Wu, et. al. "P2P Layered Streaming for Heterogeneous Networks in PPSP", draft March 2010 11.2. Informative References Lei, et al. Expires October 28, 2010 [Page 14] Internet-Draft Secure P2P Streaming Protocol April 2010 [16] Xin Xiao, Yuanchun Shi, Yuan Gao and Qian Zhang, "LayeredP2P: A New Data Scheduling Approach for Layered Streaming in Heterogeneous Networks". Infocom 2009 [17] Reza Rejaie, Antonio Ortega, "PALS: Peer-to-Peer Adaptive Layered Streaming". NOSSDAV, 2003. [18] Yi Cui, Klara Nahrstedt, "Layered Peer-to-Peer Streaming". NOSSDAV, 2003 [19] Zhengye Liu, Yanming Shen, Shivendra S.Panwar, Keith W. Ross and Yao Wang, "Using Layered Video to Provide Incentives In P2P Live Streaming". In Proc. ACM Special Interest Group on Data Communication, 2007 12. Acknowledgments Lei, et al. Expires October 28, 2010 [Page 15] Internet-Draft Secure P2P Streaming Protocol April 2010 Authors' Addresses James Zhibin Lei Hong Kong Applied Science and Technology Research Institute Company Limited (ASTRI) 3/F, Building 6, 2 Science Park West Avenue, Hong Kong Science Park, Shatin, New Territories, Hong Kong Phone: 00852-34062748 Email: lei@astri.org
Phone: Email: Lei, et al. Expires October 28, 2010 [Page 16]