Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

URI Signing for CDN Interconnection (CDNI)
draft-leung-cdni-uri-signing-02

Versions:

The information below is for an old version of the document.

Document	Type	This is an older version of an Internet-Draft whose latest revision state is "Replaced".
	Authors	Kent Leung , François Le Faucheur , Bill Downey , Ray van Brandenburg , Scott Leibrand
	Last updated	2013-05-31
	Replaced by	draft-ietf-cdni-uri-signing, draft-ietf-cdni-uri-signing, RFC 9246
	RFC stream	(None)
	Formats	txt xml htmlized pdf bibtex bibxml
Stream	Stream state	(No stream defined)
	Consensus boilerplate	Unknown
	RFC Editor Note	(None)
IESG	IESG state	I-D Exists
	Telechat date	(None)
	Responsible AD	(None)
	Send notices to	(None)

Email authors IPR References Referenced by Nits Search email archive

draft-leung-cdni-uri-signing-02

CDNI K. Leung
Internet-Draft F. Le Faucheur
Intended status: Standards Track Cisco Systems
Expires: December 2, 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

Abstract

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.

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 2, 2013.

Leung, et al. Expires December 2, 2013 [Page 1]
Internet-Draft CDNI URI Signing May 2013

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 . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. URI Signing Overview . . . . . . . . . . . . . . . . . . . 4
2. Signed URI Format . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Enforcement Attributes . . . . . . . . . . . . . . . . . . 8
2.2. Signature Computation Attributes . . . . . . . . . . . . . 9
2.3. URI Signature Attributes . . . . . . . . . . . . . . . . . 9
2.4. URI Signing Token Attribute . . . . . . . . . . . . . . . 10
3. Signing a URI . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Validating a URI Signature . . . . . . . . . . . . . . . . . . 14
5. Considerations for CDNI Interfaces . . . . . . . . . . . . . . 17
5.1. CDNI Request Routing/Footprint & Capabilities
Advertisement Interface . . . . . . . . . . . . . . . . . 17
5.2. CDNI Request Routing/Redirection Interface . . . . . . . . 18
5.3. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 18
5.4. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 19
6. Detailed URI Signing Operation . . . . . . . . . . . . . . . . 19
6.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . . 19
6.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 22
7. HTTP Adaptive Bit Rate . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28

Leung, et al. Expires December 2, 2013 [Page 2]
Internet-Draft CDNI URI Signing May 2013

1. Introduction

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.

1.1. Terminology

This document uses the terminology defined in CDNI Problem Statement
[RFC6707].

Leung, et al. Expires December 2, 2013 [Page 3]
Internet-Draft CDNI URI Signing May 2013

This document also uses the terminology of Keyed-Hashing for Message
Authentication (HMAC) [RFC2104] including the following terms
(reproduced here for convenience):

o MAC: message authentication code.

o HMAC: Hash-based message authentication code (HMAC) is a specific
construction for calculating a MAC involving a cryptographic hash
function in combination with a secret key.

o HMAC-SHA1: HMAC instantiation using SHA1 as the cryptographic hash
function.

o HMAC-MD5: HMAC instantiation using MD5 as the cryptographic hash
function.

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. URI Signing Overview

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

Leung, et al. Expires December 2, 2013 [Page 4]
Internet-Draft CDNI URI Signing May 2013

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).

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

Leung, et al. Expires December 2, 2013 [Page 5]
Internet-Draft CDNI URI Signing May 2013

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
(Section 6).

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

Leung, et al. Expires December 2, 2013 [Page 6]
Internet-Draft CDNI URI Signing May 2013

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.

2. Signed URI Format

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:

o Enforcement Attributes: Attributes that are used to enforce a
distribution policy defined by the CSP. Examples of enforcement
attributes are IP address of the UA and time window.

o Signature Computation Attributes: Attributes that are used by the
CDN to verify the URI signature embedded in the received URI. In
order to verify a URI signature, the CDN requires some attributes
that describe how the URI signature was generated. Examples of
Signature Computation Attributes include the used HMAC's hash
function and/or the key identifier.

