idnits 2.17.1 draft-ietf-cdni-uri-signing-24.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 304 has weird spacing: '...I(after v ...' -- The document date (31 December 2021) is 846 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6707 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI R. van Brandenburg 3 Internet-Draft Tiledmedia 4 Intended status: Standards Track K. Leung 5 Expires: 4 July 2022 6 P. Sorber 7 Apple, Inc. 8 31 December 2021 10 URI Signing for Content Delivery Network Interconnection (CDNI) 11 draft-ietf-cdni-uri-signing-24 13 Abstract 15 This document describes how the concept of URI Signing supports the 16 content access control requirements of Content Delivery Network 17 Interconnection (CDNI) and proposes a URI Signing method as a JSON 18 Web Token (JWT) profile. 20 The proposed URI Signing method specifies the information needed to 21 be included in the URI to transmit the signed JWT, as well as the 22 claims needed by the signed JWT to authorize a User Agent (UA). The 23 mechanism described can be used both in CDNI and single Content 24 Delivery Network (CDN) scenarios. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 4 July 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Background and overview on URI Signing . . . . . . . . . 5 62 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 63 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 64 2. JWT Format and Processing Requirements . . . . . . . . . . . 9 65 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9 66 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10 67 2.1.2. Subject (sub) claim . . . . . . . . . . . . . . . . . 10 68 2.1.3. Audience (aud) claim . . . . . . . . . . . . . . . . 11 69 2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 11 70 2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11 71 2.1.6. Issued At (iat) claim . . . . . . . . . . . . . . . . 12 72 2.1.7. JWT ID (jti) claim . . . . . . . . . . . . . . . . . 12 73 2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12 74 2.1.9. CDNI Critical Claims Set (cdnicrit) claim . . . . . . 12 75 2.1.10. Client IP (cdniip) claim . . . . . . . . . . . . . . 13 76 2.1.11. CDNI URI Container (cdniuc) claim . . . . . . . . . . 13 77 2.1.12. CDNI Expiration Time Setting (cdniets) claim . . . . 14 78 2.1.13. CDNI Signed Token Transport (cdnistt) claim . . . . . 14 79 2.1.14. CDNI Signed Token Depth (cdnistd) claim . . . . . . . 14 80 2.1.15. URI Container Forms . . . . . . . . . . . . . . . . . 15 81 2.1.15.1. URI Hash Container (hash:) . . . . . . . . . . . 15 82 2.1.15.2. URI Regular Expression Container (regex:) . . . 15 83 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 16 84 3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 16 85 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 86 3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 17 87 3.2.1. Required Claims . . . . . . . . . . . . . . . . . . . 17 88 3.3. Communicating a signed JWTs in Signed Token Renewal . . . 18 89 3.3.1. Support for cross-domain redirection . . . . . . . . 18 90 4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 18 91 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 18 92 4.2. CDNI Footprint & Capabilities Advertisement Interface . . 19 93 4.3. CDNI Request Routing Redirection Interface . . . . . . . 19 94 4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 19 95 4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 21 97 5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 21 98 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 22 99 5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 24 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 101 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 27 102 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 28 103 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 28 104 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 28 105 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 29 106 6.4. CDNI URI Signing Verification Code . . . . . . . . . . . 29 107 6.5. CDNI URI Signing Signed Token Transport . . . . . . . . . 31 108 6.6. JSON Web Token Claims Registration . . . . . . . . . . . 31 109 6.6.1. Registry Contents . . . . . . . . . . . . . . . . . . 31 110 6.7. Expert Review Guidance . . . . . . . . . . . . . . . . . 32 111 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 112 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 113 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 114 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 116 11.1. Normative References . . . . . . . . . . . . . . . . . . 35 117 11.2. Informative References . . . . . . . . . . . . . . . . . 37 118 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 38 119 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 39 120 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 39 121 A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 40 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 124 1. Introduction 126 This document describes the concept of URI Signing and how it can be 127 used to provide access authorization in the case of redirection 128 between cooperating CDNs and between a Content Service Provider (CSP) 129 and a CDN. The primary goal of URI Signing is to make sure that only 130 authorized UAs are able to access the content, with a CSP being able 131 to authorize every individual request. It should be noted that URI 132 Signing is not a content protection scheme; if a CSP wants to protect 133 the content itself, other mechanisms, such as Digital Rights 134 Management (DRM), are more appropriate. In addition to access 135 control, URI Signing also has benefits in reducing the impact of 136 denial-of-service attacks. 138 The overall problem space for CDN Interconnection (CDNI) is described 139 in CDNI Problem Statement [RFC6707]. This document, along with the 140 CDNI Requirements [RFC7337] document and the CDNI Framework 141 [RFC7336], describes the need for interconnected CDNs to be able to 142 implement an access control mechanism that enforces a CSP's 143 distribution policies. 145 Specifically, the CDNI Framework [RFC7336] states: 147 The CSP may also trust the CDN operator to perform actions such as 148 delegating traffic to additional downstream CDNs, and to enforce 149 per-request authorization performed by the CSP using techniques 150 such as URI Signing. 152 In particular, the following requirement is listed in the CDNI 153 Requirements [RFC7337]: 155 MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of 156 authorization checks and verification that are to be performed by 157 the Surrogate before delivery. For example, this could 158 potentially include the need to verify information (e.g., Expiry 159 time, Client IP address) required for access authorization. 161 This document defines a method of signing URIs that allows Surrogates 162 in interconnected CDNs to enforce a per-request authorization 163 initiated by the CSP. Splitting the role of initiating per-request 164 authorization by the CSP and the role of verifying this authorization 165 by the CDN allows any arbitrary distribution policy to be enforced 166 across CDNs without the need of CDNs to have any awareness of the 167 specific CSP distribution policies. 169 The method is implemented using Signed JSON Web Tokens (JWTs) 170 [RFC7519]. 172 1.1. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in BCP 177 14 [RFC2119] [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 This document uses the terminology defined in the CDNI Problem 181 Statement [RFC6707]. 183 This document also uses the terminology of the JSON Web Token (JWT) 184 [RFC7519]. 186 In addition, the following terms are used throughout this document: 188 * Signed URI: A URI for which a signed JWT is provided. 190 * Target CDN URI: URI created by the CSP to direct a UA towards the 191 Upstream CDN (uCDN). The Target CDN URI can be signed by the CSP 192 and verified by the uCDN and possibly further Downstream CDNs 193 (dCDNs). 195 * Redirection URI: URI created by the uCDN to redirect a UA towards 196 the dCDN. The Redirection URI can be signed by the uCDN and 197 verified by the dCDN. In a cascaded CDNI scenario, there can be 198 more than one Redirection URI. 200 * Signed Token Renewal: A series of signed JWTs that are used for 201 subsequent access to a set of related resources in a CDN, such as 202 a set of HTTP Adaptive Streaming files. Every time a signed JWT 203 is used to access a particular resource, a new signed JWT is sent 204 along with the resource that can be used to request the next 205 resource in the set. When generating a new signed JWT in Signed 206 Token Renewal, parameters are carried over from one signed JWT to 207 the next. 209 1.2. Background and overview on URI Signing 211 A CSP and CDN are assumed to have a trust relationship that enables 212 the CSP to authorize access to a content item, which is realized in 213 practice by including a set of claims in a signed JWT in the URI 214 before redirecting a UA to the CDN. Using these attributes, it is 215 possible for a CDN to check an incoming content request to see 216 whether it was authorized by the CSP (e.g., based on the UA's IP 217 address or a time window). To prevent the UA from altering the 218 claims a JWT MUST be signed. 220 Figure 1, shown below, presents an overview of the URI Signing 221 mechanism in the case of a CSP with a single CDN. When the UA 222 browses for content on CSP's website (#1), it receives HTML web pages 223 with embedded content URIs. Upon requesting these URIs, the CSP 224 redirects to a CDN, creating a Target CDN URI (#2) (alternatively, 225 the Target CDN URI itself is embedded in the HTML). The Target CDN 226 URI is the Signed URI which may include the IP address of the UA and/ 227 or a time window. The signed URI always contains a signed JWT 228 generated by the CSP using a shared secret or private key. Once the 229 UA receives the response with the Signed URI, it sends a new HTTP 230 request using the Signed URI to the CDN (#3). Upon receiving the 231 request, the CDN authenticates the Signed URI by verifying the signed 232 JWT. If applicable, the CDN checks whether the source IP address of 233 the HTTP request matches the one in the Signed URI and/or if the time 234 window is still valid. After these claims are verified, the CDN 235 delivers the content (#4). 237 Note: While using a symmetric shared key is supported, it is NOT 238 RECOMMENDED. See the Security Considerations (Section 7) section 239 about the limitations of shared keys. 241 -------- 242 / \ 243 | CSP |< * * * * * * * * * * * 244 \ / Trust * 245 -------- relationship * 246 ^ | * 247 | | * 248 1. Browse | | 2. Signed * 249 for | | URI * 250 content | | * 251 | v v 252 +------+ 3. Signed URI -------- 253 | User |----------------->/ \ 254 | Agent| | CDN | 255 | |<-----------------\ / 256 +------+ 4. Content -------- 257 Delivery 259 Figure 1: URI Signing in a CDN Environment 261 1.3. CDNI URI Signing Overview 263 In a CDNI environment, as shown in Figure 2 below, URI Signing 264 operates the same way in the initial steps #1 and #2 but the later 265 steps involve multiple CDNs delivering the content. The main 266 difference from the single CDN case is a redirection step between the 267 uCDN and the dCDN. In step #3, the UA may send an HTTP request or a 268 DNS request, depending on whether HTTP-based or DNS-based request 269 routing is used. The uCDN responds by directing the UA towards the 270 dCDN using either a Redirection URI (i.e., a Signed URI generated by 271 the uCDN) or a DNS reply, respectively (#4). Once the UA receives 272 the response, it sends the Redirection URI/Target CDN URI to the dCDN 273 (#5). The received URI is verified by the dCDN before delivering the 274 content (#6). Note: The CDNI call flows are covered in Detailed URI 275 Signing Operation (Section 5). 277 +-------------------------+ 278 |Request Redirection Modes| 279 +-------------------------+ 280 | a) HTTP | 281 | b) DNS | 282 +-------------------------+ 283 -------- 284 / \< * * * * * * * * * * * * * * 285 | CSP |< * * * * * * * * * * * * 286 \ / Trust * * 287 -------- relationship * * 288 ^ | * * 289 | | 2. Signed * * 290 1. Browse | | URI in * * 291 for | | HTML * * 292 content | | * * 293 | v 3.a)Signed URI v * 294 +------+ b)DNS request -------- * Trust 295 | User |----------------->/ \ * relationship 296 | Agent| | uCDN | * (optional) 297 | |<-----------------\ / * 298 +------+ 4.a)Redirection URI------- * 299 ^ | b)DNS Reply ^ * 300 | | * * 301 | | Trust relationship * * 302 | | * * 303 6. Content | | 5.a)Redirection URI * * 304 delivery | | b)Signed URI(after v v 305 | | DNS exchange) -------- 306 | +---------------------->/ \ [May be 307 | | dCDN | cascaded 308 +--------------------------\ / CDNs] 309 -------- 311 Figure 2: URI Signing in a CDNI Environment 313 The trust relationships between CSP, uCDN, and dCDN have direct 314 implications for URI Signing. In the case shown in Figure 2, the CSP 315 has a trust relationship with the uCDN. The delivery of the content 316 may be delegated to a dCDN, which has a relationship with the uCDN 317 but may have no relationship with the CSP. 319 In CDNI, there are two methods for request routing: DNS-based and 320 HTTP-based. For DNS-based request routing, the Signed URI (i.e., the 321 Target CDN URI) provided by the CSP reaches the dCDN directly. In 322 the case where the dCDN does not have a trust relationship with the 323 CSP, this means that either an asymmetric public/private key method 324 needs to be used for computing the signed JWT (because the CSP and 325 dCDN are not able to exchange symmetric shared secret keys), or the 326 CSP needs to allow the uCDN to redistribute shared keys to a subset 327 of their dCDNs. 329 For HTTP-based request routing, the Signed URI (i.e., the Target CDN 330 URI) provided by the CSP reaches the uCDN. After this URI has been 331 verified by the uCDN, the uCDN creates and signs a new Redirection 332 URI, redirecting the UA to the dCDN. Since this new URI can have a 333 new signed JWT, the relationship between the dCDN and CSP is not 334 relevant. Because a relationship between uCDN and dCDN always 335 exists, either asymmetric public/private keys or symmetric shared 336 secret keys can be used for URI Signing with HTTP-based request 337 routing. Note that the signed Redirection URI MUST maintain HTTPS as 338 the scheme if it was present in the original and it MAY be upgraded 339 from HTTP to HTTPS. 341 Two types of keys can be used for URI Signing: asymmetric keys and 342 symmetric shared keys. Asymmetric keys are based on a public/private 343 key pair mechanism and always contain a private key known only to the 344 entity signing the URI (either CSP or uCDN) and a public key for the 345 verification of the Signed URI. With symmetric keys, the same key is 346 used by both the signing entity for signing the URI and the verifying 347 entity for verifying the Signed URI. Regardless of the type of keys 348 used, the verifying entity has to obtain the key in a manner that 349 allows trust to be placed in the assertions made using that key 350 (either the public or the symmetric key). There are very different 351 requirements (outside the scope of this document) for distributing 352 asymmetric keys and symmetric keys. Key distribution for symmetric 353 keys requires confidentiality to prevent third parties from getting 354 access to the key, since they could then generate valid Signed URIs 355 for unauthorized requests. Key distribution for asymmetric keys does 356 not require confidentiality since public keys can typically be 357 distributed openly (because they cannot be used to sign URIs) and the 358 corresponding private keys are kept secret by the URI signer. 360 Note: While using a symmetric shared key is supported, it is NOT 361 RECOMMENDED. See the Security Considerations (Section 7) section 362 about the limitations of shared keys. 364 1.4. URI Signing in a non-CDNI context 366 While the URI Signing method defined in this document was primarily 367 created for the purpose of allowing URI Signing in CDNI scenarios, 368 i.e., between a uCDN and a dCDN, there is nothing in the defined URI 369 Signing method that precludes it from being used in a non-CDNI 370 context. As such, the described mechanism could be used in a single- 371 CDN scenario such as shown in Figure 1 in Section 1.2, for example to 372 allow a CSP that uses different CDNs to only have to implement a 373 single URI Signing mechanism. 375 2. JWT Format and Processing Requirements 377 The concept behind URI Signing is based on embedding a signed JSON 378 Web Token (JWT) [RFC7519] in an HTTP or HTTPS URI [RFC7230] (see 379 [RFC7230] Section 2.7). The signed JWT contains a number of claims 380 that can be verified to ensure the UA has legitimate access to the 381 content. 383 This document specifies the following attribute for embedding a 384 signed JWT in a Target CDN URI or Redirection URI: 386 * URI Signing Package (URISigningPackage): The URI attribute that 387 encapsulates all the URI Signing claims in a signed JWT encoded 388 format. This attribute is exposed in the Signed URI as a path- 389 style parameter or a form-style parameter. 391 The parameter name of the URI Signing Package Attribute is defined in 392 the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is 393 not used, or does not include a parameter name for the URI Signing 394 Package Attribute, the parameter name can be set by configuration 395 (out of scope of this document). 397 The URI Signing Package will be found by parsing any path-style 398 parameters and form-style parameters looking for a key name matching 399 the URI Signing Package Attribute. Both parameter styles MUST be 400 supported to allow flexibility of operation. The first matching 401 parameter SHOULD be taken to provide the signed JWT, though providing 402 more than one matching key is undefined behavior. Path-style 403 parameters generated in the form indicated by Section 3.2.7 of 404 [RFC6570] MUST be supported. Form-style parameters generated in the 405 form indicated by Sections 3.2.8 and 3.2.9 of [RFC6570] MUST be 406 supported. 408 The following is an example where the URI Signing Package Attribute 409 name is "token" and the signed JWT is "SIGNEDJWT": 411 http://example.com/media/path?come=data&token=SIGNEDJWT&other=data 413 2.1. JWT Claims 415 This section identifies the set of claims that can be used to enforce 416 the CSP distribution policy. New claims can be introduced in the 417 future to extend the distribution policy capabilities. 419 In order to provide distribution policy flexibility, the exact subset 420 of claims used in a given signed JWT is a runtime decision. Claim 421 requirements are defined in the CDNI Metadata (Section 4.4). If the 422 CDNI Metadata interface is not used, or does not include claim 423 requirements, the claim requirements can be set by configuration (out 424 of scope of this document). 426 The following claims (where the "JSON Web Token Claims" registry 427 claim name is specified in parenthesis below) are used to enforce the 428 distribution policies. All of the listed claims are mandatory to 429 implement in a URI Signing implementation, but are not mandatory to 430 use in a given signed JWT. (The "optional" and "mandatory" 431 identifiers in square brackets refer to whether or not a given claim 432 MUST be present in a URI Signing JWT.) 434 Note: The time on the entities that generate and verify the signed 435 URI MUST be in sync. In the CDNI case, this means that CSP, uCDN, 436 and dCDN servers need to be time-synchronized. It is RECOMMENDED to 437 use NTP [RFC5905] for time synchronization. 439 Note: See the Security Considerations (Section 7) section on the 440 limitations of using an expiration time and client IP address for 441 distribution policy enforcement. 443 2.1.1. Issuer (iss) claim 445 Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1 446 MUST be followed. If this claim is used, it MUST be used to confirm 447 that the indicated key was provided by said issuer and used to sign 448 the JWT. If the CDN verifying the signed JWT does not support Issuer 449 verification, or if the Issuer in the signed JWT does not match the 450 list of known acceptable Issuers, the CDN MUST reject the request. 451 If the received signed JWT contains an Issuer claim, then any JWT 452 subsequently generated for CDNI redirection MUST also contain an 453 Issuer claim, and the Issuer value MUST be updated to identify the 454 redirecting CDN. If the received signed JWT does not contain an 455 Issuer claim, an Issuer claim MAY be added to a signed JWT generated 456 for CDNI redirection. 458 2.1.2. Subject (sub) claim 460 Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2 461 MUST be followed. If this claim is used, it MUST be a JSON Web 462 Encryption (JWE [RFC7516]) Object in compact serialization form, 463 because it contains personally identifiable information. This claim 464 contains information about the subject (for example, a user or an 465 agent) that MAY be used to verify the signed JWT. If the received 466 signed JWT contains a Subject claim, then any JWT subsequently 467 generated for CDNI redirection MUST also contain a Subject claim, and 468 the Subject value MUST be the same as in the received signed JWT. A 469 signed JWT generated for CDNI redirection MUST NOT add a Subject 470 claim if no Subject claim existed in the received signed JWT. 472 2.1.3. Audience (aud) claim 474 Audience (aud) [optional] - The semantics in [RFC7519] Section 4.1.3 475 MUST be followed. This claim is used to ensure that the CDN 476 verifying the JWT is an intended recipient of the request. The claim 477 MUST contain an identity on behalf of whom the CDN can verify the 478 token (e.g., the CSP or any CDN in the chain). A CDN MAY modify the 479 claim as long it can generate a valid signature. 481 2.1.4. Expiry Time (exp) claim 483 Expiry Time (exp) [optional] - The semantics in [RFC7519] 484 Section 4.1.4 MUST be followed, though URI Signing implementations 485 MUST NOT allow for any time synchronization "leeway". If this claim 486 is used and the CDN verifying the signed JWT does not support Expiry 487 Time verification, or if the Expiry Time in the signed JWT 488 corresponds to a time equal to or earlier than the time of the 489 content request, the CDN MUST reject the request. If the received 490 signed JWT contains a Expiry Time claim, then any JWT subsequently 491 generated for CDNI redirection MUST also contain an Expiry Time 492 claim, and the Expiry Time value MUST be the same as in the received 493 signed JWT. A signed JWT generated for CDNI redirection MUST NOT add 494 an Expiry Time claim if no Expiry Time claim existed in the received 495 signed JWT. 497 2.1.5. Not Before (nbf) claim 499 Not Before (nbf) [optional] - The semantics in [RFC7519] 500 Section 4.1.5 MUST be followed, though URI Signing implementations 501 MUST NOT allow for any time synchronization "leeway". If this claim 502 is used and the CDN verifying the signed JWT does not support Not 503 Before time verification, or if the Not Before time in the signed JWT 504 corresponds to a time later than the time of the content request, the 505 CDN MUST reject the request. If the received signed JWT contains a 506 Not Before time claim, then any JWT subsequently generated for CDNI 507 redirection MUST also contain a Not Before time claim, and the Not 508 Before time value MUST be the same as in the received signed JWT. A 509 signed JWT generated for CDNI redirection MUST NOT add a Not Before 510 time claim if no Not Before time claim existed in the received signed 511 JWT. 513 2.1.6. Issued At (iat) claim 515 Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6 516 MUST be followed. If the received signed JWT contains an Issued At 517 claim, then any JWT subsequently generated for CDNI redirection MUST 518 also contain an Issued At claim, and the Issued At value MUST be 519 updated to identify the time the new JWT was generated. If the 520 received signed JWT does not contain an Issued At claim, an Issued At 521 claim MAY be added to a signed JWT generated for CDNI redirection. 523 2.1.7. JWT ID (jti) claim 525 JWT ID (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 526 MUST be followed. A JWT ID can be used to prevent replay attacks if 527 the CDN stores a list of all previously used values, and verifies 528 that the value in the current JWT has never been used before. If the 529 signed JWT contains a JWT ID claim and the CDN verifying the signed 530 JWT either does not support JWT ID storage or has previously seen the 531 value used in a request for the same content, then the CDN MUST 532 reject the request. If the received signed JWT contains a JWT ID 533 claim, then any JWT subsequently generated for CDNI redirection MUST 534 also contain a JWT ID claim, and the value MUST be the same as in the 535 received signed JWT. If the received signed JWT does not contain a 536 JWT ID claim, a JWT ID claim MUST NOT be added to a signed JWT 537 generated for CDNI redirection. Sizing of the JWT ID is application 538 dependent given the desired security constraints. 540 2.1.8. CDNI Claim Set Version (cdniv) claim 542 CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set 543 Version (cdniv) claim provides a means within a signed JWT to tie the 544 claim set to a specific version of this specification. The cdniv 545 claim is intended to allow changes in and facilitate upgrades across 546 specifications. The type is JSON integer and the value MUST be set 547 to "1", for this version of the specification. In the absence of 548 this claim, the value is assumed to be "1". For future versions this 549 claim will be mandatory. Implementations MUST reject signed JWTs 550 with unsupported CDNI Claim Set versions. 552 2.1.9. CDNI Critical Claims Set (cdnicrit) claim 554 CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical 555 Claims Set (cdnicrit) claim indicates that extensions to this 556 specification are being used that MUST be understood and processed. 557 Its value is a comma separated listing of claims in the Signed JWT 558 that use those extensions. If any of the listed extension claims are 559 not understood and supported by the recipient, then the Signed JWT 560 MUST be rejected. Producers MUST NOT include claim names defined by 561 this specification, duplicate names, or names that do not occur as 562 claim names within the Signed JWT in the cdnicrit list. Producers 563 MUST NOT use the empty list "" as the cdnicrit value. Recipients MAY 564 consider the Signed JWT to be invalid if the cdnicrit list contains 565 any claim names defined by this specification or if any other 566 constraints on its use are violated. This claim MUST be understood 567 and processed by all implementations. 569 2.1.10. Client IP (cdniip) claim 571 Client IP (cdniip) [optional] - The Client IP (cdniip) claim holds an 572 IP address or IP prefix for which the Signed URI is valid. This is 573 represented in CIDR notation, with dotted decimal format for IPv4 574 addresses [RFC0791] or canonical text representation for IPv6 575 addresses [RFC5952]. The request MUST be rejected if sourced from a 576 client outside of the specified IP range. Since the client IP is 577 considered personally identifiable information this field MUST be a 578 JSON Web Encryption (JWE [RFC7516]) Object in compact serialization 579 form. If the CDN verifying the signed JWT does not support Client IP 580 verification, or if the Client IP in the signed JWT does not match 581 the source IP address in the content request, the CDN MUST reject the 582 request. The type of this claim is a JSON string that contains the 583 JWE. If the received signed JWT contains a Client IP claim, then any 584 JWT subsequently generated for CDNI redirection MUST also contain a 585 Client IP claim, and the Client IP value MUST be the same as in the 586 received signed JWT. A signed JWT generated for CDNI redirection 587 MUST NOT add a Client IP claim if no Client IP claim existed in the 588 received signed JWT. 590 It should be noted that use of this claim can cause issues, for 591 example, in situations with dual-stack IPv4 and IPv6 networks, MPTCP, 592 QUIC, and mobile clients switching from WiFi to Cellular networks 593 where the client's source address can change, even between address 594 families. This claim exists mainly for legacy feature parity 595 reasons, therefore use of this claim should be done judiciously. An 596 example of a reasonable use case would be making a signed JWT for an 597 internal preview of an asset where the end consumer understands that 598 they must be originated from the same IP for the entirety of the 599 session. Using this claim at large is NOT RECOMMENDED. 601 2.1.11. CDNI URI Container (cdniuc) claim 603 URI Container (cdniuc) [mandatory] - The URI Container (cdniuc) holds 604 the URI representation before a URI Signing Package is added. This 605 representation can take one of several forms detailed in 606 Section 2.1.15. If the URI Container used in the signed JWT does not 607 match the URI of the content request, the CDN verifying the signed 608 JWT MUST reject the request. When comparing the URI, the percent 609 encoded form as defined in [RFC3986] Section 2.1 MUST be used. When 610 redirecting a URI, the CDN generating the new signed JWT MAY change 611 the URI Container to comport with the URI being used in the 612 redirection. 614 2.1.12. CDNI Expiration Time Setting (cdniets) claim 616 CDNI Expiration Time Setting (cdniets) [optional] - The CDNI 617 Expiration Time Setting (cdniets) claim provides a means for setting 618 the value of the Expiry Time (exp) claim when generating a subsequent 619 signed JWT in Signed Token Renewal. Its type is a JSON numeric 620 value. It denotes the number of seconds to be added to the time at 621 which the JWT is verified that gives the value of the Expiry Time 622 (exp) claim of the next signed JWT. The CDNI Expiration Time Setting 623 (cdniets) SHOULD NOT be used when not using Signed Token Renewal and 624 MUST be present when using Signed Token Renewal. 626 2.1.13. CDNI Signed Token Transport (cdnistt) claim 628 CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed 629 Token Transport (cdnistt) claim provides a means of signalling the 630 method through which a new signed JWT is transported from the CDN to 631 the UA and vice versa for the purpose of Signed Token Renewal. Its 632 type is a JSON integer. Values for this claim are defined in 633 Section 6.5. If using this claim you MUST also specify a CDNI 634 Expiration Time Setting (cdniets) as noted above. 636 2.1.14. CDNI Signed Token Depth (cdnistd) claim 638 CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token 639 Depth (cdnistd) claim is used to associate a subsequent signed JWT, 640 generated as the result of a CDNI Signed Token Transport claim, with 641 a specific URI subset. Its type is a JSON integer. Signed JWTs MUST 642 NOT use a negative value for the CDNI Signed Token Depth claim. 644 If the transport used for Signed Token Transport allows the CDN to 645 associate the path component of a URI with tokens (e.g., an HTTP 646 Cookie Path as described in section 4.1.2.4 of [RFC6265]), the CDNI 647 Signed Token Depth value is the number of path segments that should 648 be considered significant for this association. A CDNI Signed Token 649 Depth of zero means that the client SHOULD be directed to return the 650 token with requests for any path. If the CDNI Signed Token Depth is 651 greater than zero, then the client SHOULD be directed to return the 652 token for future requests wherein the first CDNI Signed Token Depth 653 segments of the path match the first CDNI Signed Token Depth segments 654 of the signed URI path. This matching MUST use the URI with the 655 token removed, as specified in Section 2.1.15. 657 If the URI path to match contains fewer segments than the CDNI Signed 658 Token Depth claim, a signed JWT MUST NOT be generated for the 659 purposes of Signed Token Renewal. If the CDNI Signed Token Depth 660 claim is omitted, it means the same thing as if its value were zero. 661 If the received signed JWT contains a CDNI Signed Token Depth claim, 662 then any JWT subsequently generated for CDNI redirection or Signed 663 Token Transport MUST also contain a CDNI Signed Token Depth claim, 664 and the value MUST be the same as in the received signed JWT. 666 2.1.15. URI Container Forms 668 The URI Container (cdniuc) claim takes one of the following forms: 669 'hash:' or 'regex:'. More forms may be added in the future to extend 670 the capabilities. 672 Before comparing a URI with contents of this container, the following 673 steps MUST be performed: 675 * Prior to verification, remove the signed JWT from the URI. This 676 removal is only for the purpose of determining if the URI matches; 677 all other purposes will use the original URI. If the signed JWT 678 is terminated by anything other than a sub-delimiter (as defined 679 in [RFC3986] Section 2.2), everything from the reserved character 680 (as defined in [RFC3986] Section 2.2) that precedes the URI 681 Signing Package Attribute to the last character of the signed JWT 682 will be removed, inclusive. Otherwise, everything from the first 683 character of the URI Signing Package Attribute to the sub- 684 delimiter that terminates the signed JWT will be removed, 685 inclusive. 687 * Normalize the URI according to section 2.7.3 [RFC7230] and 688 sections 6.2.2 and 6.2.3 [RFC3986]. This applies to both 689 generation and verification of the signed JWT. 691 2.1.15.1. URI Hash Container (hash:) 693 Prefixed with 'hash:', this string is a URL Segment form ([RFC6920] 694 Section 5) of the URI. 696 2.1.15.2. URI Regular Expression Container (regex:) 698 Prefixed with 'regex:', this string is any POSIX Section 9 [POSIX.1] 699 Extended Regular Expression compatible regular expression used to 700 match against the requested URI. These regular expressions MUST be 701 evaluated in the POSIX locale (POSIX Section 7.2 [POSIX.1]). 703 Note: Because '\' has special meaning in JSON [RFC8259] as the escape 704 character within JSON strings, the regular expression character '\' 705 MUST be escaped as '\\'. 707 An example of a 'regex:' is the following: 709 [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)? 711 Note: Due to computational complexity of executing arbitrary regular 712 expressions, it is RECOMMENDED to only execute after verifying the 713 JWT to ensure its authenticity. 715 2.2. JWT Header 717 The header of the JWT MAY be passed via the CDNI Metadata interface 718 instead of being included in the URISigningPackage. The header value 719 MUST be transmitted in the serialized encoded form and prepended to 720 the JWT payload and signature passed in the URISigningPackage prior 721 to verification. This reduces the size of the signed JWT token. 723 3. URI Signing Token Renewal 725 3.1. Overview 727 For content that is delivered via HTTP in a segmented fashion, such 728 as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216], 729 special provisions need to be made in order to ensure URI Signing can 730 be applied. In general, segmented protocols work by breaking large 731 objects (e.g., videos) into a sequence of small independent segments. 732 Such segments are then referenced by a separate manifest file, which 733 either includes a list of URLs to the segments or specifies an 734 algorithm through which a User Agent can construct the URLs to the 735 segments. Requests for segments therefore originate from the 736 manifest file and, unless the URLs in the manifest file point to the 737 CSP, are not subjected to redirection and URI Signing. This opens up 738 a vulnerability to malicious User Agents sharing the manifest file 739 and deep-linking to the segments. 741 One method for dealing with this vulnerability would be to include, 742 in the manifest itself, Signed URIs that point to the individual 743 segments. There exist a number of issues with that approach. First, 744 it requires the CDN delivering the manifest to rewrite the manifest 745 file for each User Agent, which would require the CDN to be aware of 746 the exact segmentation protocol used. Secondly, it could also 747 require the expiration time of the Signed URIs to be valid for an 748 extended duration if the content described by the manifest is meant 749 to be consumed in real time. For instance, if the manifest file were 750 to contain a segmented video stream of more than 30 minutes in 751 length, Signed URIs would require to be valid for a at least 30 752 minutes, thereby reducing their effectiveness and that of the URI 753 Signing mechanism in general. For a more detailed analysis of how 754 segmented protocols such as HTTP Adaptive Streaming protocols affect 755 CDNI, see Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. 757 The method described in this section allows CDNs to use URI Signing 758 for segmented content without having to include the Signed URIs in 759 the manifest files themselves. 761 3.2. Signed Token Renewal mechanism 763 In order to allow for effective access control of segmented content, 764 the URI Signing mechanism defined in this section is based on a 765 method through which subsequent segment requests can be linked 766 together. As part of the JWT verification procedure, the CDN can 767 generate a new signed JWT that the UA can use to do a subsequent 768 request. More specifically, whenever a UA successfully retrieves a 769 segment, it receives, in the HTTP 2xx Successful message, a signed 770 JWT that it can use whenever it requests the next segment. As long 771 as each successive signed JWT is correctly verified before a new one 772 is generated, the model is not broken and the User Agent can 773 successfully retrieve additional segments. Given the fact that with 774 segmented protocols, it is usually not possible to determine a priori 775 which segment will be requested next (i.e., to allow for seeking 776 within the content and for switching to a different representation), 777 the Signed Token Renewal uses the URI Regular Expression Container 778 scoping mechanisms in the URI Container (cdniuc) claim to allow a 779 signed JWT to be valid for more than one URL. 781 In order for this renewal of signed JWTs to work, it is necessary for 782 a UA to extract the signed JWT from the HTTP 2xx Successful message 783 of an earlier request and use it to retrieve the next segment. The 784 exact mechanism by which the client does this is outside the scope of 785 this document. However, in order to also support legacy UAs that do 786 not include any specific provisions for the handling of signed JWTs, 787 Section 3.3 defines a mechanism using HTTP Cookies [RFC6265] that 788 allows such UAs to support the concept of renewing signed JWTs 789 without requiring any additional UA support. 791 3.2.1. Required Claims 793 The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12) 794 MUST both be present for Signed Token Renewal. cdnistt MAY be set to 795 a value of '0' to mean no Signed Token Renewal, but there still MUST 796 be a corresponding cdniets that verifies as a JSON number. However, 797 if use of Signed Token Renewal is not desired, it is RECOMMENDED to 798 simply omit both. 800 3.3. Communicating a signed JWTs in Signed Token Renewal 802 This section assumes the value of the CDNI Signed Token Transport 803 (cdnistt) claim has been set to 1. 805 When using the Signed Token Renewal mechanism, the signed JWT is 806 transported to the UA via a 'URISigningPackage' cookie added to the 807 HTTP 2xx Successful message along with the content being returned to 808 the UA, or to the HTTP 3xx Redirection message in case the UA is 809 redirected to a different server. 811 3.3.1. Support for cross-domain redirection 813 For security purposes, the use of cross-domain cookies is not 814 supported in some application environments. As a result, the Cookie- 815 based method for transport of the Signed Token described in 816 Section 3.3 might break if used in combination with an HTTP 3xx 817 Redirection response where the target URL is in a different domain. 818 In such scenarios, Signed Token Renewal of a signed JWT SHOULD be 819 communicated via the query string instead, in a similar fashion to 820 how regular signed JWTs (outside of Signed Token Renewal) are 821 communicated. Note the value of the CDNI Signed Token Transport 822 (cdnistt) claim MUST be set to 2. 824 Note that the process described herein only works in cases where both 825 the manifest file and segments constituting the segmented content are 826 delivered from the same domain. In other words, any redirection 827 between different domains needs to be carried out while retrieving 828 the manifest file. 830 4. Relationship with CDNI Interfaces 832 Some of the CDNI Interfaces need enhancements to support URI Signing. 833 A dCDN that supports URI Signing needs to be able to advertise this 834 capability to the uCDN. The uCDN needs to select a dCDN based on 835 such capability when the CSP requires access control to enforce its 836 distribution policy via URI Signing. Also, the uCDN needs to be able 837 to distribute via the CDNI Metadata interface the information 838 necessary to allow the dCDN to verify a Signed URI. Events that 839 pertain to URI Signing (e.g., request denial or delivery after an 840 access authorization decision has been made) need to be included in 841 the logs communicated through the CDNI Logging interface. 843 4.1. CDNI Control Interface 845 URI Signing has no impact on this interface. 847 4.2. CDNI Footprint & Capabilities Advertisement Interface 849 The CDNI Request Routing: Footprint and Capabilities Semantics 850 document [RFC8008] defines support for advertising CDNI Metadata 851 capabilities, via CDNI Payload Type. The CDNI Payload Type 852 registered in Section 6.1 can be used for capability advertisement. 854 4.3. CDNI Request Routing Redirection Interface 856 The CDNI Request Routing Redirection Interface [RFC7975] describes 857 the recursive request redirection method. For URI Signing, the uCDN 858 signs the URI provided by the dCDN. URI Signing therefore has no 859 impact on this interface. 861 4.4. CDNI Metadata Interface 863 The CDNI Metadata Interface [RFC8006] describes the CDNI metadata 864 distribution needed to enable content acquisition and delivery. For 865 URI Signing, a new CDNI metadata object is specified. 867 The UriSigning Metadata object contains information to enable URI 868 Signing and verification by a dCDN. The UriSigning properties are 869 defined below. 871 Property: enforce 873 Description: URI Signing enforcement flag. Specifically, this 874 flag indicates if the access to content is subject to URI 875 Signing. URI Signing requires the dCDN to ensure that the URI 876 is signed and verified before delivering content. Otherwise, 877 the dCDN does not perform verification, regardless of whether 878 or not the URI is signed. 880 Type: Boolean 882 Mandatory-to-Specify: No. The default is true. 884 Property: issuers 886 Description: A list of valid Issuers against which the Issuer 887 claim in the signed JWT may be cross-referenced. 889 Type: Array of Strings 891 Mandatory-to-Specify: No. The default is an empty list. An 892 empty list means that any Issuer is acceptable. 894 Property: package-attribute 895 Description: The attribute name to use for the URI Signing 896 Package. 898 Type: String 900 Mandatory-to-Specify: No. The default is "URISigningPackage". 902 Property: jwt-header 904 Description: The header part of JWT that is used for verifying 905 a signed JWT when the JWT token in the URI Signing Package does 906 not contain a header part. 908 Type: String 910 Mandatory-to-Specify: No. By default, the header is assumed to 911 be included in the JWT token. 913 The following is an example of a URI Signing metadata payload with 914 all default values: 916 { 917 "generic-metadata-type": "MI.UriSigning" 918 "generic-metadata-value": {} 919 } 921 The following is an example of a URI Signing metadata payload with 922 explicit values: 924 { 925 "generic-metadata-type": "MI.UriSigning" 926 "generic-metadata-value": 927 { 928 "enforce": true, 929 "issuers": ["csp", "ucdn1", "ucdn2"], 930 "package-attribute": "usp", 931 "jwt-header": 932 { 933 "alg": "ES256", 934 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0" 935 } 936 } 937 } 939 4.5. CDNI Logging Interface 941 For URI Signing, the dCDN reports that enforcement of the access 942 control was applied to the request for content delivery. When the 943 request is denied due to enforcement of URI Signing, the reason is 944 logged. 946 The following CDNI Logging field for URI Signing SHOULD be supported 947 in the HTTP Request Logging Record as specified in CDNI Logging 948 Interface [RFC7937], using the new "cdni_http_request_v2" record-type 949 registered in Section 6.2.1. 951 * s-uri-signing (mandatory): 953 - format: 3DIGIT 955 - field value: this characterises the URI Signing verification 956 performed by the Surrogate on the request. The allowed values 957 are registered in Section 6.4. 959 - occurrence: there MUST be zero or exactly one instance of this 960 field. 962 * s-uri-signing-deny-reason (optional): 964 - format: QSTRING 966 - field value: a string for providing further information in case 967 the signed JWT was rejected, e.g., for debugging purposes. 969 - occurrence: there MUST be zero or exactly one instance of this 970 field. 972 5. URI Signing Message Flow 974 URI Signing supports both HTTP-based and DNS-based request routing. 975 JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of 976 representing claims to be transferred between two parties. The 977 claims in a Signed JWT are encoded as a JSON object that is used as 978 the payload of a JSON Web Signature (JWS) structure enabling the 979 claims to be digitally signed or integrity protected with a Message 980 Authentication Code (MAC). 982 5.1. HTTP Redirection 984 For HTTP-based request routing, a set of information that is unique 985 to a given end user content request is included in a Signed JWT, 986 using key information that is specific to a pair of adjacent CDNI 987 hops (e.g., between the CSP and the uCDN or between the uCDN and a 988 dCDN). This allows a CDNI hop to ascertain the authenticity of a 989 given request received from a previous CDNI hop. 991 The URI Signing method (assuming HTTP redirection, iterative request 992 routing, and a CDN path with two CDNs) includes the following steps: 994 End-User dCDN uCDN CSP 995 | | | | 996 | 1.CDNI FCI interface used to | | 997 | advertise URI Signing capability| | 998 | |------------------->| | 999 | | | | 1000 | 2.Provides information to verify Signed JWT | 1001 | | |<-------------------| 1002 | | | | 1003 | 3.CDNI Metadata interface used to| | 1004 | provide URI Signing attributes| | 1005 | |<-------------------| | 1006 : : : : 1007 : (Later in time) : : : 1008 |4.Authorization request | | 1009 |------------------------------------------------------------->| 1010 | | | [Apply distribution 1011 | | | policy] | 1012 | | | | 1013 | | (ALT: Authorization decision) 1014 |5.Request is denied | | | 1015 |<-------------------------------------------------------------| 1016 | | | | 1017 |6.CSP provides signed URI | | 1018 |<-------------------------------------------------------------| 1019 | | | | 1020 |7.Content request | | | 1021 |---------------------------------------->| [Verifiy URI | 1022 | | | signature] | 1023 | | | | 1024 | | (ALT: Verification result) | 1025 |8.Request is denied | | | 1026 |<----------------------------------------| | 1027 | | | | 1028 |9.Re-sign URI and redirect to | | 1029 | dCDN (newly signed URI) | | 1030 |<----------------------------------------| | 1031 | | | | 1032 |10.Content request | | | 1033 |------------------->| [Verify URI | | 1034 | | signature] | | 1035 | | | | 1036 | (ALT: Verification result) | | 1037 |11.Request is denied| | | 1038 |<-------------------| | | 1039 | | | | 1040 |12.Content delivery | | | 1041 |<-------------------| | | 1042 : : : : 1043 : (Later in time) : : : 1044 |13.CDNI Logging interface to include URI Signing information | 1045 | |------------------->| | 1047 Figure 3: HTTP-based Request Routing with URI Signing 1049 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1050 the dCDN advertises its capabilities including URI Signing 1051 support to the uCDN. 1053 2. CSP provides to the uCDN the information needed to verify signed 1054 URIs from that CSP. For example, this information will include 1055 one or more keys used for validation. 1057 3. Using the CDNI Metadata interface, the uCDN communicates to a 1058 dCDN the information needed to verify signed URIs from the uCDN 1059 for the given CSP. For example, this information may include 1060 the URI query string parameter name for the URI Signing Package 1061 Attribute in addition to keys used for validation. 1063 4. When a UA requests a piece of protected content from the CSP, 1064 the CSP makes a specific authorization decision for this unique 1065 request based on its local distribution policy. 1067 5. If the authorization decision is negative, the CSP rejects the 1068 request and sends an error code (e.g., 403 Forbidden) in the 1069 HTTP response. 1071 6. If the authorization decision is positive, the CSP computes a 1072 Signed JWT that is based on unique parameters of that request 1073 and conveys it to the end user as the URI to use to request the 1074 content. 1076 7. On receipt of the corresponding content request, the uCDN 1077 verifies the Signed JWT in the URI using the information 1078 provided by the CSP. 1080 8. If the verification result is negative, the uCDN rejects the 1081 request and sends an error code 403 Forbidden in the HTTP 1082 response. 1084 9. If the verification result is positive, the uCDN computes a 1085 Signed JWT that is based on unique parameters of that request 1086 and provides it to the end user as the URI to use to further 1087 request the content from the dCDN. 1089 10. On receipt of the corresponding content request, the dCDN 1090 verifies the Signed JWT in the signed URI using the information 1091 provided by the uCDN in the CDNI Metadata. 1093 11. If the verification result is negative, the dCDN rejects the 1094 request and sends an error code 403 Forbidden in the HTTP 1095 response. 1097 12. If the verification result is positive, the dCDN serves the 1098 request and delivers the content. 1100 13. At a later time, the dCDN reports logging events that include 1101 URI Signing information. 1103 With HTTP-based request routing, URI Signing matches well the general 1104 chain of trust model of CDNI both with symmetric and asymmetric keys 1105 because the key information only needs to be specific to a pair of 1106 adjacent CDNI hops. 1108 Note: While using a symmetric shared key is supported, it is NOT 1109 RECOMMENDED. See the Security Considerations (Section 7) section 1110 about the limitations of shared keys. 1112 5.2. DNS Redirection 1114 For DNS-based request routing, the CSP and uCDN must agree on a trust 1115 model appropriate to the security requirements of the CSP's 1116 particular content. Use of asymmetric public/private keys allows for 1117 unlimited distribution of the public key to dCDNs. However, if a 1118 shared secret key is preferred, then the CSP may want to restrict the 1119 distribution of the key to a (possibly empty) subset of trusted 1120 dCDNs. Authorized Delivery CDNs need to obtain the key information 1121 to verify the signed URI. 1123 Note: While using a symmetric shared key is supported, it is NOT 1124 RECOMMENDED. See the Security Considerations (Section 7) section 1125 about the limitations of shared keys. 1127 The URI Signing method (assuming iterative DNS request routing and a 1128 CDN path with two CDNs) includes the following steps. 1130 End-User dCDN uCDN CSP 1131 | | | | 1132 | 1.CDNI FCI interface used to | | 1133 | advertise URI Signing capability| | 1134 | |------------------->| | 1135 | | | | 1136 | 2.Provides information to verify Signed JWT | 1137 | | |<-------------------| 1138 | 3.CDNI Metadata interface used to| | 1139 | provide URI Signing attributes| | 1140 | |<-------------------| | 1141 : : : : 1142 : (Later in time) : : : 1143 |4.Authorization request | | 1144 |------------------------------------------------------------->| 1145 | | | [Apply distribution 1146 | | | policy] | 1147 | | | | 1148 | | (ALT: Authorization decision) 1149 |5.Request is denied | | | 1150 |<-------------------------------------------------------------| 1151 | | | | 1152 |6.Provides signed URI | | 1153 |<-------------------------------------------------------------| 1154 | | | | 1155 |7.DNS request | | | 1156 |---------------------------------------->| | 1157 | | | | 1158 |8.Redirect DNS to dCDN | | 1159 |<----------------------------------------| | 1160 | | | | 1161 |9.DNS request | | | 1162 |------------------->| | | 1163 | | | | 1164 |10.IP address of Surrogate | | 1165 |<-------------------| | | 1166 | | | | 1167 |11.Content request | | | 1168 |------------------->| [Verify URI | | 1169 | | signature] | | 1170 | | | | 1171 | (ALT: Verification result) | | 1172 |12.Request is denied| | | 1173 |<-------------------| | | 1174 | | | | 1175 |13.Content delivery | | | 1176 |<-------------------| | | 1177 : : : : 1178 : (Later in time) : : : 1179 |14.CDNI Logging interface to report URI Signing information | 1180 | |------------------->| | 1182 Figure 4: DNS-based Request Routing with URI Signing 1184 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1185 the dCDN advertises its capabilities including URI Signing 1186 support to the uCDN. 1188 2. CSP provides to the uCDN the information needed to verify Signed 1189 JWTs from that CSP. For example, this information will include 1190 one or more keys used for validation. 1192 3. Using the CDNI Metadata interface, the uCDN communicates to a 1193 dCDN the information needed to verify Signed JWTs from the CSP 1194 (e.g., the URI query string parameter name for the URI Signing 1195 Package Attribute). In the case of symmetric shared key, the 1196 uCDN checks if the dCDN is allowed by CSP to obtain the shared 1197 secret key. 1199 4. When a UA requests a piece of protected content from the CSP, 1200 the CSP makes a specific authorization decision for this unique 1201 request based on its local distribution policy. 1203 5. If the authorization decision is negative, the CSP rejects the 1204 request and sends an error code (e.g., 403 Forbidden) in the 1205 HTTP response. 1207 6. If the authorization decision is positive, the CSP computes a 1208 Signed JWT that is based on unique parameters of that request 1209 and includes it in the URI provided to the end user to request 1210 the content. 1212 7. End user sends DNS request to the uCDN. 1214 8. On receipt of the DNS request, the uCDN redirects the request to 1215 the dCDN. 1217 9. End user sends DNS request to the dCDN. 1219 10. On receipt of the DNS request, the dCDN responds with IP address 1220 of one of its Surrogates. 1222 11. On receipt of the corresponding content request, the dCDN 1223 verifies the Signed JWT in the URI using the information 1224 provided by the uCDN in the CDNI Metadata. 1226 12. If the verification result is negative, the dCDN rejects the 1227 request and sends an error code 403 Forbidden in the HTTP 1228 response. 1230 13. If the verification result is positive, the dCDN serves the 1231 request and delivers the content. 1233 14. At a later time, dCDN reports logging events that includes URI 1234 Signing information. 1236 With DNS-based request routing, URI Signing matches well the general 1237 chain of trust model of CDNI when used with asymmetric keys because 1238 the only key information that needs to be distributed across 1239 multiple, possibly untrusted, CDNI hops is the public key, which is 1240 generally not confidential. 1242 With DNS-based request routing, URI Signing does not match well with 1243 the general chain of trust model of CDNI when used with symmetric 1244 keys because the symmetric key information needs to be distributed 1245 across multiple CDNI hops, to CDNs with which the CSP may not have a 1246 trust relationship. This raises a security concern for applicability 1247 of URI Signing with symmetric keys in case of DNS-based inter-CDN 1248 request routing. Due to these concerns, this architecture is NOT 1249 RECOMMENDED. 1251 Note: While using a symmetric shared key is supported, it is NOT 1252 RECOMMENDED. See the Security Considerations (Section 7) section 1253 about the limitations of shared keys. 1255 6. IANA Considerations 1257 6.1. CDNI Payload Type 1259 This document requests the registration of the following CDNI Payload 1260 Type under the IANA "CDNI Payload Types" registry: 1262 +===============+===============+ 1263 | Payload Type | Specification | 1264 +===============+===============+ 1265 | MI.UriSigning | RFCthis | 1266 +---------------+---------------+ 1268 Table 1 1270 [RFC Editor: Please replace RFCthis with the published RFC number for 1271 this document.] 1273 6.1.1. CDNI UriSigning Payload Type 1275 Purpose: The purpose of this payload type is to distinguish 1276 UriSigning MI objects (and any associated capability advertisement). 1278 Interface: MI/FCI 1280 Encoding: see Section 4.4 1282 6.2. CDNI Logging Record Type 1284 This document requests the registration of the following CDNI Logging 1285 record-type under the IANA "CDNI Logging record-types" registry: 1287 +======================+===========+===========================+ 1288 | record-types | Reference | Description | 1289 +======================+===========+===========================+ 1290 | cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | 1291 | | | Record version 1 for | 1292 | | | content delivery using | 1293 | | | HTTP, to include URI | 1294 | | | Signing logging fields | 1295 +----------------------+-----------+---------------------------+ 1297 Table 2 1299 [RFC Editor: Please replace RFCthis with the published RFC number for 1300 this document.] 1302 6.2.1. CDNI Logging Record Version 2 for HTTP 1304 The "cdni_http_request_v2" record-type supports all of the fields 1305 supported by the "cdni_http_request_v1" record-type [RFC7937] plus 1306 the two additional fields "s-uri-signing" and "s-uri-signing-deny- 1307 reason", registered by this document in Section 6.3. The name, 1308 format, field value, and occurence information for the two new fields 1309 can be found in Section 4.5 of this document. 1311 6.3. CDNI Logging Field Names 1313 This document requests the registration of the following CDNI Logging 1314 fields under the IANA "CDNI Logging Field Names" registry: 1316 +===========================+===========+ 1317 | Field Name | Reference | 1318 +===========================+===========+ 1319 | s-uri-signing | RFCthis | 1320 +---------------------------+-----------+ 1321 | s-uri-signing-deny-reason | RFCthis | 1322 +---------------------------+-----------+ 1324 Table 3 1326 [RFC Editor: Please replace RFCthis with the published RFC number for 1327 this document.] 1329 6.4. CDNI URI Signing Verification Code 1331 The IANA is requested to create a new "CDNI URI Signing Verification 1332 Code" subregistry, in the "Content Delivery Networks Interconnection 1333 (CDNI) Parameters" registry. The "CDNI URI Signing Verification 1334 Code" namespace defines the valid values associated with the s-uri- 1335 signing CDNI Logging Field. The CDNI URI Signing Verification Code 1336 is a 3DIGIT value as defined in Section 4.5. Additions to the CDNI 1337 URI Signing Verification Code namespace will conform to the 1338 "Specification Required" policy as defined in [RFC8126]. Updates to 1339 this subregistry are expected to be infrequent. 1341 +=======+===========+=====================================+ 1342 | Value | Reference | Description | 1343 +=======+===========+=====================================+ 1344 | 000 | RFCthis | No signed JWT verification | 1345 | | | performed | 1346 +-------+-----------+-------------------------------------+ 1347 | 200 | RFCthis | Signed JWT verification performed | 1348 | | | and verified | 1349 +-------+-----------+-------------------------------------+ 1350 | 400 | RFCthis | Signed JWT verification performed | 1351 | | | and rejected because of incorrect | 1352 | | | signature | 1353 +-------+-----------+-------------------------------------+ 1354 | 401 | RFCthis | Signed JWT verification performed | 1355 | | | and rejected because of Issuer | 1356 | | | enforcement | 1357 +-------+-----------+-------------------------------------+ 1358 | 402 | RFCthis | Signed JWT verification performed | 1359 | | | and rejected because of Subject | 1360 | | | enforcement | 1361 +-------+-----------+-------------------------------------+ 1362 | 403 | RFCthis | Signed JWT verification performed | 1363 | | | and rejected because of Audience | 1364 | | | enforcement | 1365 +-------+-----------+-------------------------------------+ 1366 | 404 | RFCthis | Signed JWT verification performed | 1367 | | | and rejected because of Expiration | 1368 | | | Time enforcement | 1369 +-------+-----------+-------------------------------------+ 1370 | 405 | RFCthis | Signed JWT verification performed | 1371 | | | and rejected because of Not Before | 1372 | | | enforcement | 1373 +-------+-----------+-------------------------------------+ 1374 | 406 | RFCthis | Signed JWT verification performed | 1375 | | | and rejected because only one of | 1376 | | | CDNI Signed Token Transport or CDNI | 1377 | | | Expiration Time Setting present. | 1378 +-------+-----------+-------------------------------------+ 1379 | 407 | RFCthis | Signed JWT verification performed | 1380 | | | and rejected because of JWT ID | 1381 | | | enforcement | 1382 +-------+-----------+-------------------------------------+ 1383 | 408 | RFCthis | Signed JWT verification performed | 1384 | | | and rejected because of Version | 1385 | | | enforcement | 1386 +-------+-----------+-------------------------------------+ 1387 | 409 | RFCthis | Signed JWT verification performed | 1388 | | | and rejected because of Critical | 1389 | | | Extension enforcement | 1390 +-------+-----------+-------------------------------------+ 1391 | 410 | RFCthis | Signed JWT verification performed | 1392 | | | and rejected because of Client IP | 1393 | | | enforcement | 1394 +-------+-----------+-------------------------------------+ 1395 | 411 | RFCthis | Signed JWT verification performed | 1396 | | | and rejected because of URI | 1397 | | | Container enforcement | 1398 +-------+-----------+-------------------------------------+ 1399 | 500 | RFCthis | Unable to perform signed JWT | 1400 | | | verification because of malformed | 1401 | | | URI | 1402 +-------+-----------+-------------------------------------+ 1404 Table 4 1406 [RFC Editor: Please replace RFCthis with the published RFC number for 1407 this document.] 1409 6.5. CDNI URI Signing Signed Token Transport 1411 The IANA is requested to create a new "CDNI URI Signing Signed Token 1412 Transport" subregistry in the "Content Delivery Networks 1413 Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing 1414 Signed Token Transport" namespace defines the valid values that may 1415 be in the Signed Token Transport (cdnistt) JWT claim. Additions to 1416 the Signed Token Transport namespace conform to the "Specification 1417 Required" policy as defined in [RFC8126]. Updates to this 1418 subregistry are expected to be infrequent. 1420 The following table defines the initial Enforcement Information 1421 Elements: 1423 +=======+=============================================+=========+ 1424 | Value | Description | RFC | 1425 +=======+=============================================+=========+ 1426 | 0 | Designates token transport is not enabled | RFCthis | 1427 +-------+---------------------------------------------+---------+ 1428 | 1 | Designates token transport via cookie | RFCthis | 1429 +-------+---------------------------------------------+---------+ 1430 | 2 | Designates token transport via query string | RFCthis | 1431 +-------+---------------------------------------------+---------+ 1433 Table 5 1435 [RFC Editor: Please replace RFCthis with the published RFC number for 1436 this document.] 1438 6.6. JSON Web Token Claims Registration 1440 This specification registers the following Claims in the IANA "JSON 1441 Web Token Claims" registry [IANA.JWT.Claims] established by 1442 [RFC7519]. 1444 6.6.1. Registry Contents 1446 * Claim Name: cdniv 1447 * Claim Description: CDNI Claim Set Version 1448 * Change Controller: IESG 1449 * Specification Document(s): Section 2.1.8 of [[ this specification 1450 ]] 1452 * Claim Name: cdnicrit 1453 * Claim Description: CDNI Critical Claims Set 1454 * Change Controller: IESG 1455 * Specification Document(s): Section 2.1.9 of [[ this specification 1456 ]] 1458 * Claim Name: cdniip 1459 * Claim Description: CDNI IP Address 1460 * Change Controller: IESG 1461 * Specification Document(s): Section 2.1.10 of [[ this specification 1462 ]] 1464 * Claim Name: cdniuc 1465 * Claim Description: CDNI URI Container 1466 * Change Controller: IESG 1467 * Specification Document(s): Section 2.1.11 of [[ this specification 1468 ]] 1470 * Claim Name: cdniets 1471 * Claim Description: CDNI Expiration Time Setting for Signed Token 1472 Renewal 1473 * Change Controller: IESG 1474 * Specification Document(s): Section 2.1.12 of [[ this specification 1475 ]] 1477 * Claim Name: cdnistt 1478 * Claim Description: CDNI Signed Token Transport Method for Signed 1479 Token Renewal 1480 * Change Controller: IESG 1481 * Specification Document(s): Section 2.1.13 of [[ this specification 1482 ]] 1484 * Claim Name: cdnistd 1485 * Claim Description: CDNI Signed Token Depth 1486 * Change Controller: IESG 1487 * Specification Document(s): Section 2.1.14 of [[ this specification 1488 ]] 1490 6.7. Expert Review Guidance 1492 Generally speaking, we should determine the registration has a 1493 rational justification and does not duplicate a previous 1494 registration. Early assignment should be permissible as long as 1495 there is a reasonable expectation that the specification will become 1496 formalized. Expert Reviewers should be empowered to make 1497 determinations, but generally speaking they should allow new claims 1498 that do not otherwise introduce conflicts with implementation or 1499 things that may lead to confusion. They should also follow the 1500 guidelines of [RFC8126] Section 5 when sensible. 1502 7. Security Considerations 1504 This document describes the concept of URI Signing and how it can be 1505 used to provide access authorization in the case of CDNI. The 1506 primary goal of URI Signing is to make sure that only authorized UAs 1507 are able to access the content, with a CSP being able to authorize 1508 every individual request. It should be noted that URI Signing is not 1509 a content protection scheme; if a CSP wants to protect the content 1510 itself, other mechanisms, such as DRM, are more appropriate. 1512 CDNI URI Signing Signed Tokens leverage JSON Web Tokens and thus 1513 guidelines in [RFC8725] are applicable for all JWT interactions. 1515 In general, it holds that the level of protection against 1516 illegitimate access can be increased by including more claims in the 1517 signed JWT. The current version of this document includes claims for 1518 enforcing Issuer, Client IP Address, Not Before time, and Expiration 1519 Time, however this list can be extended with other, more complex, 1520 attributes that are able to provide some form of protection against 1521 some of the vulnerabilities highlighted below. 1523 That said, there are a number of aspects that limit the level of 1524 security offered by URI Signing and that anybody implementing URI 1525 Signing should be aware of. 1527 * Replay attacks: A (valid) Signed URI may be used to perform replay 1528 attacks. The vulnerability to replay attacks can be reduced by 1529 picking a relatively short window between the Not Before time and 1530 Expiration Time attributes, although this is limited by the fact 1531 that any HTTP-based request needs a window of at least a couple of 1532 seconds to prevent sudden network issues from denying legitimate 1533 UAs access to the content. One may also reduce exposure to replay 1534 attacks by including a unique one-time access ID via the JWT ID 1535 attribute (jti claim). Whenever the dCDN receives a request with 1536 a given unique ID, it adds that ID to the list of 'used' IDs. In 1537 the case an illegitimate UA tries to use the same URI through a 1538 replay attack, the dCDN can deny the request based on the already- 1539 used access ID. This list should be kept bounded. A reasonable 1540 approach would be to expire the entries based on the exp claim 1541 value. If no exp claim is present then a simple LRU could be 1542 used, however this would allow values to eventually be reused. 1544 * Illegitimate clients behind a NAT: In cases where there are 1545 multiple users behind the same NAT, all users will have the same 1546 IP address from the point of view of the dCDN. This results in 1547 the dCDN not being able to distinguish between different users 1548 based on Client IP Address which can lead to illegitimate users 1549 being able to access the content. One way to reduce exposure to 1550 this kind of attack is to not only check for Client IP but also 1551 for other attributes, e.g., attributes that can be found in HTTP 1552 headers. However, this may be easily circumvented by a 1553 sophisticated attacker. 1555 The shared key between CSP and uCDN may be distributed to dCDNs - 1556 including cascaded CDNs. Since this key can be used to legitimately 1557 sign a URL for content access authorization, it is important to know 1558 the implications of a compromised shared key. While using a shared 1559 key scheme can be convenient, this architecture is NOT RECOMMENDED 1560 due to the risks associated. It is included for legacy feature 1561 parity and is highly discouraged in new implementations. 1563 If a shared key usable for signing is compromised, an attacker can 1564 use it to perform a denial-of-service attack by forcing the CDN to 1565 evaluate prohibitively expensive regular expressions embedded in a 1566 URI Container (cdniuc) claim. As a result, compromised keys should 1567 be timely revoked in order to prevent exploitation. 1569 The URI Container (cdniuc) claim can be given a wildcard value. 1570 This, combined with the fact that it is the only mandatory claim, 1571 means you can effectively make a skeleton key. Doing this does not 1572 sufficiently limit the scope of the JWT and is NOT RECOMMENDED. The 1573 only way to prevent such a key from being used after it is 1574 distributed is to revoke the signing key so it no longer validates. 1576 8. Privacy 1578 The privacy protection concerns described in CDNI Logging Interface 1579 [RFC7937] apply when the client's IP address (cdniip) or Subject 1580 (sub) is embedded in the Signed URI. For this reason, the mechanism 1581 described in Section 2 encrypts the Client IP or Subject before 1582 including it in the URI Signing Package (and thus the URL itself). 1584 9. Acknowledgements 1586 The authors would like to thank the following people for their 1587 contributions in reviewing this document and providing feedback: 1588 Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan 1589 York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana 1590 Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris 1591 Lemmons. 1593 10. Contributors 1595 In addition, the authors would also like to make special mentions for 1596 certain people who contributed significant sections to this document. 1598 * Matt Caulfield provided content for the CDNI Metadata Interface 1599 section. 1601 * Emmanuel Thomas provided content for HTTP Adaptive Streaming. 1603 * Matt Miller provided consultation on JWT usage as well as code to 1604 generate working JWT examples. 1606 11. References 1608 11.1. Normative References 1610 [POSIX.1] "The Open Group Base Specifications Issue 7", IEEE 1611 Std 1003.1 2018 Edition, 31 January 2018, 1612 . 1614 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1615 DOI 10.17487/RFC0791, September 1981, 1616 . 1618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1619 Requirement Levels", BCP 14, RFC 2119, 1620 DOI 10.17487/RFC2119, March 1997, 1621 . 1623 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1624 Resource Identifier (URI): Generic Syntax", STD 66, 1625 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1626 . 1628 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1629 "Network Time Protocol Version 4: Protocol and Algorithms 1630 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1631 . 1633 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1634 Address Text Representation", RFC 5952, 1635 DOI 10.17487/RFC5952, August 2010, 1636 . 1638 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1639 DOI 10.17487/RFC6265, April 2011, 1640 . 1642 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 1643 and D. Orchard, "URI Template", RFC 6570, 1644 DOI 10.17487/RFC6570, March 2012, 1645 . 1647 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1648 Distribution Network Interconnection (CDNI) Problem 1649 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1650 2012, . 1652 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1653 Keranen, A., and P. Hallam-Baker, "Naming Things with 1654 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1655 . 1657 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1658 Protocol (HTTP/1.1): Message Syntax and Routing", 1659 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1660 . 1662 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1663 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1664 . 1666 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1667 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1668 . 1670 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 1671 and R. Peterkofsky, "Content Distribution Network 1672 Interconnection (CDNI) Logging Interface", RFC 7937, 1673 DOI 10.17487/RFC7937, August 2016, 1674 . 1676 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1677 "Content Delivery Network Interconnection (CDNI) 1678 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1679 . 1681 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1682 Writing an IANA Considerations Section in RFCs", BCP 26, 1683 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1684 . 1686 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1687 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1688 May 2017, . 1690 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1691 Interchange Format", STD 90, RFC 8259, 1692 DOI 10.17487/RFC8259, December 2017, 1693 . 1695 11.2. Informative References 1697 [IANA.JWT.Claims] 1698 IANA, "JSON Web Token Claims", 1699 . 1701 [MPEG-DASH] 1702 ISO, "Information technology -- Dynamic adaptive streaming 1703 over HTTP (DASH) -- Part 1: Media presentation description 1704 and segment format", ISO/IEC 23009-1:2014, Edition 2, May 1705 2014, . 1707 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 1708 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 1709 Content Distribution Network Interconnection (CDNI)", 1710 RFC 6983, DOI 10.17487/RFC6983, July 2013, 1711 . 1713 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1714 "Framework for Content Distribution Network 1715 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1716 August 2014, . 1718 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1719 Network Interconnection (CDNI) Requirements", RFC 7337, 1720 DOI 10.17487/RFC7337, August 2014, 1721 . 1723 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1724 DOI 10.17487/RFC7517, May 2015, 1725 . 1727 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1728 "Request Routing Redirection Interface for Content 1729 Delivery Network (CDN) Interconnection", RFC 7975, 1730 DOI 10.17487/RFC7975, October 2016, 1731 . 1733 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1734 R., and K. Ma, "Content Delivery Network Interconnection 1735 (CDNI) Request Routing: Footprint and Capabilities 1736 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1737 . 1739 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 1740 RFC 8216, DOI 10.17487/RFC8216, August 2017, 1741 . 1743 [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 1744 Current Practices", BCP 225, RFC 8725, 1745 DOI 10.17487/RFC8725, February 2020, 1746 . 1748 Appendix A. Signed URI Package Example 1750 This section contains three examples of token usage: a simple example 1751 with only the required claim present, a complex example which 1752 demonstrates the full JWT claims set, including an encrypted Client 1753 IP (cdniip), and one that uses a Signed Token Renewal. 1755 Note: All of the examples have whitespace added to improve formatting 1756 and readability, but are not present in the generated content. 1758 All examples use the following JWK Set [RFC7517]: 1760 { "keys": [ 1761 { 1762 "kty": "EC", 1763 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1764 "use": "sig", 1765 "alg": "ES256", 1766 "crv": "P-256", 1767 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1768 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA" 1769 }, 1770 { 1771 "kty": "EC", 1772 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1773 "use": "sig", 1774 "alg": "ES256", 1775 "crv": "P-256", 1776 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1777 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", 1778 "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" 1779 }, 1780 { 1781 "kty": "oct", 1782 "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", 1783 "use": "enc", 1784 "alg": "A128GCM", 1785 "k": "4uFxxV7fhNmrtiah2d1fFg" 1786 } 1787 ]} 1788 Note: They are the public signing key, the private signing key, and 1789 the shared secret enctyption key, respectively. The public and 1790 private signing keys have the same fingerprint and only vary by the 1791 'd' parameter that is missing from the public signing key. 1793 A.1. Simple Example 1795 This example is a simple common usage example containing a minimal 1796 subset of claims that the authors find most useful. 1798 The JWT Claim Set before signing: 1800 Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the 1801 URL Segment form ([RFC6920] Section 5) of "http://cdni.example/foo/ 1802 bar". 1804 { 1805 "exp": 1641079223, 1806 "iss": "uCDN Inc", 1807 "cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" 1808 } 1810 The signed JWT: 1812 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1813 dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE2NDEwNzkyMjMsImlzcyI6InVDRE4gS 1814 W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV 1815 wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.P5It6q0kxNx5NBA76D-bYKIxlourey5JpU 1816 4diFLGHaVTk21QkEskjxoeneDoBj_1C5Ty1smBOovQMrGzuPmEHA 1818 A.2. Complex Example 1820 This example uses all fields except for those dealing with Signed 1821 Token Renewal, including Client IP (cdniip) and Subject (sub) which 1822 are encrpyted. This significantly increases the size of the signed 1823 JWT token. 1825 JWE for Client IP (cdniip) of [2001:db8::1/32]: 1827 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1828 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..s614z__atK4Cijic.ieSm7 1829 o2o7rIqCYbDExdoyQ.JUnPLQzBf2dPhBPRTxHKww 1831 JWE for Subject (sub) of "UserToken": 1833 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1834 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..MbT8tWet01VVHjuS.4KP7A 1835 JefU70b.Rc_o3tCfWoPkIdySsYtfMw 1836 The JWT Claim Set before signing: 1838 { 1839 "aud": "dCDN LLC", 1840 "sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4 1841 QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..MbT8tWet01VV 1842 HjuS.4KP7AJefU70b.Rc_o3tCfWoPkIdySsYtfMw", 1843 "cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY 1844 mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..s614z__at 1845 K4Cijic.ieSm7o2o7rIqCYbDExdoyQ.JUnPLQzBf2dPhBPRTxHKww", 1846 "cdniv": 1, 1847 "exp": 1641079223, 1848 "iat": 1640906423, 1849 "iss": "uCDN Inc", 1850 "jti": "5DAafLhZAfhsbe", 1851 "nbf": 1640992823, 1852 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png" 1853 } 1855 The signed JWT: 1857 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1858 dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib 1859 U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA 1860 0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T 1861 0NKOS4uTWJUOHRXZXQwMVZWSGp1Uy40S1A3QUplZlU3MGIuUmNfbzN0Q2ZXb1BrSWR 1862 5U3NZdGZNdyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja 1863 m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp 1864 2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uczYxNHpfX2F0SzRDaWppYy5pZ 1865 VNtN28ybzdySXFDWWJERXhkb3lRLkpVblBMUXpCZjJkUGhCUFJUeEhLd3ciLCJjZG5 1866 pdiI6MSwiZXhwIjoxNjQxMDc5MjIzLCJpYXQiOjE2NDA5MDY0MjMsImlzcyI6InVDR 1867 E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE2NDA5OTI4MjMsImN 1868 kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde 1869 zN9XFwucG5nIn0.MgV1AIvlWf3rjUqWGKlpR1CcCpF8N5FX7xlZ0wGCqfJY3KpqTrV 1870 NKaEWVXGoo12oVgQ7J2KoRtcr2ah9dsjqOA 1872 A.3. Signed Token Renewal Example 1874 This example uses fields for Signed Token Renewal. 1876 The JWT Claim Set before signing: 1878 { 1879 "cdniets": 30, 1880 "cdnistt": 1, 1881 "cdnistd": 2, 1882 "exp": 1641079223, 1883 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1884 } 1886 The signed JWT: 1888 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1889 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1890 XN0ZCI6MiwiZXhwIjoxNjQxMDc5MjIzLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1891 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.qp4l3B36rRmIUBXzP 1892 WdK7p0_zlq7tvgt5oJSBSMOUEWtMsIZf3q0nXSnHPxsNdLcsTSNoFOAgq5y0EjQmvN 1893 QoA 1895 Once the server verifies the signed JWT it will return a new signed 1896 JWT with an updated expiry time (exp) as shown below. Note the 1897 expiry time is increased by the expiration time setting (cdniets) 1898 value. 1900 The JWT Claim Set before signing: 1902 { 1903 "cdniets": 30, 1904 "cdnistt": 1, 1905 "cdnistd": 2, 1906 "exp": 1641079223, 1907 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1908 } 1910 The signed JWT: 1912 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1913 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1914 XN0ZCI6MiwiZXhwIjoxNjQxMDc5MjIzLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1915 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.Qrixg5gbwCQjvV5Wg 1916 W4__NVnOeFXqqudhc202ptkrY8PDQk3BaMop6uG6dzgKk3KT5lTFVzEN9nfN8a1H8b 1917 Zow 1919 Authors' Addresses 1921 Ray van Brandenburg 1922 Tiledmedia 1923 Anna van Buerenplein 1 1924 Den Haag 1925 Phone: +31 88 866 7000 1926 Email: ray@tiledmedia.com 1928 Kent Leung 1930 Email: mail4kentl@gmail.com 1932 Phil Sorber 1933 Apple, Inc. 1934 1800 Wazee Street 1935 Suite 410 1936 Denver, CO 80202 1937 United States 1939 Email: sorber@apple.com