URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9246.
|
|
|---|---|---|---|
| Authors | Kent Leung , François Le Faucheur , Ray van Brandenburg , Bill Downey , Michel Fisher | ||
| Last updated | 2015-12-31 | ||
| Replaces | draft-leung-cdni-uri-signing | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Kevin J. Ma | ||
| IESG | IESG state | Became RFC 9246 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | "Kevin J. Ma" <kevin.j.ma@ericsson.com> |
draft-ietf-cdni-uri-signing-06
CDNI K. Leung
Internet-Draft F. Le Faucheur
Intended status: Standards Track Cisco Systems
Expires: July 2, 2016 R. van Brandenburg
TNO
B. Downey
Verizon Labs
M. Fisher
Limelight Networks
December 30, 2015
URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-06
Abstract
This document describes how the concept of URI signing supports the
content access control requirements of CDNI and proposes a 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 requests for the content referenced by the URI. The
mechanism described can be used both in CDNI and single CDN
scenarios.
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 July 2, 2016.
Leung, et al. Expires July 2, 2016 [Page 1]
Internet-Draft CDNI URI Signing December 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Background and overview on URI Signing . . . . . . . . . 4
1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 5
1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8
2. Signed URI Information Elements . . . . . . . . . . . . . . . 8
2.1. Enforcement Information Elements . . . . . . . . . . . . 10
2.2. Signature Computation Information Elements . . . . . . . 11
2.3. URI Signature Information Elements . . . . . . . . . . . 13
2.4. URI Signing Package Attribute . . . . . . . . . . . . . . 14
2.5. User Agent Attributes . . . . . . . . . . . . . . . . . . 15
3. Creating the Signed URI . . . . . . . . . . . . . . . . . . . 15
3.1. Calculating the URI Signature . . . . . . . . . . . . . . 16
3.2. Packaging the URI Signature . . . . . . . . . . . . . . . 19
4. Validating a URI Signature . . . . . . . . . . . . . . . . . 20
4.1. Information Element Extraction . . . . . . . . . . . . . 21
4.2. Signature Validation . . . . . . . . . . . . . . . . . . 22
4.3. Distribution Policy Enforcement . . . . . . . . . . . . . 24
5. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 25
5.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 25
5.2. CDNI Footprint & Capabilities Advertisement Interface . . 25
5.3. CDNI Request Routing Redirection Interface . . . . . . . 26
5.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 26
5.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 29
6. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 30
6.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 30
6.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 33
7. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Leung, et al. Expires July 2, 2016 [Page 2]
Internet-Draft CDNI URI Signing December 2015
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.1. Normative References . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction
This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of redirection
between interconnected CDNs (CDNI) and between a Content Service
Provider (CSP) and a CDN. The primary goal of URI Signing is to make
sure that only authorized User Agents (UAs) are able to access the
content, with a 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. In addition to access
control, URI Signing also has benefits in reducing the impact of
denial-of-service attacks.
The overall problem space for CDN Interconnection (CDNI) is described
in CDNI Problem Statement [RFC6707]. In this document, along with
the CDNI Requirements [RFC7337] document and the CDNI Framework
[RFC7336] 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 [RFC7336] 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 [RFC7337]:
"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
Leung, et al. Expires July 2, 2016 [Page 3]
Internet-Draft CDNI URI Signing December 2015
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.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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].
In addition, the following terms are used throughout this document:
o URI Signature: Message digest or digital signature that is
computed with an algorithm for protecting the URI.
o Original URI: The URI before URI Signing is applied.
o Signed URI: Any URI that contains a URI Signature.
o 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.
o 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.
1.2. Background and overview on URI Signing
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
Leung, et al. Expires July 2, 2016 [Page 4]
Internet-Draft CDNI URI Signing December 2015
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. If applicable, 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
Figure 1: Figure 1: URI Signing in a CDN Environment
1.3. CDNI URI Signing Overview
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
Leung, et al. Expires July 2, 2016 [Page 5]
Internet-Draft CDNI URI Signing December 2015
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 (Section 6).
Leung, et al. Expires July 2, 2016 [Page 6]
Internet-Draft CDNI URI Signing December 2015
+-------------------------+
|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) |
+-----------------------------------------+
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
Leung, et al. Expires July 2, 2016 [Page 7]
Internet-Draft CDNI URI Signing December 2015
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, the 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
MUST maintain the same, or higher, level of security as the original
Signed URI.
1.4. URI Signing in a non-CDNI context
While the URI signing 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 Figure 1 in
Section 1.2, for example to allow a CSP that uses different CDNs to
only have to implement a single URI Signing mechanism.
2. Signed URI Information Elements
The concept behind URI Signing is based on embedding in the Target
CDN URI/Redirection URI a number of information elements that can be
validated to ensure the UA has legitimate access to the content.
These information elements are appended, in an encapsulated form, to
the original URI.
Leung, et al. Expires July 2, 2016 [Page 8]
Internet-Draft CDNI URI Signing December 2015
For the purposes of the URI signing mechanism described in this
document, three types of information elements may be embedded in the
URI:
o Enforcement Information Elements: Information Elements 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.
o Signature Computation Information Elements: Information Elements
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 information elements that describe how the URI
Signature was generated. Examples of Signature Computation
Elements include the used HMACs hash function and/or the key
identifier.
o URI Signature Information Elements: The information elements that
carry the actual message digest or digital signature representing
the URI signature used for checking the integrity and authenticity
of the URI. A typical Signed URI will only contain one embedded
URI Signature Information Element.
In addition, the this document specifies the following URI attribute:
o URI Signing Package Attribute: The URI attribute that encapsulates
all the URI Signing information elements in an encoded format.
Only this attribute is exposed in the Signed URI as a URI query
parameter.
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
entity signing the URI (either CSP or uCDN) and a public key for the
verification of the Signed URI. With symmetric keys, the same key is
used by both the signing entity for signing the URI as well as by the
validating entity for validating the Signed URI. Regardless of the
type of keys used, the validating entity has to obtain the key
(either the public or the symmetric 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.
Leung, et al. Expires July 2, 2016 [Page 9]
Internet-Draft CDNI URI Signing December 2015
Note that all the URI Signing information elements and the URI query
attribute are mandatory to implement, but not mandatory to use.
2.1. Enforcement Information Elements
This section identifies the set of information elements that may be
needed to enforce the CSP distribution policy. New information
elements 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 information elements used in the URI
Signature of a given request is a deployment decision. The defined
keyword for each information element is specified in parenthesis
below.
The following information elements are used to enforce the
distribution policy:
o Expiry Time (ET) [optional] - Time when the Signed URI expires.
This is represented as an integer denoting the number of 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. In the CDNI case,
this means that servers at both the CSP, uCDN and dCDN need to be
time-synchronized. It is RECOMMENDED to use NTP for this.
o Client IP (CIP) [optional] - IP address, or IP prefix, for which
the Signed URI is valid. This is represented in CIDR notation,
with dotted decimal format for IPv4 or canonical text
representation for IPv6 addresses [RFC5952] . The request is
rejected if sourced from a client outside of the specified IP
range.
o Original URI Container (OUC) [optional] - Container for holding
the Original URI while the URI signature is calculated. The
Original URI Container information element is not transmitted as
part of the URI Signing Package Attribute. If the Original URI
Container information element is used, the URI Pattern Sequence
information element MUST NOT be used.
o URI Pattern Container (UPC) [optional] - Container for one or more
URI Patterns that describes for which content the Signed URI is
valid. The URI Pattern Container contains an expression to match
against the requested URI to check whether the requested content
is allowed to be requested. Multiple URI Patterns may be
concatenated in a single URI Pattern Container information element
Leung, et al. Expires July 2, 2016 [Page 10]
Internet-Draft CDNI URI Signing December 2015
by seperating them with a semi-colon (';') character. Each URI
Pattern follows the [RFC3986] URI format, including the '://' that
delimits the URI scheme from the hierarchy part. The pattern may
include the wildcards '*' and '?', where '*' matches any sequence
of characters (including the empty string) and '?' matches exactly
one character. The three literals '$', '*' and '?' should be
escaped as '$$', '$*' and '$?'. All other characters are treated
as literals. The following is an example of a valid URI Pattern:
'*://*/folder/content-83112371/quality_*/segment????.mp4'. An
example of two concatenated URI Patterns is the following:
'http://*/folder/content-83112371/manifest/*.xml;http://*/folder/
content-83112371/quality_*/segment????.mp4'. If the UPC is used,
the Original URI Container information element MUST NOT be used.
The Expiry Time Information Element 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 Information Element is used to restrict content access
to a particular IP address or set of IP addresses based on the IP
address for whom the content access was authorized. The URI Signing
mechanism described in this document will communicate the IP address
in the URI. To prevent the IP addess from being logged, the Client
IP information element is transmited in encrypted form.
The Original URI Container is used to limit access to the Original
URI only.
The URI Pattern Container Information Element is used to restrict
content access to a particular set of URLs.
Note: See the Security Considerations (Section 9) section on the
limitations of using an expiration time and client IP address for
distribution policy enforcement.
2.2. Signature Computation Information Elements
This section identifies the set of information elements that may be
needed to verify the URI (signature). New information elements may
be introduced in the future if new URI signing algorithms are
developed.
The defined keyword for each information element is specified in
parenthesis below.
The following information elements are used to validate the URI by
recreating the URI Signature.
Leung, et al. Expires July 2, 2016 [Page 11]
Internet-Draft CDNI URI Signing December 2015
o Version (VER) [optional] - An 8-bit unsigned integer used for
identifying the version of URI signing method. If this
Information Element is not present in the URI Signing Package
Attribute, the default version is 1.
o Key ID (KID) [optional] - A string used for obtaining the key
(e.g. database lookup, URI reference) which is needed to validate
the URI signature. The KID and KID_NUM information elements MUST
NOT be present in the same URI Signing Package Attribute.
o Numerical Key ID (KID_NUM) [optional] - A 64-bit unsigned integer
used as an optional alternative for KID. The KID and KID_NUM
information elements MUST NOT be present in the same URI Signing
Package Attribute.
o Hash Function (HF) [optional] - A string used for identifying the
hash function to compute the URI signature with HMAC. If this
Information Element is not present in the URI Signing Package
Attribute, the default hash function is SHA-256.
o Digital Signature Algorithm (DSA) [optional] - Algorithm used to
calculate the Digital Signature. If this Information Element is
not present in the URI Signing Package Attribute, the default is
EC-DSA.
o Client IP Encryption Algorithm (CEA) [optional] - Algorithm used
to encrypt the Client IP. If this Information Element is not
present in the URI Signing Package Attribute, the default is AES-
128.
o Client IP Key ID (CKI) [optional] - A 64-bit unsigned integer used
for obtaining the key (e.g. database lookup) used for encrypting/
decrypting the Client IP.
The Version Information Element 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 Information Element is used to retrieved the key which is
needed as input to the algorithm for validating the Signed URI. The
method used for obtaining the actual key from the reference included
in the Key ID Information Element is outside the scope of this
document. Instead of using the KID element, which is a string, it is
possible to use the KID_NUM element for numerical Key identifiers
Leung, et al. Expires July 2, 2016 [Page 12]
Internet-Draft CDNI URI Signing December 2015
instead. The KID_NUM element is a 64-bit unsigned integer. In cases
where numerical KEY IDs are used, it is RECOMMENDED to use KID_NUM
instead of KID.
The Hash Function Information Element indicates the hash function to
be used for HMAC-based message digest computation. The Hash Function
Information Element is used in combination with the Message Digest
Information Element defined in section Section 2.3.
The Digital Signature Algorithm Information Element indicates the
digital signature function to be in the case asymmetric keys are
used. The Digital Signature Algorithm Information Element is used in
combination with the Digital Signature Information Element defined in
section Section 2.3.
The Client IP Encryption Algorithm Information Element indicates the
encryption algorithm to be used for the Client IP. The Client IP
Encryption Algorithm Information Element is used in combination with
the Client IP Information Element defined in section Section 2.1.
The Client IP Key ID is used to retrieved the key which is used for
encrypting and decrypting the Client IP. The method used for
obtaining the actual key from the reference included in the Key ID
Information Element is outside the scope of this document. The
Client IP Encryption Algorithm Information Element is used in
combination with the Client IP Information Element defined in section
Section 2.1.
2.3. URI Signature Information Elements
This section identifies the set of information elements that carry
the URI Signature that is used for checking the integrity and
authenticity of the URI.
The defined keyword for each information element is specified in
parenthesis below.
The following information elements are used to carry the actual URI
Signature.
o Message Digest (MD) [mandatory for symmetric key] - A string used
for the message digest generated by the URI signing entity.
o Digital Signature (DS) [mandatory for asymmetric keys] - A string
used for the digital signature provided by the URI signing entity.
The Message Digest attribute contains the message digest used to
validate the Signed URI when symmetric keys are used.
Leung, et al. Expires July 2, 2016 [Page 13]
Internet-Draft CDNI URI Signing December 2015
The Digital Signature attribute contains the digital signature used
to verify the Signed URI when asymmetric keys are 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 default HMAC algorithm
used is SHA-256.
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.
2.4. URI Signing Package Attribute
The URI Signing Package Attribute is an encapsulation container for
the URI Signing Information Elements defined in the previous
sections. The URI Signing Information Elements are encoded and
stored in this attribute. URI Signing Package Attribute is appended
to the Original URI to create the Signed URI.
The primary advantage of the URI Signing Package Attribute is that it
avoids having to expose the URI Signing Information Elements directly
in the query string of the URI, thereby reducing the potential for a
namespace collision space within the URI query string. A side-
benefit of the attribute is the obfuscation performed by the URI
Signing Package Attribute hides the information (e.g. client IP
address) from view of the common user, who is not aware of the
encoding scheme. Obviously, this is not a security method since
anyone who knows the encoding scheme is able to obtain the clear
text. Note that any parameters appended to the query string after
the URI Signing Package Attribute are not validated and hence do not
affect URI Signing.
The following attribute is used to carry the encoded set of URI
Signing attributes in the Signed URI.
o URI Signing Package (URISigningPackage) - The encoded attribute
containing all the CDNI URI Signing Information Elements used for
URI Signing.
Leung, et al. Expires July 2, 2016 [Page 14]
Internet-Draft CDNI URI Signing December 2015
The URI Signing Package Attribute contains the URI Signing
Information Elements in the Base-64 encoding with URL and Filename
Safe Alphabet (a.k.a. "base64url") as specified in the Base-64 Data
Encoding [RFC4648] document. The URI Signing Package Attribute is
the only URI Signing attribute exposed in the Signed URI. The
attribute MUST be the last parameter in the query string of the URI
when the Signed URI is generated. However, a client or CDN may
append other query parameters unrelated to URI Signing to the Signed
URI. Such additional query parameters SHOULD NOT use the same name
as the URI Signing Package Attribute to avoid namespace collision and
potential failure of the URI Signing validation.
The parameter name of the URI Signing Package Attribute shall be
defined in the CDNI Metadata interface. If the CDNI Metadata
interface is not used, or does not include a parameter name for the
URI Signing Package Attribute, the parameter name is set by
configuration (out of scope of this document).
2.5. User Agent Attributes
For some use cases, such as logging, it might be useful to allow the
UA, or another entity, add one or more attributes to the Signed URI
for purposes other than URI Signing without causing URI Signing to
fail. In order to do so, such attributes MUST be appended after the
URI Signing Packacke Attribute. Any attributes appended in such way
after the URI Signature has been calculated are not validated for the
purpose of content access authorization. Adding any such attributes
to the Signed URI before the URI Signing Packacke Attribute will
cause the URI Signing validation to fail.
Note that a malicious UA might potentially use the ability to append
attributes to the Signed URI in order to try to influence the content
that is delivered. For example, the UA might append '&quality=HD' to
try to make the dCDN deliver an HD version of the requested content.
Since such an additional attribute is appended after the URI Signing
Package Attribute it is not validated and will not affect the outcome
of the URI validation. In order to deal with this vulnerability, a
dCDN is RECOMMENDED to ignore any query strings appended after the
URI Signing Package Attribute for the purpose of content selection.
3. Creating the Signed URI
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 CSP does not enforce a distribution policy and the Enforcement
Information Elements are therefore not necessary. A URI (as defined
in URI Generic Syntax [RFC3986]) contains the following parts: scheme
name, authority, path, query, and fragment. If the Original URI
Leung, et al. Expires July 2, 2016 [Page 15]
Internet-Draft CDNI URI Signing December 2015
Container information element is used, all components except for the
scheme part are 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 item
referenced by a URI with a specific scheme (e.g. RTSP). In case the
URI Pattern Container information element is used, the CSP has full
flexibility to specify which elements of the URI (including the
scheme part) are protected by the URI.
The process of generating a Signed URI can be divided into two sets
of steps: first, calculating the URI Signature and then, packaging
the URI Signature and appending it to the Original URI. 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/content.mov", is used to clarify the steps.
3.1. Calculating the URI Signature
Calculate the URI Signature by following the procedure below.
1. Create an empty buffer for performing the operations below.
2. Check if the Original URI already contains a query string. If
not, place a "?" character in the buffer. If yes, place an "&"
character in the buffer.
3. If the version is the default value (i.e. "1"), skip this step.
Otherwise, specify the version by appending the string "VER=#"
to the buffer, where '#' represents the new version number. The
following steps in the procedure is based on the initial version
of URI Signing specified by this document. For other versions,
reference the associated RFC for the URI signing procedure.
4. If time window enforcement is not needed, step 4 can be skipped.
A. If an information element was added to the buffer, append an
"&" character. Append the string "ET=". Note in the case
of re-signing a URI, the information element is carried over
from the received Signed URI.
B. 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 a URI, the value MUST remain the same as
the received Signed URI.
C. Convert this integer to a string and append to the buffer.
5. If client IP enforcement is not needed, step 5 can be skipped.
Leung, et al. Expires July 2, 2016 [Page 16]
Internet-Draft CDNI URI Signing December 2015
A. If the Client IP Encryption Algorithm used is the default
("AES-128"), this step can be skipped. If an information
element was added to the message, append an "&" character.
append the string "CEA=". Append the string for the Client
IP Encryption Algorithm to be used.
B. If the Client IP Key Identifier is not needed, this step can
be skipped. If an information element was added to the
message, append an "&" character. 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. If an information element was added to the message, 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. Note in the case of re-signing an URI,
the client IP that is encrypted MUST be equal to the
unencrypted value of the Client IP as received in the Signed
URI, see step 1 in Section 4.3.
E. Convert the encrypted Client IP to its equivalent
hexadecimal format.
F. Append the value computed in the previous step to the
buffer.
6. If a Key ID information element is not needed, step 6 can be
skipped. If an information element was added to the message,
append an "&" character. Append the string "KID=" in case a
string-based Key ID is used, or "KID_NUM=" in case a numerical
Key ID is used. Append the key identifier (e.g.
"example:keys:123" or "56128239") needed by the entity to locate
the shared key for validating the URI signature.
7. If asymmetric keys are used, step 7 can be skipped. If the hash
function for the HMAC uses the default value ("SHA-256"), step 7
can be skipped. If an information element was added to the
message, append an "&" character. Append the string "HF=".
Append the string for the new type of hash function to be used.
Note that re-signing a URI MUST use the same hash function as
the received Signed URI or one of the allowable hash functions
designated by the CDNI metadata.
Leung, et al. Expires July 2, 2016 [Page 17]
Internet-Draft CDNI URI Signing December 2015
8. If assymetric keys are used, step 8 can be skipped. If the
digital signature algorithm uses the default value ("EC-DSA"),
step 8 can be skipped. If an information element was added to
the message, append an "&" character. Append the string "DSA=".
Append the string for the digital signature function. Note that
re-signing a URI MUST use the same digital signature algorithm
as the received Signed URI or one of the allowable digital
signature algorithms designated by the CDNI metadata.
9. Depending on the type of URI enforcement used (Original URI or
URI Pattern), add the appropriate information element.
A. If enforcement based on a (set of) URI Pattern is used, this
step can be skipped. If an information element was added to
the message, append an &" character. Append the string
"OUC=". Append the Original URI, excluding the "scheme
name" part and the '://' delimiter, to the buffer.
B. If enforcement based on the Original URI is used, this step
can be skipped. If an information element was added to the
message, append an &" character. Append the string "UPC=".
Append the URI Pattern Container in the form of a string to
the buffer.
10. If asymmetric keys are used, step 10 can be skipped.
A. Obtain the shared key to be used for signing the URI.
B. Append the string "MD=". The message now contains the
complete section of the URI that is protected (e.g. "ET=120
9422976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=exa
mple:keys:123&OUC=example.com/content.mov&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. "ET=12094229
76&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:
keys:123&OUC=example.com/content.mov&MD=1ecb1446a6431352aab0
fb6e0dca30e30356593a97acb972202120dc482bddaf").
11. If symmetric keys are used, step 11 can be skipped.
Leung, et al. Expires July 2, 2016 [Page 18]
Internet-Draft CDNI URI Signing December 2015
A. Obtain the private key to be used for signing the URI.
B. If an information element was added to the message, append
an "&" character. Append the string "DS=". The message now
contains the complete section of the URI that is protected.
(e.g. "ET=1209422976&CKI=311&CIP=90C913977933FC650E7186361A
93D6C3&KID=example:keys:123&OUC=example.com/
content.mov&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, the URI Signing
Package Attribute, and the resulting Signed URI. Since
SHA-1 is not used for cryptographic purposes here, the
security concerns around SHA-1 do not apply.
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. "ET=1209422976&CKI=311&CIP=90C913977933FC650E7186361A
93D6C3&KID=example:keys:123&OUC=example.com/content.mov&DS=r
:CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E00
5668D:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331
A929A29EA24E")
12. If, as part of step 9, the URI Pattern Container information
element was added to the buffer, step 12 can be skipped. Remove
the Original URI Container from the buffer, including the
preceding "&" character. (e.g. "ET=1209422976&CKI=311&CIP=90C91
3977933FC650E7186361A93D6C3&KID=example:keys:123&MD=1ecb1446a643
1352aab0fb6e0dca30e30356593a97acb972202120dc482bddaf")
3.2. Packaging the URI Signature
Apply the URI Signing Package Attribute by following the procedure
below to generate the Signed URI.
Leung, et al. Expires July 2, 2016 [Page 19]
Internet-Draft CDNI URI Signing December 2015
1. Start from the buffer created in Section 3.1. (e.g. "ET=1209422
976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:keys
:123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc4
82bddaf").
2. Compute the URI Signing Package Attribute using Base-64 Data
Encoding [RFC4648] on the message (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA
7Q0tJPTMxMSZhbXA7Q0lQPTkwQzkxMzk3NzkzM0ZDNjUwRTcxODYzNjFBOTNENkMz
JmFtcDtLSUQ9ZXhhbXBsZTprZXlzOjEyMyZhbXA7TUQ9MWVjYjE0NDZhNjQzMTM1M
mFhYjBmYjZlMGRjYTMwZTMwMzU2NTkzYTk3YWNiOTcyMjAyMTIwZGM0ODJiZGRhZg
=="). Note: This is the value for the URI Signing Package
Attribute.
3. Copy the entire Original URI into a buffer to hold the message.
4. Check if the Original URI already contains a query string. If
not, append a "?" character. If yes, append an "&" character.
5. Append the parameter name used to indicate the URI Signing
Package Attribute, as communicated via the CDNI Metadata
interface, followed by an "=". If none is communicated by the
CDNI Metadata interface, it defaults to "URISigningPackage". For
example, if the CDNI Metadata interface specifies "SIG", append
the string "SIG=" to the message.
6. Append the URI Signing token to the message (e.g.
"http://example.com/content.mov?URISigningPackage=RVQ9MTIwOTQyMjk
3NiZhbXA7Q0tJPTMxMSZhbXA7Q0lQPTkwQzkxMzk3NzkzM0ZDNjUwRTcxODYzNjFB
OTNENkMzJmFtcDtLSUQ9ZXhhbXBsZTprZXlzOjEyMyZhbXA7TUQ9MWVjYjE0NDZhN
jQzMTM1MmFhYjBmYjZlMGRjYTMwZTMwMzU2NTkzYTk3YWNiOTcyMjAyMTIwZGM0OD
JiZGRhZg=="). Note: this is the completed Signed URI.
4. Validating a URI Signature
The process of validating a Signed URI can be divided into three sets
of steps: first, extraction of the URI Signing information elements,
then validation of the URI signature to ensure the integrity of the
Signed URI, and finally, validation of the information elements to
ensure proper enforcement of the distribution policy. The integrity
of the Signed URI 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.
Leung, et al. Expires July 2, 2016 [Page 20]
Internet-Draft CDNI URI Signing December 2015
4.1. Information Element Extraction
Extract the information elements embedded in the URI. Note that some
steps are to be skipped if the corresponding URI Signing information
elements are not embedded in the Signed URI.
1. Extract the value from 'URISigningPackage' attribute. This
value is the encoded URI Signing Package 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 URI can be validated despite a client appending another
instance of the 'URISigningPackage' attribute.
2. Decode the string using Base-64 Data Encoding [RFC4648] to
obtain all the URI Signing information elements (e.g. "ET=12094
22976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:k
eys:123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb97220212
0dc482bddaf").
3. Extract the value from "VER" if the information element exists
in the query string. Determine the version of the URI Signing
algorithm used to process the Signed URI. 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
URI, then obtain the version number in another manner (e.g.
configuration, CDNI metadata or default value).
4. Extract the value from "MD" if the information element exists in
the query string. The existence of this information element
indicates a symmetric key is used.
5. Extract the value from "DS" if the information element exists in
the query string. The existence of this information element
indicates an asymmetric key is used.
6. If neither "MD" or "DS" attribute is in the URI, then no URI
Signature exists and the request is denied. If both the "MD"
and the "DS" information elements are present, the Signed URI is
considered to be malformed and the request is denied.
7. Extract the value from "UPC" if the information element exists
in the query string. The existence of this information element
indicates content delivery is enforced based on a (set of) URI
pattern(s) instead of the Original URI.
Leung, et al. Expires July 2, 2016 [Page 21]
Internet-Draft CDNI URI Signing December 2015
8. Extract the value from "CIP" if the information element exists
in the query string. 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 in
the query string. 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 URI 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.
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.
4.2. Signature Validation
Validate the URI Signature for the Signed URI.
1. Copy the Signed URI into a buffer to hold the message for
performing the operations below
2. Remove the "URISigningPackage" attribute from the message.
Remove any subsequent part of the query string after the
"URISigningPackage" attribute.
3. Append the decoded value from "URISigningPackage" attribute
(which contains all the URI Signing Information Elements).
4. Extract the value from the "MD" or "DS" information element.
This is the received message signature.
Leung, et al. Expires July 2, 2016 [Page 22]
Internet-Draft CDNI URI Signing December 2015
5. Convert the message signature to binary format. This will be
used to compare with the computed value later.
6. Remove the the "MD" or "DS" information elements from the
message.
7. If the buffer contains the UPC information element, skip this
step. Append the "&" character to the buffer. Append the
Original URI Container (OUC) information element. Append the
Original URI to the buffer, except for the scheme part and the
'://' delimiter.
8. Append the "&" character. Append "MD=" or "DS=", depending on
which of the two was present in the Signed URI. The message is
ready for validation of the message digest (e.g. "example.com/con
tent.mov?ET=1209422976&CIP=90C913977933FC650E7186361A93D6C3&KID=e
xample:keys:123&OUC=example.com/content.mov&MD=").
9. Based on the presence of either the MD or DS information element
in the buffer, validate the message digest or digital signature
for symmetric key or asymmetric keys, respectively.
A. For MD, an HMAC algorithm is used.
1. If either the "KID" or "KID_NUM" information element
exists, validate that the key identifier is in the
allowable KID set as listed in the CDNI metadata or
configuration. The request is denied when the key
identifier is not allowed. If neither the "KID" or
"KID_NUM" information element is present in the Signed
URI, obtain the shared key via CDNI metadata or
configuration.
2. If "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. Otherwise,
the "HF" information element is not in the Signed URI.
In this case, the default hash function is SHA-256.
3. Compute the message digest using the HMAC algorithm with
the shared key and message as the two inputs to the hash
function.
4. Compare the result with the received message signature
extracted in step 5 to validate the Signed URI.
B. For DS, a digital signature function is used.
Leung, et al. Expires July 2, 2016 [Page 23]
Internet-Draft CDNI URI Signing December 2015
1. If either the "KID" or "KID_NUM" information element
exists, validate that the key identifier is in the
allowable KID set as listed in the CDNI metadata or
configuration. The request is denied when the key
identifier is not allowed. If neither the "KID" or
"KID_NUM" information element is present in the Signed
URI, obtain the public key via CDNI metadata or
configuration.
2. If "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.
Otherwise, the "DSA" information element is not in the
Signed URI. In this case, the default DSA is EC-DSA.
3. Compute the message digest using SHA-1 (without a key)
for the message.
4. Verify the digital signature using the digital signature
function (e.g. EC-DSA) with the public key, received
digital signature, and message signature (extracted in
step 5) as inputs. This validates the Signed URI.
4.3. Distribution Policy Enforcement
Note that the absence of a given Enforcement Information Element
indicates enforcement of its purpose is not necessary in the CSP's
distribution policy.
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 obtained in step 6
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.
Leung, et al. Expires July 2, 2016 [Page 24]
Internet-Draft CDNI URI Signing December 2015
2. If the "ET" information element exists, validate that the request
arrived before expiration time based on the "ET" information
element. If the time expired, then the request is denied.
3. If the "UPC" information element exists, validate that the
requested resource is in the allowed set by matching the received
URI against the URI Pattern Container information element. If
there is no match, the request is denied.
5. Relationship with CDNI Interfaces
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?).
5.1. CDNI Control Interface
URI Signing has no impact on this interface.
5.2. CDNI Footprint & Capabilities Advertisement 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 extensibility.
In general, new information elements introduced to enhance URI
Signing requires a draft and a new version.
For Enforcement Information Elements, there is no need to
advertise the based information elements such as "CIP" and "ET".
For Signature Computation Information Elements:
No need to advertise "VER" Information Element unless it's not
"1". In this case, a draft is needed to describe the new
version.
Leung, et al. Expires July 2, 2016 [Page 25]
Internet-Draft CDNI URI Signing December 2015
Advertise value of the "HF" Information Element (i.e. SHA-256)
to indicate support for the hash function; Need IANA assignment
for new hash function.
Advertise value of the "DSA" Information Element (i.e. EC-DSA)
to indicate support for the DSA; Need IANA assignment for new
digital signature algorithm.
Advertise "MD" Information Element (i.e. SHA-256) to indicate
support for symmetric key method; A new draft is needed for an
alternative method.
Advertise "DS" Information Element (i.e. EC-DSA) to indicate
support for asymmetric key method; A new draft is needed for an
alternative method.
For URI Signing Package Attribute, there is no need to advertise
the base attribute.
5.3. CDNI Request Routing Redirection Interface
The CDNI Request Routing Redirection Interface
[I-D.ietf-cdni-redirection] describes the recursive request
redirection method. For URI Signing, the Upstream CDN signs the URI
provided by the Downstream CDN. This approach has the following
benefits:
Consistency with interative request routing method
URI Signing is fully operational 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
5.4. CDNI Metadata Interface
The CDNI Metadata Interface [I-D.ietf-cdni-metadata] describes the
CDNI metadata distribution in order to enable content acquisition and
delivery. For URI Signing, additional CDNI metadata objects are
specified. In general, an Empty set means "all". These are the CDNI
metadata objects used for URI Signing.
Leung, et al. Expires July 2, 2016 [Page 26]
Internet-Draft CDNI URI Signing December 2015
The UriSigning Metadata object contains information to enable URI
signing and validation by a dCDN. The UriSigning properties are
defined below.
Property: enforce
Description: 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.
Type: Boolean
Mandatory-to-Specify: No. If a UriSigning object is present in
the metadata for a piece of content (even if the object is
empty), then URI signing should be enforced. If no UriSigning
object is present in the metadata for a piece of content, then
the URI signature should not be validated.
Property: key-id
Description: Designated key identifier used for URI Signing
computation when the Signed URI does not contain the Key ID
information element.
Type: String
Mandatory-to-Specify: No. A Key ID is not essential for all
implementations of URI signing.
Property: key-id-set
Description: Allowable Key ID set that the Signed URI's Key ID
information element can reference.
Type: List of Strings
Mandatory-to-Specify: No. Default is to allow any Key ID.
Property: hash-function
Description: Designated hash function used for URI Signing
computation when the Signed URI does not contain the Hash
Function information element.
Leung, et al. Expires July 2, 2016 [Page 27]
Internet-Draft CDNI URI Signing December 2015
Type: String (limited to the hash function strings in the
registry defined by the IANA Considerations (Section 8)
section)
Mandatory-to-Specify: No. Default is SHA-256.
Property: hash-function-set
Description: Allowable Hash Function set that the Signed URI's
Hash Function information element can reference.
Type: List of Strings
Mandatory-to-Specify: No. Default is to allow any hash
function.
Property: digital-signature-algorithm
Description: Designated digital signature function used for URI
Signing computation when the Signed URI does not contain the
Digital Signature Algorithm information element.
Type: String (limited to the digital signature algorithm
strings in the registry defined by the IANA Considerations
(Section 8) section).
Mandatory-to-Specify: No. Default is EC-DSA.
Property: digital-signature-algorithm-set
Description: Allowable digital signature function set that the
Signed URI's Digital Signature Algorithm information element
can reference.
Type: List of Strings
Mandatory-to-Specify: No. Default is to allow any DSA.
Property: version
Description: Designated version used for URI Signing
computation when the Signed URI does not contain the VER
attribute.
Type: Integer
Mandatory-to-Specify: No. Default is 1.
Leung, et al. Expires July 2, 2016 [Page 28]
Internet-Draft CDNI URI Signing December 2015
Property: version-set
Description: Allowable version set that the Signed URI's VER
attribute can reference.
Type: List of Integers
Mandatory-to-Specify: No. Default is to allow any version.
Property: package-attribute
Description: Overwrite the default name for the URL Signing
Package Attribute.
Type: String
Mandatory-to-Specify: No. Default is "URISigningPackage".
Note that the Key ID information element 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
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 or configuration MUST provide the
allowable Key ID set to authorize the Key ID information element
embedded in the Signed URI.
5.5. CDNI Logging Interface
For URI Signing, the Downstream CDN reports that enforcement of the
access control was applied to the request for content delivery. When
the request is denied due to enforcement of URI Signing, the reason
is logged.
The following CDNI Logging field for URI Signing SHOULD be supported
in the HTTP Request Logging Record as specified in CDNI Logging
Interface [I-D.ietf-cdni-logging].
o s-uri-signing (mandatory):
* format: 3DIGIT
* field value: this characterises the URI signing validation
performed by the Surrogate on the request. The allowed values
are:
Leung, et al. Expires July 2, 2016 [Page 29]
Internet-Draft CDNI URI Signing December 2015
+ "000" : no URI signature validation performed
+ "200" : URI signature validation performed and validated
+ "400" : URI signature validation performed and rejected
because of incorrect signature
+ "401" : URI signature validation performed and rejected
because of Expiration Time enforcement
+ "402" : URI signature validation performed and rejected
because of Client IP enforcement
+ "403" : URI signature validation performed and rejected
because of URI Pattern enforcement
+ "500" : unable to perform URI signature validation because
of malformed URI
+ "501" : unable to perform URI signature validation because
of unsupported version number
* occurrence: there MUST be zero or exactly one instance of this
field.
o s-uri-signing-deny-reason (optional):
* format: QSTRING
* field value: a string for providing further information in case
the URI signature was rejected, e.g. for debugging purposes.
* occurrence: there MUST be zero or exactly one instance of this
field.
6. URI Signing Message Flow
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.
6.1. HTTP Redirection
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
Leung, et al. Expires July 2, 2016 [Page 30]
Internet-Draft CDNI URI Signing December 2015
(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 FCI 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.Authorization 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 | |
Leung, et al. Expires July 2, 2016 [Page 31]
Internet-Draft CDNI URI Signing December 2015
| | 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
1. Using the CDNI Footprint & Capabilities Advertisement interface,
the Downstream CDN advertises its capabilities including URI
Signing support to the Authoritative CDN.
2. 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.
3. 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 the URI query
string parameter name for the URI Signing Package Attribute, a
hashing algorithm and/or a key corresponding to the trust
relationship between the Authoritative CDN and the Downstream
CDN.
4. 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
5. If the authorization decision is negative, the CSP rejects the
request.
6. 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.
7. On receipt of the corresponding content request, the
authoritative CDN validates the URI Signature in the URI using
the information provided by the CSP.
Leung, et al. Expires July 2, 2016 [Page 32]
Internet-Draft CDNI URI Signing December 2015
8. If the validation is negative, the authoritative CDN rejects the
request
9. 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
10. 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
11. If the validation is negative, the Downstream CDN rejects the
request and sends an error code (e.g. 403) in the HTTP response.
12. If the validation is positive, the Downstream CDN serves the
request and delivers the content.
13. 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.
6.2. DNS Redirection
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 FCI interface used to | |
| advertise URI Signing capability| |
Leung, et al. Expires July 2, 2016 [Page 33]
Internet-Draft CDNI URI Signing December 2015
| |------------------->| |
| | | |
| 2.Provides information to validate URI signature|
| | |<-------------------|
| 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| |
| |<-------------------| |
|4.Authorization 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
Leung, et al. Expires July 2, 2016 [Page 34]
Internet-Draft CDNI URI Signing December 2015
1. Using the CDNI Footprint & Capabilities Advertisement interface,
the Downstream CDN advertises its capabilities including URI
Signing support to the Authoritative CDN.
2. 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.
3. Using the CDNI Metadata interface, the Authoritative CDN
communicates to a Downstream CDN the information needed to
validate cryptographic signatures from the CSP (e.g. the URI
query string parameter name for the URI Signing Package
Attribute). In the case of symmetric key, the Authoritative CDN
checks if the Downstream CDN is allowed by CSP to obtain the
shared secret key.
4. 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.
5. If the authorization decision is negative, the CSP rejects the
request
6. 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.
7. End user sends DNS request to the authoritative CDN.
8. On receipt of the DNS request, the authoritative CDN redirects
the request to the Downstream CDN.
9. End user sends DNS request to the Downstream CDN.
10. On receipt of the DNS request, the Downstream CDN responds with
IP address of one of its Surrogates.
11. 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
12. If the validation is negative, the Downstream CDN rejects the
request and sends an error code (e.g. 403) in the HTTP response.
Leung, et al. Expires July 2, 2016 [Page 35]
Internet-Draft CDNI URI Signing December 2015
13. If the validation is positive, the Downstream CDN serves the
request and delivers the content.
14. 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 not 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.
7. HTTP Adaptive Streaming
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 [RFC6983]. [Editor
note: DASH draft discussion]
8. IANA Considerations
[Editor's note: (Is there a need to) register default value for URI
Signing Package Attribute URI query string parameter name (i.e.
URISigningPackage) to be used for URI Signing? Need anything from
IANA?]
[Editor's note: To do: Convert to proper IANA Registry format]
This document requests IANA to create three new URI Signing
registries for the Information Elements and their defined values to
be used for URI Signing.
The following Enforcement Information Element names are allocated:
o ET (Expiry time)
o CIP (Client IP address)
Leung, et al. Expires July 2, 2016 [Page 36]
Internet-Draft CDNI URI Signing December 2015
The following Signature Computation Information Element names are
allocated:
o VER (Version): 1 (Base)
o KID (Key ID)
o KID_NUM (Numerical Key ID)
o HF (Hash Function): "SHA-256"
o DSA (Digital Signature Algorithm): "EC-DSA"
The following URI Signature Information Element names are allocated:
o MD (Message Digest for Symmetric Key)
o DS (Digital Signature for Asymmetric Keys)
The IANA is requested to allocate a new entry to the CDNI Logging
Field Names Registry as specified in CDNI Logging Interface
[I-D.ietf-cdni-logging] in accordance to the "Specification Required"
policy [RFC5226]
o s-uri-signing
o s-uri-signing-deny-reason
The IANA is requested to allocate a new entry to the "CDNI
GenericMetadata Types" Registry as specified in CDNI Metadata
Interface [I-D.ietf-cdni-metadata] in accordance to the
"Specification Required" policy [RFC5226]:
+------------+---------------+---------+------+------+
| Type name | Specification | Version | MTE | STR |
+------------+---------------+---------+------+------+
| UriSigning | RFCthis | 1 | true | true |
+------------+---------------+---------+------+------+
The IANA is also requested to allocate a new MIME type under the IANA
MIME Media Type registry for the UriSigning metadata object:
application/cdni.UriSigning.v1
Leung, et al. Expires July 2, 2016 [Page 37]
Internet-Draft CDNI URI Signing December 2015
9. Security Considerations
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 appropriate.
In general, it holds that the level of protection against
illegitimate access can be increased by including more Enforcement
Information Elements in the URI. The current version of this
document includes elements 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.
Leung, et al. Expires July 2, 2016 [Page 38]
Internet-Draft CDNI URI Signing December 2015
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.
In the case where asymmetric keys are used, the KID information
element might contain the URL to the public key. To prevent
malicious clients from signing their own URIs and inserting the
associated public key URL in the KID field, thereby passing URI
validation, it is important that CDNs check whether the URI conveyed
in the KID field is in the allowable set of KIDs as listed in the
CDNI metadata or set via configuration.
10. Privacy
The privacy protection concerns described in CDNI Logging Interface
[I-D.ietf-cdni-logging] apply when the client's IP address (CIP
attribute) is embedded in the Signed URI. For this reason, the
mechanism described in Section 3 encrypts the Client IP before
including it in the URI Signing Package (and thus the URL itself).
11. Acknowledgements
The authors would like to thank the following people for their
contributions in reviewing this document and providing feedback:
Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan
York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana
Oprescu, Leif Hedstrom and Phil Sorber. In addition, Matt Caulfield
provided content for the CDNI Metadata Interface section.
12. References
12.1. Normative References
[I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-21 (work in progress), November 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
Leung, et al. Expires July 2, 2016 [Page 39]
Internet-Draft CDNI URI Signing December 2015
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>.
12.2. Informative References
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni-
metadata-12 (work in progress), October 2015.
[I-D.ietf-cdni-redirection]
Niven-Jenkins, B. and R. Brandenburg, "Request Routing
Redirection Interface for CDN Interconnection", draft-
ietf-cdni-redirection-13 (work in progress), October 2015.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>.
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection (CDNI)",
RFC 6983, DOI 10.17487/RFC6983, July 2013,
<http://www.rfc-editor.org/info/rfc6983>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <http://www.rfc-editor.org/info/rfc7336>.
Leung, et al. Expires July 2, 2016 [Page 40]
Internet-Draft CDNI URI Signing December 2015
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Network Interconnection (CDNI) Requirements", RFC 7337,
DOI 10.17487/RFC7337, August 2014,
<http://www.rfc-editor.org/info/rfc7337>.
Authors' Addresses
Kent Leung
Cisco Systems
3625 Cisco Way
San Jose 95134
USA
Phone: +1 408 526 5030
Email: kleung@cisco.com
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
Ray van Brandenburg
TNO
Anna van Buerenplein 1
Den Haag 2595DC
the Netherlands
Phone: +31 88 866 7000
Email: ray.vanbrandenburg@tno.nl
Bill Downey
Verizon Labs
60 Sylvan Road
Waltham, Massachusetts 02451
USA
Phone: +1 781 466 2475
Email: william.s.downey@verizon.com
Leung, et al. Expires July 2, 2016 [Page 41]
Internet-Draft CDNI URI Signing December 2015
Michel Fisher
Limelight Networks
222 S Mill Ave
Tempe, AZ 85281
USA
Phone: +1 360 419 5185
Email: mfisher@llnw.com
Leung, et al. Expires July 2, 2016 [Page 42]