URI Signing for CDN Interconnection (CDNI)

This document uses the terminology defined in CDNI Problem Statement . This document also uses the terminology of Keyed-Hashing for Message Authentication (HMAC) including the following terms (reproduced here for convenience): MAC: message authentication code. HMAC: Hash-based message authentication code (HMAC) is a specific construction for calculating a MAC involving a cryptographic hash function in combination with a secret key. HMAC-SHA1: HMAC instantiation using SHA1 as the cryptographic hash function. HMAC-MD5: HMAC instantiation using MD5 as the cryptographic hash function. In addition, the following terms are used throughout this document: URI Signature: Message digest or digital signature that is computed with an algorithm for protecting the URI. Original URI: The URI before URI Signing is applied. Signed URI: Any URI that contains a URI signature. Target CDN URI: Embedded URI created by the CSP to direct UA towards the Upstream CDN. The Target CDN URI can be signed by the CSP and verified by the Upstream CDN. Redirection URI: URI created by the Upstream CDN to redirect UA towards the Downstream CDN. The Redirection URI can be signed by the Upstream CDN and verified by the Downstream CDN. In a cascaded CDNI scenario, there can be more than one Redirection URI.

The next section provides an overview of how URI Signing works in a CDNI environment. As background information, URI Signing is first explained in terms of a single CDN delivering content on behalf of a CSP. A CSP and CDN are assumed to have a trust relationship that enables the CSP to authorize access to a content item by including a set of attributes in the URI before redirecting a UA to the CDN. Using these attributes, it is possible for a CDN to check an incoming content request to see whether it was authorized by the CSP (e.g. based on the UA's IP address or a time window). Of course, the attributes need to be added to the URI in a way that prevents a UA from changing the attributes, thereby leaving the CDN to think that the request was authorized by the CSP when in fact it wasn't. For this reason, a URI Signing mechanism includes in the URI a message digest or digital signature that allows a CDN to check the authenticity of the URI. The message digest or digital signature can be calculated based on a shared secret between the CSP and CDN or using CSP's asymmetric public/private key pair, respectively. Figure 1, shown below, presents an overview of the URI Signing mechanism in the case of a CSP with a single CDN. When the UA browses for content on CSP's website (#1), it receives HTML web pages with embedded content URIs. Upon requesting these URIs, the CSP redirects to a CDN, creating a Target CDN URI (#2) (alternatively, the target CDN URI itself is embedded in the HTML). The Target CDN URI is the signed URI which may include the IP address of the UA and/or a time window and always contains the URI signature which is generated by the CSP using the shared secret or a private key. Once the UA receives the response with the embedded URI, it sends a new HTTP request using the embedded URI to the CDN (#3). Upon receiving the request, the CDN checks to see if the Signed URI is authentic by verifying the URI signature. In addition, it checks whether the IP address of the HTTP request matches that in the Signed URI and if the time window is still valid. After these values are confirmed to be valid, the CDN delivers the content (#4).

-------- / \ | CSP |< * * * * * * * * * * * \ / Trust * -------- relationship * ^ | * | | * 1. Browse | | 2. Signed * for | | URI * content | | * | v v +------+ 3. Signed URI -------- | User |----------------->/ \ | Agent| | CDN | | |<-----------------\ / +------+ 4. Content -------- Delivery

In a CDNI environment, URI Signing operates the same way in the initial steps #1 and #2 but the later steps involve multiple CDNs in the process of delivering the content. The main difference from the single CDN case is a redirection step between the Upstream CDN and the Downstream CDN. In step #3, UA may send HTTP request or DNS request. Depending on whether HTTP-based or DNS-based request routing is used, the Upstream CDN responds by directing the UA towards the Downstream CDN using either a Redirection URI (which is a Signed URI generated by the Upstream CDN) or a DNS reply, respectively (#4). Once the UA receives the response, it sends the Redirection URI/Target CDN URI to the Downstream CDN (#5). The received URI is validated by the Downstream CDN before delivering the content (#6). This is depicted in the figure below. Note: The CDNI call flows are covered in Detailed URI Signing Operation.

+-------------------------+ |Request Redirection Modes| +-------------------------+ | a) HTTP | | b) DNS | +-------------------------+ -------- / \< * * * * * * * * * * * * * * | CSP |< * * * * * * * * * * * * \ / Trust * * -------- relationship * * ^ | * * | | 2. Signed * * 1. Browse | | URI in * * for | | HTML * * content | | * * | v 3.a)Signed URI v * +------+ b)DNS request -------- * Trust | User |----------------->/ \ * relationship | Agent| | uCDN | * (optional) | |<-----------------\ / * +------+ 4.a)Redirection URI------- * ^ | b)DNS Reply ^ * | | * * | | Trust relationship * * | | * * 6. Content | | 5.a)Redirection URI * * delivery | | b)Signed URI(after v v | | DNS exchange) -------- | +---------------------->/ \ [May be | | dCDN | cascaded +--------------------------\ / CDNs] -------- +-----------------------------------------+ | Key | Asymmetric | Symmetric | +-----------------------------------------+ |HTTP |Public key (uCDN)|Shared key (uCDN)| |DNS |Public key (CSP) |Shared key (CSP) | +-----------------------------------------+ The trust relationships between CSP, Upstream CDN, and Downstream CDN have direct implications for URI Signing. In the case shown in Figure 2, the CDN that the CSP has a trust relationship with is the Upstream CDN. The delivery of the content may be delegated to the Downstream CDN, which has a relationship with the Upstream CDN but may have no relationship with the CSP. In CDNI, there are two methods for request routing: DNS-based and HTTP-based. For DNS-based request routing, the Signed URI (i.e. Target CDN URI) provided by the CSP reaches the Downstream CDN directly. In the case where the Downstream CDN does not have a trust relationship with the CSP, this means that only an asymmetric public/private key method can be used for computing the URI signature because the CSP and Downstream CDN are not able to exchange symmetric shared secret keys. Since the CSP is unlikely to have relationships with all the Downstream CDNs that are delegated to by the Upstream CDN, CSP may choose to allow the Authoritative CDN to redistribute the shared key to a subset of their Downstream CDNs . For HTTP-based request routing, the Signed URI (i.e. Target CDN URI) provided by the CSP reaches the Upstream CDN. After this URI has been verified to be correct by the Upstream CDN, the Upstream CDN creates and signs a new Redirection URI to redirect the UA to the Downstream CDN. Since this new URI also has a new URI signature, this new signature can be based around the trust relationship between the Upstream CDN and Downstream CDN, and the relationship between the Downstream CDN and CSP is not relevant. Given the fact that such a relationship between Upstream CDN and Downstream CDN always exists, both asymmetric public/private keys and symmetric shared secret keys can be used for URI Signing. Note that the signed Redirection URI needs to maintain the same level of security as the original Signed URI.

