draft-ietf-cdni-uri-signing-12.txt   draft-ietf-cdni-uri-signing-13.txt 
CDNI R. van Brandenburg CDNI R. van Brandenburg
Internet-Draft Tiledmedia Internet-Draft Tiledmedia
Intended status: Standards Track K. Leung Intended status: Standards Track K. Leung
Expires: December 26, 2017 Cisco Systems, Inc. Expires: May 3, 2018 Cisco Systems, Inc.
P. Sorber P. Sorber
Comcast Cable Communications Comcast Cable Communications
June 24, 2017 October 30, 2017
URI Signing for CDN Interconnection (CDNI) URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-12 draft-ietf-cdni-uri-signing-13
Abstract Abstract
This document describes how the concept of URI signing supports the This document describes how the concept of URI signing supports the
content access control requirements of CDNI and proposes a URI content access control requirements of CDNI and proposes a URI
signing method as a JSON Web Token (JWT) [RFC7519] profile. signing method as a JSON Web Token (JWT) [RFC7519] profile.
The proposed URI signing method specifies the information needed to The proposed URI signing method specifies the information needed to
be included in the URI to transmit the signed JWT as well as the be included in the URI to transmit the signed JWT as well as the
claims needed by the signed JWT to authorize a UA. The mechanism claims needed by the signed JWT to authorize a UA. The mechanism
described can be used both in CDNI and single CDN scenarios. described can be used both in CDNI and single CDN scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2017. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Background and overview on URI Signing . . . . . . . . . 5 1.2. Background and overview on URI Signing . . . . . . . . . 5
1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6
1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8
2. JWT Format and Processing Requirements . . . . . . . . . . . 8 2. JWT Format and Processing Requirements . . . . . . . . . . . 9
2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 9 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10
2.1.2. URI Container (sub) claim . . . . . . . . . . . . . . 10 2.1.2. URI Container (sub) claim . . . . . . . . . . . . . . 10
2.1.3. Client IP (aud) claim . . . . . . . . . . . . . . . . 10 2.1.3. Client IP (aud) claim . . . . . . . . . . . . . . . . 10
2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 10 2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 11
2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11 2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11
2.1.6. Issued At (ait) claim . . . . . . . . . . . . . . . . 11 2.1.6. Issued At (iat) claim . . . . . . . . . . . . . . . . 11
2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 11 2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 12
2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12 2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12
2.1.9. CDNI Expiration Time Setting (cdniets) claim . . . . 12 2.1.9. CDNI Expiration Time Setting (cdniets) claim . . . . 12
2.1.10. CDNI Signed Token Transport (cdnistt) claim . . . . . 12 2.1.10. CDNI Signed Token Transport (cdnistt) claim . . . . . 13
2.1.11. URI Container Forms . . . . . . . . . . . . . . . . . 12 2.1.11. URI Container Forms . . . . . . . . . . . . . . . . . 13
2.1.11.1. URI Simple Container (uri:) . . . . . . . . . . 13 2.1.11.1. URI Simple Container (uri:) . . . . . . . . . . 13
2.1.11.2. URI Pattern Container (uri-pattern:) . . . . . . 13 2.1.11.2. URI Pattern Container (uri-pattern:) . . . . . . 13
2.1.11.3. URI Regular Expression Container (uri-regex:) . 14 2.1.11.3. URI Regular Expression Container (uri-regex:) . 14
2.1.11.4. URI Hash Container (uri-hash:) . . . . . . . . . 14 2.1.11.4. URI Hash Container (uri-hash:) . . . . . . . . . 14
2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 14 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 14
3. URI Signing for HAS . . . . . . . . . . . . . . . . . . . . . 14 3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 15
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Signed Token Chain mechanism . . . . . . . . . . . . . . 15 3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 15
3.3. Communicating a signed JWTs in a Signed Token Chain . . . 16 3.3. Communicating a signed JWTs in Signed Token Renewal . . . 16
3.3.1. Support for cross-domain redirection . . . . . . . . 16 3.3.1. Support for cross-domain redirection . . . . . . . . 16
4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 16 4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 17
4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 17 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 17
4.2. CDNI Footprint & Capabilities Advertisement Interface . . 17 4.2. CDNI Footprint & Capabilities Advertisement Interface . . 17
4.3. CDNI Request Routing Redirection Interface . . . . . . . 17 4.3. CDNI Request Routing Redirection Interface . . . . . . . 17
4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 17 4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 17
4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 19 4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 19
5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 20 5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 20
5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 20 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 20
5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 23 5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 25 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 26
6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 26 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 26
6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 26 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 26
6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 26 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 27
6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 26 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 27
6.4. JSON Web Token Claims Registration . . . . . . . . . . . 27 6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 27
6.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 27 6.5. JSON Web Token Claims Registration . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 28
8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Signed URI Package Example . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 31
A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 33
A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 32 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 34
A.3. Signed Token Chain Example . . . . . . . . . . . . . . . 33 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of redirection used to provide access authorization in the case of redirection
between interconnected CDNs (CDNI) and between a Content Service between interconnected CDNs (CDNI) and between a Content Service
Provider (CSP) and a CDN. The primary goal of URI Signing is to make Provider (CSP) and a CDN. The primary goal of URI Signing is to make
sure that only authorized User Agents (UAs) are able to access the sure that only authorized User Agents (UAs) are able to access the
content, with a CSP being able to authorize every individual request. content, with a CSP being able to authorize every individual request.
It should be noted that URI Signing is not a content protection It should be noted that URI Signing is not a content protection
skipping to change at page 4, line 25 skipping to change at page 4, line 28
authorization by the CDN allows any arbitrary distribution policy to authorization by the CDN allows any arbitrary distribution policy to
be enforced across CDNs without the need of CDNs to have any be enforced across CDNs without the need of CDNs to have any
awareness of the actual CSP distribution policy. awareness of the actual CSP distribution policy.
The representation of this method is a Signed JSON Web Token (JWT) The representation of this method is a Signed JSON Web Token (JWT)
[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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the terminology defined in CDNI Problem Statement This document uses the terminology defined in CDNI Problem Statement
[RFC6707]. [RFC6707].
This document also uses the terminology of JSON Web Token (JWT) This document also uses the terminology of JSON Web Token (JWT)
[RFC7519]. [RFC7519].
In addition, the following terms are used throughout this document: In addition, the following terms are used throughout this document:
o Signed URI: A URI for which a signed JWT is provided. o Signed URI: A URI for which a signed JWT is provided.
skipping to change at page 4, line 48 skipping to change at page 5, line 5
o Target CDN URI: URI created by the CSP to direct a UA towards the o Target CDN URI: URI created by the CSP to direct a UA towards the
Upstream CDN (uCDN). The Target CDN URI can be signed by the CSP Upstream CDN (uCDN). The Target CDN URI can be signed by the CSP
and verified by the uCDN and possibly further Downstream CDNs and verified by the uCDN and possibly further Downstream CDNs
(dCDNs). (dCDNs).
o Redirection URI: URI created by the uCDN to redirect a UA towards o Redirection URI: URI created by the uCDN to redirect a UA towards
the dCDN. The Redirection URI can be signed by the uCDN and the dCDN. The Redirection URI can be signed by the uCDN and
verified by the dCDN. In a cascaded CDNI scenario, there can be verified by the dCDN. In a cascaded CDNI scenario, there can be
more than one Redirection URI. more than one Redirection URI.
o Signed Token Chain: A chain of signed JWTs that are used for o 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 a Signed resource in the set. When generating a new signed JWT in Signed
Token Chain, 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 by including a set of the CSP to authorize access to a content item by including a set of
claims in the form of a signed JWT in the URI before redirecting a UA claims in the form of a signed JWT in the URI before redirecting a UA
to the CDN. Using these attributes, it is possible for a CDN to to the CDN. Using these attributes, it is possible for a CDN to
check an incoming content request to see whether it was authorized by check an incoming content request to see whether it was authorized by
the CSP (e.g., based on the UA's IP address or a time window). To the CSP (e.g., based on the UA's IP address or a time window). To
skipping to change at page 8, line 28 skipping to change at page 8, line 28
Redirection URI to redirect the UA to the dCDN. Since this new URI Redirection URI to redirect the UA to the dCDN. Since this new URI
could have a new signed JWT, a new signature can be based around the could have a new signed JWT, a new signature can be based around the
trust relationship between the uCDN and dCDN, and the relationship trust relationship between the uCDN and dCDN, and the relationship
between the dCDN and CSP is not relevant. Given the fact that such a between the dCDN and CSP is not relevant. Given the fact that such a
relationship between uCDN and dCDN always exists, both asymmetric relationship between uCDN and dCDN always exists, both asymmetric
public/private keys and symmetric shared secret keys can be used for public/private keys and symmetric shared secret keys can be used for
URI Signing with HTTP-based request routing. Note that the signed URI Signing with HTTP-based request routing. Note that the signed
Redirection URI MUST maintain the same, or higher, level of security Redirection URI MUST maintain the same, or higher, level of security
as the original Signed URI. as the original Signed URI.
Two types of keys can be used for URI Signing: asymmetric keys and
symmetric keys. Asymmetric keys are based on a public/private key
pair mechanism and always contain a private key only known to 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
used by both the signing entity for signing the URI as well as by the
validating entity for validating the Signed URI. Regardless of the
type of keys used, the validating entity has to obtain the key
(either the public or the symmetric key). There are very different
requirements for key distribution (out of scope of this document)
with asymmetric keys and with symmetric keys. Key distribution for
symmetric keys requires confidentiality to prevent another party from
getting access to the key, since it could then generate valid Signed
URIs for unauthorized requests. Key distribution for asymmetric keys
does not require confidentiality since public keys can typically be
distributed openly (because they cannot be used for URI signing) and
private keys are kept by the URI signing function.
1.4. URI Signing in a non-CDNI context 1.4. URI Signing in a non-CDNI context
While the URI signing method defined in this document was primarily While the URI signing method defined in this document was primarily
created for the purpose of allowing URI Signing in CDNI scenarios, created for the purpose of allowing URI Signing in CDNI scenarios,
e.g., between a uCDN and a dCDN or between a CSP and a dCDN, there is e.g., between a uCDN and a dCDN or between a CSP and a dCDN, there is
nothing in the defined URI Signing method that precludes it from nothing in the defined URI Signing method that precludes it from
being used in a non-CDNI context. As such, the described mechanism being used in a non-CDNI context. As such, the described mechanism
could be used in a single-CDN scenario such as shown in Figure 1 in could be used in a single-CDN scenario such as shown in Figure 1 in
Section 1.2, for example to allow a CSP that uses different CDNs to Section 1.2, for example to allow a CSP that uses different CDNs to
only have to implement a single URI Signing mechanism. only have to implement a single URI Signing mechanism.
skipping to change at page 11, line 28 skipping to change at page 11, line 47
JWT does not support Not Before time validation, or if the Not Before JWT does not support Not Before time validation, or if the Not Before
time in the signed JWT corresponds to a time later than the time of time in the signed JWT corresponds to a time later than the time of
the content request, the CDN MUST reject the request. If the the content request, the CDN MUST reject the request. If the
received signed JWT contains a Not Before time claim, then any JWT received signed JWT contains a Not Before time claim, then any JWT
subsequently generated for CDNI redirection MUST also contain a Not subsequently generated for CDNI redirection MUST also contain a Not
Before time claim, and the Not Before time value MUST be the same as Before time claim, and the Not Before time value MUST be the same as
in the received signed JWT. A signed JWT generated for CDNI in the received signed JWT. A signed JWT generated for CDNI
redirection MUST NOT add a Not Before time claim if no Not Before redirection MUST NOT add a Not Before time claim if no Not Before
time claim existed in the received signed JWT. time claim existed in the received signed JWT.
2.1.6. Issued At (ait) claim 2.1.6. Issued At (iat) claim
Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6 Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6
MUST be followed. Note: The time on the entities that generate and MUST be followed. Note: The time on the entities that generate and
validate the signed URI SHOULD be in sync. In the CDNI case, this validate the signed URI SHOULD be in sync. In the CDNI case, this
means that CSP, uCDN, and dCDN servers need to be time-synchronized. means that CSP, uCDN, and dCDN servers need to be time-synchronized.
It is RECOMMENDED to use NTP [RFC5905] for time synchronization. If It is RECOMMENDED to use NTP [RFC5905] for time synchronization. If
the received signed JWT contains an Issued At claim, then any JWT the received signed JWT contains an Issued At claim, then any JWT
subsequently generated for CDNI redirection MUST also contain an subsequently generated for CDNI redirection MUST also contain an
Issued At claim, and the Issuer value MUST be updated to identify the Issued At claim, and the Issuer value MUST be updated to identify the
time the new JWT was generated. If the received signed JWT does not time the new JWT was generated. If the received signed JWT does not
skipping to change at page 12, line 26 skipping to change at page 12, line 45
to "1", for this version of the specification. In the absence of to "1", for this version of the specification. In the absence of
this claim, the value is assumed to be "1". For future versions this this claim, the value is assumed to be "1". For future versions this
claim will be mandatory. Implementations MUST reject signed JWTs claim will be mandatory. Implementations MUST reject signed JWTs
with unsupported CDNI Claim Set versions. with unsupported CDNI Claim Set versions.
2.1.9. CDNI Expiration Time Setting (cdniets) claim 2.1.9. 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 a Signed Token Chain. Its type is a JSON integer signed JWT in Signed Token Renewal. Its type is a JSON numeric
denotes the number of seconds to be added to the Expiry Time (exp) value. It denotes the number of seconds to be added to the time at
claim of the previous signed JWT that gives the value of the Expiry which the JWT is validated that gives the value of the Expiry Time
Time (exp) claim of the next signed JWT. The CDNI Expiration Time (exp) claim of the next signed JWT. The CDNI Expiration Time Setting
Setting (cdniets) SHOULD NOT be used when not using a Signed Token (cdniets) SHOULD NOT be used when not using Signed Token Renewal.
Chain.
2.1.10. CDNI Signed Token Transport (cdnistt) claim 2.1.10. CDNI Signed Token Transport (cdnistt) claim
CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed
Token Transport (cdnistt) claim provides a means of signalling the Token Transport (cdnistt) claim provides a means of signalling the
method through which the Signed Token Chain is transported from the method through which a new signed JWT is transported from the CDN to
CDN to the UA and vice versa. Its type is a JSON integer. This the UA and vice versa for the purpose of Signed Token Renewal. Its
document only defines setting its value to '1', which means the type is a JSON integer. This document only defines setting its value
signed JWTs making up the Signed Token Chain are transported via HTTP to '1', which means the signed JWTs are transported via HTTP Cookies
Cookies in both directions. in both directions. Additional values for this claim can be defined
in Section 6.4.
2.1.11. URI Container Forms 2.1.11. URI Container Forms
The URI Container (sub) claim takes one of the following forms. More The URI Container (sub) claim takes one of the following forms. More
forms may be added in the future to extend the capabilities. forms may be added in the future to extend the capabilities.
2.1.11.1. URI Simple Container (uri:) 2.1.11.1. URI Simple Container (uri:)
When prefixed with 'uri:', the string following 'uri:' is the URI When prefixed with 'uri:', the string following 'uri:' is the URI
that MUST be matched with a simple string match to the requested URI. that MUST be matched with a simple string match to the requested URI.
skipping to change at page 14, line 17 skipping to change at page 14, line 30
Prefixed with 'uri-regex:', this string is any PCRE [PCRE839] Prefixed with 'uri-regex:', this string is any PCRE [PCRE839]
compatible regular expression used to match against the requested compatible regular expression used to match against the requested
URI. URI.
Note: Because '\' has special meaning in JSON [RFC7159] as the escape Note: Because '\' has special meaning in JSON [RFC7159] as the escape
character within JSON strings, the regular expression character '\' character within JSON strings, the regular expression character '\'
MUST be escaped as '\\'. MUST be escaped as '\\'.
An example of a 'uri-regex:' is the following: An example of a 'uri-regex:' is the following:
.*\\://.*/folder/content-83112371/quality_.*/segment.{3}\\.mp4 [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\?.*)?
Note: Due to computational complexity of executing arbitrary regular Note: Due to computational complexity of executing arbitrary regular
expressions, it is RECOMMENDED to only execute after validating the expressions, it is RECOMMENDED to only execute after validating the
JWT to ensure its authenticity. JWT to ensure its authenticity.
2.1.11.4. URI Hash Container (uri-hash:) 2.1.11.4. URI Hash Container (uri-hash:)
Prefixed with 'uri-hash:', this string is a URL Segment form Prefixed with 'uri-hash:', this string is a URL Segment form
([RFC6920] Section 5) of the URI. ([RFC6920] Section 5) of the URI.
2.2. JWT Header 2.2. JWT Header
The header of the JWT MAY be passed via the CDNI Metadata interface The header of the JWT MAY be passed via the CDNI Metadata interface
instead of being included in the URISigningPackage. The header value instead of being included in the URISigningPackage. The header value
must be transmitted in the serialized encoded form and prepended to must be transmitted in the serialized encoded form and prepended to
the JWT payload and signature passed in the URISigningPackage prior the JWT payload and signature passed in the URISigningPackage prior
to validation. This reduces the size of the signed JWT token. to validation. This reduces the size of the signed JWT token.
3. URI Signing for HAS 3. URI Signing Token Renewal
3.1. Overview 3.1. Overview
For content that is delivered via an HTTP Adaptive Streaming (HAS) For content that is delivered via HTTP in a segmented fashion, such
protocol, such as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216],
[I-D.pantos-http-live-streaming], special provisions need to be made special provisions need to be made in order to ensure URI Signing can
in order to ensure URI Signing can be applied. In general, HAS be applied. In general, segmented protocols work by breaking large
protocols work by breaking large objects (e.g. videos) into a objects (e.g. videos) into a sequence of small independent segments.
sequence of small independent chunks. Such chunks are then Such segments are then referenced by a separate manifest file, which
referenced by a separate manifest file, which either includes a list either includes a list of URLs to the segments or specifies an
of URLs to the chunks or specifies an algorithm through which a User algorithm through which a User Agent can construct the URLs to the
Agent can construct the URLs to the chunks. Requests for chunks segments. Requests for segments therefore originate from the
therefore originate from the manifest file and, unless the URLs in manifest file and, unless the URLs in the manifest file point to the
the manifest file point to the CSP, are not subjected to redirection CSP, are not subjected to redirection and URI Signing. This opens up
and URI Signing. This opens up the vulnerability of malicious User the vulnerability of malicious User Agents sharing the manifest file
Agents sharing the manifest file and deep-linking to the chunks. and deep-linking to the segments.
One method for dealing with this vulnerability would be to include in One method for dealing with this vulnerability would be to include,
the manifest itself Signed URIs that point to the individual chunks. in the manifest itself, Signed URIs that point to the individual
There exist a number of issues with that approach. First, it segments. There exist a number of issues with that approach. First,
requires the CDN delivering the manifest to rewrite the manifest file it requires the CDN delivering the manifest to rewrite the manifest
for each User Agent, which would require the CDN to be aware of the file for each User Agent, which would require the CDN to be aware of
exact HAS protocol and version used. Secondly, it would require the the exact segmentation protocol used. Secondly, it could also
expiration time of the Signed URIs to be valid for at least the full require the expiration time of the Signed URIs to be valid for an
duration of the content described by the manifest. Since it is extended duration if the content described by the manifest is meant
common for a manifest file to contain a video item of more than 30 to be consumed in real time. For instance, if the manifest file were
minutes in length, Signed URIs would require to be valid for a long to contain a segmented video stream of more than 30 minutes in
time, thereby reducing their effectiveness and that of the URI length, Signed URIs would require to be valid for a at least 30
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
HAS protocols affect CDNI, see Models for HTTP-Adaptive-Streaming- segmented protocols such as HTTP Adaptive Streaming protocols affect
Aware CDNI [RFC6983]. CDNI, see Models for HTTP-Adaptive-Streaming-Aware 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 HTTP Adaptive Streaming content (or other chunked content) for segmented content without having to include the Signed URIs in
without having to include the Signed URIs in the manifest files the manifest files themselves.
themselves.
3.2. Signed Token Chain mechanism 3.2. Signed Token Renewal mechanism
In order to allow for effective access control of HAS content, the In order to allow for effective access control of segmented content,
URI signing scheme defined in this section is based on a mechanism the URI signing scheme defined in this section is based on a
through which subsequent HAS chunk requests can be chained together. mechanism through which subsequent segment requests can be linked
As part of the JWT validation procedure, the CDN can generate a new together. As part of the JWT validation procedure, the CDN can
signed JWT that the UA can use to do a subsequent request. More generate a new signed JWT that the UA can use to do a subsequent
specifically, whenever a UA successfully retrieves an HAS chunk, it request. More specifically, whenever a UA successfully retrieves a
receives, in the HTTP 2xx Successful message, a signed JWT that it segment, it receives, in the HTTP 2xx Successful message, a signed
can use whenever it requests the next chunk. As long as each signed JWT that it can use whenever it requests the next segment. As long
JWT in such a Signed Token Chain is correctly validated before a new as each successive signed JWT is correctly validated before a new one
one is generated, the chain is not broken and the User Agent can is generated, the model is not broken and the User Agent can
successfully retrieve additional chunks. Given the fact that with successfully retrieve additional segments. Given the fact that with
HAS protocols, it is usually not possible to determine a priori which segmented protocols, it is usually not possible to determine a priori
chunk will be requested next (i.e., to allow for seeking within the which segment will be requested next (i.e., to allow for seeking
content and for switching to a different quality level), the Signed within the content and for switching to a different representation),
Token Chain uses the URI Pattern Container and/or the URI Regular the Signed Token Renewal uses the URI Pattern Container and/or the
Expression Container scoping mechanisms in the URI Container (sub) URI Regular Expression Container scoping mechanisms in the URI
claim to allow the Signed Token Chain to be valid for more than one Container (sub) claim to allow a signed JWT to be valid for more than
URL. one URL.
In order for this chaining of signed JWTs to work, it is necessary In order for this renewal of signed JWTs to work, it is necessary for
for a UA to extract the signed JWT from the HTTP 2xx Successful a UA to extract the signed JWT from the HTTP 2xx Successful message
message of an earlier request and use it to retrieve the next chunk. of an earlier request and use it to retrieve the next segment. The
The exact mechanism by which the client does this depends on the exact mechanism by which the client does this depends on the exact
exact HAS protocol and since this document is only concerned with the segmented protocol and since this document is only concerned with the
generation and validation of incoming request, this process is generation and validation of incoming request, this process is
outside the scope of this document. However, in order to also outside the scope of this document. However, in order to also
support legacy UAs that do not include any specific provisions for support legacy UAs that do not include any specific provisions for
the handling of signed JWTs, the folowing section defines a mechanism the handling of signed JWTs, the folowing section defines a mechanism
using HTTP Cookies that allows such UAs to support the concept of using HTTP Cookies that allows such UAs to support the concept of
chained signed JWTs without requiring any support on the UA side. renewing signed JWTs without requiring any support on the UA side.
3.3. Communicating a signed JWTs in a Signed Token Chain 3.3. Communicating a signed JWTs in Signed Token Renewal
This section assumes the value of the CDNI Signed Token Transport This section assumes the value of the CDNI Signed Token Transport
(cdnistt) claim has been set to 1. Other values of cdnistt are out (cdnistt) claim has been set to 1. Other values of cdnistt are out
of scope of this document. of scope of this document.
When using the Signed Token Chain mechanism, the signed JWT is When using the Signed Token Renewal mechanism, the signed JWT is
transported to the UA via a 'URISigningPackage' cookie added to the transported to the UA via a 'URISigningPackage' cookie added to the
HTTP 2xx Successful message along with the content being returned to HTTP 2xx Successful message along with the content being returned to
the UA, or to the HTTP 3xx Redirection message in case the UA is the UA, or to the HTTP 3xx Redirection message in case the UA is
redirected to a different server. redirected to a different server.
3.3.1. Support for cross-domain redirection 3.3.1. Support for cross-domain redirection
For security purposes, the use of cross-domain cookies is not For security purposes, the use of cross-domain cookies is not
supported in some application environments. As a result, the Cookie- supported in some application environments. As a result, the Cookie-
based method for transport of the Signed Token described in the based method for transport of the Signed Token described in the
previous section might break if used in combination with a HTTP 3xx previous section might break if used in combination with a 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, a Signed Token Chain 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 a Signed Token Chain) are how regular signed JWTs (outside of Signed Token Renewal) are
communicated. Note that the use of URL embedded signed JWTs SHOULD communicated. Note that the use of URL embedded signed JWTs SHOULD
NOT be used in HTTP 2xx Successful messages, since UAs might not know NOT be used in HTTP 2xx Successful messages, since UAs might not know
how to extract the signed JWTs. how to extract the signed JWTs.
Note that the process described below only works in cases where both Note that the process described below only works in cases where both
the manifest file and segments constituting the HTTP Adaptive the manifest file and segments constituting the segmented content are
Streaming content are delivered from the same domain. In other delivered from the same domain. In other words, any redirection
words, any redirection between different domains needs to be carried between different domains needs to be carried out while retrieving
out while retrieving the manifest file. the manifest file.
4. Relationship with CDNI Interfaces 4. Relationship with CDNI Interfaces
Some of the CDNI Interfaces need enhancements to support URI Signing. Some of the CDNI Interfaces need enhancements to support URI Signing.
As an example: A dCDN that supports URI Signing needs to be able to As an example: A dCDN that supports URI Signing needs to be able to
advertise this capability to the uCDN. The uCDN needs to select a advertise this capability to the uCDN. The uCDN needs to select a
dCDN based on such capability when the CSP requires access control to dCDN based on such capability when the CSP requires access control to
enforce its distribution policy via URI Signing. Also, the uCDN enforce its distribution policy via URI Signing. Also, the uCDN
needs to be able to distribute via the CDNI Metadata interface the needs to be able to distribute via the CDNI Metadata interface the
information necessary to allow the dCDN to validate a Signed URI. information necessary to allow the dCDN to validate a Signed URI.
skipping to change at page 27, line 15 skipping to change at page 27, line 42
+---------------------------+-----------+ +---------------------------+-----------+
| Field Name | Reference | | Field Name | Reference |
+---------------------------+-----------+ +---------------------------+-----------+
| s-uri-signing | RFCthis | | s-uri-signing | RFCthis |
| s-uri-signing-deny-reason | RFCthis | | s-uri-signing-deny-reason | RFCthis |
+---------------------------+-----------+ +---------------------------+-----------+
[RFC Editor: Please replace RFCthis with the published RFC number for [RFC Editor: Please replace RFCthis with the published RFC number for
this document.] this document.]
6.4. JSON Web Token Claims Registration 6.4. CDNI URI Signing Signed Token Transport
The IANA is requested to create a new "CDNI URI Signing Signed Token
Transport" subregistry in the "Content Delivery Networks
Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing
Signed Token Transport" namespace defines the valid values that may
be in the Signed Token Transport (cdnistt) JWT claim. Additions to
the Signed Token Transport namespace conform to the "Specification
Required" policy as defined in [RFC5226].
The following table defines the initial Enforcement Information
Elements:
+-------+---------------------------------------+---------+
| Value | Description | RFC |
+-------+---------------------------------------+---------+
| 1 | Designates token transport via cookie | RFCthis |
+-------+---------------------------------------+---------+
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
[Ed Note: are there any special instructions to the designated expert
reviewer?]
6.5. JSON Web Token Claims Registration
This specification registers the following Claims in the IANA "JSON This specification registers the following Claims in the IANA "JSON
Web Token Claims" registry [IANA.JWT.Claims] established by Web Token Claims" registry [IANA.JWT.Claims] established by
[RFC7519]. [RFC7519].
6.4.1. Registry Contents 6.5.1. Registry Contents
o Claim Name: "cdniv" o Claim Name: "cdniv"
o Claim Description: CDNI Claim Set Version o Claim Description: CDNI Claim Set Version
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.1.8 of [[ this specification o Specification Document(s): Section 2.1.8 of [[ this specification
]] ]]
o Claim Name: "cdniets" o Claim Name: "cdniets"
o Claim Description: CDNI Expiration Time Setting for Signed Token o Claim Description: CDNI Expiration Time Setting for Signed Token
Chain Renewal
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.1.9 of [[ this specification o Specification Document(s): Section 2.1.9 of [[ this specification
]] ]]
o Claim Name: "cdnistt" o Claim Name: "cdnistt"
o Claim Description: CDNI Signed Token Transport Method for Signed o Claim Description: CDNI Signed Token Transport Method for Signed
Token Chain Token Renewal
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.1.10 of [[ this specification o Specification Document(s): Section 2.1.10 of [[ this specification
]] ]]
7. Security Considerations 7. Security Considerations
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of CDNI. The used to provide access authorization in the case of CDNI. The
primary goal of URI Signing is to make sure that only authorized UAs primary goal of URI Signing is to make sure that only authorized UAs
are able to access the content, with a CSP being able to authorize are able to access the content, with a CSP being able to authorize
skipping to change at page 29, line 11 skipping to change at page 30, line 19
Signed URI. For this reason, the mechanism described in Section 2 Signed URI. For this reason, the mechanism described in Section 2
encrypts the Client IP before including it in the URI Signing Package encrypts the Client IP before including it in the URI Signing Package
(and thus the URL itself). (and thus the URL itself).
9. Acknowledgements 9. Acknowledgements
The authors would like to thank the following people for their The authors would like to thank the following people for their
contributions in reviewing this document and providing feedback: contributions in reviewing this document and providing feedback:
Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan
York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana
Oprescu, Leif Hedstrom, Gancho Tenev, and Brian Campbell. Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris
Lemmons.
10. Contributors 10. Contributors
In addition, the authors would also like to make special mentions for In addition, the authors would also like to make special mentions for
certain people who contributed significant sections to this document. certain people who contributed significant sections to this document.
o Matt Caulfield provided content for the CDNI Metadata Interface o Matt Caulfield provided content for the CDNI Metadata Interface
section. section.
o Emmanuel Thomas provided content for HTTP Adaptive Streaming. o Emmanuel Thomas provided content for HTTP Adaptive Streaming.
skipping to change at page 29, line 33 skipping to change at page 30, line 42
o Matt Miller provided consultation on JWT usage as well as code to o Matt Miller provided consultation on JWT usage as well as code to
generate working JWT examples. generate working JWT examples.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<http://www.rfc-editor.org/info/rfc6920>. <https://www.rfc-editor.org/info/rfc6920>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015, RFC 7516, DOI 10.17487/RFC7516, May 2015,
<http://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed.,
and R. Peterkofsky, "Content Distribution Network and R. Peterkofsky, "Content Distribution Network
Interconnection (CDNI) Logging Interface", RFC 7937, Interconnection (CDNI) Logging Interface", RFC 7937,
DOI 10.17487/RFC7937, August 2016, DOI 10.17487/RFC7937, August 2016,
<http://www.rfc-editor.org/info/rfc7937>. <https://www.rfc-editor.org/info/rfc7937>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"Content Delivery Network Interconnection (CDNI) "Content Delivery Network Interconnection (CDNI)
Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
<http://www.rfc-editor.org/info/rfc8006>. <https://www.rfc-editor.org/info/rfc8006>.
11.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.pantos-http-live-streaming] 11.2. Informative References
Pantos, R. and W. May, "HTTP Live Streaming", draft-
pantos-http-live-streaming-23 (work in progress), May
2017.
[IANA.JWT.Claims] [IANA.JWT.Claims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token Claims",
<http://www.iana.org/assignments/jwt>. <http://www.iana.org/assignments/jwt>.
[MPEG-DASH] [MPEG-DASH]
ISO, "Information technology -- Dynamic adaptive streaming ISO, "Information technology -- Dynamic adaptive streaming
over HTTP (DASH) -- Part 1: Media presentation description over HTTP (DASH) -- Part 1: Media presentation description
and segment format", ISO/IEC 23009-1:2014, Edition 2, 05 and segment format", ISO/IEC 23009-1:2014, Edition 2, 05
2014, <http://www.iso.org/standard/65274.html>. 2014, <http://www.iso.org/standard/65274.html>.
[PCRE839] Hazel, P., "Perl Compatible Regular Expressions", [PCRE839] Hazel, P., "Perl Compatible Regular Expressions",
Version 8.39, June 2016, <http://www.pcre.org/>. Version 8.39, June 2016, <http://www.pcre.org/>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>. 2012, <https://www.rfc-editor.org/info/rfc6707>.
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection (CDNI)", Content Distribution Network Interconnection (CDNI)",
RFC 6983, DOI 10.17487/RFC6983, July 2013, RFC 6983, DOI 10.17487/RFC6983, July 2013,
<http://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,
August 2014, <http://www.rfc-editor.org/info/rfc7336>. August 2014, <https://www.rfc-editor.org/info/rfc7336>.
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Network Interconnection (CDNI) Requirements", RFC 7337, Network Interconnection (CDNI) Requirements", RFC 7337,
DOI 10.17487/RFC7337, August 2014, DOI 10.17487/RFC7337, August 2014,
<http://www.rfc-editor.org/info/rfc7337>. <https://www.rfc-editor.org/info/rfc7337>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed.,
"Request Routing Redirection Interface for Content "Request Routing Redirection Interface for Content
Delivery Network (CDN) Interconnection", RFC 7975, Delivery Network (CDN) Interconnection", RFC 7975,
DOI 10.17487/RFC7975, October 2016, DOI 10.17487/RFC7975, October 2016,
<http://www.rfc-editor.org/info/rfc7975>. <https://www.rfc-editor.org/info/rfc7975>.
[RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
R., and K. Ma, "Content Delivery Network Interconnection R., and K. Ma, "Content Delivery Network Interconnection
(CDNI) Request Routing: Footprint and Capabilities (CDNI) Request Routing: Footprint and Capabilities
Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
<http://www.rfc-editor.org/info/rfc8008>. <https://www.rfc-editor.org/info/rfc8008>.
[RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming",
RFC 8216, DOI 10.17487/RFC8216, August 2017,
<https://www.rfc-editor.org/info/rfc8216>.
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 which
demonstrates the full JWT claims set, including an encrypted Client demonstrates the full JWT claims set, including an encrypted Client
IP (aud), and one that uses a Signed Token Chain. IP (aud), 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 signing key to generate the Signed URI All examples use the following JWK Set [RFC7517]:
Package:
{ { "keys": [
"kty": "EC", {
"kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", "kty": "EC",
"use": "sig", "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0",
"crv": "P-256", "use": "sig",
"x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", "alg": "ES256",
"y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", "crv": "P-256",
"d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8",
} "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA"
},
{
"kty": "EC",
"kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0",
"use": "sig",
"alg": "ES256",
"crv": "P-256",
"x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8",
"y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA",
"d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M"
},
{
"kty": "oct",
"kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998",
"use": "enc",
"alg": "A128GCM",
"k": "4uFxxV7fhNmrtiah2d1fFg"
}
]}
Note: They are the public signing key, the private signing key, and
the shared secret enctyption key, respectively. The public and
private signing keys have the same fingerprint and only vary by the
'd' parameter that is missing from the public signing key.
A.1. Simple Example A.1. Simple Example
This example is the simplest possible example containing the only This example is the simplest possible example containing the only
required field (sub). required field (sub).
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"sub": "uri:http://cdni.example/foo/bar/baz" "sub": "uri:http://cdni.example/foo/bar/baz"
skipping to change at page 32, line 36 skipping to change at page 34, line 28
The signed JWT: The signed JWT:
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJzdWIiOiJ1cmk6aHR0cDovL2NkbmkuZXhhbXBsZ dZRkRPV2tsZHVlYUltZjAifQ.eyJzdWIiOiJ1cmk6aHR0cDovL2NkbmkuZXhhbXBsZ
S9mb28vYmFyL2JheiJ9.LTizGd7zCb17Qp_80ClGApLCieRIq3dCjcRckNfLqiJ4BT S9mb28vYmFyL2JheiJ9.LTizGd7zCb17Qp_80ClGApLCieRIq3dCjcRckNfLqiJ4BT
GSfVXoDtm0Z6L5Jx4EmwM1w-WkznNajUy11iMAcA GSfVXoDtm0Z6L5Jx4EmwM1w-WkznNajUy11iMAcA
A.2. Complex Example A.2. Complex Example
This example uses all optional fields except for those dealing with This example uses all optional fields except for those dealing with
Signed Token Chaining, including Client IP (aud) which is encrpyted. Signed Token Renewal, including Client IP (aud) which is encrpyted.
This significantly increases the size of the signed JWT token. This significantly increases the size of the signed JWT token.
Shared key used for encrpyting the Client IP (aud):
{
"kty": "oct",
"kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998",
"use": "enc",
"alg": "A128GCM",
"k": "4uFxxV7fhNmrtiah2d1fFg"
}
JWE for client IP (aud) of [2001:db8::1/32]: JWE for client IP (aud) of [2001:db8::1/32]:
eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj
g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..oGLsnF8fLlFcUXK0.KFfBB g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..oGLsnF8fLlFcUXK0.KFfBB
H_FPYFu-RBFBR3rhQ.6_MVaa4t7JiVX2IgUkZ3jA H_FPYFu-RBFBR3rhQ.6_MVaa4t7JiVX2IgUkZ3jA
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm "aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm
skipping to change at page 33, line 37 skipping to change at page 35, line 17
dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJleUpoYkdjaU9pSmthWElpTENKcmFXU dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJleUpoYkdjaU9pSmthWElpTENKcmFXU
WlPaUptTFZkaWFuaENRek5rVUhWSk0yUXlOR3RRTW1obWRtOXpOMUY2TmpnNFZWUnB WlPaUptTFZkaWFuaENRek5rVUhWSk0yUXlOR3RRTW1obWRtOXpOMUY2TmpnNFZWUnB
ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLm9HTHNuRjhmTGxGY ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLm9HTHNuRjhmTGxGY
1VYSzAuS0ZmQkJIX0ZQWUZ1LVJCRkJSM3JoUS42X01WYWE0dDdKaVZYMklnVWtaM2p 1VYSzAuS0ZmQkJIX0ZQWUZ1LVJCRkJSM3JoUS42X01WYWE0dDdKaVZYMklnVWtaM2p
BIiwiY2RuaXYiOjEsImV4cCI6MTQ3NDI0MzUwMCwiaWF0IjoxNDc0MjQzMjAwLCJpc BIiwiY2RuaXYiOjEsImV4cCI6MTQ3NDI0MzUwMCwiaWF0IjoxNDc0MjQzMjAwLCJpc
3MiOiJ1Q0ROIEluYyIsImp0aSI6IjVEQWFmTGhaQWZoc2JlIiwibmJmIjoxNDc0MjQ 3MiOiJ1Q0ROIEluYyIsImp0aSI6IjVEQWFmTGhaQWZoc2JlIiwibmJmIjoxNDc0MjQ
zMjAwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGxlL2Zvby9iY zMjAwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGxlL2Zvby9iY
XIvYmF6L1swLTldezN9XFwucG5nIn0.r2FiSdfnGRw_RC2roGwh4LEYlfsWGF972-M XIvYmF6L1swLTldezN9XFwucG5nIn0.r2FiSdfnGRw_RC2roGwh4LEYlfsWGF972-M
f3He_LhGr2_3eRXP0jP_OFPj5NEtTZFY4PX_iD7vPD12_HPDJCQ f3He_LhGr2_3eRXP0jP_OFPj5NEtTZFY4PX_iD7vPD12_HPDJCQ
A.3. Signed Token Chain Example A.3. Signed Token Renewal Example
This example uses fields for Signed Token Chaining. This example uses fields for Signed Token Renewal.
The JWT Claim Set before signing: The JWT Claim Set before signing:
{ {
"cdniets": 30, "cdniets": 30,
"cdnistt": 1, "cdnistt": 1,
"exp": 1474243500, "exp": 1474243500,
"sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.ts" "sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.ts"
} }
 End of changes. 67 change blocks. 
168 lines changed or deleted 240 lines changed or added

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