draft-ietf-cdni-uri-signing-10.txt   draft-ietf-cdni-uri-signing-11.txt 
CDNI R. van Brandenburg CDNI R. van Brandenburg
Internet-Draft TNO Internet-Draft Tiledmedia
Intended status: Standards Track K. Leung Intended status: Standards Track K. Leung
Expires: April 7, 2017 Cisco Systems, Inc. Expires: November 19, 2017 Cisco Systems, Inc.
P. Sorber P. Sorber
Comcast Cable Communications Comcast Cable Communications
M. Miller M. Miller
Cisco Systems, Inc. Mozilla
October 4, 2016 May 18, 2017
URI Signing for CDN Interconnection (CDNI) URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-10 draft-ietf-cdni-uri-signing-11
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 method as a JSON Web Token (JWT) [RFC7519] profile. signing method as a JSON Web Token (JWT) [RFC7519] profile.
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 to transmit the signed JWT as well as the be included in the URI to transmit the signed JWT as well as the
claims needed by the signed JWT to authorize a UA. The mechanism claims needed by the signed JWT to authorize a UA. The mechanism
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 April 7, 2017. This Internet-Draft will expire on November 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . 4
1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 5 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 5
1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 7 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8
2. JWT Format and Processing Requirements . . . . . . . . . . . 7 2. JWT Format and Processing Requirements . . . . . . . . . . . 8
2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. URI Container Forms . . . . . . . . . . . . . . . . . 10 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 9
2.1.1.1. URI Simple Container (uri:) . . . . . . . . . . . 11 2.1.2. URI Container (sub) claim . . . . . . . . . . . . . . 10
2.1.1.2. URI Pattern Container (uri-pattern:) . . . . . . 11 2.1.3. Client IP (aud) claim . . . . . . . . . . . . . . . . 10
2.1.1.3. URI Regular Expression Container (uri-regex:) . . 12 2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 10
3. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 12 2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11
3.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 12 2.1.6. Issued At (ait) claim . . . . . . . . . . . . . . . . 11
3.2. CDNI Footprint & Capabilities Advertisement Interface . . 12 2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 11
3.3. CDNI Request Routing Redirection Interface . . . . . . . 13 2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12
3.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 13 2.1.9. URI Container Forms . . . . . . . . . . . . . . . . . 12
3.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 14 2.1.9.1. URI Simple Container (uri:) . . . . . . . . . . . 12
4. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 15 2.1.9.2. URI Pattern Container (uri-pattern:) . . . . . . 12
4.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 16 2.1.9.3. URI Regular Expression Container (uri-regex:) . . 13
4.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 18 2.1.9.4. URI Hash Container (uri-hash:) . . . . . . . . . 13
5. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 21 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 3. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 14
6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 21 3.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 14
6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 21 3.2. CDNI Footprint & Capabilities Advertisement Interface . . 14
6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 22 3.3. CDNI Request Routing Redirection Interface . . . . . . . 14
6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 22 3.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 14
6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 22 3.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 4. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 17
8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 4.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 25 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Signed URI Package Example . . . . . . . . . . . . . 26 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 23
A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 26 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 24
A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 27 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 24
6.4. JSON Web Token Claims Registration . . . . . . . . . . . 24
6.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Signed URI Package Example . . . . . . . . . . . . . 28
A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 29
A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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
scheme; if a CSP wants to protect the content itself, other scheme; if a CSP wants to protect the content itself, other
mechanisms, such as DRM, are more appropriate. In addition to access mechanisms, such as Digital Rights Management (DRM), are more
control, URI Signing also has benefits in reducing the impact of appropriate. In addition to access control, URI Signing also has
denial-of-service attacks. 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]. This document, along with the in CDNI Problem Statement [RFC6707]. This document, along with the
CDNI Requirements [RFC7337] document and the CDNI Framework CDNI Requirements [RFC7337] document and the CDNI Framework
[RFC7336], describes the need for interconnected CDNs to be able to [RFC7336], describes the need for interconnected CDNs to be able to
implement an access control mechanism that enforces the CSP's implement an access control mechanism that enforces the CSP's
distribution policy. distribution policy.
Specifically, CDNI Framework [RFC7336] states: Specifically, CDNI Framework [RFC7336] states:
"The CSP may also trust the CDN operator to perform actions such as "The CSP may also trust the CDN operator to perform actions such as
..., and to enforce per-request authorization performed by the CSP ..., and to enforce per-request authorization performed by the CSP
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 interface shall allow signaling of
signaling of authorization checks and validation that are to be authorization checks and validation that are to be performed by the
performed by the surrogate before delivery. For example, this could Surrogate before delivery. For example, this could potentially
potentially include: include the need to validate information (e.g., Expiry time, Client
IP address) required for access authorization.
* need to validate URI signed information (e.g., Expiry time, Client
IP address)."
This document proposes a method of signing URIs that allows This document proposes a method of signing URIs that allows
Surrogates in interconnected CDNs to enforce a per-request Surrogates in interconnected CDNs to enforce a per-request
authorization performed by the CSP. Splitting the role of performing authorization performed by the CSP. Splitting the role of performing
per-request authorization by the CSP and the role of validating this per-request authorization by the CSP and the role of validating this
authorization by the CDN allows any arbitrary distribution policy to authorization by the CDN allows any arbitrary distribution policy to
be enforced across CDNs without the need of CDNs to have any be enforced across CDNs without the need of CDNs to have any
awareness of the actual CSP distribution policy. awareness of the actual CSP distribution policy.
The representation of this method is a Signed JSON Web Token (JWT) The representation of this method is a Signed JSON Web Token (JWT)
skipping to change at page 4, line 22 skipping to change at page 4, line 32
document are to be interpreted as described in [RFC2119]. 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 JSON Web Token (JWT) This document also uses the terminology of JSON Web Token (JWT)
[RFC7519]. [RFC7519].
In addition, the following terms are used throughout this document: In addition, the following terms are used throughout this document:
o Signed URI: A URI that contains a signed JWT for itself. o Signed URI: A URI for which a signed JWT is provided.
o Target CDN URI: URI created by the CSP to direct UA towards the o Target CDN URI: URI created by the CSP to direct a UA towards the
Upstream CDN (uCDN). The Target CDN URI can be signed by the CSP Upstream CDN (uCDN). The Target CDN URI can be signed by the CSP
and verified by the uCDN. and verified by the uCDN and possibly further Downstream CDNs
(dCDNs).
o Redirection URI: URI created by the uCDN to redirect UA towards o Redirection URI: URI created by the uCDN to redirect a UA towards
the Downstream CDN (dCDN). The Redirection URI can be signed by the dCDN. The Redirection URI can be signed by the uCDN and
the uCDN and verified by the dCDN. In a cascaded CDNI scenario, verified by the dCDN. In a cascaded CDNI scenario, there can be
there can be more than one Redirection URI. more than one Redirection 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
claims in the form of a signed JWT in the URI before redirecting a UA claims in the form of a signed JWT in the URI before redirecting a UA
to the CDN. Using these attributes, it is possible for a CDN to to the CDN. Using these attributes, it is possible for a CDN to
check an incoming content request to see whether it was authorized by check an incoming content request to see whether it was authorized by
the CSP (e.g., based on the UA's IP address or a time window). To the CSP (e.g., based on the UA's IP address or a time window). To
prevent the UA from altering the claims a signed JWT is REQUIRED. prevent the UA from altering the claims a signed JWT is REQUIRED.
skipping to change at page 7, line 13 skipping to change at page 8, line 13
with the uCDN but may have no relationship with the CSP. with the uCDN but 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 dCDN directly. In Target CDN URI) provided by the CSP reaches the dCDN directly. In
the case where the dCDN does not have a trust relationship with the the case where the dCDN does not have a trust relationship with the
CSP, this means that either an asymmetric public/private key method CSP, this means that either an asymmetric public/private key method
needs to be used for computing the signed JWT (because the CSP and needs to be used for computing the signed JWT (because the CSP and
dCDN are not able to exchange symmetric shared secret keys), or the dCDN are not able to exchange symmetric shared secret keys), or the
CSP needs to allow the uCDN to redistribute shared keys to a subset CSP needs to allow the uCDN to redistribute shared keys to a subset
of their dCDNs . of their dCDNs.
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 uCDN. After this URI has been provided by the CSP reaches the uCDN. After this URI has been
verified to be correct by the uCDN, the uCDN creates and signs a new verified to be correct by the uCDN, the uCDN creates and signs a new
Redirection URI to redirect the UA to the dCDN. Since this new URI Redirection URI to redirect the UA to the dCDN. Since this new URI
also has a new signed JWT, this new signature can be based around the could have a new signed JWT, a new signature can be based around the
trust relationship between the uCDN and dCDN, and the relationship trust relationship between the uCDN and dCDN, and the relationship
between the dCDN and CSP is not relevant. Given the fact that such a between the dCDN and CSP is not relevant. Given the fact that such a
relationship between uCDN and dCDN always exists, both asymmetric relationship between uCDN and dCDN always exists, both asymmetric
public/private keys and symmetric shared secret keys can be used for public/private keys and symmetric shared secret keys can be used for
URI Signing with HTTP-based request routing. Note that the signed URI Signing with HTTP-based request routing. Note that the signed
Redirection URI MUST maintain the same, or higher, level of security Redirection URI MUST maintain the same, or higher, level of security
as the original Signed URI. as the original Signed URI.
1.4. URI Signing in a non-CDNI context 1.4. URI Signing in a non-CDNI context
skipping to change at page 7, line 42 skipping to change at page 8, line 42
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 method that precludes it from nothing in the defined URI Signing method 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. JWT Format and Processing Requirements 2. JWT Format and Processing Requirements
The concept behind URI Signing is based on embedding a signed JSON The concept behind URI Signing is based on embedding a signed JSON
Web Token (JWT) [RFC7519] in the Target CDN URI/Redirection URI. The Web Token (JWT) [RFC7519] in the UA request: The signed JWT contains
signed JWT contains a number of claims that can be validated to a number of claims that can be validated to ensure the UA has
ensure the UA has legitimate access to the content. legitimate access to the content.
In addition, this document specifies the following URI attribute: This document specifies the following attribute for embedding a
signed JWT in a Target CDN URI or Redirection URI:
o URI Signing Package (URISigningPackage): The URI attribute that o URI Signing Package (URISigningPackage): The URI attribute that
encapsulates all the URI Signing claims in a signed JWT encoded encapsulates all the URI Signing claims in a signed JWT encoded
format. This attribute is exposed in the Signed URI as a URI format. This attribute is exposed in the Signed URI as a URI
query parameter or as a URL path parameter. query parameter or as a URL path parameter.
The parameter name of the URI Signing Package Attribute is defined in The parameter name of the URI Signing Package Attribute is defined in
the CDNI Metadata. If the CDNI Metadata interface is not used, or the CDNI Metadata (Section 3.4). If the CDNI Metadata interface is
does not include a parameter name for the URI Signing Package not used, or does not include a parameter name for the URI Signing
Attribute, the parameter name can be set by configuration (out of Package Attribute, the parameter name can be set by configuration
scope of this document). (out of scope of this document).
2.1. JWT Claims 2.1. JWT Claims
This section identifies the set of claims that can be used to enforce This section identifies the set of claims that can be used to enforce
the CSP distribution policy. New claims can be introduced in the the CSP distribution policy. New claims can be introduced in the
future to extend the distribution policy capabilities. future to extend the distribution policy capabilities.
In order to provide distribution policy flexibility, the exact subset In order to provide distribution policy flexibility, the exact subset
of claims used in a given signed JWT is a runtime decision. Claim of claims used in a given signed JWT is a runtime decision. Claim
requirements are defined in the CDNI Metadata. If the CDNI Metadata requirements are defined in the CDNI Metadata (Section 3.4) If the
interface is not used, or does not include claim requirements, the CDNI Metadata interface is not used, or does not include claim
claim requirements can be set by configuration (out of scope of this requirements, the claim requirements can be set by configuration (out
document). of scope of this document).
The following claims (where the "JSON Web Token Claims" registry The following claims (where the "JSON Web Token Claims" registry
claim name is specified in parenthesis below) are used to enforce the claim name is specified in parenthesis below) are used to enforce the
distribution policies. All of the listed claims are mandatory to distribution policies. All of the listed claims are mandatory to
implement in a URI Signing implementation, but are not mandatory to implement in a URI Signing implementation, but are not mandatory to
use in a given signed JWT. (The "optional" and "mandatory" use in a given signed JWT. (The "optional" and "mandatory"
identifiers in square brackets refer to whether or not a given claim identifiers in square brackets refer to whether or not a given claim
MUST be present in a URI Signing JWT.) A CDN MUST be able to parse MUST be present in a URI Signing JWT.) A CDN MUST be able to parse
and process all of the claims listed below. If the signed JWT and process all of the claims listed below. If the signed JWT
contains any claims which the CDN does not understand (i.e., is contains any other claims which the CDN does not understand (i.e., is
unable to parse and process), the CDN MUST reject the request. unable to parse and process), the CDN MUST reject the request.
o Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1 Note: See the Security Considerations (Section 7) section on the
MUST be followed. This claim MAY be used to validate limitations of using an expiration time and client IP address for
authorization of the issuer of a signed JWT and also MAY be used distribution policy enforcement.
to confirm that the indicated key was provided by said issuer. If
the CDN validating the signed JWT does not support Issuer
validation, or if the Issuer in the signed JWT does not match the
list of known acceptable Issuers, the CDN MUST reject the request.
If the received signed JWT contains an Issuer claim, then any JWT
subsequently generated for CDNI redirection MUST also contain an
Issuer claim, and the Issuer value MUST be updated to identify the
redirecting CDN. If the received signed JWT does not contain an
Issuer claim, an Issuer claim MAY be added to a signed JWT
generated for CDNI redirection.
o URI Container (sub) [mandatory] - The semantics in [RFC7519] 2.1.1. Issuer (iss) claim
Section 4.1.2 MUST be followed. Container for holding the URI
representation before the URI Signing Package is added. This
representation can take one of several forms detailed in
Section 2.1.1. If the URI pattern/regex in the signed JWT does
not match the URI of the content request, the CDN validating the
signed JWT MUST reject the request. When redirecting a URI, the
CDN generating the new signed JWT MAY change the URI Container to
comport with the URI being used in the redirection.
o Client IP (aud) [optional] - The semantics in [RFC7519] Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1
Section 4.1.3 MUST be followed. IP address, or IP prefix, for MUST be followed. This claim MAY be used to validate authorization
which the Signed URI is valid. This is represented in CIDR of the issuer of a signed JWT and also MAY be used to confirm that
notation, with dotted decimal format for IPv4 or canonical text the indicated key was provided by said issuer. If the CDN validating
representation for IPv6 addresses [RFC5952]. The request is the signed JWT does not support Issuer validation, or if the Issuer
rejected if sourced from a client outside of the specified IP in the signed JWT does not match the list of known acceptable
range. Since the client IP is considered personally identifiable Issuers, the CDN MUST reject the request. If the received signed JWT
information this field MUST be a JSON Web Encryption (JWE contains an Issuer claim, then any JWT subsequently generated for
[RFC7516]) Object in compact serialization form. If the CDN CDNI redirection MUST also contain an Issuer claim, and the Issuer
validating the signed JWT does not support Client IP validation, value MUST be updated to identify the redirecting CDN. If the
or if the Client IP in the signed JWT does not match the source IP received signed JWT does not contain an Issuer claim, an Issuer claim
address in the content request request, the CDN MUST reject the MAY be added to a signed JWT generated for CDNI redirection.
request. If the received signed JWT contains a Client IP claim,
then any JWT subsequently generated for CDNI redirection MUST also
contain a Client IP claim, and the Client IP value MUST be the
same as in the received signed JWT. A signed JWT generated for
CDNI redirection MUST NOT add a Client IP claim if no Client IP
claim existed in the received signed JWT.
o Expiry Time (exp) [optional] - The semantics in [RFC7519] 2.1.2. URI Container (sub) claim
Section 4.1.4 MUST be followed, though URI Signing implementations
MUST not allow for any time synchronization "leeway". Note: The
time on the entities that generate and validate the signed URI
SHOULD be in sync. In the CDNI case, this means that CSP, uCDN
and dCDN servers need to be time-synchronized. It is RECOMMENDED
to use NTP for time synchronization. If the CDN validating the
signed JWT does not support Expiry Time validation, or if the
Expiry Time in the signed JWT corresponds to a time earlier than
the time of the content request request, the CDN MUST reject the
request. If the received signed JWT contains a Expiry Time claim,
then any JWT subsequently generated for CDNI redirection MUST also
contain an Expiry Time claim, and the Expiry Time value MUST be
the same as in the received signed JWT. A signed JWT generated
for CDNI redirection MUST NOT add an Expiry Time claim if no
Expiry Time claim existed in the received signed JWT.
o Not Before (nbf) [optional] - The semantics in [RFC7519] URI Container (sub) [mandatory] - The semantics in [RFC7519]
Section 4.1.5 MUST be followed, though URI Signing implementations Section 4.1.2 MUST be followed. Container for holding the URI
MUST not allow for any time synchronization "leeway". Note: The representation before a URI Signing Package is added. This
time on the entities that generate and validate the signed URI representation can take one of several forms detailed in
SHOULD be in sync. In the CDNI case, this means that the CSP, Section 2.1.9. If the URI pattern/regex in the signed JWT does not
uCDN, and dCDN servers need to be time-synchronized. It is match the URI of the content request, the CDN validating the signed
RECOMMENDED to use NTP for time synchronization. If the CDN JWT MUST reject the request. When comparing the URI the percent
validating the signed JWT does not support Not Before time encoded form as defined in [RFC3986] Section 2.1 MUST be used. When
validation, or if the Not Before time in the signed JWT redirecting a URI, the CDN generating the new signed JWT MAY change
corresponds to a time later than the time of the content request the URI Container to comport with the URI being used in the
request, the CDN MUST reject the request. If the received signed redirection.
JWT contains a Not Before time claim, then any JWT subsequently
generated for CDNI redirection MUST also contain a Not Before time
claim, and the Not Before time value MUST be the same as in the
received signed JWT. A signed JWT generated for CDNI redirection
MUST NOT add a Not Before time claim if no Not Before time claim
existed in the received signed JWT.
o Issued At (iat) [optional] - The semantics in [RFC7519] 2.1.3. Client IP (aud) claim
Section 4.1.6 MUST be followed. Note: The time on the entities
that generate and validate the signed URI SHOULD be in sync. In
the CDNI case, this means that CSP, uCDN, and dCDN servers need to
be time-synchronized. It is RECOMMENDED to use NTP for time
synchronization. If the received signed JWT contains an Issued At
claim, then any JWT subsequently generated for CDNI redirection
MUST also contain an Issued At claim, and the Issuer value MUST be
updated to identify the time the new JWT was generated. If the
received signed JWT does not contain an Issued At claim, an Issued
At claim MAY be added to a signed JWT generated for CDNI
redirection.
o Nonce (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 Client IP (aud) [optional] - The semantics in [RFC7519] Section 4.1.3
MUST be followed. Can be used to prevent replay attacks if the MUST be followed. IP address, or IP prefix, for which the Signed URI
CDN stores a list of all previously used Nonce values, and is valid. This is represented in CIDR notation, with dotted decimal
validates that the Nonce in the current JWT has never been used format for IPv4 or canonical text representation for IPv6 addresses
before. If the signed JWT contains a Nonce claim and the CDN [RFC5952]. The request is rejected if sourced from a client outside
validating the signed JWT does not support Nonce storage, then the of the specified IP range. Since the client IP is considered
CDN MUST reject the request. If the received signed JWT contains personally identifiable information this field MUST be a JSON Web
a Nonce claim, then any JWT subsequently generated for CDNI Encryption (JWE [RFC7516]) Object in compact serialization form. If
redirection MUST also contain a Nonce claim, and the Nonce value the CDN validating the signed JWT does not support Client IP
MUST be the same as in the received signed JWT. If the received validation, or if the Client IP in the signed JWT does not match the
signed JWT does not contain a Nonce claim, a Nonce claim MAY be source IP address in the content request, the CDN MUST reject the
added to a signed JWT generated for CDNI redirection. request. If the received signed JWT contains a Client IP claim, then
any JWT subsequently generated for CDNI redirection MUST also contain
a Client IP claim, and the Client IP value MUST be the same as in the
received signed JWT. A signed JWT generated for CDNI redirection
MUST NOT add a Client IP claim if no Client IP claim existed in the
received signed JWT.
Note: See the Security Considerations (Section 7) section on the 2.1.4. Expiry Time (exp) claim
limitations of using an expiration time and client IP address for
distribution policy enforcement.
2.1.1. URI Container Forms Expiry Time (exp) [optional] - The semantics in [RFC7519]
Section 4.1.4 MUST be followed, though URI Signing implementations
MUST NOT allow for any time synchronization "leeway". Note: The time
on the entities that generate and validate the signed URI SHOULD be
in sync. In the CDNI case, this means that CSP, uCDN, and dCDN
servers need to be time-synchronized. It is RECOMMENDED to use NTP
[RFC5905] for time synchronization. If the CDN validating the signed
JWT does not support Expiry Time validation, or if the Expiry Time in
the signed JWT corresponds to a time earlier than the time of the
content request, the CDN MUST reject the request. If the received
signed JWT contains a Expiry Time claim, then any JWT subsequently
generated for CDNI redirection MUST also contain an Expiry Time
claim, and the Expiry Time value MUST be the same as in the received
signed JWT. A signed JWT generated for CDNI redirection MUST NOT add
an Expiry Time claim if no Expiry Time claim existed in the received
signed JWT.
2.1.5. Not Before (nbf) claim
Not Before (nbf) [optional] - The semantics in [RFC7519]
Section 4.1.5 MUST be followed, though URI Signing implementations
MUST not allow for any time synchronization "leeway". Note: The time
on the entities that generate and validate the signed URI SHOULD be
in sync. In the CDNI case, this means that the CSP, uCDN, and dCDN
servers need to be time-synchronized. It is RECOMMENDED to use NTP
[RFC5905] for time synchronization. If the CDN validating the signed
JWT does not support Not Before time validation, or if the Not Before
time in the signed JWT corresponds to a time later than the time of
the content request, the CDN MUST reject the request. If the
received signed JWT contains a Not Before time claim, then any JWT
subsequently generated for CDNI redirection MUST also contain a Not
Before time claim, and the Not Before time value MUST be the same as
in the received signed JWT. A signed JWT generated for CDNI
redirection MUST NOT add a Not Before time claim if no Not Before
time claim existed in the received signed JWT.
2.1.6. Issued At (ait) claim
Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6
MUST be followed. Note: The time on the entities that generate and
validate the signed URI SHOULD be in sync. In the CDNI case, this
means that CSP, uCDN, and dCDN servers need to be time-synchronized.
It is RECOMMENDED to use NTP [RFC5905] for time synchronization. If
the received signed JWT contains an Issued At claim, then any JWT
subsequently generated for CDNI redirection MUST also contain an
Issued At claim, and the Issuer value MUST be updated to identify the
time the new JWT was generated. If the received signed JWT does not
contain an Issued At claim, an Issued At claim MAY be added to a
signed JWT generated for CDNI redirection.
2.1.7. Nonce (jti) claim
Nonce (jti) [optional] - The semantics in [RFC7519] Section 4.1.7
MUST be followed. A Nonce can be used to prevent replay attacks if
the CDN stores a list of all previously used Nonce values, and
validates that the Nonce in the current JWT has never been used
before. If the signed JWT contains a Nonce claim and the CDN
validating the signed JWT does not support Nonce storage, then the
CDN MUST reject the request. If the received signed JWT contains a
Nonce claim, then any JWT subsequently generated for CDNI redirection
MUST also contain a Nonce claim, and the Nonce value MUST be the same
as in the received signed JWT. If the received signed JWT does not
contain a Nonce claim, a Nonce claim MUST NOT be added to a signed
JWT generated for CDNI redirection.
2.1.8. CDNI Claim Set Version (cdniv) claim
CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set
Version (cdniv) claim provides a means within a signed JWT to tie the
claim set to a specific version of a specificiation. This is
intended to allow changes in and facilitate upgrades across
specifications. The type is JSON integer and the value MUST be set
to "1", for this version of the specification. In the absence of
this claim, the value is assumed to be "1". For future versions this
claim will be mandatory. Implementations MUST reject signed JWTs
with unsupported CDNI Claim Set versions.
2.1.9. URI Container Forms
The URI Container (sub) claim takes one of the following forms. More The URI Container (sub) claim takes one of the following forms. More
forms may be added in the future to extend the capabilities. forms may be added in the future to extend the capabilities.
2.1.1.1. URI Simple Container (uri:) 2.1.9.1. URI Simple Container (uri:)
When prefixed with 'uri:', the string following 'uri:' is the URI When prefixed with 'uri:', the string following 'uri:' is the URI
that MUST be matched with a simple string match to the requested URI. that MUST be matched with a simple string match to the requested URI.
2.1.1.2. URI Pattern Container (uri-pattern:) 2.1.9.2. URI Pattern Container (uri-pattern:)
Prefixed with 'uri-pattern:', this string contains one or more URI Prefixed with 'uri-pattern:', this string contains one or more URI
Patterns that describes for which content the Signed URI is valid. Patterns that describes for which content the Signed URI is valid.
Each URI Pattern contains an expression to match against the Each URI Pattern contains an expression to match against the
requested URI, to check whether the requested content is allowed to requested URI, to check whether the requested content is allowed to
be served. Multiple URI Patterns may be concatenated in a single URI be served. Multiple URI Patterns may be concatenated in a single URI
Pattern by separating them with a semi-colon (';') character. Each Pattern by separating them with a semi-colon (';') character. Each
URI Pattern follows the [RFC3986] URI format, including the '://' URI Pattern follows the [RFC3986] URI format, including the '://'
that delimits the URI scheme from the hierarchy part. The pattern that delimits the URI scheme from the hierarchy part. The pattern
may include the special literals: may include the special literals:
skipping to change at page 12, line 5 skipping to change at page 13, line 26
http://*/folder/content-83112371/manifest/*.xml; http://*/folder/content-83112371/manifest/*.xml;
http://*/folder/content-83112371/quality_*/segment????.mp4 http://*/folder/content-83112371/quality_*/segment????.mp4
In order to increase the performance of string parsing the URI In order to increase the performance of string parsing the URI
Pattern, implementations can check often-used URI Pattern prefixes to Pattern, implementations can check often-used URI Pattern prefixes to
quickly check whether certain URI components can be ignored. For quickly check whether certain URI components can be ignored. For
example, URI Pattern prefixes '*://*/' or '*://*:*' will be used in example, URI Pattern prefixes '*://*/' or '*://*:*' will be used in
case the scheme and authority components of the URI are ignored for case the scheme and authority components of the URI are ignored for
purposes of pattern enforcement. purposes of pattern enforcement.
2.1.1.3. URI Regular Expression Container (uri-regex:) 2.1.9.3. URI Regular Expression Container (uri-regex:)
Prefixed with 'uri-regex:', this string is any PCRE [PCRE839] Prefixed with 'uri-regex:', this string is any PCRE [PCRE839]
compatible regular expression used to match against the requested compatible regular expression used to match against the requested
URI. URI.
Note: Because '\' has special meaning in JSON [RFC7159] as the escape Note: Because '\' has special meaning in JSON [RFC7159] as the escape
character within JSON strings, the regular expression character '\' character within JSON strings, the regular expression character '\'
MUST be escaped as '\\'. MUST be escaped as '\\'.
An example of a 'uri-regex:' is the following: An example of a 'uri-regex:' is the following:
.*\\://.*/folder/content-83112371/quality_.*/segment.{3}\\.mp4 .*\\://.*/folder/content-83112371/quality_.*/segment.{3}\\.mp4
Note: Due to computational complexity of executing arbitrary regular Note: Due to computational complexity of executing arbitrary regular
expressions, it is RECOMMENDED to only execute after validating the expressions, it is RECOMMENDED to only execute after validating the
JWT to ensure its authenticity. JWT to ensure its authenticity.
2.1.9.4. URI Hash Container (uri-hash:)
Prefixed with 'uri-hash:', this string is a URL Segment form
([RFC6920] Section 5) of the URI.
2.2. JWT Header
The header of the JWT MAY be passed via the CDNI Metadata interface
instead of being included in the URISigningPackage. The header value
must be transmitted in the serialized encoded form and prepended to
the JWT payload and signature passed in the URISigningPackage prior
to validation. This reduces the size of the signed JWT token.
3. Relationship with CDNI Interfaces 3. 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 dCDN that supports URI Signing needs to be able to As an example: A dCDN that supports URI Signing needs to be able to
advertise this capability to the uCDN. The uCDN needs to select a advertise this capability to the uCDN. The uCDN needs to select a
dCDN based on such capability when the CSP requires access control to dCDN based on such capability when the CSP requires access control to
enforce its distribution policy via URI Signing. Also, the uCDN enforce its distribution policy via URI Signing. Also, the uCDN
needs to be able to distribute via the CDNI Metadata interface the needs to be able to distribute via the CDNI Metadata interface the
information necessary to allow the dCDN to validate a Signed URI. information necessary to allow the dCDN to validate a Signed URI.
Events that pertain to URI Signing (e.g., request denial or delivery Events that pertain to URI Signing (e.g., request denial or delivery
skipping to change at page 12, line 44 skipping to change at page 14, line 34
communicated through the CDNI Logging interface (Editor's Note: Is communicated through the CDNI Logging interface (Editor's Note: Is
this within the scope of the CDNI Logging interface?). this within the scope of the CDNI Logging interface?).
3.1. CDNI Control Interface 3.1. CDNI Control Interface
URI Signing has no impact on this interface. URI Signing has no impact on this interface.
3.2. CDNI Footprint & Capabilities Advertisement Interface 3.2. CDNI Footprint & Capabilities Advertisement Interface
The CDNI Request Routing: Footprint and Capabilities Semantics The CDNI Request Routing: Footprint and Capabilities Semantics
document [I-D.ietf-cdni-footprint-capabilities-semantics] defines document [RFC8008] defines support for advertising CDNI Metadata
support for advertising CDNI Metadata capabilities, via CDNI Payload capabilities, via CDNI Payload Type. The CDNI Payload Type
Type. The CDNI Payload Type registered in Section 6.1 can be used registered in Section 6.1 can be used for capability advertisement.
for capability advertisement.
3.3. CDNI Request Routing Redirection Interface 3.3. CDNI Request Routing Redirection Interface
The CDNI Request Routing Redirection Interface The CDNI Request Routing Redirection Interface [RFC7975] describes
[I-D.ietf-cdni-redirection] describes the recursive request the recursive request redirection method. For URI Signing, the uCDN
redirection method. For URI Signing, the uCDN signs the URI provided signs the URI provided by the dCDN. URI Signing therefore has has no
by the dCDN. URI Signing therefore has has no impact on this impact on this interface.
interface.
3.4. CDNI Metadata Interface 3.4. CDNI Metadata Interface
The CDNI Metadata Interface [I-D.ietf-cdni-metadata] describes the The CDNI Metadata Interface [RFC8006] describes the CDNI metadata
CDNI metadata distribution in order to enable content acquisition and distribution needed to enable content acquisition and delivery. For
delivery. For URI Signing, a new CDNI metadata object is specified. URI Signing, a new CDNI metadata object is specified.
The UriSigning Metadata object contains information to enable URI The UriSigning Metadata object contains information to enable URI
signing and validation by a dCDN. The UriSigning properties are signing and validation by a dCDN. The UriSigning properties are
defined below. defined below.
Property: enforce Property: enforce
Description: URI Signing enforcement flag. Specifically, this Description: URI Signing enforcement flag. Specifically, this
flag indicates if the access to content is subject to URI flag indicates if the access to content is subject to URI
Signing. URI Signing requires the dCDN to ensure that the URI Signing. URI Signing requires the dCDN to ensure that the URI
skipping to change at page 14, line 5 skipping to change at page 15, line 40
empty list means that any Issuer is acceptable. empty list means that any Issuer is acceptable.
Property: package-attribute Property: package-attribute
Description: The name to use for the URI Signing Package. Description: The name to use for the URI Signing Package.
Type: String Type: String
Mandatory-to-Specify: No. Default is "URISigningPackage". Mandatory-to-Specify: No. Default is "URISigningPackage".
Property: jwt-header
Description: The header part of JWT that is used for generating
or validating a signed JWT when the JWT token in the URI
Signing Package does not contain a header part.
Type: String
Mandatory-to-Specify: No. A jwt-header is not essential for
all implementations of URI signing.
The following is an example of a URI Signing metadata payload with The following is an example of a URI Signing metadata payload with
all default values: all default values:
{ {
"generic-metadata-type": "MI.UriSigning" "generic-metadata-type": "MI.UriSigning"
"generic-metadata-value": {} "generic-metadata-value": {}
} }
The following is an example of a URI Signing metadata payload with The following is an example of a URI Signing metadata payload with
explicit values: explicit values:
skipping to change at page 14, line 35 skipping to change at page 16, line 32
3.5. CDNI Logging Interface 3.5. CDNI Logging Interface
For URI Signing, the dCDN reports that enforcement of the access For URI Signing, the dCDN reports that enforcement of the access
control was applied to the request for content delivery. When the control was applied to the request for content delivery. When the
request is denied due to enforcement of URI Signing, the reason is request is denied due to enforcement of URI Signing, the reason is
logged. 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], using the new Interface [RFC7937], using the new "cdni_http_request_v2" record-type
"cdni_http_request_v2" record-type registered in Section 6.2.1. registered in Section 6.2.1.
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:
+ "000" : no signed JWT validation performed + "000" : no signed JWT validation performed
skipping to change at page 16, line 10 skipping to change at page 17, line 52
the payload of a JSON Web Signature (JWS) structure or as the the payload of a JSON Web Signature (JWS) structure or as the
plaintext of a JSON Web Encryption (JWE) structure, enabling the plaintext of a JSON Web Encryption (JWE) structure, enabling the
claims to be digitally signed or integrity protected with a Message claims to be digitally signed or integrity protected with a Message
Authentication Code (MAC) and/or encrypted. Authentication Code (MAC) and/or encrypted.
4.1. HTTP Redirection 4.1. HTTP Redirection
For HTTP-based request routing, a set of information that is unique For HTTP-based request routing, a set of information that is unique
to a given end user content request is included in a signed JWT, to a given end user content request is included in a signed JWT,
using key information that is specific to a pair of adjacent CDNI using key information that is specific to a pair of adjacent CDNI
hops (e.g. between the CSP and the uCDN, between the uCDN and a hops (e.g., between the CSP and the uCDN or between the uCDN and a
dCDN). This allows a CDNI hop to ascertain the authenticity of a dCDN). This allows a CDNI hop to ascertain the authenticity of a
given request received from a previous CDNI hop. given request received from a previous CDNI hop.
The URI signing method described below is based on the following The URI signing method described below is based on the following
steps (assuming HTTP redirection, iterative request routing, and a steps (assuming HTTP redirection, iterative request routing, and a
CDN path with two CDNs). Note that uCDN and uCDN are used CDN path with two CDNs). Note that uCDN and uCDN are used
exchangeably. exchangeably.
End-User dCDN uCDN CSP End-User dCDN uCDN CSP
| | | | | | | |
skipping to change at page 17, line 39 skipping to change at page 19, line 33
include a key value. include a key value.
3. Using the CDNI Metadata interface, the uCDN communicates to a 3. Using the CDNI Metadata interface, the uCDN communicates to a
dCDN the information needed to validate signed JWTs from the dCDN the information needed to validate signed JWTs from the
uCDN for the given CSP. For example, this information may uCDN for the given CSP. For example, this information may
include the URI query string parameter name for the URI Signing include the URI query string parameter name for the URI Signing
Package Attribute. Package Attribute.
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 personal distribution policy.
5. If the authorization decision is negative, the CSP rejects the 5. If the authorization decision is negative, the CSP rejects the
request. request and sends an error code (e.g., 403 Forbidden) in the
HTTP response.
6. If the authorization decision is positive, the CSP computes a 6. If the authorization decision is positive, the CSP computes a
Signed URI that is based on unique parameters of that request Signed URI that is based on unique parameters of that request
and conveys it to the end user as the URI to use to request the and conveys it to the end user as the URI to use to request the
content. content.
7. On receipt of the corresponding content request, the uCDN 7. On receipt of the corresponding content request, the uCDN
validates the signed JWT in the URI using the information validates the signed JWT in the URI using the information
provided by the CSP. provided by the CSP.
8. If the validation is negative, the uCDN rejects the request. 8. If the validation is negative, the uCDN rejects the request and
sends an error code (e.g., 403 Forbidden) in the HTTP response.
9. If the validation is positive, the uCDN computes a Signed URI 9. If the validation is positive, the uCDN computes a Signed URI
that is based on unique parameters of that request and provides that is based on unique parameters of that request and provides
to the end user as the URI to use to further request the content it to the end user as the URI to use to further request the
from the dCDN. content from the dCDN.
10. On receipt of the corresponding content request, the dCDN 10. On receipt of the corresponding content request, the dCDN
validates the signed JWT in the Signed URI using the information validates the signed JWT in the Signed URI using the information
provided by the uCDN in the CDNI Metadata. provided by the uCDN in the CDNI Metadata.
11. If the validation is negative, the dCDN rejects the request and 11. If the validation is negative, the dCDN rejects the request and
sends an error code (e.g., 403 Forbidden) in the HTTP response. sends an error code (e.g., 403 Forbidden) in the HTTP response.
12. If the validation is positive, the dCDN serves the request and 12. If the validation is positive, the dCDN serves the request and
delivers the content. delivers the content.
13. At a later time, dCDN reports logging events that includes URI 13. At a later time, the dCDN reports logging events that include
signing information. 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 and asymmetric keys chain of trust model of CDNI both with symmetric and asymmetric keys
because the key information only needs to be specific to a pair of because the key information only needs to be specific to a pair of
adjacent CDNI hops. adjacent CDNI hops.
4.2. DNS Redirection 4.2. DNS Redirection
For DNS-based request routing, the CSP and uCDN must agree on a trust For DNS-based request routing, the CSP and uCDN must agree on a trust
model appropriate to the security requirements of the CSP's model appropriate to the security requirements of the CSP's
skipping to change at page 21, line 5 skipping to change at page 23, line 5
13. If the validation is positive, the dCDN serves the request and 13. If the validation is positive, the dCDN serves the request and
delivers the content. delivers the content.
14. At a later time, dCDN reports logging events that includes URI 14. At a later time, dCDN reports logging events that includes URI
signing information. 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 needs to be distributed across the only key information that needs to be distributed across
multiple, possibly non-adjacent, CDNI hops is the public key, which multiple, possibly untrusted, CDNI hops is the public key, which is
is generally not confidential. generally not confidential.
With DNS-based request routing, URI Signing does not match well the With DNS-based request routing, URI Signing does not match well the
general chain of trust model of CDNI when used with symmetric keys general chain of trust model of CDNI when used with symmetric keys
because the symmetric key information needs to be distributed across because the symmetric key information needs to be distributed across
multiple CDNI hops, including non-adjacent hops. This raises a multiple CDNI hops, to CDNs with which the CSP may not have a trust
security concern for applicability of URI Signing with symmetric keys relationship. This raises a security concern for applicability of
in case of DNS-based inter-CDN request routing. URI Signing with symmetric keys in case of DNS-based inter-CDN
request routing.
5. HTTP Adaptive Streaming 5. HTTP Adaptive Streaming
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]. In Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. In
addition, [I-D.brandenburg-cdni-uri-signing-for-has] provides an addition, [I-D.brandenburg-cdni-uri-signing-for-has] provides an
extension to the algorithm defined in this document that deals extension to the algorithm defined in this document that deals
skipping to change at page 22, line 26 skipping to change at page 24, line 26
| | | include URI Signing logging | | | | include URI Signing logging |
| | | fields | | | | fields |
+----------------------+-----------+--------------------------------+ +----------------------+-----------+--------------------------------+
[RFC Editor: Please replace RFCthis with the published RFC number for [RFC Editor: Please replace RFCthis with the published RFC number for
this document.] this document.]
6.2.1. CDNI Logging Record Version 2 for HTTP 6.2.1. CDNI Logging Record Version 2 for HTTP
The "cdni_http_request_v2" record-type supports all of the fields The "cdni_http_request_v2" record-type supports all of the fields
supported by the "cdni_http_request_v1" record-type supported by the "cdni_http_request_v1" record-type [RFC7937] plus
[I-D.ietf-cdni-logging] plus the two additional fields "s-uri- the two additional fields "s-uri-signing" and "s-uri-signing-deny-
signing" and "s-uri-signing-deny-reason", registered by this document reason", registered by this document in Section 6.3. The name,
in Section 6.3. The name, format, field value, and occurence format, field value, and occurence information for the two new fields
information for the two new fields can be found in Section 3.5 of can be found in Section 3.5 of this document.
this document.
6.3. CDNI Logging Field Names 6.3. CDNI Logging Field Names
This document requests the registration of the following CDNI Logging This document requests the registration of the following CDNI Logging
fields under the IANA "CDNI Logging Field Names" registry: fields under the IANA "CDNI Logging Field Names" registry:
+---------------------------+-----------+ +---------------------------+-----------+
| Field Name | Reference | | Field Name | Reference |
+---------------------------+-----------+ +---------------------------+-----------+
| s-uri-signing | RFCthis | | s-uri-signing | RFCthis |
| s-uri-signing-deny-reason | RFCthis | | s-uri-signing-deny-reason | RFCthis |
+---------------------------+-----------+ +---------------------------+-----------+
[RFC Editor: Please replace RFCthis with the published RFC number for [RFC Editor: Please replace RFCthis with the published RFC number for
this document.] this document.]
6.4. JSON Web Token Claims Registration
This specification registers the following Claims in the IANA "JSON
Web Token Claims" registry [IANA.JWT.Claims] established by
[RFC7519].
6.4.1. Registry Contents
o Claim Name: "cdniv"
o Claim Description: CDNI Claim Set Version
o Change Controller: IESG
o Specification Document(s): Section 2.1.8 of [[ this specification
]]
7. Security Considerations 7. 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 CDNI. The used to provide access authorization in the case of CDNI. The
primary goal of URI Signing is to make sure that only authorized UAs primary goal of URI Signing is to make sure that only authorized UAs
are able to access the content, with a CSP being able to authorize are able to access the content, with a CSP being able to authorize
every individual request. It should be noted that URI Signing is not every individual request. It should be noted that URI Signing is not
a content protection scheme; if a CSP wants to protect the content a content protection scheme; if a CSP wants to protect the content
itself, other mechanisms, such as DRM, are more appropriate. itself, other mechanisms, such as DRM, are more appropriate.
skipping to change at page 23, line 49 skipping to change at page 26, line 14
based on Client IP Address and illegitimate users being able to based on Client IP Address and illegitimate users being able to
access the content. One way to reduce exposure to this kind of access the content. One way to reduce exposure to this kind of
attack is to not only check for Client IP but also for other attack is to not only check for Client IP but also for other
attributes, e.g., attributes that can be found in HTTP headers. attributes, e.g., attributes that can be found in HTTP headers.
The shared key between CSP and uCDN may be distributed to dCDNs - The shared key between CSP and uCDN may be distributed to dCDNs -
including cascaded CDNs. Since this key can be used to legitimately including cascaded CDNs. Since this key can be used to legitimately
sign a URL for content access authorization, it is important to know sign a URL for content access authorization, it is important to know
the implications of a compromised shared key. the implications of a compromised shared key.
In the case where asymmetric keys are used, the KID information
element might contain the URL to the public key. To prevent
malicious clients from signing their own URIs and inserting the
associated public key URL in the KID field, thereby passing URI
validation, it is important that CDNs check whether the URI conveyed
in the KID field is in the allowable set of KIDs as listed in the
CDNI metadata or set via configuration.
8. Privacy 8. 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 (aud) is [RFC7937] apply when the client's IP address (aud) is embedded in the
embedded in the Signed URI. For this reason, the mechanism described Signed URI. For this reason, the mechanism described in Section 2
in Section 2 encrypts the Client IP before including it in the URI encrypts the Client IP before including it in the URI Signing Package
Signing Package (and thus the URL itself). (and thus the URL itself).
9. Acknowledgements 9. 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 Gancho Tenev. In addition, Matt Caulfield Oprescu, Leif Hedstrom, Gancho Tenev, and Brian Campbell. In
provided content for the CDNI Metadata Interface section. addition, Matt Caulfield provided content for the CDNI Metadata
Interface section.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-27 (work in progress), June 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>.
[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>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<http://www.rfc-editor.org/info/rfc6920>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015, RFC 7516, DOI 10.17487/RFC7516, May 2015,
<http://www.rfc-editor.org/info/rfc7516>. <http://www.rfc-editor.org/info/rfc7516>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>. <http://www.rfc-editor.org/info/rfc7519>.
[RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed.,
and R. Peterkofsky, "Content Distribution Network
Interconnection (CDNI) Logging Interface", RFC 7937,
DOI 10.17487/RFC7937, August 2016,
<http://www.rfc-editor.org/info/rfc7937>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"Content Delivery Network Interconnection (CDNI)
Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
<http://www.rfc-editor.org/info/rfc8006>.
10.2. Informative References 10.2. Informative References
[I-D.brandenburg-cdni-uri-signing-for-has] [I-D.brandenburg-cdni-uri-signing-for-has]
Brandenburg, R., "URI Signing for HTTP Adaptive Streaming Brandenburg, R., "URI Signing for HTTP Adaptive Streaming
(HAS)", draft-brandenburg-cdni-uri-signing-for-has-03 (HAS)", draft-brandenburg-cdni-uri-signing-for-has-03
(work in progress), June 2016. (work in progress), June 2016.
[I-D.ietf-cdni-footprint-capabilities-semantics] [IANA.JWT.Claims]
Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., IANA, "JSON Web Token Claims",
and K. Ma, "CDNI Request Routing: Footprint and <http://www.iana.org/assignments/jwt>.
Capabilities Semantics", draft-ietf-cdni-footprint-
capabilities-semantics-20 (work in progress), May 2016.
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni-
metadata-21 (work in progress), August 2016.
[I-D.ietf-cdni-redirection]
Niven-Jenkins, B. and R. Brandenburg, "Request Routing
Redirection interface for CDN Interconnection", draft-
ietf-cdni-redirection-20 (work in progress), August 2016.
[PCRE839] Hazel, P., "Perl Compatible Regular Expressions", [PCRE839] Hazel, P., "Perl Compatible Regular Expressions",
Version 8.39, June 2016, <http://www.pcre.org/>. Version 8.39, June 2016, <http://www.pcre.org/>.
[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>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>. <http://www.rfc-editor.org/info/rfc5952>.
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection (CDNI)", Content Distribution Network Interconnection (CDNI)",
RFC 6983, DOI 10.17487/RFC6983, July 2013, RFC 6983, DOI 10.17487/RFC6983, July 2013,
<http://www.rfc-editor.org/info/rfc6983>. <http://www.rfc-editor.org/info/rfc6983>.
skipping to change at page 26, line 15 skipping to change at page 28, line 26
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network "Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <http://www.rfc-editor.org/info/rfc7336>. August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Network Interconnection (CDNI) Requirements", RFC 7337, Network Interconnection (CDNI) Requirements", RFC 7337,
DOI 10.17487/RFC7337, August 2014, DOI 10.17487/RFC7337, August 2014,
<http://www.rfc-editor.org/info/rfc7337>. <http://www.rfc-editor.org/info/rfc7337>.
[RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed.,
"Request Routing Redirection Interface for Content
Delivery Network (CDN) Interconnection", RFC 7975,
DOI 10.17487/RFC7975, October 2016,
<http://www.rfc-editor.org/info/rfc7975>.
[RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
R., and K. Ma, "Content Delivery Network Interconnection
(CDNI) Request Routing: Footprint and Capabilities
Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
<http://www.rfc-editor.org/info/rfc8008>.
Appendix A. Signed URI Package Example Appendix A. Signed URI Package Example
This section contains two examples of token usage: a simple example This section contains two examples of token usage: a simple example
with only the required claims present, and a complex example which with only the required claims present, and a complex example which
demonstrates the full JWT claims set, including an encrypted Client demonstrates the full JWT claims set, including an encrypted Client
IP (aud). IP (aud).
Note: All of the examples have whitespace added to improve formatting Note: All of the examples have whitespace added to improve formatting
and readability, but are not present in the generated content. and readability, but are not present in the generated content.
skipping to change at page 26, line 46 skipping to change at page 29, line 23
} }
A.1. Simple Example A.1. Simple Example
This example is the simplest possible example containing the only This example is the simplest possible example containing the only
required field (sub). required field (sub).
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"cdniv": 1,
"sub": "uri:http://cdni.example/foo/bar/baz" "sub": "uri:http://cdni.example/foo/bar/baz"
} }
The Signed JWT: The Signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJzdWIiOiJ1cmk6aHR0cDovL2NkbmkuZXhhbXBsZ dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pdiI6MSwic3ViIjoidXJpOmh0dHA6Ly9jZ
S9mb28vYmFyL2JheiJ9.oC4yKwUchowx4KhMsI8MQ-Sq_1s3fC8NCi-IWcmNEE9MQz G5pLmV4YW1wbGUvZm9vL2Jhci9iYXoifQ.RMPznuLnO3B9jTYJRQE_HFXD4CTBfTLZ
EEQfurJ1su2Op_dtYuc_fG8NixSVubz3HWKM4Rsw M03BkHK7wTMSSOOhJL6dORy1Avx3BJW2NNa-SsytYzM7tGCcsAJUFA
A.2. Complex Example A.2. Complex Example
This example uses all optional fields, including Client IP (aud) This example uses all optional fields, including Client IP (aud)
which is encrpyted. This significantly increases the size of the which is encrpyted. This significantly increases the size of the
signed JWT token. signed JWT token.
Shared key used for encrpyting the Client IP (aud): Shared key used for encrpyting the Client IP (aud):
{ {
"kty": "oct", "kty": "oct",
"kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998",
"use": "enc", "use": "enc",
"alg": "A128GCM", "alg": "A128GCM",
"k": "4uFxxV7fhNmrtiah2d1fFg" "k": "4uFxxV7fhNmrtiah2d1fFg"
} }
JWE for client IP (aud) of [2001:db8::1/32]: JWE for client IP (aud) of [2001:db8::1/32]:
eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj
g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..Ewl05cq3jmUe1Bv1.CHif9 g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..iirjVvKXFc_NzZkm.SJcZ7
OMPmsMPgJ8tZgvD0A.R3I2C8nfppY2wBfc4xEPPQ g5hXas-eDNsCOIQLQ._Hwi9VSHsWQGuataOdQJYQ
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm "aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm
dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..Ewl05cq3jmUe dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..iirjVvKXFc_N
1Bv1.CHif9OMPmsMPgJ8tZgvD0A.R3I2C8nfppY2wBfc4xEPPQ", zZkm.SJcZ7g5hXas-eDNsCOIQLQ._Hwi9VSHsWQGuataOdQJYQ",
"cdniv": 1,
"exp": 1474243500, "exp": 1474243500,
"iat": 1474243200, "iat": 1474243200,
"iss": "Upstream CDN Inc", "iss": "uCDN Inc",
"jti": "5DAafLhZAfhsbe", "jti": "5DAafLhZAfhsbe",
"nbf": 1474243200, "nbf": 1474243200,
"sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.png" "sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.png"
} }
The Signed JWT: The Signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJleUpoYkdjaU9pSmthWElpTENKcmFXU dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJleUpoYkdjaU9pSmthWElpTENKcmFXU
WlPaUptTFZkaWFuaENRek5rVUhWSk0yUXlOR3RRTW1obWRtOXpOMUY2TmpnNFZWUnB WlPaUptTFZkaWFuaENRek5rVUhWSk0yUXlOR3RRTW1obWRtOXpOMUY2TmpnNFZWUnB
ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLkV3bDA1Y3Ezam1VZ ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLmlpcmpWdktYRmNfT
TFCdjEuQ0hpZjlPTVBtc01QZ0o4dFpndkQwQS5SM0kyQzhuZnBwWTJ3QmZjNHhFUFB npaa20uU0pjWjdnNWhYYXMtZUROc0NPSVFMUS5fSHdpOVZTSHNXUUd1YXRhT2RRSll
RIiwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6IlVwc3RyZ RIiwiY2RuaXYiOjEsImV4cCI6MTQ3NDI0MzUwMCwiaWF0IjoxNDc0MjQzMjAwLCJpc
WFtIENETiBJbmMiLCJqdGkiOiI1REFhZkxoWkFmaHNiZSIsIm5iZiI6MTQ3NDI0MzI 3MiOiJ1Q0ROIEluYyIsImp0aSI6IjVEQWFmTGhaQWZoc2JlIiwibmJmIjoxNDc0MjQ
wMCwic3ViIjoidXJpLXJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL zMjAwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGxlL2Zvby9iY
2Jhei9bMC05XXszfVxcLnBuZyJ9.AtDNW7mwFIJPqsWAn9ojzj4imE-vTowR-FRzil XIvYmF6L1swLTldezN9XFwucG5nIn0.k_lX_z_E4-rdzjJ6DuSnoVtvifaz-W4xN0I
vnSQuQMz_u4sIspxe6RoXo_Ti8rVMgJ0jOdSvVnQUJZdfRUQ PdU6IoDZvBeu_lv39xsgfnvTO_wcflaO9MkbWyzarw3MtnITxQA
Authors' Addresses Authors' Addresses
Ray van Brandenburg Ray van Brandenburg
TNO Tiledmedia
Anna van Buerenplein 1 Anna van Buerenplein 1
Den Haag 2595DC Den Haag 2595DA
the Netherlands The Netherlands
Phone: +31 88 866 7000 Phone: +31 88 866 7000
Email: ray.vanbrandenburg@tno.nl Email: ray@tiledmedia.com
Kent Leung Kent Leung
Cisco Systems, Inc. Cisco Systems, Inc.
3625 Cisco Way 3625 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
United States United States
Phone: +1 408 526 5030 Phone: +1 408 526 5030
Email: kleung@cisco.com Email: kleung@cisco.com
Phil Sorber Phil Sorber
skipping to change at page 29, line 4 skipping to change at page 31, line 21
Email: kleung@cisco.com Email: kleung@cisco.com
Phil Sorber Phil Sorber
Comcast Cable Communications Comcast Cable Communications
1401 Wynkoop Street, Suite 300 1401 Wynkoop Street, Suite 300
Denver, CO 80202 Denver, CO 80202
United States United States
Phone: +1 720 502 3785 Phone: +1 720 502 3785
Email: phillip_sorber@comcast.com Email: phillip_sorber@comcast.com
Matthew Miller Matthew Miller
Cisco Systems, Inc. Mozilla
1899 Wynkoop Street, Suite 600
Denver, CO 80202
United States
Email: mamille2@cisco.com Email: linuxwolf@outer-planes.net
 End of changes. 70 change blocks. 
267 lines changed or deleted 349 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/