The concept behind URI Signing is based on embedding in the Target CDN URI/Redirection URI the CDNI attributes that can be validated to ensure the UA has legitimate access to the content. The CDNI attribute(s) are appended to the original URI. NOTE: If the UA or another entity needs to add one or more attributes to the Signed URI for purposes other than URI Signing, those attribute MUST be appended after the CDNI URI Signing attributes discussed in this document. Any attributes appended in such way after the URI signature has been calculated are not validated for the purpose of content access authorization. Note that adding any such attributes to the Signed URI before the CDNI URI Signing attributes will cause the URI Signing validation to fail. For the purposes of the URI signing mechanism described in this document, four types of attributes may be embedded in the URI: Enforcement Attributes: Attributes that are used to enforce a distribution policy defined by the CSP. Examples of enforcement attributes are IP address of the UA and time window. Signature Computation Attributes: Attributes that are used by the CDN to verify the URI signature embedded in the received URI. In order to verify a URI signature, the CDN requires some attributes that describe how the URI signature was generated. Examples of Signature Computation Attributes include the used HMAC's hash function and/or the key identifier. URI Signature Attributes: The attribute that carries the actual message digest or digital signature representing the URI signature used for checking the integrity and authenticity of the URI. URI Signing Package Attribute: The attribute that encapsulates all the other URI Signing attributes in an encoded format. When this attribute is used, it is the only URI Signing attribute that is exposed in the Signed URI. Two types of keys can be used for URI Signing: asymmetric keys and symmetric keys. Asymmetric keys are based on a public/private key pair mechanism and always contain a private key only known to the CDN (or CSP) signing the URI and a public key for the verification of the Signed URI. Regardless of the type of key used, the entity that validates the URI has to obtain the key. There are very different requirements for key distribution (out of scope of this document) with asymmetric keys and with symmetric keys. Key distribution for symmetric keys requires confidentiality to prevent another party from getting access to the key, since it could then generate valid Signed URIs for unauthorized requests. Key distribution for asymmetric keys does not require confidentiality since public keys can typically be distributed openly (because they cannot be used for URI signing) and private keys are kept by the URI signing function.

This section identifies the set of attributes that may be needed to enforce the CSP distribution policy. These attributes are protected by the URI signature. New attributes may be introduced in the future to extend the capabilities of the distribution policy. In order to provide flexibility in distribution policies to be enforced, the exact subset of attributes used for URI signature in a given request is a deployment decision. The defined keyword for each query string attribute is specified in parenthesis below. The following attributes are used to enforce the distribution policy: Expiry Time (ET) [optional] - Time when the Signed URI expires. This is represented in seconds since midnight 1/1/1970 UTC (i.e. UNIX epoch). The request is rejected if the received time is later than this timestamp. Note: The time including time zone on the entities that generate and validate the signed URI need to be in sync (e.g. NTP is used). Client IP (CIP) [optional] - IP address of the client for which this signed URI is generated. This is represented in dotted decimal format for IPv4 or canonical text representation for IPv6 address . The request is rejected if sourced from a client with a different IP address. The Expiry Time attribute ensures that the content authorization expires after a predetermined time. This limits the time window for content access and prevents replay of the request beyond the authorized time window. The Client IP attribute is used to restrict content access to a particular User Agent, based on its IP address for whom the content access was authorized.

