CDNI | K. Leung |
Internet-Draft | F. Le Faucheur |
Intended status: Standards Track | Cisco Systems |
Expires: December 02, 2013 | B. Downey |
Verizon Labs | |
R. van Brandenburg | |
TNO | |
S. Leibrand | |
Limelight Networks | |
May 31, 2013 |
URI Signing for CDN Interconnection (CDNI)
draft-leung-cdni-uri-signing-02
This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a candidate URI signing scheme.
The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access request for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata.
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 02, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 User Agents (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 appropriate.
The overall problem space for CDN Interconnection (CDNI) is described in CDNI Problem Statement [RFC6707]. In this document, along with the CDNI Requirements [I-D.ietf-cdni-requirements] document and the CDNI Framework [I-D.ietf-cdni-framework] the need for interconnected CDNs to be able to implement an access control mechanism that enforces the CSP's distribution policy is described.
Specifically, CDNI Framework [I-D.ietf-cdni-framework] states:
"The CSP may also trust the CDN operator to perform actions such as ..., and to enforce per-request authorization performed by the CSP using techniques such as URI signing."
In particular, the following requirement is listed in CDNI Requirements [I-D.ietf-cdni-requirements]:
"MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow signaling of authorization checks and validation that are to be performed by the surrogate before delivery. For example, this could potentially include:
* need to validate URI signed information (e.g. Expiry time, Client IP address)."
This document proposes a URI Signing scheme that allows Surrogates in interconnected CDNs to enforce a per-request authorization performed by the CSP. Splitting the role of performing per-request authorization by CSP and the role of validation of this authorization by the CDN allows any arbitrary distribution policy to be enforced across CDNs without the need of CDNs to have any awareness of the actual CSP distribution policy.
This document uses the terminology defined in CDNI Problem Statement [RFC6707].
This document also uses the terminology of Keyed-Hashing for Message Authentication (HMAC) [RFC2104] including the following terms (reproduced here for convenience):
In addition, the following terms are used throughout this document:
The following section provides an informative overview of how URI Signing works in CDNI scenarios. In order to do so, 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 asymetric public/private keys, respectively.
Figure 1, shown below, presents an overview of the URI Signing mechanism in the case of a CSP with a single CDN. In this particular example, the CSP and CDN have exchanged a (symmetric) shared secret key. Once the UA sends a content request to the CSP (#1), the CSP responds by directing the UA towards the CDN using an embedded Target CDN URI (#2). The CSP may include in this URI the IP address of the UA and/or a time window. Finally, it signs the URI using the shared secret. Once the UA receives the response with the embedded URI, it sends a new request using the embedded URI to the CDN (#3). Upon receiving the request, the CDN checks to see if the URI is authentic by verifying the URI signature. In addition, it checks whether the IP address of the UA matches that in the URI and if the time window is still valid. After these values are confirmed to be valid, the CDN starts the content delivery process (#4).
-------- / \ | CSP |< * * * * * * * * * * * \ / Trust * -------- relationship * ^ | (symmetric key) * | | * 1. Request | | 2. Signed * for | | URI * content | | * | v v +------+ 3. Signed URI -------- | User |----------------->/ \ | Agent| | CDN | | |<-----------------\ / +------+ 4. Content -------- Delivery
Figure 1: URI Signing in a CDN Environment
In CDNI scenarios, URI Signing operates the same way in the initial steps (#1-#3) 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. Depending on whether HTTP-based or DNS-based request routing is in use, the Upstream CDN responds by directing the UA towards the Downstream CDN using either a Redirection URI 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 [operation].
-------- / \ | CSP |< * * * * * * * * * * * \ / Trust * -------- relationship * ^ | (symmetric key) * | | * 1. Request | | 2. Signed * for | | URI * content | | * | v 3. Signed URI v +------+ or DNS request -------- | User |----------------->/ \ | Agent| | uCDN | | |<-----------------\ / +------+ 4. Redirection URI-------- ^ | or DNS Reply ^ | | * Trust relationship | | * (symmetric key) | | 5. Redirection URI v | | or Signed URI -------- | +------------------->/ \ [May be | | dCDN | cascaded +-----------------------\ / CDNs] 6. Content -------- delivery
Figure 2: URI Signing in a CDNI Environment
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 asymetric 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 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.
The concept behind URI Signing is based on embedding in the Target CDN URI/Redirection URI some attributes that can be validated to ensure the UA has legitimate access to the content. In the URI signing mechanism that is described in this section, four types of attributes may be embedded in the 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 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:
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).
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, the version is considered to have been set to 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.
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.
As an option to avoid exposing all the URI Signing attributes in the URI, the attributes can be obfuscated by including only the URI Signing token in the Signed URI. This also reduces the number of attributes that are appended to the Original URI to just one. The intent is to hide the information (e.g. IP address) from view for the common user who is not aware of the encoding scheme. It is not a security method since anyone who knows the encoding scheme is able to obtain the clear text.
The following attribute is used to convey the tokenized set of URI Signing attributes in the Signed URI.
The URI Signing Token attribute contains the URI Signing attributes in Base-64 Data Encoding [RFC4648] format. 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. The CDNI Metadata Interface may override the encoding format used in the "UST" 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 [RFC3986]) 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.
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.
When tokenizing the URI Signing attributes is desired, follow the procedure below.
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.
Validate the URI signature for 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?).
The Downstream CDN advertises its capability to support URI Signing via the CDNI Request Routing/Footprint & Capabilities Advertisement Interface (CDNI 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: Check if there is an impact on CDNI RI?
TBD: CDNI Redirection Interface is work in progress.
The following CDNI Metadata objects are specified for URI Signing.
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.
TBD: CDNI Logging interface is work in progress.
URI Signing supports both HTTP-based and DNS-based request routing. HMAC [RFC2104] 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 | | |------------------->| |
Figure 3: HTTP-based Request Routing with URI Signing
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 | | |------------------->| |
Figure 4: DNS-based Request Routing with URI Signing
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.
TBD - HTTP ABR calls for specific support by URI Signing ("flexible URI signing") as discussed in [I-D.brandenburg-cdni-has]. This will be added in a future version of this document.
[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:
The following Signature Computation Attributes names are allocated:
The following URI Signature Attributes names are allocated:
The following URI Signing Token Attributes names are allocated:
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.
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.
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, and Matt Caulfield.
[RFC6707] | Niven-Jenkins, B., Le Faucheur, F. and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012. |
[I-D.ietf-cdni-use-cases] | Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, K. and G. Watson, "Use Cases for Content Delivery Network Interconnection", Internet-Draft draft-ietf-cdni-use-cases-10, August 2012. |
[I-D.ietf-cdni-requirements] | Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", Internet-Draft draft-ietf-cdni-requirements-04, December 2012. |
[I-D.ietf-cdni-framework] | Peterson, L. and B. Davie, "Framework for CDN Interconnection", Internet-Draft draft-ietf-cdni-framework-03, February 2013. |
[RFC4648] | Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. |
[RFC2104] | Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. |
[RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. |
[I-D.brandenburg-cdni-has] | Brandenburg, R., Deventer, O., Faucheur, F. and K. Leung, "Models for adaptive-streaming-aware CDN Interconnection", Internet-Draft draft-brandenburg-cdni-has-04, January 2013. |
[RFC5952] | Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010. |