idnits 2.17.1 draft-ietf-cdni-uri-signing-16.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7519]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 294 has weird spacing: '...I(after v ...' -- The document date (October 23, 2018) is 2013 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 4 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: April 26, 2019 Cisco Systems, Inc. 6 P. Sorber 7 Apple, Inc. 8 October 23, 2018 10 URI Signing for CDN Interconnection (CDNI) 11 draft-ietf-cdni-uri-signing-16 13 Abstract 15 This document describes how the concept of URI signing supports the 16 content access control requirements of CDNI and proposes a URI 17 signing method as a JSON Web Token (JWT) [RFC7519] profile. 19 The proposed URI signing method specifies the information needed to 20 be included in the URI to transmit the signed JWT as well as the 21 claims needed by the signed JWT to authorize a UA. The mechanism 22 described can be used both in CDNI and single CDN scenarios. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 26, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Background and overview on URI Signing . . . . . . . . . 5 61 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 62 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 63 2. JWT Format and Processing Requirements . . . . . . . . . . . 9 64 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9 65 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10 66 2.1.2. Subject (sub) claim . . . . . . . . . . . . . . . . . 10 67 2.1.3. Audience (aud) claim . . . . . . . . . . . . . . . . 11 68 2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 11 69 2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11 70 2.1.6. Issued At (iat) claim . . . . . . . . . . . . . . . . 12 71 2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 12 72 2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12 73 2.1.9. CDNI Critical Claims Set (cdnicrit) claim . . . . . . 12 74 2.1.10. Client IP (cdniip) claim . . . . . . . . . . . . . . 13 75 2.1.11. CDNI URI Container (cdniuc) claim . . . . . . . . . . 13 76 2.1.12. CDNI Expiration Time Setting (cdniets) claim . . . . 13 77 2.1.13. CDNI Signed Token Transport (cdnistt) claim . . . . . 14 78 2.1.14. CDNI Signed Token Depth (cdnistd) claim . . . . . . . 14 79 2.1.15. URI Container Forms . . . . . . . . . . . . . . . . . 15 80 2.1.15.1. URI Hash Container (hash:) . . . . . . . . . . . 15 81 2.1.15.2. URI Regular Expression Container (regex:) . . . 15 82 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 16 83 3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 16 84 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 85 3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 17 86 3.2.1. Required Claims . . . . . . . . . . . . . . . . . . . 17 87 3.3. Communicating a signed JWTs in Signed Token Renewal . . . 17 88 3.3.1. Support for cross-domain redirection . . . . . . . . 18 89 4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 18 90 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 18 91 4.2. CDNI Footprint & Capabilities Advertisement Interface . . 19 92 4.3. CDNI Request Routing Redirection Interface . . . . . . . 19 93 4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 19 94 4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 20 95 5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 22 96 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 22 97 5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 24 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 99 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 27 100 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 28 101 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 28 102 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 28 103 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 28 104 6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 29 105 6.5. JSON Web Token Claims Registration . . . . . . . . . . . 29 106 6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 29 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 108 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 109 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 110 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 111 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 112 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 113 11.2. Informative References . . . . . . . . . . . . . . . . . 33 114 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 35 115 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 36 116 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 37 117 A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 38 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 120 1. Introduction 122 This document describes the concept of URI Signing and how it can be 123 used to provide access authorization in the case of redirection 124 between interconnected CDNs (CDNI) and between a Content Service 125 Provider (CSP) and a CDN. The primary goal of URI Signing is to make 126 sure that only authorized User Agents (UAs) are able to access the 127 content, with a CSP being able to authorize every individual request. 128 It should be noted that URI Signing is not a content protection 129 scheme; if a CSP wants to protect the content itself, other 130 mechanisms, such as Digital Rights Management (DRM), are more 131 appropriate. In addition to access control, URI Signing also has 132 benefits in reducing the impact of denial-of-service attacks. 134 The overall problem space for CDN Interconnection (CDNI) is described 135 in CDNI Problem Statement [RFC6707]. This document, along with the 136 CDNI Requirements [RFC7337] document and the CDNI Framework 137 [RFC7336], describes the need for interconnected CDNs to be able to 138 implement an access control mechanism that enforces the CSP's 139 distribution policy. 141 Specifically, CDNI Framework [RFC7336] states: 143 The CSP may also trust the CDN operator to perform actions such as 144 ..., and to enforce per-request authorization performed by the CSP 145 using techniques such as URI signing. 147 In particular, the following requirement is listed in CDNI 148 Requirements [RFC7337]: 150 MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of 151 authorization checks and validation that are to be performed by 152 the Surrogate before delivery. For example, this could 153 potentially include the need to validate information (e.g., Expiry 154 time, Client IP address) required for access authorization. 156 This document proposes a method of signing URIs that allows 157 Surrogates in interconnected CDNs to enforce a per-request 158 authorization performed by the CSP. Splitting the role of performing 159 per-request authorization by the CSP and the role of validating this 160 authorization by the CDN allows any arbitrary distribution policy to 161 be enforced across CDNs without the need of CDNs to have any 162 awareness of the actual CSP distribution policy. 164 The representation of this method is a Signed JSON Web Token (JWT) 165 [RFC7519]. 167 1.1. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in BCP 172 14 [RFC2119] [RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 This document uses the terminology defined in CDNI Problem Statement 176 [RFC6707]. 178 This document also uses the terminology of JSON Web Token (JWT) 179 [RFC7519]. 181 In addition, the following terms are used throughout this document: 183 o Signed URI: A URI for which a signed JWT is provided. 185 o Target CDN URI: URI created by the CSP to direct a UA towards the 186 Upstream CDN (uCDN). The Target CDN URI can be signed by the CSP 187 and verified by the uCDN and possibly further Downstream CDNs 188 (dCDNs). 190 o Redirection URI: URI created by the uCDN to redirect a UA towards 191 the dCDN. The Redirection URI can be signed by the uCDN and 192 verified by the dCDN. In a cascaded CDNI scenario, there can be 193 more than one Redirection URI. 195 o Signed Token Renewal: A series of signed JWTs that are used for 196 subsequent access to a set of related resources in a CDN, such as 197 a set of HTTP Adaptive Streaming files. Every time a signed JWT 198 is used to access a particular resource, a new signed JWT is sent 199 along with the resource that can be used to request the next 200 resource in the set. When generating a new signed JWT in Signed 201 Token Renewal, parameters are carried over from one signed JWT to 202 the next. 204 1.2. Background and overview on URI Signing 206 A CSP and CDN are assumed to have a trust relationship that enables 207 the CSP to authorize access to a content item by including a set of 208 claims in the form of a signed JWT in the URI before redirecting a UA 209 to the CDN. Using these attributes, it is possible for a CDN to 210 check an incoming content request to see whether it was authorized by 211 the CSP (e.g., based on the UA's IP address or a time window). To 212 prevent the UA from altering the claims a signed JWT is REQUIRED. 214 Figure 1, shown below, presents an overview of the URI Signing 215 mechanism in the case of a CSP with a single CDN. When the UA 216 browses for content on CSP's website (#1), it receives HTML web pages 217 with embedded content URIs. Upon requesting these URIs, the CSP 218 redirects to a CDN, creating a Target CDN URI (#2) (alternatively, 219 the Target CDN URI itself is embedded in the HTML). The Target CDN 220 URI is the Signed URI which may include the IP address of the UA and/ 221 or a time window and always contains the signed JWT which is 222 generated by the CSP using a shared secret or private key. Once the 223 UA receives the response with the Signed URI, it sends a new HTTP 224 request using the Signed URI to the CDN (#3). Upon receiving the 225 request, the CDN checks to see if the Signed URI is authentic by 226 verifying the signed JWT. If applicable, it checks whether the IP 227 address of the HTTP request matches that in the Signed URI and if the 228 time window is still valid. After these claims are confirmed to be 229 valid, the CDN delivers the content (#4). 231 -------- 232 / \ 233 | CSP |< * * * * * * * * * * * 234 \ / Trust * 235 -------- relationship * 236 ^ | * 237 | | * 238 1. Browse | | 2. Signed * 239 for | | URI * 240 content | | * 241 | v v 242 +------+ 3. Signed URI -------- 243 | User |----------------->/ \ 244 | Agent| | CDN | 245 | |<-----------------\ / 246 +------+ 4. Content -------- 247 Delivery 249 Figure 1: Figure 1: URI Signing in a CDN Environment 251 1.3. CDNI URI Signing Overview 253 In a CDNI environment, URI Signing operates the same way in the 254 initial steps #1 and #2 but the later steps involve multiple CDNs in 255 the process of delivering the content. The main difference from the 256 single CDN case is a redirection step between the uCDN and the dCDN. 257 In step #3, UA may send an HTTP request or a DNS request. Depending 258 on whether HTTP-based or DNS-based request routing is used, the uCDN 259 responds by directing the UA towards the dCDN using either a 260 Redirection URI (which is a Signed URI generated by the uCDN) or a 261 DNS reply, respectively (#4). Once the UA receives the response, it 262 sends the Redirection URI/Target CDN URI to the dCDN (#5). The 263 received URI is validated by the dCDN before delivering the content 264 (#6). This is depicted in the figure below. Note: The CDNI call 265 flows are covered in Detailed URI Signing Operation (Section 5). 267 +-------------------------+ 268 |Request Redirection Modes| 269 +-------------------------+ 270 | a) HTTP | 271 | b) DNS | 272 +-------------------------+ 273 -------- 274 / \< * * * * * * * * * * * * * * 275 | CSP |< * * * * * * * * * * * * 276 \ / Trust * * 277 -------- relationship * * 278 ^ | * * 279 | | 2. Signed * * 280 1. Browse | | URI in * * 281 for | | HTML * * 282 content | | * * 283 | v 3.a)Signed URI v * 284 +------+ b)DNS request -------- * Trust 285 | User |----------------->/ \ * relationship 286 | Agent| | uCDN | * (optional) 287 | |<-----------------\ / * 288 +------+ 4.a)Redirection URI------- * 289 ^ | b)DNS Reply ^ * 290 | | * * 291 | | Trust relationship * * 292 | | * * 293 6. Content | | 5.a)Redirection URI * * 294 delivery | | b)Signed URI(after v v 295 | | DNS exchange) -------- 296 | +---------------------->/ \ [May be 297 | | dCDN | cascaded 298 +--------------------------\ / CDNs] 299 -------- 301 +-----------------------------------------+ 302 | Key | Asymmetric | Symmetric | 303 +-----------------------------------------+ 304 |HTTP |Public key (uCDN)|Shared key (uCDN)| 305 |DNS |Public key (CSP) |Shared key (CSP) | 306 +-----------------------------------------+ 308 Figure 2: URI Signing in a CDNI Environment 310 The trust relationships between CSP, uCDN, and dCDN have direct 311 implications for URI Signing. In the case shown in Figure 2, the CDN 312 that the CSP has a trust relationship with is the uCDN. The delivery 313 of the content may be delegated to the dCDN, which has a relationship 314 with the uCDN but may have no relationship with the CSP. 316 In CDNI, there are two methods for request routing: DNS-based and 317 HTTP-based. For DNS-based request routing, the Signed URI (i.e., 318 Target CDN URI) provided by the CSP reaches the dCDN directly. In 319 the case where the dCDN does not have a trust relationship with the 320 CSP, this means that either an asymmetric public/private key method 321 needs to be used for computing the signed JWT (because the CSP and 322 dCDN are not able to exchange symmetric shared secret keys), or the 323 CSP needs to allow the uCDN to redistribute shared keys to a subset 324 of their dCDNs. 326 For HTTP-based request routing, the Signed URI (i.e., Target CDN URI) 327 provided by the CSP reaches the uCDN. After this URI has been 328 verified to be correct by the uCDN, the uCDN creates and signs a new 329 Redirection URI to redirect the UA to the dCDN. Since this new URI 330 could have a new signed JWT, a new signature can be based around the 331 trust relationship between the uCDN and dCDN, and the relationship 332 between the dCDN and CSP is not relevant. Given the fact that such a 333 relationship between uCDN and dCDN always exists, both asymmetric 334 public/private keys and symmetric shared secret keys can be used for 335 URI Signing with HTTP-based request routing. Note that the signed 336 Redirection URI MUST maintain the same, or higher, level of security 337 as the original Signed URI. 339 Two types of keys can be used for URI Signing: asymmetric keys and 340 symmetric keys. Asymmetric keys are based on a public/private key 341 pair mechanism and always contain a private key only known to the 342 entity signing the URI (either CSP or uCDN) and a public key for the 343 verification of the Signed URI. With symmetric keys, the same key is 344 used by both the signing entity for signing the URI as well as by the 345 validating entity for validating the Signed URI. Regardless of the 346 type of keys used, the validating entity has to obtain the key 347 (either the public or the symmetric key). There are very different 348 requirements for key distribution (out of scope of this document) 349 with asymmetric keys and with symmetric keys. Key distribution for 350 symmetric keys requires confidentiality to prevent another party from 351 getting access to the key, since it could then generate valid Signed 352 URIs for unauthorized requests. Key distribution for asymmetric keys 353 does not require confidentiality since public keys can typically be 354 distributed openly (because they cannot be used for URI signing) and 355 private keys are kept by the URI signing function. 357 1.4. URI Signing in a non-CDNI context 359 While the URI signing method defined in this document was primarily 360 created for the purpose of allowing URI Signing in CDNI scenarios, 361 e.g., between a uCDN and a dCDN or between a CSP and a dCDN, there is 362 nothing in the defined URI Signing method that precludes it from 363 being used in a non-CDNI context. As such, the described mechanism 364 could be used in a single-CDN scenario such as shown in Figure 1 in 365 Section 1.2, for example to allow a CSP that uses different CDNs to 366 only have to implement a single URI Signing mechanism. 368 2. JWT Format and Processing Requirements 370 The concept behind URI Signing is based on embedding a signed JSON 371 Web Token (JWT) [RFC7519] in an http or https URI [RFC7230] (section 372 2.7). The signed JWT contains a number of claims that can be 373 validated to ensure the UA has legitimate access to the content. 375 This document specifies the following attribute for embedding a 376 signed JWT in a Target CDN URI or Redirection URI: 378 o URI Signing Package (URISigningPackage): The URI attribute that 379 encapsulates all the URI Signing claims in a signed JWT encoded 380 format. This attribute is exposed in the Signed URI as a URI 381 query parameter or as a URL path parameter. 383 The parameter name of the URI Signing Package Attribute is defined in 384 the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is 385 not used, or does not include a parameter name for the URI Signing 386 Package Attribute, the parameter name can be set by configuration 387 (out of scope of this document). 389 The URI Signing Package will be found by searching the URI, left-to- 390 right, for the following sequence: 392 o a reserved character (as defined in [RFC3986] Section 2.2), 394 o the URI Signing Package Attribute name, 396 o if the last character of the URI Signing Package Attribute name is 397 not a reserved character, an equal symbol ('='), 399 o and a sequence of non-reserved characters that will be interpreted 400 as a signed JWT, 402 o terminated by either a reserved character or the end of the URI. 404 The first such match will be taken to provide the signed JWT; the URI 405 will not be searched for multiple signed JWTs. 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.) A CDN MUST be able to parse 427 and process all of the claims listed below. 429 Note: See the Security Considerations (Section 7) section on the 430 limitations of using an expiration time and client IP address for 431 distribution policy enforcement. 433 2.1.1. Issuer (iss) claim 435 Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1 436 MUST be followed. This claim MAY be used to validate authorization 437 of the issuer of a signed JWT and also MAY be used to confirm that 438 the indicated key was provided by said issuer. If the CDN validating 439 the signed JWT does not support Issuer validation, or if the Issuer 440 in the signed JWT does not match the list of known acceptable 441 Issuers, the CDN MUST reject the request. If the received signed JWT 442 contains an Issuer claim, then any JWT subsequently generated for 443 CDNI redirection MUST also contain an Issuer claim, and the Issuer 444 value MUST be updated to identify the redirecting CDN. If the 445 received signed JWT does not contain an Issuer claim, an Issuer claim 446 MAY be added to a signed JWT generated for CDNI redirection. 448 2.1.2. Subject (sub) claim 450 Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2 451 MUST be followed. If this claim is used, it MUST be a JSON Web 452 Encryption (JWE [RFC7516]) Object in compact serialization form, 453 because it contains personally identifiable information. This claim 454 contains information about the subject (for example, a user or an 455 agent) that MAY be used to validate the signed JWT. If the received 456 signed JWT contains a Subject claim, then any JWT subsequently 457 generated for CDNI redirection MUST also contain a Subject claim, and 458 the Subject value MUST be the same as in the received signed JWT. A 459 signed JWT generated for CDNI redirection MUST NOT add a Subject 460 claim if no Subject claim existed in the received signed JWT. 462 2.1.3. Audience (aud) claim 464 Audience (aud) [optional] - The semantics in [RFC7519] Section 4.1.3 465 MUST be followed. This claim is used to ensure that the CDN that 466 validates the JWT identifies itself with the value in this claim. 468 2.1.4. Expiry Time (exp) claim 470 Expiry Time (exp) [optional] - The semantics in [RFC7519] 471 Section 4.1.4 MUST be followed, though URI Signing implementations 472 MUST NOT allow for any time synchronization "leeway". Note: The time 473 on the entities that generate and validate the signed URI SHOULD be 474 in sync. In the CDNI case, this means that CSP, uCDN, and dCDN 475 servers need to be time-synchronized. It is RECOMMENDED to use NTP 476 [RFC5905] for time synchronization. If the CDN validating the signed 477 JWT does not support Expiry Time validation, or if the Expiry Time in 478 the signed JWT corresponds to a time earlier than the time of the 479 content request, the CDN MUST reject the request. If the received 480 signed JWT contains a Expiry Time claim, then any JWT subsequently 481 generated for CDNI redirection MUST also contain an Expiry Time 482 claim, and the Expiry Time value MUST be the same as in the received 483 signed JWT. A signed JWT generated for CDNI redirection MUST NOT add 484 an Expiry Time claim if no Expiry Time claim existed in the received 485 signed JWT. 487 2.1.5. Not Before (nbf) claim 489 Not Before (nbf) [optional] - The semantics in [RFC7519] 490 Section 4.1.5 MUST be followed, though URI Signing implementations 491 MUST NOT allow for any time synchronization "leeway". Note: The time 492 on the entities that generate and validate the signed URI SHOULD be 493 in sync. In the CDNI case, this means that the CSP, uCDN, and dCDN 494 servers need to be time-synchronized. It is RECOMMENDED to use NTP 495 [RFC5905] for time synchronization. If the CDN validating the signed 496 JWT does not support Not Before time validation, or if the Not Before 497 time in the signed JWT corresponds to a time later than the time of 498 the content request, the CDN MUST reject the request. If the 499 received signed JWT contains a Not Before time claim, then any JWT 500 subsequently generated for CDNI redirection MUST also contain a Not 501 Before time claim, and the Not Before time value MUST be the same as 502 in the received signed JWT. A signed JWT generated for CDNI 503 redirection MUST NOT add a Not Before time claim if no Not Before 504 time claim existed in the received signed JWT. 506 2.1.6. Issued At (iat) claim 508 Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6 509 MUST be followed. Note: The time on the entities that generate and 510 validate the signed URI SHOULD be in sync. In the CDNI case, this 511 means that CSP, uCDN, and dCDN servers need to be time-synchronized. 512 It is RECOMMENDED to use NTP [RFC5905] for time synchronization. If 513 the received signed JWT contains an Issued At claim, then any JWT 514 subsequently generated for CDNI redirection MUST also contain an 515 Issued At claim, and the Issuer value MUST be updated to identify the 516 time the new JWT was generated. If the received signed JWT does not 517 contain an Issued At claim, an Issued At claim MAY be added to a 518 signed JWT generated for CDNI redirection. 520 2.1.7. Nonce (jti) claim 522 Nonce (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 523 MUST be followed. A Nonce can be used to prevent replay attacks if 524 the CDN stores a list of all previously used Nonce values, and 525 validates that the Nonce in the current JWT has never been used 526 before. If the signed JWT contains a Nonce claim and the CDN 527 validating the signed JWT does not support Nonce storage, then the 528 CDN MUST reject the request. If the received signed JWT contains a 529 Nonce claim, then any JWT subsequently generated for CDNI redirection 530 MUST also contain a Nonce claim, and the Nonce value MUST be the same 531 as in the received signed JWT. If the received signed JWT does not 532 contain a Nonce claim, a Nonce claim MUST NOT be added to a signed 533 JWT generated for CDNI redirection. 535 2.1.8. CDNI Claim Set Version (cdniv) claim 537 CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set 538 Version (cdniv) claim provides a means within a signed JWT to tie the 539 claim set to a specific version of a specificiation. This is 540 intended to allow changes in and facilitate upgrades across 541 specifications. The type is JSON integer and the value MUST be set 542 to "1", for this version of the specification. In the absence of 543 this claim, the value is assumed to be "1". For future versions this 544 claim will be mandatory. Implementations MUST reject signed JWTs 545 with unsupported CDNI Claim Set versions. 547 2.1.9. CDNI Critical Claims Set (cdnicrit) claim 549 CDNI Critical Claims Set (cdnicrit) [optional] - The cdnicrit claim 550 indicates that extensions to this specification are being used that 551 MUST be understood and processed. Its value is a comma separated 552 listing of claims in the Signed JWT that use those extensions. If 553 any of the listed extension claims are not understood and supported 554 by the recipient, then the Signed JWT is invalid. Producers MUST NOT 555 include claim names defined by this specification, duplicate names, 556 or names that do not occur as claim names within the Signed JWT in 557 the cdnicrit list. Producers MUST NOT use the empty list "" as the 558 cdnicrit value. Recipients MAY consider the Signed JWT to be invalid 559 if the cdnicrit list contains any claim names defined by this 560 specification or if any other constraints on its use are violated. 561 This claim MUST be understood and processed by implementations. 563 2.1.10. Client IP (cdniip) claim 565 Client IP (cdniip) [optional] IP address, or IP prefix, for which the 566 Signed URI is valid. This is represented in CIDR notation, with 567 dotted decimal format for IPv4 or canonical text representation for 568 IPv6 addresses [RFC5952]. The request is rejected if sourced from a 569 client outside of the specified IP range. Since the client IP is 570 considered personally identifiable information this field MUST be a 571 JSON Web Encryption (JWE [RFC7516]) Object in compact serialization 572 form. If the CDN validating the signed JWT does not support Client 573 IP validation, or if the Client IP in the signed JWT does not match 574 the source IP address in the content request, the CDN MUST reject the 575 request. The type of this claim is a JSON string that contains the 576 JWE. If the received signed JWT contains a Client IP claim, then any 577 JWT subsequently generated for CDNI redirection MUST also contain a 578 Client IP claim, and the Client IP value MUST be the same as in the 579 received signed JWT. A signed JWT generated for CDNI redirection 580 MUST NOT add a Client IP claim if no Client IP claim existed in the 581 received signed JWT. 583 2.1.11. CDNI URI Container (cdniuc) claim 585 URI Container (cdniuc) [optional] - Container for holding the URI 586 representation before a URI Signing Package is added. This 587 representation can take one of several forms detailed in 588 Section 2.1.15. If the URI regex in the signed JWT does not match 589 the URI of the content request, the CDN validating the signed JWT 590 MUST reject the request. When comparing the URI, the percent encoded 591 form as defined in [RFC3986] Section 2.1 MUST be used. When 592 redirecting a URI, the CDN generating the new signed JWT MAY change 593 the URI Container to comport with the URI being used in the 594 redirection. 596 2.1.12. CDNI Expiration Time Setting (cdniets) claim 598 CDNI Expiration Time Setting (cdniets) [optional] - The CDNI 599 Expiration Time Setting (cdniets) claim provides a means for setting 600 the value of the Expiry Time (exp) claim when generating a subsequent 601 signed JWT in Signed Token Renewal. Its type is a JSON numeric 602 value. It denotes the number of seconds to be added to the time at 603 which the JWT is validated that gives the value of the Expiry Time 604 (exp) claim of the next signed JWT. The CDNI Expiration Time Setting 605 (cdniets) SHOULD NOT be used when not using Signed Token Renewal and 606 MUST be present when using Signed Token Renewal. 608 2.1.13. CDNI Signed Token Transport (cdnistt) claim 610 CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed 611 Token Transport (cdnistt) claim provides a means of signalling the 612 method through which a new signed JWT is transported from the CDN to 613 the UA and vice versa for the purpose of Signed Token Renewal. Its 614 type is a JSON integer. Values for this claim can be defined in 615 Section 6.4. If using this claim you MUST also specify a CDNI 616 Expiration Time Setting (cdniets) as noted above. 618 2.1.14. CDNI Signed Token Depth (cdnistd) claim 620 CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token 621 Depth (cdnistd) claim is used to associate a subsequent signed JWT 622 generated as the result of a CDNI Signed Token Transport claim with a 623 specific URI subset. Its type is a JSON integer. Signed JWTs MUST 624 NOT use a negative value for the CDNI Signed Token Depth claim. 626 If the transport used for Signed Token Transport allows the CDN to 627 associate the path component of a URI with tokens (e.g., an HTTP 628 Cookie Path as described in section 4.1.2.4 of [RFC6265]), the CDNI 629 Signed Token Depth value is the number of path segments that should 630 be considered significant for this association. A CDNI Signed Token 631 Depth of zero means that the client SHOULD be directed to return the 632 token with requests for any path. If the CDNI Signed Token Depth is 633 greater than zero, then the client SHOULD be directed to return the 634 token for future requests wherein the first CDNI Signed Token Depth 635 segments of the path match the first CDNI Signed Token Depth segments 636 of the signed URI path. This matching MUST use the URI with the 637 token removed, as specified in Section 2.1.15. 639 If the URI path to match contains fewer segments than the CDNI Signed 640 Token Depth claim, a signed JWT MUST NOT be generated for the 641 purposes of Signed Token Renewal. If the CDNI Signed Token Depth 642 claim is omitted, it means the same thing as if its value were zero. 643 If the received signed JWT contains a CDNI Signed Token Depth claim, 644 then any JWT subsequently generated for CDNI redirection or Signed 645 Token Transport MUST also contain a CDNI Signed Token Depth claim, 646 and the value MUST be the same as in the received signed JWT. 648 2.1.15. URI Container Forms 650 The URI Container (cdniuc) claim takes one of the following forms. 651 More forms may be added in the future to extend the capabilities. 653 Before utilizing a URI with this container, the following steps MUST 654 be performed: 656 o Prior to validation, remove the signed JWT from the URI. This 657 removal is only for the purpose of determining if the URI matches; 658 all other purposes will use the original URI. If the signed JWT 659 is terminated by anything other than a sub-delimiter (as definined 660 in [RFC3986] Section 2.2), everything from the reserved character 661 (as defined in [RFC3986] Section 2.2) that precedes the URI 662 Signing Package Attribute to the last character of the signed JWT 663 will be removed, inclusive. Otherwise, everything from the first 664 character of the URI Signing Package Attribute to the sub- 665 delimiter that terminates the signed JWT will be removed, 666 inclusive. 668 o Normalize the URI according to section 2.7.3 [RFC7230] and 669 [RFC3986] sections 6.2.2 and 6.2.3. This applies to both 670 generation and validation of the signed JWT. 672 2.1.15.1. URI Hash Container (hash:) 674 Prefixed with 'hash:', this string is a URL Segment form ([RFC6920] 675 Section 5) of the URI. 677 2.1.15.2. URI Regular Expression Container (regex:) 679 Prefixed with 'regex:', this string is any POSIX [POSIX.1] Section 9 680 Extended Regular Expression compatible regular expression used to 681 match against the requested URI. These regular expressions MUST be 682 evaluated in the POSIX locale (POSIX [POSIX.1] Section 7.2). 684 Note: Because '\' has special meaning in JSON [RFC7159] as the escape 685 character within JSON strings, the regular expression character '\' 686 MUST be escaped as '\\'. 688 An example of a 'regex:' is the following: 690 [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)? 692 Note: Due to computational complexity of executing arbitrary regular 693 expressions, it is RECOMMENDED to only execute after validating the 694 JWT to ensure its authenticity. 696 2.2. JWT Header 698 The header of the JWT MAY be passed via the CDNI Metadata interface 699 instead of being included in the URISigningPackage. The header value 700 must be transmitted in the serialized encoded form and prepended to 701 the JWT payload and signature passed in the URISigningPackage prior 702 to validation. This reduces the size of the signed JWT token. 704 3. URI Signing Token Renewal 706 3.1. Overview 708 For content that is delivered via HTTP in a segmented fashion, such 709 as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216], 710 special provisions need to be made in order to ensure URI Signing can 711 be applied. In general, segmented protocols work by breaking large 712 objects (e.g. videos) into a sequence of small independent segments. 713 Such segments are then referenced by a separate manifest file, which 714 either includes a list of URLs to the segments or specifies an 715 algorithm through which a User Agent can construct the URLs to the 716 segments. Requests for segments therefore originate from the 717 manifest file and, unless the URLs in the manifest file point to the 718 CSP, are not subjected to redirection and URI Signing. This opens up 719 the vulnerability of malicious User Agents sharing the manifest file 720 and deep-linking to the segments. 722 One method for dealing with this vulnerability would be to include, 723 in the manifest itself, Signed URIs that point to the individual 724 segments. There exist a number of issues with that approach. First, 725 it requires the CDN delivering the manifest to rewrite the manifest 726 file for each User Agent, which would require the CDN to be aware of 727 the exact segmentation protocol used. Secondly, it could also 728 require the expiration time of the Signed URIs to be valid for an 729 extended duration if the content described by the manifest is meant 730 to be consumed in real time. For instance, if the manifest file were 731 to contain a segmented video stream of more than 30 minutes in 732 length, Signed URIs would require to be valid for a at least 30 733 minutes, thereby reducing their effectiveness and that of the URI 734 Signing mechanism in general. For a more detailed analysis of how 735 segmented protocols such as HTTP Adaptive Streaming protocols affect 736 CDNI, see Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. 738 The method described in this section allows CDNs to use URI Signing 739 for segmented content without having to include the Signed URIs in 740 the manifest files themselves. 742 3.2. Signed Token Renewal mechanism 744 In order to allow for effective access control of segmented content, 745 the URI signing mechanism defined in this section is based on a 746 method through which subsequent segment requests can be linked 747 together. As part of the JWT validation procedure, the CDN can 748 generate a new signed JWT that the UA can use to do a subsequent 749 request. More specifically, whenever a UA successfully retrieves a 750 segment, it receives, in the HTTP 2xx Successful message, a signed 751 JWT that it can use whenever it requests the next segment. As long 752 as each successive signed JWT is correctly validated before a new one 753 is generated, the model is not broken and the User Agent can 754 successfully retrieve additional segments. Given the fact that with 755 segmented protocols, it is usually not possible to determine a priori 756 which segment will be requested next (i.e., to allow for seeking 757 within the content and for switching to a different representation), 758 the Signed Token Renewal uses the URI Regular Expression Container 759 scoping mechanisms in the URI Container (cdniuc) claim to allow a 760 signed JWT to be valid for more than one URL. 762 In order for this renewal of signed JWTs to work, it is necessary for 763 a UA to extract the signed JWT from the HTTP 2xx Successful message 764 of an earlier request and use it to retrieve the next segment. The 765 exact mechanism by which the client does this depends on the exact 766 segmented protocol and since this document is only concerned with the 767 generation and validation of incoming request, this process is 768 outside the scope of this document. However, in order to also 769 support legacy UAs that do not include any specific provisions for 770 the handling of signed JWTs, the folowing section defines a mechanism 771 using HTTP Cookies [RFC6265] that allows such UAs to support the 772 concept of renewing signed JWTs without requiring any support on the 773 UA side. 775 3.2.1. Required Claims 777 The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12) 778 MUST both be present to utilize Signed token Renewal. Either one 779 MUST NOT appear alone. You MAY set cdnistt to a value of '0' to mean 780 no Signed Token Renewal, but you still MUST have a corresponding 781 cdniets that validates as a JSON number. However, if you do not want 782 to use Signed Token Renewal, it is RECOMMENDED to simply omit both. 784 3.3. Communicating a signed JWTs in Signed Token Renewal 786 This section assumes the value of the CDNI Signed Token Transport 787 (cdnistt) claim has been set to 1. Other values of cdnistt are out 788 of scope of this document. 790 When using the Signed Token Renewal mechanism, the signed JWT is 791 transported to the UA via a 'URISigningPackage' cookie added to the 792 HTTP 2xx Successful message along with the content being returned to 793 the UA, or to the HTTP 3xx Redirection message in case the UA is 794 redirected to a different server. 796 3.3.1. Support for cross-domain redirection 798 For security purposes, the use of cross-domain cookies is not 799 supported in some application environments. As a result, the Cookie- 800 based method for transport of the Signed Token described in the 801 previous section might break if used in combination with a HTTP 3xx 802 Redirection response where the target URL is in a different domain. 803 In such scenarios, Signed Token Renewal of a signed JWT SHOULD be 804 communicated via the query string instead, in a similar fashion to 805 how regular signed JWTs (outside of Signed Token Renewal) are 806 communicated. Note that the use of URL embedded signed JWTs SHOULD 807 NOT be used in HTTP 2xx Successful messages, since UAs might not know 808 how to extract the signed JWTs. 810 Note that the process described below only works in cases where both 811 the manifest file and segments constituting the segmented content are 812 delivered from the same domain. In other words, any redirection 813 between different domains needs to be carried out while retrieving 814 the manifest file. 816 4. Relationship with CDNI Interfaces 818 Some of the CDNI Interfaces need enhancements to support URI Signing. 819 As an example: A dCDN that supports URI Signing needs to be able to 820 advertise this capability to the uCDN. The uCDN needs to select a 821 dCDN based on such capability when the CSP requires access control to 822 enforce its distribution policy via URI Signing. Also, the uCDN 823 needs to be able to distribute via the CDNI Metadata interface the 824 information necessary to allow the dCDN to validate a Signed URI. 825 Events that pertain to URI Signing (e.g., request denial or delivery 826 after access authorization) need to be included in the logs 827 communicated through the CDNI Logging interface (Editor's Note: Is 828 this within the scope of the CDNI Logging interface?). 830 4.1. CDNI Control Interface 832 URI Signing has no impact on this interface. 834 4.2. CDNI Footprint & Capabilities Advertisement Interface 836 The CDNI Request Routing: Footprint and Capabilities Semantics 837 document [RFC8008] defines support for advertising CDNI Metadata 838 capabilities, via CDNI Payload Type. The CDNI Payload Type 839 registered in Section 6.1 can be used for capability advertisement. 841 4.3. CDNI Request Routing Redirection Interface 843 The CDNI Request Routing Redirection Interface [RFC7975] describes 844 the recursive request redirection method. For URI Signing, the uCDN 845 signs the URI provided by the dCDN. URI Signing therefore has has no 846 impact on this interface. 848 4.4. CDNI Metadata Interface 850 The CDNI Metadata Interface [RFC8006] describes the CDNI metadata 851 distribution needed to enable content acquisition and delivery. For 852 URI Signing, a new CDNI metadata object is specified. 854 The UriSigning Metadata object contains information to enable URI 855 signing and validation by a dCDN. The UriSigning properties are 856 defined below. 858 Property: enforce 860 Description: URI Signing enforcement flag. Specifically, this 861 flag indicates if the access to content is subject to URI 862 Signing. URI Signing requires the dCDN to ensure that the URI 863 must be signed and validated before delivering content. 864 Otherwise, the dCDN does not perform validation, regardless of 865 whether or not the URI is signed. 867 Type: Boolean 869 Mandatory-to-Specify: No. The default is true. 871 Property: issuers 873 Description: A list of valid Issuers against which the Issuer 874 claim in the signed JWT may be validated. 876 Type: Array of Strings 878 Mandatory-to-Specify: No. The default is an empty list. An 879 empty list means that any Issuer is acceptable. 881 Property: package-attribute 882 Description: The name to use for the URI Signing Package. 884 Type: String 886 Mandatory-to-Specify: No. Default is "URISigningPackage". 888 Property: jwt-header 890 Description: The header part of JWT that is used for generating 891 or validating a signed JWT when the JWT token in the URI 892 Signing Package does not contain a header part. 894 Type: String 896 Mandatory-to-Specify: No. A jwt-header is not essential for 897 all implementations of URI signing. 899 The following is an example of a URI Signing metadata payload with 900 all default values: 902 { 903 "generic-metadata-type": "MI.UriSigning" 904 "generic-metadata-value": {} 905 } 907 The following is an example of a URI Signing metadata payload with 908 explicit values: 910 { 911 "generic-metadata-type": "MI.UriSigning" 912 "generic-metadata-value": 913 { 914 "enforce": true, 915 "issuers": ["csp", "ucdn1", "ucdn2"], 916 "package-attribute": "usp" 917 } 918 } 920 4.5. CDNI Logging Interface 922 For URI Signing, the dCDN reports that enforcement of the access 923 control was applied to the request for content delivery. When the 924 request is denied due to enforcement of URI Signing, the reason is 925 logged. 927 The following CDNI Logging field for URI Signing SHOULD be supported 928 in the HTTP Request Logging Record as specified in CDNI Logging 929 Interface [RFC7937], using the new "cdni_http_request_v2" record-type 930 registered in Section 6.2.1. 932 o s-uri-signing (mandatory): 934 * format: 3DIGIT 936 * field value: this characterises the URI signing validation 937 performed by the Surrogate on the request. The allowed values 938 are: 940 + "000" : no signed JWT validation performed 942 + "200" : signed JWT validation performed and validated 944 + "400" : signed JWT validation performed and rejected because 945 of incorrect signature 947 + "401" : signed JWT validation performed and rejected because 948 of Expiration Time enforcement 950 + "402" : signed JWT validation performed and rejected because 951 of Client IP enforcement 953 + "403" : signed JWT validation performed and rejected because 954 of URI Regular Expression enforcement 956 + "404" : signed JWT validation performed and rejected because 957 of Issuer enforcement 959 + "405" : signed JWT validation performed and rejected because 960 of Not Before enforcement 962 + "500" : unable to perform signed JWT validation because of 963 malformed URI 965 * occurrence: there MUST be zero or exactly one instance of this 966 field. 968 o 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 or as the 985 plaintext of a JSON Web Encryption (JWE) structure, enabling the 986 claims to be digitally signed or integrity protected with a Message 987 Authentication Code (MAC) and/or encrypted. 989 5.1. HTTP Redirection 991 For HTTP-based request routing, a set of information that is unique 992 to a given end user content request is included in a signed JWT, 993 using key information that is specific to a pair of adjacent CDNI 994 hops (e.g., between the CSP and the uCDN or between the uCDN and a 995 dCDN). This allows a CDNI hop to ascertain the authenticity of a 996 given request received from a previous CDNI hop. 998 The URI signing method described below is based on the following 999 steps (assuming HTTP redirection, iterative request routing, and a 1000 CDN path with two CDNs). Note that uCDN and uCDN are used 1001 exchangeably. 1003 End-User dCDN uCDN CSP 1004 | | | | 1005 | 1.CDNI FCI interface used to | | 1006 | advertise URI Signing capability| | 1007 | |------------------->| | 1008 | | | | 1009 | 2.Provides information to validate signed JWT | 1010 | | |<-------------------| 1011 | | | | 1012 | 3.CDNI Metadata interface used to| | 1013 | provide URI Signing attributes| | 1014 | |<-------------------| | 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 |---------------------------------------->| [Validate URI | 1029 | | | signature] | 1030 | | | | 1031 | | (ALT: Validation 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 |------------------->| [Validate URI | | 1041 | | signature] | | 1042 | | | | 1043 | (ALT: Validation 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 validate 1061 signed JWTs from that CSP. For example, this information may 1062 include a key value. 1064 3. Using the CDNI Metadata interface, the uCDN communicates to a 1065 dCDN the information needed to validate signed JWTs from the 1066 uCDN for the given CSP. For example, this information may 1067 include the URI query string parameter name for the URI Signing 1068 Package Attribute. 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 personal 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 URI 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 validates the signed JWT in the URI using the information 1085 provided by the CSP. 1087 8. If the validation is negative, the uCDN rejects the request and 1088 sends an error code (e.g., 403 Forbidden) in the HTTP response. 1090 9. If the validation is positive, the uCDN computes a Signed URI 1091 that is based on unique parameters of that request and provides 1092 it to the end user as the URI to use to further request the 1093 content from the dCDN. 1095 10. On receipt of the corresponding content request, the dCDN 1096 validates the signed JWT in the Signed URI using the information 1097 provided by the uCDN in the CDNI Metadata. 1099 11. If the validation is negative, the dCDN rejects the request and 1100 sends an error code (e.g., 403 Forbidden) in the HTTP response. 1102 12. If the validation is positive, the dCDN serves the request and 1103 delivers the content. 1105 13. At a later time, the dCDN reports logging events that include 1106 URI signing information. 1108 With HTTP-based request routing, URI Signing matches well the general 1109 chain of trust model of CDNI both with symmetric and asymmetric keys 1110 because the key information only needs to be specific to a pair of 1111 adjacent CDNI hops. 1113 5.2. DNS Redirection 1115 For DNS-based request routing, the CSP and uCDN must agree on a trust 1116 model appropriate to the security requirements of the CSP's 1117 particular content. Use of asymmetric public/private keys allows for 1118 unlimited distribution of the public key to dCDNs. However, if a 1119 shared secret key is preferred, then the CSP may want to restrict the 1120 distribution of the key to a (possibly empty) subset of trusted 1121 dCDNs. Authorized Delivery CDNs need to obtain the key information 1122 to validate the Signed URI. 1124 The URI signing method described below is based on the following 1125 steps (assuming iterative DNS request routing and a CDN path with two 1126 CDNs). 1128 End-User dCDN uCDN CSP 1129 | | | | 1130 | 1.CDNI FCI interface used to | | 1131 | advertise URI Signing capability| | 1132 | |------------------->| | 1133 | | | | 1134 | 2.Provides information to validate signed JWT | 1135 | | |<-------------------| 1136 | 3.CDNI Metadata interface used to| | 1137 | provide URI Signing attributes| | 1138 | |<-------------------| | 1139 |4.Authorization request | | 1140 |------------------------------------------------------------->| 1141 | | | [Apply distribution 1142 | | | policy] | 1143 | | | | 1144 | | (ALT: Authorization decision) 1145 |5.Request is denied | | | 1146 |<-------------------------------------------------------------| 1147 | | | | 1148 |6.Provides signed URI | | 1149 |<-------------------------------------------------------------| 1150 | | | | 1151 |7.DNS request | | | 1152 |---------------------------------------->| | 1153 | | | | 1154 |8.Redirect DNS to dCDN | | 1155 |<----------------------------------------| | 1156 | | | | 1157 |9.DNS request | | | 1158 |------------------->| | | 1159 | | | | 1160 |10.IP address of Surrogate | | 1161 |<-------------------| | | 1162 | | | | 1163 |11.Content request | | | 1164 |------------------->| [Validate URI | | 1165 | | signature] | | 1166 | | | | 1167 | (ALT: Validation result) | | 1168 |12.Request is denied| | | 1169 |<-------------------| | | 1170 | | | | 1171 |13.Content delivery | | | 1172 |<-------------------| | | 1173 : : : : 1174 : (Later in time) : : : 1175 |14.CDNI Logging interface to report URI Signing information | 1176 | |------------------->| | 1178 Figure 4: DNS-based Request Routing with URI Signing 1180 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1181 the dCDN advertises its capabilities including URI Signing 1182 support to the uCDN. 1184 2. CSP provides to the uCDN the information needed to validate 1185 cryptographic signatures from that CSP. For example, this 1186 information may include a key. 1188 3. Using the CDNI Metadata interface, the uCDN communicates to a 1189 dCDN the information needed to validate cryptographic signatures 1190 from the CSP (e.g., the URI query string parameter name for the 1191 URI Signing Package Attribute). In the case of symmetric key, 1192 the uCDN checks if the dCDN is allowed by CSP to obtain the 1193 shared secret key. 1195 4. When a UA requests a piece of protected content from the CSP, 1196 the CSP makes a specific authorization decision for this unique 1197 request based on its arbitrary distribution policy. 1199 5. If the authorization decision is negative, the CSP rejects the 1200 request. 1202 6. If the authorization decision is positive, the CSP computes a 1203 cryptographic signature that is based on unique parameters of 1204 that request and includes it in the URI provided to the end user 1205 to request the content. 1207 7. End user sends DNS request to the uCDN. 1209 8. On receipt of the DNS request, the uCDN redirects the request to 1210 the dCDN. 1212 9. End user sends DNS request to the dCDN. 1214 10. On receipt of the DNS request, the dCDN responds with IP address 1215 of one of its Surrogates. 1217 11. On receipt of the corresponding content request, the dCDN 1218 validates the cryptographic signature in the URI using the 1219 information provided by the uCDN in the CDNI Metadata. 1221 12. If the validation is negative, the dCDN rejects the request and 1222 sends an error code (e.g., 403) in the HTTP response. 1224 13. If the validation is positive, the dCDN serves the request and 1225 delivers the content. 1227 14. At a later time, dCDN reports logging events that includes URI 1228 signing information. 1230 With DNS-based request routing, URI Signing matches well the general 1231 chain of trust model of CDNI when used with asymmetric keys because 1232 the only key information that needs to be distributed across 1233 multiple, possibly untrusted, CDNI hops is the public key, which is 1234 generally not confidential. 1236 With DNS-based request routing, URI Signing does not match well the 1237 general chain of trust model of CDNI when used with symmetric keys 1238 because the symmetric key information needs to be distributed across 1239 multiple CDNI hops, to CDNs with which the CSP may not have a trust 1240 relationship. This raises a security concern for applicability of 1241 URI Signing with symmetric keys in case of DNS-based inter-CDN 1242 request routing. 1244 6. IANA Considerations 1246 6.1. CDNI Payload Type 1248 This document requests the registration of the following CDNI Payload 1249 Type under the IANA "CDNI Payload Type" registry: 1251 +---------------+---------------+ 1252 | Payload Type | Specification | 1253 +---------------+---------------+ 1254 | MI.UriSigning | RFCthis | 1255 +---------------+---------------+ 1257 [RFC Editor: Please replace RFCthis with the published RFC number for 1258 this document.] 1260 6.1.1. CDNI UriSigning Payload Type 1262 Purpose: The purpose of this payload type is to distinguish 1263 UriSigning MI objects (and any associated capability advertisement). 1265 Interface: MI/FCI 1267 Encoding: see Section 4.4 1269 6.2. CDNI Logging Record Type 1271 This document requests the registration of the following CDNI Logging 1272 record-type under the IANA "CDNI Logging record-types" registry: 1274 +----------------------+-----------+--------------------------------+ 1275 | record-types | Reference | Description | 1276 +----------------------+-----------+--------------------------------+ 1277 | cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | 1278 | | | Record version 1 for content | 1279 | | | delivery using HTTP, to | 1280 | | | include URI Signing logging | 1281 | | | fields | 1282 +----------------------+-----------+--------------------------------+ 1284 [RFC Editor: Please replace RFCthis with the published RFC number for 1285 this document.] 1287 6.2.1. CDNI Logging Record Version 2 for HTTP 1289 The "cdni_http_request_v2" record-type supports all of the fields 1290 supported by the "cdni_http_request_v1" record-type [RFC7937] plus 1291 the two additional fields "s-uri-signing" and "s-uri-signing-deny- 1292 reason", registered by this document in Section 6.3. The name, 1293 format, field value, and occurence information for the two new fields 1294 can be found in Section 4.5 of this document. 1296 6.3. CDNI Logging Field Names 1298 This document requests the registration of the following CDNI Logging 1299 fields under the IANA "CDNI Logging Field Names" registry: 1301 +---------------------------+-----------+ 1302 | Field Name | Reference | 1303 +---------------------------+-----------+ 1304 | s-uri-signing | RFCthis | 1305 | s-uri-signing-deny-reason | RFCthis | 1306 +---------------------------+-----------+ 1308 [RFC Editor: Please replace RFCthis with the published RFC number for 1309 this document.] 1311 6.4. CDNI URI Signing Signed Token Transport 1313 The IANA is requested to create a new "CDNI URI Signing Signed Token 1314 Transport" subregistry in the "Content Delivery Networks 1315 Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing 1316 Signed Token Transport" namespace defines the valid values that may 1317 be in the Signed Token Transport (cdnistt) JWT claim. Additions to 1318 the Signed Token Transport namespace conform to the "Specification 1319 Required" policy as defined in [RFC5226]. 1321 The following table defines the initial Enforcement Information 1322 Elements: 1324 +-------+-------------------------------------------+---------+ 1325 | Value | Description | RFC | 1326 +-------+-------------------------------------------+---------+ 1327 | 0 | Designates token transport is not enabled | RFCthis | 1328 | 1 | Designates token transport via cookie | RFCthis | 1329 +-------+-------------------------------------------+---------+ 1331 [RFC Editor: Please replace RFCthis with the published RFC number for 1332 this document.] 1334 [Ed Note: are there any special instructions to the designated expert 1335 reviewer?] 1337 6.5. JSON Web Token Claims Registration 1339 This specification registers the following Claims in the IANA "JSON 1340 Web Token Claims" registry [IANA.JWT.Claims] established by 1341 [RFC7519]. 1343 6.5.1. Registry Contents 1345 o Claim Name: "cdniv" 1346 o Claim Description: CDNI Claim Set Version 1347 o Change Controller: IESG 1348 o Specification Document(s): Section 2.1.8 of [[ this specification 1349 ]] 1351 o Claim Name: "cdnicrit" 1352 o Claim Description: CDNI Critical Claims Set 1353 o Change Controller: IESG 1354 o Specification Document(s): Section 2.1.9 of [[ this specification 1355 ]] 1357 o Claim Name: "cdniip" 1358 o Claim Description: CDNI IP Address 1359 o Change Controller: IESG 1360 o Specification Document(s): Section 2.1.10 of [[ this specification 1361 ]] 1363 o Claim Name: "cdniuc" 1364 o Claim Description: CDNI URI Container 1365 o Change Controller: IESG 1366 o Specification Document(s): Section 2.1.11 of [[ this specification 1367 ]] 1369 o Claim Name: "cdniets" 1370 o Claim Description: CDNI Expiration Time Setting for Signed Token 1371 Renewal 1372 o Change Controller: IESG 1373 o Specification Document(s): Section 2.1.12 of [[ this specification 1374 ]] 1376 o Claim Name: "cdnistt" 1377 o Claim Description: CDNI Signed Token Transport Method for Signed 1378 Token Renewal 1379 o Change Controller: IESG 1380 o Specification Document(s): Section 2.1.13 of [[ this specification 1381 ]] 1383 o Claim Name: "cdnistd" 1384 o Claim Description: CDNI Signed Token Depth 1385 o Change Controller: IESG 1386 o Specification Document(s): Section 2.1.14 of [[ this specification 1387 ]] 1389 7. Security Considerations 1391 This document describes the concept of URI Signing and how it can be 1392 used to provide access authorization in the case of CDNI. The 1393 primary goal of URI Signing is to make sure that only authorized UAs 1394 are able to access the content, with a CSP being able to authorize 1395 every individual request. It should be noted that URI Signing is not 1396 a content protection scheme; if a CSP wants to protect the content 1397 itself, other mechanisms, such as DRM, are more appropriate. 1399 In general, it holds that the level of protection against 1400 illegitimate access can be increased by including more claims in the 1401 signed JWT. The current version of this document includes claims for 1402 enforcing Issuer, Client IP Address, Not Before time, and Expiration 1403 Time, however this list can be extended with other, more complex, 1404 attributes that are able to provide some form of protection against 1405 some of the vulnerabilities highlighted below. 1407 That said, there are a number of aspects that limit the level of 1408 security offered by URI Signing and that anybody implementing URI 1409 Signing should be aware of. 1411 o Replay attacks: A (valid) Signed URI may be used to perform replay 1412 attacks. The vulnerability to replay attacks can be reduced by 1413 picking a relatively short window between the Not Before time and 1414 Expiration Time attributes, although this is limited by the fact 1415 that any HTTP-based request needs a window of at least a couple of 1416 seconds to prevent a sudden network issues from preventing 1417 legitimate UAs access to the content. One may also reduce 1418 exposure to replay attacks by including a unique one-time access 1419 ID via the Nonce attribute (jti claim). Whenever the dCDN 1420 receives a request with a given unique ID, it adds that ID to the 1421 list of 'used' IDs. In the case an illegitimate UA tries to use 1422 the same URI through a replay attack, the dCDN can deny the 1423 request based on the already-used access ID. 1425 o Illegitimate clients behind a NAT: In cases where there are 1426 multiple users behind the same NAT, all users will have the same 1427 IP address from the point of view of the dCDN. This results in 1428 the dCDN not being able to distinguish between the different users 1429 based on Client IP Address and illegitimate users being able to 1430 access the content. One way to reduce exposure to this kind of 1431 attack is to not only check for Client IP but also for other 1432 attributes, e.g., attributes that can be found in HTTP headers. 1434 The shared key between CSP and uCDN may be distributed to dCDNs - 1435 including cascaded CDNs. Since this key can be used to legitimately 1436 sign a URL for content access authorization, it is important to know 1437 the implications of a compromised shared key. 1439 If a shared key usable for signing is compromised, an attacker can 1440 use it to perform a denial-of-service attack by forcing the CDN to 1441 evaluate prohibitively expensive regular expressions embedded in a 1442 cdniuc claim. As a result, compromised keys should be timely revoked 1443 in order to prevent exploitation. 1445 8. Privacy 1447 The privacy protection concerns described in CDNI Logging Interface 1448 [RFC7937] apply when the client's IP address (cdniip) is embedded in 1449 the Signed URI. For this reason, the mechanism described in 1450 Section 2 encrypts the Client IP before including it in the URI 1451 Signing Package (and thus the URL itself). 1453 9. Acknowledgements 1455 The authors would like to thank the following people for their 1456 contributions in reviewing this document and providing feedback: 1457 Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan 1458 York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana 1459 Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris 1460 Lemmons. 1462 10. Contributors 1464 In addition, the authors would also like to make special mentions for 1465 certain people who contributed significant sections to this document. 1467 o Matt Caulfield provided content for the CDNI Metadata Interface 1468 section. 1470 o Emmanuel Thomas provided content for HTTP Adaptive Streaming. 1472 o Matt Miller provided consultation on JWT usage as well as code to 1473 generate working JWT examples. 1475 11. References 1477 11.1. Normative References 1479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1480 Requirement Levels", BCP 14, RFC 2119, 1481 DOI 10.17487/RFC2119, March 1997, 1482 . 1484 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1485 IANA Considerations Section in RFCs", RFC 5226, 1486 DOI 10.17487/RFC5226, May 2008, 1487 . 1489 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1490 Keranen, A., and P. Hallam-Baker, "Naming Things with 1491 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1492 . 1494 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1495 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1496 2014, . 1498 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1499 Protocol (HTTP/1.1): Message Syntax and Routing", 1500 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1501 . 1503 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1504 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1505 . 1507 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1508 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1509 . 1511 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 1512 and R. Peterkofsky, "Content Distribution Network 1513 Interconnection (CDNI) Logging Interface", RFC 7937, 1514 DOI 10.17487/RFC7937, August 2016, 1515 . 1517 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1518 "Content Delivery Network Interconnection (CDNI) 1519 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1520 . 1522 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1523 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1524 May 2017, . 1526 11.2. Informative References 1528 [IANA.JWT.Claims] 1529 IANA, "JSON Web Token Claims", 1530 . 1532 [MPEG-DASH] 1533 ISO, "Information technology -- Dynamic adaptive streaming 1534 over HTTP (DASH) -- Part 1: Media presentation description 1535 and segment format", ISO/IEC 23009-1:2014, Edition 2, 05 1536 2014, . 1538 [POSIX.1] IEEE, "The Open Group Base Specifications Issue 7", IEEE 1539 Std 1003.1 2018 Edition, Jan 2018, 1540 . 1542 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1543 Resource Identifier (URI): Generic Syntax", STD 66, 1544 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1545 . 1547 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1548 "Network Time Protocol Version 4: Protocol and Algorithms 1549 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1550 . 1552 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1553 Address Text Representation", RFC 5952, 1554 DOI 10.17487/RFC5952, August 2010, 1555 . 1557 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1558 DOI 10.17487/RFC6265, April 2011, 1559 . 1561 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1562 Distribution Network Interconnection (CDNI) Problem 1563 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1564 2012, . 1566 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 1567 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 1568 Content Distribution Network Interconnection (CDNI)", 1569 RFC 6983, DOI 10.17487/RFC6983, July 2013, 1570 . 1572 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1573 "Framework for Content Distribution Network 1574 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1575 August 2014, . 1577 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1578 Network Interconnection (CDNI) Requirements", RFC 7337, 1579 DOI 10.17487/RFC7337, August 2014, 1580 . 1582 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1583 DOI 10.17487/RFC7517, May 2015, 1584 . 1586 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1587 "Request Routing Redirection Interface for Content 1588 Delivery Network (CDN) Interconnection", RFC 7975, 1589 DOI 10.17487/RFC7975, October 2016, 1590 . 1592 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1593 R., and K. Ma, "Content Delivery Network Interconnection 1594 (CDNI) Request Routing: Footprint and Capabilities 1595 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1596 . 1598 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 1599 RFC 8216, DOI 10.17487/RFC8216, August 2017, 1600 . 1602 Appendix A. Signed URI Package Example 1604 This section contains three examples of token usage: a simple example 1605 with only the required claim present, a complex example which 1606 demonstrates the full JWT claims set, including an encrypted Client 1607 IP (cdniip), and one that uses a Signed Token Renewal. 1609 Note: All of the examples have whitespace added to improve formatting 1610 and readability, but are not present in the generated content. 1612 All examples use the following JWK Set [RFC7517]: 1614 { "keys": [ 1615 { 1616 "kty": "EC", 1617 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1618 "use": "sig", 1619 "alg": "ES256", 1620 "crv": "P-256", 1621 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1622 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA" 1623 }, 1624 { 1625 "kty": "EC", 1626 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1627 "use": "sig", 1628 "alg": "ES256", 1629 "crv": "P-256", 1630 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1631 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", 1632 "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" 1633 }, 1634 { 1635 "kty": "oct", 1636 "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", 1637 "use": "enc", 1638 "alg": "A128GCM", 1639 "k": "4uFxxV7fhNmrtiah2d1fFg" 1640 } 1641 ]} 1643 Note: They are the public signing key, the private signing key, and 1644 the shared secret enctyption key, respectively. The public and 1645 private signing keys have the same fingerprint and only vary by the 1646 'd' parameter that is missing from the public signing key. 1648 A.1. Simple Example 1650 This example is a simple common usage example containing a minimal 1651 subset of claims that the authors find most useful. 1653 The JWT Claim Set before signing: 1655 Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the 1656 URL Segment form ([RFC6920] Section 5) of "http://cdni.example/foo/ 1657 bar". 1659 { 1660 "exp": 1474243500, 1661 "iss": "uCDN Inc", 1662 "cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" 1663 } 1665 The signed JWT: 1667 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1668 dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE0NzQyNDM1MDAsImlzcyI6InVDRE4gS 1669 W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV 1670 wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.qzzAB9akC-HoEzQrkOoODWjMC0PEZRrmWz 1671 2rSMcpLtvxyxVodlB2xcpl4J4ABhLLOJzgzL9B39TljTqZApSOpQ 1673 A.2. Complex Example 1675 This example uses all fields except for those dealing with Signed 1676 Token Renewal, including Client IP (cdniip) and Subject (sub) which 1677 are encrpyted. This significantly increases the size of the signed 1678 JWT token. 1680 JWE for Client IP (cdniip) of [2001:db8::1/32]: 1682 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1683 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..SuzoOnfg-GVh-BOc.wQ9iS 1684 R1sTj-A04CiDmvcgg.9Ts_cIEUw6Yc6U5HaH1UPQ 1686 JWE for Subject (sub) of "UserToken": 1688 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1689 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..XsJ7ySeChORSIojp.R1U8E 1690 SGU2NnW.DWR8pTbeCwQZca6SitfX_g 1692 The JWT Claim Set before signing: 1694 { 1695 "aud": "dCDN LLC", 1696 "sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4 1697 QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..XsJ7ySeChORS 1698 Iojp.R1U8ESGU2NnW.DWR8pTbeCwQZca6SitfX_g", 1699 "cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY 1700 mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..SuzoOnfg- 1701 GVh-BOc.wQ9iSR1sTj-A04CiDmvcgg.9Ts_cIEUw6Yc6U5HaH1UPQ", 1702 "cdniv": 1, 1703 "exp": 1474243500, 1704 "iat": 1474243200, 1705 "iss": "uCDN Inc", 1706 "jti": "5DAafLhZAfhsbe", 1707 "nbf": 1474243200, 1708 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png" 1709 } 1711 The signed JWT: 1713 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1714 dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib 1715 U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA 1716 0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T 1717 0NKOS4uWHNKN3lTZUNoT1JTSW9qcC5SMVU4RVNHVTJOblcuRFdSOHBUYmVDd1FaY2E 1718 2U2l0ZlhfZyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja 1719 m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp 1720 2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uU3V6b09uZmctR1ZoLUJPYy53U 1721 TlpU1Ixc1RqLUEwNENpRG12Y2dnLjlUc19jSUVVdzZZYzZVNUhhSDFVUFEiLCJjZG5 1722 pdiI6MSwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6InVDR 1723 E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE0NzQyNDMyMDAsImN 1724 kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde 1725 zN9XFwucG5nIn0.XEi1NeP8Lzh6ECcbp6EoqYlnJGikaGp6F3lIJ7ZJt3bim6tOtuD 1726 pCQxmEQxobzIpWOCNdpB8kvxM_s95brKjNQ 1728 A.3. Signed Token Renewal Example 1730 This example uses fields for Signed Token Renewal. 1732 The JWT Claim Set before signing: 1734 { 1735 "cdniets": 30, 1736 "cdnistt": 1, 1737 "cdnistd": 2, 1738 "exp": 1474243500, 1739 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1740 } 1741 The signed JWT: 1743 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1744 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1745 XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTAwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1746 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.wsSvwxY8mtRax7HK_ 1747 dro_l6m-mM-HYdeaUoTSgVS5XTIhXBsCPsYQncsradmgmOWHDDOxsSMVVTjHe5E5YH 1748 ZlQ 1750 Once the server validates the signed JWT it will return a new signed 1751 JWT with an updated expiry time (exp) as shown below. Note the 1752 expiry time is increased by the expiration time setting (cdniets) 1753 value. 1755 The JWT Claim Set before signing: 1757 { 1758 "cdniets": 30, 1759 "cdnistt": 1, 1760 "cdnistd": 2, 1761 "exp": 1474243530, 1762 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1763 } 1765 The signed JWT: 1767 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1768 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1769 XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTMwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1770 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.SITeoIVZ8-yeE_GBV 1771 jYEo1P2LN-EId1gEJ6baR3Au7Dzh2o_O7LhH3k6wHY081sYMdXHucB0P5ocp-r7gqe 1772 ruQ 1774 Authors' Addresses 1776 Ray van Brandenburg 1777 Tiledmedia 1778 Anna van Buerenplein 1 1779 Den Haag 2595DA 1780 The Netherlands 1782 Phone: +31 88 866 7000 1783 Email: ray@tiledmedia.com 1784 Kent Leung 1785 Cisco Systems, Inc. 1786 3625 Cisco Way 1787 San Jose, CA 95134 1788 United States 1790 Phone: +1 408 526 5030 1791 Email: kleung@cisco.com 1793 Phil Sorber 1794 Apple, Inc. 1795 1800 Wazee Street 1796 Suite 410 1797 Denver, CO 80202 1798 United States 1800 Email: sorber@apple.com