This section identifies the set of attributes that may be needed to verify the URI (signature). New attributes may be introduced in the future if new URI signing algorithms are developed. The defined keyword for each query string attribute is specified in parenthesis below. The following attributes are used to verify the URI (signature). Version (VER) [optional] - An integer used for identifying the version of URI signing method. Key ID (KID) [optiona] - A string used for obtaining the key (e.g. database lookup, URI reference) which is needed to validate the URI signature. Hash Function (HF) [optional] - A string used for identifying the hash function to compute the URI signature (e.g. "MD5", "SHA1") with HMAC. If this attribute is not present in the URI, the default hash function is SHA256. The Version attribute indicates which version of URI signing scheme is used (including which attributes and algorithms are supported). The present document specifies Version 1. If the Version attribute is not present in the Signed URI, then the version is obtained from the CDNI metadata, else it is considered to have been set to the default value of 1. More versions may be defined in the future. The Key ID attribute is used to retrieved the key which is needed as input to the algorithm for validating the Signed URI. The Hash Function attribute indicates the hash function to be used for HMAC-based message digest computation.

The following attributes are used to convey the actual URI signature. Just to reiterate, the protected portion of the Signed URI is the entire URI, excluding the scheme name part, that is "in front" of either of the attributes below. The attribute MUST be the last attribute in the query string of the URI after all the CDNI URI Signing attributes are appended to the URI. Message Digest (MD) [mandatory for symmetric key] - A string used for the message digest generated by the URI signer. Digital Signature (DS) [mandatory for asymmetric keys] - A string used for the digital signature provided by the URI signer. The Message Digest attribute contains the message digest used to validate the Signed URI when symmetric key is used. In the case of symmetric key, HMAC algorithm is used for the following reasons: 1) Ability to use hash functions (i.e. no changes needed) with well understood cryptographic properties that perform well and for which code is freely and widely available, 2) Easy to replace the embedded hash function in case faster or more secure hash functions are found or required, 3) Original performance of the hash function is maintained without incurring a significant degradation, and 4) Simple way to use and handle keys. The Digital Signature attribute contains the digital signature used to verify the Signed URI when asymmetric keys are used. In the case of asymmetric keys, Elliptic Curve Digital Signature Algorithm (EC DSA) - a variant of DSA - is used because of the following reasons: 1) Key size is small while still offering good security, 2) Key is easy to store, and 3) Computation is faster than DSA or RSA. [Editor's note: Should there be options for other DSA?]

The URI Signing Package attribute is a container for all the other CDNI URI Signing attributes in an encoded format. The CDNI URI Signing attributes used to compute the URI signature are encoded and stored in this attribute. It is appended to the original URI to create the Signed URI. The URI Signing Package attribute serves multiple functions. It avoids the exposure of all the other CDNI URI Signing attributes. For those attributes, the potential for attribute namespace conflict is eliminated. Overlapping attribute names cause ambiguity for the optional CDNI URI Signing attributes because it's unclear if the attributes in the query string were added for URI Signing or another purpose. One way to prevent the situation is to require the CSP/CDN to not used the same attribute names when generating an URI. But that may not be always possible. Another benefit of the attribute is that the obfuscation hides the information (e.g. client IP address) from view for the common user, whom is not aware of the encoding scheme. Obviously, it is not a security method since anyone who knows the encoding scheme is able to obtain the clear text. Note that any attributes that are appended after the URI Signing Package attribute are not validated and hence do not affect URI Signing. The attributes that are appended to the Signed URI should not have the same name as this attribute to avoid failing URI Signing validation.[Editor's note: discuss if URI Signing Package should be mandatory] The following attribute is used to carry the encoded set of URI Signing attributes in the Signed URI. URI Signing Package (URISigningToken) - The encoded token containing all the CDNI URI Signing attributes used for URI SIgning. The URI Signing Package attribute contains the URI Signing attributes in the Base 64 encoding with URL and Filename Safe Alphabet (a.k.a. "base64url") as specified in theBase-64 Data Encoding document. When this attribute is used, it is the only URI Signing attribute exposed in the Signed URI. The attribute MUST be the last attribute in the query string of the URI when the Signed URI is generated. However, a client or CDN may append other attributes unrelated to URI Signing to the Signed URI as long as those attribute names do not use the same name as this attribute. The CDNI Metadata Interface may override the attribute name (i.e. "URISigningToken") and/or the encoding format used in the URI Signing Package attribute.

