[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force                           D. Gabrijelcic
Internet-Draft                                    Jozef Stefan Institute
Intended status: Informational                              June 2, 2013
Expires: December 4, 2013

                     Enhanced Closed Swarm protocol


   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 December 4, 2013.

Copyright Notice

   Copyright (c) 2013 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 December 4, 2013                [Page 1]

Internet-Draft                ECS protocol                     June 2013

   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  PoA encoding . . . . . . . . . . . . . . . . . . . 11  Digital signatures and public keys . . . . . . . . 12
     4.2.  Application data communication protection  . . . . . . . . 14
       4.2.1.  Key establishment  . . . . . . . . . . . . . . . . . . 14  Elliptic Curve Diffie-Hellman  . . . . . . . . . . 14  Note on RSA based key establishment  . . . . . . . 15  Keying material generation . . . . . . . . . . . . 15
       4.2.2.  Security services provisioning . . . . . . . . . . . . 17  AEAD-AES-GCM algorithms  . . . . . . . . . . . . . 18  AEAD-AES-CBC-HMAC-SHA2 algorithms  . . . . . . . . 18  Anti-replay service  . . . . . . . . . . . . . . . 19  Nonce requirements and generation  . . . . . . . . 19  Protected messages processing  . . . . . . . . . . 21  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 December 4, 2013                [Page 2]

Internet-Draft                ECS protocol                     June 2013

       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
   Appendix A.  Revision history  . . . . . . . . . . . . . . . . . . 37
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37

Gabrijelcic             Expires December 4, 2013                [Page 3]

Internet-Draft                ECS protocol                     June 2013

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

   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",
   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 December 4, 2013                [Page 4]

Internet-Draft                ECS protocol                     June 2013

   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 December 4, 2013                [Page 5]

Internet-Draft                ECS protocol                     June 2013

   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

3.  Authorization credential - Proof-of-Access

   Proof-of-access (PoA) is an authorization credential specified as

   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 December 4, 2013                [Page 6]

Internet-Draft                ECS protocol                     June 2013

   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

   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 December 4, 2013                [Page 7]

Internet-Draft                ECS protocol                     June 2013

   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  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 December 4, 2013                [Page 8]

Internet-Draft                ECS protocol                     June 2013

   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

                              <--    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

   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 December 4, 2013                [Page 9]

Internet-Draft                ECS protocol                     June 2013

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  Nonces
   must be at least half the key size of the pseudorandom function as
   described in Section  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

   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

Gabrijelcic             Expires December 4, 2013               [Page 10]

Internet-Draft                ECS protocol                     June 2013

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  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, must be followed.

   Rules (R) as specified in Section 3.1 must be encoded as octet

   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 December 4, 2013               [Page 11]

Internet-Draft                ECS protocol                     June 2013

   0x01              # Swarm identifier
   0x02              # Swarm public key Ks
   0x03              # Peer public key Kh
   0x04              # Expiry time
   0x05              # Rules
   0x06              # Digital signature  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.  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  Note
   that [SP800-57-3] recommends P-256 and P-384 curves for key
   establishment and digital signature.

Gabrijelcic             Expires December 4, 2013               [Page 12]

Internet-Draft                ECS protocol                     June 2013

   The ECDSA digital signature algorithm is specified in [SEC1].  The
   data hash algorithm must be from SHA2 family of hash functions

   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 December 4, 2013               [Page 13]

Internet-Draft                ECS protocol                     June 2013

   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.  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 December 4, 2013               [Page 14]

Internet-Draft                ECS protocol                     June 2013


   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.  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.  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, and a procedure for shared secret generation, see
   Section  The content of this section is based on TLS
   [RFC5246] and is only summarized here.  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_<hash>(secret, label || seed)

   The label is an ASCII string, the secret and seed are defined in
   Section and Section

   The P_<hash>(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 December 4, 2013               [Page 15]

Internet-Draft                ECS protocol                     June 2013

   A() is defined as:

   A(0) = seed
   A(i) = HMAC_hash(secret, A(i-1))

   P_<hash> 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, Table 1.  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)

   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".  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  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 December 4, 2013               [Page 16]

Internet-Draft                ECS protocol                     June 2013

   the nonces.  A number of PRF computations depends on needed length of
   output data.  The key_block is then partitioned as follows:


   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

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  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 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 December 4, 2013               [Page 17]

Internet-Draft                ECS protocol                     June 2013

   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.  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  The plaintext P is entire application data
   communication message.  The nonce N must be deterministic as
   specified in Section  The nonce N length must be 12
   octets.  The associated data A is anti-replay field SQ, if the
   service is used.  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,, 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:
   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  The nonce N, as an input to the AEAD interface is
   zero-length.  The AES-CBC mode encryption requires padding of the

Gabrijelcic             Expires December 4, 2013               [Page 18]

Internet-Draft                ECS protocol                     June 2013

   plaintext P up to the size of the AES encryption block.  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.  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  Nonce does not need to be

Gabrijelcic             Expires December 4, 2013               [Page 19]

Internet-Draft                ECS protocol                     June 2013

   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].  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
   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.  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  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 December 4, 2013               [Page 20]

