draft-ietf-cdni-uri-signing-05.txt   draft-ietf-cdni-uri-signing-06.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: February 13, 2016 R. van Brandenburg Expires: July 2, 2016 R. van Brandenburg
TNO TNO
B. Downey B. Downey
Verizon Labs Verizon Labs
M. Fisher M. Fisher
Limelight Networks Limelight Networks
August 12, 2015 December 30, 2015
URI Signing for CDN Interconnection (CDNI) URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-05 draft-ietf-cdni-uri-signing-06
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. Some validate access requests for the content referenced by the URI. The
of the information may be accessed by the CDN via configuration or mechanism described can be used both in CDNI and single CDN
CDNI metadata. scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 February 13, 2016. This Internet-Draft will expire on July 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 on URI Signing . . . . . . . . . . . . . . . . 4 1.2. Background and overview on URI Signing . . . . . . . . . 4
1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . 12 2.3. URI Signature Information Elements . . . . . . . . . . . 13
2.4. URI Signing Package Attribute . . . . . . . . . . . . . . 13 2.4. URI Signing Package Attribute . . . . . . . . . . . . . . 14
2.5. User Agent Attributes . . . . . . . . . . . . . . . . . . 14 2.5. User Agent Attributes . . . . . . . . . . . . . . . . . . 15
3. Creating the Signed URI . . . . . . . . . . . . . . . . . . . 14 3. Creating the Signed URI . . . . . . . . . . . . . . . . . . . 15
3.1. Calculating the URI Signature . . . . . . . . . . . . . . 15 3.1. Calculating the URI Signature . . . . . . . . . . . . . . 16
3.2. Packaging the URI Signature . . . . . . . . . . . . . . . 18 3.2. Packaging the URI Signature . . . . . . . . . . . . . . . 19
4. Validating a URI Signature . . . . . . . . . . . . . . . . . 19 4. Validating a URI Signature . . . . . . . . . . . . . . . . . 20
4.1. Information Element Extraction . . . . . . . . . . . . . 19 4.1. Information Element Extraction . . . . . . . . . . . . . 21
4.2. Signature Validation . . . . . . . . . . . . . . . . . . 20 4.2. Signature Validation . . . . . . . . . . . . . . . . . . 22
4.3. Distribution Policy Enforcement . . . . . . . . . . . . . 22 4.3. Distribution Policy Enforcement . . . . . . . . . . . . . 24
5. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 23 5. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 25
5.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 23 5.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 25
5.2. CDNI Footprint & Capabilities Advertisement Interface . . 23 5.2. CDNI Footprint & Capabilities Advertisement Interface . . 25
5.3. CDNI Request Routing Redirection Interface . . . . . . . 24 5.3. CDNI Request Routing Redirection Interface . . . . . . . 26
5.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 24 5.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 26
5.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 27 5.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 29
6. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 28 6. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 30
6.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 28 6.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 30
6.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 31 6.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 33
7. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 34 7. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.1. Normative References . . . . . . . . . . . . . . . . . . 37 12.1. Normative References . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . 37 12.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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 interconnected used to provide access authorization in the case of redirection
CDNs (CDNI). The primary goal of URI Signing is to make sure that between interconnected CDNs (CDNI) and between a Content Service
only authorized User Agents (UAs) are able to access the content, Provider (CSP) and a CDN. The primary goal of URI Signing is to make
with a Content Service Provider (CSP) being able to authorize every sure that only authorized User Agents (UAs) are able to access the
individual request. It should be noted that URI Signing is not a content, with a CSP being able to authorize every individual request.
content protection scheme; if a CSP wants to protect the content It should be noted that URI Signing is not a content protection
itself, other mechanisms, such as DRM, are more appropriate. scheme; if a CSP wants to protect the content itself, other
mechanisms, such as DRM, are more appropriate. In addition to access
control, URI Signing also has benefits in reducing the impact of
denial-of-service attacks.
The overall problem space for CDN Interconnection (CDNI) is described The overall problem space for CDN Interconnection (CDNI) is described
in CDNI Problem Statement [RFC6707]. In this document, along with in CDNI Problem Statement [RFC6707]. In this document, along with
the CDNI Requirements [RFC7337] document and the CDNI Framework the CDNI Requirements [RFC7337] document and the CDNI Framework
[RFC7336] the need for interconnected CDNs to be able to implement an [RFC7336] the need for interconnected CDNs to be able to implement an
access control mechanism that enforces the CSP's distribution policy access control mechanism that enforces the CSP's distribution policy
is described. is described.
Specifically, CDNI Framework [RFC7336] states: Specifically, CDNI Framework [RFC7336] states:
skipping to change at page 4, line 7 skipping to change at page 4, line 10
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.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses the terminology defined in CDNI Problem Statement This document uses the terminology defined in CDNI Problem Statement
[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] including the following terms Authentication (HMAC) [RFC2104].
(reproduced here for convenience):
o MAC: message authentication code.
o HMAC: Hash-based message authentication code (HMAC) is a specific
construction for calculating a MAC involving a cryptographic hash
function in combination with a secret key.
o HMAC-SHA256: HMAC instantiation using SHA-256 as the cryptographic
hash function.
o SHA-1: Secure Hash Algorithm 1 (SHA-1) [RFC3174] is the
cryptographic hash function.
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 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 on URI Signing 1.2. Background and overview on URI Signing
The next section provides an overview of how URI Signing works in a
CDNI environment. As background information, URI Signing is first
explained in terms of a single CDN delivering content on behalf of a
CSP.
A CSP and CDN are assumed to have a trust relationship that enables 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
skipping to change at page 5, line 32 skipping to change at page 5, line 20
browses for content on CSP's website (#1), it receives HTML web pages browses for content on CSP's website (#1), it receives HTML web pages
with embedded content URIs. Upon requesting these URIs, the CSP with embedded content URIs. Upon requesting these URIs, the CSP
redirects to a CDN, creating a Target CDN URI (#2) (alternatively, redirects to a CDN, creating a Target CDN URI (#2) (alternatively,
the Target CDN URI itself is embedded in the HTML). The Target CDN the Target CDN URI itself is embedded in the HTML). The Target CDN
URI is the Signed URI which may include the IP address of the UA and/ URI is the Signed URI which may include the IP address of the UA and/
or a time window and always contains the URI Signature which is or a time window and always contains the URI Signature which is
generated by the CSP using the shared secret or a private key. Once generated by the CSP using the shared secret or a private key. Once
the UA receives the response with the embedded URI, it sends a new the UA receives the response with the embedded URI, it sends a new
HTTP request using the embedded URI to the CDN (#3). Upon receiving HTTP request using the embedded URI to the CDN (#3). Upon receiving
the request, the CDN checks to see if the Signed URI is authentic by the request, the CDN checks to see if the Signed URI is authentic by
verifying the URI signature. In addition, it checks whether the IP verifying the URI signature. If applicable, it checks whether the IP
address of the HTTP request matches that in the Signed URI and if the address of the HTTP request matches that in the Signed URI and if the
time window is still valid. After these values are confirmed to be time window is still valid. After these values are confirmed to be
valid, the CDN delivers the content (#4). valid, the CDN delivers the content (#4).
-------- --------
/ \ / \
| CSP |< * * * * * * * * * * * | CSP |< * * * * * * * * * * *
\ / Trust * \ / Trust *
-------- relationship * -------- relationship *
^ | * ^ | *
skipping to change at page 8, line 30 skipping to change at page 8, line 30
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
SHOULD maintain the same level of security as the original Signed MUST maintain the same, or higher, level of security as the original
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
skipping to change at page 10, line 29 skipping to change at page 10, line 29
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 (e.g. NTP is used). validate the signed URI need to be in sync. In the CDNI case,
this means that servers at both the CSP, uCDN and dCDN need to be
time-synchronized. It is RECOMMENDED to use NTP for this.
o Client IP (CIP) [optional] - IP address of the client for which o Client IP (CIP) [optional] - IP address, or IP prefix, for which
this Signed URI is generated. This is represented in dotted the Signed URI is valid. This is represented in CIDR notation,
decimal format for IPv4 or canonical text representation for IPv6 with dotted decimal format for IPv4 or canonical text
address [RFC5952] . The request is rejected if sourced from a representation for IPv6 addresses [RFC5952] . The request is
client with a different IP address. rejected if sourced from a client outside of the specified IP
range.
o Original URI Container (OUC) [optional] - Container for holding
the Original URI while the URI signature is calculated. The
Original URI Container information element is not transmitted as
part of the URI Signing Package Attribute. If the Original URI
Container information element is used, the URI Pattern Sequence
information element MUST NOT be used.
o URI Pattern Container (UPC) [optional] - Container for one or more
URI Patterns that describes for which content the Signed URI is
valid. The URI Pattern Container contains an expression to match
against the requested URI to check whether the requested content
is allowed to be requested. Multiple URI Patterns may be
concatenated in a single URI Pattern Container information element
by seperating them with a semi-colon (';') character. Each URI
Pattern follows the [RFC3986] URI format, including the '://' that
delimits the URI scheme from the hierarchy part. The pattern may
include the wildcards '*' and '?', where '*' matches any sequence
of characters (including the empty string) and '?' matches exactly
one character. The three literals '$', '*' and '?' should be
escaped as '$$', '$*' and '$?'. All other characters are treated
as literals. The following is an example of a valid URI Pattern:
'*://*/folder/content-83112371/quality_*/segment????.mp4'. An
example of two concatenated URI Patterns is the following:
'http://*/folder/content-83112371/manifest/*.xml;http://*/folder/
content-83112371/quality_*/segment????.mp4'. If the UPC is used,
the Original URI Container information element MUST NOT be used.
The Expiry Time Information Element ensures that the content 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 User Agent, based on its IP address for whom the to a particular IP address or set of IP addresses based on the IP
content access was authorized. address for whom the content access was authorized. The URI Signing
mechanism described in this document will communicate the IP address
in the URI. To prevent the IP addess from being logged, the Client
IP information element is transmited in encrypted form.
The Original URI Container is used to limit access to the Original
URI only.
The URI Pattern Container Information Element is used to restrict
content access to a particular set of URLs.
Note: See the Security Considerations (Section 9) section on the 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 11, line 43 skipping to change at page 12, line 30
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
Information Element is not present in the URI Signing Package Information Element is not present in the URI Signing Package
Attribute, the default hash function is SHA-256. Attribute, the default hash function is SHA-256.
o Digital Signature Algorithm (DSA) [optional] - Algorithm used to o Digital Signature Algorithm (DSA) [optional] - Algorithm used to
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
to encrypt the Client IP. If this Information Element is not
present in the URI Signing Package Attribute, the default is AES-
128.
o Client IP Key ID (CKI) [optional] - A 64-bit unsigned integer used
for obtaining the key (e.g. database lookup) used for encrypting/
decrypting the Client IP.
The Version Information Element indicates which version of URI 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.
The Key ID Information Element is used to retrieved the key which is The Key ID Information Element is used to retrieved the key which is
needed as input to the algorithm for validating the Signed URI. The needed as input to the algorithm for validating the Signed URI. The
skipping to change at page 12, line 23 skipping to change at page 13, line 19
be used for HMAC-based message digest computation. The Hash Function be used for HMAC-based message digest computation. The Hash Function
Information Element is used in combination with the Message Digest Information Element is used in combination with the Message Digest
Information Element defined in section Section 2.3. Information Element defined in section Section 2.3.
The Digital Signature Algorithm Information Element indicates the The Digital Signature Algorithm Information Element indicates the
digital signature function to be in the case asymmetric keys are digital signature function to be in the case asymmetric keys are
used. The Digital Signature Algorithm Information Element is used in used. The Digital Signature Algorithm Information Element is used in
combination with the Digital Signature Information Element defined in combination with the Digital Signature Information Element defined in
section Section 2.3. section Section 2.3.
The Client IP Encryption Algorithm Information Element indicates the
encryption algorithm to be used for the Client IP. The Client IP
Encryption Algorithm Information Element is used in combination with
the Client IP Information Element defined in section Section 2.1.
The Client IP Key ID is used to retrieved the key which is used for
encrypting and decrypting the Client IP. The method used for
obtaining the actual key from the reference included in the Key ID
Information Element is outside the scope of this document. The
Client IP Encryption Algorithm Information Element is used in
combination with the Client IP Information Element defined in section
Section 2.1.
2.3. URI Signature Information Elements 2.3. URI Signature Information Elements
This section identifies the set of information elements that carry This section identifies the set of information elements that carry
the URI Signature that is used for checking the integrity and the URI Signature that is used for checking the integrity and
authenticity of the URI. authenticity of the URI.
The defined keyword for each information element is specified in The defined keyword for each information element is specified in
parenthesis below. parenthesis below.
The following information elements are used to carry the actual URI The following information elements are used to carry the actual URI
skipping to change at page 14, line 42 skipping to change at page 15, line 52
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. Creating the 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. The entire URI except name, authority, path, query, and fragment. If the Original URI
the "scheme name" part is protected by the URI signature. This Container information element is used, all components except for the
allows the URI signature to be validated correctly in the case when a scheme part are protected by the URI Signature. This allows the URI
client performs a fallback to another scheme (e.g. HTTP) for a signature to be validated correctly in the case when a client
content item referenced by a URI with a specific scheme (e.g. RTSP). performs a fallback to another scheme (e.g. HTTP) for a content item
The benefit is that the content access is protected regardless of the referenced by a URI with a specific scheme (e.g. RTSP). In case the
type of transport used for delivery. If the CSP wants to ensure a URI Pattern Container information element is used, the CSP has full
specific protocol is used for content delivery, that information is flexibility to specify which elements of the URI (including the
passed by CDNI metadata. Note: Support for changing of the URL scheme part) are protected by the URI.
scheme requires that the default port is used, or that the protocols
must both run on the same non-standard port.
The process of generating a Signed URI can be divided into two sets The process of generating a Signed URI can be divided into two sets
of steps: first, calculating the URI Signature and then, packaging of steps: first, calculating the URI Signature and then, packaging
the URI Signature and appending it to the Original URI. Note it is the URI Signature and appending it to the Original URI. Note it is
possible to use some other algorithm and implementation as long as possible to use some other algorithm and implementation as long as
the same result is achieved. An example for the Original URI, the same result is achieved. An example for the 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. Calculating the URI Signature
Calculate the URI Signature by following the procedure below. Calculate the URI Signature by following the procedure below.
1. Copy the Original URI, excluding the "scheme name" part, into a 1. Create an empty buffer for performing the operations below.
buffer to hold the message for performing the operations below.
2. Check if the URI already contains a query string. If not, append 2. Check if the Original URI already contains a query string. If
a "?" character. If yes, append an "&" character. not, place a "?" character in the buffer. If yes, place an "&"
character in the buffer.
3. If the version is the default value (i.e. "1"), skip this step. 3. If the version is the default value (i.e. "1"), skip this step.
Otherwise, specify the version by appending the string "VER=#", Otherwise, specify the version by appending the string "VER=#"
where '#' represents the new version number. The following steps to the buffer, where '#' represents the new version number. The
in the procedure is based on the initial version of URI Signing following steps in the procedure is based on the initial version
specified by this document. For other versions, reference the of URI Signing specified by this document. For other versions,
associated RFC for the URI signing procedure. reference the associated RFC for the URI signing procedure.
4. If time window enforcement is not needed, step 4 can be skipped. 4. If time window enforcement is not needed, step 4 can be skipped.
A. If an information element was added to the message, append an A. If an information element was added to the buffer, append an
"&" character. Append the string "ET=". Note in the case of "&" character. Append the string "ET=". Note in the case
re-signing a URI, the information element is carried over of re-signing a URI, the information element is carried over
from the received Signed URI. from the received Signed URI.
B. Get the current time in seconds since epoch (as an integer). B. Get the current time in seconds since epoch (as an integer).
Add the validity time in seconds as an integer. Note in the 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 case of re-signing a URI, the value MUST remain the same as
the received Signed URI. the received Signed URI.
C. Convert this integer to a string and append to the message. C. Convert this integer to a string and append to the buffer.
5. If client IP enforcement is not needed, step 5 can be skipped. 5. If client IP enforcement is not needed, step 5 can be skipped.
A. If an information element was added to the message, append an A. If the Client IP Encryption Algorithm used is the default
"&" character. Append the string "CIP=". Note in the case ("AES-128"), this step can be skipped. If an information
of re-signing a URI, the attribute is carried over from the element was added to the message, append an "&" character.
received Signed URI. append the string "CEA=". Append the string for the Client
IP Encryption Algorithm to be used.
B. Convert the client's IP address in dotted decimal notation B. If the Client IP Key Identifier is not needed, this step can
format (i.e. for IPv4 address) or canonical text be skipped. If an information element was added to the
representation (for IPv6 address [RFC5952]) to a string and message, append an "&" character. Append the string "CKI=".
append to the message. Note in the case of re-signing an Append the Client IP key identifier (e.g. "56128239") needed
URI, the value MUST remain the same as the received Signed by the entity to locate the shared key for decrypting the
URI. Client IP.
6. Depending on the type of key used to sign the URI, compute the C. If an information element was added to the message, append
message digest or digital signature for symmetric key or an "&" character. Append the string "CIP=".
asymmetric keys, respectively.
A. For symmetric key, HMAC is used. D. Convert the client's IP address in CIDR notation (dotted
decimal format for IPv4 or canonical text representation for
IPv6 [RFC5952]) to a string and encrypt it using AES-128 (in
ECB mode) or another algorithm if specified by the CEA
Information Element. Note in the case of re-signing an URI,
the client IP that is encrypted MUST be equal to the
unencrypted value of the Client IP as received in the Signed
URI, see step 1 in Section 4.3.
1. Obtain the shared key to be used for signing the URI. E. Convert the encrypted Client IP to its equivalent
hexadecimal format.
2. If the key identifier is not needed, skip this step. If F. Append the value computed in the previous step to the
an information element was added to the message, append buffer.
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.
3. Optional: If the hash function for the HMAC uses the 6. If a Key ID information element is not needed, step 6 can be
default value ("SHA-256"), skip this step. If an skipped. If an information element was added to the message,
information element was added to the message, append an append an "&" character. Append the string "KID=" in case a
"&" character. append the string "HF=". Append the string-based Key ID is used, or "KID_NUM=" in case a numerical
string for the new type of hash function to be used. Key ID is used. Append the key identifier (e.g.
Note that re-signing a URI MUST use the same hash "example:keys:123" or "56128239") needed by the entity to locate
function as the received Signed URI or one of the the shared key for validating the URI signature.
allowable hash functions designated by the CDNI metadata.
4. If an information element was added to the message, 7. If asymmetric keys are used, step 7 can be skipped. If the hash
append an "&" character. Append the string "MD=". The function for the HMAC uses the default value ("SHA-256"), step 7
message now contains the complete section of the URI that can be skipped. If an information element was added to the
is protected (e.g. "://example.com/content.mov?ET=120942 message, append an "&" character. Append the string "HF=".
2976&CIP=192.0.2.1&KID=example:keys:123&MD="). Append the string for the new type of hash function to be used.
Note that re-signing a URI MUST use the same hash function as
the received Signed URI or one of the allowable hash functions
designated by the CDNI metadata.
5. Compute the message digest using the HMAC algorithm and 8. If assymetric keys are used, step 8 can be skipped. If the
the default SHA-256 hash function, or another hash digital signature algorithm uses the default value ("EC-DSA"),
function if specified by the HF Information Element, with step 8 can be skipped. If an information element was added to
the shared key and message as the two inputs to the hash the message, append an "&" character. Append the string "DSA=".
function. 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.
6. Convert the message digest to its equivalent hexadecimal 9. Depending on the type of URI enforcement used (Original URI or
format. URI Pattern), add the appropriate information element.
7. Append the string for the message digest (e.g. A. If enforcement based on a (set of) URI Pattern is used, this
"://example.com/content.mov?ET=1209422976&CIP=192.0.2.1&K step can be skipped. If an information element was added to
ID=example:keys:123&MD=1ecb1446a6431352aab0fb6e0dca30e303 the message, append an &" character. Append the string
56593a97acb972202120dc482bddaf"). "OUC=". Append the Original URI, excluding the "scheme
name" part and the '://' delimiter, to the buffer.
B. For asymmetric keys, EC DSA is used. B. If enforcement based on the Original URI is used, this step
can be skipped. If an information element was added to the
message, append an &" character. Append the string "UPC=".
Append the URI Pattern Container in the form of a string to
the buffer.
1. Generate the EC private and public key pair. Store the 10. If asymmetric keys are used, step 10 can be skipped.
EC public key in a location that's reachable for any
entity that needs to validate the URI signature.
2. If the key identifier is not needed, skip this step. If A. Obtain the shared key to be used for signing the URI.
an information element was added to the message, append
an "&" character. Append the string "KID=" in case a
string-based Key ID is used, or "KID_NUM=" in case a
numerical Key ID is used. Append the key identifier
(e.g. "http://example.com/public/keys/123") needed by the
entity to locate the shared key for validating the URI
signature. Note that in the case the Key ID URI is a URL
to a public key, the Key ID URI SHOULD only contain the
"scheme name", "authority", and "path" parts (i.e. query
string is not allowed).
3. Optional: If the digital signature algorithm uses the B. Append the string "MD=". The message now contains the
default value ("EC-DSA"), skip this step. If an complete section of the URI that is protected (e.g. "ET=120
information element was added to the message, append an 9422976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=exa
"&" character. Append the string "DSA=". Append the mple:keys:123&OUC=example.com/content.mov&MD=").
string denoting the new digital signature function.
4. If an information element was added to the message, C. Compute the message digest using the HMAC algorithm and the
append an "&" character. Append the string "DS=". The default SHA-256 hash function, or another hash function if
message now contains the complete section of the URI that specified by the HF Information Element, with the shared key
is protected. (e.g. "://example.com/content.mov?ET=12094 and message as the two inputs to the hash function.
22976&CIP=192.0.2.1&KID=http://example.com/public/
keys/123&DS=").
5. Compute the message digest using SHA-1 (without a key) D. Convert the message digest to its equivalent hexadecimal
for the message. Note: The digital signature generated format.
in the next step is calculated over the SHA-1 message
digest, instead of over the cleartype message, to reduce
the length of the digital signature, and thereby the
length of 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.
6. Compute the digital signature, using the EC-DSA algorithm E. Append the string for the message digest (e.g. "ET=12094229
by default or another algorithm if specified by the DSA 76&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:
Information Element, with the private EC key and message keys:123&OUC=example.com/content.mov&MD=1ecb1446a6431352aab0
digest (obtained in previous step) as inputs. fb6e0dca30e30356593a97acb972202120dc482bddaf").
7. Convert the digital signature to its equivalent 11. If symmetric keys are used, step 11 can be skipped.
hexadecimal format.
8. Append the string for the digital signature. In the case A. Obtain the private key to be used for signing the URI.
where EC-DSA algorithm is used, this string contains the
values for the 'r' and 's' parameters, delimited by ':' B. If an information element was added to the message, append
(e.g. "://example.com/content.mov?ET=1209422976&CIP=192. an "&" character. Append the string "DS=". The message now
0.2.1&KID=http://example.com/public/keys/123&DS=r:CFB03ED contains the complete section of the URI that is protected.
B33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D (e.g. "ET=1209422976&CKI=311&CIP=90C913977933FC650E7186361A
:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A9 93D6C3&KID=example:keys:123&OUC=example.com/
29A29EA24E" ) content.mov&DS=").
C. Compute the message digest using SHA-1 (without a key) for
the message. Note: The digital signature generated in the
next step is calculated over the SHA-1 message digest,
instead of over the cleartype message. This is done to
reduce the length of the digital signature, the URI Signing
Package Attribute, and the resulting Signed URI. Since
SHA-1 is not used for cryptographic purposes here, the
security concerns around SHA-1 do not apply.
D. Compute the digital signature, using the EC-DSA algorithm by
default or another algorithm if specified by the DSA
Information Element, with the private EC key and message
digest (obtained in previous step) as inputs.
E. Convert the digital signature to its equivalent hexadecimal
format.
F. Append the string for the digital signature. In the case
where EC-DSA algorithm is used, this string contains the
values for the 'r' and 's' parameters, delimited by ':'
(e.g. "ET=1209422976&CKI=311&CIP=90C913977933FC650E7186361A
93D6C3&KID=example:keys:123&OUC=example.com/content.mov&DS=r
:CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E00
5668D:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331
A929A29EA24E")
12. If, as part of step 9, the URI Pattern Container information
element was added to the buffer, step 12 can be skipped. Remove
the Original URI Container from the buffer, including the
preceding "&" character. (e.g. "ET=1209422976&CKI=311&CIP=90C91
3977933FC650E7186361A93D6C3&KID=example:keys:123&MD=1ecb1446a643
1352aab0fb6e0dca30e30356593a97acb972202120dc482bddaf")
3.2. Packaging the URI Signature 3.2. Packaging the URI Signature
Apply the URI Signing Package Attribute by following the procedure Apply the URI Signing Package Attribute by following the procedure
below to generate the Signed URI. below to generate the Signed URI.
1. Remove the Original URI portion from the message to obtain all 1. Start from the buffer created in Section 3.1. (e.g. "ET=1209422
the URI Signing Information Elements, including the URI signature 976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:keys
(e.g. "ET=1209422976&CIP=192.0.2.1&KID=example:keys:123&MD=1ecb1 :123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc4
446a6431352aab0fb6e0dca30e30356593a97acb972202120dc482bddaf"). 82bddaf").
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. "VkVSPTEmRVQ9MTIwOTQyMjk Encoding [RFC4648] on the message (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA
3NiZDSVA9MTkyLjAuMi4xJktJRD1leGFtcGxlOmtleXM6MTIzJk1EPTFlY2IxNDQ2 7Q0tJPTMxMSZhbXA7Q0lQPTkwQzkxMzk3NzkzM0ZDNjUwRTcxODYzNjFBOTNENkMz
YTY0MzEzNTJhYWIwZmI2ZTBkY2EzMGUzMDM1NjU5M2E5N2FjYjk3MjIwMjEyMGRjN JmFtcDtLSUQ9ZXhhbXBsZTprZXlzOjEyMyZhbXA7TUQ9MWVjYjE0NDZhNjQzMTM1M
DgyYmRkYWY="). Note: This is the value for the URI Signing mFhYjBmYjZlMGRjYTMwZTMwMzU2NTkzYTk3YWNiOTcyMjAyMTIwZGM0ODJiZGRhZg
Package Attribute. =="). Note: This is the value for the URI Signing Package
Attribute.
3. Copy the entire Original URI into a buffer to hold the message. 3. Copy the entire Original URI into a buffer to hold the message.
4. Check if the Original URI already contains a query string. If 4. Check if the Original URI already contains a query string. If
not, append a "?" character. If yes, append an "&" character. not, append a "?" character. If yes, append an "&" character.
5. Append the parameter name used to indicate the URI Signing 5. 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. 6. Append the URI Signing token to the message (e.g.
"http://example.com/content.mov?URISigningPackage=VkVSPTEmRVQ9MTI "http://example.com/content.mov?URISigningPackage=RVQ9MTIwOTQyMjk
wOTQyMjk3NiZDSVA9MTkyLjAuMi4xJktJRD1leGFtcGxlOmtleXM6MTIzJk1EPTFl 3NiZhbXA7Q0tJPTMxMSZhbXA7Q0lQPTkwQzkxMzk3NzkzM0ZDNjUwRTcxODYzNjFB
Y2IxNDQ2YTY0MzEzNTJhYWIwZmI2ZTBkY2EzMGUzMDM1NjU5M2E5N2FjYjk3MjIwM OTNENkMzJmFtcDtLSUQ9ZXhhbXBsZTprZXlzOjEyMyZhbXA7TUQ9MWVjYjE0NDZhN
jEyMGRjNDgyYmRkYWY="). Note: this is the completed Signed URI. jQzMTM1MmFhYjBmYjZlMGRjYTMwZTMwMzU2NTkzYTk3YWNiOTcyMjAyMTIwZGM0OD
JiZGRhZg=="). Note: this is the completed Signed URI.
4. Validating a URI Signature 4. Validating a URI Signature
The process of validating a Signed URI can be divided into three sets The process of validating a Signed URI can be divided into three sets
of steps: first, extraction of the URI Signing information elements, of steps: first, extraction of the URI Signing information elements,
then validation of the URI signature to ensure the integrity of the then validation of the URI signature to ensure the integrity of the
Signed URI, and finally, validation of the information elements to Signed URI, and finally, validation of the information elements to
ensure proper enforcement of the distribution policy. The integrity ensure proper enforcement of the distribution policy. The integrity
of the Signed URI is confirmed before distribution policy enforcement of the Signed URI is confirmed before distribution policy enforcement
because validation procedure would detect the right event when the because validation procedure would detect the right event when the
skipping to change at page 19, line 34 skipping to change at page 21, line 20
1. Extract the value from 'URISigningPackage' attribute. This 1. Extract the value from 'URISigningPackage' attribute. This
value is the encoded URI Signing Package Attribute. If there value is the encoded URI Signing Package Attribute. If there
are multiple instances of this attribute, the first one is used are multiple instances of this attribute, the first one is used
and the remaining ones are ignored. This ensures that the and the remaining ones are ignored. This ensures that the
Signed URI can be validated despite a client appending another Signed URI can be validated despite a client appending another
instance of the 'URISigningPackage' attribute. instance of 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 all the URI Signing information elements (e.g. "ET=12094 obtain all the URI Signing information elements (e.g. "ET=12094
22976&CIP=192.0.2.1&KID=example:keys:123&MD=1ecb1446a6431352aab0 22976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:k
fb6e0dca30e30356593a97acb972202120dc482bddaf"). eys:123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb97220212
0dc482bddaf").
3. Extract the value from "VER" if the information element exists 3. 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).
skipping to change at page 20, line 14 skipping to change at page 21, line 47
5. Extract the value from "DS" if the information element exists in 5. 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 6. If neither "MD" or "DS" attribute is in the URI, then no URI
Signature exists and the request is denied. If both the "MD" 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 "CIP" if the information element exists 7. Extract the value from "UPC" if the information element exists
in the query string. The existence of this information element
indicates content delivery is enforced based on a (set of) URI
pattern(s) instead of the Original URI.
8. 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.
8. Extract the value from "ET" if the information element exists in 9. 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.
9. Extract the value from the "KID" or "KID_NUM" information 10. 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.
10. Extract the value from the "HF" information element, if it 11. 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.
11. Extract the value from the "DSA" information element, if it 12. 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
exists. The existence of this information element indicates a
different Client IP Encryption Algorithm than the default.
14. Extract the value from the "CKI" information element, if it
exists. The existence of this information element indicates a
key can be referenced using which the Client IP was encrypted.
4.2. Signature Validation 4.2. Signature Validation
Validate the URI Signature for the Signed URI. Validate the URI Signature for the Signed URI.
1. Copy the Original URI, excluding the "scheme name" part, into a 1. Copy the Signed URI into a buffer to hold the message for
buffer to hold the message for performing the operations below. performing the operations below
2. Remove the "URISigningPackage" attribute from the message. 2. Remove the "URISigningPackage" attribute from the message.
Remove any subsequent part of the query string after the Remove any subsequent part of the query string after the
"URISigningPackage" attribute. "URISigningPackage" attribute.
3. Append the decoded value from "URISigningPackage" attribute 3. Append the decoded value from "URISigningPackage" attribute
(which contains all the URI Signing Information Elements). (which contains all the URI Signing Information Elements).
4. Depending on the type of key used to sign the URI, validate the 4. Extract the value from the "MD" or "DS" information element.
message digest or digital signature for symmetric key or This is the received message signature.
asymmetric keys, respectively.
A. For symmetric key, HMAC algorithm is used. 5. Convert the message signature to binary format. This will be
used to compare with the computed value later.
a. If either the "KID" or "KID_NUM" information element 6. Remove the the "MD" or "DS" information elements from the
message.
7. If the buffer contains the UPC information element, skip this
step. Append the "&" character to the buffer. Append the
Original URI Container (OUC) information element. Append the
Original URI to the buffer, except for the scheme part and the
'://' delimiter.
8. Append the "&" character. Append "MD=" or "DS=", depending on
which of the two was present in the Signed URI. The message is
ready for validation of the message digest (e.g. "example.com/con
tent.mov?ET=1209422976&CIP=90C913977933FC650E7186361A93D6C3&KID=e
xample:keys:123&OUC=example.com/content.mov&MD=").
9. Based on the presence of either the MD or DS information element
in the buffer, validate the message digest or digital signature
for symmetric key or asymmetric keys, respectively.
A. For MD, an HMAC algorithm is used.
1. If either the "KID" or "KID_NUM" information element
exists, validate that the key identifier is in the 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
configuration. configuration.
b. If "HF" information element exists, validate that the 2. If "HF" information element exists, validate that the
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.
c. Extract the value from the "MD" information element. 3. Compute the message digest using the HMAC algorithm with
This is the received message digest.
d. Convert the message digest to binary format. This will
be used to compare with the computed value later.
e. Remove the value part of the "MD" information element
(but not the '=' character) from the message. The
message is ready for validation of the message digest
(e.g. "://example.com/content.mov?ET=1209422976&CIP=192.
0.2.1&KID=example:keys:123&MD=").
f. 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.
g. Compare the result with the received message digest to 4. Compare the result with the received message signature
validate the Signed URI. extracted in step 5 to validate the Signed URI.
B. For asymmetric keys, a digital signature function is used. B. For DS, a digital signature function is used.
a. 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
configuration. configuration.
b. If "DSA" information element exists, validate that the 2. If "DSA" information element exists, validate that the
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.
c. Extract the value from the "DS" information element. 3. Compute the message digest using SHA-1 (without a key)
This is the digital signature.
d. Convert the digital signature to binary format. This
will be used for verification later.
e. Remove the value part of the "DS" information element
(but not the '=' character) from the message. The
message is ready for validation of the digital signature
(e.g. "://example.com/content.mov?ET=1209422976&CIP=192.
0.2.1&KID=http://example.com/public/keys/123&DS=").
f. Compute the message digest using SHA-1 (without a key)
for the message. for the message.
g. 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 digest (obtained in digital signature, and message signature (extracted in
previous step) as inputs. This validates the Signed URI. step 5) as inputs. This validates the Signed URI.
4.3. Distribution Policy Enforcement 4.3. Distribution Policy Enforcement
Note the steps are to be skipped if the corresponding URI Signing Note that the absence of a given Enforcement Information Element
information elements are not in the Signed URI. The absence of a indicates enforcement of its purpose is not necessary in the CSP's
given Enforcement Information Element indicates enforcement of its distribution policy.
purpose is not necessary in the CSP's distribution policy.
1. If the "CIP" information element exists, validate that the 1. If the "CIP" information element does not exist, this step can be
request came from the same IP address as indicated in the "CIP" skipped.
information element. If the IP address is incorrect, then the
request is denied. A. Obtain the key for decrypting the Client IP, as indicated by
the Client IP Key Index information element or set via
configuration.
B. Decrypt the encrypted Client IP address obtained in step 6
using AES-128, or the algorithm specified by the Client IP
Encryption Algorithm information element.
C. Verify, using CIDR matching, that the request came from an IP
address within the range indicated by the decrypted Client IP
information element. If the IP address is incorrect, the
request is denied.
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
requested resource is in the allowed set by matching the received
URI against the URI Pattern Container information element. If
there is no match, the request is denied.
5. Relationship with CDNI Interfaces 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
skipping to change at page 23, line 32 skipping to change at page 25, line 41
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
The Downstream CDN advertises its capability to support URI Signing The Downstream CDN advertises its capability to support URI Signing
via the CDNI Footprint & Capabilities Advertisement interface (FCI). via the CDNI Footprint & Capabilities Advertisement interface (FCI).
The supported version of URI Signing needs to be included to allow The supported version of URI Signing needs to be included to allow
for future extensibility. for future extensibility.
In general, new information elements introduced to enhance URI In general, new information elements introduced to enhance URI
Signing requires a draft and a new version. ForInformation Elements, Signing requires a draft and a new version.
For Enforcement Information Elements, there is no need to For Enforcement Information Elements, there is no need to
advertise the based information elements such as "CIP" and "ET". advertise the based information elements such as "CIP" and "ET".
For Signature Computation Information Elements: For Signature Computation Information Elements:
No need to advertise "VER" Information Element unless it's not No need to advertise "VER" Information Element unless it's not
"1". In this case, a draft is needed to describe the new "1". In this case, a draft is needed to describe the new
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. EC-DSA) 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.
skipping to change at page 27, line 37 skipping to change at page 29, line 49
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].
o s-uri-signing (mandatory): o s-uri-signing (mandatory):
* format: 3DIGIT * format: 3DIGIT
* field value: this characterises the uri signing validation * field value: this characterises the URI signing validation
performed by the Surrogate on the request. The allowed values performed by the Surrogate on the request. The allowed values
are: are:
+ "0" : no uri signature validation performed + "000" : no URI signature validation performed
+ "1" : uri signature validation performed and validated + "200" : URI signature validation performed and validated
+ "2" : uri signature validation performed and rejected + "400" : URI signature validation performed and rejected
because of incorrect signature
+ "401" : URI signature validation performed and rejected
because of Expiration Time enforcement
+ "402" : URI signature validation performed and rejected
because of Client IP enforcement
+ "403" : URI signature validation performed and rejected
because of URI Pattern enforcement
+ "500" : unable to perform URI signature validation because
of malformed URI
+ "501" : unable to perform URI signature validation because
of unsupported version number
* occurrence: there MUST be zero or exactly one instance of this * 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: the rejection reason when uri signature performed * field value: a string for providing further information in case
by the Surrogate on the request. Examples: the URI signature was rejected, e.g. for debugging purposes.
+ "invalid client IP address"
+ "expired signed URI"
+ "incorrect URI signature"
* 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
skipping to change at page 35, line 4 skipping to change at page 37, line 22
o HF (Hash Function): "SHA-256" o HF (Hash Function): "SHA-256"
o DSA (Digital Signature Algorithm): "EC-DSA" o DSA (Digital Signature Algorithm): "EC-DSA"
The following URI Signature Information Element names are allocated: The following URI Signature Information Element names are allocated:
o MD (Message Digest for Symmetric Key) o MD (Message Digest for Symmetric Key)
o DS (Digital Signature for Asymmetric Keys) o DS (Digital Signature for Asymmetric Keys)
The IANA is requested to allocate a new entry to the CDNI Logging The IANA is requested to allocate a new entry to the CDNI Logging
Field Names Registry as specified in CDNI Logging Interface Field Names Registry as specified in CDNI Logging Interface
[I-D.ietf-cdni-logging] in accordance to the "Specification Required" [I-D.ietf-cdni-logging] in accordance to the "Specification Required"
policy [RFC5226] policy [RFC5226]
o s-url-signing o s-uri-signing
o s-url-signing-deny-reason o s-uri-signing-deny-reason
The IANA is requested to allocate a new entry to the "CDNI The IANA is requested to allocate a new entry to the "CDNI
GenericMetadata Types" Registry as specified in CDNI Metadata GenericMetadata Types" Registry as specified in CDNI Metadata
Interface [I-D.ietf-cdni-metadata] in accordance to the Interface [I-D.ietf-cdni-metadata] in accordance to the
"Specification Required" policy [RFC5226]: "Specification Required" policy [RFC5226]:
+------------+---------------+---------+------+------+ +------------+---------------+---------+------+------+
| Type name | Specification | Version | MTE | STR | | Type name | Specification | Version | MTE | STR |
+------------+---------------+---------+------+------+ +------------+---------------+---------+------+------+
| UriSigning | RFCthis | 1 | true | true | | UriSigning | RFCthis | 1 | true | true |
skipping to change at page 36, line 46 skipping to change at page 39, line 22
malicious clients from signing their own URIs and inserting the malicious clients from signing their own URIs and inserting the
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. This means that, when attribute) is embedded in the Signed URI. For this reason, the
anonymization is enabled, the value of the URI Signing Package mechanism described in Section 3 encrypts the Client IP before
Attribute MUST be removed from the logging record. 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 and Leif Hedstrom. In addition, Matt Caulfield provided Oprescu, Leif Hedstrom and Phil Sorber. In addition, Matt Caulfield
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-19 (work in progress), July 2015. logging-21 (work in progress), November 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [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>.
[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-11 (work in progress), July 2015. metadata-12 (work in progress), October 2015.
[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-11 (work in progress), July 2015. ietf-cdni-redirection-13 (work in progress), October 2015.
[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>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<http://www.rfc-editor.org/info/rfc3174>.
[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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <http://www.rfc-editor.org/info/rfc4648>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
 End of changes. 89 change blocks. 
301 lines changed or deleted 411 lines changed or added

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