Internet Engineering Task Force D. Gabrijelcic Internet-Draft Jozef Stefan Institute Intended status: Informational November 29, 2012 Expires: June 2, 2013 Enhanced Closed Swarm protocol draft-ppsp-gabrijelcic-ecs-00 Abstract The Enhanced Closed Swarm (ECS) protocol is a distributed access control mechanism suitable for usage in Peer-to-Peer content delivery systems. The protocol provides coarse or fine grained authorization of peers participating in content distribution. As a result, only authorized peers are allowed to communicate in a swarm. The protocol also provides data confidentiality, integrity and origin authentication for application data exchanged among peers. The protocol is simple but flexible enough to enable a range of usage scenarios. In addition to the ECS protocol, this document also describes its application in the IETF PPSPP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on June 2, 2013. Copyright Notice Copyright (c) 2012 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 Gabrijelcic Expires June 2, 2013 [Page 1] Internet-Draft ECS protocol November 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 2. Initial requirements . . . . . . . . . . . . . . . . . . . . . 4 2.1. Swarm requirements . . . . . . . . . . . . . . . . . . . . 5 3. Authorization credential - Proof-of-Access . . . . . . . . . . 6 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Enhanced Closed Swarm protocol . . . . . . . . . . . . . . . . 7 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Initial exchange . . . . . . . . . . . . . . . . . . . 7 4.1.2. Mutual authorization . . . . . . . . . . . . . . . . . 8 4.1.3. Authorization failure . . . . . . . . . . . . . . . . 9 4.1.4. Nonces . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.5. Requested service . . . . . . . . . . . . . . . . . . 10 4.1.6. Supported digital signature algorithms . . . . . . . . 10 4.1.7. PoA embedding and encoding . . . . . . . . . . . . . . 11 4.1.7.1. PoA encoding . . . . . . . . . . . . . . . . . . . 11 4.1.7.2. Digital signatures and public keys . . . . . . . . 12 4.2. Application data communication protection . . . . . . . . 14 4.2.1. Key establishment . . . . . . . . . . . . . . . . . . 14 4.2.1.1. Elliptic Curve Diffie-Hellman . . . . . . . . . . 14 4.2.1.2. Note on RSA based key establishment . . . . . . . 15 4.2.1.3. Keying material generation . . . . . . . . . . . . 15 4.2.2. Security services provisioning . . . . . . . . . . . . 17 4.2.2.1. AEAD-AES-GCM algorithms . . . . . . . . . . . . . 18 4.2.2.2. AEAD-AES-CBC-HMAC-SHA2 algorithms . . . . . . . . 18 4.2.2.3. Anti-replay service . . . . . . . . . . . . . . . 19 4.2.2.4. Nonce requirements and generation . . . . . . . . 19 4.2.2.5. Protected messages processing . . . . . . . . . . 21 4.2.2.6. Security services summary . . . . . . . . . . . . 22 4.3. Error messages . . . . . . . . . . . . . . . . . . . . . . 24 5. Access control . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1. PoA validation . . . . . . . . . . . . . . . . . . . . . . 25 5.2. Rule based access control . . . . . . . . . . . . . . . . 25 6. Initializing an ECS enabled swarm . . . . . . . . . . . . . . 26 6.1. Swarm certificate . . . . . . . . . . . . . . . . . . . . 26 7. Using ECS with PPSPP . . . . . . . . . . . . . . . . . . . . . 28 7.1. ECS protocol UDP encapsulation . . . . . . . . . . . . . . 28 7.1.1. ECS protocol messages . . . . . . . . . . . . . . . . 28 7.1.2. Initial PPSPP handshake and ECS exchange . . . . . . . 29 Gabrijelcic Expires June 2, 2013 [Page 2] Internet-Draft ECS protocol November 2012 7.1.3. ECS authorization . . . . . . . . . . . . . . . . . . 29 7.1.4. ECS encrypted message . . . . . . . . . . . . . . . . 30 7.1.5. Terminating the connection . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . . 35 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 Gabrijelcic Expires June 2, 2013 [Page 3] Internet-Draft ECS protocol November 2012 1. Introduction This document describes the Enhanced Closed Swarm protocol (ECS), a distributed access control mechanism. The protocol was designed to be used in Peer-to-Peer content delivery systems. It can be equally used in streaming on-demand, live streaming as well as in conventional downloading scenarios. A peer participating in an ECS swarm needs an credential called a proof-of-access (POA). The credential is used by the ECS protocol when the peer joins the existing swarm of other peers. On joining the protocol enables mutual authorization of both peers, the joining one and the one already in the swarm. Each of the peers is responsible to validate contacting peer credential and enforce authorization decisions as a result of credential validation. After mutual authorization the communication between peers is protected by data confidentiality, integrity and origin authentication services preventing potential malicious disruption or deceit of the communication. The credentials are expected to be issued to interested peers by content owners, or distributors acting as credential issuers. This document specifies basic issuing process requirements and the ECS protocol compliant PoA specification. This document specifies at first a general description of the Enhanced Closed Swarm protocol and authorization credential and then their usage in access control provisioning for PPSPP [I-D.ietf-ppsp-peer-protocol] with UDP encapsulation. 1.1. Conventions Used in This Document 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. Initial requirements To use the ECS protocol, each peer must be able to generate a public- private key pair according to the document specification and to keep the private key secret. The peer must support specified core digital signature and corresponding hash algorithms, and encryption and keyed hash algorithms. The peer must be able to generate a secret key according to the specification. In the rest of the document the following notations are used: Gabrijelcic Expires June 2, 2013 [Page 4] Internet-Draft ECS protocol November 2012 Notation Meaning ----------------------------------------- SWid Swarm ID Va, Vb Version, peer A, peer B Na, Nb Nonce, peer A, peer B PoAa, PoAb Proof-of-Access, peer A, peer B RSa, RSb Requested Service, peer A, peer B Ia,Ib Notification information, peer A, peer B Sab Shared secret Ks Issuer's public key (Swarm public key) Kh Holder's public key ET Expiry time R Rules {}Ks-1 Digital signature created with private key of the issuer {}Ka-1 Digital signature created with private key of peer A {}Kb-1 Digital signature created with private key of peer B {}Ka Encryption using public key of peer A [] Optional fields || Concatenation symbol PRF Pseudorandom function K AEAD interface parameter, key P AEAD interface parameter, plaintext N AEAD interface parameter, nonce A AEAD interface parameter, associated data C AEAD interface parameter, ciphertext T Data origin authentication and integrity service tag EK Secret encryption key MK Message authentication code key NI AEAD nonce, implicit part NE AEAD nonce, explicit part SQ Anti-replay protection sequence number counter 2.1. Swarm requirements A swarm using Enhanced Closed Swarm protocol must have at least one public-private key pair. The private key is used for digitally signing peers' authorization credentials. The public key is used by the peers to verify the credentials. For the protocol to be secure, trust must be managed between the peers and the system entity owning the swarm key pair and issuing the peer authorizations. Trust can be managed in different ways. For example, swarm owner's digital certificate (and corresponding public key) can be provided to peers as a trust anchor. Peers can use the anchor to validate the swarm public key before trusting the key and using it in the ECS protocol. Alternatively, peers can obtain the swarm public key from a trusted source. Gabrijelcic Expires June 2, 2013 [Page 5] Internet-Draft ECS protocol November 2012 The most straightforward way to manage trust is to name the swarm based on content and public key(s) of the swarm. In this way the peers in the swarm are sure they are in the correct swarm since changing of the keys will change the swarm. An example that should be followed is given in Section 6, on initializing an ECS enabled swarm. 3. Authorization credential - Proof-of-Access Proof-of-access (PoA) is an authorization credential specified as follows: SWid, Ks, Kh, ET,[ R,] {SWid, Ks, Kh, ET[, R]}Ks-1 PoA contains the following information: SWid - the swarm identifier, Ks - public key of the credential issuer, Kh - public key of the credential holder, ET - PoA expiry time and R - rules to be evaluated during authorization decision provisioning. The expression in curly brackets denotes that the information presented in PoA is digitally signed with the private key of the credential issuer. Credential issuer uses PoA to authorize the key Kh to access the swarm identified with SWid for specified time till ET under rules R. The rules in the PoA are optional. In this simplest case the authorization decision using such PoA is made based on SWid only, without any granularity between authorized peers. The peer can join the swarm with SWid if it possesses valid PoA with the same SWid, otherwise it must be rejected by peers. Rules bring additional flexibility into service provisioning and enable fain grained peers authorizations. Rules specification is discussed in the next section. 3.1. Rules Rules specify access rights of a peer in a swarm. They are defined by credential issuer, usually a content provider or distributor. When a peer holding a credential contacts another peer in the swarm for a service the contacted peer must evaluate the rules and enforce the results of the evaluation. The format of the Rules field, described with the ABNF notation [RFC5234], is given below: Gabrijelcic Expires June 2, 2013 [Page 6] Internet-Draft ECS protocol November 2012 rules = [general] [per-chunk] general = conditions per-chunk = conditions conditions = condition [log-operator conditions] / "(" conditions ")" log-operator = "and" / "or" condition = variable operator value / variable operator variable operator = "=" / "!=" / "<" / "<=" / ">" / ">=" variable = 1ALPHA *99(ALPHA / DIGIT) value = 1*10DIGIT / 1*10DIGIT "." DIGIT /"'" 1*10ALPHA "'" It contains two groups of conditions: a general group and per-chunk group. The general conditions are evaluated every time the credential holder connects to another peer or can require evaluation during the entire session between peers. The per-chunk conditions are evaluated on every chunk request from the credential holder. The conditions compare a variable as defined in an environment of the peer evaluating the rules with a predefined value in the rules or another variable. The details are further explained in Section 5.2. Each group of conditions is positively evaluated only if the compound logical sentence produces as a result a positive truth value. 4. Enhanced Closed Swarm protocol The Enhanced Closed Swarm protocol starts as soon as a peer tries to join the swarm or when the peer contacts additional peer(s) to participate in content distribution. If successful, the result of the protocol is mutual authorization of both peers. If not, either of peers can issue an error message specifying the reason for failure. The protocol consists of two parts. The first is a handshake aimed at mutual authorization of two peers and the second, if the handshake was successful, providing security services for application data exchanged between the peers. 4.1. Handshake The handshake is based on challenge-response identification by public-key techniques as defined in [HAC], section 10.3.3 (ii). The handshake is defined with six messages: two in initial exchange, two in mutual authorization phase and two that are sent on failure. 4.1.1. Initial exchange The ECS protocol always begins with exchange of swarm identifiers (SWid), ECS versions (V) as used by peers and nonces (N). The exchange is presented on the following diagram: Gabrijelcic Expires June 2, 2013 [Page 7] Internet-Draft ECS protocol November 2012 Peer A (initiator) Peer B (responder) ------------------------------------------------------------------- SWid, Va, Na --> (1) <-- SWid, Vb, Nb (2) The exchange assures that the peers are in the same swarm and use compatible versions of the protocol. If peer B is not in the same swarm as peer A, peer B must terminate the communication. Error message must not be sent to the initiating peer. Nonces assure freshness of the current protocol exchange, and are used with other information to derive peers shared secrets as explained in Section 4.2.1.3. Although peer B, as responder, could already start authorization process at the initiator in the second message, the burden of the first cryptographic operation is shifted from the responder to initiator (peer A) to prevent DoS attack vector on B. 4.1.2. Mutual authorization PoAa, [RSa,] {Na, Nb, PoAa [, RSa]}Ka-1 --> (3) In the third message peer A asks for authorization. The message contains peer A's PoA (PoAa), optional information on requested service (RSa) and digitally signed peers' nonces, initiator PoA and the requested service, if any. Peer A signs this information with its private key from the same key pair as the public key embedded in the PoA (PoAa). The mesage is sent to peer B. At this point peer B verifies the digital signature of the message with A's public key embedded in PoAa (Kh), PoA's digital signature with credential issuer's public key embedded in PoAa (Ks), and validates the PoA as explained in Section 5.1. Before using the credential public key embodied in the PoA, the peer must validate if the key is among trusted swarm keys. If the verifications and validations are successful, peer B responds with the fourth message requesting authorization at peer A: <-- PoAb, [RSb,] [{Sab}Ka, ] {Na, Nb, PoAb [, RSb], {Kab}Ka}Kb-1 (4) The fourth message is the same as the third message except that the responder (peer B) may add a shared secret Sab, encrypted with the public key of peer A (Ka), to the message. If present, the encrypted shared secret is included in information to be signed and signed with the private key from the same key pair as peer B's public key embedded in the peer's PoA (PoAb). The rest of the process of verification, validation and authorization at peer A is the same as it is after message three at peer B. For message verification the Gabrijelcic Expires June 2, 2013 [Page 8] Internet-Draft ECS protocol November 2012 public key (Kh), embedded in peer B's PoAb, is used. If both peers have been successfully authorized they can start content related communication. The communication is protected by data confidentiality, integrity and origin authentication services as described in Section 4.2. [Application data] Peer A <--> Peer B 4.1.3. Authorization failure If either of digital signature verifications and the PoA validations fail, the validating peer denies access with one of the following messages: <-- PoAb, Ib, {Na, Nb, PoAb, Ib}Kb-1 (5) PoAa, Ia, {Na, Nb, PoAa, Ia}Ka-1 --> (6) The messages are structurally the same. If peer A's authorization fails at peer B, peer B sends the fifth message to peer A containing its PoAb, information about the failure and the digitally signed nonces (Na, Nb), peer B's PoA (PoAb) and failure information (Ib). The signature is calculated with the peer B's private key. The failure information must contain the reason for error and may contain a hint on how to correct the error. After sending the error message peer B stops communicating with peer A, no further data must be exchanged. Peer B should delete all ephemeral information obtained or created during the protocol exchange. If peer B's authorization fails at peer A after the message 4 the procedure is exactly the same. It has to be noted that messages 5 or 6 can be sent to the corresponding peer even in the middle of successfully started session. The reason for such behavior is related to rules (R) based access control, see Section 5.2 for details. If for any reason the peer leaves the swarm, gracefully or ungracefully the remaining peer should remove all ephemeral information obtained or created during the protocol exchange. If the peer in question at some time later will join the swarm, the ECS protocol must be repeated again for successful peers authorization. Gabrijelcic Expires June 2, 2013 [Page 9] Internet-Draft ECS protocol November 2012 4.1.4. Nonces Nonces in the ECS initial key exchange must be randomly chosen. Nonces are used to ensure freshness of the messages exchanged and to ensure freshness to the key material generation needed for application data protection as explained in Section 4.2.1.3. Nonces must be at least half the key size of the pseudorandom function as described in Section 4.2.1.3.1. If the same random number source is used for both keys and nonces, care must be taken to ensure that the latter use does not compromise the former [RFC5996]. 4.1.5. Requested service Requested service field allows the requester (peer A or peer B in this section) to request specific service from the responder. The service can be related to service level, quality of service, dedicated bandwidth, etc. The field is defined with specific service variable name and its requested value. Requested service field is described in ABNF [RFC5234] notation below: ReqService = ["(" assignment ")"] ["," ReqService] assignment = variable "," value variable = 1ALPHA *99(ALPHA / DIGIT) value = 1*10DIGIT / 1*10DIGIT "." DIGIT / "'" 1*10ALPHA "'" 4.1.6. Supported digital signature algorithms Digital signature algorithms like RSA [RSA], DSA [FIPS186-3] and ECDSA [SEC1] may be used to implement the ECS protocol. Selection of the right algorithm doesn't depend only on its strength and strict purpose. Important features to consider are the size of the keys and digital signature, as well as the algorithm performance in the target environment. This document describes the ECS protocol as well as its usage with the PPSPP protocol run over the UDP. The amount of data to encapsulate is of crucial importance for the UDP encapsulation. ECDSA key sizes are the smallest for comparable bits in security regarding the other stated digital signature protocols. As minimal common denominator the ECDSA therefore must be supported by the ECS protocol implementations. Digital signature encoding, and key requirements and encoding are presented in Section 4.1.7.2. Gabrijelcic Expires June 2, 2013 [Page 10] Internet-Draft ECS protocol November 2012 4.1.7. PoA embedding and encoding The PoA as defined in Section 3 can be quite large. When minimal, without any rules (R) specified, and ignorig other smaller size fields, it contains two public keys and a digital signature. The maximum size of the rules field is in general not specified and could be large as well. The PoA can be embedded into the protocol exchange directly or indirectly via an URL. The encapsulations of the ECS protocol must specify the PoA field with a type and PoA information: either PoA itself or URL from where the PoA can be obtained from. Implementations must support URLs that employ the http scheme [RFC2616]. URLs must be encoded according to specification [RFC3986]. The ECS protocol processing is in case of the indirect embedding extended with obtaining the PoA from a specified location. All the other procedures after obtaining the PoA are exactly as specified in Section 4.1.2. If the PoA cannot be obtained from the specified location access must be denied as specified in Section 4.1.3. The default PoA embedding types, for use in encapsulation in transport protocol, are: 0x00 Directly embedded PoA 0x01 PoA obtainable from URL 4.1.7.1. PoA encoding Every PoA field have its unique type. Each field is encoded with its type and value. Swarm identifier (SWid) must be encoded as octet string. Expiry time (ET) default encoding is standard ASN.1 universal time type UTCTime. UTCTime conventions as specified in [RFC5280], Section 4.1.2.5.1, must be followed. Rules (R) as specified in Section 3.1 must be encoded as octet string. The PoA field type identifiers for SWid, ET and R are defined as follows, together with other PoA field types that are further defined in the next section: Gabrijelcic Expires June 2, 2013 [Page 11] Internet-Draft ECS protocol November 2012 0x01 # Swarm identifier 0x02 # Swarm public key Ks 0x03 # Peer public key Kh 0x04 # Expiry time 0x05 # Rules 0x06 # Digital signature 4.1.7.2. Digital signatures and public keys The public keys Kh and Ks, and corresponding digital signature must be encoded within the PoA with its type and value. The encoding for ECDSA is as follows. 4.1.7.2.1. ECC key and ECDSA signature, encoding and requirements Peer's public keys contained in the PoA (Kh) are Eliptic Curve Cryptography (ECC) public keys. ECC public keys are defined with required values for a particular set of elliptic curve domain parameters and a key. Well-known curves define a standard set of domain parameters. For the purpose of this document well known curves as are defined in [RFC5903] should be used. The keys have the following format encoding: type # uniquely identifies well-known curve octet string # encoded elliptic curve point Every ECS protocol implementation must support the following named curves specified below, based on [RFC5903], [FIPS186-3] and [SEC] naming is provided as well, and the ECS protocol type: |------+--------------------------+-------+-----------| | Type | RFC5903 | NIST | SEC | |------+--------------------------+-------+-----------| | 0x01 | 256-Bit Random ECP Group | P-256 | secp256r1 | | 0x02 | 384-Bit Random ECP Group | P-384 | secp384r1 | | 0x03 | 521-Bit Random ECP Group | P-521 | secp521r1 | |------+--------------------------+-------+-----------| Octet string, specified in format encoding, is the ECC public key encoded from elliptic curve point into a octet string as is specified in Section 2.3.3 of [SEC1]. Point compression may be used. The default curve is 256-Bit Random ECP Group. Other well-known curves could be used. The keys as specified are used in the ECS protocol for digital signing and key establishment (ECDH, Elliptic Curve Diffie-Hellman), see Section 4.2.1.1. Note that [SP800-57-3] recommends P-256 and P-384 curves for key establishment and digital signature. Gabrijelcic Expires June 2, 2013 [Page 12] Internet-Draft ECS protocol November 2012 The ECDSA digital signature algorithm is specified in [SEC1]. The data hash algorithm must be from SHA2 family of hash functions [FIPS180-3]. The digital signature is encapsulated as follows: type # Digital signature type octet string # Signature The PoA digital signature field types are defined as follows, taking into account the [RFC4754] recommendations regarding hash algorithm: |------+-----------+--------------------------+----------------| | Type | ECDSA | Elliptic Curve Group | Hash Algorithm | |------+-----------+--------------------------+----------------| | 0x01 | ECDSA-256 | 256-Bit Random ECP Group | SHA-256 | | 0x02 | ECDSA-384 | 384-Bit Random ECP Group | SHA-384 | | 0x03 | ECDSA-521 | 521-Bit Random ECP Group | SHA-512 | |------+-----------+--------------------------+----------------| The specified digital signature and hash algorithms must be supported by the implementation. Other ECDSA digital signature types and corresponding hash algorithms could be used. The default algorithm is the ECDSA-256. A result of ECDSA signature algorithm are pair of integers r and s. The encoding of the signature should follow the procedure specified in [RFC6090], Section 6.2, for each integer. The decoding procedure is defined in Section 6.1. The signature is a concatenation of the octet strings. The integers octet string size depends on the ECDSA algorithm and hash function, the table of integers bit lengths, according to [RFC4754], is provided below: |-----------+-------------+--------------| | Digital | | | | Signature | Bit Lengths | Bit Length | | Algorithm | of r and s | of Signature | |-----------+-------------+--------------| | ECDSA-256 | 256 | 512 | | ECDSA-384 | 384 | 768 | | ECDSA-521 | 528 | 1056 | |-----------+-------------+--------------| ECC peer public keys are used in the ECS protocol for key establishment as well. The peer public keys embedded in PoAs in the same swarm must use the same well-known curve. The issuer's key (Ks, swarm key), the digital signature of the PoAs, and the peer digital signature either in message 3 or 4 of the protocol, must follow the Gabrijelcic Expires June 2, 2013 [Page 13] Internet-Draft ECS protocol November 2012 specification in this section. 4.2. Application data communication protection Application data communication between peers needs to be protected. In this section and its sub-sections the data exchanged between peers is referred as a message. For an attacker it is easy to get access to content exchanged in messages or maliciously disrupt or deceive the communication. Data confidentiality, integrity and origin authentication security services need to be provided. Encapsulation in connectionless transport protocol like UDP requires anti-replay protection as well. Encapsulations in other protocols require a check if the target protocol anti-relay mechanisms are strong enough for intended purpose and at right level of abstraction. Data confidentiality service in open communication is provided by encrypting the data in communication. Stream and block cipher algorithms are used for encrypting the data. The ECS protocol may be used with connectionless protocols so only block cipher algorithms are considered. Data confidentiality service using encryption require key establishment, described in Section 4.2.1. Data integrity and origin authentication are dependent services. Keyed hash algorithms are often used for the services provisioning. Some newer algorithms, like those described in [RFC5116], combine all three services. This document describes usage of both keyed hash and combined mode algorithms in Section 4.2.2. 4.2.1. Key establishment Key establishment is a procedure that results in keying material being shared among two peers. Key establishment depends on selection of digital signature algorithm. 4.2.1.1. Elliptic Curve Diffie-Hellman The Eliptic Curve Diffie-Hellman (ECDH) key establishment algorithm generates a shared secret from the other peer public key (lets say peer A) and a private key of the peer generating the secret (peer B). The other peer (peer A) generates the same secret from its private key and the other peer (peer B) public key. Using ECDH during the ECS protocol message exchange peer B can calculate the secret key Sab after receiving and verifying the message 3 from peer A, and peer A after receiving and verifying the message 4, see Section 4.1.2. There is no need to exchange any other additional information in the message 4; peer B must not send the shared secret Sab to peer A while using the ECDH key establishment Gabrijelcic Expires June 2, 2013 [Page 14] Internet-Draft ECS protocol November 2012 algorithm. The ECS protocol protects the ECDH algorithm against active attacks since the public keys of both peers are authenticated via message 3 and 4 digital signature verification. The ECDH algorithm is further described in [RFC6090], Section 4. For interoperability see the same document, Section 7.1. The shared secret (Sab) is compact representation of the result of the ECDH computation. The ECDH as described algorithm must be supported by ECS protocol implementations. 4.2.1.2. Note on RSA based key establishment If the RSA algorithm is used for key establishment the key needs to be exchanged directly among ECS protocol peers. Peer B generates the shared secret after receiving and validating the message 3, see Section 4.1.2, and sends the secret in the message 4, in the field Sab, encrypted with the peer A public key. The RSA algorithm is not mandatory in the current specification. The Sab ECS protocol field is reserved for possible future use. 4.2.1.3. Keying material generation For the security services provisioning a number of shared secrets between peers in communication are needed. To jointly arrive to same secrets a known pseudorandom function is needed, see Section 4.2.1.3.1, and a procedure for shared secret generation, see Section 4.2.1.3.3. The content of this section is based on TLS [RFC5246] and is only summarized here. 4.2.1.3.1. Pseudorandom function The pseudorandom function (PRF) is described in [RFC5246], Section 5. The PRF is HMAC based [RFC2104] and uses hash algorithm SHA-256. The PRF is defined as follows: PRF(secret, label, seed) = P_(secret, label || seed) The label is an ASCII string, the secret and seed are defined in Section 4.2.1.3.2 and Section 4.2.1.3.3. The P_(secret, data) function is a data expansion function that expands the secret and data as follows: P_hash(secret, seed) = HMAC_hash(secret, A(1) || seed) || HMAC_hash(secret, A(2) || seed) || HMAC_hash(secret, A(3) || seed) || ... Gabrijelcic Expires June 2, 2013 [Page 15] Internet-Draft ECS protocol November 2012 A() is defined as: A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) P_ based on SHA-256 generates 32 bytes of output data on each iteration. A number of iterations may be needed to obtain required output data size. A summary of the PRF required data sizes for supported security services algorithms is presented in Section 4.2.2.6, Table 1. 4.2.1.3.2. Master secret The master secret generation is described in [RFC5246], Section 8.1. The master secret is generated from secret key, result of key establishment as described in Section 4.2.1, and nonces exchanged in the ECS protocol initial exchange, see Section 4.1.1. master_secret = PRF(Sab, "master secret", Na || Nb) [0..47]; The notation on the end of the PRF function denotes that the master secret is exactly 48 bytes in length. The PRF function secret parameter value is Sab and the seed parameter value is concatenation of the nonces. The label parameter value is "master secret". 4.2.1.3.3. Key generation Key generation is described in [RFC5246], Section 6.3. The algorithms that provide data confidentiality, and data integrity and origin authentication separately, need 4 shared secrets: two for keyed hash computation and two for data encryption. The peers in communication (peer A and peer B) use separate shared secrets for protecting sending and receiving data traffic. The algorithms that provide all three services combined may need 4 secrets as well: two for data encryption and two for initialization vector (IV) generation. The last two secrets for IV generation are needed only if implicit nonce techniques are used as explained in Section 4.2.2.1. The shared secrets are generated as follows: key_block = PRF(master secret, "key expansion", Na || Nb); The PRF function secret parameter value is the master secret, generated as explained in previous section, the label parameter value is "key expansion" and the seed parameter value is a concatenation of Gabrijelcic Expires June 2, 2013 [Page 16] Internet-Draft ECS protocol November 2012 the nonces. A number of PRF computations depends on needed length of output data. The key_block is then partitioned as follows: peerA_write_EK[EK_length] peerB_write_EK[EK_length] peerA_write_NI[NI_length] peerB_write_NI[NI_length] peerA_write_MK[MK_length] peerB_write_MK[MK_length] Usage of the generated shared secrets and their lengths is explained in section Section 4.2.2. Note that not all the values are needed for all algorithms. The order of the partitioning is different as in [RFC5246]. 4.2.2. Security services provisioning Data confidentiality, origin authentication and integrity services in the ECS protocol must be provided through the AEAD (Authenticated Encryption with Associated Data) interface as defined in [RFC5116]. The interface hides the cryptographic details of the services design and implementation and it is suitable for wrapping both combined mode and keyed hash algorithms. The AEAD interface has two operations, authenticated encryption and authenticated decryption. The authenticated encryption has four input parameters: secret key K, nonce N, plaintext P and associated data A. There is a single output: ciphertext C or an indication that the requested operation could not be performed. A part of the ciphertext C is a tag T, providing data origin authentication and integrity services. The secret key K is a result of key establishment as explained in Section 4.2.1.3.3. The key must not be explicitly included in any other interface input. The nonce N is random and non-repeating value. It is of the same nature as the nonce as defined in Section 4.1.4, but of different value, and it could be generated in different way, see Section 4.2.2.4 for details on nonce requirements and generation. The plaintext P is application data communication message. The associated data A is data that must be authenticated and integrity protected, but does not need to be encrypted. The nonce must not be added to associated data A. It is checked internally to the AEAD algorithm. On the wire the nonce, or its explicit part, is always prepended to the ciphertext. The authenticated decryption has four inputs: K, N, A and C as defined above. It has a single output, ether a plaintext P or an indication that the inputs are not authentic. Gabrijelcic Expires June 2, 2013 [Page 17] Internet-Draft ECS protocol November 2012 This document specifies six AEAD interface compliant algorithms for the security services provisioning: two based on AES-GCM algorithm and four based on AES-CBC-HMAC-SHA algorithms. The protocol implementations must implement the first two and should implement the other four. The other four may become mandatory for implementation when their specification standardization is finalized. Other algorithms may be used if they comply to AEAD interface and fulfill the interface requirements as are specified in [RFC5116], section 4. 4.2.2.1. AEAD-AES-GCM algorithms The AEAD-AES_GCM algorithms are specified in [RFC5116]. The algorithms work as specified in [SP800-38D], using AES-128 or AES-256 block cipher. Corresponding algorithms are AEAD_AES_128_GCM, specified in the [RFC5116] section 5.1, and AEAD_AES_256_GCM, specified in the section 5.2 of the same document. The algorithms are named and have the same numeric identifier as specified in [RFC5116]. The default algorithm to be used in the ECS protocol implementation is AEAD_AES_128_GCM. The AEAD interface key K is key EK, derived as specified in Section 4.2.1.3.3. The plaintext P is entire application data communication message. The nonce N must be deterministic as specified in Section 4.2.2.4.1. The nonce N length must be 12 octets. The associated data A is anti-replay field SQ, if the service is used. 4.2.2.2. AEAD-AES-CBC-HMAC-SHA2 algorithms The AEAD-AES-CBC-HMAC-SHA2 algorithms are specified in [AEAD-AES-CBC]. The algorithms use encrypt-then-MAC method based on AES in chaining block cipher (CBC) mode encryption with random nonces, see Section 4.2.2.4.2,, and message authentication code as a keyed authentication code uses HMAC [RFC2104] with SHA hash function, truncated to 128 bits (16 octets) [RFC4868]. The [AEAD-AES-CBC] specifies four algorithms: AEAD_AES_128_CBC_HMAC_SHA_256, AEAD_AES_192_CBC_HMAC_SHA_384, AEAD_AES_256_CBC_HMAC_SHA_512 and AEAD_AES_128_CBC_HMAC_SHA1. The algorithms differ in the length of the AES key (128, 192 and 256) and corresponding SHA hash function (SHA256, SHA384, SHA512 and SHA1). The AEAD interface inputs P and A are the same as in the AEAD-AES-GCM case. The AEAD interface encryption key K is concatenation of the encryption key EK and HMAC key MK, derived as specified in Section 4.2.1.3.3. The nonce N, as an input to the AEAD interface is zero-length. The AES-CBC mode encryption requires padding of the Gabrijelcic Expires June 2, 2013 [Page 18] Internet-Draft ECS protocol November 2012 plaintext P up to the size of the AES encryption block. 4.2.2.3. Anti-replay service Application data communication messages are anti-replay protected with a sequence number. The sequence number must be 32 bits long and is transmitted explicitly with the message. The sequence number message counter of ECS protocol instance must be initialized to one at the sender and to zero at the receiver. For each transmitted message within the instance at the sender, the sequence number is increased by one. If the message anti-replay service is validated negatively the message must be discarded. The messages are discarded based on sliding receive window. The following sliding window procedure, based on [RFC4302] must be followed. The receive window size of 32 must be supported, larger window sizes may be required by target transport protocol encapsulation or chosen by the receiver. The "right" edge of the window is at the highest sequence number of the positively validated message. The messages below "left" edge of the window are rejected. The messages within the window are checked for duplicates. The positively validated message is a message for which all provided security services were validated to positive value. Only the sequence numbers of positively validated messages update the sequence numbers received and can slide the window. The pseudocode as presented in appendix section B2.3 of [RFC4302], describes an efficient sliding window algorithm implementation based on bits shifting (the "pass integrity check" code condition needs to be replaced with positive security services validation). The anti-replay service is the first security service validated for the received message matched to the ECS protocol instance, allowing fast discards based on the sliding window procedure. The sequence number transmitted with the message must be protected by data origin authentication and integrity services. It must not be confidential, therefore data confidentiality service is not provided for the sequence number. If the sequence number security services are not validated positively the entire message fails the validation and it must be discarded. 4.2.2.4. Nonce requirements and generation A basic nonce requirement is nonce value uniqueness for each AEAD interface invocation, for any fixed value of the secret key [RFC5116]. To avoid synchronization of used nonce values between two peers in communication a separate secret key is used for each direction, see Section 4.2.1.3.3. Nonce does not need to be Gabrijelcic Expires June 2, 2013 [Page 19] Internet-Draft ECS protocol November 2012 confidential. To prevent precomputation attacks at least part of the nonce should be unpredictable prior the secret key establishment. Nonces can be generated in a number of ways. Two nonce construction frameworks to be used with this specification are deterministic and random as are described in [SP800-38D]. 4.2.2.4.1. Deterministic nonces In the deterministic construction, the nonce is a concatenation of a fixed field and an invocation field. The fixed part identifies the encrypting device. The invocation part provides the nonce's uniqueness. The nonce must be 12 octets long. The fixed field NI is 8 octets long and is generated as explained in Section 4.2.1.3.3. The invocation field is 4 octets long and is a counter. The counter should start at 1. The counter value must not be reused. If the counter space is exhausted, the ECS protocol connection must terminate and a new one may be established, if needed. Since the nonce construction is deterministic and known to both the encrypting and decrypting device, only invocation part of the nonce needs to be passed from the encrypting to decrypting device. The deterministic nonce generation is compliant with AEAD specification [RFC5116] recommended nonce creation, specified in Section 3.2. Unlike the partly implicit nonces as described in Section 3.2.1, it doesn't specify fixed-distinct field as explicit. If multiple encryption devices with the same key are to be used with this specification, a separate nonce implicit part NI should be generated for each of them. Such usage is not specified in this specification. 4.2.2.4.2. Random nonces In the random construction the nonce is a concatenation of a random field and the free field. The random field must be at least 12 octets long. The free field has the same role as fixed field in the deterministic construction and may be empty. The nonce must be unpredictable to an adversary. For generating the random field values a pseudorandom generator may be used with the same level of security as the block cipher in use. The initial inputs for pseudorandom generator must not make use of encryption key or keyed hash key as specified in Section 4.2.1.3.3. Suitable pseudorandom generators are described in [SP800-90A]. The AEAD interface allows zero-length nonces as input to AEAD encryption function. In this case the AEAD implementation must provide a suitable pseudorandom generator and input for its initialization. Since the random field values are generated at Gabrijelcic Expires June 2, 2013 [Page 20] Internet-Draft ECS protocol November 2012 random their values must be passed along with the ciphertext C to the decrypting device. If the free field is used the procedure for its value generation may be know. In such case the field may not be passed along with the ciphertext. 4.2.2.5. Protected messages processing This section assumes that the initial ECS handshake as described in Section 4.1.1 and Section 4.1.2 was successful and that the keying material was generated at both peers in communication, A and B, as described in Section 4.2.1.3. The anti-replay service, as described in Section 4.2.2.3, is provided for the application data communication. Peer A assembles the application data message per the application specification. The anti-replay service sequence number counter is increased by one. Then the peer invokes the AEAD encryption interface with the following parameters, depending on the algorithm selection: - secret key K, either key EK generated as explained in Section 4.2.1.3.3 (peerA_write_EK), or concatenation of EK and MK keys (peerA_write_EK || peerA_write_MK) - nonce N, either concatenation of implicit part and explicit part (peerA_write_NI || NE), or zero-length nonce - plaintext P, application data message - and associated data, the message sequence number counter field. If the AEAD interface invocation returns ciphertext C, the message to be send to the peer is formed as: protected message = SQ || NE || C or SQ || C The protected message is sent to peer B and the sequence number counter value stored. If the AEAD interface returns an indication that the requested encryption operation could not be performed the application message is discarded. Such event should be logged at the sender. When peer B receives the message the message is disassembled. The peer must check the received sequence number, according to the procedure as described in Section 4.2.2.3. If the sequence number is not in the sequence number window or newer, the message must be discarded. If the sequence number checkes out, the peer invokes the AEAD decryption interface with the following parameters: Gabrijelcic Expires June 2, 2013 [Page 21] Internet-Draft ECS protocol November 2012 - secret key K, either key EK generated as explained in Section 4.2.1.3.3 (peerA_write_EK), or concatenation of EK and MK keys (peerA_write_EK || peerA_write_MK) - nonce N, either concatenation of implicit nonce part and explicit nonce part received in the message (peerA_write_NI || NE), or, zero-length nonce, - associated data A assembled at the peer B, in this case the sequence number received, - and ciphertext C as received in the message. If the AEAD decryption interface invocation returns plaintext P, the peer accepts the message and updates the receiving sequence number counter value. If the interface invocation returns the FAIL symbol the message must be discarded. The sequence number counter value must not be updated. Such event may be logged at the receiver. The assembly and disassembly of the security services protected message is ECS protocol encapsulation specific. Any encapsulation must clearly specify how application message and security services related information is assembled in the protected message so the message can be unambiguously disassembled at the receiver. If the length of the protected message is explicitly specified in the message, it must be included in associated data A. The procedure of sending the application message at peer B is exactly the same as at peer A. The only difference is that peer B uses its own keying material (peerB_write_EK, peerB_write_MK and peerB_write_NI, see Section 4.2.1.3.3) when sending the message, and peer A uses peer B keying material when receiving the message. Errors on processing the received messages are not fatal to the established ECS protocol between the peers. The application related communication should continue. On excessive number of errors either of the peers may terminate the connection. The ECS protocol connection, at application data communication protection level, must terminate if either of two conditions are met: the anti-replay service counter space is exhausted or, in the case of deterministic nonce generation, the nonce counter space is exhausted. The connection between peers may be reestablished, if desired. 4.2.2.6. Security services summary The algorithms used for security services provisioning are summarized in the tables below. In Table 1 the encryption key Ke, message Gabrijelcic Expires June 2, 2013 [Page 22] Internet-Draft ECS protocol November 2012 authentication code key MK and nonce implicit part NI length in octets for each algorithm is presented. These parameters' values are generated by a pseudorandom generator as defined in Section 4.2.1.3. In the fifth column the required PRF output length is specified. In the column six the total length of the PRF output is presented, according to the hash function specified in Section 4.2.1.3.3 and needed number of PRF iterations. |-------------------------------+----+----+----+----------+----------| | algorithm | EK | NI | MK | PRF req. | PRF gen. | |-------------------------------+----+----+----+----------+----------| | AEAD_AES_128_GCM | 16 | 8 | 0 | 48 | 64 | | AEAD_AES_256_GCM | 32 | 8 | 0 | 80 | 96 | | AEAD_AES_128_CBC_HMAC_SHA_256 | 16 | 0 | 32 | 96 | 96 | | AEAD_AES_192_CBC_HMAC_SHA_384 | 24 | 0 | 48 | 144 | 160 | | AEAD_AES_256_CBC_HMAC_SHA_512 | 32 | 0 | 64 | 192 | 192 | | AEAD_AES_128_CBC_HMAC_SHA1 | 16 | 0 | 20 | 72 | 96 | |-------------------------------+----+----+----+----------+----------| Table 1: Key material length and PRF data required In Table 2 the application data communication message expansion due to security services provisioning is presented. The message is expanded due to inclusion of the nonce explicit part Ne, data origin authentication and integrity tag T and anti-replay sequence field SQ in the message. The message may be expanded because of per-algorithm required padding (Pad.) of the plaintext before encryption. The padding is reported as a worst case, when the plaintext ends on 16 octets boundary. In this case the entire block of padding needs to be added which adds 16 octets to the message. On average the padded length should be 8 octets. The last column reports the maximum number of octets that may be added to the message. |-------------------------------+----+------+----+----+------| | algorithm | NE | Pad. | T | SQ | Max. | |-------------------------------+----+------+----+----+------| | AEAD_AES_128_GCM | 4 | 0 | 16 | 4 | 24 | | AEAD_AES_256_GCM | 4 | 0 | 16 | 4 | 24 | | AEAD_AES_128_CBC_HMAC_SHA_256 | 16 | 16 | 16 | 4 | 52 | | AEAD_AES_192_CBC_HMAC_SHA_384 | 16 | 16 | 24 | 4 | 60 | | AEAD_AES_256_CBC_HMAC_SHA_512 | 16 | 16 | 32 | 4 | 68 | | AEAD_AES_128_CBC_HMAC_SHA1 | 16 | 16 | 12 | 4 | 48 | |-------------------------------+----+------+----+----+------| Table 2: Application data messages expansion Gabrijelcic Expires June 2, 2013 [Page 23] Internet-Draft ECS protocol November 2012 4.3. Error messages The Enhanced Closed Swarm error messages are sent either due to fatal failures in the mutual authorization phase of the protocol, messages 3 and 4, see Section 4.1.2, or because access control decisions during the application data communication as explained in Section 5.2. For either reasons the error messages should be sent and the communication between the peers must be aborted. The error messages and their codes are as follows: 0x00 authorization failed 0x01 issuer unknown 0x02 PoA expired 0x03 service request failed The "authorization failed" message is sent by either peer A or B if the peer access control request has failed. The message is sent as well for other verification failures of the messages 3, 4 and PoA not specified in this section. The "issuer unknown" message is sent by either peer A and B if the peer verifying the other peer credentials cannot find the credential issuer (Ks) key among trusted keys of the swarm. The "PoA expired" message is sent by the peer verifying the requesting peer PoA and the PoA expiry time has been reached. The "service request failed" is sent if the messages 3 and 4 of the protocol specify the service request (Rs) and the authorizing peer access control decision has denied access. In contrast to authorization failed message (0x00) this message indicates lack of resources at the peer doing authorization. For example, the authorizing peer has no slots available for requested service level at the moment. It is possible that the slot will be available later. The "service request failed" error message can be raised during application data communication as well, due to lack of resources. The error messages should include information (I) that could help the requesting peer resolving the issues causing the failure. The implementation may log the raised failures as well the application data communication protection failures that otherwise must not be communicated among the peers. 5. Access control Initial access control decisions are made during the validation of Gabrijelcic Expires June 2, 2013 [Page 24] Internet-Draft ECS protocol November 2012 the ECS protocol message 3 at the receiver and message 4 at the initiator. First, decisions are made during PoA validation and the next can be done based on the rules (R) embedded in PoA. 5.1. PoA validation If the PoA's digital signature verification was successful, as explained in Section 4, PoA must be validated. At first the SWid of the swarm is compared to the SWid as exchanged in the first two ECS messages. If equal, the validation can continue, else, the peer owing PoA must be rejected. Next, the time validity is evaluated, if the PoA is expired, the the peer must be rejected. The ECS protocol doesn't provide any direct mechanisms for revoking PoAs. Expiry time (ET) in the PoA may be used for this purpose. But setting very short expiry time may be reasonable in the live streaming scenario only. In the streaming on demand and conventional download scenarios expiry time should be set long enough to enable the peers to upload to the swarm after the download (seeding). 5.2. Rule based access control If the PoA contains the rule field (R) the next access control step is validation of the rules. Basic access control elements are a policy, the environment, and a decision and enforcement function (DEF) [X812]. Rules represent the policy. The environment is the environment at each peer, based on which access control decisions can be made. The DEF compares the environment values with the values in the rules. If any of the rules fails, the DEF must deny access to peer's resources in question. Not all rules can be based on the environment variables derived from the peer implementation. In such case the requested service field (RS) in the ECS protocol's third or fourth message can be used to transmit extra information. If the requested service is present in the request, the receiver must insert the variable and its value in its environment for evaluation . Some of the rules can require not only an evaluation during initial phase of the ECS protocol, i.e. messages 1-4, but during the entire session among the peers. Examples are rules related to geolocation, time of usage, network location, etc., and per-chunk rules as described in Section 3.1. Such rules should be constantly validated, based on dynamic peer environment updates. If any of such rules fail the connection between the peers must be terminated, as explained in Section 4. The environment, the rules and the DEF must be aligned for the rule Gabrijelcic Expires June 2, 2013 [Page 25] Internet-Draft ECS protocol November 2012 based access control to succeed. It is meaningless for the credential issuer to specify a rule that has no counterpart in the environment and cannot be enforced in the peer implementation. If the DEF encounters a variable during the evaluation of the rules that has no counterpart in the environment, the function must return a negative response resulting in termination of the connection between the peers participating in the ECS protocol. 6. Initializing an ECS enabled swarm The ECS enabled swarm should be initialized with the swarm certificate, specifying the security services parameters. If the swarm certificate is issued the swarm identifier should be a cryptographic hash of the swarm certificate. The SHA-256 hash function must be used. Peers joining the swarm should obtain the certificate from a trusted source. Based on parameters in the certificate they should generate a key pair suitable for the swarm or reuse an existing one. If the certificate does specify a handshake signature type a corresponding key pair type must be used. Otherwise the default type must be used, see Section 4.1.7.2.1. The swarm owner should generate PoAs for the peers. The PoA must contain a public key from the peer generated key pair. 6.1. Swarm certificate The swarm certificate is a digital certificate specifying security parameters of an ECS-protocol enabled swarm. The following security parameters may be specified: - origin: origin of the swarm certificate as an URL, specified in the same way as the PoA URL in section Section 4.1.7, - creation date: the time of swarm certificate creation, in the same format as the expiry time specified in Section 4.1.7, - ECS protocol version: minimal protocol version needed to join the swarm, - swarm key type: the type of the swarm key, specified as in Section 4.1.7.2.1, Gabrijelcic Expires June 2, 2013 [Page 26] Internet-Draft ECS protocol November 2012 - swarm keys: a comma separated list of swarm keys Ks, all must be of the type as specified in the swarm key type, - handshake signature type: the type of the signature in the handshake messages, the public keys of the users must mach the type, - PoA signature type: the type of PoA signature, - and application data communication protection algorithm: a selection of data origin authentication, integrity and confidentiality service algorithm. The security parameters specification in the ABNF [RFC5234] notation is as follows: SP = [ORIGIN] [CREATION_DATE] [ECS_VERSION] [SWARM_KEY_TYPE] SWARM_KEYS [HANDSHAKE_SIGNATURE_TYPE] [ADCP_ALGORITHM] ORIGIN = http_URL ; see [RFC2616] CREATION_DATE = UTCTime ; see [RFC5280] ECS_VERSION = OCTET SWARM_KEY_TYPE = OCTET SWARM_KEYS = key [SWARM_KEYS] HANDSHAKE_SIGNATURE_TYPE = OCTET PoA_SIGNATURE_TYPE = OCTET ADCP_ALGORITHM = OCTET key = *OCTET ; see Section 4.7.2.1 The swarm certificate is then defined as follows: [SWid,] SP, {[SWid,] SP}Ks-1 The swarm certificate contains a swarm identifier, security parameters specification (SP), and digital signature, created with the private key of the swarm key pair (Ks). If the certificate is used to name the swarm the swarm identifyer itself must not be included in the certificate. Instead a content identifier should be used. If there are multiple keys listed in the specification the swarm certificate must be verifiable with the first key. If the swarm certificate is issued it must contain at least one key in the swarm keys parameter. All the other parameters are optional. If not present, the defaults are used where applicable. An example specification of security parameters is shown below, with the defaults as specified in this document (a swarm key is left out): Gabrijelcic Expires June 2, 2013 [Page 27] Internet-Draft ECS protocol November 2012 ECS_VERSION = 0x01 SWARM_KEY_TYPE = 0x01 SWARM_KEYS = key HANDSHAKE_SIGNATURE_TYPE = 0x01 PoA_SIGNATURE_TYPE = 0x01 ADCP_ALGORITHM = 0x01 7. Using ECS with PPSPP The Peer-to-Peer Streaming Peer Protocol (PPSPP) [I-D.ietf-ppsp-peer-protocol] provides a number of transport protocol options. Preferred option is transport over the UDP protocol. 7.1. ECS protocol UDP encapsulation For encapsulation of the ECS protocol in UDP and its usage with PPSPP the following two general PPSPP message types are defined: ECS_PROTOCOL = 0x0B ECS_ENCRYPTED = 0x0C The first type enables transmission of the ECS protocol messages as described in Section 4 via PPSPP and the second is used for exchange of security services protected application communication. In general most of the ECS protocol messages and fields are of variable length so every message and field is defined by its type (1 byte) and its length (2 bytes, length in bytes). The examples in the document are represented in the same hex-like two character-per-byte notation as in [I-D.ietf-ppsp-peer-protocol]. 7.1.1. ECS protocol messages ECS messages and fields as described in Section 4 are defined with the following types: ECS_SWARM_ID = 0x01 ECS_VERSION = 0x02 ECS_NONCE = 0x03 ECS_POA = 0x04 ECS_REQUESTED_SERVICE = 0x05 ECS_SHARED_SECRET = 0x06 ECS_ERROR_INFO = 0x07 ECS_SIGNATURE = 0x08 The following message is an example of initial exchange as discussed in Section 4.1.1: Gabrijelcic Expires June 2, 2013 [Page 28] Internet-Draft ECS protocol November 2012 0B 002C # ECS_PROTOCOL, length 01 0012 # ECS_SWARM_ID, length 123412341234123412341234123412341234 # Swid 02 0001 0001 # ECS_VERSION, length, 1 03 0010 # ECS_NONCE, length 8c9c54b1cbd3de261df2d341a8b7164d # Nonce 7.1.2. Initial PPSPP handshake and ECS exchange The ECS protocol initial exchange message follows the initial handshake defined in [I-D.ietf-ppsp-peer-protocol]: 00000000 # CHANNEL, 0 10 01 # VERSION 04 7FFFFFFF # HASH, binumber 1234123412341234123412341234123412341234 # root hash 00 00000011 # HANDSHAKE, peer A selected 0B 0018 # ECS_PROTOCOL, length 02 0001 0001 # ECS_VERSION, length, 1 03 0010 # ECS_NONCE, length 8c9c54b1cbd3de261df2d341a8b7164d # Nonce The SWid must be present in the first PPSPP handshake message and can be avoided in the first ECS protocol exchange message. Peer B's response, initial exchange message 2 as described in Section 4.1.1, following the initial PPSPP handshake messages can be: 00000011 # CHANNEL, 17 10 01 # VERSION 00 00000022 # CHANNEL, peer B selected 0B 0018 # ECS_PROTOCOL, length 02 0001 0001 # ECS_VERSION, length, 1 03 0010 # ECS_NONCE, length 08b3aa180c3f6b948213def673ddcded # Nonce The PPSPP specification allows additional messages to be sent already in the second datagram. However, if the ECS protocol is used no additional PPSPP messages are allowed till message 4 of the ECS protocol. In this case the ECS protocol initial exchange message should be the last message added to the UDP datagram. 7.1.3. ECS authorization The message 3 sent by peer A, see Section 4.1.2, is encoded as follows, including the PoA and digital signature of the message, the PoA and signature are artificial: Gabrijelcic Expires June 2, 2013 [Page 29] Internet-Draft ECS protocol November 2012 00000022 # CHANNEL, 34 0B 0010 # ECS_PROTOCOL, length 04 0004 aef1aef1 # ECS_PoA, length, PoAa 08 0006 # ECS_SIGNATURE, length 0001 abcdabcd # signature type, signature The message 4 is similar to the message 3. It shows the information to be signed with peer B's private key: 0s 00000011 |--| 0B 000E 04 0002 1234 08 0006 0001 3454123a |_______________________| Digitally signed Digital signature in both messages 3 and 4 covers all the fields in the ECS message except the signature itself. The length of the signature is set to all 0's for the signing and then overwritten with the right length. Conversely, for verification of the signature the length of the signature has to be overwritten with 0's before verification. 7.1.4. ECS encrypted message The ECS encrypted messages contain security services protected application data messages as defined in Section 4.2. The protected messages consists of: the ECS_ENCRYPTED field, message length, anti- replay protection sequence number counter field SQ, the explicit part of the nonce NE if present, and ciphertext C. The sequence number counter is always 4 octets long. The length of the explicit part of the nonce depends on the algorithm selected, see Section 4.2.2.6 for the security service summary. The rest of the message is ciphertext. An example of the ECS_ENCRYPTED message is given below, the algorithm used is the default, AEAD_AES_128_GCM, see Section 4.2.2.1: 0C 000C # ECS_ENCRYPTED, length 00000001 # Sequence number SQ 00000001 # Explicit part, nonce NE 23abfe08 # chipertext C The associated data A of the packet, L denotes the length of the message, is formed as follows: A = L || SQ || C The protected message is created and processed according to procedures specified in Section 4.2.2.5. All the rest of the Gabrijelcic Expires June 2, 2013 [Page 30] Internet-Draft ECS protocol November 2012 application communication messages are exactly as described in [I-D.ietf-ppsp-peer-protocol], but embedded in the protected message, except the channel information: 00000011 # Channel 17 0C 000C # ECS_ENCRYPTED, length xxxx # the protected message When the ECS_ENCRYPTED messages are created the implementations must take care that the messages fit into the target PPSPP datagram size, see [I-D.ietf-ppsp-peer-protocol], Section 9.1.1. The application data protected by security services may contain multiple PPSPP messages, as in PPSPP specification, till the specified condition is met. The ECS protocol message 4 as specified in Section 7.1.3 can be already followed by some initial light communication data, created as specified in Section 4.2.2.5 and assembled as ECS_ENCRYPTED message. If the peer B cannot be authorized by peer A based on content of the message 4, the peer should avoid decrypting the ECS_ENCRYPTED message and discard the data. Peer A must deny access and terminate the connection with error message as explained in Section 4.1.3. 7.1.5. Terminating the connection The reasons for ECS protocol connection termination and procedures to follow in such case are described in Section 4.1.3 and Section 4.2.2.5. The connection can terminate as well for other reasons as described in PPSPP specification [I-D.ietf-ppsp-peer-protocol]. After termination the ECS protocol ephemeral data should be removed. The PPSPP keep alive message should be respected. The message in UDP case consists of channel id only and is therefore not encrypted and carries no ECS protocol related messages. 8. Security Considerations This document describes the Enhanced Closed Swarm protocol, and provides guidance on its usage. Many of the security issues are discussed throughout this document. The protocol reuses a number of security mechanisms and algorithms specified in the referenced documents. These documents' security considerations are important for the ECS protocol security. Documents to be considered are the AEAD interface specification [RFC5116], partly the TLS appendix F.4 on Security of Composite Cipher Modes [RFC5246] and the note on nonces and keys in IKEv2 specification [RFC4306]. For the usage of the ECS protocol with the PPSPP protocol the security considerations Gabrijelcic Expires June 2, 2013 [Page 31] Internet-Draft ECS protocol November 2012 as described in [I-D.ietf-ppsp-peer-protocol], specifically in Section 13.1, must also be considered. In general the Enhanced Closed Swarm protocol protects both authorized peer resources and content in distribution. The content itself is not protected after being obtained by the peers and could be potentially distributed to unauthorized entities by other means. For content protection outside the distribution appropriate Digital Rights Management solutions should be used beside the ECS protocol, if needed. Authorized clients using maliciously modified implementation could leak the content to unauthorized peers already during the distribution. But such leak doesn't affect other authorized clients resources usage and could be potentially prevented by detecting the malicious clients or peers and preventing them to obtain the authorizations in the future. A basic ECS defense against denial-of-service attacks is related to the four message handshake as described in Section 4.1. The handshake shifts the first cryptographic calculation from responder, peer B, to initiator, peer A. The defense puts the peers on equal footing if the peer A really signs the third ECS protocol message and if the peer A's computational power is comparable to the peer B's. If the peer A can initiate many ECS connections to peer B and uses precomputed third response messages, peer B's computing resources could be jeopardized. To counter such and attack the peer B should keep a small state across multiple ECS instances to detect the attack and block the peer if needed. A possibility to include PoA information in the third and fourth ECS protocol message as a URL can present a security threat if the feature is misused in some potential scenarios. For example, a swarm initiator, responsible for generating PoAs for the interested peers can return a URL to the peer PoA instead of the PoA itself. If the URL points to a third party or it is maliciously crafted its usage can amplify in the swarm and can result in denial-of-service attack. The peers should validate the URLs, and obtain and validate PoAs before using URLs as references to them in the swarm. The URLs of the PoAs should be limited to the same origin as the PoAs were obtained from or from an origin the user can trust. The swarm initiators should avoid specifying large PoAs that might need to be specified as a URL and cannot be included in the protocol messages directly. 9. Rationale The ECS protocol provides access control mechanisms in distributed peer-to-peer systems. The aim of the protocol is to protect peer Gabrijelcic Expires June 2, 2013 [Page 32] Internet-Draft ECS protocol November 2012 resources and the communication channels between them against unauthorized usage. The main motivation for the protocol are lack of an open specification of the protocol functionality, and a number of use cases anticipated by service and content providers but which cannot be implement with current peer-to-peer systems. The ECS protocol provides a number of security services and mechanisms sufficient for a swarm initiator to initiate a closed swarm, provide interested peers authorization credentials (PoA) to access the swarm, enable mutual peer authentication and authorization and security protect an application communication. Unlike common Digital Rights Management systems the ECS protocol does not address the issues of protecting or limiting the access to content directly. The content itself is distributed as is, without any modifications or mechanisms that could restrict its usage after the content has been obtained. If needed, one could use additional security mechanisms and services to provide the DRM functionality along with the ECS protocol, but such mechanisms and services or interoperability with the protocol are beyond the scope of this document. The protocol is designed as simple as possible while offering enough flexibility to enable a number of usage scenarios. The protocol is swarm oriented and a swarm initiator can choose per swarm protocol security parameters and authorization rules according to its own needs. No prior relationship or common authorities are needed between interested peers and the initiator, except that every peer needs to provide the issuer a public key to join the swarm in name of which new PoA credentials can be issued. For every closed swarm the peer can use a different key pair. The protocol is designed to be used with connection and connectionless protocols like UDP and TCP and fulfilling requirements they impose. A number of security protocols related to the ECS protocol has been already specified in IETF, most notably IPsec, TLS and DTLS. For a number of reasons IPsec is not suitable for all applications [RFC5406]. The TLS protocol is suitable only for connection oriented protocols (TCP), while DTLS, as TLS modification, is suitable for datagram oriented transport (UDP). Both protocols secure data communication between applications, a client and a server. In contrast to peer-to-peer systems, in application domain TLS/DTLS are designed for, the server is a scarce resource and the clients obtain and manage the connection to the server accordingly. In peer-to-peer systems the distribution of 'client' and 'servers' is assumed to be more even. The ECS protocol simplifies obtaining, providing and managing the secure connection between peers. The protocol handshake assumes no connection or retransmission of the messages. The Gabrijelcic Expires June 2, 2013 [Page 33] Internet-Draft ECS protocol November 2012 handshake either succeeds or not. All protocol messages must fit into a single encapsulating protocol datagram. The protocol doesn't support rekeying. If the conditions for rekeying are met the protocol instance must be restarted, if needed, and no previous instance state is kept. The choice of mandatory supported security algorithms is limited to small but reasonable set. The protocol supports only one way to provide application data communication protection via the AEAD interface. The protocol doesn't support any security parameters negotiation between peers in communication. A swarm certificate is a single interface to specify swarm security parameters, controlled solely by a swarm initiator. One of the major advantages of existing IETF security protocols is their maturity. The ECS protocol has reused existing and validated solutions from TLS/DTLS, IPsec and IKEv2 wherever possible. 10. Acknowledgments The Closed Swarm protocol was initially designed by Njaal Borch et al [CS] in the P2P-Next project (http://www.p2p-next.org/), a research project supported by the European Community under its 7th Framework Programme (grant agreement no. 216217). The protocol was further extended by Vladimir Jovanovikj et al into the Enhanced Closed Swarm protocol [ECS]. Their work was partly supported by the P2P-Next project and Slovenian Research Agency. The views and conclusions contained herein are those of the author and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the P2P-Next project, the European Commission or Slovenian Research Agency. Many reviewers provided valuable comments on earlier drafts of this document. 11. References 11.1. Normative References [FIPS180-3] National Institute of Standards and Technology (NIST), "Secure Hash Standard", FIPS Publication 180-3, October 2008. [FIPS186-3] National Institute of Standards and Technology (NIST), "Digital Signature Standard", FIPS Publication 186-3, November 2008. Gabrijelcic Expires June 2, 2013 [Page 34] Internet-Draft ECS protocol November 2012 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008. 11.2. Informative References [AEAD-AES-CBC] McGrew, D. and K. Patterson, "Authenticated Encryption with AES-CBC and HMAC-SHA", draft mcgrew-aead-aes-cbc- hmac-sha2-00, June 2012. [CS] Borch, N., Michell, K., Artzen, I., and D. Gabrijelcic, "Access control to BitTorrent swarms using closed swarms", Proceedings of the 2010 ACM workshop on Advanced video streaming techniques for peer-to-peer networks and social networking AVSTP2P '10, 2010. [ECS] Jovanoviky, V., Gabrijelcic, D., Klobucar, T., and D. Gabrijelcic, "Access control in BitTottent P2P networks using the enhanced Closed Swarms protocol", Proceedings of the Fifth International Conference on Emerging Security Information, Systems and Technologies SECURWARE 2011, 2011. [HAC] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Criptography", 1997. [I-D.ietf-ppsp-peer-protocol] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to- Peer Streaming Peer Protocol (PPSPP)", draft-ietf-ppsp-peer-protocol-03 (work in progress), October 2012. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, Gabrijelcic Expires June 2, 2013 [Page 35] Internet-Draft ECS protocol November 2012 December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007. [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009. [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. [RSA] Rivest, R., Shamir, A., and L. Adelman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, v. 21, n. 2, pp. 120-126. , February 1978. [SEC] Standards for Efficient Cryptography Group, "Recommended Elliptic Curve Domain Parameters", SEC 2, September 2000. [SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1-v2, May 2009. Gabrijelcic Expires June 2, 2013 [Page 36] Internet-Draft ECS protocol November 2012 [SP800-38D] National Institute of Standards and Technology (NIST), "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, November 2007. [SP800-57-3] National Institute of Standards and Technology (NIST), "RECOMMENDATION FOR KEY MANAGEMENT, Part 3: Application- Specific Key Management Guidance", NIST Special Publication 800-57, December 2009. [SP800-90A] National Institute of Standards and Technology (NIST), "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST Special Publication 800-90A, January 2012. [X812] International Telecommunication Union - Telecommunication Standardization Sector (ITU-T), "Data networks, open system communications and security, Information technology - Open systems interconnection - Security frameworks for open systems: Access control framework", ITU-T Recomendation X.812, 1994. Author's Address Dusan Gabrijelcic Jozef Stefan Institute Jamova 39 Ljubljana, 1000 Slovenia Email: dusan@e5.ijs.si Gabrijelcic Expires June 2, 2013 [Page 37]