Internet-Draft                ECS protocol                     June 2013

   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.  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  The anti-replay service, as described
   in Section, is provided for the application data

   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

   -  secret key K, either key EK generated as explained in
      Section (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

   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  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 December 4, 2013               [Page 21]

Internet-Draft                ECS protocol                     June 2013

   -  secret key K, either key EK generated as explained in
      Section (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 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.  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 December 4, 2013               [Page 22]

Internet-Draft                ECS protocol                     June 2013

   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
   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 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 December 4, 2013               [Page 23]

Internet-Draft                ECS protocol                     June 2013

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 December 4, 2013               [Page 24]

Internet-Draft                ECS protocol                     June 2013

   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 December 4, 2013               [Page 25]

Internet-Draft                ECS protocol                     June 2013

   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

   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 key type: the type of the swarm key, specified as in

Gabrijelcic             Expires December 4, 2013               [Page 26]

Internet-Draft                ECS protocol                     June 2013

   -  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

   -  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:

   ORIGIN = http_URL ; see [RFC2616]
   CREATION_DATE = UTCTime ; see [RFC5280]
   key = *OCTET ; see Section

   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 December 4, 2013               [Page 27]

Internet-Draft                ECS protocol                     June 2013

   ECS_VERSION = 0x01
   SWARM_KEY_TYPE = 0x01
   SWARM_KEYS = key

7.  Using ECS with PPSPP

   The Peer-to-Peer Streaming Peer Protocol (PPSPP)
   [I-D.ietf-ppsp-peer-protocol] supports a number of transport
   protocols.  Preferred transfer protocol is UDP.

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 = 0x14             (Msg Type 20)
   ECS_ENCRYPTED = 0x15            (Msg Type 21)

   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 ECS protocol values and
   messages as specified are serialized as is defined in PPSPP
   specification, Section 8.2.  Further examples in the document are
   represented in the same hex-like two character-per-byte notation as
   in the PPSPP specification.

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_ERROR_INFO = 0x07

   The following message is an example of initial exchange as discussed

Gabrijelcic             Expires December 4, 2013               [Page 28]

Internet-Draft                ECS protocol                     June 2013

   in Section 4.1.1:

   14 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 the PPSPP specification, Section 8.4:

   00000000                                 # CHANNEL, 0
   00 00000011                              # HANDSHAKE, CHANNEL
   v=01 si=....                             # HANDSHAKE options
   14 0018                                  # ECS_PROTOCOL, length
   02 0001 0001                             # ECS_VERSION, length, 1
   03 0010                                  # ECS_NONCE, length
   8c9c54b1cbd3de261df2d341a8b7164d         # Nonce

   The SWid must be present as an option in PPSPP handshake message and
   can be avoided in the first ECS protocol exchange message.  For other
   handshake message options see the PPSPP specification, Section 7.

   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
   00 00000022                              # HANDSHAKE, CHANNEL
   v=01 si=....                             # HANDSHAKE options
   14 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 first exchanged datagrams, see Section 3.1 and 8.4 of the protocol
   specification.  However, if the ECS protocol is used no additional
   PPSPP messages are allowed till message 4 of the ECS protocol, see
   Section 7.1.4 for details.

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 December 4, 2013               [Page 29]

Internet-Draft                ECS protocol                     June 2013

   00000022                                 # CHANNEL, 34
   14 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:

   00000011                |--|
   14 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

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 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

   15 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  All the rest of the

Gabrijelcic             Expires December 4, 2013               [Page 30]

Internet-Draft                ECS protocol                     June 2013

   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
   15 000C                                # ECS_ENCRYPTED, length
   .......                                # 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 8.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 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  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
   as described in [I-D.ietf-ppsp-peer-protocol], specifically in

Gabrijelcic             Expires December 4, 2013               [Page 31]

Internet-Draft                ECS protocol                     June 2013

   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

9.  Rationale

   The ECS protocol provides access control mechanisms in distributed
   peer-to-peer systems.  The aim of the protocol is to protect peer
   resources and the communication channels between them against

Gabrijelcic             Expires December 4, 2013               [Page 32]

Internet-Draft                ECS protocol                     June 2013

   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

   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
   handshake either succeeds or not.  All protocol messages must fit

Gabrijelcic             Expires December 4, 2013               [Page 33]

Internet-Draft                ECS protocol                     June 2013

   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

11.  References

11.1.  Normative References

              National Institute of Standards and Technology (NIST),
              "Secure Hash Standard", FIPS Publication 180-3,
              October 2008.

              National Institute of Standards and Technology (NIST),
              "Digital Signature Standard", FIPS Publication 186-3,
              November 2008.

Gabrijelcic             Expires December 4, 2013               [Page 34]

Internet-Draft                ECS protocol                     June 2013

   [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

              McGrew, D. and K. Patterson, "Authenticated Encryption
              with AES-CBC and HMAC-SHA", draft mcgrew-aead-aes-cbc-
              hmac-sha2-01, October 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,

   [HAC]      Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
              of Applied Criptography", 1997.

              Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-
              Peer Streaming Peer Protocol (PPSPP)",
              draft-ietf-ppsp-peer-protocol-06 (work in progress),
              February 2013.

   [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 December 4, 2013               [Page 35]

Internet-Draft                ECS protocol                     June 2013

              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 December 4, 2013               [Page 36]

Internet-Draft                ECS protocol                     June 2013

              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.

              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.

              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.

Appendix A.  Revision history

   -00  Initial version

   -01  Minor revision

      +   Updates the ECS protocol UDP encapusulation, Section 7.1,
          according to the PPSPP protocol draft version -06

      +   Additional small clarifications in the same encapsulation

Gabrijelcic             Expires December 4, 2013               [Page 37]

Internet-Draft                ECS protocol                     June 2013

Author's Address

   Dusan Gabrijelcic
   Jozef Stefan Institute
   Jamova 39
   Ljubljana,   1000

   Email: dusan@e5.ijs.si

Gabrijelcic             Expires December 4, 2013               [Page 38]