CDNI R. van Brandenburg
Internet-Draft TNO
Intended status: Standards Track June 6, 2016
Expires: December 8, 2016
URI Signing for HTTP Adaptive Streaming (HAS)
draft-brandenburg-cdni-uri-signing-for-has-03
Abstract
This document defines an extension to the URI Signing mechanism
specified in [I-D.ietf-cdni-uri-signing] that allows for URI Signing
of content delivered via HTTP Adaptive Streaming protocols such as
MPEG DASH or HLS.
The proposed mechanism is applicable to both CDNI as well as single-
CDN environments.
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 8, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
van Brandenburg Expires December 8, 2016 [Page 1]
Internet-Draft CDNI URI Signing for HAS June 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. URI Signing in a non-CDNI context . . . . . . . . . . . . 4
2. URI Signing for HAS overview . . . . . . . . . . . . . . . . 4
3. Signed URI Information Elements . . . . . . . . . . . . . . . 5
3.1. Signature Computation Information Elements . . . . . . . 5
4. Creating an initial Signed Token . . . . . . . . . . . . . . 5
4.1. Calculating the URI Signature (initial Signed Token) . . 6
5. Communicating a Signed Token . . . . . . . . . . . . . . . . 10
5.1. Communicating the Signed Token via Cookie . . . . . . . . 10
5.2. Support for cross-domain redirection . . . . . . . . . . 10
6. Receiving a Signed Token . . . . . . . . . . . . . . . . . . 11
7. Validating a Signed Token . . . . . . . . . . . . . . . . . . 12
7.1. Decode URI Signing Package and Information Element
Extraction . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Signature Validation . . . . . . . . . . . . . . . . . . 14
7.3. Distribution Policy Enforcement . . . . . . . . . . . . . 16
7.4. Subsequent Signed Token Generation . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
[I-D.ietf-cdni-uri-signing] describes the concept of URI Signing and
how it can be used to provide access authorization in the case of
interconnected CDNs (CDNI). The primary goal of URI Signing is to
make sure that only authorized User Agents (UAs) are able to access
specific content, with a Content Service Provider (CSP) being able to
authorize every individual request. As noted in
[I-D.ietf-cdni-uri-signing], URI Signing is not a content protection
scheme; if a CSP wants to protect the content itself, other
mechanisms, such as DRM, are more appropriate.
For content that is delivered via an HTTP Adaptive Streaming (HAS)
protocol, such as MPEG DASH or HLS [Editor's Note: Include
reference], special provisions need to be made in order to ensure URI
Signing can be applied. In general, HAS protocols work by breaking
large objects (e.g. videos) into a sequence of small independent
chunks. Such chunks are then referenced by a separate manifest file,
which either includes a list of URLs to the chunks or specifies an
van Brandenburg Expires December 8, 2016 [Page 2]
Internet-Draft CDNI URI Signing for HAS June 2016
algorithm through which a User Agent can construct the URLs to the
chunks. Requests for chunks therefore originate from the manifest
file and, unless the URLs in the manifest file point to the CSP, are
not subjected to redirection and URI Signing. This opens up the
vulnerability of malicious User Agents sharing the manifest file and
deep-linking to the chunks.
One method for dealing with this vulnerability would be to include in
the manifest itself Signed URIs that point to the individual chunks.
There exist a number of issues with that approach. First, it
requires the CDN delivering the manifest to rewrite the manifest file
for each User Agent, which would require the CDN to be aware of the
exact HAS protocol and version used. Secondly, it would require the
expiration time of the Signed URIs to be valid for at least the full
duration of the content described by the manifest. Since it is not
uncommon for a manifest file to contain a video item of more than 30
minutes in length, this would require the Signed URIs to be valid for
a long time, thereby reducing their effectiveness and that of the URI
Signing mechanism in general. For a more detailed analysis of how
HAS protocols affect CDNI, see Models for HTTP-Adaptive-Streaming-
Aware CDNI [RFC6983].
The method defined in this document allows CDNs to use URI Signing
for HTTP Adaptive Streaming content without having to include the
Signed URIs in the manifest files themselves.
1.1. Terminology
This document uses the terminology defined in CDNI Problem Statement
[RFC6707] and [I-D.ietf-cdni-uri-signing].
In addition, the following term is used throughout this document:
o Signed Token: A set of URI Signing Information Elements protected
by a URI Signature that can be used to retrieve a pre-determined
set of resources. It can be communicated through various methods,
including the Cookie-based mechanism defined in this document. A
Signed Token differs from a Signed URI as defined in
[I-D.ietf-cdni-uri-signing] in the sense that it is self-contained
and can be communicated outside the context of a particular URL.
A sequence of Signed Tokens can be used to form a Signed Token
Chain in the case of HTTP Adaptive Streaming content.
o Signed Token Chain: A chain of Signed Tokens that are used for
subsequent access to a set of related resources in a CDN. Every
time a Signed Token is used to access a particular resource, a new
Signed Token is sent along with the resource that can be used to
request the next resource in the set. When generating a new
van Brandenburg Expires December 8, 2016 [Page 3]
Internet-Draft CDNI URI Signing for HAS June 2016
Signed Token in a Signed Token Chain, parameters are carried over
from one Signed Token to the next via URI Signing Information
Elements.
1.2. URI Signing in a non-CDNI context
While the URI Signing for HTTP Adaptive Streaming scheme defined in
this document was primarily created for the purpose of allowing URI
Signing in CDNI scenarios, e.g. between a uCDN and a dCDN or between
a CSP and a dCDN, there is nothing in the defined URI Signing scheme
that precludes it from being used in a non-CDNI context. As such,
the described mechanism could be used in a single-CDN scenario such
as shown in section 1.2 of [I-D.ietf-cdni-uri-signing] , for example
to allow a CSP that uses different CDNs to only have to implement a
single URI Signing mechanism.
2. URI Signing for HAS overview
In order to allow for effective access control of HAS content, the
URI signing scheme defined in this document is based on a mechanism
through which subsequent chunk requests can be chained together. As
part of the URI validation procedure, the CDN can generate a Signed
Token that the UA can use to do a subsequent request. More
specifically, whenever a UA successfully retrieves a chunk, it
receives, in the HTTP 2xx Successful message, a Signed Token that it
can use whenever it requests the next chunk. As long as each Signed
Token in such a Signed Token Chain is correctly validated before a
new one is generated, the chain is not broken and the User Agent can
successfully retrieve additional chunks. Given the fact that with
HAS protocols, it is usually not possible to determine a priori which
chunk will be requested next (i.e. to allow for seeking within the
content and for switching to a different quality level), the Signed
Token Chain includes a scoping mechanism that allows it to be valid
for more than one URL.
In order for this chaining of Signed Tokens to work, it is necessary
for a UA to extract the Signed Token from the HTTP 2xx Successful
message of an earlier request and use it to retrieve the next chunk.
The exact mechanism by which the client does this depends on the
exact HAS protocol and since this document is only concerned with the
generation and validation of incoming request, this process is
outside the scope of this document. However, in order to also
support legacy UAs that do not include any specific provisions for
the handling of Signed Tokens, this document does define a mechanism
using HTTP Cookies that allows such UAs to support the concept of
chained Signed Tokens without requiring any support on the UA side.
van Brandenburg Expires December 8, 2016 [Page 4]
Internet-Draft CDNI URI Signing for HAS June 2016
3. Signed URI Information Elements
This document defines additional Information Elements beyond those
defined in [I-D.ietf-cdni-uri-signing].
3.1. Signature Computation Information Elements
This section specifies additional Information Elements that may be
needed to verify and calculate a new Signed Token, in addition to the
Signature Computation Information Elements specified in
[I-D.ietf-cdni-uri-signing]:
o Expiration Time Setting (ETS) [optional for Signed Token] - An
16-bit unsigned integer (in seconds) used for setting the value of
the Expiry Time Information Element in newly generated Signed
Tokens. The Expiration Time Setting Information Element MUST NOT
be used in a Signed URI as defined in [I-D.ietf-cdni-uri-signing].
o Signed Token Transport (STT) [mandatory for Signed Token] - An
8-bit unsigned integer used for signalling the method through
which the Signed Token is transported from the CDN to the UA and
vice versa. This document only defines setting the STT
Information Element to a value of 1, which means that the Signed
Token is transported via a Cookie for both directions.
The Expiration Time Setting Information Element is used to
communicate to the CDN to which duration the Expiry Time Information
Element should be set whenever a new Signed Token is generated.
The Signed Token Transport Information Element is used to to
communicate to the CDN which method to use for transporting the
Signed Token to the UA
4. Creating an initial Signed Token
The following procedure defines the algorithm for creating the
initial Signed Token of a Signed Token Chain. Note that the process
described in this section is only performed for creating the initial
Signed Token of a particular Signed Token Chain. Subsequent Signed
Tokens forming the same Signed Token Chain are generated as part of
the URI Signature Validation process described in Section 7. The
creation of the initial Signed Token will typically be done by the
CSP the first time a particular UA requests the manifest file.
Choosing appropriate values of the Enforcement Information Elements
in the initial Signed Token requires some knowledge of the structure
of the HTTP Adapative Streaming content that is being requested.
van Brandenburg Expires December 8, 2016 [Page 5]
Internet-Draft CDNI URI Signing for HAS June 2016
In contrast with the Signed URI defined in
[I-D.ietf-cdni-uri-signing] a Signed Token MUST always contain a URI
Pattern Container Information Element instead of a Original URI
Container Information Element. The URI Pattern Container element is
used to convey the set of resources for which the particular Signed
Token is valid.
The process of generating a initial Signed Token can be divided into
two sets of steps: first, calculating the URI Signature and then,
packaging the URI Signature along with the URI Signing Information
Elements into a URI Signing Package to construct a Signed Token and
appending the Signed Token to the message. Note it is possible to
use some other algorithm and implementation as long as the same
result is achieved. An example for the Original URI,
"http://example.com/folder/content-83112371/manifest.xml", is used to
clarify the steps.
Note that although the URI Signing for HAS mechanism defined in this
document uses most of the Information Elements defined in
[I-D.ietf-cdni-uri-signing] and is fully compatible with it, to make
it easier for CDNs to distinguish between Signed Tokens and the
Signed URIs specified in [I-D.ietf-cdni-uri-signing], the URI Signing
Version field is set to '2' when Signed Token are used.
4.1. Calculating the URI Signature (initial Signed Token)
Calculate the URI Signature for use with a Signed Token by following
the procedure below.
1. Create an empty buffer for constructing the Signed Token and
performing the operations below.
2. Place the string "VER=2" in the buffer.
3. If time window enforcement is needed, perform this step.
A. Append an "&" character to the buffer. Append the string
"ET=".
B. Get the current time in seconds since epoch (as an integer).
Add the validity time (in seconds) of the initial Signed
Token as an integer.
C. Convert this integer to a string and append to the buffer.
D. Append an "&" character to the buffer. Append the string
"ETS=".
van Brandenburg Expires December 8, 2016 [Page 6]
Internet-Draft CDNI URI Signing for HAS June 2016
E. Append the Expiration Time Setting (in seconds) in the form
of a string to the message. Note: the length of the
Expiration Time Setting should be appropriate given the
segment duration of the HTTP Adaptive Streaming content in
question. As an example, if the segment duration is 10
seconds, the Expiration Time Setting should be at minimum 10
seconds, and preferably a bit more.
4. If client IP enforcement is needed, perform this step.
A. Skip this step if the Client IP Encryption Algorithm used is
the default ("AES-128"). Append the string "CEA=" to the
buffer. Append the string for the Client IP Encryption
Algorithm to be used.
B. If the Client IP Key Identifier is needed, perform this
step. Append an "&" character to the buffer. Append the
string "CKI=". Append the Client IP key identifier (e.g.
"56128239") needed by the entity to locate the shared key
for decrypting the Client IP.
C. Append an "&" character. Append the string "CIP=".
D. Convert the client's IP address in CIDR notation (dotted
decimal format for IPv4 or canonical text representation for
IPv6 [RFC5952]) to a string and encrypt it using AES-128 (in
ECB mode) or another algorithm if specified by the CEA
Information Element.
E. Convert the encrypted Client IP to its equivalent
hexadecimal format.
F. Append the value computed in the previous step to the
buffer.
5. If a Key ID Information Element is needed, perform this step.
Append an "&" character to the buffer. Append the string "KID="
in case a string-based Key ID is used, or "KID_NUM=" in case a
numerical Key ID is used. Append the key identifier (e.g.
"example:keys:123" or "56128239") needed by the entity to locate
the shared key for validating the URI signature.
6. If a symmetric shared key is used, perform this step. However,
skip this step when the hash function for the HMAC uses the
default value ("SHA-256"). Append an "&" character to the
buffer. Append the string "HF=". Append the string for the new
type of hash function to be used.
van Brandenburg Expires December 8, 2016 [Page 7]
Internet-Draft CDNI URI Signing for HAS June 2016
7. If asymmetric public/private keys are used, perform this step.
However, skip this step if the digital signature algorithm uses
the default value ("ECDSA"). Append an "&" character to the
buffer. Append the string "DSA=". Append the string for the
digital signature function.
8. Append an "&" character. Append the string "UPC=".
9. Append the value of the URI Pattern Container in the form of a
string to the buffer. Note: the value of the URI Pattern
Container element should be appropriate given the file and
folder structure of the HTTP Adaptive Streaming content in
question. As an example, if the URL to the manifest file is
'http://example.com/folder/content-83112371/manifest.xml', a
suitable URI Pattern might be '*://*/folder/content-83112371/
quality_*/segment????.mp4'. If the manifest file and segments
are stored in different paths, it is possible to concatenate
multiple URI Patterns in a single URI Pattern Container
Information Element, such as '*://*/folder/content-
83112371/manifest/*.xml;*://*/folder/content-83112371/
quality_*/segment????.mp4'.
10. Append an "&" character. Append the string "STT=". Append the
value of the Signed Token Transport IE as a string to the
buffer. In case the Cookie-based mechanism described in
Section 5 is used, this value is set to 1.
11. If symmetric keys are used, perform this step.
A. Obtain the shared key to be used for signing the Signed
Token
B. Append the string "MD=". The buffer now contains the
complete section of the Signed Token that is protected (e.g.
"VER=2&ET=1209422976&ETS=15&CIP=192.0.2.1&UPC=*://*/folder/
content-83112371/
quality_*/segment????.mp4&KID=example:keys:123&MD=").
C. Compute the message digest using the HMAC algorithm and the
default SHA-256 hash function, or another hash function if
specified by the HF Information Element, with the shared key
and message as the two inputs to the hash function.
D. Convert the message digest to its equivalent hexadecimal
format.
E. Append the string for the message digest (e.g.
"VER=2&ET=1209422976&ETS=15&CIP=192.0.2.1&UPC=*://*/folder/
van Brandenburg Expires December 8, 2016 [Page 8]
Internet-Draft CDNI URI Signing for HAS June 2016
content-83112371/quality_*/segment????.mp4&KID=example:keys:
123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb97220212
0dc482bddaf").
12. If asymmetric public/private keys are used, perform this step.
A. Obtain the private key to be used for signing the Signed
Token.
B. Append the string "DS=". The message now contains the
complete section of the Signed Token that is protected.
(e.g.
"VER=2&ET=1209422976&ETS=15&CIP=192.0.2.1&UPC=*://*/folder/
content-83112371/
quality_*/segment????.mp4&KID=example:keys:123&DS=").
C. Compute the message digest using SHA-1 (without a key) for
the message. Note: The digital signature generated in the
next step is calculated over the SHA-1 message digest,
instead of over the cleartype message. This is done to
reduce the length of the digital signature and the resulting
Signed URI. Since SHA-1 is not used for cryptographic
purposes here, the security concerns around SHA-1 do not
apply.
D. Compute the digital signature, using the EC-DSA algorithm by
default or another algorithm if specified by the DSA
Information Element, with the private EC key and message
digest (obtained in previous step) as inputs.
E. Convert the digital signature to its equivalent hexadecimal
format.
F. Append the string for the digital signature. In the case
where EC-DSA algorithm is used, this string contains the
values for the 'r' and 's' parameters, delimited by ':'
(e.g.
"VER=2&ET=1209422976&ETS=15&CIP=192.0.2.1&UPC=*://*/folder/
content-83112371/quality_*/segment????.mp4&KID=example:keys:
123&DS=r:CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03
F59F1E005668D:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC
8AA71331A929A29EA24E")
13. The buffer now contains the complete Signed Token. The Signed
Token is packaged and transported to the UA as defined in
Section 5
van Brandenburg Expires December 8, 2016 [Page 9]
Internet-Draft CDNI URI Signing for HAS June 2016
5. Communicating a Signed Token
The following steps describe the mechanism used for transporting a
Signed Token to a UA as part of an HTTP 2xx Successful message or an
HTTP 3xx Redirection message. The steps below assume the value of
the Signed Token Transport (STT) Information Element has been set to
1. Other values of STT are out of scope of this document.
5.1. Communicating the Signed Token via Cookie
The Signed Token is communication to the UA via HTTP Cookies. By
using standard HTTP Cookies, current UAs do not need to be adapted
for them to work with the Signed Token Chain mechanism described in
this document.
1. Encode the Signed Token by applying Base-64 Data Encoding
[RFC4648] on the value of the Signed Token.
2. Add a 'URISigningPackage' cookie to the HTTP 2xx Successful along
with the content being returned to the UA, or to the HTTP 3xx
Redirection message in case the UA is redirected to a different
server. Set the value of the Cookie to the Base-64 encoded
Signed Token obtained in the previous step.
5.2. Support for cross-domain redirection
For security purposes, use of cross-domain cookies is not supported
in some application environments. Because of this, the Cookie-based
method for transport of the Signed Token described in the previous
section might break if used in combination with a HTTP 3xx
Redirection response where the target URL is in a different domain.
To allow for this scenario, the steps below SHOULD be used in such
cases instead of the process defined in Section 5.1. They MUST NOT
be used in combination with HTTP 2xx Successful messages. Note that
the process described below only works in cases where both the
manifest file and segments constituting the HTTP Adaptive Streaming
content are delivered from the same domain. In other words, any
redirection between different domains needs to be carried out while
retrieving the manifest file.
1. Copy the entire Original URI into a buffer to hold the message.
2. Check if the Original URI already contains a query string. If
not, append a "?" character. If yes, append an "&" character.
3. Append the parameter name used to indicate the URI Signing
Package Attribute, as communicated via the CDNI Metadata
interface or set by configuration, followed by an "=". If none
van Brandenburg Expires December 8, 2016 [Page 10]
Internet-Draft CDNI URI Signing for HAS June 2016
is communicated by the CDNI Metadata interface or set by
configuration, it defaults to "URISigningPackage". For example,
if the CDNI Metadata interface specifies "SIG", append the string
"SIG=" to the message.
4. Encode the Signed Token by applying Base-64 Data Encoding
[RFC4648] on the value of the Signed Token.
5. Append the URI Signing token to the message (e.g.
"http://example.com/folder/content-83112371/manifest.xml?URISigni
ngPackage=VkVSPTImYW1wO0VUPTEyMDk0MjI5NzYmYW1wO0VUUz0xNSZhbXA7Q0l
QPTE5Mi4wLjIuMSZhbXA7VVBDPSo6Ly8qL2ZvbGRlci9jb250ZW50LTgzMTEyMzcx
L3F1YWxpdHlfKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6M
TIzJmFtcDtNRD0xZWNiMTQ0NmE2NDMxMzUyYWFiMGZiNmUwZGNhMzBlMzAzNTY1OT
NhOTdhY2I5NzIyMDIxMjBkYzQ4MmJkZGFm").
6. Place the message in the Location header of the HTTP 3xx
Redirection message returned to the UA.
6. Receiving a Signed Token
The following steps describe the mechanism used for receiving a
Signed Token as part of an HTTP GET request. The steps below assume
the value of the Signed Token Transport (STT) Information Element has
been set to 1 and the mechanism described in Section 5 has been used
to send the Signed Token to the UA. Other values of STT are out of
scope of this document.
1. Check if the query string component of the received URI contains
the 'URISigningPackage' attribute. If there are multiple
instances of this attribute, the first one is used and the
remaining ones are ignored. This ensures that the Signed Token
can be validated despite a client appending another instance of
the URI Signing Package attribute. If the 'URISigningPackage'
attribute is present, the Signed Token was sent to the UA as part
of a cross-domain HTTP 3xx Redirection message. Extract the
value of the 'URISigningPackage' attribute and use that as the
URI Signing Package for the Signed Token validation procedure
defined in Section 7.
2. If the query string component of the received URI does not
contain the 'URISigningPackage' attribute, check if the HTTP
request contains a 'URISigningPackage' cookie and use that as the
URI Signing Package for the Signed Token validation procedure
defined in Section 7.
3. If the request does not contain the 'URISigningPackage' query
string attribute, does not contain a URISigningPackage cookie,
van Brandenburg Expires December 8, 2016 [Page 11]
Internet-Draft CDNI URI Signing for HAS June 2016
and the server doesn't support values of STT other than '1', the
request is denied.
7. Validating a Signed Token
The process of validating a Signed Token can be divided into four
sets of steps: 1) Decode URI Signing Package and extract the URI
Signing Information Elements, 2) Validate the signature of the Signed
Token to ensure its integrity, 3) Validate the Enforcement
Information Elements to ensure proper enforcement of the distribution
policy, and 4) Generate a subsequent Signed Token and communicate it
to the UA.
In the algorithm below, the integrity of the Signed Token is
confirmed before distribution policy enforcement because validation
procedure would detect the right event when the URI is tampered with.
Note it is possible to use some other algorithm and implementation as
long as the same result is achieved.
7.1. Decode URI Signing Package and Information Element Extraction
Decode the URI Signing Package obtained as defined in Section 6 and
extract the URI Signing Information Elements. Note that some steps
are to be skipped if the corresponding URI Signing Information
Elements are not embedded in the Signed Token.
1. Decode the URI Signing Package using Base-64 Data Encoding
[RFC4648] to obtain all the URI Signing Information Elements in
the form of a concatenated string (e.g.
"VER=2&ET=1209422976&ETS=15&CIP=192.0.2.1&UPC=*://*/folder/
content-83112371/quality_*/segment????.mp4&KID=example:keys:123&
MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc482bd
daf").
2. Extract the value from "VER" if the Information Element exists.
Determine the version of the URI Signing algorithm used to
process the Signed URI or Signed Token. If the CDNI Metadata
interface is used, check to see if the used version of the URI
Signing algorithm is among the allowed set of URI Signing
versions specified by the metadata. If this is not the case,
the request is denied. If the Information Element is not in the
Information Elements string, then it is assumed to be set to
'1'. In that case, the Signed URI validation mechanism
specified in [I-D.ietf-cdni-uri-signing] should be followed
instead of the Signed Token mechanism defined in this document.
3. If the value of the "VER" Information Element is set to a value
unequal to '2', the URI Signing Package refers to a different
van Brandenburg Expires December 8, 2016 [Page 12]
Internet-Draft CDNI URI Signing for HAS June 2016
version of URI Signing and the algorithm specified in this
section shouldn't be used.
4. Extract the value from "MD" if the Information Element exists.
The existence of this Information Element indicates a symmetric
key is used.
5. Extract the value from "DS" if the Information Element exists.
The existence of this Information Element indicates an
asymmetric key is used.
6. If neither the "MD" or "DS" attribute exists, then no URI
Signature exists and the request is denied. If both the "MD"
and the "DS" Information Elements are present, the Signed Token
is considered to be malformed and the request is denied.
7. Extract the value from "UPC". If the Information Element
doesn't exist, the Signed Token is considered to be malformed
and the request is denied.
8. Extract the value from "CIP" if the Information Element exists.
The existence of this Information Element indicates content
delivery is enforced based on client IP address.
9. Extract the value from "ET" if the Information Element exists.
The existence of this Information Element indicates content
delivery is enforced based on time.
10. Extract the value from the "KID" or "KID_NUM" Information
Element if they exist. The existence of either of these
Information Elements indicates a key can be referenced. If both
the "KID" and the "KID_NUM" Information Elements are present,
the Signed Token is considered to be malformed and the request
is denied.
11. Extract the value from the "HF" Information Element if it
exists. The existence of this Information Element indicates a
different hash function than the default.
12. Extract the value from the "DSA" Information Element if it
exists. The existence of this Information Element indicates a
different digital signature algorithm than the default.
13. Extract the value from the "CEA" Information Element if it
exists. The existence of this Information Element indicates a
different Client IP Encryption Algorithm than the default.
van Brandenburg Expires December 8, 2016 [Page 13]
Internet-Draft CDNI URI Signing for HAS June 2016
14. Extract the value from the "CKI" Information Element if it
exists. The existence of this Information Element indicates a
key can be referenced using which the Client IP was encrypted.
15. Extract the value from "STT". If the Information Element
doesn't exist, the Signed Token is considered to be malformed
and the request is denied. If STT is equal to '1', the Cookie-
based transport mechanism defined in Section 5 is used for
returning the new Signed Token. If STT is unequal to '1', the
new Signed Token is transported via a method that is not defined
by this document.
16. Extract the value from "ETS" if the Information Element exists.
This Information Element indicates the validity time of the next
Signed Token in the chain.
7.2. Signature Validation
Validate the URI Signature of the Signed Token.
1. Copy the decoded URI Signing Package into a new buffer to hold
the message for performing the operations below.
2. Based on the presenence of either the MD or DS Information
Element in the decoded Signed Token, validate the message digest
or digital signature for symmetric or asymmetric keys,
respectively.
3.
A. For MD, an HMAC algorithm is used.
a. If either the "KID" or "KID_NUM" Information Element
exists, validate that the key identifier is in the
allowable KID set as listed in the CDNI metadata or
configuration. The request is denied when the key
identifier is not allowed. If neither the "KID" or
"KID_NUM" Information Element is present in the received
URI Signing Package, obtain the shared key via CDNI
metadata or configuration.
b. If the "HF" Information Element exists, validate that the
hash function is in the allowable "HF" set as listed in
the CDNI metadata or configuration. The request is
denied when the hash function is not allowed. If the
"HF" Information Element is not in the received URI
Signing Package, the default hash function is SHA-256.
van Brandenburg Expires December 8, 2016 [Page 14]
Internet-Draft CDNI URI Signing for HAS June 2016
c. Convert the extracted value of the MD element to binary
format. This will be used to compare with the computed
value later.
d. Remove the value part of the "MD" Information Element
(but not the '=' character) from the buffer. The message
is ready for validation of the message digest (e.g. "VER
=2&ET=1209422976&ETS=15&CIP=192.0.2.1&UPC=*://*/folder/
content-83112371/
quality_*/segment????.mp4&KID=example:keys:123&MD=").
e. Compute the message digest using the HMAC algorithm with
the shared key and message as the two inputs to the hash
function.
f. Compare the result with the received message digest to
validate the Signed Token. If there is no match, the
request is denied.
B. For DS, a digital signature function is used.
a. If either the "KID" or "KID_NUM" Information Element
exists, validate that the key identifier is in the
allowable KID set as listed in the CDNI metadata or
configuration. The request is denied when the key
identifier is not allowed. If neither the "KID" or
"KID_NUM" Information Element is present in the received
URI Signing Package, obtain the public key via CDNI
metadata or configuration.
b. If the "DSA" Information Element exists, validate that
the digital signature algorithm is in the allowable "DSA"
set as listed in the CDNI metadata or configuration. The
request is denied when the DSA is not allowed. If the
"DSA" Information Element is not in the received URI
Signing Package, the default DSA is EC-DSA.
c. Convert the extracted value of the DS element to binary
format. This will be used for verification later.
d. Remove the value part of the "DS" Information Element
(but not the '=' character) from the message. The
message is ready for validation of the digital signature
(e.g. "VER=2&ET=1209422976&ETS=15&CIP=192.0.2.1&UPC=*://
*/folder/content-83112371/
quality_*/segment????.mp4&KID=http://example.com/public/
keys/123&DS=").
van Brandenburg Expires December 8, 2016 [Page 15]
Internet-Draft CDNI URI Signing for HAS June 2016
e. Compute the message digest using SHA-1 (without a key)
for the message.
f. Verify the digital signature using the digital signature
function (e.g. EC-DSA) with the public key, received
digital signature, and message digest (obtained in
previous step) as inputs. This validates the Signed
Token. If signature is determined to be invalid, the
request is denied.
7.3. Distribution Policy Enforcement
Note that some of the steps below are to be skipped if the
corresponding URI Signing Information Elements are not in the
received URI Signing Package. The absence of a given Enforcement
Information Element indicates enforcement of its purpose is not
necessary in the CSP's distribution policy. The exception is the URI
Pattern Container Information Element, which is mandatory for Signed
Tokens.
1. If the "CIP" Information Element does not exist, this step can be
skipped.
A. Obtain the key for decrypting the Client IP, as indicated by
the Client IP Key Index Information Element or set via
configuration.
B. Decrypt the encrypted Client IP address communicated through
the Client IP Information Element using AES-128, or the
algorithm specified by the Client IP Encryption Algorithm
Information Element.
C. Verify, using CIDR matching, that the request came from an IP
address within the range indicated by the decrypted Client IP
Information Element. If the IP address is incorrect, the
request is denied.
2. If the "ET" Information Element exists, validate that the request
arrived before expiration time based on the Expiration Time
Information Element. If the time expired, the request is denied.
3. Validate that the requested resource is in the allowed set by
matching the received URI against each of the URI Patterns in the
URI Pattern Container Information Element until a match is found.
If there is no match, the request is denied.
van Brandenburg Expires December 8, 2016 [Page 16]
Internet-Draft CDNI URI Signing for HAS June 2016
7.4. Subsequent Signed Token Generation
The following steps describe how to generate a subsequent Signed
Token in a Signed Token Chain. Note that the process for generating
an initial Signed Token is described in Section 4 and the process
below is used for generating all subsequent tokens after the initial
one.
1. Create a new buffer for constructing the new Signed Token in the
steps below.
2. Append the string "VER=2"
3. If the received URI Signing Package contains the "ET"
Information Element, perform this step.
A. Append an "&" character to the buffer. Append the string
"ET=".
B. If the received URI Signing Package contains the "ETS"
Information Element, perform this step.
1. Get the value of the "ETS" Information Element and
convert it to an integer.
2. Get the current time in seconds sinds epoch (as an
integer) and add the value of the "ETS" Information
Element as seconds.
3. Convert the result to a string and append it to the
buffer.
4. Append the "&" character and the "ETS=" string to the
buffer.
5. Append the value of the "ETS" Information Element in the
received URI Signing Package to the buffer.
C. If the received Signed Token does not contain the "ETS"
Information Element, perform this step. Get the value of
the "ET" Information Element from the received URI Signing
Package and append it to the buffer.
4. If the received URI Signing Package contains the "CIP"
Information Element, perform this step.
van Brandenburg Expires December 8, 2016 [Page 17]
Internet-Draft CDNI URI Signing for HAS June 2016
A. Append an "&" character to the buffer. Append the string
"CIP=". Append the value of the "CIP" Information Element
in the received URI Signing Package.
B. If the received URI Signing Package contains the "CEA"
Information Element, perform this step. Append an "&"
character to the buffer. Append the string "CEA=" to the
buffer. Append the value of the "CEA" Information Element
in the received URI Signing Package.
C. If the received URI Signing Package contains the "CKI"
Information Element, perform this step. Append an "&"
character to the buffer. Append the string "CKI=". Append
the value of the "CKI" Information Element in the received
URI Signing Package.
5. If a Key ID Information Element is needed, perform this step.
Append an "&" character to the buffer. Append the string "KID="
in case a string-based Key ID is used, or "KID_NUM=" in case a
numerical Key ID is used. Append the key identifier (e.g.
"example:keys:123" or "56128239") needed by the entity to locate
the shared key for validating the URI signature.
6. If symmetric keys are used, perform this step. If the hash
function for the HMAC uses the default value ("SHA-256"), this
step can be skipped. Append an "&" character to the buffer.
Append the string "HF=". Append the string for the new type of
hash function to be used.
7. If asymmetric keys are used, perform this step. If the digital
signature algorithm uses the default value ("EC-DSA"), this step
can be skipped. Append an "&" character to the buffer. Append
the string "DSA=". Append the string for the digital signature
function.
8. Append an "&" character to the buffer. Append the string
"UPC=". Append the value of the "UPC" Information Element in
the received URI Signing Package.
9. Append an "&" character to the buffer. Append the string
"STT=". Append the value of the "STT" Information Element in
the received URI Signing Package.
10. Depending on the type of key used to sign the received Signed
Token, compute the message digest or digital signature for
symmetric key or asymmetric keys, respectively.
A. If asymmetric keys are used, this step can be skipped.
van Brandenburg Expires December 8, 2016 [Page 18]
Internet-Draft CDNI URI Signing for HAS June 2016
1. Obtain the shared key to be used for signing the Signed
Token.
2. Append an "&" character to the buffer. Append the
string "MD=". The message now contains the complete set
of URI Signing Information Elements over which the URI
Signature is computed (e.g. "VER=2&ET=1209422976&ETS=15
&CIP=192.0.2.1&UPC=*://*/folder/content-83112371/
quality_*/segment????.mp4&KID=example:keys:123&MD=").
3. Compute the message digest using the HMAC algorithm and
the default SHA-256 hash function, or another hash
function if specified by the HF Information Element,
with the shared key and message as the two inputs to the
hash function.
4. Convert the message digest to its equivalent hexadecimal
format.
5. Append the string for the message digest to the buffer
(e.g. "VER=2&ET=1209422976&ETS=15&CIP=192.0.2.1&UPC=*:/
/*/folder/content-83112371/quality_*/segment????.mp4&KID
=example:keys:123&MD=d6117d7db8a68bd59f6e7e3343484831acd
8f23bbaa7f44b285a2f3bb6f02cfd").
B. If symmetric keys are used, this step can be skipped.
1. Obtain the private key to be used for signing the Signed
Token.
2. Append the string "DS=". The message now contains the
complete section of the Signed Token that is protected.
(e.g. "VER=2&ET=1209422976&ETS=15&CIP=192.0.2.1&UPC=*:/
/*/folder/content-83112371/
quality_*/segment????.mp4&KID=example:keys:123&DS=").
3. Compute the message digest using SHA-1 (without a key)
for the message. Note: The digital signature generated
in the next step is calculated over the SHA-1 message
digest, instead of over the cleartype message. This is
done to reduce the length of the digital signature and
the resulting Signed URI. Since SHA-1 is not used for
cryptographic purposes here, the security concerns
around SHA-1 do not apply.
4. Compute the digital signature, using the EC-DSA
algorithm by default or another algorithm if specified
by the DSA Information Element, with the private EC key
van Brandenburg Expires December 8, 2016 [Page 19]
Internet-Draft CDNI URI Signing for HAS June 2016
and message digest (obtained in previous step) as
inputs.
5. Convert the digital signature to its equivalent
hexadecimal format.
6. Append the string for the digital signature. In the
case where EC-DSA algorithm is used, this string
contains the values for the 'r' and 's' parameters,
delimited by ':' (e.g. "VER=2&ET=1209422976&ETS=15&CIP=
192.0.2.1&UPC=*://*/folder/content-83112371/quality_*/se
gment????.mp4&KID=example:keys:123&DS=r:CFB03EDB33810AB6
C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D:s:57ED0
E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA
24E")
11. The buffer now contains the complete Signed Token. The Signed
Token is packaged and transported to the UA as defined in
Section 5
8. IANA Considerations
[Editor's note: TO DO]
9. References
9.1. Normative References
[I-D.ietf-cdni-uri-signing]
Leung, K., Faucheur, F., Brandenburg, R., Downey, B., and
M. Fisher, "URI Signing for CDN Interconnection (CDNI)",
draft-ietf-cdni-uri-signing-07 (work in progress), April
2016.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>.
van Brandenburg Expires December 8, 2016 [Page 20]
Internet-Draft CDNI URI Signing for HAS June 2016
9.2. Informative References
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection (CDNI)",
RFC 6983, DOI 10.17487/RFC6983, July 2013,
<http://www.rfc-editor.org/info/rfc6983>.
Author's Address
Ray van Brandenburg
TNO
Anna van Buerenplein 1
Den Haag 2595DC
the Netherlands
Phone: +31 88 866 7000
Email: ray.vanbrandenburg@tno.nl
van Brandenburg Expires December 8, 2016 [Page 21]