Internet DRAFT - draft-brandenburg-cdni-uri-signing-for-has
draft-brandenburg-cdni-uri-signing-for-has
CDNI R. van Brandenburg
Internet-Draft TNO
Intended status: Standards Track March 9, 2016
Expires: September 10, 2016
URI Signing for HTTP Adaptive Streaming (HAS)
draft-brandenburg-cdni-uri-signing-for-has-02
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 September 10, 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 September 10, 2016 [Page 1]
Internet-Draft CDNI URI Signing for HAS March 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
4.2. Packaging the URI Signature (initial Signed Token) . . . 10
4.2.1. Communicating the Signed Token in a HTTP 3xx
Redirection message . . . . . . . . . . . . . . . . . 10
4.2.2. Communicating the Signed Token in a HTTP 2xx
Successful message . . . . . . . . . . . . . . . . . 11
4.2.2.1. Header-based . . . . . . . . . . . . . . . . . . 11
4.2.2.2. Cookie-based . . . . . . . . . . . . . . . . . . 11
5. Validating a Signed Token . . . . . . . . . . . . . . . . . . 12
5.1. Information Element Extraction . . . . . . . . . . . . . 12
5.2. Signature Validation . . . . . . . . . . . . . . . . . . 14
5.3. Distribution Policy Enforcement . . . . . . . . . . . . . 16
5.4. Subsequent Signed Token Generation . . . . . . . . . . . 17
5.4.1. Calculating the URI Signature (subsequent Signed
Token) . . . . . . . . . . . . . . . . . . . . . . . 17
5.4.2. Packaging the URI Signature (subsequent Signed Token) 20
5.4.2.1. Communicating the Signed Token in a HTTP 3xx
Redirection message . . . . . . . . . . . . . . . 20
5.4.2.2. Communicating the Signed Token in a HTTP 2xx
Successful message . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
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
van Brandenburg Expires September 10, 2016 [Page 2]
Internet-Draft CDNI URI Signing for HAS March 2016
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
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 via a URL, an HTTP
Header or a Cookie. A Signed Token differs from a Signed URI as
defined in [I-D.ietf-cdni-uri-signing] in the sense that it is
van Brandenburg Expires September 10, 2016 [Page 3]
Internet-Draft CDNI URI Signing for HAS March 2016
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.
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 the 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 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 legacy
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 September 10, 2016 [Page 4]
Internet-Draft CDNI URI Signing for HAS March 2016
3. Signed URI Information Elements
This document defines a few additional Information Elements beyond
those defined in [I-D.ietf-cdni-uri-signing].
3.1. Signature Computation Information Elements
This section specifies two 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 URI Signing Cookie Flag (USCF) [optional for Signed Token] - The
presence of this flag indicates the URI Signing Information
Elements contents of the URI Signing Package Attribute are
communicated via the Cookie header of the HTTP request instead of
via the query string component of the URI. The URI Signing Cookie
Flag MUST NOT be used in a Signed URI as defined 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].
The URI Signing Cookie Flag Information Element is used to indicate
the contents of the URI Signing Package attribute is communicated via
the Cookie header of the HTTP request instead of via the query string
component of the URI. The primary use case for this is the case
where the chained Signed Token mechanism is used in combination with
legacy UAs.
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.
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 chain. Subsequent Signed Tokens forming
the same chain are generated as part of the URI Signature Validation
process described in Section 5. 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
van Brandenburg Expires September 10, 2016 [Page 5]
Internet-Draft CDNI URI Signing for HAS March 2016
some knowledge of the structure of the HTTP Adapative Streaming
content that is being requested.
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 not needed, this step can be
skipped.
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 of the initial Signed Token in seconds
as an integer.
C. Convert this integer to a string and append to the buffer.
van Brandenburg Expires September 10, 2016 [Page 6]
Internet-Draft CDNI URI Signing for HAS March 2016
D. Append an "&" character to the buffer. Append the string
"ETS=".
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 not needed, this step can be
skipped.
A. If the Client IP Encryption Algorithm used is the default
("AES-128"), this step can be skipped. 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 not needed, this step can
be skipped. 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 not needed, this step can be
skipped. 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.
van Brandenburg Expires September 10, 2016 [Page 7]
Internet-Draft CDNI URI Signing for HAS March 2016
6. If asymmetric keys are used, this step can be skipped. 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 symmetric keys are used, this step can be skipped. 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. Append the string "UPC=".
9. Append the value of the URI Pattern Container in the form of a
string to the message. 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. If support for legacy clients using the URI Signing Cookie Flag
is not used, this step can be skipped. Append an "&" character.
Append the string "USCF=1"
11. If asymmetric keys are used, this step can be skipped.
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.
van Brandenburg Expires September 10, 2016 [Page 8]
Internet-Draft CDNI URI Signing for HAS March 2016
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/
content-83112371/quality_*/segment????.mp4&KID=example:keys:
123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb97220212
0dc482bddaf").
12. If symmetric keys are used, this step can be skipped.
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")
van Brandenburg Expires September 10, 2016 [Page 9]
Internet-Draft CDNI URI Signing for HAS March 2016
13. The buffer now contains the complete Signed Token.
4.2. Packaging the URI Signature (initial Signed Token)
The following steps depend on whether the Signed Token is
communicated to the UA via an HTTP 3xx Redirection message or via an
HTTP 2xx Successful message. In the case of a redirection response,
the Signed Token can be communicated as part of the query string
component of the URL signalled via the Location header of the
Redirection message. In the case of a 2xx Successful message, the
Signed Token can be communicated via either a dedicated header or,
for legacy UAs, via the Set-Cookie header.
4.2.1. Communicating the Signed Token in a HTTP 3xx Redirection message
The following steps describe how the Signed Token can be communicated
to the UA via an HTTP 3xx Redirection message.
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
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 (e.g. "VkVSPTImYW1wO0
VUPTEyMDk0MjI5NzYmYW1wO0VUUz0xNSZhbXA7Q0lQPTE5Mi4wLjIuMSZhbXA7VVB
DPSo6Ly8qL2ZvbGRlci9jb250ZW50LTgzMTEyMzcxL3F1YWxpdHlfKi9zZWdtZW50
Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD0xZWNiMTQ0N
mE2NDMxMzUyYWFiMGZiNmUwZGNhMzBlMzAzNTY1OTNhOTdhY2I5NzIyMDIxMjBkYz
Q4MmJkZGFm").
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").
van Brandenburg Expires September 10, 2016 [Page 10]
Internet-Draft CDNI URI Signing for HAS March 2016
6. Place the message in the Location header of the HTTP 3xx
Redirection message returned to the UA.
4.2.2. Communicating the Signed Token in a HTTP 2xx Successful message
The following steps describe how the Signed Token can be communicated
to the UA via an HTTP 2xx Successful message.
4.2.2.1. Header-based
The following steps are used in case the UA is expected to implement
a mechanisms for extracting the Signed Token from the dedicated URI
Signing HTTP Header and place in the query string component of the
next request. If the URI Signing Package does NOT contain the "USCF"
Information Element, the new Signed Token SHALL be communicated via
the following method.
1. Encode the Signed Token by applying Base-64 Data Encoding
[RFC4648] on the value of the Signed Token (e.g. "VkVSPTImYW1wO0
VUPTEyMDk0MjI5NzYmYW1wO0VUUz0xNSZhbXA7Q0lQPTE5Mi4wLjIuMSZhbXA7VVB
DPSo6Ly8qL2ZvbGRlci9jb250ZW50LTgzMTEyMzcxL3F1YWxpdHlfKi9zZWdtZW50
Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD0xZWNiMTQ0N
mE2NDMxMzUyYWFiMGZiNmUwZGNhMzBlMzAzNTY1OTNhOTdhY2I5NzIyMDIxMjBkYz
Q4MmJkZGFm").
2. Place the value of the encoded Signed Token in the URI Signing
Header of the HTTP 2xx Successful message of the content being
returned to the UA. Note: The HTTP Header name to use is
communicated via the CDNI Metadata Interface or set via
configuration. Otherwise, it defaults to 'URISigningPackage'.
4.2.2.2. Cookie-based
The following steps are used in combination with legacy UAs that do
not support a dedicated URI Signing HTTP header. If the received URI
Signing Package contains the "USCF" Information Element, the new
Signed Token MUST be communicated via the following method.
1. Encode the Signed Token by applying Base-64 Data Encoding
[RFC4648] on the value of the Signed Token (e.g. "VkVSPTImYW1wO0
VUPTEyMDk0MjI5NzYmYW1wO0VUUz0xNSZhbXA7Q0lQPTE5Mi4wLjIuMSZhbXA7VVB
DPSo6Ly8qL2ZvbGRlci9jb250ZW50LTgzMTEyMzcxL3F1YWxpdHlfKi9zZWdtZW50
Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD0xZWNiMTQ0N
mE2NDMxMzUyYWFiMGZiNmUwZGNhMzBlMzAzNTY1OTNhOTdhY2I5NzIyMDIxMjBkYz
Q4MmJkZGFm").
van Brandenburg Expires September 10, 2016 [Page 11]
Internet-Draft CDNI URI Signing for HAS March 2016
2. Add a 'URISigningPackage' cookie to the HTTP 2xx Successful
message of the content being returned to the UA, with the value
set to the encoded Signed Token.
5. Validating a Signed Token
The process of validating a Signed Token can be divided into four
sets of steps: first, extraction of the URI Signing information
elements, then validation of the URI signature to ensure the
integrity of the Signed Token, validation of the information elements
to ensure proper enforcement of the distribution policy, and finally,
generating a subsequent Signed Token and communicating 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.
5.1. Information Element Extraction
Extract the information elements embedded in the Signed URI or Signed
Token. Note that some steps are to be skipped if the corresponding
URI Signing Information Elements are not embedded in the Signed URI
or Signed Token.
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 query string
component of the received URI does not contain the URI Signing
Package attribute, check if the HTTP request contains a
'URISigningPackage' cookie and use that as the URI Signing
Package in the following steps. If the request does not contain
the URI Signing Package query string attribute and does not
contain a URISigningPackage cookie, the request is denied.
2. 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").
van Brandenburg Expires September 10, 2016 [Page 12]
Internet-Draft CDNI URI Signing for HAS March 2016
3. 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.
4. If this value of the "VER" information element is set to a value
unequal to '2', the URI Signing Package refers to a different
version of URI Signing and the algorithm specified in this
section shouldn't be used.
5. Extract the value from "MD" if the information element exists.
The existence of this information element indicates a symmetric
key is used.
6. Extract the value from "DS" if the information element exists.
The existence of this information element indicates an
asymmetric key is used.
7. 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 URI is
considered to be malformed and the request is denied.
8. Extract the value from "UPC" if the information element exists.
The existence of this information element indicates content
delivery is enforced based on a (set of) URI pattern(s).
9. 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.
10. Extract the value from "ET" if the information element exists.
The existence of this information element indicates content
delivery is enforced based on time.
11. 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 URI is considered to be malformed and the request is
denied.
van Brandenburg Expires September 10, 2016 [Page 13]
Internet-Draft CDNI URI Signing for HAS March 2016
12. 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.
13. 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.
14. 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.
15. 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.
16. Extract the value from "USCF" if the information element exists.
The existence of this information element indicates cookie-based
communication for legacy UAs should be used for signalling the
next Signed Token in case a HTTP 2xx Succcessful message is sent
to the user.
17. 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.
5.2. Signature Validation
Validate the URI Signature of the Signed Token.
1. Create a new buffer for validating the Signed Token in the steps
below.
2. Copy the decoded contents of the Signed Token in the buffer.
3. Depending on the type of key used to create the Signed Token,
validate the message digest or digital signature for symmetric
key or asymmetric keys, respectively.
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
van Brandenburg Expires September 10, 2016 [Page 14]
Internet-Draft CDNI URI Signing for HAS March 2016
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.
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 message. The
message is ready for validation of the message digest
(e.g. "://example.com/content.mov?VER=2&ET=1209422976&CIP
=192.0.2.1&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.
van Brandenburg Expires September 10, 2016 [Page 15]
Internet-Draft CDNI URI Signing for HAS March 2016
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. "://example.com/content.mov?VER=2&ET=1209422976&CIP
=192.0.2.1&KID=http://example.com/public/keys/123&DS=").
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.
5.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.
van Brandenburg Expires September 10, 2016 [Page 16]
Internet-Draft CDNI URI Signing for HAS March 2016
3. Validate that the requested resource is in the allowed set by
matching the received URI against the URI Pattern Container
information element. If there is no match, the request is
denied.
5.4. Subsequent Signed Token Generation
The following steps describe how to generate a subsequent Signed
Token in a chain of Signed Tokens. 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.
The process of generating a subsequent 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 new
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.
5.4.1. Calculating the URI Signature (subsequent Signed Token)
Calculate the URI Signature for use with the new Signed Token by
following the procedure below.
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 does not contain the "ET"
information element, skip this step.
A. Append an "&" character to the buffer. Append the string
"ET=".
B. If the received URI Signing Package does not contain the
"ETS" information element, skip 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.
van Brandenburg Expires September 10, 2016 [Page 17]
Internet-Draft CDNI URI Signing for HAS March 2016
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 URI Signing Package 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 does not contain the "CIP"
information element, skip this step.
A. If an information element was added to the message, append
an "&" character. Append the string "CIP=".
B. Append the value of the "CIP" information element in the
received URI Signing Package.
5. If a Key ID information element is not needed, this step can be
skipped. 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 asymmetric keys are used, this step can be skipped. 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 symmetric keys are used, this step can be skipped. 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.
van Brandenburg Expires September 10, 2016 [Page 18]
Internet-Draft CDNI URI Signing for HAS March 2016
9. If the received URI Signing Package does not contain the "USCF"
information element, skip this step. Append an "&" character to
the buffer. Appent the string "USCF=1".
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.
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
van Brandenburg Expires September 10, 2016 [Page 19]
Internet-Draft CDNI URI Signing for HAS March 2016
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
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")
5.4.2. Packaging the URI Signature (subsequent Signed Token)
The following steps depend on whether the Signed Token is
communicated to the UA via an HTTP 3xx Redirection message or via an
HTTP 2xx Successful message. In the case of a redirection response,
the Signed Token can be communicated as part of the query string
component of the URL signalled via the Location header of the
Redirection message. In the case of a 2xx Successful message, the
Signed Token can be communicated via either a dedicated HTTP header
or, for legacy UAs, via the Set-Cookie header. If the received URI
Signing Package contains the "USCF" Information Element, the new
Signed Token MUST be communicated via the Cookie method. If the
received URI Signing Package does NOT contain the "USCF" Information
Element, the new Signed Token SHALL be communicated via the dedicated
HTTP header.
5.4.2.1. Communicating the Signed Token in a HTTP 3xx Redirection
message
The following steps describe how the new Signed Token can be
communicated to the UA via an HTTP 3xx Redirection message.
van Brandenburg Expires September 10, 2016 [Page 20]
Internet-Draft CDNI URI Signing for HAS March 2016
1. Copy the target URI of the HTTP 3xx Redirection message into a
buffer to hold the message.
2. Check if the 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, followed by an "=". If none is communicated by the
CDNI Metadata interface, 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 (e.g. "RVQ9MTIwOTQyMj
k3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQ
tODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6
MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmM
jNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
5. Append the URI Signing token to the message (e.g.
"http://example.com/folder/content-83112371/manifest.xml?URISigni
ngPackage=RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4
xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1w
O0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2Z
TdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
6. Place the message in the Location header of the HTTP 3xx
Redirection message returned to the UA.
5.4.2.2. Communicating the Signed Token in a HTTP 2xx Successful
message
The following steps describe how the new Signed Token can be
communicated to the UA via an HTTP 2xx Successful message.
5.4.2.2.1. Header-based
If the received URI Signing Package does NOT contain the "USCF"
Information Element, the new Signed Token SHALL be communicated via
the following method.
1. Encode the Signed Token by applying Base-64 Data Encoding
[RFC4648] on the value of the Signed Token (e.g. "RVQ9MTIwOTQyMj
k3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQ
tODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6
MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmM
jNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
van Brandenburg Expires September 10, 2016 [Page 21]
Internet-Draft CDNI URI Signing for HAS March 2016
2. Place the value of the encoded Signed Token in the URI Signing
Header of the HTTP 2xx Successful message of the content being
returned to the UA. Note: The HTTP Header name to use is
communicated via the CDNI Metadata Interface or set via
configuration. Otherwise, it defaults to 'URISigningPackage'.
5.4.2.2.2. Cookie-based
If the received URI Signing Package contains the "USCF" Information
Element, the new Signed Token MUST be communicated via the following
method.
1. Encode the Signed Token by applying Base-64 Data Encoding
[RFC4648] on the value of the Signed Token (e.g. "RVQ9MTIwOTQyMj
k3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQ
tODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6
MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmM
jNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
2. Add a 'URISigningPackage' cookie to the HTTP 2xx Successful
message of the content being returned to the UA, with the value
set to the encoded Signed Token.
6. IANA Considerations
[Editor's note: TO DO]
7. References
7.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-06 (work in progress),
December 2015.
[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>.
van Brandenburg Expires September 10, 2016 [Page 22]
Internet-Draft CDNI URI Signing for HAS March 2016
[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>.
7.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 September 10, 2016 [Page 23]
