CDNI R. van Brandenburg
Internet-Draft TNO
Intended status: Standards Track November 2, 2015
Expires: May 5, 2016

URI Signing for HTTP Adaptive Streaming (HAS)
draft-brandenburg-cdni-uri-signing-for-has-01

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 May 5, 2016.

Copyright Notice

Copyright (c) 2015 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

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

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.

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. Enforcement Information Elements

This section specifies an additional information element that is needed to enforce the CSP distribution policy, beyond those specified in [I-D.ietf-cdni-uri-signing]:

The Path Pattern Sequence Information Element is used to restrict content access to a particular set of URLs, based on the path component of the URI on which it is available. This is primarily useful for content delivered via an HTTP Adaptive Streaming protocol using a manifest file, where it is often not known a priori which segment will be requested next.

3.2. 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]:

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 some knowledge of the structure of the HTTP Adapative Streaming content that is being requested.

In contrast with a Signed URI defined in [I-D.ietf-cdni-uri-signing], where the URI Signature is calculated over the Original URI, a Signed Token does not protect the Original URI. Instead, the Path Pattern Sequence Information 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.

Note: Although this document uses

  1. Create a new buffer for constructing the Signed Token in the steps below.
  2. Append the string "VER=2"
  3. If time window enforcement is not needed, this step can be skipped.
    1. If an information element was added to the message, append an "&" character. Append the string "ET=".
    2. 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.
    3. Convert this integer to a string and append to the message.
    4. Append an "&" character. Append the string "ETS=".
    5. 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.
    1. If an information element was added to the message, append an "&" character. Append the string "CIP=".
    2. Convert the client's IP address in dotted decimal notation format (i.e. for IPv4 address) or canonical text representation (for IPv6 address [RFC5952]) to a string and append to the message.
  5. If an information element was added to the message, append an "&" character. Append the string "PPS=".
  6. Append the value of the Path Pattern Sequence in the form of a string to the message. Note: the value of the Path Pattern Sequence element should be appropriate given the file and folder structure of the HTTP Adaptive Streaming content in question. As an example, if the Original URI for the manifest file is 'http://example.com/folder/content-83112371/manifest.xml', a suitable Path Pattern might be '*/content-83112371/*/segment????.mp4'. If the manifest file and segments are stored in different paths, it is possible to concatenate multiple Path Patterns in a single Path Pattern Sequence information element, such as '/folder/content-83112371/manifest/*.xml:*/folder/content-83112371/quality_*/segment????.mp4'.
  7. Depending on the type of key used to sign the URI, compute the message digest or digital signature for symmetric key or asymmetric keys, respectively.
    1. For symmetric key, HMAC is used.
      1. Obtain the shared key to be used for signing the URI.
      2. If the key identifier is not needed, skip this step. If an information element was added to the message, append an "&" character. 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.
      3. Optional: If the hash function for the HMAC uses the default value ("SHA-256"), skip this step. If an information element was added to the message, append an "&" character. append the string "HF=". Append the string for the new type of hash function to be used. Note one MUST use the same hash function as communicated in the original concatenated information element string or one of the allowable hash functions designated by the CDNI metadata.
      4. If an information element was added to the message, append an "&" character. 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&PPS=*/content-83112371/*/segment????.mp4&KID=example:keys:123&MD=").
      5. 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.
      6. Convert the message digest to its equivalent hexadecimal format.
      7. Append the string for the message digest (e.g. "VER=2&ET=1209422976&ETS=15&CIP=192.0.2.1&PP=*/content-83112371/*/segment????.mp4&KID=example:keys:123&MD=d6117d7db8a68bd59f6e7e3343484831acd8f23bbaa7f44b285a2f3bb6f02cfd").
    2. For asymmetric keys, EC DSA is used.
      1. Generate the EC private and public key pair. Store the EC public key in a location that's reachable for any entity that needs to validate the URI signature.
      2. If the key identifier is not needed, skip this step. If an information element was added to the message, append an "&" character. 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. "http://example.com/public/keys/123") needed by the entity to locate the shared key for validating the URI signature. Note that in the case the Key ID URI is a URL to a public key, the Key ID URI SHOULD only contain the "scheme name", "authority", and "path" parts (i.e. query string is not allowed).
      3. Optional: If the digital signature algorithm uses the default value ("EC-DSA"), skip this step. If an information element was added to the message, append an "&" character. Append the string "DSA=". Append the string denoting the new digital signature function.
      4. If an information element was added to the message, append an "&" character. Append the string "DS=". 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&PPS=*/content-83112371/*/segment????.mp4&KID=example:keys:123&DS=").
      5. 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, to reduce the length of the digital signature, and thereby the length of the Signed Token. Since SHA-1 is not used for cryptographic purposes here, the security concerns around SHA-1 do not apply.
      6. 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.
      7. Convert the digital signature to its equivalent hexadecimal format.
      8. 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&PPS=*/content-83112371/*/segment????.mp4&KID=example:keys:123&DS=r:CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24E" )

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, 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. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
  5. Append the URI Signing token to the message (e.g. "http://example.com/folder/content-83112371/manifest.xml?URISigningPackage=RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
  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.

  1. Encode the Signed Token by applying Base-64 Data Encoding [RFC4648] on the value of the Signed Token (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
  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.

  1. Encode the Signed Token by applying Base-64 Data Encoding [RFC4648] on the value of the Signed Token (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
  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&CIP=192.0.2.1&KID=example:keys:123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc482bddaf").
  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 "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 "PPS", if the information element exists. This information element is used to check whether there is a match between the path of the requested resource and the set of resources for which the Signed Token was generated. If the information element is not in the information elements string, the request is deined.
  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.
  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 "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.
  15. 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.
    1. For symmetric key, HMAC algorithm is used.
      1. 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.
      2. 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.
      3. Extract the value from the "MD" information element. This is the received message digest.
      4. Convert the message digest to binary format. This will be used to compare with the computed value later.
      5. 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=").
      6. Compute the message digest using the HMAC algorithm with the shared key and message as the two inputs to the hash function.
      7. Compare the result with the received message digest to validate the Signed URI or Signed Token. If there is no match, the request is denied.
    2. For asymmetric keys, a digital signature function is used.
      1. 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.
      2. 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.
      3. Extract the value from the "DS" information element. This is the received digital signature.
      4. Convert the digital signature to binary format. This will be used for verification later.
      5. 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=").
      6. Compute the message digest using SHA-1 (without a key) for the message.
      7. 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 URI or 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 Path Pattern Sequence Information Element, which is mandatory for Signed Tokens.

  1. If the "CIP" information element exists, validate that the request came from the same IP address as indicated in the "CIP" 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 "ET" 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 the Path Pattern Sequence 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.
    1. If an information element was added to the message, append an "&" character. Append the string "ET=".
    2. 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 message.
      4. Append the "&" character and the "ETS=" string.
      5. Append the value of the "ETS" information element in the received URI Signing Package.
    3. 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 original concatenated information element string and append it to the message.
  4. If the received URI Signing Package does not contain the "CIP" information element, skip this step.
    1. If an information element was added to the message, append an "&" character. Append the string "CIP=".
    2. Append the value of the "CIP" information element in the received URI Signing Package.
  5. If an information element was added to the message, append an "&" character. Append the string "PPS=". Append the value of the "PPS" information element in the received URI Signing Package.
  6. 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.
    1. For symmetric key, HMAC is used.
      1. Obtain the shared key to be used for signing the Signed Token.
      2. If the key identifier is not needed, skip this step. If an information element was added to the message, append an "&" character. 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.
      3. Optional: If the hash function for the HMAC uses the default value ("SHA-256"), skip this step. If an information element was added to the message, append an "&" character. append the string "HF=". Append the string for the new type of hash function to be used. Note one MUST use the same hash function as communicated in the received URI Signing Package or one of the allowable hash functions designated by the CDNI metadata.
      4. If an information element was added to the message, append an "&" character. 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&PPS=*/content-83112371/*/segment????.mp4&KID=example:keys:123&MD=").
      5. 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.
      6. Convert the message digest to its equivalent hexadecimal format.
      7. Append the string for the message digest (e.g. "VER=2&ET=1209422976&ETS=15&CIP=192.0.2.1&PPS=*/content-83112371/*/segment????.mp4&KID=example:keys:123&MD=d6117d7db8a68bd59f6e7e3343484831acd8f23bbaa7f44b285a2f3bb6f02cfd").
    2. For asymmetric keys, EC DSA is used.
      1. Generate the EC private and public key pair. Store the EC public key in a location that's reachable for any entity that needs to validate the URI signature.
      2. If the key identifier is not needed, skip this step. If an information element was added to the message, append an "&" character. 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. "http://example.com/public/keys/123") needed by the entity to locate the shared key for validating the URI signature. Note that in the case the Key ID URI is a URL to a public key, the Key ID URI SHOULD only contain the "scheme name", "authority", and "path" parts (i.e. query string is not allowed).
      3. Optional: If the digital signature algorithm uses the default value ("EC-DSA"), skip this step. If an information element was added to the message, append an "&" character. Append the string "DSA=". Append the string denoting the new digital signature function.
      4. If an information element was added to the message, append an "&" character. Append the string "DS=". 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&PPS=*/content-83112371/*/segment????.mp4&KID=example:keys:123&DS=").
      5. 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, to reduce the length of the digital signature, and thereby the length of the URI Signing Package Attribute and the resulting Signed URI. Since SHA-1 is not used for cryptographic purposes here, the security concerns around SHA-1 do not apply.
      6. 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.
      7. Convert the digital signature to its equivalent hexadecimal format.
      8. 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&PPS=*/content-83112371/*/segment????.mp4&KID=example:keys:123&DS=r:CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24E" )

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.

  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. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
  5. Append the URI Signing token to the message (e.g. "http://example.com/folder/content-83112371/manifest.xml?URISigningPackage=RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
  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. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
  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. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").
  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)", Internet-Draft draft-ietf-cdni-uri-signing-05, August 2015.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010.
[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.

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.

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