draft-ietf-cdni-uri-signing-06.txt   draft-ietf-cdni-uri-signing-07.txt 
CDNI K. Leung CDNI K. Leung
Internet-Draft F. Le Faucheur Internet-Draft F. Le Faucheur
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: July 2, 2016 R. van Brandenburg Expires: October 7, 2016 R. van Brandenburg
TNO TNO
B. Downey B. Downey
Verizon Labs Verizon Labs
M. Fisher M. Fisher
Limelight Networks Limelight Networks
December 30, 2015 April 5, 2016
URI Signing for CDN Interconnection (CDNI) URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-06 draft-ietf-cdni-uri-signing-07
Abstract Abstract
This document describes how the concept of URI signing supports the This document describes how the concept of URI signing supports the
content access control requirements of CDNI and proposes a URI content access control requirements of CDNI and proposes a URI
signing scheme. signing scheme.
The proposed URI signing method specifies the information needed to The proposed URI signing method specifies the information needed to
be included in the URI and the algorithm used to authorize and 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 validate access requests for the content referenced by the URI. The
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 2, 2016. This Internet-Draft will expire on October 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Background and overview on URI Signing . . . . . . . . . 4 1.2. Background and overview on URI Signing . . . . . . . . . 5
1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 5 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6
1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8
2. Signed URI Information Elements . . . . . . . . . . . . . . . 8 2. Signed URI Information Elements . . . . . . . . . . . . . . . 8
2.1. Enforcement Information Elements . . . . . . . . . . . . 10 2.1. Enforcement Information Elements . . . . . . . . . . . . 10
2.2. Signature Computation Information Elements . . . . . . . 11 2.2. Signature Computation Information Elements . . . . . . . 11
2.3. URI Signature Information Elements . . . . . . . . . . . 13 2.3. URI Signature Information Elements . . . . . . . . . . . 13
2.4. URI Signing Package Attribute . . . . . . . . . . . . . . 14 2.4. URI Signing Package Attribute . . . . . . . . . . . . . . 14
2.5. User Agent Attributes . . . . . . . . . . . . . . . . . . 15 2.5. User Agent Attributes . . . . . . . . . . . . . . . . . . 15
3. Creating the Signed URI . . . . . . . . . . . . . . . . . . . 15 3. Create a Signed URI . . . . . . . . . . . . . . . . . . . . . 15
3.1. Calculating the URI Signature . . . . . . . . . . . . . . 16 3.1. Compose URI Signing IEs with Protected URI . . . . . . . 16
3.2. Packaging the URI Signature . . . . . . . . . . . . . . . 19 3.2. Compute URI Signature . . . . . . . . . . . . . . . . . . 18
4. Validating a URI Signature . . . . . . . . . . . . . . . . . 20 3.3. Encode the URI Signing Package . . . . . . . . . . . . . 19
4.1. Information Element Extraction . . . . . . . . . . . . . 21 3.4. Assemble the Signed URI . . . . . . . . . . . . . . . . . 20
4.2. Signature Validation . . . . . . . . . . . . . . . . . . 22 4. Validate a Signed URI . . . . . . . . . . . . . . . . . . . . 20
4.3. Distribution Policy Enforcement . . . . . . . . . . . . . 24 4.1. Extract and Decode URI Signing Package . . . . . . . . . 21
4.2. Extract URI Signing IEs . . . . . . . . . . . . . . . . . 21
4.3. Obtain URI Signing IEs with Protected URI . . . . . . . . 22
4.4. Validate URI Signature . . . . . . . . . . . . . . . . . 23
4.5. Distribution Policy Enforcement . . . . . . . . . . . . . 25
5. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 25 5. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 25
5.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 25 5.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 26
5.2. CDNI Footprint & Capabilities Advertisement Interface . . 25 5.2. CDNI Footprint & Capabilities Advertisement Interface . . 26
5.3. CDNI Request Routing Redirection Interface . . . . . . . 26 5.3. CDNI Request Routing Redirection Interface . . . . . . . 27
5.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 26 5.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 27
5.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 29 5.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 30
6. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 30 6. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 32
6.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 30 6.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 32
6.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 33 6.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 35
7. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 7. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 8.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 38
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 38
12.1. Normative References . . . . . . . . . . . . . . . . . . 39 8.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . 40 8.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 8.4. CDNI URI Signing Enforcement Information Elements . . . . 39
8.5. CDNI URI Signing Signature Computation Information
Elements . . . . . . . . . . . . . . . . . . . . . . . . 40
8.6. CDNI URI Signing Signature Information Elements . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Normative References . . . . . . . . . . . . . . . . . . 43
12.2. Informative References . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of redirection used to provide access authorization in the case of redirection
between interconnected CDNs (CDNI) and between a Content Service between interconnected CDNs (CDNI) and between a Content Service
Provider (CSP) and a CDN. The primary goal of URI Signing is to make 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 sure that only authorized User Agents (UAs) are able to access the
content, with a CSP being able to authorize every individual request. content, with a CSP being able to authorize every individual request.
It should be noted that URI Signing is not a content protection It should be noted that URI Signing is not a content protection
skipping to change at page 3, line 45 skipping to change at page 4, line 10
using techniques such as URI signing." using techniques such as URI signing."
In particular, the following requirement is listed in CDNI In particular, the following requirement is listed in CDNI
Requirements [RFC7337]: Requirements [RFC7337]:
"MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow "MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow
signaling of authorization checks and validation that are to be signaling of authorization checks and validation that are to be
performed by the surrogate before delivery. For example, this could performed by the surrogate before delivery. For example, this could
potentially include: potentially include:
* need to validate URI signed information (e.g. Expiry time, Client * need to validate URI signed information (e.g., Expiry time, Client
IP address)." IP address)."
This document proposes a URI Signing scheme that allows Surrogates in This document proposes a URI Signing scheme that allows Surrogates in
interconnected CDNs to enforce a per-request authorization performed interconnected CDNs to enforce a per-request authorization performed
by the CSP. Splitting the role of performing per-request by the CSP. Splitting the role of performing per-request
authorization by CSP and the role of validation of this authorization authorization by CSP and the role of validation of this authorization
by the CDN allows any arbitrary distribution policy to be enforced by the CDN allows any arbitrary distribution policy to be enforced
across CDNs without the need of CDNs to have any awareness of the across CDNs without the need of CDNs to have any awareness of the
actual CSP distribution policy. actual CSP distribution policy.
skipping to change at page 4, line 25 skipping to change at page 4, line 38
[RFC6707]. [RFC6707].
This document also uses the terminology of Keyed-Hashing for Message This document also uses the terminology of Keyed-Hashing for Message
Authentication (HMAC) [RFC2104]. Authentication (HMAC) [RFC2104].
In addition, the following terms are used throughout this document: In addition, the following terms are used throughout this document:
o URI Signature: Message digest or digital signature that is o URI Signature: Message digest or digital signature that is
computed with an algorithm for protecting the URI. computed with an algorithm for protecting the URI.
o Original URI: The URI before URI Signing is applied. o Full Original URI: The URI before URI Signing is applied.
o Signed URI: Any URI that contains a URI Signature. o Signed URI: Any URI that contains a URI Signature.
o Target CDN URI: Embedded URI created by the CSP to direct UA 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 towards the Upstream CDN. The Target CDN URI can be signed by the
CSP and verified by the Upstream CDN. CSP and verified by the Upstream CDN.
o Redirection URI: URI created by the Upstream CDN to redirect UA o Redirection URI: URI created by the Upstream CDN to redirect UA
towards the Downstream CDN. The Redirection URI can be signed by towards the Downstream CDN. The Redirection URI can be signed by
the Upstream CDN and verified by the Downstream CDN. In a the Upstream CDN and verified by the Downstream CDN. In a
cascaded CDNI scenario, there can be more than one Redirection cascaded CDNI scenario, there can be more than one Redirection
URI. URI.
1.2. Background and overview on URI Signing 1.2. Background and overview on URI Signing
A CSP and CDN are assumed to have a trust relationship that enables 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 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 attributes in the URI before redirecting a UA to the CDN. Using
these attributes, it is possible for a CDN to check an incoming 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. 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 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 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 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 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 this reason, a URI Signing mechanism includes in the URI a message
digest or digital signature that allows a CDN to check the digest or digital signature that allows a CDN to check the
authenticity of the URI. The message digest or digital signature can authenticity of the URI. The message digest or digital signature can
be calculated based on a shared secret between the CSP and CDN or be calculated based on a shared secret between the CSP and CDN or
using CSP's asymmetric public/private key pair, respectively. using CSP's asymmetric public/private key pair, respectively.
skipping to change at page 8, line 8 skipping to change at page 8, line 8
Figure 2: URI Signing in a CDNI Environment Figure 2: URI Signing in a CDNI Environment
The trust relationships between CSP, Upstream CDN, and Downstream CDN The trust relationships between CSP, Upstream CDN, and Downstream CDN
have direct implications for URI Signing. In the case shown in 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 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 Upstream CDN. The delivery of the content may be delegated to the
Downstream CDN, which has a relationship with the Upstream CDN but Downstream CDN, which has a relationship with the Upstream CDN but
may have no relationship with the CSP. may have no relationship with the CSP.
In CDNI, there are two methods for request routing: DNS-based and In CDNI, there are two methods for request routing: DNS-based and
HTTP-based. For DNS-based request routing, the Signed URI (i.e. HTTP-based. For DNS-based request routing, the Signed URI (i.e.,
Target CDN URI) provided by the CSP reaches the Downstream CDN Target CDN URI) provided by the CSP reaches the Downstream CDN
directly. In the case where the Downstream CDN does not have a trust directly. In the case where the Downstream CDN does not have a trust
relationship with the CSP, this means that only an asymmetric public/ relationship with the CSP, this means that only an asymmetric public/
private key method can be used for computing the URI Signature private key method can be used for computing the URI Signature
because the CSP and Downstream CDN are not able to exchange symmetric because the CSP and Downstream CDN are not able to exchange symmetric
shared secret keys. Since the CSP is unlikely to have relationships shared secret keys. Since the CSP is unlikely to have relationships
with all the Downstream CDNs that are delegated to by the Upstream with all the Downstream CDNs that are delegated to by the Upstream
CDN, the CSP may choose to allow the Authoritative CDN to CDN, the CSP may choose to allow the Authoritative CDN to
redistribute the shared key to a subset of their Downstream CDNs . redistribute the shared key to a subset of their Downstream CDNs .
For HTTP-based request routing, the Signed URI (i.e. Target CDN URI) 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 provided by the CSP reaches the Upstream CDN. After this URI has
been verified to be correct by the Upstream CDN, the Upstream CDN 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 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, Downstream CDN. Since this new URI also has a new URI Signature,
this new signature can be based around the trust relationship between this new signature can be based around the trust relationship between
the Upstream CDN and Downstream CDN, and the relationship between the the Upstream CDN and Downstream CDN, and the relationship between the
Downstream CDN and CSP is not relevant. Given the fact that such a Downstream CDN and CSP is not relevant. Given the fact that such a
relationship between Upstream CDN and Downstream CDN always exists, relationship between Upstream CDN and Downstream CDN always exists,
both asymmetric public/private keys and symmetric shared secret keys both asymmetric public/private keys and symmetric shared secret keys
can be used for URI Signing. Note that the signed Redirection URI can be used for URI Signing. Note that the signed Redirection URI
MUST maintain the same, or higher, level of security as the original MUST maintain the same, or higher, level of security as the original
Signed URI. Signed URI.
1.4. URI Signing in a non-CDNI context 1.4. URI Signing in a non-CDNI context
While the URI signing scheme defined in this document was primarily While the URI signing scheme defined in this document was primarily
created for the purpose of allowing URI Signing in CDNI scenarios, 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 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 nothing in the defined URI Signing scheme that precludes it from
being used in a non-CDNI context. As such, the described mechanism 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 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 Section 1.2, for example to allow a CSP that uses different CDNs to
only have to implement a single URI Signing mechanism. only have to implement a single URI Signing mechanism.
2. Signed URI Information Elements 2. Signed URI Information Elements
The concept behind URI Signing is based on embedding in the Target The concept behind URI Signing is based on embedding in the Target
CDN URI/Redirection URI a number of information elements that can be CDN URI/Redirection URI a number of information elements that can be
skipping to change at page 10, line 26 skipping to change at page 10, line 26
enforced, the exact subset of information elements used in the URI enforced, the exact subset of information elements used in the URI
Signature of a given request is a deployment decision. The defined Signature of a given request is a deployment decision. The defined
keyword for each information element is specified in parenthesis keyword for each information element is specified in parenthesis
below. below.
The following information elements are used to enforce the The following information elements are used to enforce the
distribution policy: distribution policy:
o Expiry Time (ET) [optional] - Time when the Signed URI expires. o Expiry Time (ET) [optional] - Time when the Signed URI expires.
This is represented as an integer denoting the number of seconds This is represented as an integer denoting the number of seconds
since midnight 1/1/1970 UTC (i.e. UNIX epoch). The request is since midnight 1/1/1970 UTC (i.e., UNIX epoch). The request is
rejected if the received time is later than this timestamp. Note: rejected if the received time is later than this timestamp. Note:
The time, including time zone, on the entities that generate and The time, including time zone, on the entities that generate and
validate the signed URI need to be in sync. In the CDNI case, 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 this means that servers at both the CSP, uCDN and dCDN need to be
time-synchronized. It is RECOMMENDED to use NTP for this. time-synchronized. It is RECOMMENDED to use NTP for this.
o Client IP (CIP) [optional] - IP address, or IP prefix, for which o Client IP (CIP) [optional] - IP address, or IP prefix, for which
the Signed URI is valid. This is represented in CIDR notation, the Signed URI is valid. This is represented in CIDR notation,
with dotted decimal format for IPv4 or canonical text with dotted decimal format for IPv4 or canonical text
representation for IPv6 addresses [RFC5952] . The request is representation for IPv6 addresses [RFC5952]. The request is
rejected if sourced from a client outside of the specified IP rejected if sourced from a client outside of the specified IP
range. range.
o Original URI Container (OUC) [optional] - Container for holding o Original URI Container (OUC) [optional] - Container for holding
the Original URI while the URI signature is calculated. The the Full Original URI while the URI signature is calculated. The
Original URI Container information element is not transmitted as Original URI Container information element is not transmitted as
part of the URI Signing Package Attribute. If the Original URI part of the URI Signing Package Attribute. If the Original URI
Container information element is used, the URI Pattern Sequence Container information element is used, the URI Pattern Sequence
information element MUST NOT be used. information element MUST NOT be used.
o URI Pattern Container (UPC) [optional] - Container for one or more o URI Pattern Container (UPC) [optional] - Container for one or more
URI Patterns that describes for which content the Signed URI is URI Patterns that describes for which content the Signed URI is
valid. The URI Pattern Container contains an expression to match valid. The URI Pattern Container contains an expression to match
against the requested URI to check whether the requested content against the requested URI to check whether the requested content
is allowed to be requested. Multiple URI Patterns may be is allowed to be requested. Multiple URI Patterns may be
skipping to change at page 11, line 27 skipping to change at page 11, line 27
The Expiry Time Information Element ensures that the content The Expiry Time Information Element ensures that the content
authorization expires after a predetermined time. This limits the authorization expires after a predetermined time. This limits the
time window for content access and prevents replay of the request time window for content access and prevents replay of the request
beyond the authorized time window. beyond the authorized time window.
The Client IP Information Element is used to restrict content access 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 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 address for whom the content access was authorized. The URI Signing
mechanism described in this document will communicate the IP address mechanism described in this document will communicate the IP address
in the URI. To prevent the IP addess from being logged, the Client in the URI. To prevent the IP address from being logged, the Client
IP information element is transmited in encrypted form. IP information element is transmitted in encrypted form.
The Original URI Container is used to limit access to the Original The Original URI Container is used to limit access to the Original
URI only. URI only.
The URI Pattern Container Information Element is used to restrict The URI Pattern Container Information Element is used to restrict
content access to a particular set of URLs. content access to a particular set of URIs.
Note: See the Security Considerations (Section 9) section on the Note: See the Security Considerations (Section 9) section on the
limitations of using an expiration time and client IP address for limitations of using an expiration time and client IP address for
distribution policy enforcement. distribution policy enforcement.
2.2. Signature Computation Information Elements 2.2. Signature Computation Information Elements
This section identifies the set of information elements that may be This section identifies the set of information elements that may be
needed to verify the URI (signature). New information elements may needed to verify the URI (signature). New information elements may
be introduced in the future if new URI signing algorithms are be introduced in the future if new URI signing algorithms are
skipping to change at page 12, line 11 skipping to change at page 12, line 11
The following information elements are used to validate the URI by The following information elements are used to validate the URI by
recreating the URI Signature. recreating the URI Signature.
o Version (VER) [optional] - An 8-bit unsigned integer used for o Version (VER) [optional] - An 8-bit unsigned integer used for
identifying the version of URI signing method. If this identifying the version of URI signing method. If this
Information Element is not present in the URI Signing Package Information Element is not present in the URI Signing Package
Attribute, the default version is 1. Attribute, the default version is 1.
o Key ID (KID) [optional] - A string used for obtaining the key o Key ID (KID) [optional] - A string used for obtaining the key
(e.g. database lookup, URI reference) which is needed to validate (e.g., database lookup, URI reference) which is needed to validate
the URI signature. The KID and KID_NUM information elements MUST the URI signature. The KID and KID_NUM information elements MUST
NOT be present in the same URI Signing Package Attribute. NOT be present in the same URI Signing Package Attribute.
o Numerical Key ID (KID_NUM) [optional] - A 64-bit unsigned integer o Numerical Key ID (KID_NUM) [optional] - A 64-bit unsigned integer
used as an optional alternative for KID. The KID and KID_NUM used as an optional alternative for KID. The KID and KID_NUM
information elements MUST NOT be present in the same URI Signing information elements MUST NOT be present in the same URI Signing
Package Attribute. Package Attribute.
o Hash Function (HF) [optional] - A string used for identifying the o Hash Function (HF) [optional] - A string used for identifying the
hash function to compute the URI signature with HMAC. If this hash function to compute the URI signature with HMAC. If this
skipping to change at page 12, line 36 skipping to change at page 12, line 36
calculate the Digital Signature. If this Information Element is calculate the Digital Signature. If this Information Element is
not present in the URI Signing Package Attribute, the default is not present in the URI Signing Package Attribute, the default is
EC-DSA. EC-DSA.
o Client IP Encryption Algorithm (CEA) [optional] - Algorithm used o Client IP Encryption Algorithm (CEA) [optional] - Algorithm used
to encrypt the Client IP. If this Information Element is not to encrypt the Client IP. If this Information Element is not
present in the URI Signing Package Attribute, the default is AES- present in the URI Signing Package Attribute, the default is AES-
128. 128.
o Client IP Key ID (CKI) [optional] - A 64-bit unsigned integer used o Client IP Key ID (CKI) [optional] - A 64-bit unsigned integer used
for obtaining the key (e.g. database lookup) used for encrypting/ for obtaining the key (e.g., database lookup) used for encrypting/
decrypting the Client IP. decrypting the Client IP.
The Version Information Element indicates which version of URI The Version Information Element indicates which version of URI
signing scheme is used (including which attributes and algorithms are signing scheme is used (including which attributes and algorithms are
supported). The present document specifies Version 1. If the supported). The present document specifies Version 1. If the
Version attribute is not present in the Signed URI, then the version Version attribute is not present in the Signed URI, then the version
is obtained from the CDNI metadata, else it is considered to have 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 been set to the default value of 1. More versions may be defined in
the future. the future.
skipping to change at page 14, line 9 skipping to change at page 14, line 9
o Digital Signature (DS) [mandatory for asymmetric keys] - A string o Digital Signature (DS) [mandatory for asymmetric keys] - A string
used for the digital signature provided by the URI signing entity. used for the digital signature provided by the URI signing entity.
The Message Digest attribute contains the message digest used to The Message Digest attribute contains the message digest used to
validate the Signed URI when symmetric keys are used. validate the Signed URI when symmetric keys are used.
The Digital Signature attribute contains the digital signature used The Digital Signature attribute contains the digital signature used
to verify the Signed URI when asymmetric keys are used. to verify the Signed URI when asymmetric keys are used.
In the case of symmetric key, HMAC algorithm is used for the In the case of symmetric key, HMAC algorithm is used for the
following reasons: 1) Ability to use hash functions (i.e. no changes following reasons: 1) Ability to use hash functions (i.e., no changes
needed) with well understood cryptographic properties that perform needed) with well understood cryptographic properties that perform
well and for which code is freely and widely available, 2) Easy to 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 replace the embedded hash function in case faster or more secure hash
functions are found or required, 3) Original performance of the hash functions are found or required, 3) Original performance of the hash
function is maintained without incurring a significant degradation, function is maintained without incurring a significant degradation,
and 4) Simple way to use and handle keys. The default HMAC algorithm and 4) Simple way to use and handle keys. The default HMAC algorithm
used is SHA-256. used is SHA-256.
In the case of asymmetric keys, Elliptic Curve Digital Signature In the case of asymmetric keys, Elliptic Curve Digital Signature
Algorithm (EC DSA) - a variant of DSA - is used because of the Algorithm (EC DSA) - a variant of DSA - is used because of the
skipping to change at page 14, line 37 skipping to change at page 14, line 37
the URI Signing Information Elements defined in the previous the URI Signing Information Elements defined in the previous
sections. The URI Signing Information Elements are encoded and sections. The URI Signing Information Elements are encoded and
stored in this attribute. URI Signing Package Attribute is appended stored in this attribute. URI Signing Package Attribute is appended
to the Original URI to create the Signed URI. to the Original URI to create the Signed URI.
The primary advantage of the URI Signing Package Attribute is that it The primary advantage of the URI Signing Package Attribute is that it
avoids having to expose the URI Signing Information Elements directly avoids having to expose the URI Signing Information Elements directly
in the query string of the URI, thereby reducing the potential for a in the query string of the URI, thereby reducing the potential for a
namespace collision space within the URI query string. A side- namespace collision space within the URI query string. A side-
benefit of the attribute is the obfuscation performed by the URI benefit of the attribute is the obfuscation performed by the URI
Signing Package Attribute hides the information (e.g. client IP Signing Package Attribute hides the information (e.g., client IP
address) from view of the common user, who is not aware of the address) from view of the common user, who is not aware of the
encoding scheme. Obviously, this is not a security method since encoding scheme. Obviously, this is not a security method since
anyone who knows the encoding scheme is able to obtain the clear anyone who knows the encoding scheme is able to obtain the clear
text. Note that any parameters appended to the query string after text. Note that any parameters appended to the query string after
the URI Signing Package Attribute are not validated and hence do not the URI Signing Package Attribute are not validated and hence do not
affect URI Signing. affect URI Signing.
The following attribute is used to carry the encoded set of URI The following attribute is used to carry the encoded set of URI
Signing attributes in the Signed URI. Signing attributes in the Signed URI.
skipping to change at page 15, line 45 skipping to change at page 15, line 45
Note that a malicious UA might potentially use the ability to append 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 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 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. try to make the dCDN deliver an HD version of the requested content.
Since such an additional attribute is appended after the URI Signing Since such an additional attribute is appended after the URI Signing
Package Attribute it is not validated and will not affect the outcome Package Attribute it is not validated and will not affect the outcome
of the URI validation. In order to deal with this vulnerability, a of the URI validation. In order to deal with this vulnerability, a
dCDN is RECOMMENDED to ignore any query strings appended after the dCDN is RECOMMENDED to ignore any query strings appended after the
URI Signing Package Attribute for the purpose of content selection. URI Signing Package Attribute for the purpose of content selection.
3. Creating the Signed URI 3. Create a Signed URI
The following procedure for signing a URI defines the algorithms in The following procedure for signing a URI defines the algorithms in
this version of URI Signing. Note that some steps may be skipped if this version of URI Signing. Note that some steps may be skipped if
the CSP does not enforce a distribution policy and the Enforcement the CSP does not enforce a distribution policy and the Enforcement
Information Elements are therefore not necessary. A URI (as defined Information Elements are therefore not necessary. A URI (as defined
in URI Generic Syntax [RFC3986]) contains the following parts: scheme in URI Generic Syntax [RFC3986]) contains the following parts: scheme
name, authority, path, query, and fragment. If the Original URI name, authority, path, query, and fragment. If the Original URI
Container information element is used, all components except for the Container information element is used, all components except for the
scheme part are protected by the URI Signature. This allows the URI scheme part are protected by the URI Signature. This allows the URI
signature to be validated correctly in the case when a client signature to be validated correctly in the case when a client
performs a fallback to another scheme (e.g. HTTP) for a content item 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 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 URI Pattern Container information element is used, the CSP has full
flexibility to specify which elements of the URI (including the flexibility to specify which elements of the URI (including the
scheme part) are protected by the URI. scheme part) are protected by the URI.
The process of generating a Signed URI can be divided into two sets The process of generating a Signed URI can be divided into four sets
of steps: first, calculating the URI Signature and then, packaging of steps: 1) Compose URI Signing IEs with original URI / URI pattern,
the URI Signature and appending it to the Original URI. Note it is 2) Compute the URI Signature, 3) Encode the URI Signing Package, and
possible to use some other algorithm and implementation as long as 4) Assemble the parts to create the Signed URI. Note it is possible
the same result is achieved. An example for the Original URI, to use some other algorithm and implementation as long as the same
result is achieved. An example for the Full Original URI,
"http://example.com/content.mov", is used to clarify the steps. "http://example.com/content.mov", is used to clarify the steps.
3.1. Calculating the URI Signature 3.1. Compose URI Signing IEs with Protected URI
Calculate the URI Signature by following the procedure below. Calculate the URI Signature by following the procedure below.
1. Create an empty buffer for performing the operations below. 1. Create an empty buffer for performing the operations below.
2. Check if the Original URI already contains a query string. If 2. If the version is not the default value (i.e. "1"), perform this
not, place a "?" character in the buffer. If yes, place an "&" step. Specify the version by appending the string "VER=#" to the
character in the buffer. buffer, where '#' represents the new version number. The
following steps in the procedure are based on the initial version
of URI Signing specified by this document. For other versions,
reference the associated RFC for the URI signing procedure.
3. If the version is the default value (i.e. "1"), skip this step. 3. If time window enforcement is needed, perform 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 MUST be carried
over from the received Signed URI.
A. If an information element was added to the buffer, append an B. Get the current time in seconds since epoch (as an integer).
"&" character. Append the string "ET=". Note in the case Add the validity time in seconds as an integer. Note in the
of re-signing a URI, the information element is carried over case of re-signing a URI, the value MUST remain the same as
from the received Signed URI. the received Signed URI.
B. Get the current time in seconds since epoch (as an integer). C. Convert this integer to a string and append to the buffer.
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. 4. If client IP enforcement is needed, perform this step.
5. If client IP enforcement is not needed, step 5 can be skipped. A. Skip this step when the Client IP Encryption Algorithm used
is the default ("AES-128"). If an information element was
added to the buffer, append an "&" character. Append the
string "CEA=". Append the string for the Client IP
Encryption Algorithm to be used.
A. If the Client IP Encryption Algorithm used is the default B. If the Client IP Key Identifier is needed, perform this step.
("AES-128"), this step can be skipped. If an information If an information element was added to the buffer, append an
element was added to the message, append an "&" character. "&" character. Append the string "CKI=". Append the Client
append the string "CEA=". Append the string for the Client IP key identifier (e.g., "56128239") needed by the entity to
IP Encryption Algorithm to be used. locate the shared key for decrypting the Client IP.
B. If the Client IP Key Identifier is not needed, this step can C. If an information element was added to the buffer, append an
be skipped. If an information element was added to the "&" character. Append the string "CIP=".
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 D. Convert the client's IP address in CIDR notation (dotted
an "&" character. Append the string "CIP=". 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 a 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.5.
D. Convert the client's IP address in CIDR notation (dotted E. Convert the encrypted Client IP to its equivalent hexadecimal
decimal format for IPv4 or canonical text representation for format.
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 F. Append the value computed in the previous step to the buffer.
hexadecimal format.
F. Append the value computed in the previous step to the 5. If a Key ID information element is needed, perform this step. If
buffer. an information element was added to the buffer, 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.
6. If a Key ID information element is not needed, step 6 can be 6. If symmetric shared key is used, perform this step. However,
skipped. If an information element was added to the message, skip this step when the hash function for the HMAC uses the
append an "&" character. Append the string "KID=" in case a default value ("SHA-256"). If an information element was added
string-based Key ID is used, or "KID_NUM=" in case a numerical to the buffer, append an "&" character. Append the string "HF=".
Key ID is used. Append the key identifier (e.g. Append the string for the new hash function to be used. Note
"example:keys:123" or "56128239") needed by the entity to locate that re-signing a URI MUST use the same hash function as the
the shared key for validating the URI signature. received Signed URI or one of the allowable hash functions
designated by the CDNI metadata.
7. If asymmetric keys are used, step 7 can be skipped. If the hash 7. If asymmetric private/public keys are used, perform this step.
function for the HMAC uses the default value ("SHA-256"), step 7 However, skip this step when the digital signature algorithm uses
can be skipped. If an information element was added to the the default value ("EC-DSA"). If an information element was
message, append an "&" character. Append the string "HF=". added to the buffer, append an "&" character. Append the string
Append the string for the new type of hash function to be used. "DSA=". Append the string for the digital signature function.
Note that re-signing a URI MUST use the same hash function as Note that re-signing a URI MUST use the same digital signature
the received Signed URI or one of the allowable hash functions algorithm as the received Signed URI or one of the allowable
designated by the CDNI metadata. digital signature algorithms designated by the CDNI metadata.
8. If assymetric keys are used, step 8 can be skipped. If the 8. Depending on the type of URI enforcement used (Full Original URI
digital signature algorithm uses the default value ("EC-DSA"), or URI Pattern), add the appropriate information element.
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 A. If enforcement based on the Full Original URI, perform this
URI Pattern), add the appropriate information element. step. If an information element was added to the buffer,
append an "&" character. Append the string "OUC=". Append
the Original URI, excluding the "scheme name" part and the
"://" delimiter, to the buffer. Note: the Original URI
Container information element MUST be the last information
element in the buffer before the signature information
element.
A. If enforcement based on a (set of) URI Pattern is used, this B. If enforcement based on a URI Pattern, perform this step. If
step can be skipped. If an information element was added to an information element was added to the buffer, append an "&"
the message, append an &" character. Append the string character. Append the string "UPC=". Append the URI Pattern
"OUC=". Append the Original URI, excluding the "scheme Container in the form of a string to the buffer.
name" part and the '://' delimiter, to the buffer.
B. If enforcement based on the Original URI is used, this step 3.2. Compute URI Signature
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. Compute the URI Signature by following the procedure below. The
buffer from the previous section is used.
A. Obtain the shared key to be used for signing the URI. 1. If symmetric shared key is used, perform this step.
B. Append the string "MD=". The message now contains the A. Obtain the shared key to be used for signing the URI.
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 B. Append the string "MD=". The buffer now contains the
default SHA-256 hash function, or another hash function if complete section of the URI that is protected (e.g. "ET=1209
specified by the HF Information Element, with the shared key 422976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=examp
and message as the two inputs to the hash function. le:keys:123&OUC=example.com/content.mov&MD=").
D. Convert the message digest to its equivalent hexadecimal C. Compute the message digest using the HMAC algorithm and the
format. 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.
E. Append the string for the message digest (e.g. "ET=12094229 D. Convert the message digest to its equivalent hexadecimal
76&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example: format.
keys:123&OUC=example.com/content.mov&MD=1ecb1446a6431352aab0
fb6e0dca30e30356593a97acb972202120dc482bddaf").
11. If symmetric keys are used, step 11 can be skipped. E. Append the string for the message digest (e.g. "ET=120942297
6&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:ke
ys:123&OUC=example.com/content.mov&MD=1ecb1446a6431352aab0fb6
e0dca30e30356593a97acb972202120dc482bddaf").
A. Obtain the private key to be used for signing the URI. 2. If asymmetric private/public keys are used, perform this step.
B. If an information element was added to the message, append A. Obtain the private key to be used for signing the URI.
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 B. If an information element was added to the buffer, append an
the message. Note: The digital signature generated in the "&" character. Append the string "DS=". The buffer now
next step is calculated over the SHA-1 message digest, contains the complete section of the URI that is protected.
instead of over the cleartype message. This is done to (e.g. "ET=1209422976&CKI=311&CIP=90C913977933FC650E7186361A9
reduce the length of the digital signature, the URI Signing 3D6C3&KID=example:keys:123&OUC=example.com/content.mov&DS=").
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 C. Compute the message digest using SHA-1 (without a key) for
default or another algorithm if specified by the DSA the buffer. Note: The digital signature generated in the
Information Element, with the private EC key and message next step is calculated over the SHA-1 message digest,
digest (obtained in previous step) as inputs. instead of over the full cleartext buffer. 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.
E. Convert the digital signature to its equivalent hexadecimal D. Compute the digital signature, using the EC-DSA algorithm by
format. 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.
F. Append the string for the digital signature. In the case E. Convert the digital signature to its equivalent hexadecimal
where EC-DSA algorithm is used, this string contains the format.
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 F. Append the string for the digital signature. In the case
element was added to the buffer, step 12 can be skipped. Remove where EC-DSA algorithm is used, this string contains the
the Original URI Container from the buffer, including the values for the 'r' and 's' parameters, delimited by ':' (e.g.
preceding "&" character. (e.g. "ET=1209422976&CKI=311&CIP=90C91 "ET=1209422976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&K
3977933FC650E7186361A93D6C3&KID=example:keys:123&MD=1ecb1446a643 ID=example:keys:123&OUC=example.com/content.mov&DS=r:CFB03EDB
1352aab0fb6e0dca30e30356593a97acb972202120dc482bddaf") 33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D:s:57
ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24
E")
3.2. Packaging the URI Signature 3.3. Encode the URI Signing Package
Apply the URI Signing Package Attribute by following the procedure Encode the URI Signing Package by following the procedure below. The
below to generate the Signed URI. buffer from the previous section is used.
1. Start from the buffer created in Section 3.1. (e.g. "ET=1209422 1. If enforcement is based on the Full Original URI, this step is
976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:keys performed. Remove the Original URI Container Attribute from the
:123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc4 buffer, including the preceding "&" character (e.g. "ET=12094229
82bddaf"). 76&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:keys:
123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc48
2bddaf"). Note: This attribute is not needed in the encoded URI
Signing Package because the Full Original URI is part of the
Signed URI.
2. Compute the URI Signing Package Attribute using Base-64 Data 2. Compute the URI Signing Package Attribute using Base-64 Data
Encoding [RFC4648] on the message (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA Encoding [RFC4648] on the message (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA
7Q0tJPTMxMSZhbXA7Q0lQPTkwQzkxMzk3NzkzM0ZDNjUwRTcxODYzNjFBOTNENkMz 7Q0tJPTMxMSZhbXA7Q0lQPTkwQzkxMzk3NzkzM0ZDNjUwRTcxODYzNjFBOTNENkMz
JmFtcDtLSUQ9ZXhhbXBsZTprZXlzOjEyMyZhbXA7TUQ9MWVjYjE0NDZhNjQzMTM1M JmFtcDtLSUQ9ZXhhbXBsZTprZXlzOjEyMyZhbXA7TUQ9MWVjYjE0NDZhNjQzMTM1M
mFhYjBmYjZlMGRjYTMwZTMwMzU2NTkzYTk3YWNiOTcyMjAyMTIwZGM0ODJiZGRhZg mFhYjBmYjZlMGRjYTMwZTMwMzU2NTkzYTk3YWNiOTcyMjAyMTIwZGM0ODJiZGRhZg
=="). Note: This is the value for the URI Signing Package =="). Note: This is the value for the URI Signing Package
Attribute. Attribute.
3. Copy the entire Original URI into a buffer to hold the message. 3.4. Assemble the Signed URI
4. Check if the Original URI already contains a query string. If Assemble the parts to create the Signed URI by following the
not, append a "?" character. If yes, append an "&" character. procedure below.
5. Append the parameter name used to indicate the URI Signing 1. Copy the entire Full Original URI into a new empty buffer.
2. Check if the Full Original URI already contains a query string.
If not, append a "?" character. If yes, append an "&" character.
3. Append the parameter name used to indicate the URI Signing
Package Attribute, as communicated via the CDNI Metadata Package Attribute, as communicated via the CDNI Metadata
interface, followed by an "=". If none is communicated by the interface, followed by an "=". If none is communicated by the
CDNI Metadata interface, it defaults to "URISigningPackage". For CDNI Metadata interface, it defaults to "URISigningPackage". For
example, if the CDNI Metadata interface specifies "SIG", append example, if the CDNI Metadata interface specifies "SIG", append
the string "SIG=" to the message. the string "SIG=" to the message.
6. Append the URI Signing token to the message (e.g. 4. Append the URI Signing Package that was generated in previous
"http://example.com/content.mov?URISigningPackage=RVQ9MTIwOTQyMjk section (e.g. "http://example.com/content.mov?URISigningPackage=
3NiZhbXA7Q0tJPTMxMSZhbXA7Q0lQPTkwQzkxMzk3NzkzM0ZDNjUwRTcxODYzNjFB RVQ9MTIwOTQyMjk3NiZhbXA7Q0tJPTMxMSZhbXA7Q0lQPTkwQzkxMzk3NzkzM0ZDN
OTNENkMzJmFtcDtLSUQ9ZXhhbXBsZTprZXlzOjEyMyZhbXA7TUQ9MWVjYjE0NDZhN jUwRTcxODYzNjFBOTNENkMzJmFtcDtLSUQ9ZXhhbXBsZTprZXlzOjEyMyZhbXA7TU
jQzMTM1MmFhYjBmYjZlMGRjYTMwZTMwMzU2NTkzYTk3YWNiOTcyMjAyMTIwZGM0OD Q9MWVjYjE0NDZhNjQzMTM1MmFhYjBmYjZlMGRjYTMwZTMwMzU2NTkzYTk3YWNiOTc
JiZGRhZg=="). Note: this is the completed Signed URI. yMjAyMTIwZGM0ODJiZGRhZg=="). Note: this is the completed Signed
URI.
4. Validating a URI Signature 4. Validate a Signed URI
The process of validating a Signed URI can be divided into three sets The process of validating a Signed URI can be divided into five sets
of steps: first, extraction of the URI Signing information elements, of steps: 1) Extract and decode URI Signing Package from the Signed
then validation of the URI signature to ensure the integrity of the URI, 2) Extract the URI Signing information elements, 3) Obtain the
Signed URI, and finally, validation of the information elements to Protected URI, 4) Validate URI signature to ensure integrity of
ensure proper enforcement of the distribution policy. The integrity Signed URI, and 5) Ensure proper enforcement of the distribution
of the Signed URI is confirmed before distribution policy enforcement policy. The integrity of the Signed URI is confirmed before
because validation procedure would detect the right event when the distribution policy enforcement because validation procedure will
URI is tampered with. Note it is possible to use some other detect first if the URI has been tampered with. Note it is possible
algorithm and implementation as long as the same result is achieved. to use some other algorithm and implementation as long as the same
result is achieved.
4.1. Information Element Extraction 4.1. Extract and Decode URI Signing Package
Extract the information elements embedded in the URI. Note that some Extract the encoded URI Signing Package Attribute from the Signed
steps are to be skipped if the corresponding URI Signing information URI. The attribute is decoded for subsequent processing by the
elements are not embedded in the Signed URI. Downstream CDN.
1. Extract the value from 'URISigningPackage' attribute. This 1. Extract the value from 'URISigningPackage' attribute. This value
value is the encoded URI Signing Package Attribute. If there is the encoded URI Signing Package Attribute. If there are
are multiple instances of this attribute, the first one is used multiple instances of this attribute, the first one is used and
and the remaining ones are ignored. This ensures that the the remaining ones are ignored. This ensures that the Signed URI
Signed URI can be validated despite a client appending another can be validated despite a client appending another instance of
instance of the 'URISigningPackage' attribute. the 'URISigningPackage' attribute.
2. Decode the string using Base-64 Data Encoding [RFC4648] to 2. Decode the string using Base-64 Data Encoding [RFC4648] to obtain
obtain all the URI Signing information elements (e.g. "ET=12094 all the URI Signing information elements (e.g. "ET=1209422976&CK
22976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:k I=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:keys:123&M
eys:123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb97220212 D=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc482bdda
0dc482bddaf"). f").
3. Extract the value from "VER" if the information element exists 4.2. Extract URI Signing IEs
Extract the information elements in the URI Signing Package
Attribute. Note that some steps are to be skipped if the
corresponding URI Signing information elements are not embedded in
the attribute. Some of the information elements will be used to
validate the URI signature in the subsequent section.
1. Extract the value from "VER" if the information element exists
in the query string. Determine the version of the URI Signing in the query string. Determine the version of the URI Signing
algorithm used to process the Signed URI. If the CDNI Metadata algorithm used to process the Signed URI. If the CDNI Metadata
interface is used, check to see if the used version of the URI interface is used, check to see if the used version of the URI
Signing algorithm is among the allowed set of URI Signing Signing algorithm is among the allowed set of URI Signing
versions specified by the metadata. If this is not the case, versions specified by the metadata. If this is not the case,
the request is denied. If the information element is not in the the request is denied. If the information element is not in the
URI, then obtain the version number in another manner (e.g. URI, then obtain the version number in another manner (e.g.,
configuration, CDNI metadata or default value). configuration, CDNI metadata or default value).
4. Extract the value from "MD" if the information element exists in 2. Extract the value from "MD" if the information element exists in
the query string. The existence of this information element the query string. The existence of this information element
indicates a symmetric key is used. indicates a symmetric key is used.
5. Extract the value from "DS" if the information element exists in 3. Extract the value from "DS" if the information element exists in
the query string. The existence of this information element the query string. The existence of this information element
indicates an asymmetric key is used. indicates an asymmetric key is used.
6. If neither "MD" or "DS" attribute is in the URI, then no URI 4. If neither "MD" or "DS" attribute is in the URI, then no URI
Signature exists and the request is denied. If both the "MD" Signature exists and the request is denied. If both the "MD"
and the "DS" information elements are present, the Signed URI is and the "DS" information elements are present, the Signed URI is
considered to be malformed and the request is denied. considered to be malformed and the request is denied.
7. Extract the value from "UPC" if the information element exists 5. Extract the value from "UPC" if the information element exists
in the query string. The existence of this information element in the query string. The existence of this information element
indicates content delivery is enforced based on a (set of) URI indicates content delivery is enforced based on a (set of) URI
pattern(s) instead of the Original URI. pattern(s) instead of the Full Original URI.
8. Extract the value from "CIP" if the information element exists 6. Extract the value from "CIP" if the information element exists
in the query string. The existence of this information element in the query string. The existence of this information element
indicates content delivery is enforced based on client IP indicates content delivery is enforced based on client IP
address. address.
9. Extract the value from "ET" if the information element exists in 7. Extract the value from "ET" if the information element exists in
the query string. The existence of this information element the query string. The existence of this information element
indicates content delivery is enforced based on time. indicates content delivery is enforced based on time.
10. Extract the value from the "KID" or "KID_NUM" information 8. Extract the value from the "KID" or "KID_NUM" information
element, if they exist. The existence of either of these element, if they exist. The existence of either of these
information elements indicates a key can be referenced. If both information elements indicates a key can be referenced. If both
the "KID" and the "KID_NUM" information elements are present, the "KID" and the "KID_NUM" information elements are present,
the Signed URI is considered to be malformed and the request is the Signed URI is considered to be malformed and the request is
denied. denied.
11. Extract the value from the "HF" information element, if it 9. Extract the value from the "HF" information element, if it
exists. The existence of this information element indicates a exists. The existence of this information element indicates a
different hash function than the default. different hash function than the default.
12. Extract the value from the "DSA" information element, if it 10. Extract the value from the "DSA" information element, if it
exists. The existence of this information element indicates a exists. The existence of this information element indicates a
different digital signature algorithm than the default. different digital signature algorithm than the default.
13. Extract the value from the "CEA" information element, if it 11. Extract the value from the "CEA" information element, if it
exists. The existence of this information element indicates a exists. The existence of this information element indicates a
different Client IP Encryption Algorithm than the default. different Client IP Encryption Algorithm than the default.
14. Extract the value from the "CKI" information element, if it 12. Extract the value from the "CKI" information element, if it
exists. The existence of this information element indicates a exists. The existence of this information element indicates a
key can be referenced using which the Client IP was encrypted. key can be referenced using which the Client IP was encrypted.
4.2. Signature Validation 4.3. Obtain URI Signing IEs with Protected URI
Validate the URI Signature for the Signed URI. Obtain the message that contain the URI Signing Information Elements
and Protected URI (either Full Original URI or URI pattern). This is
the content that was used to generate the URI signature, which is
validated by Downstream CDN in the next section..
1. Copy the Signed URI into a buffer to hold the message for 1. Copy the decoded URI Signing Package into a new buffer to hold
performing the operations below the message for performing the operations below. Note: The
attribute contains all the URI Signing Information Elements and
may also include the URI Pattern Container.
2. Remove the "URISigningPackage" attribute from the message. 2. Remove the value part of the "MD" or "DS" information element
Remove any subsequent part of the query string after the from the message. The part of information element that remains
"URISigningPackage" attribute. is "MD=" or "DS=".
3. Append the decoded value from "URISigningPackage" attribute 3. When UPC information element exists, the Protected URI is a set
(which contains all the URI Signing Information Elements). of URIs (i.e., URI Pattern which is conveyed in the value of the
UPC IE). Otherwise, the Protected URI is the Full Original URI.
4. Extract the value from the "MD" or "DS" information element. A. For URI Pattern, the message already contains the Protected
This is the received message signature. URI. Therefore, no additional operation is needed to create
the protected URI.
5. Convert the message signature to binary format. This will be B. For Full Original URI, the message is missing the Full
used to compare with the computed value later. Original URI in the URI Signing Package. Perform the
following steps.
6. Remove the the "MD" or "DS" information elements from the 1. Remove the string "MD=" or "DS=".
message.
7. If the buffer contains the UPC information element, skip this 2. Append the string "OUC=". Append the Full Original URI,
step. Append the "&" character to the buffer. Append the excluding the "scheme name" part and the "://" delimiter,
Original URI Container (OUC) information element. Append the to the buffer.
Original URI to the buffer, except for the scheme part and the
'://' delimiter.
8. Append the "&" character. Append "MD=" or "DS=", depending on 3. Append the "&" character. Append "MD=" or "DS=",
which of the two was present in the Signed URI. The message is depending on which of the two was present in the URI
ready for validation of the message digest (e.g. "example.com/con Signing Package. The message is ready for validation of
tent.mov?ET=1209422976&CIP=90C913977933FC650E7186361A93D6C3&KID=e the message digest (e.g. "ET=1209422976&CIP=90C913977933
xample:keys:123&OUC=example.com/content.mov&MD="). FC650E7186361A93D6C3&KID=example:keys:123&OUC=example.com
/content.mov&MD=").
9. Based on the presence of either the MD or DS information element 4.4. Validate URI Signature
in the buffer, validate the message digest or digital signature
for symmetric key or asymmetric keys, respectively. Validate the URI Signature for the Signed URI. The message used for
computation is obtained from previous section.
1. The received message signature is the value extracted from the
"MD" or "DS" information element. Convert the message signature
to binary format. This will be used to compare with the computed
value later.
2. Based on the presence of either the MD or DS information element
in the URI Signing Package, validate the message digest or
digital signature for symmetric key or asymmetric keys,
respectively.
A. For MD, an HMAC algorithm is used. A. For MD, an HMAC algorithm is used.
1. If either the "KID" or "KID_NUM" information element 1. If either the "KID" or "KID_NUM" information element
exists, validate that the key identifier is in the exists, validate that the key identifier is in the
allowable KID set as listed in the CDNI metadata or allowable KID set as listed in the CDNI metadata or
configuration. The request is denied when the key configuration. The request is denied when the key
identifier is not allowed. If neither the "KID" or identifier is not allowed. If neither the "KID" or
"KID_NUM" information element is present in the Signed "KID_NUM" information element is present in the Signed
URI, obtain the shared key via CDNI metadata or URI, obtain the shared key via CDNI metadata or
skipping to change at page 23, line 49 skipping to change at page 24, line 27
hash function is in the allowable "HF" set as listed in hash function is in the allowable "HF" set as listed in
the CDNI metadata or configuration. The request is the CDNI metadata or configuration. The request is
denied when the hash function is not allowed. Otherwise, denied when the hash function is not allowed. Otherwise,
the "HF" information element is not in the Signed URI. the "HF" information element is not in the Signed URI.
In this case, the default hash function is SHA-256. In this case, the default hash function is SHA-256.
3. Compute the message digest using the HMAC algorithm with 3. Compute the message digest using the HMAC algorithm with
the shared key and message as the two inputs to the hash the shared key and message as the two inputs to the hash
function. function.
4. Compare the result with the received message signature 4. Compare the result with the received message signature to
extracted in step 5 to validate the Signed URI. validate the Signed URI.
B. For DS, a digital signature function is used. B. For DS, a digital signature function is used.
1. If either the "KID" or "KID_NUM" information element 1. If either the "KID" or "KID_NUM" information element
exists, validate that the key identifier is in the exists, validate that the key identifier is in the
allowable KID set as listed in the CDNI metadata or allowable KID set as listed in the CDNI metadata or
configuration. The request is denied when the key configuration. The request is denied when the key
identifier is not allowed. If neither the "KID" or identifier is not allowed. If neither the "KID" or
"KID_NUM" information element is present in the Signed "KID_NUM" information element is present in the Signed
URI, obtain the public key via CDNI metadata or URI, obtain the public key via CDNI metadata or
skipping to change at page 24, line 25 skipping to change at page 24, line 52
digital signature algorithm is in the allowable "DSA" set digital signature algorithm is in the allowable "DSA" set
as listed in the CDNI metadata or configuration. The as listed in the CDNI metadata or configuration. The
request is denied when the DSA is not allowed. request is denied when the DSA is not allowed.
Otherwise, the "DSA" information element is not in the Otherwise, the "DSA" information element is not in the
Signed URI. In this case, the default DSA is EC-DSA. Signed URI. In this case, the default DSA is EC-DSA.
3. Compute the message digest using SHA-1 (without a key) 3. Compute the message digest using SHA-1 (without a key)
for the message. for the message.
4. Verify the digital signature using the digital signature 4. Verify the digital signature using the digital signature
function (e.g. EC-DSA) with the public key, received function (e.g., EC-DSA) with the public key, received
digital signature, and message signature (extracted in digital signature, and message digest (obtained in
step 5) as inputs. This validates the Signed URI. previous step) as inputs. This validates the Signed URI.
4.3. Distribution Policy Enforcement 4.5. Distribution Policy Enforcement
Note that the absence of a given Enforcement Information Element Note that the absence of a given Enforcement Information Element
indicates enforcement of its purpose is not necessary in the CSP's indicates enforcement of its purpose is not necessary in the CSP's
distribution policy. distribution policy.
1. If the "CIP" information element does not exist, this step can be 1. If the "CIP" information element does not exist, this step can be
skipped. skipped.
A. Obtain the key for decrypting the Client IP, as indicated by A. Obtain the key for decrypting the Client IP, as indicated by
the Client IP Key Index information element or set via the Client IP Key Index information element or set via
skipping to change at page 25, line 11 skipping to change at page 25, line 35
address within the range indicated by the decrypted Client IP address within the range indicated by the decrypted Client IP
information element. If the IP address is incorrect, the information element. If the IP address is incorrect, the
request is denied. request is denied.
2. If the "ET" information element exists, validate that the request 2. If the "ET" information element exists, validate that the request
arrived before expiration time based on the "ET" information arrived before expiration time based on the "ET" information
element. If the time expired, then the request is denied. element. If the time expired, then the request is denied.
3. If the "UPC" information element exists, validate that the 3. If the "UPC" information element exists, validate that the
requested resource is in the allowed set by matching the received requested resource is in the allowed set by matching the received
URI against the URI Pattern Container information element. If URI against each of the Patterns in the URI Pattern Container
there is no match, the request is denied. information element until a match is found. If there is no
match, the request is denied.
5. Relationship with CDNI Interfaces 5. Relationship with CDNI Interfaces
Some of the CDNI Interfaces need enhancements to support URI Signing. Some of the CDNI Interfaces need enhancements to support URI Signing.
As an example: A Downstream CDN that supports URI Signing needs to be As an example: A Downstream CDN that supports URI Signing needs to be
able to advertise this capability to the Upstream CDN. The Upstream able to advertise this capability to the Upstream CDN. The Upstream
CDN needs to select a Downstream CDN based on such capability when CDN needs to select a Downstream CDN based on such capability when
the CSP requires access control to enforce its distribution policy the CSP requires access control to enforce its distribution policy
via URI Signing. Also, the Upstream CDN needs to be able to via URI Signing. Also, the Upstream CDN needs to be able to
distribute via the CDNI Metadata interface the information necessary distribute via the CDNI Metadata interface the information necessary
to allow the Downstream CDN to validate a Signed URI . Events that to allow the Downstream CDN to validate a Signed URI. Events that
pertain to URI Signing (e.g. request denial or delivery after access pertain to URI Signing (e.g., request denial or delivery after access
authorization) need to be included in the logs communicated through authorization) need to be included in the logs communicated through
the CDNI Logging interface (Editor's Note: Is this within the scope the CDNI Logging interface (Editor's Note: Is this within the scope
of the CDNI Logging interface?). of the CDNI Logging interface?).
5.1. CDNI Control Interface 5.1. CDNI Control Interface
URI Signing has no impact on this interface. URI Signing has no impact on this interface.
5.2. CDNI Footprint & Capabilities Advertisement Interface 5.2. CDNI Footprint & Capabilities Advertisement Interface
skipping to change at page 26, line 13 skipping to change at page 26, line 38
version. version.
Advertise value of the "HF" Information Element (i.e. SHA-256) Advertise value of the "HF" Information Element (i.e. SHA-256)
to indicate support for the hash function; Need IANA assignment to indicate support for the hash function; Need IANA assignment
for new hash function. for new hash function.
Advertise value of the "DSA" Information Element (i.e. EC-DSA) Advertise value of the "DSA" Information Element (i.e. EC-DSA)
to indicate support for the DSA; Need IANA assignment for new to indicate support for the DSA; Need IANA assignment for new
digital signature algorithm. digital signature algorithm.
Advertise "MD" Information Element (i.e. SHA-256) to indicate Advertise "MD" Information Element (i.e., SHA-256) to indicate
support for symmetric key method; A new draft is needed for an support for symmetric key method; A new draft is needed for an
alternative method. alternative method.
Advertise "DS" Information Element (i.e. EC-DSA) to indicate Advertise "DS" Information Element (i.e., EC-DSA) to indicate
support for asymmetric key method; A new draft is needed for an support for asymmetric key method; A new draft is needed for an
alternative method. alternative method.
For URI Signing Package Attribute, there is no need to advertise For URI Signing Package Attribute, there is no need to advertise
the base attribute. the base attribute.
5.3. CDNI Request Routing Redirection Interface 5.3. CDNI Request Routing Redirection Interface
The CDNI Request Routing Redirection Interface The CDNI Request Routing Redirection Interface
[I-D.ietf-cdni-redirection] describes the recursive request [I-D.ietf-cdni-redirection] describes the recursive request
skipping to change at page 29, line 34 skipping to change at page 30, line 11
key is provided by the CSP or the Upstream CDN for the content item 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 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 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 content with a private key and provide the public key in the Signed
URI. This just confirms that the URI Signer authorized the delivery. 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, But it's necessary for the URI Signer to be the content owner. So,
the CDNI Metadata interface or configuration MUST provide the the CDNI Metadata interface or configuration MUST provide the
allowable Key ID set to authorize the Key ID information element allowable Key ID set to authorize the Key ID information element
embedded in the Signed URI. embedded in the Signed URI.
The following is an example of a URI Signing metadata payload with
all default values:
{
"generic-metadata-type": "MI.UriSigning.v1"
"generic-metadata-value": {}
}
The following is an example of a URI Signing metadata payload with
explicit values:
{
"generic-metadata-type": "MI.UriSigning.v1"
"generic-metadata-value":
{
"enforce": true,
"key-id": "1",
"key-id-set": ["1", "2", "3"],
"hash-function": "SHA-512",
"hash-function-set": ["SHA-384", "SHA-512"],
"digital-signature-algorithm": "EC-DSA",
"digital-signature-algorithm-set": ["EC-DSA"],
"version": 1,
"version-set": [1],
"package-attribute": "usp"
}
}
5.5. CDNI Logging Interface 5.5. CDNI Logging Interface
For URI Signing, the Downstream CDN reports that enforcement of the For URI Signing, the Downstream CDN reports that enforcement of the
access control was applied to the request for content delivery. When access control was applied to the request for content delivery. When
the request is denied due to enforcement of URI Signing, the reason the request is denied due to enforcement of URI Signing, the reason
is logged. is logged.
The following CDNI Logging field for URI Signing SHOULD be supported The following CDNI Logging field for URI Signing SHOULD be supported
in the HTTP Request Logging Record as specified in CDNI Logging in the HTTP Request Logging Record as specified in CDNI Logging
Interface [I-D.ietf-cdni-logging]. Interface [I-D.ietf-cdni-logging].
skipping to change at page 30, line 35 skipping to change at page 31, line 47
of unsupported version number of unsupported version number
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
field. field.
o s-uri-signing-deny-reason (optional): o s-uri-signing-deny-reason (optional):
* format: QSTRING * format: QSTRING
* field value: a string for providing further information in case * field value: a string for providing further information in case
the URI signature was rejected, e.g. for debugging purposes. the URI signature was rejected, e.g., for debugging purposes.
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
field. field.
6. URI Signing Message Flow 6. URI Signing Message Flow
URI Signing supports both HTTP-based and DNS-based request routing. URI Signing supports both HTTP-based and DNS-based request routing.
HMAC [RFC2104] defines a hash-based message authentication code HMAC [RFC2104] defines a hash-based message authentication code
allowing two parties that share a symmetric key or asymmetric keys to allowing two parties that share a symmetric key or asymmetric keys to
establish the integrity and authenticity of a set of information establish the integrity and authenticity of a set of information
(e.g. a message) through a cryptographic hash function. (e.g., a message) through a cryptographic hash function.
6.1. HTTP Redirection 6.1. HTTP Redirection
For HTTP-based request routing, HMAC is applied to a set of For HTTP-based request routing, HMAC is applied to a set of
information that is unique to a given end user content request using information that is unique to a given end user content request using
key information that is specific to a pair of adjacent CDNI hops key information that is specific to a pair of adjacent CDNI hops
(e.g. between the CSP and the Authoritative CDN, between the (e.g. between the CSP and the Authoritative CDN, between the
Authoritative CDN and a Downstream CDN). This allows a CDNI hop to Authoritative CDN and a Downstream CDN). This allows a CDNI hop to
ascertain the authenticity of a given request received from a ascertain the authenticity of a given request received from a
previous CDNI hop. previous CDNI hop.
skipping to change at page 33, line 19 skipping to change at page 34, line 35
Signed URI that is based on unique parameters of that request Signed URI that is based on unique parameters of that request
and provides to the end user as the URI to use to further and provides to the end user as the URI to use to further
request the content from the Downstream CDN request the content from the Downstream CDN
10. On receipt of the corresponding content request, the Downstream 10. On receipt of the corresponding content request, the Downstream
CDN validates the URI Signature in the Signed URI using the CDN validates the URI Signature in the Signed URI using the
information provided by the Authoritative CDN in the CDNI information provided by the Authoritative CDN in the CDNI
Metadata Metadata
11. If the validation is negative, the Downstream CDN rejects the 11. If the validation is negative, the Downstream CDN rejects the
request and sends an error code (e.g. 403) in the HTTP response. request and sends an error code (e.g., 403) in the HTTP
response.
12. If the validation is positive, the Downstream CDN serves the 12. If the validation is positive, the Downstream CDN serves the
request and delivers the content. request and delivers the content.
13. At a later time, Downstream CDN reports logging events that 13. At a later time, Downstream CDN reports logging events that
includes URI signing information. includes URI signing information.
With HTTP-based request routing, URI Signing matches well the general With HTTP-based request routing, URI Signing matches well the general
chain of trust model of CDNI both with symmetric key and asymmetric 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 keys because the key information only need to be specific to a pair
skipping to change at page 35, line 16 skipping to change at page 36, line 36
the Downstream CDN advertises its capabilities including URI the Downstream CDN advertises its capabilities including URI
Signing support to the Authoritative CDN. Signing support to the Authoritative CDN.
2. CSP provides to the Authoritative CDN the information needed to 2. CSP provides to the Authoritative CDN the information needed to
validate cryptographic signatures from that CSP. For example, validate cryptographic signatures from that CSP. For example,
this information may include a hash function, algorithm, and a this information may include a hash function, algorithm, and a
key. key.
3. Using the CDNI Metadata interface, the Authoritative CDN 3. Using the CDNI Metadata interface, the Authoritative CDN
communicates to a Downstream CDN the information needed to communicates to a Downstream CDN the information needed to
validate cryptographic signatures from the CSP (e.g. the URI validate cryptographic signatures from the CSP (e.g., the URI
query string parameter name for the URI Signing Package query string parameter name for the URI Signing Package
Attribute). In the case of symmetric key, the Authoritative CDN Attribute). In the case of symmetric key, the Authoritative CDN
checks if the Downstream CDN is allowed by CSP to obtain the checks if the Downstream CDN is allowed by CSP to obtain the
shared secret key. shared secret key.
4. When a UA requests a piece of protected content from the CSP, 4. When a UA requests a piece of protected content from the CSP,
the CSP makes a specific authorization decision for this unique the CSP makes a specific authorization decision for this unique
request based on its arbitrary distribution policy. request based on its arbitrary distribution policy.
5. If the authorization decision is negative, the CSP rejects the 5. If the authorization decision is negative, the CSP rejects the
skipping to change at page 35, line 50 skipping to change at page 37, line 23
10. On receipt of the DNS request, the Downstream CDN responds with 10. On receipt of the DNS request, the Downstream CDN responds with
IP address of one of its Surrogates. IP address of one of its Surrogates.
11. On receipt of the corresponding content request, the Downstream 11. On receipt of the corresponding content request, the Downstream
CDN validates the cryptographic signature in the URI using the CDN validates the cryptographic signature in the URI using the
information provided by the Authoritative CDN in the CDNI information provided by the Authoritative CDN in the CDNI
Metadata Metadata
12. If the validation is negative, the Downstream CDN rejects the 12. If the validation is negative, the Downstream CDN rejects the
request and sends an error code (e.g. 403) in the HTTP response. request and sends an error code (e.g., 403) in the HTTP
response.
13. If the validation is positive, the Downstream CDN serves the 13. If the validation is positive, the Downstream CDN serves the
request and delivers the content. request and delivers the content.
14. At a later time, Downstream CDN reports logging events that 14. At a later time, Downstream CDN reports logging events that
includes URI signing information. includes URI signing information.
With DNS-based request routing, URI Signing matches well the general With DNS-based request routing, URI Signing matches well the general
chain of trust model of CDNI when used with asymmetric keys because chain of trust model of CDNI when used with asymmetric keys because
the only key information that need to be distributed across multiple the only key information that need to be distributed across multiple
skipping to change at page 36, line 35 skipping to change at page 38, line 9
The authors note that in order to perform URI signing for individual The authors note that in order to perform URI signing for individual
content segments of HTTP Adaptive Bitrate content, specific URI content segments of HTTP Adaptive Bitrate content, specific URI
signing mechanisms are needed. Such mechanisms are currently out-of- signing mechanisms are needed. Such mechanisms are currently out-of-
scope of this document. More details on this topic is covered in scope of this document. More details on this topic is covered in
Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. [Editor Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. [Editor
note: DASH draft discussion] note: DASH draft discussion]
8. IANA Considerations 8. IANA Considerations
[Editor's note: (Is there a need to) register default value for URI 8.1. CDNI Payload Type
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 the registration of the following CDNI Payload
Type under the IANA "CDNI Payload Type" registry:
This document requests IANA to create three new URI Signing +------------------+---------------+
registries for the Information Elements and their defined values to | Payload Type | Specification |
be used for URI Signing. +------------------+---------------+
| MI.UriSigning.v1 | RFCthis |
+------------------+---------------+
The following Enforcement Information Element names are allocated: [RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
o ET (Expiry time) 8.1.1. CDNI UriSigning Payload Type
o CIP (Client IP address) Purpose: The purpose of this payload type is to distinguish
The following Signature Computation Information Element names are UriSigning MI objects (and any associated capability advertisement).
allocated:
o VER (Version): 1 (Base) Interface: MI/FCI
o KID (Key ID) Encoding: see Section 5.4
o KID_NUM (Numerical Key ID) 8.2. CDNI Logging Record Type
o HF (Hash Function): "SHA-256" This document requests the registration of the following CDNI Logging
record-type under the IANA "CDNI Logging record-types" registry:
o DSA (Digital Signature Algorithm): "EC-DSA" +----------------------+-----------+--------------------------------+
| record-types | Reference | Description |
+----------------------+-----------+--------------------------------+
| cdni_http_request_v2 | RFCthis | Extension to CDNI Logging |
| | | Record version 1 for content |
| | | delivery using HTTP, to |
| | | include URI Signing logging |
| | | fields |
+----------------------+-----------+--------------------------------+
The following URI Signature Information Element names are allocated: [RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
o MD (Message Digest for Symmetric Key) 8.2.1. CDNI Logging Record Version 2 for HTTP
o DS (Digital Signature for Asymmetric Keys) The "cdni_http_request_v2" record-type supports all of the fields
supported by the "cdni_http_request_v1" record-type
[I-D.ietf-cdni-logging] plus the two additional fields "s-uri-
signing" and "s-uri-signing-deny-reason", registered by this document
in Section 8.3. The name, format, field value, and occurence
information for the two new fields can be found in Section 5.5 of
this document.
The IANA is requested to allocate a new entry to the CDNI Logging 8.3. CDNI Logging Field Names
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 This document requests the registration of the following CDNI Logging
fields under the IANA "CDNI Logging Field Names" registry:
o s-uri-signing-deny-reason +---------------------------+-----------+
| Field Name | Reference |
+---------------------------+-----------+
| s-uri-signing | RFCthis |
| s-uri-signing-deny-reason | RFCthis |
+---------------------------+-----------+
The IANA is requested to allocate a new entry to the "CDNI [RFC Editor: Please replace RFCthis with the published RFC number for
GenericMetadata Types" Registry as specified in CDNI Metadata this document.]
Interface [I-D.ietf-cdni-metadata] in accordance to the
"Specification Required" policy [RFC5226]:
+------------+---------------+---------+------+------+ 8.4. CDNI URI Signing Enforcement Information Elements
| 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 The IANA is requested to create a new "CDNI URI Signing Enforcement
MIME Media Type registry for the UriSigning metadata object: Information Elements" subregistry in the "Content Delivery Networks
Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing
Enforcement Information Elements" namespace defines the valid
Enforcement Information Elements that may be included in a URI
Signing token. Additions to the Enforcement Information Elements
namespace conform to the "Specification Required" policy as defined
in [RFC5226].
application/cdni.UriSigning.v1 The following table defines the initial Enforcement Information
Elements:
+-----------------------+------------------------+---------+
| Element | Description | RFC |
+-----------------------+------------------------+---------+
| ET | Expiry Time | RFCthis |
| CIP | Client IP Address | RFCthis |
| OUC | Original URI Container | RFCthis |
| URI Pattern Container | Client IP Address | RFCthis |
+-----------------------+------------------------+---------+
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
[Ed Note: are there any special instructions to the designated expert
reviewer?]
8.5. CDNI URI Signing Signature Computation Information Elements
The IANA is requested to create a new "CDNI URI Signing Signature
Computation Information Elements" subregistry in the "Content
Delivery Networks Interconnection (CDNI) Parameters" registry. The
"CDNI URI Signing Signature Computation Information Elements"
namespace defines the valid Signature Computation Information
Elements that may be included in a URI Signing token. Additions to
the Signature Computation Information Elements namespace conform to
the "Specification Required" policy as defined in [RFC5226].
The following table defines the initial Signature Computation
Information Elements:
+---------+-------------------------------------+---------+
| Element | Description | RFC |
+---------+-------------------------------------+---------+
| VER | Version Number | RFCthis |
| KID | Non-numerical Key Identifier | RFCthis |
| KID_NUM | Numerical Key Identifier | RFCthis |
| HF | Hash Function | RFCthis |
| DSA | Digital Signature Algorithm | RFCthis |
| CEA | Client IP Encryption Algorithm | RFCthis |
| CKI | Client IP Encryption Key Identifier | RFCthis |
+---------+-------------------------------------+---------+
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
[Ed Note: are there any special instructions to the designated expert
reviewer?]
8.6. CDNI URI Signing Signature Information Elements
The IANA is requested to create a new "CDNI URI Signing Signature
Information Elements" subregistry in the "Content Delivery Networks
Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing
Signature Information Elements" namespace defines the valid Signature
Information Elements that may be included in a URI Signing token.
Additions to the Signature Information Elements namespace conform to
the "Specification Required" policy as defined in [RFC5226].
The following table defines the initial Signature Information
Elements:
+---------+---------------------------------------+---------+
| Element | Description | RFC |
+---------+---------------------------------------+---------+
| MD | Message Digest for Symmetric Key | RFCthis |
| DS | Digital Signature for Asymmetric Keys | RFCthis |
+---------+---------------------------------------+---------+
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
[Ed Note: are there any special instructions to the designated expert
reviewer?]
9. Security Considerations 9. Security Considerations
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of interconnected used to provide access authorization in the case of interconnected
CDNs (CDNI). The primary goal of URI Signing is to make sure that 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 only authorized UAs are able to access the content, with a Content
Service Provider (CSP) being able to authorize every individual Service Provider (CSP) being able to authorize every individual
request. It should be noted that URI Signing is not a content request. It should be noted that URI Signing is not a content
protection scheme; if a CSP wants to protect the content itself, protection scheme; if a CSP wants to protect the content itself,
skipping to change at page 39, line 23 skipping to change at page 42, line 37
associated public key URL in the KID field, thereby passing URI associated public key URL in the KID field, thereby passing URI
validation, it is important that CDNs check whether the URI conveyed 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 in the KID field is in the allowable set of KIDs as listed in the
CDNI metadata or set via configuration. CDNI metadata or set via configuration.
10. Privacy 10. Privacy
The privacy protection concerns described in CDNI Logging Interface The privacy protection concerns described in CDNI Logging Interface
[I-D.ietf-cdni-logging] apply when the client's IP address (CIP [I-D.ietf-cdni-logging] apply when the client's IP address (CIP
attribute) is embedded in the Signed URI. For this reason, the attribute) is embedded in the Signed URI. For this reason, the
mechanism described in Section 3 encrypts the Client IP before mechanism described in Section 3.1 encrypts the Client IP before
including it in the URI Signing Package (and thus the URL itself). including it in the URI Signing Package (and thus the URL itself).
11. Acknowledgements 11. Acknowledgements
The authors would like to thank the following people for their The authors would like to thank the following people for their
contributions in reviewing this document and providing feedback: contributions in reviewing this document and providing feedback:
Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan
York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana
Oprescu, Leif Hedstrom and Phil Sorber. In addition, Matt Caulfield Oprescu, Leif Hedstrom and Phil Sorber. In addition, Matt Caulfield
provided content for the CDNI Metadata Interface section. provided content for the CDNI Metadata Interface section.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-cdni-logging] [I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R. Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-21 (work in progress), November 2015. logging-24 (work in progress), April 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
skipping to change at page 40, line 15 skipping to change at page 43, line 34
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>. 2012, <http://www.rfc-editor.org/info/rfc6707>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni- "CDN Interconnection Metadata", draft-ietf-cdni-
metadata-12 (work in progress), October 2015. metadata-13 (work in progress), March 2016.
[I-D.ietf-cdni-redirection] [I-D.ietf-cdni-redirection]
Niven-Jenkins, B. and R. Brandenburg, "Request Routing Niven-Jenkins, B. and R. Brandenburg, "Request Routing
Redirection Interface for CDN Interconnection", draft- Redirection interface for CDN Interconnection", draft-
ietf-cdni-redirection-13 (work in progress), October 2015. ietf-cdni-redirection-17 (work in progress), February
2016.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <http://www.rfc-editor.org/info/rfc2104>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
 End of changes. 137 change blocks. 
334 lines changed or deleted 503 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/