The following procedure for signing a URI defines the algorithms in this version of URI Signing. Note that some steps may be skipped if the URI Signing attribute is not needed to enforce the distribution policy. A URI (as defined in URI Generic Syntax) contains the following parts: scheme name, authority, path, query, and fragment. The entire URI except the "scheme name" part is protected by the URI signature. This allows the URI signature to be validated correctly in the case when a client performs a fallback to another scheme (e.g. HTTP) for a content referenced by an URI with a specific scheme (e.g. RTSP). The benefit is that the content access is protected regardless of the type of transport used for delivery. If the CSP wants to ensure a specific protocol is used for content delivery, that information is passed by CDNI metadata. Note: The following URI signing steps are specified to generate a Signed URI. However, 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/content.mov", is used to clarify the steps. The URI Signing attributes are appended to the protected portion of the URI to compute the URI signature. Copy the Original URI, excluding the "scheme name" part, into a buffer to hold the message for performing the operations below. Check if the URI already contains a query string. If not, append a "?" character. If yes, append an "&" character. If the version needs to be specified, then append the string "VER=1". This represents the version of URI Signing specified by this document. If time window enforcement is needed, then perform the this step and the next two steps. Append the string "&ET=". Note in the case of re-signing an URI, the attribute is carried over from the received Signed URI. Get the current time in seconds since epoch (as an integer). Add the validity time in seconds as an integer. Note in the case of re-signing an URI, the value MUST remain the same as the received Signed URI. Convert this integer to a string and append to the message. If client IP address enforcement is needed, then perform this step and the next step. Append the string "&CIP=". Note in the case of re-signing an URI, the attribute is carried over from the received Signed URI. Convert the client's IP address in dotted decimal notation format (i.e. for IPv4 address) or canonical text representation (for IPv6 address) to a string and append to the message. Note in the case of re-signing an URI, the value MUST remain the same as the received Signed URI. 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. For symmetric key, HMAC is used. Obtain the shared key to be used for signing the URI. If the key identifier needs to be specified, then perform this step and the next step. Append the string "&KID=". Append the key identifier (e.g. "example:keys:123") needed by the entity to locate the shared key for validating the URI signature. If the hash function for HMAC needs to be specified, then perform this step and the next step. Append the string "&HF=". Append the string for the type of hash function (e.g. "MD5", "SHA-1"). Note that re-signing an URI MUST use the same hash function as the received Signed URI or one of the allowable hash functions designated by the CDNI metadata. Append the string "&MD=". The message contains the complete section of the URI that is protected. (e.g. "://example.com/content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&HF=SHA-1&MD="). Compute the message digest (note: this is the URI signature) using the HMAC algorithm with the shared key and message as the two inputs to the hash function which is specified by the "HF" attribute. Note: Computation happens before URL encoding with escape characters is performed for reserved characters. Convert the message digest to its equivalent hexadecimal format. Append the string for the message digest (e.g. "://example.com/content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&HF=SHA-1&MD=4fb1c1adf1588fbe11cc6a04c6e69f35"). For asymmetric keys, EC DSA is used. 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. If the key identifier needs to be specified, then perform this step and the next step. Append the string "&KID=". 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 the Key ID URI contains only the "scheme name", "authority", and "path" parts. Append the string "&DS=". The message contains the complete section of the URI that is protected. (e.g. "://example.com/content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=http://example.com/public/keys/123&DS="). Compute the message digest using SHA-1 (without a key) for the message. Compute the digital signature (note: this is the URI signature) using the EC DSA algorithm with the private EC key and message digest (obtained in previous step) as inputs. Note: Computation happens before URL encoding with escape characters is performed for reserved characters. Convert the digital signature to its equivalent hexadecimal format. Append the string for the digital signature which contains the values for the 'r' and 's' parameters. The (r,s) pair is denoted by ':' (e.g. "://example.com/content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=http://example.com/public/keys/123&DS=r:CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24E" ) When packaging the URI Signing attributes is not necessary, generate the Signed URI by prepending the "scheme name" part to the message (e.g. http://example.com/content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=http://example.com/public/keys/123&DS=r:CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24E" ). Note: this is the Signed URI before URI Signing Package is applied. Apply the URI Signing Package attribute by following the procedure below to generate the URL Signing token. Generate the URI Signing token in this step and the next step. Remove the Original URI portion from the message to obtain all the URI Signing attributes, including the URI signature (e.g. "VER=1&ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&HF=SHA-1&MD=4fb1c1adf1588fbe11cc6a04c6e69f35"). Compute the URI Signing token using Base-64 Data Encoding on the message (e.g. "VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjEmS0lEPWZvb2JhcjprZXlzOjEyMyZIRj1TSEEtMSZNRD00ZmIxYzFhZGYxNTg4ZmJlMTFjYzZhMDRjNmU2OWYzNQ=="). Note: This is the value for the URI Signing token. Append the URI Signing token to the Original URI in this step and the next three steps. Copy the entire Original URI into a buffer to hold the message. Check if the URI already contains a query string. If not, append a "?" character. If yes, append an "&" character. Append the string "URISigningToken=" to the message. Append the URI Signing token to the message (e.g. "http://example.com/content.mov?URISigningToken=VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjEmS0lEPWZvb2JhcjprZXlzOjEyMyZIRj1TSEEtMSZNRD00ZmIxYzFhZGYxNTg4ZmJlMTFjYzZhMDRjNmU2OWYzNQ=="). Note: this is the completed Signed URI.

