rfc9246.original   rfc9246.txt 
CDNI R. van Brandenburg Internet Engineering Task Force (IETF) R. van Brandenburg
Internet-Draft Tiledmedia Request for Comments: 9246 Tiledmedia
Intended status: Standards Track K. Leung Category: Standards Track K. Leung
Expires: 23 September 2022 ISSN: 2070-1721
P. Sorber P. Sorber
Apple, Inc. Apple, Inc.
22 March 2022 May 2022
URI Signing for Content Delivery Network Interconnection (CDNI) URI Signing for Content Delivery Network Interconnection (CDNI)
draft-ietf-cdni-uri-signing-26
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 Content Delivery Network content access control requirements of Content Delivery Network
Interconnection (CDNI) and proposes a URI Signing method as a JSON Interconnection (CDNI) and proposes a URI Signing method as a JSON
Web Token (JWT) profile. 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 User Agent (UA). The claims needed by the signed JWT to authorize a User Agent (UA). The
mechanism described can be used both in CDNI and single Content mechanism described can be used both in CDNI and single Content
Delivery Network (CDN) scenarios. Delivery Network (CDN) scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 23 September 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9246.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology
1.2. Background and overview on URI Signing . . . . . . . . . 5 1.2. Background and Overview on URI Signing
1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 1.3. CDNI URI Signing Overview
1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 9 1.4. URI Signing in a Non-CDNI Context
2. JWT Format and Processing Requirements . . . . . . . . . . . 9 2. JWT Format and Processing Requirements
2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. JWT Claims
2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10 2.1.1. Issuer (iss) Claim
2.1.2. Subject (sub) claim . . . . . . . . . . . . . . . . . 11 2.1.2. Subject (sub) Claim
2.1.3. Audience (aud) claim . . . . . . . . . . . . . . . . 11 2.1.3. Audience (aud) Claim
2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 11 2.1.4. Expiry Time (exp) Claim
2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 12 2.1.5. Not Before (nbf) Claim
2.1.6. Issued At (iat) claim . . . . . . . . . . . . . . . . 12 2.1.6. Issued At (iat) Claim
2.1.7. JWT ID (jti) claim . . . . . . . . . . . . . . . . . 12 2.1.7. JWT ID (jti) Claim
2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 13 2.1.8. CDNI Claim Set Version (cdniv) Claim
2.1.9. CDNI Critical Claims Set (cdnicrit) claim . . . . . . 13 2.1.9. CDNI Critical Claims Set (cdnicrit) Claim
2.1.10. Client IP Address (cdniip) claim . . . . . . . . . . 13 2.1.10. Client IP Address (cdniip) Claim
2.1.11. CDNI URI Container (cdniuc) claim . . . . . . . . . . 14 2.1.11. CDNI URI Container (cdniuc) Claim
2.1.12. CDNI Expiration Time Setting (cdniets) claim . . . . 14 2.1.12. CDNI Expiration Time Setting (cdniets) Claim
2.1.13. CDNI Signed Token Transport (cdnistt) claim . . . . . 14 2.1.13. CDNI Signed Token Transport (cdnistt) Claim
2.1.14. CDNI Signed Token Depth (cdnistd) claim . . . . . . . 15 2.1.14. CDNI Signed Token Depth (cdnistd) Claim
2.1.15. URI Container Forms . . . . . . . . . . . . . . . . . 15 2.1.15. URI Container Forms
2.1.15.1. URI Hash Container (hash:) . . . . . . . . . . . 16 2.1.15.1. URI Hash Container (hash:)
2.1.15.2. URI Regular Expression Container (regex:) . . . 16 2.1.15.2. URI Regular Expression Container (regex:)
2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 16 2.2. JWT Header
3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 17 3. URI Signing Token Renewal
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Overview
3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 17 3.2. Signed Token Renewal Mechanism
3.2.1. Required Claims . . . . . . . . . . . . . . . . . . . 18 3.2.1. Required Claims
3.3. Communicating a signed JWTs in Signed Token Renewal . . . 18 3.3. Communicating a Signed JWTs in Signed Token Renewal
3.3.1. Support for cross-domain redirection . . . . . . . . 18 3.3.1. Support for Cross-Domain Redirection
4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 19 4. Relationship with CDNI Interfaces
4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 19 4.1. CDNI Control Interface
4.2. CDNI Footprint & Capabilities Advertisement Interface . . 19 4.2. CDNI Footprint & Capabilities Advertisement Interface
4.3. CDNI Request Routing Redirection Interface . . . . . . . 19 4.3. CDNI Request Routing Redirection Interface
4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 19 4.4. CDNI Metadata Interface
4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 21 4.5. CDNI Logging Interface
5. URI Signing Message Flow
5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 22 5.1. HTTP Redirection
5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 22 5.2. DNS Redirection
5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6.1. CDNI Payload Type
6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 28 6.1.1. CDNI UriSigning Payload Type
6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 28 6.2. CDNI Logging Record Type
6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 28 6.2.1. CDNI Logging Record Version 2 for HTTP
6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 29 6.3. CDNI Logging Field Names
6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 29 6.4. CDNI URI Signing Verification Code
6.4. CDNI URI Signing Verification Code . . . . . . . . . . . 30 6.5. CDNI URI Signing Signed Token Transport
6.5. CDNI URI Signing Signed Token Transport . . . . . . . . . 31 6.6. JSON Web Token Claims Registration
6.6. JSON Web Token Claims Registration . . . . . . . . . . . 32 6.6.1. Registry Contents
6.6.1. Registry Contents . . . . . . . . . . . . . . . . . . 32 6.7. Expert Review Guidance
6.7. Expert Review Guidance . . . . . . . . . . . . . . . . . 33 7. Security Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8. Privacy
8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. References
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 9.1. Normative References
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 9.2. Informative References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Signed URI Package Example
11.1. Normative References . . . . . . . . . . . . . . . . . . 35 A.1. Simple Example
11.2. Informative References . . . . . . . . . . . . . . . . . 37 A.2. Complex Example
Appendix A. Signed URI Package Example . . . . . . . . . . . . . 39 A.3. Signed Token Renewal Example
A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 40 Acknowledgements
A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 40 Contributors
A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 41 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of redirection used to provide access authorization in the case of redirection
between cooperating CDNs and between a Content Service Provider (CSP) between cooperating CDNs and between a Content Service Provider (CSP)
and a CDN. The primary goal of URI Signing is to make sure that only and a CDN. The primary goal of URI Signing is to make sure that only
authorized UAs are able to access the content, with a CSP being able authorized UAs are able to access the content, with a CSP being able
to authorize every individual request. It should be noted that URI to authorize every individual request. It should be noted that URI
Signing is not a content protection scheme; if a CSP wants to protect Signing is not a content protection scheme; if a CSP wants to protect
the content itself, other mechanisms, such as Digital Rights the content itself, other mechanisms, such as Digital Rights
Management (DRM), are more appropriate. In addition to access Management (DRM), are more appropriate. In addition to access
control, URI Signing also has benefits in reducing the impact of control, URI Signing also has benefits in reducing the impact of
denial-of-service attacks. 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 the CDNI Problem Statement [RFC6707] specification. This
CDNI Requirements [RFC7337] document and the CDNI Framework document, along with the Content Distribution Network Interconnection
[RFC7336], describes the need for interconnected CDNs to be able to (CDNI) Requirements [RFC7337] document and the Framework for Content
implement an access control mechanism that enforces a CSP's Distribution Network Interconnection (CDNI) [RFC7336], describes the
distribution policies. need for interconnected CDNs to be able to implement an access
control mechanism that enforces a CSP's distribution policies.
Specifically, the 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
delegating traffic to additional downstream CDNs, and to enforce delegating traffic to additional downstream CDNs, and to enforce
per-request authorization performed by the CSP using techniques per-request authorization performed by the CSP using techniques
such as URI Signing. such as URI Signing.
In particular, the following requirement is listed in the 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
authorization checks and verification that are to be performed by | of authorization checks and validation that are to be
the Surrogate before delivery. For example, this could | performed by the Surrogate before delivery. For example,
potentially include the need to verify information (e.g., Expiry | this could potentially include the need to validate
time, Client IP address) required for access authorization. | information (e.g., Expiry time, Client IP address) required
| for access authorization.
This document defines a method of signing URIs that allows Surrogates This document defines a method of signing URIs that allows Surrogates
in interconnected CDNs to enforce a per-request authorization in interconnected CDNs to enforce a per-request authorization
initiated by the CSP. Splitting the role of initiating per-request initiated by the CSP. Splitting the role of initiating per-request
authorization by the CSP and the role of verifying this authorization authorization by the CSP and the role of verifying this authorization
by the CDN allows any arbitrary distribution policy to be enforced by the CDN allows any arbitrary distribution policy to be enforced
across CDNs without the need of CDNs to have any awareness of the across CDNs without the need of CDNs to have any awareness of the
specific CSP distribution policies. specific CSP distribution policies.
The method is implemented using Signed JSON Web Tokens (JWTs) 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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 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 the CDNI Problem This document uses the terminology defined in the CDNI Problem
Statement [RFC6707]. Statement [RFC6707].
This document also uses the terminology of the 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:
* Signed URI: A URI for which a signed JWT is provided. Signed URI: A URI for which a signed JWT is provided.
* Target CDN URI: URI created by the CSP to direct a UA towards the Target CDN URI: A 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).
* Redirection URI: URI created by the uCDN to redirect a UA towards Redirection URI: A URI created by the uCDN to redirect a UA towards
the dCDN. The Redirection URI can be signed by the uCDN and the dCDN. The Redirection URI can be signed by the uCDN and
verified by the dCDN. In a cascaded CDNI scenario, there can be verified by the dCDN. In a cascaded CDNI scenario, there can be
more than one Redirection URI. more than one Redirection URI.
* Signed Token Renewal: A series of signed JWTs that are used for Signed Token Renewal: A series of signed JWTs that are used for
subsequent access to a set of related resources in a CDN, such as subsequent access to a set of related resources in a CDN, such as
a set of HTTP Adaptive Streaming files. Every time a signed JWT a set of HTTP Adaptive Streaming files. Every time a signed JWT
is used to access a particular resource, a new signed JWT is sent is used to access a particular resource, a new signed JWT is sent
along with the resource that can be used to request the next along with the resource that can be used to request the next
resource in the set. When generating a new signed JWT in Signed resource in the set. When generating a new signed JWT in Signed
Token Renewal, parameters are carried over from one signed JWT to Token Renewal, parameters are carried over from one signed JWT to
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, which is realized in the CSP to authorize access to a content item, which is realized in
practice by including a set of claims in a signed JWT in the URI practice by including a set of claims in a signed JWT in the URI
before redirecting a UA to the CDN. Using these attributes, it is before redirecting a UA to the CDN. Using these attributes, it is
possible for a CDN to check an incoming content request to see possible for a CDN to check an incoming content request to see
whether it was authorized by the CSP (e.g., based on a time window or whether it was authorized by the CSP (e.g., based on a time window or
pattern matching the URI). To prevent the UA from altering the pattern matching the URI). To prevent the UA from altering the
claims the JWT MUST be signed. claims, the JWT MUST be signed.
Figure 1, shown below, presents an overview of the URI Signing Figure 1 presents an overview of the URI Signing mechanism in the
mechanism in the case of a CSP with a single CDN. When the UA case of a CSP with a single CDN. When the UA browses for content on
browses for content on CSP's website (#1), it receives HTML web pages CSP's website (1), it receives HTML web pages with embedded content
with embedded content URIs. Upon requesting these URIs, the CSP URIs. Upon requesting these URIs, the CSP redirects to a CDN,
redirects to a CDN, creating a Target CDN URI (#2) (alternatively, creating a Target CDN URI (2) (alternatively, the Target CDN URI
the Target CDN URI itself is embedded in the HTML). The Target CDN itself is embedded in the HTML). The Target CDN URI is the Signed
URI is the Signed URI which may include the IP address of the UA and/ URI, which may include the IP address of the UA and/or a time window.
or a time window. The signed URI always contains a signed JWT The signed URI always contains a signed JWT generated by the CSP
generated by the CSP using a shared secret or private key. Once the using a shared secret or private key. Once the UA receives the
UA receives the response with the Signed URI, it sends a new HTTP response with the Signed URI, it sends a new HTTP request using the
request using the Signed URI to the CDN (#3). Upon receiving the Signed URI to the CDN (3). Upon receiving the request, the CDN
request, the CDN authenticates the Signed URI by verifying the signed authenticates the Signed URI by verifying the signed JWT. If
JWT. If applicable, the CDN checks whether the time window is still applicable, the CDN checks whether the time window is still valid in
valid in the Signed URI and the pattern matches the URI of the the Signed URI and the pattern matches the URI of the request. After
request. After these claims are verified, the CDN delivers the these claims are verified, the CDN delivers the content (4).
content (#4).
Note: While using a symmetric shared key is supported, it is NOT Note: While using a symmetric shared key is supported, it is NOT
RECOMMENDED. See the Security Considerations (Section 7) section RECOMMENDED. See the Security Considerations (Section 7) about the
about the limitations of shared keys. limitations of shared keys.
-------- --------
/ \ / \
| 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 32 skipping to change at line 261
| Agent| | CDN | | Agent| | CDN |
| |<-----------------\ / | |<-----------------\ /
+------+ 4. Content -------- +------+ 4. Content --------
Delivery Delivery
Figure 1: URI Signing in a CDN Environment Figure 1: URI Signing in a CDN Environment
1.3. CDNI URI Signing Overview 1.3. CDNI URI Signing Overview
In a CDNI environment, as shown in Figure 2 below, URI Signing In a CDNI environment, as shown in Figure 2 below, URI Signing
operates the same way in the initial steps #1 and #2, but the later operates the same way in the initial steps 1 and 2, but the later
steps involve multiple CDNs delivering the content. The main steps involve multiple CDNs delivering the content. The main
difference from the single CDN case is a redirection step between the difference from the single CDN case is a redirection step between the
uCDN and the dCDN. In step #3, the UA may send an HTTP request or a uCDN and the dCDN. In step 3, the UA may send an HTTP request or a
DNS request, depending on whether HTTP-based or DNS-based request DNS request, depending on whether HTTP-based or DNS-based request
routing is used. The uCDN responds by directing the UA towards the routing is used. The uCDN responds by directing the UA towards the
dCDN using either a Redirection URI (i.e., a Signed URI generated by dCDN using either a Redirection URI (i.e., a Signed URI generated by
the uCDN) or a DNS reply, respectively (#4). Once the UA receives the uCDN) or a DNS reply, respectively (4). Once the UA receives the
the response, it sends the Redirection URI/Target CDN URI to the dCDN response, it sends the Redirection URI/Target CDN URI to the dCDN
(#5). The received URI is verified by the dCDN before delivering the (5). The received URI is verified by the dCDN before delivering the
content (#6). Note: The CDNI call flows are covered in Detailed URI content (6).
Signing Operation (Section 5).
Note: The CDNI call flows are covered in URI Signing Message Flow
(Section 5).
+-------------------------+ +-------------------------+
|Request Redirection Modes| |Request Redirection Modes|
+-------------------------+ +-------------------------+
| a) HTTP | | a) HTTP |
| b) DNS | | b) DNS |
+-------------------------+ +-------------------------+
-------- --------
/ \< * * * * * * * * * * * * * * / \< * * * * * * * * * * * * * *
| CSP |< * * * * * * * * * * * * | CSP |< * * * * * * * * * * * *
skipping to change at page 8, line 23 skipping to change at line 336
For HTTP-based request routing, the Signed URI (i.e., the Target CDN For HTTP-based request routing, the Signed URI (i.e., the Target CDN
URI) 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 by the uCDN, the uCDN creates and signs a new Redirection verified by the uCDN, the uCDN creates and signs a new Redirection
URI, redirecting the UA to the dCDN. Since this new URI can have a URI, redirecting the UA to the dCDN. Since this new URI can have a
new signed JWT, the relationship between the dCDN and CSP is not new signed JWT, the relationship between the dCDN and CSP is not
relevant. Because a relationship between uCDN and dCDN always relevant. Because a relationship between uCDN and dCDN always
exists, either asymmetric public/private keys or symmetric shared exists, either asymmetric public/private keys or symmetric shared
secret keys can be used for URI Signing with HTTP-based request secret keys can be used for URI Signing with HTTP-based request
routing. Note that the signed Redirection URI MUST maintain HTTPS as routing. Note that the signed Redirection URI MUST maintain HTTPS as
the scheme if it was present in the original and it MAY be upgraded the scheme if it was present in the original, and it MAY be upgraded
from http: to https:. from "http:" to "https:".
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 shared keys. Asymmetric keys are based on a public/private symmetric shared keys. Asymmetric keys are based on a public/private
key pair mechanism and always contain a private key known only to the key 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 and the verifying used by both the signing entity for signing the URI and the verifying
entity for verifying the Signed URI. Regardless of the type of keys entity for verifying the Signed URI. Regardless of the type of keys
used, the verifying entity has to obtain the key in a manner that used, the verifying entity has to obtain the key in a manner that
allows trust to be placed in the assertions made using that key allows trust to be placed in the assertions made using that key
skipping to change at page 8, line 46 skipping to change at line 359
requirements (outside the scope of this document) for distributing requirements (outside the scope of this document) for distributing
asymmetric keys and symmetric keys. Key distribution for symmetric asymmetric keys and symmetric keys. Key distribution for symmetric
keys requires confidentiality to prevent third parties from getting keys requires confidentiality to prevent third parties from getting
access to the key, since they could then generate valid Signed URIs access to the key, since they could then generate valid Signed URIs
for unauthorized requests. Key distribution for asymmetric keys does for unauthorized requests. Key distribution for asymmetric keys 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 to sign URIs) and the distributed openly (because they cannot be used to sign URIs) and the
corresponding private keys are kept secret by the URI signer. corresponding private keys are kept secret by the URI signer.
Note: While using a symmetric shared key is supported, it is NOT Note: While using a symmetric shared key is supported, it is NOT
RECOMMENDED. See the Security Considerations (Section 7) section RECOMMENDED. See the Security Considerations (Section 7) about the
about the limitations of shared keys. limitations of shared keys.
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,
i.e., between a uCDN and a dCDN, there is nothing in the defined URI i.e., between a uCDN and a dCDN, there is nothing in the defined URI
Signing method that precludes it from being used in a non-CDNI Signing method that precludes it from being used in a non-CDNI
context. As such, the described mechanism could be used in a single- context. As such, the described mechanism could be used in a single-
CDN scenario such as shown in Figure 1 in Section 1.2, for example to CDN scenario such as shown in Figure 1 in Section 1.2 for example to
allow a CSP that uses different CDNs to only have to implement a allow a CSP that uses different CDNs to 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] (see Web Token (JWT) [RFC7519] in an HTTP or HTTPS URI [RFC7230] (see
[RFC7230] Section 2.7). The signed JWT contains a number of claims Section 2.7 of [RFC7230]). The signed JWT contains a number of
that can be verified to ensure the UA has legitimate access to the claims that can be verified to ensure the UA has legitimate access to
content. 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:
* URI Signing Package (URISigningPackage): The URI attribute that 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 path- format. This attribute is exposed in the Signed URI as a path-
style parameter or a form-style parameter. style parameter or a form-style parameter.
The parameter name of the URI Signing Package Attribute is defined in The parameter name of the URI Signing Package Attribute is defined in
the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is
not used, or does not include a parameter name for the URI Signing not used, or does not include a parameter name for the URI Signing
Package Attribute, the parameter name can be set by configuration Package Attribute, the parameter name can be set by configuration
(out of scope of this document). (out of scope of this document).
skipping to change at page 10, line 21 skipping to change at line 426
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 parentheses below) are used to enforce the claim name is specified in parentheses 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 necessarily implement in a URI Signing implementation but are not necessarily
mandatory to use in a given signed JWT. (The "optional" and mandatory to use in a given signed JWT. (The "optional" and
"mandatory" identifiers in square brackets refer to whether or not a "mandatory" identifiers in square brackets refer to whether or not a
given claim MUST be present in a URI Signing JWT.) given claim MUST be present in a URI Signing JWT.)
Note: The time on the entities that generate and verify the signed Note: The time on the entities that generate and verify the signed
URI MUST be in sync. In the CDNI case, this means that CSP, uCDN, URI MUST be in sync. In the CDNI case, this means that CSP, uCDN,
and dCDN servers need to be time-synchronized. It is RECOMMENDED to and dCDN servers need to be time synchronized. It is RECOMMENDED to
use NTP [RFC5905] for time synchronization. use NTP [RFC5905] for time synchronization.
Note: See the Security Considerations (Section 7) section on the Note: See the Security Considerations (Section 7) on the limitations
limitations of using an expiration time and client IP address for of using an expiration time and Client IP address for distribution
distribution policy enforcement. 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 Section 4.1.1 of [RFC7519]
MUST be followed. If this claim is used, it MUST be used to identify MUST be followed. If this claim is used, it MUST be used to identify
the issuer (signer) of the JWT. In particular, the recipient will the issuer (signer) of the JWT. In particular, the recipient will
have already received, in trusted configuration, a mapping of issuer have already received, in trusted configuration, a mapping of issuer
name to one or more keys used to sign JWTs, and must verify that the name to one or more keys used to sign JWTs and must verify that the
JWT was signed by one of those keys. If this claim is used and the JWT was signed by one of those keys. If this claim is used and the
CDN verifying the signed JWT does not support Issuer verification, or CDN verifying the signed JWT does not support Issuer verification, or
if the Issuer in the signed JWT does not match the list of known if the Issuer in the signed JWT does not match the list of known
acceptable Issuers, or if the Issuer claim does not match the key acceptable Issuers, or if the Issuer claim does not match the key
used to sign the JWT, the CDN MUST reject the request. If the used to sign the JWT, the CDN MUST reject the request. If the
received signed JWT contains an Issuer claim, then any JWT received signed JWT contains an Issuer claim, then any JWT
subsequently generated for CDNI redirection MUST also contain an subsequently generated for CDNI redirection MUST also contain an
Issuer claim, and the Issuer value MUST be updated to identify the Issuer claim, and the Issuer value MUST be updated to identify the
redirecting CDN. If the received signed JWT does not contain an redirecting CDN. If the received signed JWT does not contain an
Issuer claim, an Issuer claim MAY be added to a signed JWT generated Issuer claim, an Issuer claim MAY be added to a signed JWT generated
for CDNI redirection. 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 Section 4.1.2 of
MUST be followed. If this claim is used, it MUST be a JSON Web [RFC7519] MUST be followed. If this claim is used, it MUST be a JSON
Encryption (JWE [RFC7516]) Object in compact serialization form, Web 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 verify 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 Section 4.1.3 of
MUST be followed. This claim is used to ensure that the CDN [RFC7519] MUST be followed. This claim is used to ensure that the
verifying the JWT is an intended recipient of the request. The claim CDN verifying the JWT is an intended recipient of the request. The
MUST contain an identity belonging to the chain of entities involved claim MUST contain an identity belonging to the chain of entities
in processing the request (e.g., identifying the CSP or any CDN in involved in processing the request (e.g., identifying the CSP or any
the chain) that the recipient is configured to use for the processing CDN in the chain) that the recipient is configured to use for the
of this request. A CDN MAY modify the claim as long it can generate processing of this request. A CDN MAY modify the claim as long it
a valid signature. 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 Section 4.1.4 of
Section 4.1.4 MUST be followed, though URI Signing implementations [RFC7519] MUST be followed, though URI Signing implementations MUST
MUST NOT allow for any time synchronization "leeway". If this claim NOT allow for any time-synchronization "leeway". If this claim is
is used and the CDN verifying the signed JWT does not support Expiry used and the CDN verifying the signed JWT does not support Expiry
Time verification, or if the Expiry Time in the signed JWT Time verification, or if the Expiry Time in the signed JWT
corresponds to a time equal to or earlier than the time of the corresponds to a time equal to or earlier than the time of the
content request, the CDN MUST reject the request. If the received content request, the CDN MUST reject the request. If the received
signed JWT contains an Expiry Time claim, then any JWT subsequently signed JWT contains an Expiry Time claim, then any JWT subsequently
generated for CDNI redirection MUST also contain an Expiry Time generated for CDNI redirection MUST also contain an Expiry Time
claim, and the Expiry Time value MUST be the same as in the received claim, and the Expiry Time value MUST be the same as in the received
signed JWT. A signed JWT generated for CDNI redirection MUST NOT add signed JWT. A signed JWT generated for CDNI redirection MUST NOT add
an Expiry Time claim if no Expiry Time claim existed in the received an Expiry Time claim if no Expiry Time claim existed in the received
signed JWT. signed JWT.
2.1.5. Not Before (nbf) claim 2.1.5. Not Before (nbf) Claim
Not Before (nbf) [optional] - The semantics in [RFC7519] Not Before (nbf) [optional] - The semantics in Section 4.1.5 of
Section 4.1.5 MUST be followed, though URI Signing implementations [RFC7519] MUST be followed, though URI Signing implementations MUST
MUST NOT allow for any time synchronization "leeway". If this claim NOT allow for any time-synchronization "leeway". If this claim is
is used and the CDN verifying the signed JWT does not support Not used and the CDN verifying the signed JWT does not support Not Before
Before time verification, or if the Not Before time in the signed JWT time verification, or if the Not Before time in the signed JWT
corresponds to a time later than the time of the content request, the corresponds to a time later than the time of the content request, the
CDN MUST reject the request. If the received signed JWT contains a CDN MUST reject the request. If the received signed JWT contains a
Not Before time claim, then any JWT subsequently generated for CDNI Not Before time claim, then any JWT subsequently generated for CDNI
redirection MUST also contain a Not Before time claim, and the Not redirection MUST also contain a Not Before time claim, and the Not
Before time value MUST be the same as in the received signed JWT. A Before time value MUST be the same as in the received signed JWT. A
signed JWT generated for CDNI redirection MUST NOT add a Not Before signed JWT generated for CDNI redirection MUST NOT add a Not Before
time claim if no Not Before time claim existed in the received signed time claim if no Not Before time claim existed in the received signed
JWT. 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 Section 4.1.6 of
MUST be followed. If the received signed JWT contains an Issued At [RFC7519] MUST be followed. If the received signed JWT contains an
claim, then any JWT subsequently generated for CDNI redirection MUST Issued At claim, then any JWT subsequently generated for CDNI
also contain an Issued At claim, and the Issued At value MUST be redirection MUST also contain an Issued At claim, and the Issued At
updated to identify the time the new JWT was generated. If the value MUST be updated to identify the time the new JWT was generated.
received signed JWT does not contain an Issued At claim, an Issued At If the received signed JWT does not contain an Issued At claim, an
claim MAY be added to a signed JWT generated for CDNI redirection. Issued At claim MAY be added to a signed JWT generated for CDNI
redirection.
2.1.7. JWT ID (jti) claim 2.1.7. JWT ID (jti) Claim
JWT ID (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 JWT ID (jti) [optional] - The semantics in Section 4.1.7 of [RFC7519]
MUST be followed. A JWT ID can be used to prevent replay attacks if MUST be followed. A JWT ID can be used to prevent replay attacks if
the CDN stores a list of all previously used values, and verifies the CDN stores a list of all previously used values and verifies that
that the value in the current JWT has never been used before. If the the value in the current JWT has never been used before. If the
signed JWT contains a JWT ID claim and the CDN verifying the signed signed JWT contains a JWT ID claim and the CDN verifying the signed
JWT either does not support JWT ID storage or has previously seen the JWT either does not support JWT ID storage or has previously seen the
value used in a request for the same content, then the CDN MUST value used in a request for the same content, then the CDN MUST
reject the request. If the received signed JWT contains a JWT ID reject the request. If the received signed JWT contains a JWT ID
claim, then any JWT subsequently generated for CDNI redirection MUST claim, then any JWT subsequently generated for CDNI redirection MUST
also contain a JWT ID claim, and the value MUST be the same as in the also contain a JWT ID claim, and the value MUST be the same as in the
received signed JWT. If the received signed JWT does not contain a received signed JWT. If the received signed JWT does not contain a
JWT ID claim, a JWT ID claim MUST NOT be added to a signed JWT JWT ID claim, a JWT ID claim MUST NOT be added to a signed JWT
generated for CDNI redirection. Sizing of the JWT ID is application generated for CDNI redirection. Sizing of the JWT ID is application
dependent given the desired security constraints. dependent given the desired security constraints.
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 this specification. The cdniv claim set to a specific version of this specification. The cdniv
claim is 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 a 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
this claim, the value is assumed to be "1". For future versions 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 CDNI Critical CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical
Claims Set (cdnicrit) claim indicates that extensions to this Claims Set (cdnicrit) claim indicates that extensions to this
specification are being used that MUST be understood and processed. specification are being used that MUST be understood and processed.
Its value is a comma separated listing of claims in the Signed JWT Its value is a comma-separated listing of claims in the Signed JWT
that use those extensions. If any of the listed extension claims are that use those extensions. If any of the listed extension claims are
not understood and supported by the recipient, then the Signed JWT not understood and supported by the recipient, then the Signed JWT
MUST be rejected. Producers MUST NOT include claim names defined by MUST be rejected. Producers MUST NOT include claim names defined by
this specification, duplicate names, or names that do not occur as this specification, duplicate names, or names that do not occur as
claim names within the Signed JWT in the cdnicrit list. Producers claim names within the Signed JWT in the cdnicrit list. Producers
MUST NOT use the empty list "" as the cdnicrit value. Recipients MAY MUST NOT use the empty list "" as the cdnicrit value. Recipients MAY
consider the Signed JWT to be invalid if the cdnicrit list contains consider the Signed JWT to be invalid if the cdnicrit list contains
any claim names defined by this specification or if any other any claim names defined by this specification or if any other
constraints on its use are violated. This claim MUST be understood constraints on its use are violated. This claim MUST be understood
and processed by all implementations. and processed by all implementations.
2.1.10. Client IP Address (cdniip) claim 2.1.10. Client IP Address (cdniip) Claim
Client IP Address (cdniip) [optional] - The Client IP Address Client IP Address (cdniip) [optional] - The Client IP Address
(cdniip) claim holds an IP address or IP prefix for which the Signed (cdniip) claim holds an IP address or IP prefix for which the Signed
URI is valid. This is represented in CIDR notation, with dotted URI is valid. This is represented in CIDR notation with dotted
decimal format for IPv4 addresses [RFC0791] or canonical text decimal format for IPv4 addresses [RFC0791] or canonical text
representation for IPv6 addresses [RFC5952]. The request MUST be representation for IPv6 addresses [RFC5952]. The request MUST be
rejected if sourced from a client outside the specified IP range. rejected if sourced from a client outside the specified IP range.
Since the client IP is considered personally identifiable information Since the Client IP is considered personally identifiable
this field MUST be a JSON Web Encryption (JWE [RFC7516]) Object in information, this field MUST be a JSON Web Encryption (JWE [RFC7516])
compact serialization form. If the CDN verifying the signed JWT does Object in compact serialization form. If the CDN verifying the
not support Client IP verification, or if the Client IP in the signed signed JWT does not support Client IP verification, or if the Client
JWT does not match the source IP address in the content request, the IP in the signed JWT does not match the source IP address in the
CDN MUST reject the request. The type of this claim is a JSON string content request, the CDN MUST reject the request. The type of this
that contains the JWE. If the received signed JWT contains a Client claim is a JSON string that contains the JWE. If the received signed
IP claim, then any JWT subsequently generated for CDNI redirection JWT contains a Client IP claim, then any JWT subsequently generated
MUST also contain a Client IP claim, and the Client IP value MUST be for CDNI redirection MUST also contain a Client IP claim, and the
the same as in the received signed JWT. A signed JWT generated for Client IP value MUST be the same as in the received signed JWT. A
CDNI redirection MUST NOT add a Client IP claim if no Client IP claim signed JWT generated for CDNI redirection MUST NOT add a Client IP
existed in the received signed JWT. claim if no Client IP claim existed in the received signed JWT.
It should be noted that use of this claim can cause issues, for It should be noted that use of this claim can cause issues, for
example, in situations with dual-stack IPv4 and IPv6 networks, MPTCP, example, in situations with dual-stack IPv4 and IPv6 networks, MPTCP,
QUIC, and mobile clients switching from Wi-Fi to Cellular networks QUIC, and mobile clients switching from Wi-Fi to Cellular networks
where the client's source address can change, even between address where the client's source address can change, even between address
families. This claim exists mainly for legacy feature parity families. This claim exists mainly for legacy feature parity
reasons, therefore use of this claim should be done judiciously. An reasons; therefore, use of this claim should be done judiciously. An
example of a reasonable use case would be making a signed JWT for an example of a reasonable use case would be making a signed JWT for an
internal preview of an asset where the end consumer understands that internal preview of an asset where the end consumer understands that
they must be originated from the same IP for the entirety of the they must be originated from the same IP for the entirety of the
session. Using this claim at large is NOT RECOMMENDED. session. Using this claim at large is NOT RECOMMENDED.
2.1.11. CDNI URI Container (cdniuc) claim 2.1.11. CDNI URI Container (cdniuc) Claim
URI Container (cdniuc) [mandatory] - The URI Container (cdniuc) holds URI Container (cdniuc) [mandatory] - The URI Container (cdniuc) holds
the URI 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 Container used in the signed JWT does not Section 2.1.15. If the URI Container used in the signed JWT does not
match the URI of the content request, the CDN verifying the signed match the URI of the content request, the CDN verifying the signed
JWT MUST reject the request. When comparing the URI, the percent JWT MUST reject the request. When comparing the URI, the percent
encoded form as defined in [RFC3986] Section 2.1 MUST be used. When encoded form as defined in Section 2.1 of [RFC3986] MUST be used.
redirecting a URI, the CDN generating the new signed JWT MAY change When redirecting a URI, the CDN generating the new signed JWT MAY
the URI Container to comport with the URI being used in the change 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 verified 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 signaling 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 are defined in type is a JSON integer. Values for this claim are defined in
Section 6.5. If using this claim you MUST also specify a CDNI Section 6.5. 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 generated as the result of a CDNI Signed Token Transport claim, with
a 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 CDN SHOULD send the client a token to greater than zero, then the CDN SHOULD send the client a token to
return for future requests wherein the first CDNI Signed Token Depth return for future requests wherein the first CDNI Signed Token Depth
segments of the path match the first CDNI Signed Token Depth segments segments of the path match the first CDNI Signed Token Depth segments
of the signed URI path. This matching MUST use the URI with the of the signed URI path. This matching MUST use the URI with the
token removed, as specified in Section 2.1.15. token removed, as specified in Section 2.1.15.
skipping to change at page 16, line 9 skipping to change at line 683
'hash:' or 'regex:'. More forms may be added in the future to extend 'hash:' or 'regex:'. More forms may be added in the future to extend
the capabilities. the capabilities.
Before comparing a URI with contents of this container, the following Before comparing a URI with contents of this container, the following
steps MUST be performed: steps MUST be performed:
* Prior to verification, remove the signed JWT from the URI. This * 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 defined is terminated by anything other than a sub-delimiter (as defined
in [RFC3986] Section 2.2), everything from the reserved character in Section 2.2 of [RFC3986]), everything from the reserved
(as defined in [RFC3986] Section 2.2) that precedes the URI character (as defined in Section 2.2 of [RFC3986]) that precedes
Signing Package Attribute to the last character of the signed JWT the URI Signing Package Attribute to the last character of the
will be removed, inclusive. Otherwise, everything from the first signed JWT will be removed, inclusive. Otherwise, everything from
character of the URI Signing Package Attribute to the sub- the first character of the URI Signing Package Attribute to the
delimiter that terminates the signed JWT will be removed, sub-delimiter that terminates the signed JWT will be removed,
inclusive. inclusive.
* Normalize the URI according to section 2.7.3 [RFC7230] and * Normalize the URI according to Section 2.7.3 of [RFC7230] and
sections 6.2.2 and 6.2.3 [RFC3986]. This applies to both Sections 6.2.2 and 6.2.3 of [RFC3986]. This applies to both
generation and verification 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 (Section 5
Section 5) of the URI. of [RFC6920]) 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 Section 9 [POSIX.1] Prefixed with 'regex:', this string is any regular expression
Extended Regular Expression compatible regular expression used to compatible with POSIX (Section 9 of [POSIX.1]) Extended Regular
match against the requested URI. These regular expressions MUST be Expression used to match against the requested URI. These regular
evaluated in the POSIX locale (POSIX Section 7.2 [POSIX.1]). expressions MUST be evaluated in the POSIX locale (Section 7.2 of
[POSIX.1]).
Note: Because '\' has special meaning in JSON [RFC8259] 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 verifying 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
skipping to change at page 17, line 21 skipping to change at line 744
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
a vulnerability to 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
to be consumed in real time. For instance, if the manifest file were to be consumed in real time. For instance, if the manifest file were
to contain a segmented video stream of more than 30 minutes in to contain a segmented video stream of more than 30 minutes in
length, Signed URIs would require to be valid for at least 30 length, Signed URIs would require to be valid for at least 30
minutes, thereby reducing their effectiveness and that of the URI minutes, thereby reducing their effectiveness and that of the URI
Signing mechanism in general. For a more detailed analysis of how Signing mechanism in general. For a more detailed analysis of how
segmented protocols such as HTTP Adaptive Streaming protocols affect segmented protocols such as HTTP Adaptive Streaming protocols affect
CDNI, see Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. CDNI, see Models for HTTP-Adaptive-Streaming-Aware Content
Distribution Network Interconnection (CDNI) [RFC6983].
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 verification 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 verified 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 is outside the scope of exact mechanism by which the client does this is outside the scope of
skipping to change at page 18, line 33 skipping to change at line 806
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 for Signed Token Renewal. cdnistt MAY be set to MUST both be present for Signed Token Renewal. cdnistt MAY be set to
a value of '0' to mean no Signed Token Renewal, but there still MUST a value of '0' to mean no Signed Token Renewal, but there still MUST
be a corresponding cdniets that verifies as a JSON number. However, be a corresponding cdniets that verifies as a JSON number. However,
if use of Signed Token Renewal is not desired, it is RECOMMENDED to if use of Signed Token Renewal is not desired, it is RECOMMENDED to
simply omit both. 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. (cdnistt) claim has been set to 1.
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 based method for transport of the Signed Token described in
Section 3.3 might break if used in combination with an HTTP 3xx Section 3.3 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 the value of the CDNI Signed Token Transport communicated. Note the value of the CDNI Signed Token Transport
skipping to change at page 19, line 36 skipping to change at line 857
the logs communicated through the CDNI Logging interface. the logs communicated through 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 registered
registered in Section 6.1 can be used for capability advertisement. in Section 6.1 can be used for capability advertisement.
4.3. CDNI Request Routing Redirection Interface 4.3. CDNI Request Routing Redirection Interface
The CDNI Request Routing Redirection Interface [RFC7975] describes The CDNI Request Routing Redirection Interface [RFC7975] describes
the recursive request redirection method. For URI Signing, the uCDN the recursive request redirection method. For URI Signing, the uCDN
signs the URI provided by the dCDN. URI Signing therefore has no signs the URI provided by the dCDN. URI Signing therefore 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 verification 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
is signed and verified before delivering content. Otherwise, URI is signed and verified before delivering content.
the dCDN does not perform verification, regardless of whether Otherwise, the dCDN does not perform verification,
or not the URI is signed. regardless of whether 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 cross-referenced. claim in the signed JWT may be cross-referenced.
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 in the trusted key store of empty list means that any Issuer in the trusted key store of
issuers is acceptable. issuers is acceptable.
Property: package-attribute Property: package-attribute
Description: The attribute name to use for the URI Signing Description: The attribute name to use for the URI Signing
Package. Package.
Type: String Type: String
Mandatory-to-Specify: No. The 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 verifying Description: The header part of JWT that is used for verifying
a signed JWT when the JWT token in the URI Signing Package does a signed JWT when the JWT token in the URI Signing Package
not contain a header part. does not contain a header part.
Type: String Type: String
Mandatory-to-Specify: No. By default, the header is assumed to Mandatory-to-Specify: No. By default, the header is assumed
be included in the JWT token. to 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
skipping to change at page 21, line 39 skipping to change at line 955
} }
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 "Content
Interface [RFC7937], using the new "cdni_http_request_v2" record-type Distribution Network Interconnection (CDNI) Logging Interface"
registered in Section 6.2.1. [RFC7937] using the new "cdni_http_request_v2" record-type registered
in Section 6.2.1.
* s-uri-signing (mandatory): * s-uri-signing (mandatory):
- format: 3DIGIT Format: 3DIGIT
- field value: this characterises the URI Signing verification Field value: this characterizes 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 registered in Section 6.4. are registered in Section 6.4.
- occurrence: there MUST be zero or exactly one instance of this Occurrence: there MUST be zero or exactly one instance of this
field. field.
* s-uri-signing-deny-reason (optional): * s-uri-signing-deny-reason (optional):
- format: QSTRING Format: QSTRING
- field value: a string for providing further information in case Field value: a string for providing further information in case
the signed JWT was rejected, e.g., for debugging purposes. the signed JWT was rejected, e.g., for debugging purposes.
- occurrence: there MUST be zero or exactly one instance of this Occurrence: there MUST be zero or exactly one instance of this
field. field.
5. URI Signing Message Flow 5. URI Signing Message Flow
URI Signing supports both HTTP-based and DNS-based request routing. URI Signing supports both HTTP-based and DNS-based request routing.
JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of
representing claims to be transferred between two parties. The representing claims to be transferred between two parties. The
claims in a Signed JWT are encoded as a JSON object that is used as claims in a Signed JWT are encoded as a JSON object that is used as
the payload of a JSON Web Signature (JWS) structure enabling the the payload of a JSON Web Signature (JWS) structure enabling the
claims to be digitally signed or integrity protected with a Message claims to be digitally signed or integrity protected with a Message
skipping to change at page 23, line 4 skipping to change at line 1016
| advertise URI Signing capability| | | advertise URI Signing capability| |
| |------------------->| | | |------------------->| |
| | | | | | | |
| 2.Provides information to verify 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) : : : : (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 | | |
|---------------------------------------->| [Verifiy URI | |---------------------------------------->| [Verify URI |
| | | signature] | | | | signature] |
| | | | | | | |
| | (ALT: Verification 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) | |
|<----------------------------------------| | |<----------------------------------------| |
| | | | | | | |
skipping to change at page 23, line 45 skipping to change at line 1056
|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 3: 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 verify signed 2. CSP provides to the uCDN the information needed to verify signed
URIs from that CSP. For example, this information will include URIs from that CSP. For example, this information will include
one or more keys used for validation. one or more keys used for validation.
3. Using the CDNI Metadata interface, the uCDN communicates to a 3. Using the CDNI Metadata interface, the uCDN communicates to a
skipping to change at page 25, line 14 skipping to change at line 1118
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.
Note: While using a symmetric shared key is supported, it is NOT Note: While using a symmetric shared key is supported, it is NOT
RECOMMENDED. See the Security Considerations (Section 7) section RECOMMENDED. See the Security Considerations (Section 7) about the
about the limitations of shared keys. limitations of shared keys.
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 required, then the distribution SHOULD be shared secret key is required, then the distribution SHOULD be
performed by the CSP directly. performed by the CSP directly.
Note: While using a symmetric shared key is supported, it is NOT Note: While using a symmetric shared key is supported, it is NOT
RECOMMENDED. See the Security Considerations (Section 7) section RECOMMENDED. See the Security Considerations (Section 7) about the
about the limitations of shared keys. limitations of shared keys.
The URI Signing method (assuming iterative DNS request routing and a The URI Signing method (assuming iterative DNS request routing and a
CDN path with two CDNs) includes the following steps. CDN path with two CDNs) includes the following steps.
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| |
| |------------------->| | | |------------------->| |
| | | | | | | |
skipping to change at page 27, line 18 skipping to change at line 1218
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 JWT that is based on unique parameters of that request Signed JWT that is based on unique parameters of that request
and includes it in the URI provided to the end user to request and includes it in the URI provided to the end user to request
the content. the content.
7. End user sends DNS request to the uCDN. 7. The end user sends a 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. The end user sends a 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
verifies the Signed JWT in the URI using the information verifies the Signed JWT in the URI using the information
provided by the uCDN in the CDNI Metadata. provided by the uCDN in the CDNI Metadata.
12. If the verification result is negative, the dCDN rejects the 12. If the verification result is negative, the dCDN rejects the
request and sends an error code 403 Forbidden in the HTTP request and sends an error code 403 Forbidden in the HTTP
skipping to change at page 27, line 51 skipping to change at line 1251
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.
With DNS-based request routing, URI Signing does not match well with With DNS-based request routing, URI Signing does not match well with
the general chain of trust model of CDNI when used with symmetric the general chain of trust model of CDNI when used with symmetric
keys because the symmetric key information needs to be distributed keys because the symmetric key information needs to be distributed
across multiple CDNI hops, to CDNs with which the CSP may not have a across multiple CDNI hops to CDNs with which the CSP may not have a
trust relationship. This raises a security concern for applicability trust relationship. This raises a security concern for applicability
of URI Signing with symmetric keys in case of DNS-based inter-CDN of URI Signing with symmetric keys in case of DNS-based inter-CDN
request routing. Due to these flaws, this architecture MUST NOT be request routing. Due to these flaws, this architecture MUST NOT be
implemented. implemented.
Note: While using a symmetric shared key is supported, it is NOT Note: While using a symmetric shared key is supported, it is NOT
RECOMMENDED. See the Security Considerations (Section 7) section RECOMMENDED. See the Security Considerations (Section 7) about the
about the limitations of shared keys. limitations of shared keys.
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 IANA has registered the following CDNI Payload Type under the IANA
Type under the IANA "CDNI Payload Types" registry: "CDNI Payload Types" registry:
+===============+===============+ +===============+===============+
| Payload Type | Specification | | Payload Type | Specification |
+===============+===============+ +===============+===============+
| MI.UriSigning | RFCthis | | MI.UriSigning | RFC 9246 |
+---------------+---------------+ +---------------+---------------+
Table 1 Table 1
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
6.1.1. CDNI UriSigning Payload Type 6.1.1. CDNI UriSigning Payload Type
Purpose: The purpose of this payload type is to distinguish Purpose: The purpose of this payload type is to distinguish
UriSigning MI objects (and any associated capability advertisement). UriSigning Metadata interface (MI) objects (and any associated
capability advertisement).
Interface: MI/FCI Interface: MI/FCI
Encoding: see Section 4.4 Encoding: see Section 4.4
6.2. CDNI Logging Record Type 6.2. CDNI Logging Record Type
This document requests the registration of the following CDNI Logging IANA has registered the following CDNI Logging record-type under the
record-type under the IANA "CDNI Logging record-types" registry: IANA "CDNI Logging record-types" registry:
+======================+===========+===========================+ +======================+===========+===========================+
| record-types | Reference | Description | | record-types | Reference | Description |
+======================+===========+===========================+ +======================+===========+===========================+
| cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | | cdni_http_request_v2 | RFC 9246 | Extension to CDNI Logging |
| | | Record version 1 for | | | | Record version 1 for |
| | | content delivery using | | | | content delivery using |
| | | HTTP, to include URI | | | | HTTP, to include URI |
| | | Signing logging fields | | | | Signing Logging fields |
+----------------------+-----------+---------------------------+ +----------------------+-----------+---------------------------+
Table 2 Table 2
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
6.2.1. CDNI Logging Record Version 2 for HTTP 6.2.1. CDNI Logging Record Version 2 for HTTP
The "cdni_http_request_v2" record-type supports all of the fields The "cdni_http_request_v2" record-type supports all of the fields
supported by the "cdni_http_request_v1" record-type [RFC7937] plus supported by the "cdni_http_request_v1" record-type [RFC7937] plus
the two additional fields "s-uri-signing" and "s-uri-signing-deny- the two additional fields "s-uri-signing" and "s-uri-signing-deny-
reason", registered by this document in Section 6.3. The name, reason", registered by this document in Section 6.3. The name,
format, field value, and occurence information for the two new fields format, field value, and occurrence information for the two new
can be found in Section 4.5 of this document. fields can be found in Section 4.5 of this document.
6.3. CDNI Logging Field Names 6.3. CDNI Logging Field Names
This document requests the registration of the following CDNI Logging IANA has registered the following CDNI Logging fields under the IANA
fields under the IANA "CDNI Logging Field Names" registry: "CDNI Logging Field Names" registry:
+===========================+===========+ +===========================+===========+
| Field Name | Reference | | Field Name | Reference |
+===========================+===========+ +===========================+===========+
| s-uri-signing | RFCthis | | s-uri-signing | RFC 9246 |
+---------------------------+-----------+ +---------------------------+-----------+
| s-uri-signing-deny-reason | RFCthis | | s-uri-signing-deny-reason | RFC 9246 |
+---------------------------+-----------+ +---------------------------+-----------+
Table 3 Table 3
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
6.4. CDNI URI Signing Verification Code 6.4. CDNI URI Signing Verification Code
The IANA is requested to create a new "CDNI URI Signing Verification IANA has created a new "CDNI URI Signing Verification Code"
Code" subregistry, in the "Content Delivery Networks Interconnection subregistry in the "Content Delivery Networks Interconnection (CDNI)
(CDNI) Parameters" registry. The "CDNI URI Signing Verification Parameters" registry. The "CDNI URI Signing Verification Code"
Code" namespace defines the valid values associated with the s-uri- namespace defines the valid values associated with the s-uri-signing
signing CDNI Logging Field. The CDNI URI Signing Verification Code CDNI Logging field. The CDNI URI Signing Verification Code is a
is a 3DIGIT value as defined in Section 4.5. Additions to the CDNI 3DIGIT value as defined in Section 4.5. Additions to the CDNI URI
URI Signing Verification Code namespace will conform to the Signing Verification Code namespace will conform to the
"Specification Required" policy as defined in [RFC8126]. Updates to "Specification Required" policy as defined in [RFC8126]. Updates to
this subregistry are expected to be infrequent. this subregistry are expected to be infrequent.
+=======+===========+=====================================+ +=======+===========+=====================================+
| Value | Reference | Description | | Value | Reference | Description |
+=======+===========+=====================================+ +=======+===========+=====================================+
| 000 | RFCthis | No signed JWT verification | | 000 | RFC 9246 | No signed JWT verification |
| | | performed | | | | performed |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 200 | RFCthis | Signed JWT verification performed | | 200 | RFC 9246 | Signed JWT verification performed |
| | | and verified | | | | and verified |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 400 | RFCthis | Signed JWT verification performed | | 400 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of incorrect | | | | and rejected because of incorrect |
| | | signature | | | | signature |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 401 | RFCthis | Signed JWT verification performed | | 401 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Issuer | | | | and rejected because of Issuer |
| | | enforcement | | | | enforcement |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 402 | RFCthis | Signed JWT verification performed | | 402 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Subject | | | | and rejected because of Subject |
| | | enforcement | | | | enforcement |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 403 | RFCthis | Signed JWT verification performed | | 403 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Audience | | | | and rejected because of Audience |
| | | enforcement | | | | enforcement |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 404 | RFCthis | Signed JWT verification performed | | 404 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Expiration | | | | and rejected because of Expiration |
| | | Time enforcement | | | | Time enforcement |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 405 | RFCthis | Signed JWT verification performed | | 405 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Not Before | | | | and rejected because of Not Before |
| | | enforcement | | | | enforcement |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 406 | RFCthis | Signed JWT verification performed | | 406 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because only one of | | | | and rejected because only one of |
| | | CDNI Signed Token Transport or CDNI | | | | CDNI Signed Token Transport or CDNI |
| | | Expiration Time Setting present. | | | | Expiration Time Setting present |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 407 | RFCthis | Signed JWT verification performed | | 407 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of JWT ID | | | | and rejected because of JWT ID |
| | | enforcement | | | | enforcement |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 408 | RFCthis | Signed JWT verification performed | | 408 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Version | | | | and rejected because of Version |
| | | enforcement | | | | enforcement |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 409 | RFCthis | Signed JWT verification performed | | 409 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Critical | | | | and rejected because of Critical |
| | | Extension enforcement | | | | Extension enforcement |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 410 | RFCthis | Signed JWT verification performed | | 410 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Client IP | | | | and rejected because of Client IP |
| | | enforcement | | | | enforcement |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 411 | RFCthis | Signed JWT verification performed | | 411 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of URI | | | | and rejected because of URI |
| | | Container enforcement | | | | Container enforcement |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
| 500 | RFCthis | Unable to perform signed JWT | | 500 | RFC 9246 | Unable to perform signed JWT |
| | | verification because of malformed | | | | verification because of malformed |
| | | URI | | | | URI |
+-------+-----------+-------------------------------------+ +-------+-----------+-------------------------------------+
Table 4 Table 4
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
6.5. CDNI URI Signing Signed Token Transport 6.5. CDNI URI Signing Signed Token Transport
The IANA is requested to create a new "CDNI URI Signing Signed Token IANA has created a new "CDNI URI Signing Signed Token Transport"
Transport" subregistry in the "Content Delivery Networks subregistry in the "Content Delivery Networks Interconnection (CDNI)
Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing Parameters" registry. The "CDNI URI Signing Signed Token Transport"
Signed Token Transport" namespace defines the valid values that may namespace defines the valid values that may be in the Signed Token
be in the Signed Token Transport (cdnistt) JWT claim. Additions to Transport (cdnistt) JWT claim. Additions to the Signed Token
the Signed Token Transport namespace conform to the "Specification Transport namespace conform to the "Specification Required" policy as
Required" policy as defined in [RFC8126]. Updates to this defined in [RFC8126]. Updates to this subregistry are expected to be
subregistry are expected to be infrequent. infrequent.
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 | RFC 9246 |
+-------+---------------------------------------------+---------+ +-------+---------------------------------------------+----------+
| 1 | Designates token transport via cookie | RFCthis | | 1 | Designates token transport via cookie | RFC 9246 |
+-------+---------------------------------------------+---------+ +-------+---------------------------------------------+----------+
| 2 | Designates token transport via query string | RFCthis | | 2 | Designates token transport via query string | RFC 9246 |
+-------+---------------------------------------------+---------+ +-------+---------------------------------------------+----------+
Table 5
[RFC Editor: Please replace RFCthis with the published RFC number for Table 5
this document.]
6.6. JSON Web Token Claims Registration 6.6. 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.6.1. Registry Contents 6.6.1. Registry Contents
* Claim Name: cdniv Claim Name: cdniv
* Claim Description: CDNI Claim Set Version Claim Description: CDNI Claim Set Version
* Change Controller: IESG Change Controller: IESG
* Specification Document(s): Section 2.1.8 of [[ this specification Specification Document(s): Section 2.1.8 of RFC 9246
]]
* Claim Name: cdnicrit Claim Name: cdnicrit
* Claim Description: CDNI Critical Claims Set Claim Description: CDNI Critical Claims Set
* Change Controller: IESG Change Controller: IESG
* Specification Document(s): Section 2.1.9 of [[ this specification Specification Document(s): Section 2.1.9 of RFC 9246
]]
* Claim Name: cdniip Claim Name: cdniip
* Claim Description: CDNI IP Address Claim Description: CDNI IP Address
* Change Controller: IESG Change Controller: IESG
* Specification Document(s): Section 2.1.10 of [[ this specification Specification Document(s): Section 2.1.10 of RFC 9246
]]
* Claim Name: cdniuc Claim Name: cdniuc
* Claim Description: CDNI URI Container Claim Description: CDNI URI Container
* Change Controller: IESG Change Controller: IESG
* Specification Document(s): Section 2.1.11 of [[ this specification Specification Document(s): Section 2.1.11 of RFC 9246
]]
* Claim Name: cdniets Claim Name: cdniets
* Claim Description: CDNI Expiration Time Setting for Signed Token Claim Description: CDNI Expiration Time Setting for Signed Token
Renewal Renewal
* Change Controller: IESG Change Controller: IESG
* Specification Document(s): Section 2.1.12 of [[ this specification Specification Document(s): Section 2.1.12 of RFC 9246
]]
* Claim Name: cdnistt Claim Name: cdnistt
* Claim Description: CDNI Signed Token Transport Method for Signed Claim Description: CDNI Signed Token Transport Method for Signed
Token Renewal Token Renewal
* Change Controller: IESG Change Controller: IESG
* Specification Document(s): Section 2.1.13 of [[ this specification Specification Document(s): Section 2.1.13 of RFC 9246
]]
* Claim Name: cdnistd Claim Name: cdnistd
* Claim Description: CDNI Signed Token Depth Claim Description: CDNI Signed Token Depth
* Change Controller: IESG Change Controller: IESG
* Specification Document(s): Section 2.1.14 of [[ this specification Specification Document(s): Section 2.1.14 of RFC 9246
]]
6.7. Expert Review Guidance 6.7. Expert Review Guidance
Generally speaking, we should determine the registration has a Generally speaking, we should determine the registration has a
rational justification and does not duplicate a previous rational justification and does not duplicate a previous
registration. Early assignment should be permissible as long as registration. Early assignment should be permissible as long as
there is a reasonable expectation that the specification will become there is a reasonable expectation that the specification will become
formalized. Expert Reviewers should be empowered to make formalized. Expert Reviewers should be empowered to make
determinations, but generally speaking they should allow new claims determinations, but generally speaking they should allow new claims
that do not otherwise introduce conflicts with implementation or that do not otherwise introduce conflicts with implementation or
things that may lead to confusion. They should also follow the things that may lead to confusion. They should also follow the
guidelines of [RFC8126] Section 5 when sensible. guidelines of Section 5 of [RFC8126] when sensible.
7. Security Considerations 7. Security Considerations
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of CDNI. The used to provide access authorization in the case of CDNI. The
primary goal of URI Signing is to make sure that only authorized UAs primary goal of URI Signing is to make sure that only authorized UAs
are able to access the content, with a CSP being able to authorize are able to access the content, with a CSP being able to authorize
every individual request. It should be noted that URI Signing is not every individual request. It should be noted that URI Signing is not
a content protection scheme; if a CSP wants to protect the content a content protection scheme; if a CSP wants to protect the content
itself, other mechanisms, such as DRM, are more appropriate. itself, other mechanisms, such as DRM, are more appropriate.
CDNI URI Signing Signed Tokens leverage JSON Web Tokens and thus CDNI URI Signing Signed Tokens leverage JSON Web Tokens and thus,
guidelines in [RFC8725] are applicable for all JWT interactions. guidelines in [RFC8725] are applicable for all JWT interactions.
In general, it holds that the level of protection against In general, it holds that the level of protection against
illegitimate access can be increased by including more claims in the illegitimate access can be increased by including more claims in the
signed JWT. The current version of this document includes claims for signed JWT. The current version of this document includes claims for
enforcing Issuer, Client IP Address, Not Before time, and Expiration enforcing Issuer, Client IP Address, Not Before time, and Expiration
Time, however this list can be extended with other, more complex, Time; however, this list can be extended with other more complex
attributes that are able to provide some form of protection against attributes that are able to provide some form of protection against
some of the vulnerabilities highlighted below. some of the vulnerabilities highlighted below.
That said, there are a number of aspects that limit the level of That said, there are a number of aspects that limit the level of
security offered by URI Signing and that anybody implementing URI security offered by URI Signing and that anybody implementing URI
Signing should be aware of. Signing should be aware of.
* Replay attacks: A (valid) Signed URI may be used to perform replay 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 sudden network issues from denying legitimate seconds to prevent sudden network issues from denying legitimate
UAs access to the content. One may also reduce exposure to replay UAs access to the content. One may also reduce exposure to replay
attacks by including a unique one-time access ID via the JWT ID attacks by including a unique one-time access ID via the JWT ID
attribute (jti claim). Whenever the dCDN receives a request with attribute (jti claim). Whenever the dCDN receives a request with
a given unique ID, it adds that ID to the list of 'used' IDs. In a given unique ID, it adds that ID to the list of 'used' IDs. In
the case an illegitimate UA tries to use the same URI through a the case an illegitimate UA tries to use the same URI through a
replay attack, the dCDN can deny the request based on the already- replay attack, the dCDN can deny the request based on the already
used access ID. This list should be kept bounded. A reasonable used access ID. This list should be kept bounded. A reasonable
approach would be to expire the entries based on the exp claim approach would be to expire the entries based on the exp claim
value. If no exp claim is present then a simple LRU could be value. If no exp claim is present, then a simple LRU could be
used, however this would allow values to eventually be reused. used; however, this would allow values to eventually be reused.
* Illegitimate clients behind a NAT: In cases where there are Illegitimate clients behind a NAT: In cases where there are multiple
multiple users behind the same NAT, all users will have the same users behind the same NAT, all users will have the same IP address
IP address from the point of view of the dCDN. This results in from the point of view of the dCDN. This results in the dCDN not
the dCDN not being able to distinguish between different users being able to distinguish between different users based on Client
based on Client IP Address which can lead to illegitimate users IP Address, which can lead to illegitimate users being able to
being able to access the content. One way to reduce exposure to access the content. One way to reduce exposure to this kind of
this kind of attack is to not only check for Client IP but also attack is to not only check for Client IP but also for other
for other attributes, e.g., attributes that can be found in HTTP attributes, e.g., attributes that can be found in HTTP headers.
headers. However, this may be easily circumvented by a However, this may be easily circumvented by a sophisticated
sophisticated attacker. attacker.
A shared key distribured between CSP and uCDN is more likely to be A shared key distributed between CSP and uCDN is more likely to be
compromised. Since this key can be used to legitimately sign a URL compromised. Since this key can be used to legitimately sign a URL
for content access authorization, it is important to know the for content access authorization, it is important to know the
implications of a compromised shared key. While using a shared key implications of a compromised shared key. While using a shared key
scheme can be convenient, this architecture is NOT RECOMMENDED due to scheme can be convenient, this architecture is NOT RECOMMENDED due to
the risks associated. It is included for legacy feature parity and the risks associated. It is included for legacy feature parity and
is highly discouraged in new implementations. is highly discouraged in new implementations.
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
skipping to change at page 35, line 20 skipping to change at line 1563
The URI Container (cdniuc) claim can be given a wildcard value. The URI Container (cdniuc) claim can be given a wildcard value.
This, combined with the fact that it is the only mandatory claim, This, combined with the fact that it is the only mandatory claim,
means you can effectively make a skeleton key. Doing this does not means you can effectively make a skeleton key. Doing this does not
sufficiently limit the scope of the JWT and is NOT RECOMMENDED. The sufficiently limit the scope of the JWT and is NOT RECOMMENDED. The
only way to prevent such a key from being used after it is only way to prevent such a key from being used after it is
distributed is to revoke the signing key so it no longer validates. distributed is to revoke the signing key so it no longer validates.
8. Privacy 8. Privacy
The privacy protection concerns described in CDNI Logging Interface The privacy protection concerns described in "Content Distribution
[RFC7937] apply when the client's IP address (cdniip) or Subject Network Interconnection (CDNI) Logging Interface" [RFC7937] apply
(sub) is embedded in the Signed URI. For this reason, the mechanism when the client's IP address (cdniip) or Subject (sub) is embedded in
described in Section 2 encrypts the Client IP or Subject before the Signed URI. For this reason, the mechanism described in
including it in the URI Signing Package (and thus the URL itself). Section 2 encrypts the Client IP or Subject before including it in
the URI Signing Package (and thus the URL itself).
9. Acknowledgements
The authors would like to thank the following people for their
contributions in reviewing this document and providing feedback:
Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan
York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana
Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris
Lemmons.
10. Contributors
In addition, the authors would also like to make special mentions for
certain people who contributed significant sections to this document.
* Matt Caulfield provided content for the CDNI Metadata Interface
section.
* Emmanuel Thomas provided content for HTTP Adaptive Streaming.
* Matt Miller provided consultation on JWT usage as well as code to
generate working JWT examples.
11. References 9. References
11.1. Normative References 9.1. Normative References
[POSIX.1] "The Open Group Base Specifications Issue 7", IEEE [POSIX.1] The Open Group, "IEEE Standard for Information Technology
Std 1003.1 2018 Edition, 31 January 2018, -- Portable Operating System Interface (POSIX(TM)) Base
<http://pubs.opengroup.org/onlinepubs/9699919799/>. Specifications, Issue 7", (Revision of IEEE Std
1003.1-2008), IEEE Std 1003.1-2017, January 2018,
<https://pubs.opengroup.org/onlinepubs/9699919799/>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <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>.
skipping to change at page 37, line 43 skipping to change at line 1661
[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 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
11.2. Informative References 9.2. Informative References
[IANA.JWT.Claims] [IANA.JWT.Claims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token (JWT)",
<http://www.iana.org/assignments/jwt>. <https://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, May and segment formats", ISO/IEC 23009-1:2014, Edition 2, May
2014, <http://www.iso.org/standard/65274.html>. 2014, <https://www.iso.org/standard/65274.html>.
[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>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network "Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
skipping to change at page 39, line 8 skipping to change at line 1717
<https://www.rfc-editor.org/info/rfc8216>. <https://www.rfc-editor.org/info/rfc8216>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725, Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020, DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>. <https://www.rfc-editor.org/info/rfc8725>.
Appendix A. Signed URI Package Example Appendix A. Signed URI Package Example
This section contains three examples of token usage: a simple example This section contains three examples of token usage: a simple example
with only the required claim present, a complex example which with only the required claim present, a complex example that
demonstrates the full JWT claims set, including an encrypted Client demonstrates the full JWT claims set, including an encrypted Client
IP Address (cdniip), and one that uses a Signed Token Renewal. IP Address (cdniip), and one that uses a Signed Token Renewal.
Note: All of the examples have whitespace added to improve formatting Note: All of the examples have whitespace added to improve formatting
and readability, but are not present in the generated content. and readability, but are not present in the generated content.
All examples use the following JWK Set [RFC7517]: All examples use the following JWK Set [RFC7517]:
{ "keys": [ { "keys": [
{ {
skipping to change at page 39, line 47 skipping to change at line 1756
{ {
"kty": "oct", "kty": "oct",
"kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998",
"use": "enc", "use": "enc",
"alg": "A128GCM", "alg": "A128GCM",
"k": "4uFxxV7fhNmrtiah2d1fFg" "k": "4uFxxV7fhNmrtiah2d1fFg"
} }
]} ]}
Note: They are the public signing key, the private signing key, and Note: They are the public signing key, the private signing key, and
the shared secret enctyption key, respectively. The public and the shared secret encryption key, respectively. The public and
private signing keys have the same fingerprint and only vary by the private signing keys have the same fingerprint and only vary by the
'd' parameter that is missing from the public signing key. 'd' parameter that is missing from the public signing key.
A.1. Simple Example A.1. Simple Example
This example is a simple common usage example containing a minimal This example is a simple common usage example containing a minimal
subset of claims that the authors find most useful. subset of claims that the authors find most useful.
The JWT Claim Set before signing: The JWT Claim Set before signing:
Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the
URL Segment form ([RFC6920] Section 5) of "http://cdni.example/foo/ URL Segment form (Section 5 of [RFC6920]) of
bar". "http://cdni.example/foo/bar".
{ {
"exp": 1646867369, "exp": 1646867369,
"iss": "uCDN Inc", "iss": "uCDN Inc",
"cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" "cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY"
} }
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE2NDY4NjczNjksImlzcyI6InVDRE4gS dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE2NDY4NjczNjksImlzcyI6InVDRE4gS
W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV
wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.TaNlJM3D96i_9J9XvlICO6FUIDFTqt3E2Y wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.TaNlJM3D96i_9J9XvlICO6FUIDFTqt3E2Y
JkEUOLfcH0b89wYRKTbJ9Yj6h_GRgSoZoQO0cps3yUPcWGK3smCw JkEUOLfcH0b89wYRKTbJ9Yj6h_GRgSoZoQO0cps3yUPcWGK3smCw
A.2. Complex Example A.2. Complex Example
This example uses all fields except for those dealing with Signed This example uses all fields except for those dealing with Signed
Token Renewal, including Client IP Address (cdniip) and Subject (sub) Token Renewal, including Client IP Address (cdniip) and Subject
which are encrpyted. This significantly increases the size of the (sub), which are encrypted. This significantly increases the size of
signed JWT token. the signed JWT token.
JWE for Client IP Address (cdniip) of [2001:db8::1/32]: JWE for Client IP Address (cdniip) of [2001:db8::1/32]:
eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST
NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBIc3nWjOb.bGXWT NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBIc3nWjOb.bGXWT
HPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA HPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA
JWE for Subject (sub) of "UserToken": JWE for Subject (sub) of "UserToken":
eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST
skipping to change at page 42, line 4 skipping to change at line 1853
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"cdniets": 30, "cdniets": 30,
"cdnistt": 1, "cdnistt": 1,
"cdnistd": 2, "cdnistd": 2,
"exp": 1646867369, "exp": 1646867369,
"cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
} }
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua
XN0ZCI6MiwiZXhwIjoxNjQ2ODY3MzY5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R XN0ZCI6MiwiZXhwIjoxNjQ2ODY3MzY5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R
uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.tlPvoKw3BCClw4Lx9 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.tlPvoKw3BCClw4Lx9
PQu7MK6b2IN55ZoCPSaxovGK0zS53Wpb1MbJBow7G8LiGR39h6-2Iq7PWUSr3MdTIz PQu7MK6b2IN55ZoCPSaxovGK0zS53Wpb1MbJBow7G8LiGR39h6-2Iq7PWUSr3MdTIz
HYw HYw
Once the server verifies 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,
"exp": 1646867399, "exp": 1646867399,
"cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
skipping to change at page 42, line 37 skipping to change at line 1887
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua
XN0ZCI6MiwiZXhwIjoxNjQ2ODY3Mzk5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R XN0ZCI6MiwiZXhwIjoxNjQ2ODY3Mzk5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R
uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.ivY5d_fKGd-OHTpUs uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.ivY5d_fKGd-OHTpUs
8uJUrnHvt-rduzu5H4zM7167pUUAghub53FqDQ5G16jRYX2sY73mA_uLpYDdb-CPts 8uJUrnHvt-rduzu5H4zM7167pUUAghub53FqDQ5G16jRYX2sY73mA_uLpYDdb-CPts
8FA 8FA
Acknowledgements
The authors would like to thank the following people for their
contributions in reviewing this document and providing feedback:
Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan
York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana
Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris
Lemmons.
Contributors
In addition, the authors would also like to make special mentions for
certain people who contributed significant sections to this document.
* Matt Caulfield provided content for Section 4.4, "CDNI Metadata
Interface".
* Emmanuel Thomas provided content for HTTP Adaptive Streaming.
* Matt Miller provided consultation on JWT usage as well as code to
generate working JWT examples.
Authors' Addresses Authors' Addresses
Ray van Brandenburg Ray van Brandenburg
Tiledmedia Tiledmedia
Anna van Buerenplein 1 Anna van Buerenplein 1
Den Haag 2595DA Den Haag
Netherlands
Phone: +31 88 866 7000 Phone: +31 88 866 7000
Email: ray@tiledmedia.com Email: ray@tiledmedia.com
Kent Leung Kent Leung
Email: mail4kentl@gmail.com Email: mail4kentl@gmail.com
Phil Sorber Phil Sorber
Apple, Inc. Apple, Inc.
1800 Wazee Street
Suite 410 Suite 410
1800 Wazee Street
Denver, CO 80202 Denver, CO 80202
United States United States
Email: sorber@apple.com Email: sorber@apple.com
 End of changes. 180 change blocks. 
471 lines changed or deleted 458 lines changed or added

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

mirror server hosted at Truenetwork, Russian Federation.