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, . [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, . 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, . 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]