The following steps are specified to validate a Signed URI. However, it is possible to use some other algorithm and implementation as long as the same result is achieved. Note that some steps are to be skipped if the corresponding URI Signing attribute is not embedded in the Signed URI. The absence of a given attribute indicates enforcement of its purpose is not necessary in the distribution policy. Extract the value from "URISigningToken" attribute. This value is the encoded URI Signing token. If there are multiple instances of this attribute, the last one is used. Decode the string using Base-64 Data Encoding (or another encoding method specified by configuration or CDNI metada) to obtain all the URI Signing attributes (e.g. "VER=1&ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&HF=SHA-1&MD=4fb1c1adf1588fbe11cc6a04c6e69f35"). Extract the value from "VER" attribute if the attribute exists. Determine the version of the URI Signing algorithm used to process the Signed URI. If the attribute is not in the URI, then obtain the version number in another manner (e.g. configuration or CDNI metadata). Extract the value from "CIP" attribute if the attribute exists. Validate that the request came from the same IP address as indicated in the "CIP" attribute. If the IP address is incorrect, then the request is denied. Extract the value from "ET" attribute if the attribute exists. Validate that the request arrived before expiration time based on the "ET" attribute. If the time expired, then the request is denied. Extract the value from "MD" attribute if the attribute exists. If there are multiple instances of this attribute, the last one is used. [Editor's note: remove sentence if URISigningToken is mandatory] The attribute indicates symmetric key is used. Extract the value from "DS" attribute if the attribute exists. If there are multiple instances of this attribute, the last one is used. [Editor's note: remove sentence if URISigningToken is mandatory] The attribute indicates asymmetric key is used. If neither "MD" or "DS" attribute is in the URI, then no URI signature exists and the request is denied. Validate the URI signature for the Signed URI. Copy the Original URI, excluding the "scheme name" part, into a buffer to hold the message for performing the operations below. Remove the "URISigningToken" attribute from the message. Append the decoded value from "URISigningToken" attribute (which contains all the URI Signing attributes). Depending on the type of key used to sign the URI, validate the message digest or digital signature for symmetric key or asymmetric keys, respectively. For symmetric key, HMAC algorithm is used. Extract the value from the "KID" attribute if the attribute exists. Use the key identifier (e.g. "example:keys:123") to locate the shared key, which may be one of the keys available to use (i.e. set by configuration or CDNI metadata). If the attribute is not in the URI, then obtain the key in another manner (e.g. configuration or CDNI metadata). Extract the value from the "HF" attribute if the attribute exists. Determine the type of hash function (e.g. "MD5", "SHA-1") to use for HMAC. If the attribute is not in the URI, then obtain the hash function type in another manner (e.g. configuration or CDNI metadata). Extract the value from the "MD" attribute. This is the received message digest. Convert the message digest to binary format. This will be used to compare with the computed value later. Remove the value part of the "MD" attribute (but not the '=' character) from the message. The message is ready for validation of the message digest (e.g. "://example.com/content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&HF=SHA-1&MD="). Compute the message digest using the HMAC algorithm with the shared key and message as the two inputs to the hash function which is specified by the "HF" attribute. Note: Computation happens after URL decoding of the escape characters is performed for reserved characters. Compare the result with the received message digest to validate the Signed URI. For asymmetric keys, EC DSA is used. Extract the value from the "KID" attribute. Use the key identifier (e.g. "http://example.com/public/keys/123") to obtain the EC public key, which may be one of the keys available to use (i.e. set by configuration or CDNI metadata). If the attribute is not in the URI, then obtain the key in another manner (e.g. configuration or CDNI metadata). Extract the value from the "DS" attribute. This is the digital signature. Convert the digital signature to binary format. This will be used for verification later. Remove the value part of the "DS" attribute (but not the '=' character) from the message. The message is ready for validation of the digital signature (e.g. "://example.com/content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=http://example.com/public/keys/123&DS="). Compute the message digest using SHA-1 (without a key) for the message. Note: Computation happens after URL decoding of the escape characters is performed for reserved characters. Verify the digital signature using the EC DSA algorithm with the public EC key, received digital signature, and message digest (obtained in previous step) as inputs. This validates the Signed URI.

