draft-ietf-cdni-uri-signing-11.txt   draft-ietf-cdni-uri-signing-12.txt 
CDNI R. van Brandenburg CDNI R. van Brandenburg
Internet-Draft Tiledmedia Internet-Draft Tiledmedia
Intended status: Standards Track K. Leung Intended status: Standards Track K. Leung
Expires: November 19, 2017 Cisco Systems, Inc. Expires: December 26, 2017 Cisco Systems, Inc.
P. Sorber P. Sorber
Comcast Cable Communications Comcast Cable Communications
M. Miller June 24, 2017
Mozilla
May 18, 2017
URI Signing for CDN Interconnection (CDNI) URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-11 draft-ietf-cdni-uri-signing-12
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 40
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 November 19, 2017. This Internet-Draft will expire on December 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 . . . . . . . . . 5
1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 5 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6
1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8
2. JWT Format and Processing Requirements . . . . . . . . . . . 8 2. JWT Format and Processing Requirements . . . . . . . . . . . 8
2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 9 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 9
2.1.2. URI Container (sub) claim . . . . . . . . . . . . . . 10 2.1.2. URI Container (sub) claim . . . . . . . . . . . . . . 10
2.1.3. Client IP (aud) claim . . . . . . . . . . . . . . . . 10 2.1.3. Client IP (aud) claim . . . . . . . . . . . . . . . . 10
2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 10 2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 10
2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11 2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11
2.1.6. Issued At (ait) claim . . . . . . . . . . . . . . . . 11 2.1.6. Issued At (ait) claim . . . . . . . . . . . . . . . . 11
2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 11 2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 11
2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12 2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12
2.1.9. URI Container Forms . . . . . . . . . . . . . . . . . 12 2.1.9. CDNI Expiration Time Setting (cdniets) claim . . . . 12
2.1.9.1. URI Simple Container (uri:) . . . . . . . . . . . 12 2.1.10. CDNI Signed Token Transport (cdnistt) claim . . . . . 12
2.1.9.2. URI Pattern Container (uri-pattern:) . . . . . . 12 2.1.11. URI Container Forms . . . . . . . . . . . . . . . . . 12
2.1.9.3. URI Regular Expression Container (uri-regex:) . . 13 2.1.11.1. URI Simple Container (uri:) . . . . . . . . . . 13
2.1.9.4. URI Hash Container (uri-hash:) . . . . . . . . . 13 2.1.11.2. URI Pattern Container (uri-pattern:) . . . . . . 13
2.1.11.3. URI Regular Expression Container (uri-regex:) . 14
2.1.11.4. URI Hash Container (uri-hash:) . . . . . . . . . 14
2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 14 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 14
3. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 14 3. URI Signing for HAS . . . . . . . . . . . . . . . . . . . . . 14
3.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 14 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. CDNI Footprint & Capabilities Advertisement Interface . . 14 3.2. Signed Token Chain mechanism . . . . . . . . . . . . . . 15
3.3. CDNI Request Routing Redirection Interface . . . . . . . 14 3.3. Communicating a signed JWTs in a Signed Token Chain . . . 16
3.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 14 3.3.1. Support for cross-domain redirection . . . . . . . . 16
3.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 16 4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 16
4. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 17 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 17
4.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 17 4.2. CDNI Footprint & Capabilities Advertisement Interface . . 17
4.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 20 4.3. CDNI Request Routing Redirection Interface . . . . . . . 17
5. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 23 4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 19
6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 23 5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 20
6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 23 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 20
6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 24 5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 23
6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 25
6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 24 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 26
6.4. JSON Web Token Claims Registration . . . . . . . . . . . 24 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 26
6.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 25 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 26
8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.4. JSON Web Token Claims Registration . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 6.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 26 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Signed URI Package Example . . . . . . . . . . . . . 28 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Signed URI Package Example . . . . . . . . . . . . . 31
A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 32
A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 32
A.3. Signed Token Chain Example . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of redirection used to provide access authorization in the case of redirection
between interconnected CDNs (CDNI) and between a Content Service between interconnected CDNs (CDNI) and between a Content Service
Provider (CSP) and a CDN. The primary goal of URI Signing is to make Provider (CSP) and a CDN. The primary goal of URI Signing is to make
sure that only authorized User Agents (UAs) are able to access the sure that only authorized User Agents (UAs) are able to access the
content, with a CSP being able to authorize every individual request. content, with a CSP being able to authorize every individual request.
It should be noted that URI Signing is not a content protection It should be noted that URI Signing is not a content protection
skipping to change at page 3, line 42 skipping to change at page 3, line 46
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 interface shall allow signaling of MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of
authorization checks and validation that are to be performed by the authorization checks and validation that are to be performed by
Surrogate before delivery. For example, this could potentially the Surrogate before delivery. For example, this could
include the need to validate information (e.g., Expiry time, Client potentially include the need to validate information (e.g., Expiry
IP address) required for access authorization. time, Client IP address) required for access authorization.
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 44 skipping to change at page 4, line 48
o Target CDN URI: URI created by the CSP to direct a 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 possibly further Downstream CDNs and verified by the uCDN and possibly further Downstream CDNs
(dCDNs). (dCDNs).
o Redirection URI: URI created by the uCDN to redirect a UA towards o Redirection URI: URI created by the uCDN to redirect a UA towards
the dCDN. The Redirection URI can be signed by the uCDN and the dCDN. The Redirection URI can be signed by the uCDN and
verified by the dCDN. In a cascaded CDNI scenario, there can be verified by the dCDN. In a cascaded CDNI scenario, there can be
more than one Redirection URI. more than one Redirection URI.
o Signed Token Chain: A chain of signed JWTs that are used for
subsequent access to a set of related resources in a CDN, such as
a set of HTTP Adaptive Streaming files. Every time a signed JWT
is used to access a particular resource, a new signed JWT is sent
along with the resource that can be used to request the next
resource in the set. When generating a new signed JWT in a Signed
Token Chain, parameters are carried over from one signed JWT to
the next.
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 6, line 10 skipping to change at page 6, line 39
the process of delivering the content. The main difference from the the process of delivering the content. The main difference from the
single CDN case is a redirection step between the uCDN and the dCDN. single CDN case is a redirection step between the uCDN and the dCDN.
In step #3, UA may send an HTTP request or a DNS request. Depending In step #3, UA may send an HTTP request or a DNS request. Depending
on whether HTTP-based or DNS-based request routing is used, the uCDN on whether HTTP-based or DNS-based request routing is used, the uCDN
responds by directing the UA towards the dCDN using either a responds by directing the UA towards the dCDN using either a
Redirection URI (which is a Signed URI generated by the uCDN) or a Redirection URI (which is a Signed URI generated by the uCDN) or a
DNS reply, respectively (#4). Once the UA receives the response, it DNS reply, respectively (#4). Once the UA receives the response, it
sends the Redirection URI/Target CDN URI to the dCDN (#5). The sends the Redirection URI/Target CDN URI to the dCDN (#5). The
received URI is validated by the dCDN before delivering the content received URI is validated by the dCDN before delivering the content
(#6). This is depicted in the figure below. Note: The CDNI call (#6). This is depicted in the figure below. Note: The CDNI call
flows are covered in Detailed URI Signing Operation (Section 4). flows are covered in Detailed URI Signing Operation (Section 5).
+-------------------------+ +-------------------------+
|Request Redirection Modes| |Request Redirection Modes|
+-------------------------+ +-------------------------+
| a) HTTP | | a) HTTP |
| b) DNS | | b) DNS |
+-------------------------+ +-------------------------+
-------- --------
/ \< * * * * * * * * * * * * * * / \< * * * * * * * * * * * * * *
| CSP |< * * * * * * * * * * * * | CSP |< * * * * * * * * * * * *
skipping to change at page 9, line 6 skipping to change at page 9, line 6
This document specifies the following attribute for embedding a This document specifies the following attribute for embedding a
signed JWT in a Target CDN URI or Redirection URI: 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 (Section 3.4). If the CDNI Metadata interface is the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is
not used, or does not include a parameter name for the URI Signing not used, or does not include a parameter name for the URI Signing
Package Attribute, the parameter name can be set by configuration Package Attribute, the parameter name can be set by configuration
(out of 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 (Section 3.4) If the requirements are defined in the CDNI Metadata (Section 4.4) If the
CDNI Metadata interface is not used, or does not include claim CDNI Metadata interface is not used, or does not include claim
requirements, the claim requirements can be set by configuration (out requirements, the claim requirements can be set by configuration (out
of scope of this 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
skipping to change at page 10, line 11 skipping to change at page 10, line 11
value MUST be updated to identify the redirecting CDN. If the value MUST be updated to identify the redirecting CDN. If the
received signed JWT does not contain an Issuer claim, an Issuer claim received signed JWT does not contain an Issuer claim, an Issuer claim
MAY be added to a signed JWT generated for CDNI redirection. MAY be added to a signed JWT generated for CDNI redirection.
2.1.2. URI Container (sub) claim 2.1.2. URI Container (sub) claim
URI Container (sub) [mandatory] - The semantics in [RFC7519] URI Container (sub) [mandatory] - The semantics in [RFC7519]
Section 4.1.2 MUST be followed. Container for holding the URI Section 4.1.2 MUST be followed. Container for holding the URI
representation before a URI Signing Package is added. This representation before a URI Signing Package is added. This
representation can take one of several forms detailed in representation can take one of several forms detailed in
Section 2.1.9. If the URI pattern/regex in the signed JWT does not Section 2.1.11. If the URI pattern/regex in the signed JWT does not
match the URI of the content request, the CDN validating the signed match the URI of the content request, the CDN validating the signed
JWT MUST reject the request. When comparing the URI the percent JWT MUST reject the request. When comparing the URI the percent
encoded form as defined in [RFC3986] Section 2.1 MUST be used. When encoded form as defined in [RFC3986] Section 2.1 MUST be used. When
redirecting a URI, the CDN generating the new signed JWT MAY change redirecting a URI, the CDN generating the new signed JWT MAY change
the URI Container to comport with the URI being used in the the URI Container to comport with the URI being used in the
redirection. redirection.
2.1.3. Client IP (aud) claim 2.1.3. Client IP (aud) claim
Client IP (aud) [optional] - The semantics in [RFC7519] Section 4.1.3 Client IP (aud) [optional] - The semantics in [RFC7519] Section 4.1.3
skipping to change at page 11, line 13 skipping to change at page 11, line 13
generated for CDNI redirection MUST also contain an Expiry Time generated for CDNI redirection MUST also contain an Expiry Time
claim, and the Expiry Time value MUST be the same as in the received 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 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 an Expiry Time claim if no Expiry Time claim existed in the received
signed JWT. signed JWT.
2.1.5. Not Before (nbf) claim 2.1.5. Not Before (nbf) claim
Not Before (nbf) [optional] - The semantics in [RFC7519] Not Before (nbf) [optional] - The semantics in [RFC7519]
Section 4.1.5 MUST be followed, though URI Signing implementations Section 4.1.5 MUST be followed, though URI Signing implementations
MUST not allow for any time synchronization "leeway". Note: The time MUST NOT allow for any time synchronization "leeway". Note: The time
on the entities that generate and validate the signed URI SHOULD be 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 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 servers need to be time-synchronized. It is RECOMMENDED to use NTP
[RFC5905] for time synchronization. If the CDN validating the signed [RFC5905] for time synchronization. If the CDN validating the signed
JWT does not support Not Before time validation, or if the Not Before 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 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 the content request, the CDN MUST reject the request. If the
received signed JWT contains a Not Before time claim, then any JWT received signed JWT contains a Not Before time claim, then any JWT
subsequently generated for CDNI redirection MUST also contain a Not subsequently generated for CDNI redirection MUST also contain a Not
Before time claim, and the Not Before time value MUST be the same as Before time claim, and the Not Before time value MUST be the same as
skipping to change at page 12, line 21 skipping to change at page 12, line 21
CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set
Version (cdniv) claim provides a means within a signed JWT to tie the Version (cdniv) claim provides a means within a signed JWT to tie the
claim set to a specific version of a specificiation. This is claim set to a specific version of a specificiation. This is
intended to allow changes in and facilitate upgrades across intended to allow changes in and facilitate upgrades across
specifications. The type is JSON integer and the value MUST be set specifications. The type is JSON integer and the value MUST be set
to "1", for this version of the specification. In the absence of 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 this claim, the value is assumed to be "1". For future versions this
claim will be mandatory. Implementations MUST reject signed JWTs claim will be mandatory. Implementations MUST reject signed JWTs
with unsupported CDNI Claim Set versions. with unsupported CDNI Claim Set versions.
2.1.9. URI Container Forms 2.1.9. CDNI Expiration Time Setting (cdniets) claim
CDNI Expiration Time Setting (cdniets) [optional] - The CDNI
Expiration Time Setting (cdniets) claim provides a means for setting
the value of the Expiry Time (exp) claim when generating a subsequent
signed JWT in a Signed Token Chain. Its type is a JSON integer
denotes the number of seconds to be added to the Expiry Time (exp)
claim of the previous signed JWT that gives the value of the Expiry
Time (exp) claim of the next signed JWT. The CDNI Expiration Time
Setting (cdniets) SHOULD NOT be used when not using a Signed Token
Chain.
2.1.10. CDNI Signed Token Transport (cdnistt) claim
CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed
Token Transport (cdnistt) claim provides a means of signalling the
method through which the Signed Token Chain is transported from the
CDN to the UA and vice versa. Its type is a JSON integer. This
document only defines setting its value to '1', which means the
signed JWTs making up the Signed Token Chain are transported via HTTP
Cookies in both directions.
2.1.11. 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.9.1. URI Simple Container (uri:) 2.1.11.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.9.2. URI Pattern Container (uri-pattern:) 2.1.11.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:
';' - separates individual patterns when the string contains o ';' - separates individual patterns when the string contains
multiple URI patterns. multiple URI patterns.
'*' - matches any sequence of characters, including the empty o '*' - matches any sequence of characters, including the empty
string. string.
'?' - matches exactly one character. o '?' - matches exactly one character.
'$' - used to escape the special literals; MUST be followed by o '$' - used to escape the special literals; MUST be followed by
exactly one of ';', '*', '?', or '$'. exactly one of ';', '*', '?', or '$'.
The following is an example of a valid URI Pattern: The following is an example of a valid URI Pattern:
*://*/folder/content-83112371/quality_*/segment????.mp4 *://*/folder/content-83112371/quality_*/segment????.mp4
An example of two concatenated URI Patterns is the following An example of two concatenated URI Patterns is the following
(whitespace is inserted after the ';' for readability and should not (whitespace is inserted after the ';' for readability and should not
be present in the actual representation): be present in the actual representation):
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.9.3. URI Regular Expression Container (uri-regex:) 2.1.11.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:) 2.1.11.4. URI Hash Container (uri-hash:)
Prefixed with 'uri-hash:', this string is a URL Segment form Prefixed with 'uri-hash:', this string is a URL Segment form
([RFC6920] Section 5) of the URI. ([RFC6920] Section 5) of the URI.
2.2. JWT Header 2.2. JWT Header
The header of the JWT MAY be passed via the CDNI Metadata interface The header of the JWT MAY be passed via the CDNI Metadata interface
instead of being included in the URISigningPackage. The header value instead of being included in the URISigningPackage. The header value
must be transmitted in the serialized encoded form and prepended to must be transmitted in the serialized encoded form and prepended to
the JWT payload and signature passed in the URISigningPackage prior the JWT payload and signature passed in the URISigningPackage prior
to validation. This reduces the size of the signed JWT token. to validation. This reduces the size of the signed JWT token.
3. Relationship with CDNI Interfaces 3. URI Signing for HAS
3.1. Overview
For content that is delivered via an HTTP Adaptive Streaming (HAS)
protocol, such as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS)
[I-D.pantos-http-live-streaming], special provisions need to be made
in order to ensure URI Signing can be applied. In general, HAS
protocols work by breaking large objects (e.g. videos) into a
sequence of small independent chunks. Such chunks are then
referenced by a separate manifest file, which either includes a list
of URLs to the chunks or specifies an algorithm through which a User
Agent can construct the URLs to the chunks. Requests for chunks
therefore originate from the manifest file and, unless the URLs in
the manifest file point to the CSP, are not subjected to redirection
and URI Signing. This opens up the vulnerability of malicious User
Agents sharing the manifest file and deep-linking to the chunks.
One method for dealing with this vulnerability would be to include in
the manifest itself Signed URIs that point to the individual chunks.
There exist a number of issues with that approach. First, it
requires the CDN delivering the manifest to rewrite the manifest file
for each User Agent, which would require the CDN to be aware of the
exact HAS protocol and version used. Secondly, it would require the
expiration time of the Signed URIs to be valid for at least the full
duration of the content described by the manifest. Since it is
common for a manifest file to contain a video item of more than 30
minutes in length, Signed URIs would require to be valid for a long
time, thereby reducing their effectiveness and that of the URI
Signing mechanism in general. For a more detailed analysis of how
HAS protocols affect CDNI, see Models for HTTP-Adaptive-Streaming-
Aware CDNI [RFC6983].
The method described in this section allows CDNs to use URI Signing
for HTTP Adaptive Streaming content (or other chunked content)
without having to include the Signed URIs in the manifest files
themselves.
3.2. Signed Token Chain mechanism
In order to allow for effective access control of HAS content, the
URI signing scheme defined in this section is based on a mechanism
through which subsequent HAS chunk requests can be chained together.
As part of the JWT validation procedure, the CDN can generate a new
signed JWT that the UA can use to do a subsequent request. More
specifically, whenever a UA successfully retrieves an HAS chunk, it
receives, in the HTTP 2xx Successful message, a signed JWT that it
can use whenever it requests the next chunk. As long as each signed
JWT in such a Signed Token Chain is correctly validated before a new
one is generated, the chain is not broken and the User Agent can
successfully retrieve additional chunks. Given the fact that with
HAS protocols, it is usually not possible to determine a priori which
chunk will be requested next (i.e., to allow for seeking within the
content and for switching to a different quality level), the Signed
Token Chain uses the URI Pattern Container and/or the URI Regular
Expression Container scoping mechanisms in the URI Container (sub)
claim to allow the Signed Token Chain to be valid for more than one
URL.
In order for this chaining of signed JWTs to work, it is necessary
for a UA to extract the signed JWT from the HTTP 2xx Successful
message of an earlier request and use it to retrieve the next chunk.
The exact mechanism by which the client does this depends on the
exact HAS protocol and since this document is only concerned with the
generation and validation of incoming request, this process is
outside the scope of this document. However, in order to also
support legacy UAs that do not include any specific provisions for
the handling of signed JWTs, the folowing section defines a mechanism
using HTTP Cookies that allows such UAs to support the concept of
chained signed JWTs without requiring any support on the UA side.
3.3. Communicating a signed JWTs in a Signed Token Chain
This section assumes the value of the CDNI Signed Token Transport
(cdnistt) claim has been set to 1. Other values of cdnistt are out
of scope of this document.
When using the Signed Token Chain mechanism, the signed JWT is
transported to the UA via a 'URISigningPackage' cookie added to the
HTTP 2xx Successful message along with the content being returned to
the UA, or to the HTTP 3xx Redirection message in case the UA is
redirected to a different server.
3.3.1. Support for cross-domain redirection
For security purposes, the use of cross-domain cookies is not
supported in some application environments. As a result, the Cookie-
based method for transport of the Signed Token described in the
previous section might break if used in combination with a HTTP 3xx
Redirection response where the target URL is in a different domain.
In such scenarios, a Signed Token Chain signed JWT SHOULD be
communicated via the query string instead, in a similar fashion to
how regular signed JWTs (outside a Signed Token Chain) are
communicated. Note that the use of URL embedded signed JWTs SHOULD
NOT be used in HTTP 2xx Successful messages, since UAs might not know
how to extract the signed JWTs.
Note that the process described below only works in cases where both
the manifest file and segments constituting the HTTP Adaptive
Streaming content are delivered from the same domain. In other
words, any redirection between different domains needs to be carried
out while retrieving the manifest file.
4. 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
after access authorization) need to be included in the logs after access authorization) need to be included in the logs
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 4.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 4.2. CDNI Footprint & Capabilities Advertisement Interface
The CDNI Request Routing: Footprint and Capabilities Semantics The CDNI Request Routing: Footprint and Capabilities Semantics
document [RFC8008] defines support for advertising CDNI Metadata document [RFC8008] defines support for advertising CDNI Metadata
capabilities, via CDNI Payload Type. The CDNI Payload Type capabilities, via CDNI Payload Type. The CDNI Payload Type
registered in Section 6.1 can be used for capability advertisement. registered in Section 6.1 can be used for capability advertisement.
3.3. CDNI Request Routing Redirection Interface 4.3. CDNI Request Routing Redirection Interface
The CDNI Request Routing Redirection Interface [RFC7975] describes The CDNI Request Routing Redirection Interface [RFC7975] describes
the recursive request redirection method. For URI Signing, the uCDN the recursive request redirection method. For URI Signing, the uCDN
signs the URI provided by the dCDN. URI Signing therefore has has no signs the URI provided by the dCDN. URI Signing therefore has has no
impact on this interface. impact on this interface.
3.4. CDNI Metadata Interface 4.4. CDNI Metadata Interface
The CDNI Metadata Interface [RFC8006] describes the CDNI metadata The CDNI Metadata Interface [RFC8006] describes the CDNI metadata
distribution needed to enable content acquisition and delivery. For distribution needed to enable content acquisition and 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
skipping to change at page 16, line 23 skipping to change at page 19, line 5
{ {
"generic-metadata-type": "MI.UriSigning" "generic-metadata-type": "MI.UriSigning"
"generic-metadata-value": "generic-metadata-value":
{ {
"enforce": true, "enforce": true,
"issuers": ["csp", "ucdn1", "ucdn2"], "issuers": ["csp", "ucdn1", "ucdn2"],
"package-attribute": "usp" "package-attribute": "usp"
} }
} }
3.5. CDNI Logging Interface 4.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 [RFC7937], using the new "cdni_http_request_v2" record-type Interface [RFC7937], using the new "cdni_http_request_v2" record-type
registered in Section 6.2.1. registered in Section 6.2.1.
skipping to change at page 17, line 36 skipping to change at page 20, line 15
o s-uri-signing-deny-reason (optional): o s-uri-signing-deny-reason (optional):
* format: QSTRING * format: QSTRING
* field value: a string for providing further information in case * field value: a string for providing further information in case
the signed JWT was rejected, e.g., for debugging purposes. the signed JWT was rejected, e.g., for debugging purposes.
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
field. field.
4. URI Signing Message Flow 5. 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.
JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of
representing claims to be transferred between two parties. The representing claims to be transferred between two parties. The
claims in a signed JWT are encoded as a JSON object that is used as claims in a signed JWT are encoded as a JSON object that is used as
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 5.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 or 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
skipping to change at page 20, line 28 skipping to change at page 23, line 5
delivers the content. delivers the content.
13. At a later time, the dCDN reports logging events that include 13. At a later time, the dCDN reports logging events that include
URI 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 5.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
particular content. Use of asymmetric public/private keys allows for particular content. Use of asymmetric public/private keys allows for
unlimited distribution of the public key to dCDNs. However, if a unlimited distribution of the public key to dCDNs. However, if a
shared secret key is preferred, then the CSP may want to restrict the shared secret key is preferred, then the CSP may want to restrict the
distribution of the key to a (possibly empty) subset of trusted distribution of the key to a (possibly empty) subset of trusted
dCDNs. Authorized Delivery CDNs need to obtain the key information dCDNs. Authorized Delivery CDNs need to obtain the key information
to validate the Signed URI. to validate the Signed URI.
skipping to change at page 23, line 16 skipping to change at page 25, line 40
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, to CDNs with which the CSP may not have a trust multiple CDNI hops, to CDNs with which the CSP may not have a trust
relationship. This raises a security concern for applicability of relationship. This raises a security concern for applicability of
URI Signing with symmetric keys in case of DNS-based inter-CDN URI Signing with symmetric keys in case of DNS-based inter-CDN
request routing. request routing.
5. HTTP Adaptive Streaming
The authors note that in order to perform URI signing for individual
content segments of HTTP Adaptive Bitrate content, specific URI
signing mechanisms are needed. Such mechanisms are currently out-of-
scope of this document. More details on this topic is covered in
Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. In
addition, [I-D.brandenburg-cdni-uri-signing-for-has] provides an
extension to the algorithm defined in this document that deals
specifically with URI signing of segmented content.
6. IANA Considerations 6. IANA Considerations
6.1. CDNI Payload Type 6.1. CDNI Payload Type
This document requests the registration of the following CDNI Payload This document requests the registration of the following CDNI Payload
Type under the IANA "CDNI Payload Type" registry: Type under the IANA "CDNI Payload Type" registry:
+---------------+---------------+ +---------------+---------------+
| Payload Type | Specification | | Payload Type | Specification |
+---------------+---------------+ +---------------+---------------+
skipping to change at page 23, line 50 skipping to change at page 26, line 15
[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.1.1. CDNI UriSigning Payload Type 6.1.1. CDNI UriSigning Payload Type
Purpose: The purpose of this payload type is to distinguish Purpose: The purpose of this payload type is to distinguish
UriSigning MI objects (and any associated capability advertisement). UriSigning MI objects (and any associated capability advertisement).
Interface: MI/FCI Interface: MI/FCI
Encoding: see Section 3.4 Encoding: see Section 4.4
6.2. CDNI Logging Record Type 6.2. CDNI Logging Record Type
This document requests the registration of the following CDNI Logging This document requests the registration of the following CDNI Logging
record-type under the IANA "CDNI Logging record-types" registry: record-type under the IANA "CDNI Logging record-types" registry:
+----------------------+-----------+--------------------------------+ +----------------------+-----------+--------------------------------+
| record-types | Reference | Description | | record-types | Reference | Description |
+----------------------+-----------+--------------------------------+ +----------------------+-----------+--------------------------------+
| cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | | cdni_http_request_v2 | RFCthis | Extension to CDNI Logging |
skipping to change at page 24, line 30 skipping to change at page 26, line 42
[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 [RFC7937] plus supported by the "cdni_http_request_v1" record-type [RFC7937] plus
the two additional fields "s-uri-signing" and "s-uri-signing-deny- the two additional fields "s-uri-signing" and "s-uri-signing-deny-
reason", registered by this document in Section 6.3. The name, reason", registered by this document in Section 6.3. The name,
format, field value, and occurence information for the two new fields format, field value, and occurence information for the two new fields
can be found in Section 3.5 of this document. can be found in Section 4.5 of 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 |
skipping to change at page 25, line 13 skipping to change at page 27, line 29
[RFC7519]. [RFC7519].
6.4.1. Registry Contents 6.4.1. Registry Contents
o Claim Name: "cdniv" o Claim Name: "cdniv"
o Claim Description: CDNI Claim Set Version o Claim Description: CDNI Claim Set Version
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.1.8 of [[ this specification o Specification Document(s): Section 2.1.8 of [[ this specification
]] ]]
o Claim Name: "cdniets"
o Claim Description: CDNI Expiration Time Setting for Signed Token
Chain
o Change Controller: IESG
o Specification Document(s): Section 2.1.9 of [[ this specification
]]
o Claim Name: "cdnistt"
o Claim Description: CDNI Signed Token Transport Method for Signed
Token Chain
o Change Controller: IESG
o Specification Document(s): Section 2.1.10 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 25, line 35 skipping to change at page 28, line 17
signed JWT. The current version of this document includes claims for signed JWT. The current version of this document includes claims for
enforcing Issuer, Client IP Address, Not Before time, and Expiration enforcing Issuer, Client IP Address, Not Before time, and Expiration
Time, however this list can be extended with other, more complex, Time, however this list can be extended with other, more complex,
attributes that are able to provide some form of protection against attributes that are able to provide some form of protection against
some of the vulnerabilities highlighted below. some of the vulnerabilities highlighted below.
That said, there are a number of aspects that limit the level of That said, there are a number of aspects that limit the level of
security offered by URI Signing and that anybody implementing URI security offered by URI Signing and that anybody implementing URI
Signing should be aware of. Signing should be aware of.
Replay attacks: A (valid) Signed URI may be used to perform replay o Replay attacks: A (valid) Signed URI may be used to perform replay
attacks. The vulnerability to replay attacks can be reduced by attacks. The vulnerability to replay attacks can be reduced by
picking a relatively short window between the Not Before time and picking a relatively short window between the Not Before time and
Expiration Time attributes, although this is limited by the fact Expiration Time attributes, although this is limited by the fact
that any HTTP-based request needs a window of at least a couple of that any HTTP-based request needs a window of at least a couple of
seconds to prevent a sudden network issues from preventing seconds to prevent a sudden network issues from preventing
legitimate UAs access to the content. One may also reduce legitimate UAs access to the content. One may also reduce
exposure to replay attacks by including a unique one-time access exposure to replay attacks by including a unique one-time access
ID via the Nonce attribute (jti claim). Whenever the dCDN ID via the Nonce attribute (jti claim). Whenever the dCDN
receives a request with a given unique ID, it adds that ID to the receives a request with a given unique ID, it adds that ID to the
list of 'used' IDs. In the case an illegitimate UA tries to use list of 'used' IDs. In the case an illegitimate UA tries to use
the same URI through a replay attack, the dCDN can deny the the same URI through a replay attack, the dCDN can deny the
request based on the already-used access ID. request based on the already-used access ID.
Illegitimate clients behind a NAT: In cases where there are o Illegitimate clients behind a NAT: In cases where there are
multiple users behind the same NAT, all users will have the same multiple users behind the same NAT, all users will have the same
IP address from the point of view of the dCDN. This results in IP address from the point of view of the dCDN. This results in
the dCDN not being able to distinguish between the different users the dCDN not being able to distinguish between the different users
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
skipping to change at page 26, line 28 skipping to change at page 29, line 11
Signed URI. For this reason, the mechanism described in Section 2 Signed URI. For this reason, the mechanism described in Section 2
encrypts the Client IP before including it in the URI Signing Package encrypts the Client IP before including it in the URI 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, Gancho Tenev, and Brian Campbell. In Oprescu, Leif Hedstrom, Gancho Tenev, and Brian Campbell.
addition, Matt Caulfield provided content for the CDNI Metadata
Interface section.
10. References 10. Contributors
10.1. Normative References In addition, the authors would also like to make special mentions for
certain people who contributed significant sections to this document.
o Matt Caulfield provided content for the CDNI Metadata Interface
section.
o Emmanuel Thomas provided content for HTTP Adaptive Streaming.
o Matt Miller provided consultation on JWT usage as well as code to
generate working JWT examples.
11. References
11.1. Normative References
[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
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<http://www.rfc-editor.org/info/rfc6920>. <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)",
skipping to change at page 27, line 28 skipping to change at page 30, line 16
and R. Peterkofsky, "Content Distribution Network and R. Peterkofsky, "Content Distribution Network
Interconnection (CDNI) Logging Interface", RFC 7937, Interconnection (CDNI) Logging Interface", RFC 7937,
DOI 10.17487/RFC7937, August 2016, DOI 10.17487/RFC7937, August 2016,
<http://www.rfc-editor.org/info/rfc7937>. <http://www.rfc-editor.org/info/rfc7937>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"Content Delivery Network Interconnection (CDNI) "Content Delivery Network Interconnection (CDNI)
Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
<http://www.rfc-editor.org/info/rfc8006>. <http://www.rfc-editor.org/info/rfc8006>.
10.2. Informative References 11.2. Informative References
[I-D.brandenburg-cdni-uri-signing-for-has] [I-D.pantos-http-live-streaming]
Brandenburg, R., "URI Signing for HTTP Adaptive Streaming Pantos, R. and W. May, "HTTP Live Streaming", draft-
(HAS)", draft-brandenburg-cdni-uri-signing-for-has-03 pantos-http-live-streaming-23 (work in progress), May
(work in progress), June 2016. 2017.
[IANA.JWT.Claims] [IANA.JWT.Claims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token Claims",
<http://www.iana.org/assignments/jwt>. <http://www.iana.org/assignments/jwt>.
[MPEG-DASH]
ISO, "Information technology -- Dynamic adaptive streaming
over HTTP (DASH) -- Part 1: Media presentation description
and segment format", ISO/IEC 23009-1:2014, Edition 2, 05
2014, <http://www.iso.org/standard/65274.html>.
[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, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <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>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>.
[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>.
[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>.
skipping to change at page 28, line 40 skipping to change at page 31, line 40
<http://www.rfc-editor.org/info/rfc7975>. <http://www.rfc-editor.org/info/rfc7975>.
[RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
R., and K. Ma, "Content Delivery Network Interconnection R., and K. Ma, "Content Delivery Network Interconnection
(CDNI) Request Routing: Footprint and Capabilities (CDNI) Request Routing: Footprint and Capabilities
Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
<http://www.rfc-editor.org/info/rfc8008>. <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 three examples of token usage: a simple example
with only the required claims present, and a complex example which with only the required claim present, 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), and one that uses a Signed Token Chain.
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.
Both examples use the following signing key to generate the Signed All examples use the following signing key to generate the Signed URI
URI Package: Package:
{ {
"kty": "EC", "kty": "EC",
"kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0",
"use": "sig", "use": "sig",
"crv": "P-256", "crv": "P-256",
"x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8",
"y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA",
"d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M"
} }
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.eyJjZG5pdiI6MSwic3ViIjoidXJpOmh0dHA6Ly9jZ dZRkRPV2tsZHVlYUltZjAifQ.eyJzdWIiOiJ1cmk6aHR0cDovL2NkbmkuZXhhbXBsZ
G5pLmV4YW1wbGUvZm9vL2Jhci9iYXoifQ.RMPznuLnO3B9jTYJRQE_HFXD4CTBfTLZ S9mb28vYmFyL2JheiJ9.LTizGd7zCb17Qp_80ClGApLCieRIq3dCjcRckNfLqiJ4BT
M03BkHK7wTMSSOOhJL6dORy1Avx3BJW2NNa-SsytYzM7tGCcsAJUFA GSfVXoDtm0Z6L5Jx4EmwM1w-WkznNajUy11iMAcA
A.2. Complex Example A.2. Complex Example
This example uses all optional fields, including Client IP (aud) This example uses all optional fields except for those dealing with
which is encrpyted. This significantly increases the size of the Signed Token Chaining, including Client IP (aud) which is encrpyted.
signed JWT token. This significantly increases the size of the 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..iirjVvKXFc_NzZkm.SJcZ7 g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..oGLsnF8fLlFcUXK0.KFfBB
g5hXas-eDNsCOIQLQ._Hwi9VSHsWQGuataOdQJYQ H_FPYFu-RBFBR3rhQ.6_MVaa4t7JiVX2IgUkZ3jA
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm "aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm
dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..iirjVvKXFc_N dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..oGLsnF8fLlFc
zZkm.SJcZ7g5hXas-eDNsCOIQLQ._Hwi9VSHsWQGuataOdQJYQ", UXK0.KFfBBH_FPYFu-RBFBR3rhQ.6_MVaa4t7JiVX2IgUkZ3jA",
"cdniv": 1, "cdniv": 1,
"exp": 1474243500, "exp": 1474243500,
"iat": 1474243200, "iat": 1474243200,
"iss": "uCDN 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
ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLmlpcmpWdktYRmNfT ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLm9HTHNuRjhmTGxGY
npaa20uU0pjWjdnNWhYYXMtZUROc0NPSVFMUS5fSHdpOVZTSHNXUUd1YXRhT2RRSll 1VYSzAuS0ZmQkJIX0ZQWUZ1LVJCRkJSM3JoUS42X01WYWE0dDdKaVZYMklnVWtaM2p
RIiwiY2RuaXYiOjEsImV4cCI6MTQ3NDI0MzUwMCwiaWF0IjoxNDc0MjQzMjAwLCJpc BIiwiY2RuaXYiOjEsImV4cCI6MTQ3NDI0MzUwMCwiaWF0IjoxNDc0MjQzMjAwLCJpc
3MiOiJ1Q0ROIEluYyIsImp0aSI6IjVEQWFmTGhaQWZoc2JlIiwibmJmIjoxNDc0MjQ 3MiOiJ1Q0ROIEluYyIsImp0aSI6IjVEQWFmTGhaQWZoc2JlIiwibmJmIjoxNDc0MjQ
zMjAwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGxlL2Zvby9iY zMjAwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGxlL2Zvby9iY
XIvYmF6L1swLTldezN9XFwucG5nIn0.k_lX_z_E4-rdzjJ6DuSnoVtvifaz-W4xN0I XIvYmF6L1swLTldezN9XFwucG5nIn0.r2FiSdfnGRw_RC2roGwh4LEYlfsWGF972-M
PdU6IoDZvBeu_lv39xsgfnvTO_wcflaO9MkbWyzarw3MtnITxQA f3He_LhGr2_3eRXP0jP_OFPj5NEtTZFY4PX_iD7vPD12_HPDJCQ
A.3. Signed Token Chain Example
This example uses fields for Signed Token Chaining.
The JWT Claim Set before signing:
{
"cdniets": 30,
"cdnistt": 1,
"exp": 1474243500,
"sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.ts"
}
The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI
joxNDc0MjQzNTAwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGx
lL2Zvby9iYXIvYmF6L1swLTldezN9XFwudHMifQ.VYF7Eqk1WhRWdvDVUx5mXDJaS-
r6jbjgiYuwIEAYmbLWsF2dUDohrV70sz7TC09n-oNf_ws4eeH_A6AnvF4FTQ
Once the server validates the signed JWT it will return a new signed
JWT with an updated expiry time (exp) as shown below. Note the
expiry time is increased by the expiration time setting (cdniets)
value.
The JWT Claim Set before signing:
{
"cdniets": 30,
"cdnistt": 1,
"exp": 1474243530,
"sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.ts"
}
The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI
joxNDc0MjQzNTMwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGx
lL2Zvby9iYXIvYmF6L1swLTldezN9XFwudHMifQ.zzXhYg6b7_8MylW-RS97qZv3hQ
QlYg-TxhC-wigdB4moxlFEjndDvv0EDxl42faQaE39BCHZq7H-DXVpBrhxTw
Authors' Addresses Authors' Addresses
Ray van Brandenburg Ray van Brandenburg
Tiledmedia Tiledmedia
Anna van Buerenplein 1 Anna van Buerenplein 1
Den Haag 2595DA Den Haag 2595DA
The Netherlands The Netherlands
Phone: +31 88 866 7000 Phone: +31 88 866 7000
skipping to change at page 31, line 4 skipping to change at page 34, line 43
Authors' Addresses Authors' Addresses
Ray van Brandenburg Ray van Brandenburg
Tiledmedia Tiledmedia
Anna van Buerenplein 1 Anna van Buerenplein 1
Den Haag 2595DA Den Haag 2595DA
The Netherlands The Netherlands
Phone: +31 88 866 7000 Phone: +31 88 866 7000
Email: ray@tiledmedia.com 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
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
Mozilla
Email: linuxwolf@outer-planes.net
 End of changes. 62 change blocks. 
127 lines changed or deleted 328 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/