o URI Signature Attributes: The attribute that contains the actual
message digest or digital signature representing the URI signature

Leung, et al. Expires December 2, 2013 [Page 7]
Internet-Draft CDNI URI Signing May 2013

and conveying the integrity and authenticity of the URI.

o URI Signing Token Attribute: The attribute that obfuscates all the
other URI Signing attributes in the Signed URI.

Two types of keys can be used for URI Signing: asymmetric keys and
symmetric keys. Asymmetric keys are based on a public/private key
pair mechanism and always contain a private key only known to the CDN
(or CSP) signing the URI and a public key for the verification of the
Signed URI. Regardless of the type of key used, the entity that
validates the URI has to obtain the key. There are very different
requirements for key distribution 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.

2.1. Enforcement Attributes

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:

o Expiry Time (ET) [optional] - Time when the Signed URI expires.
This is represented in seconds since midnight 1/1/1970 UTC (i.e.
UNIX epoch). The request is rejected if the received time is
later than this timestamp. Note: The time including time zone on
the entities that generate and validate the signed URI need to be
in sync (e.g. NTP is used).

o Client IP (CIP) [optional] - IP address of the client for which
this signed URI is generated. This is represented in dotted
decimal format for IPv4 or canonical text representation for IPv6
address [RFC5952] . The request is rejected if sourced from a
client with a different IP address.

The Expiry Time attribute ensures that the content authorization

Leung, et al. Expires December 2, 2013 [Page 8]
Internet-Draft CDNI URI Signing May 2013

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.

2.2. Signature Computation Attributes

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).

o Version (VER) [optional] - An integer used for identifying the
version of URI signing method.

o Key ID (KID) [optiona] - A string used for obtaining the key (e.g.
database lookup, URI reference) which is needed to validate the
URI signature.

o Hash Function (HF) [optional] - A string used for identifying the
hash function to compute the URI signature (e.g. "MD5", "SHA1")
with HMAC.

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.

2.3. URI Signature Attributes

The following attributes are used to convey the actual URI signature.

Leung, et al. Expires December 2, 2013 [Page 9]
Internet-Draft CDNI URI Signing May 2013

o Message Digest (MD) [mandatory for symmetric key] - A string used
for the message digest generated by the URI signer.

o Digital Signature (DS) [mandatory for asymmetric keys] - A string
used for the digital signature provided by the URI signer.

The Message Digest attribute contains the message digest used to
validate the Signed URI when symmetric key is used. In the case of
symmetric key, HMAC algorithm is used for the following reasons: 1)
Ability to use hash functions (i.e. no changes needed) with well
understood cryptographic properties that perform well and for which
code is freely and widely available, 2) Easy to replace the embedded
hash function in case faster or more secure hash functions are found
or required, 3) Original performance of the hash function is
maintained without incurring a significant degradation, and 4) Simple
way to use and handle keys.

The Digital Signature attribute contains the digital signature used
to verify the Signed URI when asymmetric keys are used. In the case
of asymmetric keys, Elliptic Curve Digital Signature Algorithm (EC
DSA) - a variant of DSA - is used because of the following reasons:
1) Key size is small while still offering good security, 2) Key is
easy to store, and 3) Computation is faster than DSA or RSA.

2.4. URI Signing Token Attribute

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.

o URI Signing Token (UST) [optional] - The encoded token containing
the URI Signing attributes.

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.

Leung, et al. Expires December 2, 2013 [Page 10]
Internet-Draft CDNI URI Signing May 2013

3. Signing a 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 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.

1. Copy the Original URI, excluding the "scheme name" part, into a
buffer to hold the message for performing the operations below.

2. Check if the URI already contains a query string. If not,
append a "?" character. If yes, append an "&" character.

3. If the version needs to be specified, then append the string
"VER=1". This represents the version of URI Signing specified
by this document.

4. If time window enforcement is needed, then perform the this step
and the next two steps. Append the string "&ET=".