Some of the CDNI Interfaces need enhancements to support URI Signing. As an example: A Downstream CDN that supports URI Signing needs to be able to advertise this capability to the Upstream CDN. The Upstream CDN needs to select a Downstream CDN based on such capability when the CSP requires access control to enforce its distribution policy via URI Signing. Also, the Upstream CDN needs to be able to distribute via the CDNI Metadata interface the information necessary to allow the Downstream CDN to validate a Signed URI . Events that pertain to URI Signing (e.g. request denial or delivery after access authorization) need to be included in the logs communicated through the CDNI Logging interface (Editor's Note: Is this within the scope of the CDNI Logging Interface?).

URI Signing has no impact on this interface.

The Downstream CDN advertises its capability to support URI Signing via the CDNI Footprint & Capabilities Advertisement Interface ( FCI). The supported version of URI Signing needs to be included to allow for future extendebility. TBD: To be taken into account by Footprint & Capabilities design team working on this area. [Editor's note: Advertise the CDNI metadata for URI Signing capability?]

[Editor's Note: Debate the approach of dCDN providing the Signed URI vs. uCDN performing the signing function. List the pros/cons of each approach for the CDNI Request Routing Redirection interface (RI). Offer recommendation?] The two approaches: Downstream CDN provides the Signed URI Key distribution is not necessary Downstream CDN can use any scheme for Signed URI as long as the security level meets the CSP's expectation Upstream CDN signs the URI Consistency with interative request routing method URI Signing works even when Downstream CDN does not have the signing function (which may be the case when the Downstream CDN operates only as a delivering CDN) Upstream CDN can act as a conversion gateway for the requesting routing interface between Upstream CDN and CSP and request routing interface between Upstream CDN and Downstream CDN since these two interfaces may not be the same TBD: CDNI Redirection Interface is work in progress.

The following CDNI Metadata objects are specified for URI Signing. URI Signing enforcement flag. Specifically, this flag indicates if the access to content is subject to URI Signing. URI Signing requires the Downstream CDN to ensure that the URI must be signed and validated before content delivery. Otherwise, Downstream CDN does not perform validation regardless if URI is signed or not. Designated key identifier used for URI Signing computation when the Signed URI does not contain the Key ID attribute Allowable Key ID set that the Signed URI's Key ID attribute can reference Designated hash function used for URI Signing computation when the Signed URI does not contain the Hash Function attribute Allowable Hash Function set that the Signed URI's Hash Function attribute can reference Allowable crypto algorithm set? [Editor's note: TBD] Overwrite the default name for the URL Signing Attribute Set attribute Designated version used for URI Signing computation when the Signed URI does not contain the VER attribute Allowable version/algorithm set that the Signed URI's VER attribute can reference Allowable set of Downstream CDNs that participate in URI SIgning based on the symmetric key Overwrite the default encoding method for URI Signing Attribute Set attribute Note that the Key ID information is not needed if only one key is provided by the CSP or the Upstream CDN for the content item or set of content items covered by the CDNI Metadata object. In the case of asymmetric keys, it's easy for any entity to sign the URI for a content with a private key and provide the public key in the Signed URI. This just confirms that the URI Signer authorized the delivery. But it's necessary for the URI Signer to be the content owner. So, the CDNI Metadata Interface MUST provide the public key for the content or information to authorize the received Key ID attribute. TBD: CDNI Metadata Interface is work in progress.

The Downstream CDN reports that enforcement of the access control was applied to the request for content delivery. The following CDNI Logging field for URI Signing SHOULD be supported in the HTTP Request Logging Record as specified in CDNI Logging Interface. s-uri-signing: format: 1DIGIT field value: this characterises the uri signing validation performed by the Surrogate on the request. The "0" : no uri signature validation performed "1" : uri signature validation performed and validated "2" : uri signature validation performed and rejected allowed values are: occurrence: there MUST be zero or exactly one instance of this field. [Editor's note: Need to log these URI signature validation events (e.g. invalid client IP address, expired signed URI, incorrect URI signature, successful validation)?] TBD: CDNI Logging interface is work in progress.

URI Signing supports both HTTP-based and DNS-based request routing. HMAC defines a hash-based message authentication code allowing two parties that share a symmetric key or asymmetric keys to establish the integrity and authenticity of a set of information (e.g. a message) through a cryptographic hash function.

For HTTP-based request routing, HMAC is applied to a set of information that is unique to a given end user content request using key information that is specific to a pair of adjacent CDNI hops (e.g. between the CSP and the Authoritative CDN, between the Authoritative CDN and a Downstream CDN). This allows a CDNI hop to ascertain the authenticity of a given request received from a previous CDNI hop. The URI signing scheme described below is based on the following steps (assuming HTTP redirection, iterative request routing and a CDN path with two CDNs). Note that Authoritative CDN and Upstream CDN are used exchangeably.

End-User dCDN uCDN CSP | | | | | 1.CDNI RR interface used to | | | advertise URI Signing capability| | | |------------------->| | | | | | | 2.Provides information to validate URI signature| | | |<-------------------| | | | | | 3.CDNI Metadata interface used to| | | provide URI Signing attributes| | | |<-------------------| | |4.Authorisation request | | |------------------------------------------------------------->| | | | [Apply distribution | | | policy] | | | | | | | (ALT: Authorization decision) |5.Request is denied | | <Negative> | |<-------------------------------------------------------------| | | | | |6.CSP provides signed URI | <Positive> | |<-------------------------------------------------------------| | | | | |7.Content request | | | |---------------------------------------->| [Validate URI | | | | signature] | | | | | | | (ALT: Validation result) | |8.Request is denied | <Negative>| | |<----------------------------------------| | | | | | |9.Re-sign URI and redirect to <Positive>| | | dCDN (newly signed URI) | | |<----------------------------------------| | | | | | |10.Content request | | | |------------------->| [Validate URI | | | | signature] | | | | | | | (ALT: Validation result) | | |11.Request is denied| <Negative> | | |<-------------------| | | | | | | |12.Content delivery | <Positive> | | |<-------------------| | | : : : : : (Later in time) : : : |13.CDNI Logging interface to include URI Signing information | | |------------------->| | Using the CDNI Request Routing/Footprint & Capabilities Advertisement interface, the Downstream CDN advertises its capabilities including URI Signing support to the Authoritative CDN. CSP provides to the Authoritative CDN the information needed to validate URI signatures from that CSP. For example, this information may include a hashing function, algorithm, and a key value. Using the CDNI Metadata interface, the Authoritative CDN communicates to a Downstream CDN the information needed to validate URI signatures from the Authoritative CDN for the given CSP. For example, this information may include a hashing algorithm and private key corresponding to the trust relationship between the Authoritative CDN and the Downstream CDN. When a UA requests a piece of protected content from the CSP, the CSP makes a specific authorization decision for this unique request based on its arbitrary distribution policy If the authorization decision is negative, the CSP rejects the request. If the authorization decision is positive, the CSP computes a Signed URI that is based on unique parameters of that request and conveys it to the end user as the URI to use to request the content. On receipt of the corresponding content request, the authoritative CDN validates the URI Signature in the URI using the information provided by the CSP. If the validation is negative, the authoritative CDN rejects the request If the validation is positive, the authoritative CDN computes a Signed URI that is based on unique parameters of that request and provides to the end user as the URI to use to further request the content from the Downstream CDN On receipt of the corresponding content request, the Downstream CDN validates the URI Signature in the Signed URI using the information provided by the Authoritative CDN in the CDNI Metadata If the validation is negative, the Downstream CDN rejects the request and sends an error code (e.g. 403) in the HTTP response. If the validation is positive, the Downstream CDN serves the request and delivers the content. At a later time, Downstream CDN reports logging events that includes URI signing information. With HTTP-based request routing, URI Signing matches well the general chain of trust model of CDNI both with symmetric key and asymmetric keys because the key information only need to be specific to a pair of adjacent CDNI hops.

For DNS-based request routing, the CSP and Authoritative CDN must agree on a trust model appropriate to the security requirements of the CSP's particular content. Use of asymmetric public/private keys allows for unlimited distribution of the public key to downstream CDNs. However, if a shared secret key is preferred, then the CSP may want to restrict the distribution of the key to a (possibly empty) subset of trusted Downstream CDNs. Authorized Delivery CDNs need to obtain the key information to validate the Signed UR, which is computed by the CSP based on its distribution policy. The URI signing scheme described below is based on the following steps (assuming iterative DNS request routing and a CDN path with two CDNs). Note that Authoritative CDN and Upstream CDN are used exchangeably.

End-User dCDN uCDN CSP | | | | | 1.CDNI RR interface used to | | | advertise URI Signing capability| | | |------------------->| | | | | | | 2.Provides information to validate URI signature| | | |<-------------------| | | 3.CDNI Metadata interface used to| | | provide URI Signing attributes| | | |<-------------------| | |4.authorisation request | | |------------------------------------------------------------->| | | | [Apply distribution | | | policy] | | | | | | | (ALT: Authorization decision) |5.Request is denied | | <Negative> | |<-------------------------------------------------------------| | | | | |6.Provides signed URI | <Positive> | |<-------------------------------------------------------------| | | | | |7.DNS request | | | |---------------------------------------->| | | | | | |8.Redirect DNS to dCDN | | |<----------------------------------------| | | | | | |9.DNS request | | | |------------------->| | | | | | | |10.IP address of Surrogate | | |<-------------------| | | | | | | |11.Content request | | | |------------------->| [Validate URI | | | | signature] | | | | | | | (ALT: Validation result) | | |12.Request is denied| <Negative> | | |<-------------------| | | | | | | |13.Content delivery | <Positive> | | |<-------------------| | | : : : : : (Later in time) : : : |14.CDNI Logging interface to report URI Signing information | | |------------------->| | Using the CDNI Request Routing interface, the Downstream CDN advertises its capabilities including URI Signing support to the Authoritative CDN. CSP provides to the Authoritative CDN the information needed to validate cryptographic signatures from that CSP. For example, this information may include a hash function, algorithm, and a key. Using the CDNI Metadata interface, the Authoritative CDN communicates to a Downstream CDN the information needed to validate cryptographic signatures from the CSP. In the case of symmetric key, the Authoritative CDN checks if the Downstream CDN is allowed by CSP to obtain the shared secret key. When a UA requests a piece of protected content from the CSP, the CSP makes a specific authorization decision for this unique request based on its arbitrary distribution policy. If the authorization decision is negative, the CSP rejects the request If the authorization decision is positive, the CSP computes a cryptographic signature that is based on unique parameters of that request and includes it in the URI provided to the end user to request the content. End user sends DNS request to the authoritative CDN. On receipt of the DNS request, the authoritative CDN redirects the request to the Downstream CDN. End user sends DNS request to the Downstream CDN. On receipt of the DNS request, the Downstream CDN responds with IP address of one of its Surrogates. On receipt of the corresponding content request, the Downstream CDN validates the cryptographic signature in the URI using the information provided by the Authoritative CDN in the CDNI Metadata If the validation is negative, the Downstream CDN rejects the request and sends an error code (e.g. 403) in the HTTP response. If the validation is positive, the Downstream CDN serves the request and delivers the content. At a later time, Downstream CDN reports logging events that includes URI signing information. With DNS-based request routing, URI Signing matches well the general chain of trust model of CDNI when used with asymmetric keys because the only key information that need to be distributed across multiple CDNI hops including non-adjacent hops is the public key, that is generally not confidential. With DNS-based request routing, URI Signing does match well the general chain of trust model of CDNI when used with symmetric keys because the symmetric key information needs to be distributed across multiple CDNI hops including non-adjacent hops. This raises a security concern for applicability of URI Signing with symmetric keys in case of DNS-based inter-CDN request routing.

The authors note that in order to perform URI signing for individual content segments of HTTP Adaptive Bitrate content, specific URI signing mechanisms are needed. Such mechanisms are currently out-of-scope of this document. More details on this topic is covered in Models for HTTP-Adaptive-Streaming-Aware CDNI.

[Editor note: (Is there a need to/How to) register official query string attribute keywords to be used for URI Signing? Need anything from IANA?] This document requests IANA to create three new registries for the attributes (a.k.a. keywords) and their defined values in the URI Signing token. This document highlights the use of the following query string attribute in the URI to support URI Signing. There is no intention to claim any query string attribute for URI beyond the CDNI URI Signing context. That means the entities that sign the URI or validate the URI signature comply to the keyword specified in the query string for the URI Signing function only when URI Signing is used and only in the context of CDNI. The following Enforcement Attributes names are allocated: ET (Expiry time) CIP (Client IP address) The following Signature Computation Attributes names are allocated: VER (Version): 1(Base) KID (Key ID) HF (Hash Function): "MD5", "SHA1" The following URI Signature Attributes names are allocated: MD (Message Digest) DS (Digital Signature) The following URI Signing Package Attribute names are allocated: URI Signing Package (URI Signing token) The IANA is requested to allocate a new entry to the CDNI Logging Field Names Registry as specified in CDNI Logging Interface in accordance to the "Specification Required" policy s-url-signing

This document 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 UAs are able to access the content, with a Content Service Provider (CSP) being able to authorize every individual request. It should be noted that URI Signing is not a content protection scheme; if a CSP wants to protect the content itself, other mechanisms, such as DRM, are more approriate. In general it holds that the level of protection against illegitimate access can be increased by including more Enforcement Attributes in the URI. The current version of this document includes attributes for enforcing Client IP Address and Expiration Time, however this list can be extended with other, more complex, attributes that are able to provide some form of protection against some of the vulnerabilities highlighted below. That said, there are a number of aspects that limit the level of security offered by URI signing and that anybody implementing URI signing should be aware of. Replay attacks: Any (valid) Signed URI can be used to perform replay attacks. The vulnerability to replay attacks can be reduced by picking a relatively short window for the Expiration Time attribute, although this is limited by the fact that any HTTP-based request needs a window of at least a couple of seconds to prevent any sudden network issues from preventing legitimate UAs access to the content. One way to reduce exposure to replay attacks is to include in the URI a unique one-time access ID. Whenever the Downstream CDN receives a request with a given unique access ID, it adds that access ID to the list of 'used' IDs. In the case an illegitimate UA tries to use the same URI through a replay attack, the Downstream CDN can deny the request based on the already-used access ID. Illegitimate client behind a NAT: In cases where there are multiple users behind the same NAT, all users will have the same IP address from the point of view of the Downstream CDN. This results in the Downstream CDN not being able to distinguish between the different users based on Client IP Address and illegitimate users being able to access the content. One way to reduce exposure to this kind of attack is to not only check for Client IP but also for other attributes that can be found in the HTTP headers. TBD: ... The shared key between CSP and Authoritative CDN may be distributed to Downstream CDNs - including cascaded CDNs. Since this key can be used to legitimately sign a URL for content access authorization, it's important to know the implications of a compromised shared key. [Editor's note: Threat model cover in the Security section - Prevent client from spoofing URI (Ray) - Security implications - The scope of protection by URI Signing - Protects against DoS (network bandwidth and other nodes besides the edge cache); limits the time window. ]

The privacy protection concerns described in CDNI Logging Interface apply when the client's IP address (CIP attribute) is embedded in the Signed URI. In this case, all the CDNI attributes MUST be removed from the logging record when anonymization is enabled.

The authors would like to thank the following people for their contributions in reviewing this document and providing feedback: Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan York, Bhaskar Bhupalam, Matt Caulfield, and Samuel Rajakumar .