idnits 2.17.1 draft-ietf-cdni-uri-signing-21.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 299 has weird spacing: '...I(after v ...' -- The document date (February 11, 2021) is 1163 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: August 15, 2021 Cisco Systems, Inc. 6 P. Sorber 7 Apple, Inc. 8 February 11, 2021 10 URI Signing for Content Delivery Network Interconnection (CDNI) 11 draft-ietf-cdni-uri-signing-21 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 August 15, 2021. 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 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Background and overview on URI Signing . . . . . . . . . 5 63 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 64 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 65 2. JWT Format and Processing Requirements . . . . . . . . . . . 9 66 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9 67 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10 68 2.1.2. Subject (sub) claim . . . . . . . . . . . . . . . . . 10 69 2.1.3. Audience (aud) claim . . . . . . . . . . . . . . . . 11 70 2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 11 71 2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11 72 2.1.6. Issued At (iat) claim . . . . . . . . . . . . . . . . 11 73 2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 12 74 2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12 75 2.1.9. CDNI Critical Claims Set (cdnicrit) claim . . . . . . 12 76 2.1.10. Client IP (cdniip) claim . . . . . . . . . . . . . . 13 77 2.1.11. CDNI URI Container (cdniuc) claim . . . . . . . . . . 13 78 2.1.12. CDNI Expiration Time Setting (cdniets) claim . . . . 13 79 2.1.13. CDNI Signed Token Transport (cdnistt) claim . . . . . 14 80 2.1.14. CDNI Signed Token Depth (cdnistd) claim . . . . . . . 14 81 2.1.15. URI Container Forms . . . . . . . . . . . . . . . . . 14 82 2.1.15.1. URI Hash Container (hash:) . . . . . . . . . . . 15 83 2.1.15.2. URI Regular Expression Container (regex:) . . . 15 84 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 15 85 3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 16 86 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 87 3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 16 88 3.2.1. Required Claims . . . . . . . . . . . . . . . . . . . 17 89 3.3. Communicating a signed JWTs in Signed Token Renewal . . . 17 90 3.3.1. Support for cross-domain redirection . . . . . . . . 17 91 4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 18 92 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 18 93 4.2. CDNI Footprint & Capabilities Advertisement Interface . . 18 94 4.3. CDNI Request Routing Redirection Interface . . . . . . . 18 95 4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 19 96 4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 20 97 5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 21 98 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . 27 103 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 27 104 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 27 105 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 28 106 6.4. CDNI URI Signing Verification Code . . . . . . . . . . . 28 107 6.5. CDNI URI Signing Signed Token Transport . . . . . . . . . 29 108 6.6. JSON Web Token Claims Registration . . . . . . . . . . . 30 109 6.6.1. Registry Contents . . . . . . . . . . . . . . . . . . 30 110 6.7. Expert Review Guidance . . . . . . . . . . . . . . . . . 31 111 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 112 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 113 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 114 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 116 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 117 11.2. Informative References . . . . . . . . . . . . . . . . . 35 118 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 36 119 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 37 120 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 38 121 A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 39 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 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 interconnected CDNs (CDNI) and between a Content Service 129 Provider (CSP) and a CDN. The primary goal of URI Signing is to make 130 sure that only authorized UAs are able to access the content, with a 131 CSP being able to authorize every individual request. It should be 132 noted that URI Signing is not a content protection scheme; if a CSP 133 wants to protect the content itself, other mechanisms, such as 134 Digital Rights Management (DRM), are more appropriate. In addition 135 to access control, URI Signing also has benefits in reducing the 136 impact of 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 o Signed URI: A URI for which a signed JWT is provided. 190 o 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 o 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 o 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 by including a set of 213 claims in the form of a signed JWT in the URI before redirecting a UA 214 to the CDN. Using these attributes, it is possible for a CDN to 215 check an incoming content request to see whether it was authorized by 216 the CSP (e.g., based on the UA's IP address or a time window). To 217 prevent the UA from altering the claims a JWT MUST be signed. 219 Figure 1, shown below, presents an overview of the URI Signing 220 mechanism in the case of a CSP with a single CDN. When the UA 221 browses for content on CSP's website (#1), it receives HTML web pages 222 with embedded content URIs. Upon requesting these URIs, the CSP 223 redirects to a CDN, creating a Target CDN URI (#2) (alternatively, 224 the Target CDN URI itself is embedded in the HTML). The Target CDN 225 URI is the Signed URI which may include the IP address of the UA and/ 226 or a time window. The signed URI always contains a signed JWT 227 generated by the CSP using a shared secret or private key. Once the 228 UA receives the response with the Signed URI, it sends a new HTTP 229 request using the Signed URI to the CDN (#3). Upon receiving the 230 request, the CDN authenticates the Signed URI by verifying the signed 231 JWT. If applicable, the CDN checks whether the source IP address of 232 the HTTP request matches the one in the Signed URI and/or if the time 233 window is still valid. After these claims are verified, the CDN 234 delivers the content (#4). 236 -------- 237 / \ 238 | CSP |< * * * * * * * * * * * 239 \ / Trust * 240 -------- relationship * 241 ^ | * 242 | | * 243 1. Browse | | 2. Signed * 244 for | | URI * 245 content | | * 246 | v v 247 +------+ 3. Signed URI -------- 248 | User |----------------->/ \ 249 | Agent| | CDN | 250 | |<-----------------\ / 251 +------+ 4. Content -------- 252 Delivery 254 Figure 1: Figure 1: URI Signing in a CDN Environment 256 1.3. CDNI URI Signing Overview 258 In a CDNI environment, as shown in Figure 2 below, URI Signing 259 operates the same way in the initial steps #1 and #2 but the later 260 steps involve multiple CDNs delivering the content. The main 261 difference from the single CDN case is a redirection step between the 262 uCDN and the dCDN. In step #3, the UA may send an HTTP request or a 263 DNS request. Depending on whether HTTP-based or DNS-based request 264 routing is used. The uCDN responds by directing the UA towards the 265 dCDN using either a Redirection URI (i.e., a Signed URI generated by 266 the uCDN) or a DNS reply, respectively (#4). Once the UA receives 267 the response, it sends the Redirection URI/Target CDN URI to the dCDN 268 (#5). The received URI is verified by the dCDN before delivering the 269 content (#6). Note: The CDNI call flows are covered in Detailed URI 270 Signing Operation (Section 5). 272 +-------------------------+ 273 |Request Redirection Modes| 274 +-------------------------+ 275 | a) HTTP | 276 | b) DNS | 277 +-------------------------+ 278 -------- 279 / \< * * * * * * * * * * * * * * 280 | CSP |< * * * * * * * * * * * * 281 \ / Trust * * 282 -------- relationship * * 283 ^ | * * 284 | | 2. Signed * * 285 1. Browse | | URI in * * 286 for | | HTML * * 287 content | | * * 288 | v 3.a)Signed URI v * 289 +------+ b)DNS request -------- * Trust 290 | User |----------------->/ \ * relationship 291 | Agent| | uCDN | * (optional) 292 | |<-----------------\ / * 293 +------+ 4.a)Redirection URI------- * 294 ^ | b)DNS Reply ^ * 295 | | * * 296 | | Trust relationship * * 297 | | * * 298 6. Content | | 5.a)Redirection URI * * 299 delivery | | b)Signed URI(after v v 300 | | DNS exchange) -------- 301 | +---------------------->/ \ [May be 302 | | dCDN | cascaded 303 +--------------------------\ / CDNs] 304 -------- 306 Figure 2: URI Signing in a CDNI Environment 308 The trust relationships between CSP, uCDN, and dCDN have direct 309 implications for URI Signing. In the case shown in Figure 2, the CSP 310 has a trust relationship with the uCDN. The delivery of the content 311 may be delegated to a dCDN, which has a relationship with the uCDN 312 but may have no relationship with the CSP. 314 In CDNI, there are two methods for request routing: DNS-based and 315 HTTP-based. For DNS-based request routing, the Signed URI (i.e., the 316 Target CDN URI) provided by the CSP reaches the dCDN directly. In 317 the case where the dCDN does not have a trust relationship with the 318 CSP, this means that either an asymmetric public/private key method 319 needs to be used for computing the signed JWT (because the CSP and 320 dCDN are not able to exchange symmetric shared secret keys), or the 321 CSP needs to allow the uCDN to redistribute shared keys to a subset 322 of their dCDNs. 324 For HTTP-based request routing, the Signed URI (i.e., the Target CDN 325 URI) provided by the CSP reaches the uCDN. After this URI has been 326 verified by the uCDN, the uCDN creates and signs a new Redirection 327 URI, redirecting the UA to the dCDN. Since this new URI can have a 328 new signed JWT, the relationship between the dCDN and CSP is not 329 relevant. Because a relationship between uCDN and dCDN always 330 exists, either asymmetric public/private keys or symmetric shared 331 secret keys can be used for URI Signing with HTTP-based request 332 routing. Note that the signed Redirection URI MUST maintain the same 333 (or higher) level of security as the original Signed URI. 335 +------------------------------------------+ 336 | Mode | Asymmetric Key | Symmetric Key | 337 +------------------------------------------+ 338 |HTTP |Public key (uCDN)|Shared key (uCDN)| 339 |DNS |Public key (CSP) |Shared key (CSP) | 340 +------------------------------------------+ 342 Figure 3: CDNI URI Signing Key 344 Two types of keys can be used for URI Signing: asymmetric keys and 345 symmetric keys. Asymmetric keys are based on a public/private key 346 pair mechanism and always contain a private key known only to the 347 entity signing the URI (either CSP or uCDN) and a public key for the 348 verification of the Signed URI. With symmetric keys, the same key is 349 used by both the signing entity for signing the URI and the verifying 350 entity for verifying the Signed URI. Regardless of the type of keys 351 used, the verifying entity has to obtain the key (either the public 352 or the symmetric key). There are very different requirements 353 (outside the scope of this document) for distributing asymmetric keys 354 and symmetric keys. Key distribution for symmetric keys requires 355 confidentiality to prevent third parties from getting access to the 356 key, since they could then generate valid Signed URIs for 357 unauthorized requests. Key distribution for asymmetric keys does not 358 require confidentiality since public keys can typically be 359 distributed openly (because they cannot be used to sign URIs) and the 360 corresponding private keys are kept secret by the URI signer. 362 1.4. URI Signing in a non-CDNI context 364 While the URI Signing method defined in this document was primarily 365 created for the purpose of allowing URI Signing in CDNI scenarios, 366 i.e., between a uCDN and a dCDN, there is nothing in the defined URI 367 Signing method that precludes it from being used in a non-CDNI 368 context. As such, the described mechanism could be used in a single- 369 CDN scenario such as shown in Figure 1 in Section 1.2, for example to 370 allow a CSP that uses different CDNs to only have to implement a 371 single URI Signing mechanism. 373 2. JWT Format and Processing Requirements 375 The concept behind URI Signing is based on embedding a signed JSON 376 Web Token (JWT) [RFC7519] in an HTTP or HTTPS URI [RFC7230] (see 377 [RFC7230] Section 2.7). The signed JWT contains a number of claims 378 that can be verified to ensure the UA has legitimate access to the 379 content. 381 This document specifies the following attribute for embedding a 382 signed JWT in a Target CDN URI or Redirection URI: 384 o URI Signing Package (URISigningPackage): The URI attribute that 385 encapsulates all the URI Signing claims in a signed JWT encoded 386 format. This attribute is exposed in the Signed URI as a path- 387 style parameter or a form-style parameter. 389 The parameter name of the URI Signing Package Attribute is defined in 390 the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is 391 not used, or does not include a parameter name for the URI Signing 392 Package Attribute, the parameter name can be set by configuration 393 (out of scope of this document). 395 The URI Signing Package will be found by parsing any path-style 396 parameters and form-style parameters looking for a key name matching 397 the URI Signing Package Attribute. Both parameter styles MUST be 398 supported to allow flexibility of operation. The first matching 399 parameter SHOULD be taken to provide the signed JWT, though providing 400 more than one matching key is undefined behavior. 402 The following is an example where the URI Signing Package Attribute 403 name is "token" and the signed JWT is "SIGNEDJWT": 405 http://example.com/media/path?come=data&token=SIGNEDJWT&other=data 407 2.1. JWT Claims 409 This section identifies the set of claims that can be used to enforce 410 the CSP distribution policy. New claims can be introduced in the 411 future to extend the distribution policy capabilities. 413 In order to provide distribution policy flexibility, the exact subset 414 of claims used in a given signed JWT is a runtime decision. Claim 415 requirements are defined in the CDNI Metadata (Section 4.4). If the 416 CDNI Metadata interface is not used, or does not include claim 417 requirements, the claim requirements can be set by configuration (out 418 of scope of this document). 420 The following claims (where the "JSON Web Token Claims" registry 421 claim name is specified in parenthesis below) are used to enforce the 422 distribution policies. All of the listed claims are mandatory to 423 implement in a URI Signing implementation, but are not mandatory to 424 use in a given signed JWT. (The "optional" and "mandatory" 425 identifiers in square brackets refer to whether or not a given claim 426 MUST be present in a URI Signing JWT.) 428 Note: The time on the entities that generate and verify the signed 429 URI SHOULD be in sync. In the CDNI case, this means that CSP, uCDN, 430 and dCDN servers need to be time-synchronized. It is RECOMMENDED to 431 use NTP [RFC5905] for time synchronization. 433 Note: See the Security Considerations (Section 7) section on the 434 limitations of using an expiration time and client IP address for 435 distribution policy enforcement. 437 2.1.1. Issuer (iss) claim 439 Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1 440 MUST be followed. This claim MAY be used to verify authorization of 441 the issuer of a signed JWT and also MAY be used to confirm that the 442 indicated key was provided by said issuer. If the CDN verifying the 443 signed JWT does not support Issuer verification, or if the Issuer in 444 the signed JWT does not match the list of known acceptable Issuers, 445 the CDN MUST reject the request. If the received signed JWT contains 446 an Issuer claim, then any JWT subsequently generated for CDNI 447 redirection MUST also contain an Issuer claim, and the Issuer value 448 MUST be updated to identify the redirecting CDN. If the received 449 signed JWT does not contain an Issuer claim, an Issuer claim MAY be 450 added to a signed JWT generated for CDNI redirection. 452 2.1.2. Subject (sub) claim 454 Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2 455 MUST be followed. If this claim is used, it MUST be a JSON Web 456 Encryption (JWE [RFC7516]) Object in compact serialization form, 457 because it contains personally identifiable information. This claim 458 contains information about the subject (for example, a user or an 459 agent) that MAY be used to verify the signed JWT. If the received 460 signed JWT contains a Subject claim, then any JWT subsequently 461 generated for CDNI redirection MUST also contain a Subject claim, and 462 the Subject value MUST be the same as in the received signed JWT. A 463 signed JWT generated for CDNI redirection MUST NOT add a Subject 464 claim if no Subject claim existed in the received signed JWT. 466 2.1.3. Audience (aud) claim 468 Audience (aud) [optional] - The semantics in [RFC7519] Section 4.1.3 469 MUST be followed. This claim is used to ensure that the CDN verifing 470 the JWT is an intended recipient of the request. The claim should 471 contain an identity on behalf of whom the CDN can verify the token 472 (e.g., the CSP or any uCDN in the chain). A dCDN MAY modify the 473 claim as long it can generate a valid signature. 475 2.1.4. Expiry Time (exp) claim 477 Expiry Time (exp) [optional] - The semantics in [RFC7519] 478 Section 4.1.4 MUST be followed, though URI Signing implementations 479 MUST NOT allow for any time synchronization "leeway". If the CDN 480 verifying the signed JWT does not support Expiry Time verification, 481 or if the Expiry Time in the signed JWT corresponds to a time equal 482 to or earlier than the time of the content request, the CDN MUST 483 reject the request. If the received signed JWT contains a Expiry 484 Time claim, then any JWT subsequently generated for CDNI redirection 485 MUST also contain an Expiry Time claim, and the Expiry Time value 486 MUST be the same as in the received signed JWT. A signed JWT 487 generated for CDNI redirection MUST NOT add an Expiry Time claim if 488 no Expiry Time claim existed in the received signed JWT. 490 2.1.5. Not Before (nbf) claim 492 Not Before (nbf) [optional] - The semantics in [RFC7519] 493 Section 4.1.5 MUST be followed, though URI Signing implementations 494 MUST NOT allow for any time synchronization "leeway". If the CDN 495 verifying the signed JWT does not support Not Before time 496 verification, or if the Not Before time in the signed JWT corresponds 497 to a time later than the time of the content request, the CDN MUST 498 reject the request. If the received signed JWT contains a Not Before 499 time claim, then any JWT subsequently generated for CDNI redirection 500 MUST also contain a Not Before time claim, and the Not Before time 501 value MUST be the same as in the received signed JWT. A signed JWT 502 generated for CDNI redirection MUST NOT add a Not Before time claim 503 if no Not Before time claim existed in the received signed JWT. 505 2.1.6. Issued At (iat) claim 507 Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6 508 MUST be followed. If the received signed JWT contains an Issued At 509 claim, then any JWT subsequently generated for CDNI redirection MUST 510 also contain an Issued At claim, and the Issuer value MUST be updated 511 to identify the time the new JWT was generated. If the received 512 signed JWT does not contain an Issued At claim, an Issued At claim 513 MAY be added to a signed JWT generated for CDNI redirection. 515 2.1.7. Nonce (jti) claim 517 Nonce (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 518 MUST be followed. A Nonce can be used to prevent replay attacks if 519 the CDN stores a list of all previously used Nonce values, and 520 verifies that the Nonce in the current JWT has never been used 521 before. If the signed JWT contains a Nonce claim and the CDN 522 verifying the signed JWT either does not support Nonce storage or has 523 previously seen the Nonce used in a request for the same content, 524 then the CDN MUST reject the request. If the received signed JWT 525 contains a Nonce claim, then any JWT subsequently generated for CDNI 526 redirection MUST also contain a Nonce claim, and the Nonce value MUST 527 be the same as in the received signed JWT. If the received signed 528 JWT does not contain a Nonce claim, a Nonce claim MUST NOT be added 529 to a signed JWT generated for CDNI redirection. 531 2.1.8. CDNI Claim Set Version (cdniv) claim 533 CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set 534 Version (cdniv) claim provides a means within a signed JWT to tie the 535 claim set to a specific version of this specification. The cdniv 536 claim is intended to allow changes in and facilitate upgrades across 537 specifications. The type is JSON integer and the value MUST be set 538 to "1", for this version of the specification. In the absence of 539 this claim, the value is assumed to be "1". For future versions this 540 claim will be mandatory. Implementations MUST reject signed JWTs 541 with unsupported CDNI Claim Set versions. 543 2.1.9. CDNI Critical Claims Set (cdnicrit) claim 545 CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical 546 Claims Set (cdnicrit) claim indicates that extensions to this 547 specification are being used that MUST be understood and processed. 548 Its value is a comma separated listing of claims in the Signed JWT 549 that use those extensions. If any of the listed extension claims are 550 not understood and supported by the recipient, then the Signed JWT is 551 invalid. Producers MUST NOT include claim names defined by this 552 specification, duplicate names, or names that do not occur as claim 553 names within the Signed JWT in the cdnicrit list. Producers MUST NOT 554 use the empty list "" as the cdnicrit value. Recipients MAY consider 555 the Signed JWT to be invalid if the cdnicrit list contains any claim 556 names defined by this specification or if any other constraints on 557 its use are violated. This claim MUST be understood and processed by 558 all implementations. 560 2.1.10. Client IP (cdniip) claim 562 Client IP (cdniip) [optional] - The Client IP (cdniip) claim holds an 563 IP address or IP prefix for which the Signed URI is valid. This is 564 represented in CIDR notation, with dotted decimal format for IPv4 565 addresses [RFC0791] or canonical text representation for IPv6 566 addresses [RFC5952]. The request MUST be rejected if sourced from a 567 client outside of the specified IP range. Since the client IP is 568 considered personally identifiable information this field MUST be a 569 JSON Web Encryption (JWE [RFC7516]) Object in compact serialization 570 form. If the CDN verifying the signed JWT does not support Client IP 571 verification, or if the Client IP in the signed JWT does not match 572 the source IP address in the content request, the CDN MUST reject the 573 request. The type of this claim is a JSON string that contains the 574 JWE. If the received signed JWT contains a Client IP claim, then any 575 JWT subsequently generated for CDNI redirection MUST also contain a 576 Client IP claim, and the Client IP value MUST be the same as in the 577 received signed JWT. A signed JWT generated for CDNI redirection 578 MUST NOT add a Client IP claim if no Client IP claim existed in the 579 received signed JWT. 581 2.1.11. CDNI URI Container (cdniuc) claim 583 URI Container (cdniuc) [optional] - The URI Container (cdniuc) holds 584 the URI representation before a URI Signing Package is added. This 585 representation can take one of several forms detailed in 586 Section 2.1.15. If the URI Container used in the signed JWT does not 587 match the URI of the content request, the CDN verifying the signed 588 JWT MUST reject the request. When comparing the URI, the percent 589 encoded form as defined in [RFC3986] Section 2.1 MUST be used. When 590 redirecting a URI, the CDN generating the new signed JWT MAY change 591 the URI Container to comport with the URI being used in the 592 redirection. 594 2.1.12. CDNI Expiration Time Setting (cdniets) claim 596 CDNI Expiration Time Setting (cdniets) [optional] - The CDNI 597 Expiration Time Setting (cdniets) claim provides a means for setting 598 the value of the Expiry Time (exp) claim when generating a subsequent 599 signed JWT in Signed Token Renewal. Its type is a JSON numeric 600 value. It denotes the number of seconds to be added to the time at 601 which the JWT is verified that gives the value of the Expiry Time 602 (exp) claim of the next signed JWT. The CDNI Expiration Time Setting 603 (cdniets) SHOULD NOT be used when not using Signed Token Renewal and 604 MUST be present when using Signed Token Renewal. 606 2.1.13. CDNI Signed Token Transport (cdnistt) claim 608 CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed 609 Token Transport (cdnistt) claim provides a means of signalling the 610 method through which a new signed JWT is transported from the CDN to 611 the UA and vice versa for the purpose of Signed Token Renewal. Its 612 type is a JSON integer. Values for this claim are defined in 613 Section 6.5. If using this claim you MUST also specify a CDNI 614 Expiration Time Setting (cdniets) as noted above. 616 2.1.14. CDNI Signed Token Depth (cdnistd) claim 618 CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token 619 Depth (cdnistd) claim is used to associate a subsequent signed JWT, 620 generated as the result of a CDNI Signed Token Transport claim, with 621 a specific URI subset. Its type is a JSON integer. Signed JWTs MUST 622 NOT use a negative value for the CDNI Signed Token Depth claim. 624 If the transport used for Signed Token Transport allows the CDN to 625 associate the path component of a URI with tokens (e.g., an HTTP 626 Cookie Path as described in section 4.1.2.4 of [RFC6265]), the CDNI 627 Signed Token Depth value is the number of path segments that should 628 be considered significant for this association. A CDNI Signed Token 629 Depth of zero means that the client SHOULD be directed to return the 630 token with requests for any path. If the CDNI Signed Token Depth is 631 greater than zero, then the client SHOULD be directed to return the 632 token for future requests wherein the first CDNI Signed Token Depth 633 segments of the path match the first CDNI Signed Token Depth segments 634 of the signed URI path. This matching MUST use the URI with the 635 token removed, as specified in Section 2.1.15. 637 If the URI path to match contains fewer segments than the CDNI Signed 638 Token Depth claim, a signed JWT MUST NOT be generated for the 639 purposes of Signed Token Renewal. If the CDNI Signed Token Depth 640 claim is omitted, it means the same thing as if its value were zero. 641 If the received signed JWT contains a CDNI Signed Token Depth claim, 642 then any JWT subsequently generated for CDNI redirection or Signed 643 Token Transport MUST also contain a CDNI Signed Token Depth claim, 644 and the value MUST be the same as in the received signed JWT. 646 2.1.15. URI Container Forms 648 The URI Container (cdniuc) claim takes one of the following forms: 649 'hash:' or 'regex:'. More forms may be added in the future to extend 650 the capabilities. 652 Before comparing a URI with contents of this container, the following 653 steps MUST be performed: 655 o Prior to verification, remove the signed JWT from the URI. This 656 removal is only for the purpose of determining if the URI matches; 657 all other purposes will use the original URI. If the signed JWT 658 is terminated by anything other than a sub-delimiter (as definined 659 in [RFC3986] Section 2.2), everything from the reserved character 660 (as defined in [RFC3986] Section 2.2) that precedes the URI 661 Signing Package Attribute to the last character of the signed JWT 662 will be removed, inclusive. Otherwise, everything from the first 663 character of the URI Signing Package Attribute to the sub- 664 delimiter that terminates the signed JWT will be removed, 665 inclusive. 667 o Normalize the URI according to section 2.7.3 [RFC7230] and 668 sections 6.2.2 and 6.2.3 [RFC3986]. This applies to both 669 generation and verification of the signed JWT. 671 2.1.15.1. URI Hash Container (hash:) 673 Prefixed with 'hash:', this string is a URL Segment form ([RFC6920] 674 Section 5) of the URI. 676 2.1.15.2. URI Regular Expression Container (regex:) 678 Prefixed with 'regex:', this string is any POSIX Section 9 [POSIX.1] 679 Extended Regular Expression compatible regular expression used to 680 match against the requested URI. These regular expressions MUST be 681 evaluated in the POSIX locale (POSIX Section 7.2 [POSIX.1]). 683 Note: Because '\' has special meaning in JSON [RFC8259] as the escape 684 character within JSON strings, the regular expression character '\' 685 MUST be escaped as '\\'. 687 An example of a 'regex:' is the following: 689 [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)? 691 Note: Due to computational complexity of executing arbitrary regular 692 expressions, it is RECOMMENDED to only execute after verifying the 693 JWT to ensure its authenticity. 695 2.2. JWT Header 697 The header of the JWT MAY be passed via the CDNI Metadata interface 698 instead of being included in the URISigningPackage. The header value 699 must be transmitted in the serialized encoded form and prepended to 700 the JWT payload and signature passed in the URISigningPackage prior 701 to verification. This reduces the size of the signed JWT token. 703 3. URI Signing Token Renewal 705 3.1. Overview 707 For content that is delivered via HTTP in a segmented fashion, such 708 as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216], 709 special provisions need to be made in order to ensure URI Signing can 710 be applied. In general, segmented protocols work by breaking large 711 objects (e.g., videos) into a sequence of small independent segments. 712 Such segments are then referenced by a separate manifest file, which 713 either includes a list of URLs to the segments or specifies an 714 algorithm through which a User Agent can construct the URLs to the 715 segments. Requests for segments therefore originate from the 716 manifest file and, unless the URLs in the manifest file point to the 717 CSP, are not subjected to redirection and URI Signing. This opens up 718 a vulnerability to malicious User Agents sharing the manifest file 719 and deep-linking to the segments. 721 One method for dealing with this vulnerability would be to include, 722 in the manifest itself, Signed URIs that point to the individual 723 segments. There exist a number of issues with that approach. First, 724 it requires the CDN delivering the manifest to rewrite the manifest 725 file for each User Agent, which would require the CDN to be aware of 726 the exact segmentation protocol used. Secondly, it could also 727 require the expiration time of the Signed URIs to be valid for an 728 extended duration if the content described by the manifest is meant 729 to be consumed in real time. For instance, if the manifest file were 730 to contain a segmented video stream of more than 30 minutes in 731 length, Signed URIs would require to be valid for a at least 30 732 minutes, thereby reducing their effectiveness and that of the URI 733 Signing mechanism in general. For a more detailed analysis of how 734 segmented protocols such as HTTP Adaptive Streaming protocols affect 735 CDNI, see Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. 737 The method described in this section allows CDNs to use URI Signing 738 for segmented content without having to include the Signed URIs in 739 the manifest files themselves. 741 3.2. Signed Token Renewal mechanism 743 In order to allow for effective access control of segmented content, 744 the URI Signing mechanism defined in this section is based on a 745 method through which subsequent segment requests can be linked 746 together. As part of the JWT verification procedure, the CDN can 747 generate a new signed JWT that the UA can use to do a subsequent 748 request. More specifically, whenever a UA successfully retrieves a 749 segment, it receives, in the HTTP 2xx Successful message, a signed 750 JWT that it can use whenever it requests the next segment. As long 751 as each successive signed JWT is correctly verified before a new one 752 is generated, the model is not broken and the User Agent can 753 successfully retrieve additional segments. Given the fact that with 754 segmented protocols, it is usually not possible to determine a priori 755 which segment will be requested next (i.e., to allow for seeking 756 within the content and for switching to a different representation), 757 the Signed Token Renewal uses the URI Regular Expression Container 758 scoping mechanisms in the URI Container (cdniuc) claim to allow a 759 signed JWT to be valid for more than one URL. 761 In order for this renewal of signed JWTs to work, it is necessary for 762 a UA to extract the signed JWT from the HTTP 2xx Successful message 763 of an earlier request and use it to retrieve the next segment. The 764 exact mechanism by which the client does this is outside the scope of 765 this document. However, in order to also support legacy UAs that do 766 not include any specific provisions for the handling of signed JWTs, 767 Section 3.3 defines a mechanism using HTTP Cookies [RFC6265] that 768 allows such UAs to support the concept of renewing signed JWTs 769 without requiring any additional UA support. 771 3.2.1. Required Claims 773 The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12) 774 MUST both be present for Signed Token Renewal. You MAY set cdnistt 775 to a value of '0' to mean no Signed Token Renewal, but you still MUST 776 have a corresponding cdniets that verifies as a JSON number. 777 However, if you do not want to use Signed Token Renewal, it is 778 RECOMMENDED to simply omit both. 780 3.3. Communicating a signed JWTs in Signed Token Renewal 782 This section assumes the value of the CDNI Signed Token Transport 783 (cdnistt) claim has been set to 1. Other values of cdnistt are out 784 of scope of this document. 786 When using the Signed Token Renewal mechanism, the signed JWT is 787 transported to the UA via a 'URISigningPackage' cookie added to the 788 HTTP 2xx Successful message along with the content being returned to 789 the UA, or to the HTTP 3xx Redirection message in case the UA is 790 redirected to a different server. 792 3.3.1. Support for cross-domain redirection 794 For security purposes, the use of cross-domain cookies is not 795 supported in some application environments. As a result, the Cookie- 796 based method for transport of the Signed Token described in 797 Section 3.3 might break if used in combination with an HTTP 3xx 798 Redirection response where the target URL is in a different domain. 800 In such scenarios, Signed Token Renewal of a signed JWT SHOULD be 801 communicated via the query string instead, in a similar fashion to 802 how regular signed JWTs (outside of Signed Token Renewal) are 803 communicated. Note that the use of URL embedded signed JWTs SHOULD 804 NOT be used in HTTP 2xx Successful messages, since UAs might not know 805 how to extract the signed JWTs. 807 Note that the process described herein only works in cases where both 808 the manifest file and segments constituting the segmented content are 809 delivered from the same domain. In other words, any redirection 810 between different domains needs to be carried out while retrieving 811 the manifest file. 813 4. Relationship with CDNI Interfaces 815 Some of the CDNI Interfaces need enhancements to support URI Signing. 816 A dCDN that supports URI Signing needs to be able to advertise this 817 capability to the uCDN. The uCDN needs to select a dCDN based on 818 such capability when the CSP requires access control to enforce its 819 distribution policy via URI Signing. Also, the uCDN needs to be able 820 to distribute via the CDNI Metadata interface the information 821 necessary to allow the dCDN to verify a Signed URI. Events that 822 pertain to URI Signing (e.g., request denial or delivery after access 823 authorization) need to be included in the logs communicated through 824 the CDNI Logging interface. 826 4.1. CDNI Control Interface 828 URI Signing has no impact on this interface. 830 4.2. CDNI Footprint & Capabilities Advertisement Interface 832 The CDNI Request Routing: Footprint and Capabilities Semantics 833 document [RFC8008] defines support for advertising CDNI Metadata 834 capabilities, via CDNI Payload Type. The CDNI Payload Type 835 registered in Section 6.1 can be used for capability advertisement. 837 4.3. CDNI Request Routing Redirection Interface 839 The CDNI Request Routing Redirection Interface [RFC7975] describes 840 the recursive request redirection method. For URI Signing, the uCDN 841 signs the URI provided by the dCDN. URI Signing therefore has has no 842 impact on this interface. 844 4.4. CDNI Metadata Interface 846 The CDNI Metadata Interface [RFC8006] describes the CDNI metadata 847 distribution needed to enable content acquisition and delivery. For 848 URI Signing, a new CDNI metadata object is specified. 850 The UriSigning Metadata object contains information to enable URI 851 Signing and verification by a dCDN. The UriSigning properties are 852 defined below. 854 Property: enforce 856 Description: URI Signing enforcement flag. Specifically, this 857 flag indicates if the access to content is subject to URI 858 Signing. URI Signing requires the dCDN to ensure that the URI 859 is signed and verified before delivering content. Otherwise, 860 the dCDN does not perform verification, regardless of whether 861 or not the URI is signed. 863 Type: Boolean 865 Mandatory-to-Specify: No. The default is true. 867 Property: issuers 869 Description: A list of valid Issuers against which the Issuer 870 claim in the signed JWT may be verified. 872 Type: Array of Strings 874 Mandatory-to-Specify: No. The default is an empty list. An 875 empty list means that any Issuer is acceptable. 877 Property: package-attribute 879 Description: The name to use for the URI Signing Package. 881 Type: String 883 Mandatory-to-Specify: No. The default is "URISigningPackage". 885 Property: jwt-header 887 Description: The header part of JWT that is used for generating 888 or verifying a signed JWT when the JWT token in the URI Signing 889 Package does not contain a header part. 891 Type: String 892 Mandatory-to-Specify: No. By default, the header is assumed to 893 be included in the JWT token. 895 The following is an example of a URI Signing metadata payload with 896 all default values: 898 { 899 "generic-metadata-type": "MI.UriSigning" 900 "generic-metadata-value": {} 901 } 903 The following is an example of a URI Signing metadata payload with 904 explicit values: 906 { 907 "generic-metadata-type": "MI.UriSigning" 908 "generic-metadata-value": 909 { 910 "enforce": true, 911 "issuers": ["csp", "ucdn1", "ucdn2"], 912 "package-attribute": "usp", 913 "jwt-header": 914 { 915 "alg": "ES256", 916 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0" 917 } 918 } 919 } 921 4.5. CDNI Logging Interface 923 For URI Signing, the dCDN reports that enforcement of the access 924 control was applied to the request for content delivery. When the 925 request is denied due to enforcement of URI Signing, the reason is 926 logged. 928 The following CDNI Logging field for URI Signing SHOULD be supported 929 in the HTTP Request Logging Record as specified in CDNI Logging 930 Interface [RFC7937], using the new "cdni_http_request_v2" record-type 931 registered in Section 6.2.1. 933 o s-uri-signing (mandatory): 935 * format: 3DIGIT 936 * field value: this characterises the URI Signing verification 937 performed by the Surrogate on the request. The allowed values 938 are registered in Section 6.4. 940 * occurrence: there MUST be zero or exactly one instance of this 941 field. 943 o s-uri-signing-deny-reason (optional): 945 * format: QSTRING 947 * field value: a string for providing further information in case 948 the signed JWT was rejected, e.g., for debugging purposes. 950 * occurrence: there MUST be zero or exactly one instance of this 951 field. 953 5. URI Signing Message Flow 955 URI Signing supports both HTTP-based and DNS-based request routing. 956 JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of 957 representing claims to be transferred between two parties. The 958 claims in a signed JWT are encoded as a JSON object that is used as 959 the payload of a JSON Web Signature (JWS) structure or as the 960 plaintext of a JSON Web Encryption (JWE) structure, enabling the 961 claims to be digitally signed or integrity protected with a Message 962 Authentication Code (MAC) and/or encrypted. 964 5.1. HTTP Redirection 966 For HTTP-based request routing, a set of information that is unique 967 to a given end user content request is included in a signed JWT, 968 using key information that is specific to a pair of adjacent CDNI 969 hops (e.g., between the CSP and the uCDN or between the uCDN and a 970 dCDN). This allows a CDNI hop to ascertain the authenticity of a 971 given request received from a previous CDNI hop. 973 The URI Signing method (assuming HTTP redirection, iterative request 974 routing, and a CDN path with two CDNs) includes the following steps: 976 End-User dCDN uCDN CSP 977 | | | | 978 | 1.CDNI FCI interface used to | | 979 | advertise URI Signing capability| | 980 | |------------------->| | 981 | | | | 982 | 2.Provides information to verify signed JWT | 983 | | |<-------------------| 984 | | | | 985 | 3.CDNI Metadata interface used to| | 986 | provide URI Signing attributes| | 987 | |<-------------------| | 988 : : : : 989 : (Later in time) : : : 990 |4.Authorization request | | 991 |------------------------------------------------------------->| 992 | | | [Apply distribution 993 | | | policy] | 994 | | | | 995 | | (ALT: Authorization decision) 996 |5.Request is denied | | | 997 |<-------------------------------------------------------------| 998 | | | | 999 |6.CSP provides signed URI | | 1000 |<-------------------------------------------------------------| 1001 | | | | 1002 |7.Content request | | | 1003 |---------------------------------------->| [Verifiy URI | 1004 | | | signature] | 1005 | | | | 1006 | | (ALT: Verification result) | 1007 |8.Request is denied | | | 1008 |<----------------------------------------| | 1009 | | | | 1010 |9.Re-sign URI and redirect to | | 1011 | dCDN (newly signed URI) | | 1012 |<----------------------------------------| | 1013 | | | | 1014 |10.Content request | | | 1015 |------------------->| [Verify URI | | 1016 | | signature] | | 1017 | | | | 1018 | (ALT: Verification result) | | 1019 |11.Request is denied| | | 1020 |<-------------------| | | 1021 | | | | 1022 |12.Content delivery | | | 1023 |<-------------------| | | 1024 : : : : 1025 : (Later in time) : : : 1026 |13.CDNI Logging interface to include URI Signing information | 1027 | |------------------->| | 1029 Figure 4: HTTP-based Request Routing with URI Signing 1031 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1032 the dCDN advertises its capabilities including URI Signing 1033 support to the uCDN. 1035 2. CSP provides to the uCDN the information needed to verify signed 1036 JWTs from that CSP. For example, this information may include a 1037 key value. 1039 3. Using the CDNI Metadata interface, the uCDN communicates to a 1040 dCDN the information needed to verify signed JWTs from the uCDN 1041 for the given CSP. For example, this information may include 1042 the URI query string parameter name for the URI Signing Package 1043 Attribute. 1045 4. When a UA requests a piece of protected content from the CSP, 1046 the CSP makes a specific authorization decision for this unique 1047 request based on its personal distribution policy. 1049 5. If the authorization decision is negative, the CSP rejects the 1050 request and sends an error code (e.g., 403 Forbidden) in the 1051 HTTP response. 1053 6. If the authorization decision is positive, the CSP computes a 1054 Signed URI that is based on unique parameters of that request 1055 and conveys it to the end user as the URI to use to request the 1056 content. 1058 7. On receipt of the corresponding content request, the uCDN 1059 verifies the signed JWT in the URI using the information 1060 provided by the CSP. 1062 8. If the verification is negative, the uCDN rejects the request 1063 and sends an error code 403 Forbidden in the HTTP response. 1065 9. If the verification is positive, the uCDN computes a Signed URI 1066 that is based on unique parameters of that request and provides 1067 it to the end user as the URI to use to further request the 1068 content from the dCDN. 1070 10. On receipt of the corresponding content request, the dCDN 1071 verifies the signed JWT in the Signed URI using the information 1072 provided by the uCDN in the CDNI Metadata. 1074 11. If the verification is negative, the dCDN rejects the request 1075 and sends an error code 403 Forbidden in the HTTP response. 1077 12. If the verification is positive, the dCDN serves the request and 1078 delivers the content. 1080 13. At a later time, the dCDN reports logging events that include 1081 URI Signing information. 1083 With HTTP-based request routing, URI Signing matches well the general 1084 chain of trust model of CDNI both with symmetric and asymmetric keys 1085 because the key information only needs to be specific to a pair of 1086 adjacent CDNI hops. 1088 5.2. DNS Redirection 1090 For DNS-based request routing, the CSP and uCDN must agree on a trust 1091 model appropriate to the security requirements of the CSP's 1092 particular content. Use of asymmetric public/private keys allows for 1093 unlimited distribution of the public key to dCDNs. However, if a 1094 shared secret key is preferred, then the CSP may want to restrict the 1095 distribution of the key to a (possibly empty) subset of trusted 1096 dCDNs. Authorized Delivery CDNs need to obtain the key information 1097 to verify the Signed URI. 1099 The URI Signing method (assuming iterative DNS request routing and a 1100 CDN path with two CDNs) includes the following steps. 1102 End-User dCDN uCDN CSP 1103 | | | | 1104 | 1.CDNI FCI interface used to | | 1105 | advertise URI Signing capability| | 1106 | |------------------->| | 1107 | | | | 1108 | 2.Provides information to verify signed JWT | 1109 | | |<-------------------| 1110 | 3.CDNI Metadata interface used to| | 1111 | provide URI Signing attributes| | 1112 | |<-------------------| | 1113 : : : : 1114 : (Later in time) : : : 1115 |4.Authorization request | | 1116 |------------------------------------------------------------->| 1117 | | | [Apply distribution 1118 | | | policy] | 1119 | | | | 1120 | | (ALT: Authorization decision) 1121 |5.Request is denied | | | 1122 |<-------------------------------------------------------------| 1123 | | | | 1124 |6.Provides signed URI | | 1125 |<-------------------------------------------------------------| 1126 | | | | 1127 |7.DNS request | | | 1128 |---------------------------------------->| | 1129 | | | | 1130 |8.Redirect DNS to dCDN | | 1131 |<----------------------------------------| | 1132 | | | | 1133 |9.DNS request | | | 1134 |------------------->| | | 1135 | | | | 1136 |10.IP address of Surrogate | | 1137 |<-------------------| | | 1138 | | | | 1139 |11.Content request | | | 1140 |------------------->| [Verify URI | | 1141 | | signature] | | 1142 | | | | 1143 | (ALT: Verification result) | | 1144 |12.Request is denied| | | 1145 |<-------------------| | | 1146 | | | | 1147 |13.Content delivery | | | 1148 |<-------------------| | | 1149 : : : : 1150 : (Later in time) : : : 1151 |14.CDNI Logging interface to report URI Signing information | 1152 | |------------------->| | 1154 Figure 5: DNS-based Request Routing with URI Signing 1156 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1157 the dCDN advertises its capabilities including URI Signing 1158 support to the uCDN. 1160 2. CSP provides to the uCDN the information needed to verify 1161 cryptographic signatures from that CSP. For example, this 1162 information may include a key. 1164 3. Using the CDNI Metadata interface, the uCDN communicates to a 1165 dCDN the information needed to verify cryptographic signatures 1166 from the CSP (e.g., the URI query string parameter name for the 1167 URI Signing Package Attribute). In the case of symmetric key, 1168 the uCDN checks if the dCDN is allowed by CSP to obtain the 1169 shared secret key. 1171 4. When a UA requests a piece of protected content from the CSP, 1172 the CSP makes a specific authorization decision for this unique 1173 request based on its arbitrary distribution policy. 1175 5. If the authorization decision is negative, the CSP rejects the 1176 request and sends an error code (e.g., 403 Forbidden) in the 1177 HTTP response. 1179 6. If the authorization decision is positive, the CSP computes a 1180 cryptographic signature that is based on unique parameters of 1181 that request and includes it in the URI provided to the end user 1182 to request the content. 1184 7. End user sends DNS request to the uCDN. 1186 8. On receipt of the DNS request, the uCDN redirects the request to 1187 the dCDN. 1189 9. End user sends DNS request to the dCDN. 1191 10. On receipt of the DNS request, the dCDN responds with IP address 1192 of one of its Surrogates. 1194 11. On receipt of the corresponding content request, the dCDN 1195 verifies the cryptographic signature in the URI using the 1196 information provided by the uCDN in the CDNI Metadata. 1198 12. If the verification is negative, the dCDN rejects the request 1199 and sends an error code 403 Forbidden in the HTTP response. 1201 13. If the verification is positive, the dCDN serves the request and 1202 delivers the content. 1204 14. At a later time, dCDN reports logging events that includes URI 1205 Signing information. 1207 With DNS-based request routing, URI Signing matches well the general 1208 chain of trust model of CDNI when used with asymmetric keys because 1209 the only key information that needs to be distributed across 1210 multiple, possibly untrusted, CDNI hops is the public key, which is 1211 generally not confidential. 1213 With DNS-based request routing, URI Signing does not match well the 1214 general chain of trust model of CDNI when used with symmetric keys 1215 because the symmetric key information needs to be distributed across 1216 multiple CDNI hops, to CDNs with which the CSP may not have a trust 1217 relationship. This raises a security concern for applicability of 1218 URI Signing with symmetric keys in case of DNS-based inter-CDN 1219 request routing. 1221 6. IANA Considerations 1223 6.1. CDNI Payload Type 1225 This document requests the registration of the following CDNI Payload 1226 Type under the IANA "CDNI Payload Types" registry: 1228 +---------------+---------------+ 1229 | Payload Type | Specification | 1230 +---------------+---------------+ 1231 | MI.UriSigning | RFCthis | 1232 +---------------+---------------+ 1234 [RFC Editor: Please replace RFCthis with the published RFC number for 1235 this document.] 1237 6.1.1. CDNI UriSigning Payload Type 1239 Purpose: The purpose of this payload type is to distinguish 1240 UriSigning MI objects (and any associated capability advertisement). 1242 Interface: MI/FCI 1244 Encoding: see Section 4.4 1246 6.2. CDNI Logging Record Type 1248 This document requests the registration of the following CDNI Logging 1249 record-type under the IANA "CDNI Logging record-types" registry: 1251 +----------------------+-----------+--------------------------------+ 1252 | record-types | Reference | Description | 1253 +----------------------+-----------+--------------------------------+ 1254 | cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | 1255 | | | Record version 1 for content | 1256 | | | delivery using HTTP, to | 1257 | | | include URI Signing logging | 1258 | | | fields | 1259 +----------------------+-----------+--------------------------------+ 1261 [RFC Editor: Please replace RFCthis with the published RFC number for 1262 this document.] 1264 6.2.1. CDNI Logging Record Version 2 for HTTP 1266 The "cdni_http_request_v2" record-type supports all of the fields 1267 supported by the "cdni_http_request_v1" record-type [RFC7937] plus 1268 the two additional fields "s-uri-signing" and "s-uri-signing-deny- 1269 reason", registered by this document in Section 6.3. The name, 1270 format, field value, and occurence information for the two new fields 1271 can be found in Section 4.5 of this document. 1273 6.3. CDNI Logging Field Names 1275 This document requests the registration of the following CDNI Logging 1276 fields under the IANA "CDNI Logging Field Names" registry: 1278 +---------------------------+-----------+ 1279 | Field Name | Reference | 1280 +---------------------------+-----------+ 1281 | s-uri-signing | RFCthis | 1282 | s-uri-signing-deny-reason | RFCthis | 1283 +---------------------------+-----------+ 1285 [RFC Editor: Please replace RFCthis with the published RFC number for 1286 this document.] 1288 6.4. CDNI URI Signing Verification Code 1290 The IANA is requested to create a new "CDNI URI Signing Verification 1291 Code" subregistry, in the "Content Delivery Networks Interconnection 1292 (CDNI) Parameters" registry. The "CDNI URI Signing Verification 1293 Code" namespace defines the valid values associated with the s-uri- 1294 signing CDNI Logging Field. The CDNI URI Signing Verification Code 1295 is a 3DIGIT value as defined in Section 4.5. Additions to the CDNI 1296 URI Signing Verification Code namespace will conform to the 1297 "Specification Required" policy as defined in [RFC8126]. Updates to 1298 this subregistry are expected to be sparse. 1300 +-------+-----------+-----------------------------------------------+ 1301 | Value | Reference | Description | 1302 +-------+-----------+-----------------------------------------------+ 1303 | 000 | RFCthis | No signed JWT verification performed | 1304 | 200 | RFCthis | Signed JWT verification performed and | 1305 | | | verified | 1306 | 400 | RFCthis | Signed JWT verification performed and | 1307 | | | rejected because of incorrect signature | 1308 | 401 | RFCthis | Signed JWT verification performed and | 1309 | | | rejected because of Issuer enforcement | 1310 | 402 | RFCthis | Signed JWT verification performed and | 1311 | | | rejected because of Subject enforcement | 1312 | 403 | RFCthis | Signed JWT verification performed and | 1313 | | | rejected because of Audience enforcement | 1314 | 404 | RFCthis | Signed JWT verification performed and | 1315 | | | rejected because of Expiration Time | 1316 | | | enforcement | 1317 | 405 | RFCthis | Signed JWT verification performed and | 1318 | | | rejected because of Not Before enforcement | 1319 | 406 | RFCthis | Signed JWT verification performed and | 1320 | | | rejected because of Issued At enforcement | 1321 | 407 | RFCthis | Signed JWT verification performed and | 1322 | | | rejected because of Nonce enforcement | 1323 | 408 | RFCthis | Signed JWT verification performed and | 1324 | | | rejected because of Version enforcement | 1325 | 409 | RFCthis | Signed JWT verification performed and | 1326 | | | rejected because of Critical Extention | 1327 | | | enforcement | 1328 | 410 | RFCthis | Signed JWT verification performed and | 1329 | | | rejected because of Client IP enforcement | 1330 | 411 | RFCthis | Signed JWT verification performed and | 1331 | | | rejected because of URI Container enforcement | 1332 | 500 | RFCthis | Unable to perform signed JWT verification | 1333 | | | because of malformed URI | 1334 +-------+-----------+-----------------------------------------------+ 1336 [RFC Editor: Please replace RFCthis with the published RFC number for 1337 this document.] 1339 6.5. CDNI URI Signing Signed Token Transport 1341 The IANA is requested to create a new "CDNI URI Signing Signed Token 1342 Transport" subregistry in the "Content Delivery Networks 1343 Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing 1344 Signed Token Transport" namespace defines the valid values that may 1345 be in the Signed Token Transport (cdnistt) JWT claim. Additions to 1346 the Signed Token Transport namespace conform to the "Specification 1347 Required" policy as defined in [RFC8126]. Updates to this 1348 subregistry are expected to be sparse. 1350 The following table defines the initial Enforcement Information 1351 Elements: 1353 +-------+-------------------------------------------+---------+ 1354 | Value | Description | RFC | 1355 +-------+-------------------------------------------+---------+ 1356 | 0 | Designates token transport is not enabled | RFCthis | 1357 | 1 | Designates token transport via cookie | RFCthis | 1358 +-------+-------------------------------------------+---------+ 1360 [RFC Editor: Please replace RFCthis with the published RFC number for 1361 this document.] 1363 6.6. JSON Web Token Claims Registration 1365 This specification registers the following Claims in the IANA "JSON 1366 Web Token Claims" registry [IANA.JWT.Claims] established by 1367 [RFC7519]. 1369 6.6.1. Registry Contents 1371 o Claim Name: "cdniv" 1372 o Claim Description: CDNI Claim Set Version 1373 o Change Controller: IESG 1374 o Specification Document(s): Section 2.1.8 of [[ this specification 1375 ]] 1377 o Claim Name: "cdnicrit" 1378 o Claim Description: CDNI Critical Claims Set 1379 o Change Controller: IESG 1380 o Specification Document(s): Section 2.1.9 of [[ this specification 1381 ]] 1383 o Claim Name: "cdniip" 1384 o Claim Description: CDNI IP Address 1385 o Change Controller: IESG 1386 o Specification Document(s): Section 2.1.10 of [[ this specification 1387 ]] 1389 o Claim Name: "cdniuc" 1390 o Claim Description: CDNI URI Container 1391 o Change Controller: IESG 1392 o Specification Document(s): Section 2.1.11 of [[ this specification 1393 ]] 1395 o Claim Name: "cdniets" 1396 o Claim Description: CDNI Expiration Time Setting for Signed Token 1397 Renewal 1398 o Change Controller: IESG 1399 o Specification Document(s): Section 2.1.12 of [[ this specification 1400 ]] 1402 o Claim Name: "cdnistt" 1403 o Claim Description: CDNI Signed Token Transport Method for Signed 1404 Token Renewal 1405 o Change Controller: IESG 1406 o Specification Document(s): Section 2.1.13 of [[ this specification 1407 ]] 1409 o Claim Name: "cdnistd" 1410 o Claim Description: CDNI Signed Token Depth 1411 o Change Controller: IESG 1412 o Specification Document(s): Section 2.1.14 of [[ this specification 1413 ]] 1415 6.7. Expert Review Guidance 1417 Generally speaking, we should determine the registration has a 1418 rational justification and does not duplicate a previous 1419 registration. Early assignment should be permissible as long as 1420 there is a reasonable expectation that the specification will become 1421 formalized. Expert Reviewers should be empowered to make 1422 determinations, but generally speaking they should allow new claims 1423 that do not otherwise introduce conflicts with implementation or 1424 things that may lead to confusion. They should also follow the 1425 guidelines of [RFC8126] Section 5 when sensible. 1427 7. Security Considerations 1429 This document describes the concept of URI Signing and how it can be 1430 used to provide access authorization in the case of CDNI. The 1431 primary goal of URI Signing is to make sure that only authorized UAs 1432 are able to access the content, with a CSP being able to authorize 1433 every individual request. It should be noted that URI Signing is not 1434 a content protection scheme; if a CSP wants to protect the content 1435 itself, other mechanisms, such as DRM, are more appropriate. 1437 In general, it holds that the level of protection against 1438 illegitimate access can be increased by including more claims in the 1439 signed JWT. The current version of this document includes claims for 1440 enforcing Issuer, Client IP Address, Not Before time, and Expiration 1441 Time, however this list can be extended with other, more complex, 1442 attributes that are able to provide some form of protection against 1443 some of the vulnerabilities highlighted below. 1445 That said, there are a number of aspects that limit the level of 1446 security offered by URI Signing and that anybody implementing URI 1447 Signing should be aware of. 1449 o Replay attacks: A (valid) Signed URI may be used to perform replay 1450 attacks. The vulnerability to replay attacks can be reduced by 1451 picking a relatively short window between the Not Before time and 1452 Expiration Time attributes, although this is limited by the fact 1453 that any HTTP-based request needs a window of at least a couple of 1454 seconds to prevent sudden network issues from denying legitimate 1455 UAs access to the content. One may also reduce exposure to replay 1456 attacks by including a unique one-time access ID via the Nonce 1457 attribute (jti claim). Whenever the dCDN receives a request with 1458 a given unique ID, it adds that ID to the list of 'used' IDs. In 1459 the case an illegitimate UA tries to use the same URI through a 1460 replay attack, the dCDN can deny the request based on the already- 1461 used access ID. 1463 o Illegitimate clients behind a NAT: In cases where there are 1464 multiple users behind the same NAT, all users will have the same 1465 IP address from the point of view of the dCDN. This results in 1466 the dCDN not being able to distinguish between different users 1467 based on Client IP Address which can lead to illegitimate users 1468 being able to access the content. One way to reduce exposure to 1469 this kind of attack is to not only check for Client IP but also 1470 for other attributes, e.g., attributes that can be found in HTTP 1471 headers. 1473 The shared key between CSP and uCDN may be distributed to dCDNs - 1474 including cascaded CDNs. Since this key can be used to legitimately 1475 sign a URL for content access authorization, it is important to know 1476 the implications of a compromised shared key. 1478 If a shared key usable for signing is compromised, an attacker can 1479 use it to perform a denial-of-service attack by forcing the CDN to 1480 evaluate prohibitively expensive regular expressions embedded in a 1481 cdniuc claim. As a result, compromised keys should be timely revoked 1482 in order to prevent exploitation. 1484 8. Privacy 1486 The privacy protection concerns described in CDNI Logging Interface 1487 [RFC7937] apply when the client's IP address (cdniip) is embedded in 1488 the Signed URI. For this reason, the mechanism described in 1489 Section 2 encrypts the Client IP before including it in the URI 1490 Signing Package (and thus the URL itself). 1492 9. Acknowledgements 1494 The authors would like to thank the following people for their 1495 contributions in reviewing this document and providing feedback: 1496 Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan 1497 York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana 1498 Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris 1499 Lemmons. 1501 10. Contributors 1503 In addition, the authors would also like to make special mentions for 1504 certain people who contributed significant sections to this document. 1506 o Matt Caulfield provided content for the CDNI Metadata Interface 1507 section. 1509 o Emmanuel Thomas provided content for HTTP Adaptive Streaming. 1511 o Matt Miller provided consultation on JWT usage as well as code to 1512 generate working JWT examples. 1514 11. References 1516 11.1. Normative References 1518 [POSIX.1] "The Open Group Base Specifications Issue 7", IEEE 1519 Std 1003.1 2018 Edition, Jan 2018, 1520 . 1522 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1523 DOI 10.17487/RFC0791, September 1981, 1524 . 1526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1527 Requirement Levels", BCP 14, RFC 2119, 1528 DOI 10.17487/RFC2119, March 1997, 1529 . 1531 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1532 Resource Identifier (URI): Generic Syntax", STD 66, 1533 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1534 . 1536 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1537 Address Text Representation", RFC 5952, 1538 DOI 10.17487/RFC5952, August 2010, 1539 . 1541 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1542 DOI 10.17487/RFC6265, April 2011, 1543 . 1545 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1546 Distribution Network Interconnection (CDNI) Problem 1547 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1548 2012, . 1550 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1551 Keranen, A., and P. Hallam-Baker, "Naming Things with 1552 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1553 . 1555 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1556 Protocol (HTTP/1.1): Message Syntax and Routing", 1557 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1558 . 1560 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1561 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1562 . 1564 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1565 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1566 . 1568 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 1569 and R. Peterkofsky, "Content Distribution Network 1570 Interconnection (CDNI) Logging Interface", RFC 7937, 1571 DOI 10.17487/RFC7937, August 2016, 1572 . 1574 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1575 "Content Delivery Network Interconnection (CDNI) 1576 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1577 . 1579 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1580 Writing an IANA Considerations Section in RFCs", BCP 26, 1581 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1582 . 1584 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1585 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1586 May 2017, . 1588 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1589 Interchange Format", STD 90, RFC 8259, 1590 DOI 10.17487/RFC8259, December 2017, 1591 . 1593 11.2. Informative References 1595 [IANA.JWT.Claims] 1596 IANA, "JSON Web Token Claims", 1597 . 1599 [MPEG-DASH] 1600 ISO, "Information technology -- Dynamic adaptive streaming 1601 over HTTP (DASH) -- Part 1: Media presentation description 1602 and segment format", ISO/IEC 23009-1:2014, Edition 2, 05 1603 2014, . 1605 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1606 "Network Time Protocol Version 4: Protocol and Algorithms 1607 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1608 . 1610 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 1611 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 1612 Content Distribution Network Interconnection (CDNI)", 1613 RFC 6983, DOI 10.17487/RFC6983, July 2013, 1614 . 1616 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1617 "Framework for Content Distribution Network 1618 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1619 August 2014, . 1621 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1622 Network Interconnection (CDNI) Requirements", RFC 7337, 1623 DOI 10.17487/RFC7337, August 2014, 1624 . 1626 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1627 DOI 10.17487/RFC7517, May 2015, 1628 . 1630 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1631 "Request Routing Redirection Interface for Content 1632 Delivery Network (CDN) Interconnection", RFC 7975, 1633 DOI 10.17487/RFC7975, October 2016, 1634 . 1636 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1637 R., and K. Ma, "Content Delivery Network Interconnection 1638 (CDNI) Request Routing: Footprint and Capabilities 1639 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1640 . 1642 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 1643 RFC 8216, DOI 10.17487/RFC8216, August 2017, 1644 . 1646 Appendix A. Signed URI Package Example 1648 This section contains three examples of token usage: a simple example 1649 with only the required claim present, a complex example which 1650 demonstrates the full JWT claims set, including an encrypted Client 1651 IP (cdniip), and one that uses a Signed Token Renewal. 1653 Note: All of the examples have whitespace added to improve formatting 1654 and readability, but are not present in the generated content. 1656 All examples use the following JWK Set [RFC7517]: 1658 { "keys": [ 1659 { 1660 "kty": "EC", 1661 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1662 "use": "sig", 1663 "alg": "ES256", 1664 "crv": "P-256", 1665 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1666 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA" 1667 }, 1668 { 1669 "kty": "EC", 1670 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1671 "use": "sig", 1672 "alg": "ES256", 1673 "crv": "P-256", 1674 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1675 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", 1676 "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" 1677 }, 1678 { 1679 "kty": "oct", 1680 "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", 1681 "use": "enc", 1682 "alg": "A128GCM", 1683 "k": "4uFxxV7fhNmrtiah2d1fFg" 1684 } 1685 ]} 1687 Note: They are the public signing key, the private signing key, and 1688 the shared secret enctyption key, respectively. The public and 1689 private signing keys have the same fingerprint and only vary by the 1690 'd' parameter that is missing from the public signing key. 1692 A.1. Simple Example 1694 This example is a simple common usage example containing a minimal 1695 subset of claims that the authors find most useful. 1697 The JWT Claim Set before signing: 1699 Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the 1700 URL Segment form ([RFC6920] Section 5) of "http://cdni.example/foo/ 1701 bar". 1703 { 1704 "exp": 1474243500, 1705 "iss": "uCDN Inc", 1706 "cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" 1707 } 1709 The signed JWT: 1711 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1712 dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE0NzQyNDM1MDAsImlzcyI6InVDRE4gS 1713 W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV 1714 wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.qzzAB9akC-HoEzQrkOoODWjMC0PEZRrmWz 1715 2rSMcpLtvxyxVodlB2xcpl4J4ABhLLOJzgzL9B39TljTqZApSOpQ 1717 A.2. Complex Example 1719 This example uses all fields except for those dealing with Signed 1720 Token Renewal, including Client IP (cdniip) and Subject (sub) which 1721 are encrpyted. This significantly increases the size of the signed 1722 JWT token. 1724 JWE for Client IP (cdniip) of [2001:db8::1/32]: 1726 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1727 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..SuzoOnfg-GVh-BOc.wQ9iS 1728 R1sTj-A04CiDmvcgg.9Ts_cIEUw6Yc6U5HaH1UPQ 1730 JWE for Subject (sub) of "UserToken": 1732 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1733 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..XsJ7ySeChORSIojp.R1U8E 1734 SGU2NnW.DWR8pTbeCwQZca6SitfX_g 1736 The JWT Claim Set before signing: 1738 { 1739 "aud": "dCDN LLC", 1740 "sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4 1741 QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..XsJ7ySeChORS 1742 Iojp.R1U8ESGU2NnW.DWR8pTbeCwQZca6SitfX_g", 1743 "cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY 1744 mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..SuzoOnfg- 1745 GVh-BOc.wQ9iSR1sTj-A04CiDmvcgg.9Ts_cIEUw6Yc6U5HaH1UPQ", 1746 "cdniv": 1, 1747 "exp": 1474243500, 1748 "iat": 1474243200, 1749 "iss": "uCDN Inc", 1750 "jti": "5DAafLhZAfhsbe", 1751 "nbf": 1474243200, 1752 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png" 1753 } 1755 The signed JWT: 1757 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1758 dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib 1759 U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA 1760 0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T 1761 0NKOS4uWHNKN3lTZUNoT1JTSW9qcC5SMVU4RVNHVTJOblcuRFdSOHBUYmVDd1FaY2E 1762 2U2l0ZlhfZyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja 1763 m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp 1764 2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uU3V6b09uZmctR1ZoLUJPYy53U 1765 TlpU1Ixc1RqLUEwNENpRG12Y2dnLjlUc19jSUVVdzZZYzZVNUhhSDFVUFEiLCJjZG5 1766 pdiI6MSwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6InVDR 1767 E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE0NzQyNDMyMDAsImN 1768 kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde 1769 zN9XFwucG5nIn0.XEi1NeP8Lzh6ECcbp6EoqYlnJGikaGp6F3lIJ7ZJt3bim6tOtuD 1770 pCQxmEQxobzIpWOCNdpB8kvxM_s95brKjNQ 1772 A.3. Signed Token Renewal Example 1774 This example uses fields for Signed Token Renewal. 1776 The JWT Claim Set before signing: 1778 { 1779 "cdniets": 30, 1780 "cdnistt": 1, 1781 "cdnistd": 2, 1782 "exp": 1474243500, 1783 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1784 } 1785 The signed JWT: 1787 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1788 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1789 XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTAwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1790 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.wsSvwxY8mtRax7HK_ 1791 dro_l6m-mM-HYdeaUoTSgVS5XTIhXBsCPsYQncsradmgmOWHDDOxsSMVVTjHe5E5YH 1792 ZlQ 1794 Once the server verifies the signed JWT it will return a new signed 1795 JWT with an updated expiry time (exp) as shown below. Note the 1796 expiry time is increased by the expiration time setting (cdniets) 1797 value. 1799 The JWT Claim Set before signing: 1801 { 1802 "cdniets": 30, 1803 "cdnistt": 1, 1804 "cdnistd": 2, 1805 "exp": 1474243530, 1806 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1807 } 1809 The signed JWT: 1811 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1812 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1813 XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTMwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1814 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.SITeoIVZ8-yeE_GBV 1815 jYEo1P2LN-EId1gEJ6baR3Au7Dzh2o_O7LhH3k6wHY081sYMdXHucB0P5ocp-r7gqe 1816 ruQ 1818 Authors' Addresses 1820 Ray van Brandenburg 1821 Tiledmedia 1822 Anna van Buerenplein 1 1823 Den Haag 2595DA 1824 The Netherlands 1826 Phone: +31 88 866 7000 1827 Email: ray@tiledmedia.com 1828 Kent Leung 1829 Cisco Systems, Inc. 1830 3625 Cisco Way 1831 San Jose, CA 95134 1832 United States 1834 Phone: +1 408 526 5030 1835 Email: kleung@cisco.com 1837 Phil Sorber 1838 Apple, Inc. 1839 1800 Wazee Street 1840 Suite 410 1841 Denver, CO 80202 1842 United States 1844 Email: sorber@apple.com