5. Get the current time in seconds since epoch (as an integer).
Add the validity time in seconds as an integer.

6. Convert this integer to a string and append to the message.

7. If client IP address enforcement is needed, then perform this
step and the next step. Append the string "&CIP=".

8. Convert the client's IP address in dotted decimal notation
format (i.e. for IPv4 address) or canonical text representation
(for IPv6 address [RFC5952]) to a string and append to the
message.

Leung, et al. Expires December 2, 2013 [Page 11]
Internet-Draft CDNI URI Signing May 2013

9. Depending on the type of key used to sign the URI, compute the
message digest or digital signature for symmetric key or
asymmetric keys, respectively.

A. For symmetric key, HMAC is used.

a. Obtain the shared key to be used for signing the URI.

b. If the key identifier needs to be specified, then
perform this step and the next step. Append the string
"&KID=".

c. Append the key identifier (e.g. "example:keys:123")
needed by the entity to locate the shared key for
validating the URI signature.

d. If the hash function for HMAC needs to be specified,
then perform this step and the next step. Append the
string "&HF=".

e. Append the string for the type of hash function (e.g.
"MD5", "SHA-1")

f. Append the string "&MD=".

g. The message contains the complete section of the URI
that is protected. (e.g. "://example.com/
content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&
KID=example:keys:123&HF=SHA-1&MD=").

h. Compute the message digest (note: this is the URI
signature) using the HMAC algorithm with the shared key
and message as the two inputs to the hash function which
is specified by the "HF" attribute.

i. Convert the message digest to its equivalent human
readable value.

j. Append the string for the message digest (e.g. "://
example.com/
content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&
KID=example:keys:123&HF=SHA-1&
MD=4fb1c1adf1588fbe11cc6a04c6e69f35").

B. For asymmetric keys, EC DSA is used.

a. Generate the EC private and public key pair. Store the
EC public key in a location that's reachable for any

Leung, et al. Expires December 2, 2013 [Page 12]
Internet-Draft CDNI URI Signing May 2013

entity that needs to validate the URI signature.

b. If the key identifier needs to be specified, then
perform this step and the next step. Append the string
"&KID=".

c. Append the key identifier (e.g.
"http://example.com/public/keys/123") needed by the
entity to locate the shared key for validating the URI
signature. Note the Key ID URI contains only the
"scheme name", "authority", and "path" parts.

d. Append the string "&DS=".

e. The message contains the complete section of the URI
that is protected. (e.g. "://example.com/
content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=http://
example.com/public/keys/123&DS=").

f. Compute the message digest using SHA-1 (without a key)
for the message.

g. Compute the digital signature (note: this is the URI
signature) using the EC DSA algorithm with the private
EC key and message digest (obtained in previous step) as
inputs.

h. Convert the digital signature to its equivalent human
readable value.

i. Append the string for the digital signature which
contains the values for the 'r' and 's' parameters. The
(r,s) pair is denoted by ':' (e.g. "://example.com/
content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=http://
example.com/public/keys/
123&
DS=r:
CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1
E005668D:s:
57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929
A29EA24E" )

10. Generate the Signed URI (i.e. when tokenizing the URI Signing
attributes is not necessary) by prepending the "scheme name"
part to the message (e.g. http://example.com/
content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=http://
example.com/public/keys/
123&

Leung, et al. Expires December 2, 2013 [Page 13]
Internet-Draft CDNI URI Signing May 2013

DS=r:
CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D
:s:
57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24E
" ). Note: this is the completed Signed URI.

When tokenizing the URI Signing attributes is desired, follow the
procedure below.

1. Generate the URI Signing token in this step and the next step.
Remove the Original URI portion from the message to obtain all
the URI Signing attributes, including the URI signature ("VER=1&
ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&HF=SHA-1&
MD=4fb1c1adf1588fbe11cc6a04c6e69f35").

2. Compute the URI Signing token using Base-64 Data Encoding
[RFC4648] on the message (e.g. "VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9
MTAuMC4wLjEmS0lEPWZvb2JhcjprZXlzOjEyMyZIRj1TSEEtMSZNRD00ZmIxYzFhZ
GYxNTg4ZmJlMTFjYzZhMDRjNmU2OWYzNQ==") Note: This is the value for
the URI Signing token.

3. Append the URI Signing token to the Original URI in this step and
the next three steps. Copy the entire Original URI into a buffer
to hold the message.

4. Check if the URI already contains a query string. If not, append
a "?" character. If yes, append an "&" character.

5. Append the string "UST=" to the message.

6. Append the URI Signing token to the message (e.g. "http://
example.com/
content.mov?UST=VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjEmS0lEP
WZvb2JhcjprZXlzOjEyMyZIRj1TSEEtMSZNRD00ZmIxYzFhZGYxNTg4ZmJlMTFjYz
ZhMDRjNmU2OWYzNQ=="). Note: This is the complete Signed URI.

4. Validating a URI Signature

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.

Leung, et al. Expires December 2, 2013 [Page 14]
Internet-Draft CDNI URI Signing May 2013

1. Extract the value from "UST" attribute if the attribute exists.
This value is the encoded URI Signing token. If there is no
token in the URI, then skip the next step.

2. Decode the string using Base-64 Data Encoding [RFC4648] (or
another encoding method specified by configuration or CDNI
metada) to obtain all the URI Signing attributes (e.g. "VER=1&
ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&HF=SHA-1&
MD=4fb1c1adf1588fbe11cc6a04c6e69f35").

3. Extract the value from "VER" attribute if the attribute exists.
Determine the version of the URI Signing algorithm used to
process the Signed URI. If the attribute is not in the URI, then
obtain the version number in another manner (e.g. configuration
or CDNI metadata).

4. Extract the value from "CIP" attribute if the attribute exists.
Validate that the request came from the same IP address as
indicated in the "CIP" attribute. If the IP address is
incorrect, then the request is denied.

5. Extract the value from "ET" attribute if the attribute exists.
Validate that the request arrived before expiration time based on
the "ET" attribute. If the time expired, then the request is
denied.

6. Extract the value from "MD" attribute if the attribute exists.
The attribute indicates symmetric key is used.

7. Extract the value from "DS" attribute if the attribute exists.
The attribute indicates asymmetric key is used.

8. If neither "MD" or "DS" attribute is in the URI, then no URI
signature exists and the request is denied.

Validate the URI signature for the Signed URI.

1. Copy the Original URI, excluding the "scheme name" part, into a
buffer to hold the message for performing the operations below.

2. Remove the "UST" attribute from the message.

3. Append the decoded value from "UST" attribute (which contains all
the URI Signing attributes).

4. Depending on the type of key used to sign the URI, validate the
message digest or digital signature for symmetric key or
asymmetric keys, respectively.

Leung, et al. Expires December 2, 2013 [Page 15]
Internet-Draft CDNI URI Signing May 2013

A. For symmetric key, HMAC algorithm is used.

a. Extract the value from the "KID" attribute if the
attribute exists. Use the key identifier (e.g. "example:
keys:123") to locate the shared key, which may be one of
the keys available to use (i.e. set by configuration or
CDNI metadata). If the attribute is not in the URI, then
obtain the key in another manner (e.g. configuration or
CDNI metadata).

b. Extract the value from the "HF" attribute if the
attribute exists. Determine the type of hash function
(e.g. "MD5", "SHA-1") to use for HMAC. If the attribute
is not in the URI, then obtain the hash function type in
another manner (e.g. configuration or CDNI metadata).

c. Extract the value from the "MD" attribute. This is the
received message digest.

d. Convert the message digest to binary format. This will
be used to compare with the computed value later.

e. Remove the value part of the "MD" attribute (but not the
'=' character) from the message. The message is ready
for validation of the message digest (e.g. "://
example.com/
content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&
KID=example:keys:123&HF=SHA-1&MD=").

f. Compute the message digest using the HMAC algorithm with
the shared key and message as the two inputs to the hash
function which is specified by the "HF" attribute.

g. Compare the result with the received message digest to
validate the Signed URI.

B. For asymmetric keys, EC DSA is used.

a. Extract the value from the "KID" attribute. Use the key
identifier (e.g. "http://example.com/public/keys/123") to
obtain the EC public key, which may be one of the keys
available to use (i.e. set by configuration or CDNI
metadata). If the attribute is not in the URI, then
obtain the key in another manner (e.g. configuration or
CDNI metadata).

b. Extract the value from the "DS" attribute. This is the
digital signature.

Leung, et al. Expires December 2, 2013 [Page 16]
Internet-Draft CDNI URI Signing May 2013

c. Convert the digital signature to binary format. This
will be used for verification later.

d. Remove the value part of the "DS" attribute (but not the
'=' character) from the message. The message is ready
for validation of the digital signature (e.g. "://
example.com/
content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=http://
example.com/public/keys/123&DS=").

e. Compute the message digest using SHA-1 (without a key)
for the message.

f. Verify the digital signature using the EC DSA algorithm
with the public EC key, received digital signature, and
message digest (obtained in previous step) as inputs.
This validates the Signed URI.

5. Considerations for 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 Request Routing/Footprint & Capabilities Advertisement
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.

o URI Signing version

Leung, et al. Expires December 2, 2013 [Page 17]
Internet-Draft CDNI URI Signing May 2013

5.2. CDNI Request Routing/Redirection Interface

Editor's Note: Check if there is an impact on CDNI RI?

TBD: CDNI Redirection Interface is work in progress.

5.3. CDNI Metadata Interface

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.

o Content access control indication.

o Type of access control. Specifically, access to content is
subject to URI Signing. URI Signing required indication means
Downstream CDN ensures URI must be signed and validated before
content delivery. Otherwise, Downstream CDN does not perform
validation regardless if URI is signed or not.

o Version of URI Signing to use for validating the Signed URI

o Key value along with its key index (i.e. Key ID) and type
(asymmetric or symmetric) used for validating URI signature.
There may be one or more keys available to use for validation.

o Authorization to distribute the key(s) to Downstream CDNs

o Hash function for HMAC to be used for validation (i.e. enforce a
specific hash function for security level)

o Encoding format to override the "UST" attribute. (Editor Note: Is
this needed in CDNI Metadata or defined in a new CDNI attribute?)

Leung, et al. Expires December 2, 2013 [Page 18]
Internet-Draft CDNI URI Signing May 2013

5.4. CDNI Logging Interface

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.

o URI signature validation events (e.g. invalid client IP address,
expired signed URI, incorrect URI signature, successful
validation)

o Delivery log with confirmation of access control enforcement (i.e
Delivery CDN enforced URI Signing before content delivery)

6. Detailed URI Signing Operation

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
(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.

Leung, et al. Expires December 2, 2013 [Page 19]
Internet-Draft CDNI URI Signing May 2013

| 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

1. Using the CDNI Request Routing/Footprint & Capabilities
Advertisement interface, the Downstream CDN advertises its
capabilities including URI Signing support to the Authoritative
CDN.

Leung, et al. Expires December 2, 2013 [Page 20]
Internet-Draft CDNI URI Signing May 2013

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 a hashing
algorithm and private 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.

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.

Leung, et al. Expires December 2, 2013 [Page 21]
Internet-Draft CDNI URI Signing May 2013

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

Leung, et al. Expires December 2, 2013 [Page 22]
Internet-Draft CDNI URI Signing May 2013

|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

1. Using the CDNI Request Routing 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. 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.

Leung, et al. Expires December 2, 2013 [Page 23]
Internet-Draft CDNI URI Signing May 2013

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.

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

Leung, et al. Expires December 2, 2013 [Page 24]
Internet-Draft CDNI URI Signing May 2013

7. HTTP Adaptive Bit Rate

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.

8. IANA Considerations

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

o ET (Expiry time)

o CIP (Client IP address)

The following Signature Computation Attributes names are allocated:

o VER (Version): 1(Base)

o KID (Key ID)

o HF (Hash Function): "MD5", "SHA1"

The following URI Signature Attributes names are allocated:

o MD (Message Digest)

o DS (Digital Signature)

The following URI Signing Token Attributes names are allocated:

Leung, et al. Expires December 2, 2013 [Page 25]
Internet-Draft CDNI URI Signing May 2013

o UST (URI Signing Token)

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 approriate.

In general it holds that the level of protection against illegitimate
access can be increased by including more Enforcement Attributes in
the URI. The current version of this document includes attributes
for enforcing Client IP Address and Expiration Time, however this
list can be extended with other, more complex, attributes that are
able to provide some form of protection against some of the
vulnerabilities highlighted below.

That said, there are a number of aspects that limit the level of
security offered by URI signing and that anybody implementing URI
signing should be aware of.

Replay attacks: Any (valid) Signed URI can be used to perform
replay attacks. The vulnerability to replay attacks can be
reduced by picking a relatively short window for the Expiration
Time attribute, although this is limited by the fact that any
HTTP-based request needs a window of at least a couple of seconds
to prevent any sudden network issues from preventing legitimate
UAs access to the content. One way to reduce exposure to replay
attacks is to include in the URI a unique one-time access ID.
Whenever the Downstream CDN receives a request with a given unique
access ID, it adds that access ID to the list of 'used' IDs. In
the case an illegitimate UA tries to use the same URI through a
replay attack, the Downstream CDN can deny the request based on
the already-used access ID.

Illegitimate client behind a NAT: In cases where there are
multiple users behind the same NAT, all users will have the same
IP address from the point of view of the Downstream CDN. This
results in the Downstream CDN not being able to distinguish
between the different users based on Client IP Address and
illegitimate users being able to access the content. One way to
reduce exposure to this kind of attack is to not only check for
Client IP but also for other attributes that can be found in the

Leung, et al. Expires December 2, 2013 [Page 26]
Internet-Draft CDNI URI Signing May 2013

HTTP headers.

TBD: ...

The shared key between CSP and Authoritative CDN may be distributed
to Downstream CDNs - including cascaded CDNs. Since this key can be
used to legitimately sign a URL for content access authorization,
it's important to know the implications of a compromised shared key.

10. Acknowledgements

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.

11. References

11.1. Normative References

[I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-03 (work in
progress), February 2013.

[I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements",
draft-ietf-cdni-requirements-06 (work in progress),
April 2013.

[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", draft-ietf-cdni-use-cases-10 (work in
progress), August 2012.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.

[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem

Leung, et al. Expires December 2, 2013 [Page 27]
Internet-Draft CDNI URI Signing May 2013

Statement", RFC 6707, September 2012.

11.2. Informative References

[I-D.brandenburg-cdni-has]
Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung,
"Models for adaptive-streaming-aware CDN Interconnection",
draft-brandenburg-cdni-has-05 (work in progress),
April 2013.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.

[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.

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

Leung, et al. Expires December 2, 2013 [Page 28]
Internet-Draft CDNI URI Signing May 2013

Bill Downey
Verizon Labs
60 Sylvan Road
Waltham, Massachusetts 02451
USA

Phone: +1 781 466 2475
Email: william.s.downey@verizon.com

Ray van Brandenburg
TNO
Brassersplein 2
Delft, 2612CT
the Netherlands

Phone: +31 88 866 7000
Email: ray.vanbrandenburg@tno.nl

Scott Leibrand
Limelight Networks
222 S Mill Ave
Tempe, AZ 85281
USA

Phone: +1 360 419 5185
Email: sleibrand@llnw.com

Leung, et al. Expires December 2, 2013 [Page 29]

URI Signing for CDN Interconnection (CDNI) draft-leung-cdni-uri-signing-02

URI Signing for CDN Interconnection (CDNI)
draft-leung-cdni-uri-signing-02