idnits 2.17.1 draft-ietf-cdni-uri-signing-26.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 (22 March 2022) is 759 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: 23 September 2022 6 P. Sorber 7 Apple, Inc. 8 22 March 2022 10 URI Signing for Content Delivery Network Interconnection (CDNI) 11 draft-ietf-cdni-uri-signing-26 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 23 September 2022. 43 Copyright Notice 45 Copyright (c) 2022 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 . . . . . . . . . . . . 9 64 2. JWT Format and Processing Requirements . . . . . . . . . . . 9 65 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 10 66 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10 67 2.1.2. Subject (sub) claim . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . 12 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 . . . . . . . . 13 74 2.1.9. CDNI Critical Claims Set (cdnicrit) claim . . . . . . 13 75 2.1.10. Client IP Address (cdniip) claim . . . . . . . . . . 13 76 2.1.11. CDNI URI Container (cdniuc) claim . . . . . . . . . . 14 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 . . . . . . . 15 80 2.1.15. URI Container Forms . . . . . . . . . . . . . . . . . 15 81 2.1.15.1. URI Hash Container (hash:) . . . . . . . . . . . 16 82 2.1.15.2. URI Regular Expression Container (regex:) . . . 16 83 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 16 84 3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 17 85 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17 86 3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 17 87 3.2.1. Required Claims . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . 19 91 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . 22 98 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 22 99 5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 25 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 101 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . 29 105 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 29 106 6.4. CDNI URI Signing Verification Code . . . . . . . . . . . 30 107 6.5. CDNI URI Signing Signed Token Transport . . . . . . . . . 31 108 6.6. JSON Web Token Claims Registration . . . . . . . . . . . 32 109 6.6.1. Registry Contents . . . . . . . . . . . . . . . . . . 32 110 6.7. Expert Review Guidance . . . . . . . . . . . . . . . . . 33 111 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 112 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 113 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 114 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 116 11.1. Normative References . . . . . . . . . . . . . . . . . . 35 117 11.2. Informative References . . . . . . . . . . . . . . . . . 37 118 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 39 119 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 40 120 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 40 121 A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 41 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 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 a time window or 217 pattern matching the URI). To prevent the UA from altering the 218 claims the 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 time window is still 233 valid in the Signed URI and the pattern matches the URI of the 234 request. After these claims are verified, the CDN delivers the 235 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 CDN directly. In the 322 case where the dCDN does not have a trust relationship with the CSP, 323 this means that either an asymmetric public/private key method needs 324 to be used for computing the signed JWT (because the CSP and dCDN are 325 not able to exchange symmetric shared secret keys). Shared keys MUST 326 NOT be redistributed. 328 For HTTP-based request routing, the Signed URI (i.e., the Target CDN 329 URI) provided by the CSP reaches the uCDN. After this URI has been 330 verified by the uCDN, the uCDN creates and signs a new Redirection 331 URI, redirecting the UA to the dCDN. Since this new URI can have a 332 new signed JWT, the relationship between the dCDN and CSP is not 333 relevant. Because a relationship between uCDN and dCDN always 334 exists, either asymmetric public/private keys or symmetric shared 335 secret keys can be used for URI Signing with HTTP-based request 336 routing. Note that the signed Redirection URI MUST maintain HTTPS as 337 the scheme if it was present in the original and it MAY be upgraded 338 from http: to https:. 340 Two types of keys can be used for URI Signing: asymmetric keys and 341 symmetric shared keys. Asymmetric keys are based on a public/private 342 key pair mechanism and always contain a private key known only to the 343 entity signing the URI (either CSP or uCDN) and a public key for the 344 verification of the Signed URI. With symmetric keys, the same key is 345 used by both the signing entity for signing the URI and the verifying 346 entity for verifying the Signed URI. Regardless of the type of keys 347 used, the verifying entity has to obtain the key in a manner that 348 allows trust to be placed in the assertions made using that key 349 (either the public or the symmetric key). There are very different 350 requirements (outside the scope of this document) for distributing 351 asymmetric keys and symmetric keys. Key distribution for symmetric 352 keys requires confidentiality to prevent third parties from getting 353 access to the key, since they could then generate valid Signed URIs 354 for unauthorized requests. Key distribution for asymmetric keys does 355 not require confidentiality since public keys can typically be 356 distributed openly (because they cannot be used to sign URIs) and the 357 corresponding private keys are kept secret by the URI signer. 359 Note: While using a symmetric shared key is supported, it is NOT 360 RECOMMENDED. See the Security Considerations (Section 7) section 361 about the limitations of shared keys. 363 1.4. URI Signing in a non-CDNI context 365 While the URI Signing method defined in this document was primarily 366 created for the purpose of allowing URI Signing in CDNI scenarios, 367 i.e., between a uCDN and a dCDN, there is nothing in the defined URI 368 Signing method that precludes it from being used in a non-CDNI 369 context. As such, the described mechanism could be used in a single- 370 CDN scenario such as shown in Figure 1 in Section 1.2, for example to 371 allow a CSP that uses different CDNs to only have to implement a 372 single URI Signing mechanism. 374 2. JWT Format and Processing Requirements 376 The concept behind URI Signing is based on embedding a signed JSON 377 Web Token (JWT) [RFC7519] in an HTTP or HTTPS URI [RFC7230] (see 378 [RFC7230] Section 2.7). The signed JWT contains a number of claims 379 that can be verified to ensure the UA has legitimate access to the 380 content. 382 This document specifies the following attribute for embedding a 383 signed JWT in a Target CDN URI or Redirection URI: 385 * URI Signing Package (URISigningPackage): The URI attribute that 386 encapsulates all the URI Signing claims in a signed JWT encoded 387 format. This attribute is exposed in the Signed URI as a path- 388 style parameter or a form-style parameter. 390 The parameter name of the URI Signing Package Attribute is defined in 391 the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is 392 not used, or does not include a parameter name for the URI Signing 393 Package Attribute, the parameter name can be set by configuration 394 (out of scope of this document). 396 The URI Signing Package will be found by parsing any path-style 397 parameters and form-style parameters looking for a key name matching 398 the URI Signing Package Attribute. Both parameter styles MUST be 399 supported to allow flexibility of operation. The first matching 400 parameter SHOULD be taken to provide the signed JWT, though providing 401 more than one matching key is undefined behavior. Path-style 402 parameters generated in the form indicated by Section 3.2.7 of 403 [RFC6570] and Form-style parameters generated in the form indicated 404 by Sections 3.2.8 and 3.2.9 of [RFC6570] MUST be supported. 406 The following is an example where the URI Signing Package Attribute 407 name is "token" and the signed JWT is "SIGNEDJWT": 409 http://example.com/media/path?come=data&token=SIGNEDJWT&other=data 411 2.1. JWT Claims 413 This section identifies the set of claims that can be used to enforce 414 the CSP distribution policy. New claims can be introduced in the 415 future to extend the distribution policy capabilities. 417 In order to provide distribution policy flexibility, the exact subset 418 of claims used in a given signed JWT is a runtime decision. Claim 419 requirements are defined in the CDNI Metadata (Section 4.4). If the 420 CDNI Metadata interface is not used, or does not include claim 421 requirements, the claim requirements can be set by configuration (out 422 of scope of this document). 424 The following claims (where the "JSON Web Token Claims" registry 425 claim name is specified in parentheses below) are used to enforce the 426 distribution policies. All of the listed claims are mandatory to 427 implement in a URI Signing implementation, but are not necessarily 428 mandatory to use in a given signed JWT. (The "optional" and 429 "mandatory" identifiers in square brackets refer to whether or not a 430 given claim MUST be present in a URI Signing JWT.) 432 Note: The time on the entities that generate and verify the signed 433 URI MUST be in sync. In the CDNI case, this means that CSP, uCDN, 434 and dCDN servers need to be time-synchronized. It is RECOMMENDED to 435 use NTP [RFC5905] for time synchronization. 437 Note: See the Security Considerations (Section 7) section on the 438 limitations of using an expiration time and client IP address for 439 distribution policy enforcement. 441 2.1.1. Issuer (iss) claim 443 Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1 444 MUST be followed. If this claim is used, it MUST be used to identify 445 the issuer (signer) of the JWT. In particular, the recipient will 446 have already received, in trusted configuration, a mapping of issuer 447 name to one or more keys used to sign JWTs, and must verify that the 448 JWT was signed by one of those keys. If this claim is used and the 449 CDN verifying the signed JWT does not support Issuer verification, or 450 if the Issuer in the signed JWT does not match the list of known 451 acceptable Issuers, or if the Issuer claim does not match the key 452 used to sign the JWT, the CDN MUST reject the request. If the 453 received signed JWT contains an Issuer claim, then any JWT 454 subsequently generated for CDNI redirection MUST also contain an 455 Issuer claim, and the Issuer value MUST be updated to identify the 456 redirecting CDN. If the received signed JWT does not contain an 457 Issuer claim, an Issuer claim MAY be added to a signed JWT generated 458 for CDNI redirection. 460 2.1.2. Subject (sub) claim 462 Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2 463 MUST be followed. If this claim is used, it MUST be a JSON Web 464 Encryption (JWE [RFC7516]) Object in compact serialization form, 465 because it contains personally identifiable information. This claim 466 contains information about the subject (for example, a user or an 467 agent) that MAY be used to verify the signed JWT. If the received 468 signed JWT contains a Subject claim, then any JWT subsequently 469 generated for CDNI redirection MUST also contain a Subject claim, and 470 the Subject value MUST be the same as in the received signed JWT. A 471 signed JWT generated for CDNI redirection MUST NOT add a Subject 472 claim if no Subject claim existed in the received signed JWT. 474 2.1.3. Audience (aud) claim 476 Audience (aud) [optional] - The semantics in [RFC7519] Section 4.1.3 477 MUST be followed. This claim is used to ensure that the CDN 478 verifying the JWT is an intended recipient of the request. The claim 479 MUST contain an identity belonging to the chain of entities involved 480 in processing the request (e.g., identifying the CSP or any CDN in 481 the chain) that the recipient is configured to use for the processing 482 of this request. A CDN MAY modify the claim as long it can generate 483 a valid signature. 485 2.1.4. Expiry Time (exp) claim 487 Expiry Time (exp) [optional] - The semantics in [RFC7519] 488 Section 4.1.4 MUST be followed, though URI Signing implementations 489 MUST NOT allow for any time synchronization "leeway". If this claim 490 is used and the CDN verifying the signed JWT does not support Expiry 491 Time verification, or if the Expiry Time in the signed JWT 492 corresponds to a time equal to or earlier than the time of the 493 content request, the CDN MUST reject the request. If the received 494 signed JWT contains an Expiry Time claim, then any JWT subsequently 495 generated for CDNI redirection MUST also contain an Expiry Time 496 claim, and the Expiry Time value MUST be the same as in the received 497 signed JWT. A signed JWT generated for CDNI redirection MUST NOT add 498 an Expiry Time claim if no Expiry Time claim existed in the received 499 signed JWT. 501 2.1.5. Not Before (nbf) claim 503 Not Before (nbf) [optional] - The semantics in [RFC7519] 504 Section 4.1.5 MUST be followed, though URI Signing implementations 505 MUST NOT allow for any time synchronization "leeway". If this claim 506 is used and the CDN verifying the signed JWT does not support Not 507 Before time verification, or if the Not Before time in the signed JWT 508 corresponds to a time later than the time of the content request, the 509 CDN MUST reject the request. If the received signed JWT contains a 510 Not Before time claim, then any JWT subsequently generated for CDNI 511 redirection MUST also contain a Not Before time claim, and the Not 512 Before time value MUST be the same as in the received signed JWT. A 513 signed JWT generated for CDNI redirection MUST NOT add a Not Before 514 time claim if no Not Before time claim existed in the received signed 515 JWT. 517 2.1.6. Issued At (iat) claim 519 Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6 520 MUST be followed. If the received signed JWT contains an Issued At 521 claim, then any JWT subsequently generated for CDNI redirection MUST 522 also contain an Issued At claim, and the Issued At value MUST be 523 updated to identify the time the new JWT was generated. If the 524 received signed JWT does not contain an Issued At claim, an Issued At 525 claim MAY be added to a signed JWT generated for CDNI redirection. 527 2.1.7. JWT ID (jti) claim 529 JWT ID (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 530 MUST be followed. A JWT ID can be used to prevent replay attacks if 531 the CDN stores a list of all previously used values, and verifies 532 that the value in the current JWT has never been used before. If the 533 signed JWT contains a JWT ID claim and the CDN verifying the signed 534 JWT either does not support JWT ID storage or has previously seen the 535 value used in a request for the same content, then the CDN MUST 536 reject the request. If the received signed JWT contains a JWT ID 537 claim, then any JWT subsequently generated for CDNI redirection MUST 538 also contain a JWT ID claim, and the value MUST be the same as in the 539 received signed JWT. If the received signed JWT does not contain a 540 JWT ID claim, a JWT ID claim MUST NOT be added to a signed JWT 541 generated for CDNI redirection. Sizing of the JWT ID is application 542 dependent given the desired security constraints. 544 2.1.8. CDNI Claim Set Version (cdniv) claim 546 CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set 547 Version (cdniv) claim provides a means within a signed JWT to tie the 548 claim set to a specific version of this specification. The cdniv 549 claim is intended to allow changes in and facilitate upgrades across 550 specifications. The type is JSON integer and the value MUST be set 551 to "1", for this version of the specification. In the absence of 552 this claim, the value is assumed to be "1". For future versions this 553 claim will be mandatory. Implementations MUST reject signed JWTs 554 with unsupported CDNI Claim Set versions. 556 2.1.9. CDNI Critical Claims Set (cdnicrit) claim 558 CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical 559 Claims Set (cdnicrit) claim indicates that extensions to this 560 specification are being used that MUST be understood and processed. 561 Its value is a comma separated listing of claims in the Signed JWT 562 that use those extensions. If any of the listed extension claims are 563 not understood and supported by the recipient, then the Signed JWT 564 MUST be rejected. Producers MUST NOT include claim names defined by 565 this specification, duplicate names, or names that do not occur as 566 claim names within the Signed JWT in the cdnicrit list. Producers 567 MUST NOT use the empty list "" as the cdnicrit value. Recipients MAY 568 consider the Signed JWT to be invalid if the cdnicrit list contains 569 any claim names defined by this specification or if any other 570 constraints on its use are violated. This claim MUST be understood 571 and processed by all implementations. 573 2.1.10. Client IP Address (cdniip) claim 575 Client IP Address (cdniip) [optional] - The Client IP Address 576 (cdniip) claim holds an IP address or IP prefix for which the Signed 577 URI is valid. This is represented in CIDR notation, with dotted 578 decimal format for IPv4 addresses [RFC0791] or canonical text 579 representation for IPv6 addresses [RFC5952]. The request MUST be 580 rejected if sourced from a client outside the specified IP range. 581 Since the client IP is considered personally identifiable information 582 this field MUST be a JSON Web Encryption (JWE [RFC7516]) Object in 583 compact serialization form. If the CDN verifying the signed JWT does 584 not support Client IP verification, or if the Client IP in the signed 585 JWT does not match the source IP address in the content request, the 586 CDN MUST reject the request. The type of this claim is a JSON string 587 that contains the JWE. If the received signed JWT contains a Client 588 IP claim, then any JWT subsequently generated for CDNI redirection 589 MUST also contain a Client IP claim, and the Client IP value MUST be 590 the same as in the received signed JWT. A signed JWT generated for 591 CDNI redirection MUST NOT add a Client IP claim if no Client IP claim 592 existed in the received signed JWT. 594 It should be noted that use of this claim can cause issues, for 595 example, in situations with dual-stack IPv4 and IPv6 networks, MPTCP, 596 QUIC, and mobile clients switching from Wi-Fi to Cellular networks 597 where the client's source address can change, even between address 598 families. This claim exists mainly for legacy feature parity 599 reasons, therefore use of this claim should be done judiciously. An 600 example of a reasonable use case would be making a signed JWT for an 601 internal preview of an asset where the end consumer understands that 602 they must be originated from the same IP for the entirety of the 603 session. Using this claim at large is NOT RECOMMENDED. 605 2.1.11. CDNI URI Container (cdniuc) claim 607 URI Container (cdniuc) [mandatory] - The URI Container (cdniuc) holds 608 the URI representation before a URI Signing Package is added. This 609 representation can take one of several forms detailed in 610 Section 2.1.15. If the URI Container used in the signed JWT does not 611 match the URI of the content request, the CDN verifying the signed 612 JWT MUST reject the request. When comparing the URI, the percent 613 encoded form as defined in [RFC3986] Section 2.1 MUST be used. When 614 redirecting a URI, the CDN generating the new signed JWT MAY change 615 the URI Container to comport with the URI being used in the 616 redirection. 618 2.1.12. CDNI Expiration Time Setting (cdniets) claim 620 CDNI Expiration Time Setting (cdniets) [optional] - The CDNI 621 Expiration Time Setting (cdniets) claim provides a means for setting 622 the value of the Expiry Time (exp) claim when generating a subsequent 623 signed JWT in Signed Token Renewal. Its type is a JSON numeric 624 value. It denotes the number of seconds to be added to the time at 625 which the JWT is verified that gives the value of the Expiry Time 626 (exp) claim of the next signed JWT. The CDNI Expiration Time Setting 627 (cdniets) SHOULD NOT be used when not using Signed Token Renewal and 628 MUST be present when using Signed Token Renewal. 630 2.1.13. CDNI Signed Token Transport (cdnistt) claim 632 CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed 633 Token Transport (cdnistt) claim provides a means of signalling the 634 method through which a new signed JWT is transported from the CDN to 635 the UA and vice versa for the purpose of Signed Token Renewal. Its 636 type is a JSON integer. Values for this claim are defined in 637 Section 6.5. If using this claim you MUST also specify a CDNI 638 Expiration Time Setting (cdniets) as noted above. 640 2.1.14. CDNI Signed Token Depth (cdnistd) claim 642 CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token 643 Depth (cdnistd) claim is used to associate a subsequent signed JWT, 644 generated as the result of a CDNI Signed Token Transport claim, with 645 a specific URI subset. Its type is a JSON integer. Signed JWTs MUST 646 NOT use a negative value for the CDNI Signed Token Depth claim. 648 If the transport used for Signed Token Transport allows the CDN to 649 associate the path component of a URI with tokens (e.g., an HTTP 650 Cookie Path as described in section 4.1.2.4 of [RFC6265]), the CDNI 651 Signed Token Depth value is the number of path segments that should 652 be considered significant for this association. A CDNI Signed Token 653 Depth of zero means that the client SHOULD be directed to return the 654 token with requests for any path. If the CDNI Signed Token Depth is 655 greater than zero, then the CDN SHOULD send the client a token to 656 return for future requests wherein the first CDNI Signed Token Depth 657 segments of the path match the first CDNI Signed Token Depth segments 658 of the signed URI path. This matching MUST use the URI with the 659 token removed, as specified in Section 2.1.15. 661 If the URI path to match contains fewer segments than the CDNI Signed 662 Token Depth claim, a signed JWT MUST NOT be generated for the 663 purposes of Signed Token Renewal. If the CDNI Signed Token Depth 664 claim is omitted, it means the same thing as if its value were zero. 665 If the received signed JWT contains a CDNI Signed Token Depth claim, 666 then any JWT subsequently generated for CDNI redirection or Signed 667 Token Transport MUST also contain a CDNI Signed Token Depth claim, 668 and the value MUST be the same as in the received signed JWT. 670 2.1.15. URI Container Forms 672 The URI Container (cdniuc) claim takes one of the following forms: 673 'hash:' or 'regex:'. More forms may be added in the future to extend 674 the capabilities. 676 Before comparing a URI with contents of this container, the following 677 steps MUST be performed: 679 * Prior to verification, remove the signed JWT from the URI. This 680 removal is only for the purpose of determining if the URI matches; 681 all other purposes will use the original URI. If the signed JWT 682 is terminated by anything other than a sub-delimiter (as defined 683 in [RFC3986] Section 2.2), everything from the reserved character 684 (as defined in [RFC3986] Section 2.2) that precedes the URI 685 Signing Package Attribute to the last character of the signed JWT 686 will be removed, inclusive. Otherwise, everything from the first 687 character of the URI Signing Package Attribute to the sub- 688 delimiter that terminates the signed JWT will be removed, 689 inclusive. 691 * Normalize the URI according to section 2.7.3 [RFC7230] and 692 sections 6.2.2 and 6.2.3 [RFC3986]. This applies to both 693 generation and verification of the signed JWT. 695 2.1.15.1. URI Hash Container (hash:) 697 Prefixed with 'hash:', this string is a URL Segment form ([RFC6920] 698 Section 5) of the URI. 700 2.1.15.2. URI Regular Expression Container (regex:) 702 Prefixed with 'regex:', this string is any POSIX Section 9 [POSIX.1] 703 Extended Regular Expression compatible regular expression used to 704 match against the requested URI. These regular expressions MUST be 705 evaluated in the POSIX locale (POSIX Section 7.2 [POSIX.1]). 707 Note: Because '\' has special meaning in JSON [RFC8259] as the escape 708 character within JSON strings, the regular expression character '\' 709 MUST be escaped as '\\'. 711 An example of a 'regex:' is the following: 713 [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)? 715 Note: Due to computational complexity of executing arbitrary regular 716 expressions, it is RECOMMENDED to only execute after verifying the 717 JWT to ensure its authenticity. 719 2.2. JWT Header 721 The header of the JWT MAY be passed via the CDNI Metadata interface 722 instead of being included in the URISigningPackage. The header value 723 MUST be transmitted in the serialized encoded form and prepended to 724 the JWT payload and signature passed in the URISigningPackage prior 725 to verification. This reduces the size of the signed JWT token. 727 3. URI Signing Token Renewal 729 3.1. Overview 731 For content that is delivered via HTTP in a segmented fashion, such 732 as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216], 733 special provisions need to be made in order to ensure URI Signing can 734 be applied. In general, segmented protocols work by breaking large 735 objects (e.g., videos) into a sequence of small independent segments. 736 Such segments are then referenced by a separate manifest file, which 737 either includes a list of URLs to the segments or specifies an 738 algorithm through which a User Agent can construct the URLs to the 739 segments. Requests for segments therefore originate from the 740 manifest file and, unless the URLs in the manifest file point to the 741 CSP, are not subjected to redirection and URI Signing. This opens up 742 a vulnerability to malicious User Agents sharing the manifest file 743 and deep-linking to the segments. 745 One method for dealing with this vulnerability would be to include, 746 in the manifest itself, Signed URIs that point to the individual 747 segments. There exist a number of issues with that approach. First, 748 it requires the CDN delivering the manifest to rewrite the manifest 749 file for each User Agent, which would require the CDN to be aware of 750 the exact segmentation protocol used. Secondly, it could also 751 require the expiration time of the Signed URIs to be valid for an 752 extended duration if the content described by the manifest is meant 753 to be consumed in real time. For instance, if the manifest file were 754 to contain a segmented video stream of more than 30 minutes in 755 length, Signed URIs would require to be valid for at least 30 756 minutes, thereby reducing their effectiveness and that of the URI 757 Signing mechanism in general. For a more detailed analysis of how 758 segmented protocols such as HTTP Adaptive Streaming protocols affect 759 CDNI, see Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. 761 The method described in this section allows CDNs to use URI Signing 762 for segmented content without having to include the Signed URIs in 763 the manifest files themselves. 765 3.2. Signed Token Renewal mechanism 767 In order to allow for effective access control of segmented content, 768 the URI Signing mechanism defined in this section is based on a 769 method through which subsequent segment requests can be linked 770 together. As part of the JWT verification procedure, the CDN can 771 generate a new signed JWT that the UA can use to do a subsequent 772 request. More specifically, whenever a UA successfully retrieves a 773 segment, it receives, in the HTTP 2xx Successful message, a signed 774 JWT that it can use whenever it requests the next segment. As long 775 as each successive signed JWT is correctly verified before a new one 776 is generated, the model is not broken, and the User Agent can 777 successfully retrieve additional segments. Given the fact that with 778 segmented protocols, it is usually not possible to determine a priori 779 which segment will be requested next (i.e., to allow for seeking 780 within the content and for switching to a different representation), 781 the Signed Token Renewal uses the URI Regular Expression Container 782 scoping mechanisms in the URI Container (cdniuc) claim to allow a 783 signed JWT to be valid for more than one URL. 785 In order for this renewal of signed JWTs to work, it is necessary for 786 a UA to extract the signed JWT from the HTTP 2xx Successful message 787 of an earlier request and use it to retrieve the next segment. The 788 exact mechanism by which the client does this is outside the scope of 789 this document. However, in order to also support legacy UAs that do 790 not include any specific provisions for the handling of signed JWTs, 791 Section 3.3 defines a mechanism using HTTP Cookies [RFC6265] that 792 allows such UAs to support the concept of renewing signed JWTs 793 without requiring any additional UA support. 795 3.2.1. Required Claims 797 The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12) 798 MUST both be present for Signed Token Renewal. cdnistt MAY be set to 799 a value of '0' to mean no Signed Token Renewal, but there still MUST 800 be a corresponding cdniets that verifies as a JSON number. However, 801 if use of Signed Token Renewal is not desired, it is RECOMMENDED to 802 simply omit both. 804 3.3. Communicating a signed JWTs in Signed Token Renewal 806 This section assumes the value of the CDNI Signed Token Transport 807 (cdnistt) claim has been set to 1. 809 When using the Signed Token Renewal mechanism, the signed JWT is 810 transported to the UA via a 'URISigningPackage' cookie added to the 811 HTTP 2xx Successful message along with the content being returned to 812 the UA, or to the HTTP 3xx Redirection message in case the UA is 813 redirected to a different server. 815 3.3.1. Support for cross-domain redirection 817 For security purposes, the use of cross-domain cookies is not 818 supported in some application environments. As a result, the Cookie- 819 based method for transport of the Signed Token described in 820 Section 3.3 might break if used in combination with an HTTP 3xx 821 Redirection response where the target URL is in a different domain. 822 In such scenarios, Signed Token Renewal of a signed JWT SHOULD be 823 communicated via the query string instead, in a similar fashion to 824 how regular signed JWTs (outside of Signed Token Renewal) are 825 communicated. Note the value of the CDNI Signed Token Transport 826 (cdnistt) claim MUST be set to 2. 828 Note that the process described herein only works in cases where both 829 the manifest file and segments constituting the segmented content are 830 delivered from the same domain. In other words, any redirection 831 between different domains needs to be carried out while retrieving 832 the manifest file. 834 4. Relationship with CDNI Interfaces 836 Some of the CDNI Interfaces need enhancements to support URI Signing. 837 A dCDN that supports URI Signing needs to be able to advertise this 838 capability to the uCDN. The uCDN needs to select a dCDN based on 839 such capability when the CSP requires access control to enforce its 840 distribution policy via URI Signing. Also, the uCDN needs to be able 841 to distribute via the CDNI Metadata interface the information 842 necessary to allow the dCDN to verify a Signed URI. Events that 843 pertain to URI Signing (e.g., request denial or delivery after an 844 access authorization decision has been made) need to be included in 845 the logs communicated through the CDNI Logging interface. 847 4.1. CDNI Control Interface 849 URI Signing has no impact on this interface. 851 4.2. CDNI Footprint & Capabilities Advertisement Interface 853 The CDNI Request Routing: Footprint and Capabilities Semantics 854 document [RFC8008] defines support for advertising CDNI Metadata 855 capabilities, via CDNI Payload Type. The CDNI Payload Type 856 registered in Section 6.1 can be used for capability advertisement. 858 4.3. CDNI Request Routing Redirection Interface 860 The CDNI Request Routing Redirection Interface [RFC7975] describes 861 the recursive request redirection method. For URI Signing, the uCDN 862 signs the URI provided by the dCDN. URI Signing therefore has no 863 impact on this interface. 865 4.4. CDNI Metadata Interface 867 The CDNI Metadata Interface [RFC8006] describes the CDNI metadata 868 distribution needed to enable content acquisition and delivery. For 869 URI Signing, a new CDNI metadata object is specified. 871 The UriSigning Metadata object contains information to enable URI 872 Signing and verification by a dCDN. The UriSigning properties are 873 defined below. 875 Property: enforce 877 Description: URI Signing enforcement flag. Specifically, this 878 flag indicates if the access to content is subject to URI 879 Signing. URI Signing requires the dCDN to ensure that the URI 880 is signed and verified before delivering content. Otherwise, 881 the dCDN does not perform verification, regardless of whether 882 or not the URI is signed. 884 Type: Boolean 886 Mandatory-to-Specify: No. The default is true. 888 Property: issuers 890 Description: A list of valid Issuers against which the Issuer 891 claim in the signed JWT may be cross-referenced. 893 Type: Array of Strings 895 Mandatory-to-Specify: No. The default is an empty list. An 896 empty list means that any Issuer in the trusted key store of 897 issuers is acceptable. 899 Property: package-attribute 901 Description: The attribute name to use for the URI Signing 902 Package. 904 Type: String 906 Mandatory-to-Specify: No. The default is "URISigningPackage". 908 Property: jwt-header 910 Description: The header part of JWT that is used for verifying 911 a signed JWT when the JWT token in the URI Signing Package does 912 not contain a header part. 914 Type: String 916 Mandatory-to-Specify: No. By default, the header is assumed to 917 be included in the JWT token. 919 The following is an example of a URI Signing metadata payload with 920 all default values: 922 { 923 "generic-metadata-type": "MI.UriSigning" 924 "generic-metadata-value": {} 925 } 927 The following is an example of a URI Signing metadata payload with 928 explicit values: 930 { 931 "generic-metadata-type": "MI.UriSigning" 932 "generic-metadata-value": 933 { 934 "enforce": true, 935 "issuers": ["csp", "ucdn1", "ucdn2"], 936 "package-attribute": "usp", 937 "jwt-header": 938 { 939 "alg": "ES256", 940 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0" 941 } 942 } 943 } 945 4.5. CDNI Logging Interface 947 For URI Signing, the dCDN reports that enforcement of the access 948 control was applied to the request for content delivery. When the 949 request is denied due to enforcement of URI Signing, the reason is 950 logged. 952 The following CDNI Logging field for URI Signing SHOULD be supported 953 in the HTTP Request Logging Record as specified in CDNI Logging 954 Interface [RFC7937], using the new "cdni_http_request_v2" record-type 955 registered in Section 6.2.1. 957 * s-uri-signing (mandatory): 959 - format: 3DIGIT 961 - field value: this characterises the URI Signing verification 962 performed by the Surrogate on the request. The allowed values 963 are registered in Section 6.4. 965 - occurrence: there MUST be zero or exactly one instance of this 966 field. 968 * s-uri-signing-deny-reason (optional): 970 - format: QSTRING 972 - field value: a string for providing further information in case 973 the signed JWT was rejected, e.g., for debugging purposes. 975 - occurrence: there MUST be zero or exactly one instance of this 976 field. 978 5. URI Signing Message Flow 980 URI Signing supports both HTTP-based and DNS-based request routing. 981 JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of 982 representing claims to be transferred between two parties. The 983 claims in a Signed JWT are encoded as a JSON object that is used as 984 the payload of a JSON Web Signature (JWS) structure enabling the 985 claims to be digitally signed or integrity protected with a Message 986 Authentication Code (MAC). 988 5.1. HTTP Redirection 990 For HTTP-based request routing, a set of information that is unique 991 to a given end user content request is included in a Signed JWT, 992 using key information that is specific to a pair of adjacent CDNI 993 hops (e.g., between the CSP and the uCDN or between the uCDN and a 994 dCDN). This allows a CDNI hop to ascertain the authenticity of a 995 given request received from a previous CDNI hop. 997 The URI Signing method (assuming HTTP redirection, iterative request 998 routing, and a CDN path with two CDNs) includes the following steps: 1000 End-User dCDN uCDN CSP 1001 | | | | 1002 | 1.CDNI FCI interface used to | | 1003 | advertise URI Signing capability| | 1004 | |------------------->| | 1005 | | | | 1006 | 2.Provides information to verify Signed JWT | 1007 | | |<-------------------| 1008 | | | | 1009 | 3.CDNI Metadata interface used to| | 1010 | provide URI Signing attributes| | 1011 | |<-------------------| | 1012 : : : : 1014 : (Later in time) : : : 1015 |4.Authorization request | | 1016 |------------------------------------------------------------->| 1017 | | | [Apply distribution 1018 | | | policy] | 1019 | | | | 1020 | | (ALT: Authorization decision) 1021 |5.Request is denied | | | 1022 |<-------------------------------------------------------------| 1023 | | | | 1024 |6.CSP provides signed URI | | 1025 |<-------------------------------------------------------------| 1026 | | | | 1027 |7.Content request | | | 1028 |---------------------------------------->| [Verifiy URI | 1029 | | | signature] | 1030 | | | | 1031 | | (ALT: Verification result) | 1032 |8.Request is denied | | | 1033 |<----------------------------------------| | 1034 | | | | 1035 |9.Re-sign URI and redirect to | | 1036 | dCDN (newly signed URI) | | 1037 |<----------------------------------------| | 1038 | | | | 1039 |10.Content request | | | 1040 |------------------->| [Verify URI | | 1041 | | signature] | | 1042 | | | | 1043 | (ALT: Verification result) | | 1044 |11.Request is denied| | | 1045 |<-------------------| | | 1046 | | | | 1047 |12.Content delivery | | | 1048 |<-------------------| | | 1049 : : : : 1050 : (Later in time) : : : 1051 |13.CDNI Logging interface to include URI Signing information | 1052 | |------------------->| | 1054 Figure 3: HTTP-based Request Routing with URI Signing 1056 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1057 the dCDN advertises its capabilities including URI Signing 1058 support to the uCDN. 1060 2. CSP provides to the uCDN the information needed to verify signed 1061 URIs from that CSP. For example, this information will include 1062 one or more keys used for validation. 1064 3. Using the CDNI Metadata interface, the uCDN communicates to a 1065 dCDN the information needed to verify signed URIs from the uCDN 1066 for the given CSP. For example, this information may include 1067 the URI query string parameter name for the URI Signing Package 1068 Attribute in addition to keys used for validation. 1070 4. When a UA requests a piece of protected content from the CSP, 1071 the CSP makes a specific authorization decision for this unique 1072 request based on its local distribution policy. 1074 5. If the authorization decision is negative, the CSP rejects the 1075 request and sends an error code (e.g., 403 Forbidden) in the 1076 HTTP response. 1078 6. If the authorization decision is positive, the CSP computes a 1079 Signed JWT that is based on unique parameters of that request 1080 and conveys it to the end user as the URI to use to request the 1081 content. 1083 7. On receipt of the corresponding content request, the uCDN 1084 verifies the Signed JWT in the URI using the information 1085 provided by the CSP. 1087 8. If the verification result is negative, the uCDN rejects the 1088 request and sends an error code 403 Forbidden in the HTTP 1089 response. 1091 9. If the verification result is positive, the uCDN computes a 1092 Signed JWT that is based on unique parameters of that request 1093 and provides it to the end user as the URI to use to further 1094 request the content from the dCDN. 1096 10. On receipt of the corresponding content request, the dCDN 1097 verifies the Signed JWT in the signed URI using the information 1098 provided by the uCDN in the CDNI Metadata. 1100 11. If the verification result is negative, the dCDN rejects the 1101 request and sends an error code 403 Forbidden in the HTTP 1102 response. 1104 12. If the verification result is positive, the dCDN serves the 1105 request and delivers the content. 1107 13. At a later time, the dCDN reports logging events that include 1108 URI Signing information. 1110 With HTTP-based request routing, URI Signing matches well the general 1111 chain of trust model of CDNI both with symmetric and asymmetric keys 1112 because the key information only needs to be specific to a pair of 1113 adjacent CDNI hops. 1115 Note: While using a symmetric shared key is supported, it is NOT 1116 RECOMMENDED. See the Security Considerations (Section 7) section 1117 about the limitations of shared keys. 1119 5.2. DNS Redirection 1121 For DNS-based request routing, the CSP and uCDN must agree on a trust 1122 model appropriate to the security requirements of the CSP's 1123 particular content. Use of asymmetric public/private keys allows for 1124 unlimited distribution of the public key to dCDNs. However, if a 1125 shared secret key is required, then the distribution SHOULD be 1126 performed by the CSP directly. 1128 Note: While using a symmetric shared key is supported, it is NOT 1129 RECOMMENDED. See the Security Considerations (Section 7) section 1130 about the limitations of shared keys. 1132 The URI Signing method (assuming iterative DNS request routing and a 1133 CDN path with two CDNs) includes the following steps. 1135 End-User dCDN uCDN CSP 1136 | | | | 1137 | 1.CDNI FCI interface used to | | 1138 | advertise URI Signing capability| | 1139 | |------------------->| | 1140 | | | | 1141 | 2.Provides information to verify Signed JWT | 1142 | | |<-------------------| 1143 | 3.CDNI Metadata interface used to| | 1144 | provide URI Signing attributes| | 1145 | |<-------------------| | 1146 : : : : 1147 : (Later in time) : : : 1148 |4.Authorization request | | 1149 |------------------------------------------------------------->| 1150 | | | [Apply distribution 1151 | | | policy] | 1152 | | | | 1153 | | (ALT: Authorization decision) 1154 |5.Request is denied | | | 1155 |<-------------------------------------------------------------| 1156 | | | | 1157 |6.Provides signed URI | | 1158 |<-------------------------------------------------------------| 1159 | | | | 1160 |7.DNS request | | | 1161 |---------------------------------------->| | 1162 | | | | 1163 |8.Redirect DNS to dCDN | | 1164 |<----------------------------------------| | 1165 | | | | 1166 |9.DNS request | | | 1167 |------------------->| | | 1168 | | | | 1169 |10.IP address of Surrogate | | 1170 |<-------------------| | | 1171 | | | | 1172 |11.Content request | | | 1173 |------------------->| [Verify URI | | 1174 | | signature] | | 1175 | | | | 1176 | (ALT: Verification result) | | 1177 |12.Request is denied| | | 1178 |<-------------------| | | 1179 | | | | 1180 |13.Content delivery | | | 1181 |<-------------------| | | 1182 : : : : 1183 : (Later in time) : : : 1184 |14.CDNI Logging interface to report URI Signing information | 1185 | |------------------->| | 1187 Figure 4: DNS-based Request Routing with URI Signing 1189 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1190 the dCDN advertises its capabilities including URI Signing 1191 support to the uCDN. 1193 2. CSP provides to the uCDN the information needed to verify Signed 1194 JWTs from that CSP. For example, this information will include 1195 one or more keys used for validation. 1197 3. Using the CDNI Metadata interface, the uCDN communicates to a 1198 dCDN the information needed to verify Signed JWTs from the CSP 1199 (e.g., the URI query string parameter name for the URI Signing 1200 Package Attribute). In the case of symmetric shared key, the 1201 uCDN MUST NOT share the key with a dCDN. 1203 4. When a UA requests a piece of protected content from the CSP, 1204 the CSP makes a specific authorization decision for this unique 1205 request based on its local distribution policy. 1207 5. If the authorization decision is negative, the CSP rejects the 1208 request and sends an error code (e.g., 403 Forbidden) in the 1209 HTTP response. 1211 6. If the authorization decision is positive, the CSP computes a 1212 Signed JWT that is based on unique parameters of that request 1213 and includes it in the URI provided to the end user to request 1214 the content. 1216 7. End user sends DNS request to the uCDN. 1218 8. On receipt of the DNS request, the uCDN redirects the request to 1219 the dCDN. 1221 9. End user sends DNS request to the dCDN. 1223 10. On receipt of the DNS request, the dCDN responds with IP address 1224 of one of its Surrogates. 1226 11. On receipt of the corresponding content request, the dCDN 1227 verifies the Signed JWT in the URI using the information 1228 provided by the uCDN in the CDNI Metadata. 1230 12. If the verification result is negative, the dCDN rejects the 1231 request and sends an error code 403 Forbidden in the HTTP 1232 response. 1234 13. If the verification result is positive, the dCDN serves the 1235 request and delivers the content. 1237 14. At a later time, dCDN reports logging events that includes URI 1238 Signing information. 1240 With DNS-based request routing, URI Signing matches well the general 1241 chain of trust model of CDNI when used with asymmetric keys because 1242 the only key information that needs to be distributed across 1243 multiple, possibly untrusted, CDNI hops is the public key, which is 1244 generally not confidential. 1246 With DNS-based request routing, URI Signing does not match well with 1247 the general chain of trust model of CDNI when used with symmetric 1248 keys because the symmetric key information needs to be distributed 1249 across multiple CDNI hops, to CDNs with which the CSP may not have a 1250 trust relationship. This raises a security concern for applicability 1251 of URI Signing with symmetric keys in case of DNS-based inter-CDN 1252 request routing. Due to these flaws, this architecture MUST NOT be 1253 implemented. 1255 Note: While using a symmetric shared key is supported, it is NOT 1256 RECOMMENDED. See the Security Considerations (Section 7) section 1257 about the limitations of shared keys. 1259 6. IANA Considerations 1261 6.1. CDNI Payload Type 1263 This document requests the registration of the following CDNI Payload 1264 Type under the IANA "CDNI Payload Types" registry: 1266 +===============+===============+ 1267 | Payload Type | Specification | 1268 +===============+===============+ 1269 | MI.UriSigning | RFCthis | 1270 +---------------+---------------+ 1272 Table 1 1274 [RFC Editor: Please replace RFCthis with the published RFC number for 1275 this document.] 1277 6.1.1. CDNI UriSigning Payload Type 1279 Purpose: The purpose of this payload type is to distinguish 1280 UriSigning MI objects (and any associated capability advertisement). 1282 Interface: MI/FCI 1284 Encoding: see Section 4.4 1286 6.2. CDNI Logging Record Type 1288 This document requests the registration of the following CDNI Logging 1289 record-type under the IANA "CDNI Logging record-types" registry: 1291 +======================+===========+===========================+ 1292 | record-types | Reference | Description | 1293 +======================+===========+===========================+ 1294 | cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | 1295 | | | Record version 1 for | 1296 | | | content delivery using | 1297 | | | HTTP, to include URI | 1298 | | | Signing logging fields | 1299 +----------------------+-----------+---------------------------+ 1301 Table 2 1303 [RFC Editor: Please replace RFCthis with the published RFC number for 1304 this document.] 1306 6.2.1. CDNI Logging Record Version 2 for HTTP 1308 The "cdni_http_request_v2" record-type supports all of the fields 1309 supported by the "cdni_http_request_v1" record-type [RFC7937] plus 1310 the two additional fields "s-uri-signing" and "s-uri-signing-deny- 1311 reason", registered by this document in Section 6.3. The name, 1312 format, field value, and occurence information for the two new fields 1313 can be found in Section 4.5 of this document. 1315 6.3. CDNI Logging Field Names 1317 This document requests the registration of the following CDNI Logging 1318 fields under the IANA "CDNI Logging Field Names" registry: 1320 +===========================+===========+ 1321 | Field Name | Reference | 1322 +===========================+===========+ 1323 | s-uri-signing | RFCthis | 1324 +---------------------------+-----------+ 1325 | s-uri-signing-deny-reason | RFCthis | 1326 +---------------------------+-----------+ 1328 Table 3 1330 [RFC Editor: Please replace RFCthis with the published RFC number for 1331 this document.] 1333 6.4. CDNI URI Signing Verification Code 1335 The IANA is requested to create a new "CDNI URI Signing Verification 1336 Code" subregistry, in the "Content Delivery Networks Interconnection 1337 (CDNI) Parameters" registry. The "CDNI URI Signing Verification 1338 Code" namespace defines the valid values associated with the s-uri- 1339 signing CDNI Logging Field. The CDNI URI Signing Verification Code 1340 is a 3DIGIT value as defined in Section 4.5. Additions to the CDNI 1341 URI Signing Verification Code namespace will conform to the 1342 "Specification Required" policy as defined in [RFC8126]. Updates to 1343 this subregistry are expected to be infrequent. 1345 +=======+===========+=====================================+ 1346 | Value | Reference | Description | 1347 +=======+===========+=====================================+ 1348 | 000 | RFCthis | No signed JWT verification | 1349 | | | performed | 1350 +-------+-----------+-------------------------------------+ 1351 | 200 | RFCthis | Signed JWT verification performed | 1352 | | | and verified | 1353 +-------+-----------+-------------------------------------+ 1354 | 400 | RFCthis | Signed JWT verification performed | 1355 | | | and rejected because of incorrect | 1356 | | | signature | 1357 +-------+-----------+-------------------------------------+ 1358 | 401 | RFCthis | Signed JWT verification performed | 1359 | | | and rejected because of Issuer | 1360 | | | enforcement | 1361 +-------+-----------+-------------------------------------+ 1362 | 402 | RFCthis | Signed JWT verification performed | 1363 | | | and rejected because of Subject | 1364 | | | enforcement | 1365 +-------+-----------+-------------------------------------+ 1366 | 403 | RFCthis | Signed JWT verification performed | 1367 | | | and rejected because of Audience | 1368 | | | enforcement | 1369 +-------+-----------+-------------------------------------+ 1370 | 404 | RFCthis | Signed JWT verification performed | 1371 | | | and rejected because of Expiration | 1372 | | | Time enforcement | 1373 +-------+-----------+-------------------------------------+ 1374 | 405 | RFCthis | Signed JWT verification performed | 1375 | | | and rejected because of Not Before | 1376 | | | enforcement | 1377 +-------+-----------+-------------------------------------+ 1378 | 406 | RFCthis | Signed JWT verification performed | 1379 | | | and rejected because only one of | 1380 | | | CDNI Signed Token Transport or CDNI | 1381 | | | Expiration Time Setting present. | 1382 +-------+-----------+-------------------------------------+ 1383 | 407 | RFCthis | Signed JWT verification performed | 1384 | | | and rejected because of JWT ID | 1385 | | | enforcement | 1386 +-------+-----------+-------------------------------------+ 1387 | 408 | RFCthis | Signed JWT verification performed | 1388 | | | and rejected because of Version | 1389 | | | enforcement | 1390 +-------+-----------+-------------------------------------+ 1391 | 409 | RFCthis | Signed JWT verification performed | 1392 | | | and rejected because of Critical | 1393 | | | Extension enforcement | 1394 +-------+-----------+-------------------------------------+ 1395 | 410 | RFCthis | Signed JWT verification performed | 1396 | | | and rejected because of Client IP | 1397 | | | enforcement | 1398 +-------+-----------+-------------------------------------+ 1399 | 411 | RFCthis | Signed JWT verification performed | 1400 | | | and rejected because of URI | 1401 | | | Container enforcement | 1402 +-------+-----------+-------------------------------------+ 1403 | 500 | RFCthis | Unable to perform signed JWT | 1404 | | | verification because of malformed | 1405 | | | URI | 1406 +-------+-----------+-------------------------------------+ 1408 Table 4 1410 [RFC Editor: Please replace RFCthis with the published RFC number for 1411 this document.] 1413 6.5. CDNI URI Signing Signed Token Transport 1415 The IANA is requested to create a new "CDNI URI Signing Signed Token 1416 Transport" subregistry in the "Content Delivery Networks 1417 Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing 1418 Signed Token Transport" namespace defines the valid values that may 1419 be in the Signed Token Transport (cdnistt) JWT claim. Additions to 1420 the Signed Token Transport namespace conform to the "Specification 1421 Required" policy as defined in [RFC8126]. Updates to this 1422 subregistry are expected to be infrequent. 1424 The following table defines the initial Enforcement Information 1425 Elements: 1427 +=======+=============================================+=========+ 1428 | Value | Description | RFC | 1429 +=======+=============================================+=========+ 1430 | 0 | Designates token transport is not enabled | RFCthis | 1431 +-------+---------------------------------------------+---------+ 1432 | 1 | Designates token transport via cookie | RFCthis | 1433 +-------+---------------------------------------------+---------+ 1434 | 2 | Designates token transport via query string | RFCthis | 1435 +-------+---------------------------------------------+---------+ 1437 Table 5 1439 [RFC Editor: Please replace RFCthis with the published RFC number for 1440 this document.] 1442 6.6. JSON Web Token Claims Registration 1444 This specification registers the following Claims in the IANA "JSON 1445 Web Token Claims" registry [IANA.JWT.Claims] established by 1446 [RFC7519]. 1448 6.6.1. Registry Contents 1450 * Claim Name: cdniv 1451 * Claim Description: CDNI Claim Set Version 1452 * Change Controller: IESG 1453 * Specification Document(s): Section 2.1.8 of [[ this specification 1454 ]] 1456 * Claim Name: cdnicrit 1457 * Claim Description: CDNI Critical Claims Set 1458 * Change Controller: IESG 1459 * Specification Document(s): Section 2.1.9 of [[ this specification 1460 ]] 1462 * Claim Name: cdniip 1463 * Claim Description: CDNI IP Address 1464 * Change Controller: IESG 1465 * Specification Document(s): Section 2.1.10 of [[ this specification 1466 ]] 1468 * Claim Name: cdniuc 1469 * Claim Description: CDNI URI Container 1470 * Change Controller: IESG 1471 * Specification Document(s): Section 2.1.11 of [[ this specification 1472 ]] 1474 * Claim Name: cdniets 1475 * Claim Description: CDNI Expiration Time Setting for Signed Token 1476 Renewal 1477 * Change Controller: IESG 1478 * Specification Document(s): Section 2.1.12 of [[ this specification 1479 ]] 1481 * Claim Name: cdnistt 1482 * Claim Description: CDNI Signed Token Transport Method for Signed 1483 Token Renewal 1484 * Change Controller: IESG 1485 * Specification Document(s): Section 2.1.13 of [[ this specification 1486 ]] 1488 * Claim Name: cdnistd 1489 * Claim Description: CDNI Signed Token Depth 1490 * Change Controller: IESG 1491 * Specification Document(s): Section 2.1.14 of [[ this specification 1492 ]] 1494 6.7. Expert Review Guidance 1496 Generally speaking, we should determine the registration has a 1497 rational justification and does not duplicate a previous 1498 registration. Early assignment should be permissible as long as 1499 there is a reasonable expectation that the specification will become 1500 formalized. Expert Reviewers should be empowered to make 1501 determinations, but generally speaking they should allow new claims 1502 that do not otherwise introduce conflicts with implementation or 1503 things that may lead to confusion. They should also follow the 1504 guidelines of [RFC8126] Section 5 when sensible. 1506 7. Security Considerations 1508 This document describes the concept of URI Signing and how it can be 1509 used to provide access authorization in the case of CDNI. The 1510 primary goal of URI Signing is to make sure that only authorized UAs 1511 are able to access the content, with a CSP being able to authorize 1512 every individual request. It should be noted that URI Signing is not 1513 a content protection scheme; if a CSP wants to protect the content 1514 itself, other mechanisms, such as DRM, are more appropriate. 1516 CDNI URI Signing Signed Tokens leverage JSON Web Tokens and thus 1517 guidelines in [RFC8725] are applicable for all JWT interactions. 1519 In general, it holds that the level of protection against 1520 illegitimate access can be increased by including more claims in the 1521 signed JWT. The current version of this document includes claims for 1522 enforcing Issuer, Client IP Address, Not Before time, and Expiration 1523 Time, however this list can be extended with other, more complex, 1524 attributes that are able to provide some form of protection against 1525 some of the vulnerabilities highlighted below. 1527 That said, there are a number of aspects that limit the level of 1528 security offered by URI Signing and that anybody implementing URI 1529 Signing should be aware of. 1531 * Replay attacks: A (valid) Signed URI may be used to perform replay 1532 attacks. The vulnerability to replay attacks can be reduced by 1533 picking a relatively short window between the Not Before time and 1534 Expiration Time attributes, although this is limited by the fact 1535 that any HTTP-based request needs a window of at least a couple of 1536 seconds to prevent sudden network issues from denying legitimate 1537 UAs access to the content. One may also reduce exposure to replay 1538 attacks by including a unique one-time access ID via the JWT ID 1539 attribute (jti claim). Whenever the dCDN receives a request with 1540 a given unique ID, it adds that ID to the list of 'used' IDs. In 1541 the case an illegitimate UA tries to use the same URI through a 1542 replay attack, the dCDN can deny the request based on the already- 1543 used access ID. This list should be kept bounded. A reasonable 1544 approach would be to expire the entries based on the exp claim 1545 value. If no exp claim is present then a simple LRU could be 1546 used, however this would allow values to eventually be reused. 1548 * Illegitimate clients behind a NAT: In cases where there are 1549 multiple users behind the same NAT, all users will have the same 1550 IP address from the point of view of the dCDN. This results in 1551 the dCDN not being able to distinguish between different users 1552 based on Client IP Address which can lead to illegitimate users 1553 being able to access the content. One way to reduce exposure to 1554 this kind of attack is to not only check for Client IP but also 1555 for other attributes, e.g., attributes that can be found in HTTP 1556 headers. However, this may be easily circumvented by a 1557 sophisticated attacker. 1559 A shared key distribured between CSP and uCDN is more likely to be 1560 compromised. Since this key can be used to legitimately sign a URL 1561 for content access authorization, it is important to know the 1562 implications of a compromised shared key. While using a shared key 1563 scheme can be convenient, this architecture is NOT RECOMMENDED due to 1564 the risks associated. It is included for legacy feature parity and 1565 is highly discouraged in new implementations. 1567 If a shared key usable for signing is compromised, an attacker can 1568 use it to perform a denial-of-service attack by forcing the CDN to 1569 evaluate prohibitively expensive regular expressions embedded in a 1570 URI Container (cdniuc) claim. As a result, compromised keys should 1571 be timely revoked in order to prevent exploitation. 1573 The URI Container (cdniuc) claim can be given a wildcard value. 1574 This, combined with the fact that it is the only mandatory claim, 1575 means you can effectively make a skeleton key. Doing this does not 1576 sufficiently limit the scope of the JWT and is NOT RECOMMENDED. The 1577 only way to prevent such a key from being used after it is 1578 distributed is to revoke the signing key so it no longer validates. 1580 8. Privacy 1582 The privacy protection concerns described in CDNI Logging Interface 1583 [RFC7937] apply when the client's IP address (cdniip) or Subject 1584 (sub) is embedded in the Signed URI. For this reason, the mechanism 1585 described in Section 2 encrypts the Client IP or Subject before 1586 including it in the URI Signing Package (and thus the URL itself). 1588 9. Acknowledgements 1590 The authors would like to thank the following people for their 1591 contributions in reviewing this document and providing feedback: 1592 Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan 1593 York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana 1594 Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris 1595 Lemmons. 1597 10. Contributors 1599 In addition, the authors would also like to make special mentions for 1600 certain people who contributed significant sections to this document. 1602 * Matt Caulfield provided content for the CDNI Metadata Interface 1603 section. 1605 * Emmanuel Thomas provided content for HTTP Adaptive Streaming. 1607 * Matt Miller provided consultation on JWT usage as well as code to 1608 generate working JWT examples. 1610 11. References 1612 11.1. Normative References 1614 [POSIX.1] "The Open Group Base Specifications Issue 7", IEEE 1615 Std 1003.1 2018 Edition, 31 January 2018, 1616 . 1618 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1619 DOI 10.17487/RFC0791, September 1981, 1620 . 1622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1623 Requirement Levels", BCP 14, RFC 2119, 1624 DOI 10.17487/RFC2119, March 1997, 1625 . 1627 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1628 Resource Identifier (URI): Generic Syntax", STD 66, 1629 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1630 . 1632 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1633 "Network Time Protocol Version 4: Protocol and Algorithms 1634 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1635 . 1637 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1638 Address Text Representation", RFC 5952, 1639 DOI 10.17487/RFC5952, August 2010, 1640 . 1642 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1643 DOI 10.17487/RFC6265, April 2011, 1644 . 1646 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 1647 and D. Orchard, "URI Template", RFC 6570, 1648 DOI 10.17487/RFC6570, March 2012, 1649 . 1651 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1652 Distribution Network Interconnection (CDNI) Problem 1653 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1654 2012, . 1656 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1657 Keranen, A., and P. Hallam-Baker, "Naming Things with 1658 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1659 . 1661 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1662 Protocol (HTTP/1.1): Message Syntax and Routing", 1663 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1664 . 1666 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1667 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1668 . 1670 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1671 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1672 . 1674 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 1675 and R. Peterkofsky, "Content Distribution Network 1676 Interconnection (CDNI) Logging Interface", RFC 7937, 1677 DOI 10.17487/RFC7937, August 2016, 1678 . 1680 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1681 "Content Delivery Network Interconnection (CDNI) 1682 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1683 . 1685 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1686 Writing an IANA Considerations Section in RFCs", BCP 26, 1687 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1688 . 1690 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1691 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1692 May 2017, . 1694 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1695 Interchange Format", STD 90, RFC 8259, 1696 DOI 10.17487/RFC8259, December 2017, 1697 . 1699 11.2. Informative References 1701 [IANA.JWT.Claims] 1702 IANA, "JSON Web Token Claims", 1703 . 1705 [MPEG-DASH] 1706 ISO, "Information technology -- Dynamic adaptive streaming 1707 over HTTP (DASH) -- Part 1: Media presentation description 1708 and segment format", ISO/IEC 23009-1:2014, Edition 2, May 1709 2014, . 1711 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 1712 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 1713 Content Distribution Network Interconnection (CDNI)", 1714 RFC 6983, DOI 10.17487/RFC6983, July 2013, 1715 . 1717 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1718 "Framework for Content Distribution Network 1719 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1720 August 2014, . 1722 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1723 Network Interconnection (CDNI) Requirements", RFC 7337, 1724 DOI 10.17487/RFC7337, August 2014, 1725 . 1727 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1728 DOI 10.17487/RFC7517, May 2015, 1729 . 1731 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1732 "Request Routing Redirection Interface for Content 1733 Delivery Network (CDN) Interconnection", RFC 7975, 1734 DOI 10.17487/RFC7975, October 2016, 1735 . 1737 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1738 R., and K. Ma, "Content Delivery Network Interconnection 1739 (CDNI) Request Routing: Footprint and Capabilities 1740 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1741 . 1743 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 1744 RFC 8216, DOI 10.17487/RFC8216, August 2017, 1745 . 1747 [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 1748 Current Practices", BCP 225, RFC 8725, 1749 DOI 10.17487/RFC8725, February 2020, 1750 . 1752 Appendix A. Signed URI Package Example 1754 This section contains three examples of token usage: a simple example 1755 with only the required claim present, a complex example which 1756 demonstrates the full JWT claims set, including an encrypted Client 1757 IP Address (cdniip), and one that uses a Signed Token Renewal. 1759 Note: All of the examples have whitespace added to improve formatting 1760 and readability, but are not present in the generated content. 1762 All examples use the following JWK Set [RFC7517]: 1764 { "keys": [ 1765 { 1766 "kty": "EC", 1767 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1768 "use": "sig", 1769 "alg": "ES256", 1770 "crv": "P-256", 1771 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1772 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA" 1773 }, 1774 { 1775 "kty": "EC", 1776 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1777 "use": "sig", 1778 "alg": "ES256", 1779 "crv": "P-256", 1780 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1781 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", 1782 "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" 1783 }, 1784 { 1785 "kty": "oct", 1786 "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", 1787 "use": "enc", 1788 "alg": "A128GCM", 1789 "k": "4uFxxV7fhNmrtiah2d1fFg" 1790 } 1791 ]} 1793 Note: They are the public signing key, the private signing key, and 1794 the shared secret enctyption key, respectively. The public and 1795 private signing keys have the same fingerprint and only vary by the 1796 'd' parameter that is missing from the public signing key. 1798 A.1. Simple Example 1800 This example is a simple common usage example containing a minimal 1801 subset of claims that the authors find most useful. 1803 The JWT Claim Set before signing: 1805 Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the 1806 URL Segment form ([RFC6920] Section 5) of "http://cdni.example/foo/ 1807 bar". 1809 { 1810 "exp": 1646867369, 1811 "iss": "uCDN Inc", 1812 "cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" 1813 } 1815 The signed JWT: 1817 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1818 dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE2NDY4NjczNjksImlzcyI6InVDRE4gS 1819 W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV 1820 wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.TaNlJM3D96i_9J9XvlICO6FUIDFTqt3E2Y 1821 JkEUOLfcH0b89wYRKTbJ9Yj6h_GRgSoZoQO0cps3yUPcWGK3smCw 1823 A.2. Complex Example 1825 This example uses all fields except for those dealing with Signed 1826 Token Renewal, including Client IP Address (cdniip) and Subject (sub) 1827 which are encrpyted. This significantly increases the size of the 1828 signed JWT token. 1830 JWE for Client IP Address (cdniip) of [2001:db8::1/32]: 1832 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1833 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBIc3nWjOb.bGXWT 1834 HPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA 1836 JWE for Subject (sub) of "UserToken": 1838 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1839 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8Bp-Ui.6P1A3 1840 F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g 1842 The JWT Claim Set before signing: 1844 { 1845 "aud": "dCDN LLC", 1846 "sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4 1847 QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8B 1848 p-Ui.6P1A3F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g", 1849 "cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY 1850 mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBI 1851 c3nWjOb.bGXWTHPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA", 1852 "cdniv": 1, 1853 "exp": 1646867369, 1854 "iat": 1646694569, 1855 "iss": "uCDN Inc", 1856 "jti": "5DAafLhZAfhsbe", 1857 "nbf": 1646780969, 1858 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png" 1859 } 1861 The signed JWT: 1863 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1864 dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib 1865 U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA 1866 0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T 1867 0NKOS4uQ0xBdTgweGNsYzhCcC1VaS42UDFBM0Y2aXAyRHYuQ29oZHRMTHBnQm5UdlJ 1868 KUUNGdXotZyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja 1869 m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp 1870 2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uYVVEREZFUUJJYzNuV2pPYi5iR 1871 1hXVEhQa250bVBDS24wcFBQTkVRLml5VHR0bkZ5Yk8yWUJMcXdsX1lTakEiLCJjZG5 1872 pdiI6MSwiZXhwIjoxNjQ2ODY3MzY5LCJpYXQiOjE2NDY2OTQ1NjksImlzcyI6InVDR 1873 E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE2NDY3ODA5NjksImN 1874 kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde 1875 zN9XFwucG5nIn0.IjmVX0uD5MYqArc-M08uEsEeoDQn8kuYXZ9HGHDmDDxsHikT0c8 1876 jcX8xYD0z3LzQclMG65i1kT2sRbZ7isUw8w 1878 A.3. Signed Token Renewal Example 1880 This example uses fields for Signed Token Renewal. 1882 The JWT Claim Set before signing: 1884 { 1885 "cdniets": 30, 1886 "cdnistt": 1, 1887 "cdnistd": 2, 1888 "exp": 1646867369, 1889 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1890 } 1891 The signed JWT: 1893 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1894 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1895 XN0ZCI6MiwiZXhwIjoxNjQ2ODY3MzY5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1896 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.tlPvoKw3BCClw4Lx9 1897 PQu7MK6b2IN55ZoCPSaxovGK0zS53Wpb1MbJBow7G8LiGR39h6-2Iq7PWUSr3MdTIz 1898 HYw 1900 Once the server verifies the signed JWT it will return a new signed 1901 JWT with an updated expiry time (exp) as shown below. Note the 1902 expiry time is increased by the expiration time setting (cdniets) 1903 value. 1905 The JWT Claim Set before signing: 1907 { 1908 "cdniets": 30, 1909 "cdnistt": 1, 1910 "cdnistd": 2, 1911 "exp": 1646867399, 1912 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1913 } 1915 The signed JWT: 1917 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1918 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1919 XN0ZCI6MiwiZXhwIjoxNjQ2ODY3Mzk5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1920 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.ivY5d_fKGd-OHTpUs 1921 8uJUrnHvt-rduzu5H4zM7167pUUAghub53FqDQ5G16jRYX2sY73mA_uLpYDdb-CPts 1922 8FA 1924 Authors' Addresses 1926 Ray van Brandenburg 1927 Tiledmedia 1928 Anna van Buerenplein 1 1929 Den Haag 1930 Phone: +31 88 866 7000 1931 Email: ray@tiledmedia.com 1933 Kent Leung 1934 Email: mail4kentl@gmail.com 1935 Phil Sorber 1936 Apple, Inc. 1937 1800 Wazee Street 1938 Suite 410 1939 Denver, CO 80202 1940 United States 1941 Email: sorber@apple.com