draft-ietf-cdni-uri-signing-16.txt   draft-ietf-cdni-uri-signing-17.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: April 26, 2019 Cisco Systems, Inc. Expires: September 12, 2019 Cisco Systems, Inc.
P. Sorber P. Sorber
Apple, Inc. Apple, Inc.
October 23, 2018 March 11, 2019
URI Signing for CDN Interconnection (CDNI) URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-16 draft-ietf-cdni-uri-signing-17
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) 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
described can be used both in CDNI and single CDN scenarios. described can be used both in CDNI and single CDN scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 26, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . 5 1.2. Background and overview on URI Signing . . . . . . . . . 5
1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . 9 2. JWT Format and Processing Requirements . . . . . . . . . . . 9
2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10
2.1.2. Subject (sub) claim . . . . . . . . . . . . . . . . . 10 2.1.2. Subject (sub) claim . . . . . . . . . . . . . . . . . 10
2.1.3. Audience (aud) claim . . . . . . . . . . . . . . . . 11 2.1.3. Audience (aud) claim . . . . . . . . . . . . . . . . 11
2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 11 2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 11
2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11 2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11
2.1.6. Issued At (iat) claim . . . . . . . . . . . . . . . . 12 2.1.6. Issued At (iat) claim . . . . . . . . . . . . . . . . 12
2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 12 2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 12
2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12 2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12
2.1.9. CDNI Critical Claims Set (cdnicrit) claim . . . . . . 12 2.1.9. CDNI Critical Claims Set (cdnicrit) claim . . . . . . 13
2.1.10. Client IP (cdniip) claim . . . . . . . . . . . . . . 13 2.1.10. Client IP (cdniip) claim . . . . . . . . . . . . . . 13
2.1.11. CDNI URI Container (cdniuc) claim . . . . . . . . . . 13 2.1.11. CDNI URI Container (cdniuc) claim . . . . . . . . . . 13
2.1.12. CDNI Expiration Time Setting (cdniets) claim . . . . 13 2.1.12. CDNI Expiration Time Setting (cdniets) claim . . . . 14
2.1.13. CDNI Signed Token Transport (cdnistt) claim . . . . . 14 2.1.13. CDNI Signed Token Transport (cdnistt) claim . . . . . 14
2.1.14. CDNI Signed Token Depth (cdnistd) claim . . . . . . . 14 2.1.14. CDNI Signed Token Depth (cdnistd) claim . . . . . . . 14
2.1.15. URI Container Forms . . . . . . . . . . . . . . . . . 15 2.1.15. URI Container Forms . . . . . . . . . . . . . . . . . 15
2.1.15.1. URI Hash Container (hash:) . . . . . . . . . . . 15 2.1.15.1. URI Hash Container (hash:) . . . . . . . . . . . 15
2.1.15.2. URI Regular Expression Container (regex:) . . . 15 2.1.15.2. URI Regular Expression Container (regex:) . . . 15
2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 16 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 16
3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 16 3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 16
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 17 3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 17
3.2.1. Required Claims . . . . . . . . . . . . . . . . . . . 17 3.2.1. Required Claims . . . . . . . . . . . . . . . . . . . 17
3.3. Communicating a signed JWTs in Signed Token Renewal . . . 17 3.3. Communicating a signed JWTs in Signed Token Renewal . . . 18
3.3.1. Support for cross-domain redirection . . . . . . . . 18 3.3.1. Support for cross-domain redirection . . . . . . . . 18
4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 18 4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 18
4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 18 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 19
4.2. CDNI Footprint & Capabilities Advertisement Interface . . 19 4.2. CDNI Footprint & Capabilities Advertisement Interface . . 19
4.3. CDNI Request Routing Redirection Interface . . . . . . . 19 4.3. CDNI Request Routing Redirection Interface . . . . . . . 19
4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 19 4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 19
4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 20 4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 21
5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 22 5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 22
5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 22 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 22
5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 24 5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 27 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 28
6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 28 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 28
6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 28 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 28
6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 28 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 29
6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 28 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 29
6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 29 6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 29
6.5. JSON Web Token Claims Registration . . . . . . . . . . . 29 6.5. JSON Web Token Claims Registration . . . . . . . . . . . 30
6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 29 6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Signed URI Package Example . . . . . . . . . . . . . 35 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 35
A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 36 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 36
A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 37 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 37
A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 38 A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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
skipping to change at page 3, line 45 skipping to change at page 3, line 45
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 Digital Rights Management (DRM), are more mechanisms, such as Digital Rights Management (DRM), are more
appropriate. In addition to access control, URI Signing also has appropriate. In addition to access control, URI Signing also has
benefits in reducing the impact of 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 a CSP's
distribution policy. distribution policies.
Specifically, CDNI Framework [RFC7336] states: Specifically, the 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 delegating traffic to additional downstream CDNs, and to enforce
using techniques such as URI signing. per-request authorization performed by the CSP using techniques
such as URI signing.
In particular, the following requirement is listed in CDNI In particular, the following requirement is listed in the 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 authorization checks and verification that are to be performed by
the Surrogate before delivery. For example, this could the Surrogate before delivery. For example, this could
potentially include the need to validate information (e.g., Expiry potentially include the need to verify information (e.g., Expiry
time, Client 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 defines a method of signing URIs that allows Surrogates
Surrogates in interconnected CDNs to enforce a per-request in interconnected CDNs to enforce a per-request authorization
authorization performed by the CSP. Splitting the role of performing initiated by the CSP. Splitting the role of initiating per-request
per-request authorization by the CSP and the role of validating this authorization by the CSP and the role of verifying this authorization
authorization by the CDN allows any arbitrary distribution policy to by the CDN allows any arbitrary distribution policy to be enforced
be enforced across CDNs without the need of CDNs to have any across CDNs without the need of CDNs to have any awareness of the
awareness of the actual CSP distribution policy. specific CSP distribution policies.
The representation of this method is a Signed JSON Web Token (JWT) The method is implemented using Signed JSON Web Tokens (JWTs)
[RFC7519]. [RFC7519].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the terminology defined in CDNI Problem Statement This document uses the terminology defined in the CDNI Problem
[RFC6707]. Statement [RFC6707].
This document also uses the terminology of JSON Web Token (JWT) This document also uses the terminology of the 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 for which a signed JWT is provided. o Signed URI: A URI for which a signed JWT is provided.
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).
skipping to change at page 5, line 27 skipping to change at page 5, line 24
the next. 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 JWT MUST be signed.
Figure 1, shown below, presents an overview of the URI Signing Figure 1, shown below, presents an overview of the URI Signing
mechanism in the case of a CSP with a single CDN. When the UA mechanism in the case of a CSP with a single CDN. When the UA
browses for content on CSP's website (#1), it receives HTML web pages browses for content on CSP's website (#1), it receives HTML web pages
with embedded content URIs. Upon requesting these URIs, the CSP with embedded content URIs. Upon requesting these URIs, the CSP
redirects to a CDN, creating a Target CDN URI (#2) (alternatively, redirects to a CDN, creating a Target CDN URI (#2) (alternatively,
the Target CDN URI itself is embedded in the HTML). The Target CDN the Target CDN URI itself is embedded in the HTML). The Target CDN
URI is the Signed URI which may include the IP address of the UA and/ URI is the Signed URI which may include the IP address of the UA and/
or a time window and always contains the signed JWT which is or a time window. The signed URI always contains a signed JWT
generated by the CSP using a shared secret or private key. Once the generated by the CSP using a shared secret or private key. Once the
UA receives the response with the Signed URI, it sends a new HTTP UA receives the response with the Signed URI, it sends a new HTTP
request using the Signed URI to the CDN (#3). Upon receiving the request using the Signed URI to the CDN (#3). Upon receiving the
request, the CDN checks to see if the Signed URI is authentic by request, the CDN authenticates the Signed URI by verifying the signed
verifying the signed JWT. If applicable, it checks whether the IP JWT. If applicable, the CDN checks whether the source IP address of
address of the HTTP request matches that in the Signed URI and if the the HTTP request matches the one in the Signed URI and/or if the time
time window is still valid. After these claims are confirmed to be window is still valid. After these claims are verified, the CDN
valid, the CDN delivers the content (#4). delivers the content (#4).
-------- --------
/ \ / \
| CSP |< * * * * * * * * * * * | CSP |< * * * * * * * * * * *
\ / Trust * \ / Trust *
-------- relationship * -------- relationship *
^ | * ^ | *
| | * | | *
1. Browse | | 2. Signed * 1. Browse | | 2. Signed *
for | | URI * for | | URI *
skipping to change at page 6, line 27 skipping to change at page 6, line 27
| User |----------------->/ \ | User |----------------->/ \
| Agent| | CDN | | Agent| | CDN |
| |<-----------------\ / | |<-----------------\ /
+------+ 4. Content -------- +------+ 4. Content --------
Delivery Delivery
Figure 1: Figure 1: URI Signing in a CDN Environment Figure 1: Figure 1: URI Signing in a CDN Environment
1.3. CDNI URI Signing Overview 1.3. CDNI URI Signing Overview
In a CDNI environment, URI Signing operates the same way in the In a CDNI environment, as shown in Figure 2 below, URI Signing
initial steps #1 and #2 but the later steps involve multiple CDNs in operates the same way in the initial steps #1 and #2 but the later
the process of delivering the content. The main difference from the steps involve multiple CDNs delivering the content. The main
single CDN case is a redirection step between the uCDN and the dCDN. difference from the single CDN case is a redirection step between the
In step #3, UA may send an HTTP request or a DNS request. Depending uCDN and the dCDN. In step #3, the UA may send an HTTP request or a
on whether HTTP-based or DNS-based request routing is used, the uCDN DNS request. Depending on whether HTTP-based or DNS-based request
responds by directing the UA towards the dCDN using either a routing is used. The uCDN responds by directing the UA towards the
Redirection URI (which is a Signed URI generated by the uCDN) or a dCDN using either a Redirection URI (i.e., a Signed URI generated by
DNS reply, respectively (#4). Once the UA receives the response, it the uCDN) or a DNS reply, respectively (#4). Once the UA receives
sends the Redirection URI/Target CDN URI to the dCDN (#5). The the response, it sends the Redirection URI/Target CDN URI to the dCDN
received URI is validated by the dCDN before delivering the content (#5). The received URI is verified by the dCDN before delivering the
(#6). This is depicted in the figure below. Note: The CDNI call content (#6). Note: The CDNI call flows are covered in Detailed URI
flows are covered in Detailed URI Signing Operation (Section 5). 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 7, line 39 skipping to change at page 7, line 39
| | Trust relationship * * | | Trust relationship * *
| | * * | | * *
6. Content | | 5.a)Redirection URI * * 6. Content | | 5.a)Redirection URI * *
delivery | | b)Signed URI(after v v delivery | | b)Signed URI(after v v
| | DNS exchange) -------- | | DNS exchange) --------
| +---------------------->/ \ [May be | +---------------------->/ \ [May be
| | dCDN | cascaded | | dCDN | cascaded
+--------------------------\ / CDNs] +--------------------------\ / CDNs]
-------- --------
+-----------------------------------------+
| Key | Asymmetric | Symmetric |
+-----------------------------------------+
|HTTP |Public key (uCDN)|Shared key (uCDN)|
|DNS |Public key (CSP) |Shared key (CSP) |
+-----------------------------------------+
Figure 2: URI Signing in a CDNI Environment Figure 2: URI Signing in a CDNI Environment
The trust relationships between CSP, uCDN, and dCDN have direct The trust relationships between CSP, uCDN, and dCDN have direct
implications for URI Signing. In the case shown in Figure 2, the CDN implications for URI Signing. In the case shown in Figure 2, the CSP
that the CSP has a trust relationship with is the uCDN. The delivery has a trust relationship with the uCDN. The delivery of the content
of the content may be delegated to the dCDN, which has a relationship may be delegated to a dCDN, which has a relationship with the uCDN
with the uCDN but may have no relationship with the CSP. 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., the
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., the Target CDN
provided by the CSP reaches the uCDN. After this URI has been URI) 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 by the uCDN, the uCDN creates and signs a new Redirection
Redirection URI to redirect the UA to the dCDN. Since this new URI URI, redirecting the UA to the dCDN. Since this new URI can have a
could have a new signed JWT, a new signature can be based around the new signed JWT, the relationship between the dCDN and CSP is not
trust relationship between the uCDN and dCDN, and the relationship relevant. Because a relationship between uCDN and dCDN always
between the dCDN and CSP is not relevant. Given the fact that such a exists, either asymmetric public/private keys or symmetric shared
relationship between uCDN and dCDN always exists, both asymmetric secret keys can be used for URI Signing with HTTP-based request
public/private keys and symmetric shared secret keys can be used for routing. Note that the signed Redirection URI MUST maintain the same
URI Signing with HTTP-based request routing. Note that the signed (or higher) level of security as the original Signed URI.
Redirection URI MUST maintain the same, or higher, level of security
as the original Signed URI. +------------------------------------------+
| Mode | Asymmetric Key | Symmetric Key |
+------------------------------------------+
|HTTP |Public key (uCDN)|Shared key (uCDN)|
|DNS |Public key (CSP) |Shared key (CSP) |
+------------------------------------------+
Figure 3: CDNI URI Signing Key
Two types of keys can be used for URI Signing: asymmetric keys and Two types of keys can be used for URI Signing: asymmetric keys and
symmetric keys. Asymmetric keys are based on a public/private key symmetric keys. Asymmetric keys are based on a public/private key
pair mechanism and always contain a private key only known to the pair mechanism and always contain a private key known only to the
entity signing the URI (either CSP or uCDN) and a public key for the entity signing the URI (either CSP or uCDN) and a public key for the
verification of the Signed URI. With symmetric keys, the same key is verification of the Signed URI. With symmetric keys, the same key is
used by both the signing entity for signing the URI as well as by the used by both the signing entity for signing the URI as well as by the
validating entity for validating the Signed URI. Regardless of the verifying entity for verifying the Signed URI. Regardless of the
type of keys used, the validating entity has to obtain the key type of keys used, the verifying entity has to obtain the key (either
(either the public or the symmetric key). There are very different the public or the symmetric key). There are very different
requirements for key distribution (out of scope of this document) requirements (outside the scope of this document) for distributing
with asymmetric keys and with symmetric keys. Key distribution for asymmetric keys and symmetric keys. Key distribution for symmetric
symmetric keys requires confidentiality to prevent another party from keys requires confidentiality to prevent third parties from getting
getting access to the key, since it could then generate valid Signed access to the key, since they could then generate valid Signed URIs
URIs for unauthorized requests. Key distribution for asymmetric keys for unauthorized requests. Key distribution for asymmetric keys does
does not require confidentiality since public keys can typically be not require confidentiality since public keys can typically be
distributed openly (because they cannot be used for URI signing) and distributed openly (because they cannot be used to sign URIs) and
private keys are kept by the URI signing function. private keys are kept secret by the URI signer.
1.4. URI Signing in a non-CDNI context 1.4. URI Signing in a non-CDNI context
While the URI signing method defined in this document was primarily While the URI signing method defined in this document was primarily
created for the purpose of allowing URI Signing in CDNI scenarios, created for the purpose of allowing URI Signing in CDNI scenarios,
e.g., between a uCDN and a dCDN or between a CSP and a dCDN, there is i.e., between a uCDN and a dCDN, there is nothing in the defined URI
nothing in the defined URI Signing method that precludes it from Signing method that precludes it from being used in a non-CDNI
being used in a non-CDNI context. As such, the described mechanism context. As such, the described mechanism could be used in a single-
could be used in a single-CDN scenario such as shown in Figure 1 in CDN scenario such as shown in Figure 1 in Section 1.2, for example to
Section 1.2, for example to allow a CSP that uses different CDNs to allow a CSP that uses different CDNs to only have to implement a
only have to implement a single URI Signing mechanism. 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 an http or https URI [RFC7230] (section Web Token (JWT) [RFC7519] in an HTTP or HTTPS URI [RFC7230]
2.7). The signed JWT contains a number of claims that can be (Section 2.7). The signed JWT contains a number of claims that can
validated to ensure the UA has legitimate access to the content. be verified to ensure the UA has legitimate access to the content.
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
skipping to change at page 10, line 7 skipping to change at page 10, line 13
will not be searched for multiple signed JWTs. will not be searched for multiple signed JWTs.
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 4.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
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. and process all of the claims listed below.
Note: See the Security Considerations (Section 7) section on the Note: See the Security Considerations (Section 7) section on the
limitations of using an expiration time and client IP address for limitations of using an expiration time and client IP address for
distribution policy enforcement. distribution policy enforcement.
2.1.1. Issuer (iss) claim 2.1.1. Issuer (iss) claim
Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1 Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1
MUST be followed. This claim MAY be used to validate authorization MUST be followed. This claim MAY be used to verify authorization of
of the issuer of a signed JWT and also MAY be used to confirm that the issuer of a signed JWT and also MAY be used to confirm that the
the indicated key was provided by said issuer. If the CDN validating indicated key was provided by said issuer. If the CDN verifying the
the signed JWT does not support Issuer validation, or if the Issuer signed JWT does not support Issuer verification, or if the Issuer in
in the signed JWT does not match the list of known acceptable the signed JWT does not match the list of known acceptable Issuers,
Issuers, the CDN MUST reject the request. If the received signed JWT the CDN MUST reject the request. If the received signed JWT contains
contains an Issuer claim, then any JWT subsequently generated for an Issuer claim, then any JWT subsequently generated for CDNI
CDNI redirection MUST also contain an Issuer claim, and the Issuer redirection MUST also contain an Issuer claim, and the Issuer value
value MUST be updated to identify the redirecting CDN. If the MUST be updated to identify the redirecting CDN. If the received
received signed JWT does not contain an Issuer claim, an Issuer claim signed JWT does not contain an Issuer claim, an Issuer claim MAY be
MAY be added to a signed JWT generated for CDNI redirection. added to a signed JWT generated for CDNI redirection.
2.1.2. Subject (sub) claim 2.1.2. Subject (sub) claim
Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2 Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2
MUST be followed. If this claim is used, it MUST be a JSON Web MUST be followed. If this claim is used, it MUST be a JSON Web
Encryption (JWE [RFC7516]) Object in compact serialization form, Encryption (JWE [RFC7516]) Object in compact serialization form,
because it contains personally identifiable information. This claim because it contains personally identifiable information. This claim
contains information about the subject (for example, a user or an contains information about the subject (for example, a user or an
agent) that MAY be used to validate the signed JWT. If the received agent) that MAY be used to verify the signed JWT. If the received
signed JWT contains a Subject claim, then any JWT subsequently signed JWT contains a Subject claim, then any JWT subsequently
generated for CDNI redirection MUST also contain a Subject claim, and generated for CDNI redirection MUST also contain a Subject claim, and
the Subject value MUST be the same as in the received signed JWT. A the Subject value MUST be the same as in the received signed JWT. A
signed JWT generated for CDNI redirection MUST NOT add a Subject signed JWT generated for CDNI redirection MUST NOT add a Subject
claim if no Subject claim existed in the received signed JWT. claim if no Subject claim existed in the received signed JWT.
2.1.3. Audience (aud) claim 2.1.3. Audience (aud) claim
Audience (aud) [optional] - The semantics in [RFC7519] Section 4.1.3 Audience (aud) [optional] - The semantics in [RFC7519] Section 4.1.3
MUST be followed. This claim is used to ensure that the CDN that MUST be followed. This claim is used to ensure that the CDN verifing
validates the JWT identifies itself with the value in this claim. the JWT is an intended recipient of the request. It should be
appropriately set to an identiy that the validating CDN understands
itself to be capable of validating on behalf of. This may be the CSP
identity, or any CDN in the chain and can also be modified as needed
by any entity in the chain as long as they can generate a valid
signature.
2.1.4. Expiry Time (exp) claim 2.1.4. Expiry Time (exp) claim
Expiry Time (exp) [optional] - The semantics in [RFC7519] Expiry Time (exp) [optional] - The semantics in [RFC7519]
Section 4.1.4 MUST be followed, though URI Signing implementations Section 4.1.4 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 verify the signed URI SHOULD be in
in sync. In the CDNI case, this means that CSP, uCDN, and dCDN sync. In the CDNI case, this means that CSP, uCDN, and dCDN servers
servers need to be time-synchronized. It is RECOMMENDED to use NTP need to be time-synchronized. It is RECOMMENDED to use NTP [RFC5905]
[RFC5905] for time synchronization. If the CDN validating the signed for time synchronization. If the CDN verifying the signed JWT does
JWT does not support Expiry Time validation, or if the Expiry Time in not support Expiry Time verification, or if the Expiry Time in the
the signed JWT corresponds to a time earlier than the time of the signed JWT corresponds to a time equal to or earlier than the time of
content request, the CDN MUST reject the request. If the received the content request, the CDN MUST reject the request. If the
signed JWT contains a Expiry Time claim, then any JWT subsequently received signed JWT contains a Expiry Time claim, then any JWT
generated for CDNI redirection MUST also contain an Expiry Time subsequently generated for CDNI redirection MUST also contain an
claim, and the Expiry Time value MUST be the same as in the received Expiry Time claim, and the Expiry Time value MUST be the same as in
signed JWT. A signed JWT generated for CDNI redirection MUST NOT add the received signed JWT. A signed JWT generated for CDNI redirection
an Expiry Time claim if no Expiry Time claim existed in the received MUST NOT add an Expiry Time claim if no Expiry Time claim existed in
signed JWT. the received 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 verify the signed URI SHOULD be in
in sync. In the CDNI case, this means that the CSP, uCDN, and dCDN 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 verifying the signed
JWT does not support Not Before time validation, or if the Not Before JWT does not support Not Before time verification, or if the Not
time in the signed JWT corresponds to a time later than the time of Before time in the signed JWT corresponds to a time later than the
the content request, the CDN MUST reject the request. If 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 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
in the received signed JWT. A signed JWT generated for CDNI in the received signed JWT. A signed JWT generated for CDNI
redirection MUST NOT add a Not Before time claim if no Not Before redirection MUST NOT add a Not Before time claim if no Not Before
time claim existed in the received signed JWT. time claim existed in the received signed JWT.
2.1.6. Issued At (iat) claim 2.1.6. Issued At (iat) claim
Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6 Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6
MUST be followed. Note: The time on the entities that generate and 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 verify the signed URI SHOULD be in sync. In the CDNI case, this
means that CSP, uCDN, and dCDN servers need to be time-synchronized. means that CSP, uCDN, and dCDN servers need to be time-synchronized.
It is RECOMMENDED to use NTP [RFC5905] for time synchronization. If It is RECOMMENDED to use NTP [RFC5905] for time synchronization. If
the received signed JWT contains an Issued At claim, then any JWT the received signed JWT contains an Issued At claim, then any JWT
subsequently generated for CDNI redirection MUST also contain an subsequently generated for CDNI redirection MUST also contain an
Issued At claim, and the Issuer value MUST be updated to identify the 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 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 contain an Issued At claim, an Issued At claim MAY be added to a
signed JWT generated for CDNI redirection. signed JWT generated for CDNI redirection.
2.1.7. Nonce (jti) claim 2.1.7. Nonce (jti) claim
Nonce (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 Nonce (jti) [optional] - The semantics in [RFC7519] Section 4.1.7
MUST be followed. A Nonce can be used to prevent replay attacks if 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 the CDN stores a list of all previously used Nonce values, and
validates that the Nonce in the current JWT has never been used verifies that the Nonce in the current JWT has never been used
before. If the signed JWT contains a Nonce claim and the CDN before. If the signed JWT contains a Nonce claim and the CDN
validating the signed JWT does not support Nonce storage, then the verifying the signed JWT either does not support Nonce storage or has
CDN MUST reject the request. If the received signed JWT contains a previously seen the nonce used in a request for the same content,
Nonce claim, then any JWT subsequently generated for CDNI redirection then the CDN MUST reject the request. If the received signed JWT
MUST also contain a Nonce claim, and the Nonce value MUST be the same contains a Nonce claim, then any JWT subsequently generated for CDNI
as in the received signed JWT. If the received signed JWT does not redirection MUST also contain a Nonce claim, and the Nonce value MUST
contain a Nonce claim, a Nonce claim MUST NOT be added to a signed be the same as in the received signed JWT. If the received signed
JWT generated for CDNI redirection. 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 2.1.8. CDNI Claim Set Version (cdniv) claim
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 this specification. The cdniv
intended to allow changes in and facilitate upgrades across claim is 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. CDNI Critical Claims Set (cdnicrit) claim 2.1.9. CDNI Critical Claims Set (cdnicrit) claim
CDNI Critical Claims Set (cdnicrit) [optional] - The cdnicrit claim CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical
indicates that extensions to this specification are being used that Claims Set (cdnicrit) claim indicates that extensions to this
MUST be understood and processed. Its value is a comma separated specification are being used that MUST be understood and processed.
listing of claims in the Signed JWT that use those extensions. If Its value is a comma separated listing of claims in the Signed JWT
any of the listed extension claims are not understood and supported that use those extensions. If any of the listed extension claims are
by the recipient, then the Signed JWT is invalid. Producers MUST NOT not understood and supported by the recipient, then the Signed JWT is
include claim names defined by this specification, duplicate names, invalid. Producers MUST NOT include claim names defined by this
or names that do not occur as claim names within the Signed JWT in specification, duplicate names, or names that do not occur as claim
the cdnicrit list. Producers MUST NOT use the empty list "" as the names within the Signed JWT in the cdnicrit list. Producers MUST NOT
cdnicrit value. Recipients MAY consider the Signed JWT to be invalid use the empty list "" as the cdnicrit value. Recipients MAY consider
if the cdnicrit list contains any claim names defined by this the Signed JWT to be invalid if the cdnicrit list contains any claim
specification or if any other constraints on its use are violated. names defined by this specification or if any other constraints on
This claim MUST be understood and processed by implementations. its use are violated. This claim MUST be understood and processed by
all implementations.
2.1.10. Client IP (cdniip) claim 2.1.10. Client IP (cdniip) claim
Client IP (cdniip) [optional] IP address, or IP prefix, for which the Client IP (cdniip) [optional] - The Client IP (cdniip) claim hold an
Signed URI is valid. This is represented in CIDR notation, with IP address or IP prefix for which the Signed URI is valid. This is
dotted decimal format for IPv4 or canonical text representation for represented in CIDR notation, with dotted decimal format for IPv4
IPv6 addresses [RFC5952]. The request is rejected if sourced from a addresses [RFC0791] or canonical text representation for IPv6
addresses [RFC5952]. The request MUST be rejected if sourced from a
client outside of the specified IP range. Since the client IP is client outside of the specified IP range. Since the client IP is
considered personally identifiable information this field MUST be a considered personally identifiable information this field MUST be a
JSON Web Encryption (JWE [RFC7516]) Object in compact serialization JSON Web Encryption (JWE [RFC7516]) Object in compact serialization
form. If the CDN validating the signed JWT does not support Client form. If the CDN verifying the signed JWT does not support Client IP
IP validation, or if the Client IP in the signed JWT does not match verification, or if the Client IP in the signed JWT does not match
the source IP address in the content request, the CDN MUST reject the the source IP address in the content request, the CDN MUST reject the
request. The type of this claim is a JSON string that contains the request. The type of this claim is a JSON string that contains the
JWE. If the received signed JWT contains a Client IP claim, then any JWE. If the received signed JWT contains a Client IP claim, then any
JWT subsequently generated for CDNI redirection MUST also contain a 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 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 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 MUST NOT add a Client IP claim if no Client IP claim existed in the
received signed JWT. received signed JWT.
2.1.11. CDNI URI Container (cdniuc) claim 2.1.11. CDNI URI Container (cdniuc) claim
URI Container (cdniuc) [optional] - Container for holding the URI URI Container (cdniuc) [optional] - The URI Container (cdniuc) holds
representation before a URI Signing Package is added. This the URI 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.15. If the URI regex in the signed JWT does not match Section 2.1.15. If the URI Container used in the signed JWT does not
the URI of the content request, the CDN validating the signed JWT match the URI of the content request, the CDN verifying the signed
MUST reject the request. When comparing the URI, the percent encoded JWT MUST reject the request. When comparing the URI, the percent
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.12. CDNI Expiration Time Setting (cdniets) claim 2.1.12. CDNI Expiration Time Setting (cdniets) claim
CDNI Expiration Time Setting (cdniets) [optional] - The CDNI CDNI Expiration Time Setting (cdniets) [optional] - The CDNI
Expiration Time Setting (cdniets) claim provides a means for setting Expiration Time Setting (cdniets) claim provides a means for setting
the value of the Expiry Time (exp) claim when generating a subsequent the value of the Expiry Time (exp) claim when generating a subsequent
signed JWT in Signed Token Renewal. Its type is a JSON numeric signed JWT in Signed Token Renewal. Its type is a JSON numeric
value. It denotes the number of seconds to be added to the time at value. It denotes the number of seconds to be added to the time at
which the JWT is validated that gives the value of the Expiry Time which the JWT is verified that gives the value of the Expiry Time
(exp) claim of the next signed JWT. The CDNI Expiration Time Setting (exp) claim of the next signed JWT. The CDNI Expiration Time Setting
(cdniets) SHOULD NOT be used when not using Signed Token Renewal and (cdniets) SHOULD NOT be used when not using Signed Token Renewal and
MUST be present when using Signed Token Renewal. MUST be present when using Signed Token Renewal.
2.1.13. CDNI Signed Token Transport (cdnistt) claim 2.1.13. CDNI Signed Token Transport (cdnistt) claim
CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed
Token Transport (cdnistt) claim provides a means of signalling the Token Transport (cdnistt) claim provides a means of signalling the
method through which a new signed JWT is transported from the CDN to method through which a new signed JWT is transported from the CDN to
the UA and vice versa for the purpose of Signed Token Renewal. Its the UA and vice versa for the purpose of Signed Token Renewal. Its
type is a JSON integer. Values for this claim can be defined in type is a JSON integer. Values for this claim are defined in
Section 6.4. If using this claim you MUST also specify a CDNI Section 6.4. If using this claim you MUST also specify a CDNI
Expiration Time Setting (cdniets) as noted above. Expiration Time Setting (cdniets) as noted above.
2.1.14. CDNI Signed Token Depth (cdnistd) claim 2.1.14. CDNI Signed Token Depth (cdnistd) claim
CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token
Depth (cdnistd) claim is used to associate a subsequent signed JWT Depth (cdnistd) claim is used to associate a subsequent signed JWT,
generated as the result of a CDNI Signed Token Transport claim with a generated as the result of a CDNI Signed Token Transport claim, with
specific URI subset. Its type is a JSON integer. Signed JWTs MUST a specific URI subset. Its type is a JSON integer. Signed JWTs MUST
NOT use a negative value for the CDNI Signed Token Depth claim. NOT use a negative value for the CDNI Signed Token Depth claim.
If the transport used for Signed Token Transport allows the CDN to If the transport used for Signed Token Transport allows the CDN to
associate the path component of a URI with tokens (e.g., an HTTP associate the path component of a URI with tokens (e.g., an HTTP
Cookie Path as described in section 4.1.2.4 of [RFC6265]), the CDNI Cookie Path as described in section 4.1.2.4 of [RFC6265]), the CDNI
Signed Token Depth value is the number of path segments that should Signed Token Depth value is the number of path segments that should
be considered significant for this association. A CDNI Signed Token be considered significant for this association. A CDNI Signed Token
Depth of zero means that the client SHOULD be directed to return the Depth of zero means that the client SHOULD be directed to return the
token with requests for any path. If the CDNI Signed Token Depth is token with requests for any path. If the CDNI Signed Token Depth is
greater than zero, then the client SHOULD be directed to return the greater than zero, then the client SHOULD be directed to return the
skipping to change at page 15, line 7 skipping to change at page 15, line 16
Token Depth claim, a signed JWT MUST NOT be generated for the Token Depth claim, a signed JWT MUST NOT be generated for the
purposes of Signed Token Renewal. If the CDNI Signed Token Depth purposes of Signed Token Renewal. If the CDNI Signed Token Depth
claim is omitted, it means the same thing as if its value were zero. claim is omitted, it means the same thing as if its value were zero.
If the received signed JWT contains a CDNI Signed Token Depth claim, If the received signed JWT contains a CDNI Signed Token Depth claim,
then any JWT subsequently generated for CDNI redirection or Signed then any JWT subsequently generated for CDNI redirection or Signed
Token Transport MUST also contain a CDNI Signed Token Depth claim, Token Transport MUST also contain a CDNI Signed Token Depth claim,
and the value MUST be the same as in the received signed JWT. and the value MUST be the same as in the received signed JWT.
2.1.15. URI Container Forms 2.1.15. URI Container Forms
The URI Container (cdniuc) claim takes one of the following forms. The URI Container (cdniuc) claim takes one of the following forms:
More forms may be added in the future to extend the capabilities. 'hash:' or 'regex:'. More forms may be added in the future to extend
the capabilities.
Before utilizing a URI with this container, the following steps MUST Before comparing a URI with contents of this container, the following
be performed: steps MUST be performed:
o Prior to validation, remove the signed JWT from the URI. This o Prior to verification, remove the signed JWT from the URI. This
removal is only for the purpose of determining if the URI matches; removal is only for the purpose of determining if the URI matches;
all other purposes will use the original URI. If the signed JWT all other purposes will use the original URI. If the signed JWT
is terminated by anything other than a sub-delimiter (as definined is terminated by anything other than a sub-delimiter (as definined
in [RFC3986] Section 2.2), everything from the reserved character in [RFC3986] Section 2.2), everything from the reserved character
(as defined in [RFC3986] Section 2.2) that precedes the URI (as defined in [RFC3986] Section 2.2) that precedes the URI
Signing Package Attribute to the last character of the signed JWT Signing Package Attribute to the last character of the signed JWT
will be removed, inclusive. Otherwise, everything from the first will be removed, inclusive. Otherwise, everything from the first
character of the URI Signing Package Attribute to the sub- character of the URI Signing Package Attribute to the sub-
delimiter that terminates the signed JWT will be removed, delimiter that terminates the signed JWT will be removed,
inclusive. inclusive.
o Normalize the URI according to section 2.7.3 [RFC7230] and o Normalize the URI according to section 2.7.3 [RFC7230] and
[RFC3986] sections 6.2.2 and 6.2.3. This applies to both sections 6.2.2 and 6.2.3 [RFC3986]. This applies to both
generation and validation of the signed JWT. generation and verification of the signed JWT.
2.1.15.1. URI Hash Container (hash:) 2.1.15.1. URI Hash Container (hash:)
Prefixed with 'hash:', this string is a URL Segment form ([RFC6920] Prefixed with 'hash:', this string is a URL Segment form ([RFC6920]
Section 5) of the URI. Section 5) of the URI.
2.1.15.2. URI Regular Expression Container (regex:) 2.1.15.2. URI Regular Expression Container (regex:)
Prefixed with 'regex:', this string is any POSIX [POSIX.1] Section 9 Prefixed with 'regex:', this string is any POSIX Section 9 [POSIX.1]
Extended Regular Expression compatible regular expression used to Extended Regular Expression compatible regular expression used to
match against the requested URI. These regular expressions MUST be match against the requested URI. These regular expressions MUST be
evaluated in the POSIX locale (POSIX [POSIX.1] Section 7.2). evaluated in the POSIX locale (POSIX Section 7.2 [POSIX.1]).
Note: Because '\' has special meaning in JSON [RFC7159] as the escape Note: Because '\' has special meaning in JSON [RFC8259] 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 'regex:' is the following: An example of a 'regex:' is the following:
[^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)? [^:]*\\://[^/]*/folder/content/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 verifying the
JWT to ensure its authenticity. JWT to ensure its authenticity.
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 verification. This reduces the size of the signed JWT token.
3. URI Signing Token Renewal 3. URI Signing Token Renewal
3.1. Overview 3.1. Overview
For content that is delivered via HTTP in a segmented fashion, such For content that is delivered via HTTP in a segmented fashion, such
as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216], as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216],
special provisions need to be made in order to ensure URI Signing can special provisions need to be made in order to ensure URI Signing can
be applied. In general, segmented protocols work by breaking large be applied. In general, segmented protocols work by breaking large
objects (e.g. videos) into a sequence of small independent segments. objects (e.g., videos) into a sequence of small independent segments.
Such segments are then referenced by a separate manifest file, which Such segments are then referenced by a separate manifest file, which
either includes a list of URLs to the segments or specifies an either includes a list of URLs to the segments or specifies an
algorithm through which a User Agent can construct the URLs to the algorithm through which a User Agent can construct the URLs to the
segments. Requests for segments therefore originate from the segments. Requests for segments therefore originate from the
manifest file and, unless the URLs in the manifest file point to 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 CSP, are not subjected to redirection and URI Signing. This opens up
the vulnerability of malicious User Agents sharing the manifest file a vulnerability to malicious User Agents sharing the manifest file
and deep-linking to the segments. and deep-linking to the segments.
One method for dealing with this vulnerability would be to include, One method for dealing with this vulnerability would be to include,
in the manifest itself, Signed URIs that point to the individual in the manifest itself, Signed URIs that point to the individual
segments. There exist a number of issues with that approach. First, segments. There exist a number of issues with that approach. First,
it requires the CDN delivering the manifest to rewrite the manifest 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 file for each User Agent, which would require the CDN to be aware of
the exact segmentation protocol used. Secondly, it could also the exact segmentation protocol used. Secondly, it could also
require the expiration time of the Signed URIs to be valid for an require the expiration time of the Signed URIs to be valid for an
extended duration if the content described by the manifest is meant extended duration if the content described by the manifest is meant
skipping to change at page 17, line 10 skipping to change at page 17, line 19
The method described in this section allows CDNs to use URI Signing The method described in this section allows CDNs to use URI Signing
for segmented content without having to include the Signed URIs in for segmented content without having to include the Signed URIs in
the manifest files themselves. the manifest files themselves.
3.2. Signed Token Renewal mechanism 3.2. Signed Token Renewal mechanism
In order to allow for effective access control of segmented content, In order to allow for effective access control of segmented content,
the URI signing mechanism defined in this section is based on a the URI signing mechanism defined in this section is based on a
method through which subsequent segment requests can be linked method through which subsequent segment requests can be linked
together. As part of the JWT validation procedure, the CDN can together. As part of the JWT verification procedure, the CDN can
generate a new signed JWT that the UA can use to do a subsequent generate a new signed JWT that the UA can use to do a subsequent
request. More specifically, whenever a UA successfully retrieves a request. More specifically, whenever a UA successfully retrieves a
segment, it receives, in the HTTP 2xx Successful message, a signed segment, it receives, in the HTTP 2xx Successful message, a signed
JWT that it can use whenever it requests the next segment. As long JWT that it can use whenever it requests the next segment. As long
as each successive signed JWT is correctly validated before a new one as each successive signed JWT is correctly verified before a new one
is generated, the model is not broken and the User Agent can is generated, the model is not broken and the User Agent can
successfully retrieve additional segments. Given the fact that with successfully retrieve additional segments. Given the fact that with
segmented protocols, it is usually not possible to determine a priori segmented protocols, it is usually not possible to determine a priori
which segment will be requested next (i.e., to allow for seeking which segment will be requested next (i.e., to allow for seeking
within the content and for switching to a different representation), within the content and for switching to a different representation),
the Signed Token Renewal uses the URI Regular Expression Container the Signed Token Renewal uses the URI Regular Expression Container
scoping mechanisms in the URI Container (cdniuc) claim to allow a scoping mechanisms in the URI Container (cdniuc) claim to allow a
signed JWT to be valid for more than one URL. signed JWT to be valid for more than one URL.
In order for this renewal of signed JWTs to work, it is necessary for In order for this renewal of signed JWTs to work, it is necessary for
a UA to extract the signed JWT from the HTTP 2xx Successful message a UA to extract the signed JWT from the HTTP 2xx Successful message
of an earlier request and use it to retrieve the next segment. The of an earlier request and use it to retrieve the next segment. The
exact mechanism by which the client does this depends on the exact exact mechanism by which the client does this is outside the scope of
segmented protocol and since this document is only concerned with the this document. However, in order to also support legacy UAs that do
generation and validation of incoming request, this process is not include any specific provisions for the handling of signed JWTs,
outside the scope of this document. However, in order to also the following section defines a mechanism using HTTP Cookies
support legacy UAs that do not include any specific provisions for [RFC6265] that allows such UAs to support the concept of renewing
the handling of signed JWTs, the folowing section defines a mechanism signed JWTs without requiring any additional UA support.
using HTTP Cookies [RFC6265] that allows such UAs to support the
concept of renewing signed JWTs without requiring any support on the
UA side.
3.2.1. Required Claims 3.2.1. Required Claims
The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12) The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12)
MUST both be present to utilize Signed token Renewal. Either one MUST both be present for Signed Token Renewal. You MAY set cdnistt
MUST NOT appear alone. You MAY set cdnistt to a value of '0' to mean to a value of '0' to mean no Signed Token Renewal, but you still MUST
no Signed Token Renewal, but you still MUST have a corresponding have a corresponding cdniets that verifies as a JSON number.
cdniets that validates as a JSON number. However, if you do not want However, if you do not want to use Signed Token Renewal, it is
to use Signed Token Renewal, it is RECOMMENDED to simply omit both. RECOMMENDED to simply omit both.
3.3. Communicating a signed JWTs in Signed Token Renewal 3.3. Communicating a signed JWTs in Signed Token Renewal
This section assumes the value of the CDNI Signed Token Transport This section assumes the value of the CDNI Signed Token Transport
(cdnistt) claim has been set to 1. Other values of cdnistt are out (cdnistt) claim has been set to 1. Other values of cdnistt are out
of scope of this document. of scope of this document.
When using the Signed Token Renewal mechanism, the signed JWT is When using the Signed Token Renewal mechanism, the signed JWT is
transported to the UA via a 'URISigningPackage' cookie added to the transported to the UA via a 'URISigningPackage' cookie added to the
HTTP 2xx Successful message along with the content being returned to 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 the UA, or to the HTTP 3xx Redirection message in case the UA is
redirected to a different server. redirected to a different server.
3.3.1. Support for cross-domain redirection 3.3.1. Support for cross-domain redirection
For security purposes, the use of cross-domain cookies is not For security purposes, the use of cross-domain cookies is not
supported in some application environments. As a result, the Cookie- supported in some application environments. As a result, the Cookie-
based method for transport of the Signed Token described in the based method for transport of the Signed Token described in the
previous section might break if used in combination with a HTTP 3xx previous section might break if used in combination with an HTTP 3xx
Redirection response where the target URL is in a different domain. Redirection response where the target URL is in a different domain.
In such scenarios, Signed Token Renewal of a signed JWT SHOULD be In such scenarios, Signed Token Renewal of a signed JWT SHOULD be
communicated via the query string instead, in a similar fashion to communicated via the query string instead, in a similar fashion to
how regular signed JWTs (outside of Signed Token Renewal) are how regular signed JWTs (outside of Signed Token Renewal) are
communicated. Note that the use of URL embedded signed JWTs SHOULD communicated. Note that the use of URL embedded signed JWTs SHOULD
NOT be used in HTTP 2xx Successful messages, since UAs might not know NOT be used in HTTP 2xx Successful messages, since UAs might not know
how to extract the signed JWTs. how to extract the signed JWTs.
Note that the process described below only works in cases where both Note that the process described herein only works in cases where both
the manifest file and segments constituting the segmented content are the manifest file and segments constituting the segmented content are
delivered from the same domain. In other words, any redirection delivered from the same domain. In other words, any redirection
between different domains needs to be carried out while retrieving between different domains needs to be carried out while retrieving
the manifest file. the manifest file.
4. Relationship with CDNI Interfaces 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 A dCDN that supports URI Signing needs to be able to advertise this
advertise this capability to the uCDN. The uCDN needs to select a capability to the uCDN. The uCDN needs to select a dCDN based on
dCDN based on such capability when the CSP requires access control to such capability when the CSP requires access control to enforce its
enforce its distribution policy via URI Signing. Also, the uCDN distribution policy via URI Signing. Also, the uCDN needs to be able
needs to be able to distribute via the CDNI Metadata interface the to distribute via the CDNI Metadata interface the information
information necessary to allow the dCDN to validate a Signed URI. necessary to allow the dCDN to verify a Signed URI. Events that
Events that pertain to URI Signing (e.g., request denial or delivery pertain to URI Signing (e.g., request denial or delivery after access
after access authorization) need to be included in the logs authorization) need to be included in the logs communicated through
communicated through the CDNI Logging interface (Editor's Note: Is the CDNI Logging interface.
this within the scope of the CDNI Logging interface?).
4.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.
4.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
skipping to change at page 19, line 26 skipping to change at page 19, line 30
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.
4.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 verification 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
must be signed and validated before delivering content. is signed and verified before delivering content. Otherwise,
Otherwise, the dCDN does not perform validation, regardless of the dCDN does not perform verification, regardless of whether
whether or not the URI is signed. or not the URI is signed.
Type: Boolean Type: Boolean
Mandatory-to-Specify: No. The default is true. Mandatory-to-Specify: No. The default is true.
Property: issuers Property: issuers
Description: A list of valid Issuers against which the Issuer Description: A list of valid Issuers against which the Issuer
claim in the signed JWT may be validated. claim in the signed JWT may be verified.
Type: Array of Strings Type: Array of Strings
Mandatory-to-Specify: No. The default is an empty list. An Mandatory-to-Specify: No. The default is an empty list. An
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. The default is "URISigningPackage".
Property: jwt-header Property: jwt-header
Description: The header part of JWT that is used for generating Description: The header part of JWT that is used for generating
or validating a signed JWT when the JWT token in the URI or verifying a signed JWT when the JWT token in the URI Signing
Signing Package does not contain a header part. Package does not contain a header part.
Type: String Type: String
Mandatory-to-Specify: No. A jwt-header is not essential for Mandatory-to-Specify: No. By default, the header is assumed to
all implementations of URI signing. be included in the JWT token.
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:
{ {
"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",
"jwt-header": "1234abcd"
} }
} }
4.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.
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 verification
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 verification performed
+ "200" : signed JWT validation performed and validated + "200" : signed JWT verification performed and verified
+ "400" : signed JWT validation performed and rejected because + "400" : signed JWT verification performed and rejected
of incorrect signature because of incorrect signature
+ "401" : signed JWT validation performed and rejected because + "401" : signed JWT verification performed and rejected
of Expiration Time enforcement because of Expiration Time enforcement
+ "402" : signed JWT validation performed and rejected because + "402" : signed JWT verification performed and rejected
of Client IP enforcement because of Client IP enforcement
+ "403" : signed JWT validation performed and rejected because + "403" : signed JWT verification performed and rejected
of URI Regular Expression enforcement because of URI Container enforcement
+ "404" : signed JWT validation performed and rejected because + "404" : signed JWT verification performed and rejected
of Issuer enforcement because of Issuer enforcement
+ "405" : signed JWT validation performed and rejected because + "405" : signed JWT verification performed and rejected
of Not Before enforcement because of Not Before enforcement
+ "500" : unable to perform signed JWT validation because of + "406" : signed JWT verification performed and rejected
because of Subject enforcement
+ "407" : signed JWT verification performed and rejected
because of Audience enforcement
+ "408" : signed JWT verification performed and rejected
because of Nonce enforcement
+ "409" : signed JWT verification performed and rejected
because of Version enforcement
+ "410" : signed JWT verification performed and rejected
because of Critical Extention enforcement
+ "500" : unable to perform signed JWT verification because of
malformed URI malformed URI
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
field. field.
o s-uri-signing-deny-reason (optional): o s-uri-signing-deny-reason (optional):
* format: QSTRING * format: QSTRING
* field value: a string for providing further information in case * field value: a string for providing further information in case
skipping to change at page 22, line 28 skipping to change at page 22, line 50
5.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 (assuming HTTP redirection, iterative request
steps (assuming HTTP redirection, iterative request routing, and a routing, and a CDN path with two CDNs) includes the following steps:
CDN path with two CDNs). Note that uCDN and uCDN are used
exchangeably.
End-User dCDN uCDN CSP End-User dCDN uCDN CSP
| | | | | | | |
| 1.CDNI FCI interface used to | | | 1.CDNI FCI interface used to | |
| advertise URI Signing capability| | | advertise URI Signing capability| |
| |------------------->| | | |------------------->| |
| | | | | | | |
| 2.Provides information to validate signed JWT | | 2.Provides information to verify signed JWT |
| | |<-------------------| | | |<-------------------|
| | | | | | | |
| 3.CDNI Metadata interface used to| | | 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| | | provide URI Signing attributes| |
| |<-------------------| | | |<-------------------| |
: : : :
: (Later in time) : : :
|4.Authorization request | | |4.Authorization request | |
|------------------------------------------------------------->| |------------------------------------------------------------->|
| | | [Apply distribution | | | [Apply distribution
| | | policy] | | | | policy] |
| | | | | | | |
| | (ALT: Authorization decision) | | (ALT: Authorization decision)
|5.Request is denied | | <Negative> | |5.Request is denied | | <Negative> |
|<-------------------------------------------------------------| |<-------------------------------------------------------------|
| | | | | | | |
|6.CSP provides signed URI | <Positive> | |6.CSP provides signed URI | <Positive> |
|<-------------------------------------------------------------| |<-------------------------------------------------------------|
| | | | | | | |
|7.Content request | | | |7.Content request | | |
|---------------------------------------->| [Validate URI | |---------------------------------------->| [Verifiy URI |
| | | signature] | | | | signature] |
| | | | | | | |
| | (ALT: Validation result) | | | (ALT: Verification result) |
|8.Request is denied | <Negative>| | |8.Request is denied | <Negative>| |
|<----------------------------------------| | |<----------------------------------------| |
| | | | | | | |
|9.Re-sign URI and redirect to <Positive>| | |9.Re-sign URI and redirect to <Positive>| |
| dCDN (newly signed URI) | | | dCDN (newly signed URI) | |
|<----------------------------------------| | |<----------------------------------------| |
| | | | | | | |
|10.Content request | | | |10.Content request | | |
|------------------->| [Validate URI | | |------------------->| [Verify URI | |
| | signature] | | | | signature] | |
| | | | | | | |
| (ALT: Validation result) | | | (ALT: Verification result) | |
|11.Request is denied| <Negative> | | |11.Request is denied| <Negative> | |
|<-------------------| | | |<-------------------| | |
| | | | | | | |
|12.Content delivery | <Positive> | | |12.Content delivery | <Positive> | |
|<-------------------| | | |<-------------------| | |
: : : : : : : :
: (Later in time) : : : : (Later in time) : : :
|13.CDNI Logging interface to include URI Signing information | |13.CDNI Logging interface to include URI Signing information |
| |------------------->| | | |------------------->| |
Figure 3: HTTP-based Request Routing with URI Signing Figure 4: HTTP-based Request Routing with URI Signing
1. Using the CDNI Footprint & Capabilities Advertisement interface, 1. Using the CDNI Footprint & Capabilities Advertisement interface,
the dCDN advertises its capabilities including URI Signing the dCDN advertises its capabilities including URI Signing
support to the uCDN. support to the uCDN.
2. CSP provides to the uCDN the information needed to validate 2. CSP provides to the uCDN the information needed to verify signed
signed JWTs from that CSP. For example, this information may JWTs from that CSP. For example, this information may include a
include a key value. 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 verify signed JWTs from the uCDN
uCDN for the given CSP. For example, this information may for the given CSP. For example, this information may include
include the URI query string parameter name for the URI Signing the URI query string parameter name for the URI Signing Package
Package Attribute. 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 personal 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 and sends an error code (e.g., 403 Forbidden) in the request and sends an error code (e.g., 403 Forbidden) in the
HTTP response. 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 verifies 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 and 8. If the verification is negative, the uCDN rejects the request
sends an error code (e.g., 403 Forbidden) in the HTTP response. and sends an error code 403 Forbidden in the HTTP response.
9. If the validation is positive, the uCDN computes a Signed URI 9. If the verification 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
it to the end user as the URI to use to further request the it to the end user as the URI to use to further request the
content 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 verifies 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 verification is negative, the dCDN rejects the request
sends an error code (e.g., 403 Forbidden) in the HTTP response. and sends an error code 403 Forbidden in the HTTP response.
12. If the validation is positive, the dCDN serves the request and 12. If the verification is positive, the dCDN serves the request and
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.
5.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 verify the Signed URI.
The URI signing method described below is based on the following The URI signing method (assuming iterative DNS request routing and a
steps (assuming iterative DNS request routing and a CDN path with two CDN path with two CDNs) includes the following steps.
CDNs).
End-User dCDN uCDN CSP End-User dCDN uCDN CSP
| | | | | | | |
| 1.CDNI FCI interface used to | | | 1.CDNI FCI interface used to | |
| advertise URI Signing capability| | | advertise URI Signing capability| |
| |------------------->| | | |------------------->| |
| | | | | | | |
| 2.Provides information to validate signed JWT | | 2.Provides information to verify signed JWT |
| | |<-------------------| | | |<-------------------|
| 3.CDNI Metadata interface used to| | | 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| | | provide URI Signing attributes| |
| |<-------------------| | | |<-------------------| |
: : : :
: (Later in time) : : :
|4.Authorization request | | |4.Authorization request | |
|------------------------------------------------------------->| |------------------------------------------------------------->|
| | | [Apply distribution | | | [Apply distribution
| | | policy] | | | | policy] |
| | | | | | | |
| | (ALT: Authorization decision) | | (ALT: Authorization decision)
|5.Request is denied | | <Negative> | |5.Request is denied | | <Negative> |
|<-------------------------------------------------------------| |<-------------------------------------------------------------|
| | | | | | | |
|6.Provides signed URI | <Positive> | |6.Provides signed URI | <Positive> |
skipping to change at page 25, line 50 skipping to change at page 26, line 26
|8.Redirect DNS to dCDN | | |8.Redirect DNS to dCDN | |
|<----------------------------------------| | |<----------------------------------------| |
| | | | | | | |
|9.DNS request | | | |9.DNS request | | |
|------------------->| | | |------------------->| | |
| | | | | | | |
|10.IP address of Surrogate | | |10.IP address of Surrogate | |
|<-------------------| | | |<-------------------| | |
| | | | | | | |
|11.Content request | | | |11.Content request | | |
|------------------->| [Validate URI | | |------------------->| [Verify URI | |
| | signature] | | | | signature] | |
| | | | | | | |
| (ALT: Validation result) | | | (ALT: Verification result) | |
|12.Request is denied| <Negative> | | |12.Request is denied| <Negative> | |
|<-------------------| | | |<-------------------| | |
| | | | | | | |
|13.Content delivery | <Positive> | | |13.Content delivery | <Positive> | |
|<-------------------| | | |<-------------------| | |
: : : : : : : :
: (Later in time) : : : : (Later in time) : : :
|14.CDNI Logging interface to report URI Signing information | |14.CDNI Logging interface to report URI Signing information |
| |------------------->| | | |------------------->| |
Figure 4: DNS-based Request Routing with URI Signing Figure 5: DNS-based Request Routing with URI Signing
1. Using the CDNI Footprint & Capabilities Advertisement interface, 1. Using the CDNI Footprint & Capabilities Advertisement interface,
the dCDN advertises its capabilities including URI Signing the dCDN advertises its capabilities including URI Signing
support to the uCDN. support to the uCDN.
2. CSP provides to the uCDN the information needed to validate 2. CSP provides to the uCDN the information needed to verify
cryptographic signatures from that CSP. For example, this cryptographic signatures from that CSP. For example, this
information may include a key. information may include a key.
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 cryptographic signatures dCDN the information needed to verify cryptographic signatures
from the CSP (e.g., the URI query string parameter name for the from the CSP (e.g., the URI query string parameter name for the
URI Signing Package Attribute). In the case of symmetric key, URI Signing Package Attribute). In the case of symmetric key,
the uCDN checks if the dCDN is allowed by CSP to obtain the the uCDN checks if the dCDN is allowed by CSP to obtain the
shared secret key. shared secret key.
4. When a UA requests a piece of protected content from the CSP, 4. When a UA requests a piece of protected content from the CSP,
the CSP makes a specific authorization decision for this unique the CSP makes a specific authorization decision for this unique
request based on its arbitrary distribution policy. request based on its arbitrary distribution policy.
5. If the authorization decision is negative, the CSP rejects the 5. If the authorization decision is negative, the CSP rejects the
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
cryptographic signature that is based on unique parameters of cryptographic signature that is based on unique parameters of
that request and includes it in the URI provided to the end user that request and includes it in the URI provided to the end user
to request the content. to request the content.
7. End user sends DNS request to the uCDN. 7. End user sends DNS request to the uCDN.
8. On receipt of the DNS request, the uCDN redirects the request to 8. On receipt of the DNS request, the uCDN redirects the request to
the dCDN. the dCDN.
9. End user sends DNS request to the dCDN. 9. End user sends DNS request to the dCDN.
10. On receipt of the DNS request, the dCDN responds with IP address 10. On receipt of the DNS request, the dCDN responds with IP address
of one of its Surrogates. of one of its Surrogates.
11. On receipt of the corresponding content request, the dCDN 11. On receipt of the corresponding content request, the dCDN
validates the cryptographic signature in the URI using the verifies the cryptographic signature in the URI using the
information provided by the uCDN in the CDNI Metadata. information provided by the uCDN in the CDNI Metadata.
12. If the validation is negative, the dCDN rejects the request and 12. If the verification is negative, the dCDN rejects the request
sends an error code (e.g., 403) in the HTTP response. and sends an error code 403 Forbidden in the HTTP response.
13. If the validation is positive, the dCDN serves the request and 13. If the verification 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 untrusted, CDNI hops is the public key, which is multiple, possibly untrusted, CDNI hops is the public key, which is
generally not confidential. generally not confidential.
skipping to change at page 27, line 40 skipping to change at page 28, line 18
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.
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 Types" registry:
+---------------+---------------+ +---------------+---------------+
| Payload Type | Specification | | Payload Type | Specification |
+---------------+---------------+ +---------------+---------------+
| MI.UriSigning | RFCthis | | MI.UriSigning | 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.]
skipping to change at page 29, line 16 skipping to change at page 29, line 40
this document.] this document.]
6.4. CDNI URI Signing Signed Token Transport 6.4. CDNI URI Signing Signed Token Transport
The IANA is requested to create a new "CDNI URI Signing Signed Token The IANA is requested to create a new "CDNI URI Signing Signed Token
Transport" subregistry in the "Content Delivery Networks Transport" subregistry in the "Content Delivery Networks
Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing
Signed Token Transport" namespace defines the valid values that may Signed Token Transport" namespace defines the valid values that may
be in the Signed Token Transport (cdnistt) JWT claim. Additions to be in the Signed Token Transport (cdnistt) JWT claim. Additions to
the Signed Token Transport namespace conform to the "Specification the Signed Token Transport namespace conform to the "Specification
Required" policy as defined in [RFC5226]. Required" policy as defined in [RFC8126].
The following table defines the initial Enforcement Information The following table defines the initial Enforcement Information
Elements: Elements:
+-------+-------------------------------------------+---------+ +-------+-------------------------------------------+---------+
| Value | Description | RFC | | Value | Description | RFC |
+-------+-------------------------------------------+---------+ +-------+-------------------------------------------+---------+
| 0 | Designates token transport is not enabled | RFCthis | | 0 | Designates token transport is not enabled | RFCthis |
| 1 | Designates token transport via cookie | RFCthis | | 1 | Designates token transport via cookie | 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.]
[Ed Note: are there any special instructions to the designated expert
reviewer?]
6.5. JSON Web Token Claims Registration 6.5. JSON Web Token Claims Registration
This specification registers the following Claims in the IANA "JSON This specification registers the following Claims in the IANA "JSON
Web Token Claims" registry [IANA.JWT.Claims] established by Web Token Claims" registry [IANA.JWT.Claims] established by
[RFC7519]. [RFC7519].
6.5.1. Registry Contents 6.5.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
skipping to change at page 31, line 16 skipping to change at page 31, line 38
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.
o 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 denying legitimate
legitimate UAs access to the content. One may also reduce UAs access to the content. One may also reduce exposure to replay
exposure to replay attacks by including a unique one-time access attacks by including a unique one-time access ID via the Nonce
ID via the Nonce attribute (jti claim). Whenever the dCDN attribute (jti claim). Whenever the dCDN receives a request with
receives a request with a given unique ID, it adds that ID to the a given unique ID, it adds that ID to the list of 'used' IDs. In
list of 'used' IDs. In the case an illegitimate UA tries to use the case an illegitimate UA tries to use the same URI through a
the same URI through a replay attack, the dCDN can deny the replay attack, the dCDN can deny the request based on the already-
request based on the already-used access ID. used access ID.
o 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 different users
based on Client IP Address and illegitimate users being able to based on Client IP Address which can lead to illegitimate users
access the content. One way to reduce exposure to this kind of being able to access the content. One way to reduce exposure to
attack is to not only check for Client IP but also for other this kind of attack is to not only check for Client IP but also
attributes, e.g., attributes that can be found in HTTP headers. for other 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.
If a shared key usable for signing is compromised, an attacker can If a shared key usable for signing is compromised, an attacker can
use it to perform a denial-of-service attack by forcing the CDN to use it to perform a denial-of-service attack by forcing the CDN to
evaluate prohibitively expensive regular expressions embedded in a evaluate prohibitively expensive regular expressions embedded in a
cdniuc claim. As a result, compromised keys should be timely revoked cdniuc claim. As a result, compromised keys should be timely revoked
skipping to change at page 32, line 31 skipping to change at page 33, line 9
o Emmanuel Thomas provided content for HTTP Adaptive Streaming. o Emmanuel Thomas provided content for HTTP Adaptive Streaming.
o Matt Miller provided consultation on JWT usage as well as code to o Matt Miller provided consultation on JWT usage as well as code to
generate working JWT examples. generate working JWT examples.
11. References 11. References
11.1. Normative References 11.1. Normative References
[POSIX.1] "The Open Group Base Specifications Issue 7", IEEE
Std 1003.1 2018 Edition, Jan 2018,
<http://pubs.opengroup.org/onlinepubs/9699919799/>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
IANA Considerations Section in RFCs", RFC 5226, Resource Identifier (URI): Generic Syntax", STD 66,
DOI 10.17487/RFC5226, May 2008, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[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,
<https://www.rfc-editor.org/info/rfc6920>. <https://www.rfc-editor.org/info/rfc6920>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[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,
<https://www.rfc-editor.org/info/rfc7516>. <https://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
skipping to change at page 33, line 29 skipping to change at page 34, 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,
<https://www.rfc-editor.org/info/rfc7937>. <https://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,
<https://www.rfc-editor.org/info/rfc8006>. <https://www.rfc-editor.org/info/rfc8006>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
11.2. Informative References 11.2. Informative References
[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] [MPEG-DASH]
ISO, "Information technology -- Dynamic adaptive streaming ISO, "Information technology -- Dynamic adaptive streaming
over HTTP (DASH) -- Part 1: Media presentation description over HTTP (DASH) -- Part 1: Media presentation description
and segment format", ISO/IEC 23009-1:2014, Edition 2, 05 and segment format", ISO/IEC 23009-1:2014, Edition 2, 05
2014, <http://www.iso.org/standard/65274.html>. 2014, <http://www.iso.org/standard/65274.html>.
[POSIX.1] IEEE, "The Open Group Base Specifications Issue 7", IEEE
Std 1003.1 2018 Edition, Jan 2018,
<http://pubs.opengroup.org/onlinepubs/9699919799/>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://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,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[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, <https://www.rfc-editor.org/info/rfc6707>. 2012, <https://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,
<https://www.rfc-editor.org/info/rfc6983>. <https://www.rfc-editor.org/info/rfc6983>.
skipping to change at page 39, line 13 skipping to change at page 39, line 13
} }
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua
XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTAwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTAwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R
uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.wsSvwxY8mtRax7HK_ uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.wsSvwxY8mtRax7HK_
dro_l6m-mM-HYdeaUoTSgVS5XTIhXBsCPsYQncsradmgmOWHDDOxsSMVVTjHe5E5YH dro_l6m-mM-HYdeaUoTSgVS5XTIhXBsCPsYQncsradmgmOWHDDOxsSMVVTjHe5E5YH
ZlQ ZlQ
Once the server validates the signed JWT it will return a new signed Once the server verifies the signed JWT it will return a new signed
JWT with an updated expiry time (exp) as shown below. Note the JWT with an updated expiry time (exp) as shown below. Note the
expiry time is increased by the expiration time setting (cdniets) expiry time is increased by the expiration time setting (cdniets)
value. value.
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"cdniets": 30, "cdniets": 30,
"cdnistt": 1, "cdnistt": 1,
"cdnistd": 2, "cdnistd": 2,
 End of changes. 137 change blocks. 
339 lines changed or deleted 366 lines changed or added

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