Internet DRAFT - draft-ppsp-gabrijelcic-ecs
draft-ppsp-gabrijelcic-ecs
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
draft-ppsp-gabrijelcic-ecs-01
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 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
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 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
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 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
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 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
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 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 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 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
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 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 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 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
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 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
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 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
[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 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.
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 December 4, 2013 [Page 14]
Internet-Draft ECS protocol June 2013
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_<hash>(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_<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 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 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:
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 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.
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 December 4, 2013 [Page 18]
Internet-Draft ECS protocol June 2013
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 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].
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 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.
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 December 4, 2013 [Page 21]
Internet-Draft ECS protocol June 2013
- 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 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 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 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 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 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
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 December 4, 2013 [Page 27]
Internet-Draft ECS protocol June 2013
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] 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_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
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:
0s
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
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:
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 4.2.2.5. 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 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
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
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
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
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
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
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 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
[AEAD-AES-CBC]
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,
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-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
[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.
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
section
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
Slovenia
Email: dusan@e5.ijs.si
Gabrijelcic Expires December 4, 2013 [Page 38]
