idnits 2.17.1 draft-ietf-cdni-uri-signing-14.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 292 has weird spacing: '...I(after v ...' -- The document date (March 5, 2018) is 2237 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) Summary: 3 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: September 6, 2018 Cisco Systems, Inc. 6 P. Sorber 7 March 5, 2018 9 URI Signing for CDN Interconnection (CDNI) 10 draft-ietf-cdni-uri-signing-14 12 Abstract 14 This document describes how the concept of URI signing supports the 15 content access control requirements of CDNI and proposes a URI 16 signing method as a JSON Web Token (JWT) [RFC7519] profile. 18 The proposed URI signing method specifies the information needed to 19 be included in the URI to transmit the signed JWT as well as the 20 claims needed by the signed JWT to authorize a UA. The mechanism 21 described can be used both in CDNI and single CDN scenarios. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 6, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Background and overview on URI Signing . . . . . . . . . 5 60 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 61 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 62 2. JWT Format and Processing Requirements . . . . . . . . . . . 9 63 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10 65 2.1.2. Subject (sub) claim . . . . . . . . . . . . . . . . . 10 66 2.1.3. Audience (aud) claim . . . . . . . . . . . . . . . . 11 67 2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 11 68 2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11 69 2.1.6. Issued At (iat) claim . . . . . . . . . . . . . . . . 12 70 2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 12 71 2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12 72 2.1.9. Client IP (cdniip) claim . . . . . . . . . . . . . . 12 73 2.1.10. CDNI URI Container (cdniuc) claim . . . . . . . . . . 13 74 2.1.11. CDNI Expiration Time Setting (cdniets) claim . . . . 13 75 2.1.12. CDNI Signed Token Transport (cdnistt) claim . . . . . 13 76 2.1.13. URI Container Forms . . . . . . . . . . . . . . . . . 14 77 2.1.13.1. URI Simple Container (uri:) . . . . . . . . . . 14 78 2.1.13.2. URI Regular Expression Container (uri-regex:) . 14 79 2.1.13.3. URI Hash Container (uri-hash:) . . . . . . . . . 14 80 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 15 81 3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 15 82 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 83 3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 16 84 3.2.1. Required Claims . . . . . . . . . . . . . . . . . . . 16 85 3.3. Communicating a signed JWTs in Signed Token Renewal . . . 16 86 3.3.1. Support for cross-domain redirection . . . . . . . . 17 87 4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 17 88 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 17 89 4.2. CDNI Footprint & Capabilities Advertisement Interface . . 18 90 4.3. CDNI Request Routing Redirection Interface . . . . . . . 18 91 4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 18 92 4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 19 93 5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 21 94 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 21 95 5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 23 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 97 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 26 98 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 27 99 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 27 100 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 27 101 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 27 102 6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 28 103 6.5. JSON Web Token Claims Registration . . . . . . . . . . . 28 104 6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 28 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 106 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 107 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 108 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 111 11.2. Informative References . . . . . . . . . . . . . . . . . 32 112 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 33 113 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 34 114 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 35 115 A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 36 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 118 1. Introduction 120 This document describes the concept of URI Signing and how it can be 121 used to provide access authorization in the case of redirection 122 between interconnected CDNs (CDNI) and between a Content Service 123 Provider (CSP) and a CDN. The primary goal of URI Signing is to make 124 sure that only authorized User Agents (UAs) are able to access the 125 content, with a CSP being able to authorize every individual request. 126 It should be noted that URI Signing is not a content protection 127 scheme; if a CSP wants to protect the content itself, other 128 mechanisms, such as Digital Rights Management (DRM), are more 129 appropriate. In addition to access control, URI Signing also has 130 benefits in reducing the impact of denial-of-service attacks. 132 The overall problem space for CDN Interconnection (CDNI) is described 133 in CDNI Problem Statement [RFC6707]. This document, along with the 134 CDNI Requirements [RFC7337] document and the CDNI Framework 135 [RFC7336], describes the need for interconnected CDNs to be able to 136 implement an access control mechanism that enforces the CSP's 137 distribution policy. 139 Specifically, CDNI Framework [RFC7336] states: 141 The CSP may also trust the CDN operator to perform actions such as 142 ..., and to enforce per-request authorization performed by the CSP 143 using techniques such as URI signing. 145 In particular, the following requirement is listed in CDNI 146 Requirements [RFC7337]: 148 MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of 149 authorization checks and validation that are to be performed by 150 the Surrogate before delivery. For example, this could 151 potentially include the need to validate information (e.g., Expiry 152 time, Client IP address) required for access authorization. 154 This document proposes a method of signing URIs that allows 155 Surrogates in interconnected CDNs to enforce a per-request 156 authorization performed by the CSP. Splitting the role of performing 157 per-request authorization by the CSP and the role of validating this 158 authorization by the CDN allows any arbitrary distribution policy to 159 be enforced across CDNs without the need of CDNs to have any 160 awareness of the actual CSP distribution policy. 162 The representation of this method is a Signed JSON Web Token (JWT) 163 [RFC7519]. 165 1.1. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 This document uses the terminology defined in CDNI Problem Statement 174 [RFC6707]. 176 This document also uses the terminology of JSON Web Token (JWT) 177 [RFC7519]. 179 In addition, the following terms are used throughout this document: 181 o Signed URI: A URI for which a signed JWT is provided. 183 o Target CDN URI: URI created by the CSP to direct a UA towards the 184 Upstream CDN (uCDN). The Target CDN URI can be signed by the CSP 185 and verified by the uCDN and possibly further Downstream CDNs 186 (dCDNs). 188 o Redirection URI: URI created by the uCDN to redirect a UA towards 189 the dCDN. The Redirection URI can be signed by the uCDN and 190 verified by the dCDN. In a cascaded CDNI scenario, there can be 191 more than one Redirection URI. 193 o Signed Token Renewal: A series of signed JWTs that are used for 194 subsequent access to a set of related resources in a CDN, such as 195 a set of HTTP Adaptive Streaming files. Every time a signed JWT 196 is used to access a particular resource, a new signed JWT is sent 197 along with the resource that can be used to request the next 198 resource in the set. When generating a new signed JWT in Signed 199 Token Renewal, parameters are carried over from one signed JWT to 200 the next. 202 1.2. Background and overview on URI Signing 204 A CSP and CDN are assumed to have a trust relationship that enables 205 the CSP to authorize access to a content item by including a set of 206 claims in the form of a signed JWT in the URI before redirecting a UA 207 to the CDN. Using these attributes, it is possible for a CDN to 208 check an incoming content request to see whether it was authorized by 209 the CSP (e.g., based on the UA's IP address or a time window). To 210 prevent the UA from altering the claims a signed JWT is REQUIRED. 212 Figure 1, shown below, presents an overview of the URI Signing 213 mechanism in the case of a CSP with a single CDN. When the UA 214 browses for content on CSP's website (#1), it receives HTML web pages 215 with embedded content URIs. Upon requesting these URIs, the CSP 216 redirects to a CDN, creating a Target CDN URI (#2) (alternatively, 217 the Target CDN URI itself is embedded in the HTML). The Target CDN 218 URI is the Signed URI which may include the IP address of the UA and/ 219 or a time window and always contains the signed JWT which is 220 generated by the CSP using a shared secret or private key. Once the 221 UA receives the response with the Signed URI, it sends a new HTTP 222 request using the Signed URI to the CDN (#3). Upon receiving the 223 request, the CDN checks to see if the Signed URI is authentic by 224 verifying the signed JWT. If applicable, it checks whether the IP 225 address of the HTTP request matches that in the Signed URI and if the 226 time window is still valid. After these claims are confirmed to be 227 valid, the CDN delivers the content (#4). 229 -------- 230 / \ 231 | CSP |< * * * * * * * * * * * 232 \ / Trust * 233 -------- relationship * 234 ^ | * 235 | | * 236 1. Browse | | 2. Signed * 237 for | | URI * 238 content | | * 239 | v v 240 +------+ 3. Signed URI -------- 241 | User |----------------->/ \ 242 | Agent| | CDN | 243 | |<-----------------\ / 244 +------+ 4. Content -------- 245 Delivery 247 Figure 1: Figure 1: URI Signing in a CDN Environment 249 1.3. CDNI URI Signing Overview 251 In a CDNI environment, URI Signing operates the same way in the 252 initial steps #1 and #2 but the later steps involve multiple CDNs in 253 the process of delivering the content. The main difference from the 254 single CDN case is a redirection step between the uCDN and the dCDN. 255 In step #3, UA may send an HTTP request or a DNS request. Depending 256 on whether HTTP-based or DNS-based request routing is used, the uCDN 257 responds by directing the UA towards the dCDN using either a 258 Redirection URI (which is a Signed URI generated by the uCDN) or a 259 DNS reply, respectively (#4). Once the UA receives the response, it 260 sends the Redirection URI/Target CDN URI to the dCDN (#5). The 261 received URI is validated by the dCDN before delivering the content 262 (#6). This is depicted in the figure below. Note: The CDNI call 263 flows are covered in Detailed URI Signing Operation (Section 5). 265 +-------------------------+ 266 |Request Redirection Modes| 267 +-------------------------+ 268 | a) HTTP | 269 | b) DNS | 270 +-------------------------+ 271 -------- 272 / \< * * * * * * * * * * * * * * 273 | CSP |< * * * * * * * * * * * * 274 \ / Trust * * 275 -------- relationship * * 276 ^ | * * 277 | | 2. Signed * * 278 1. Browse | | URI in * * 279 for | | HTML * * 280 content | | * * 281 | v 3.a)Signed URI v * 282 +------+ b)DNS request -------- * Trust 283 | User |----------------->/ \ * relationship 284 | Agent| | uCDN | * (optional) 285 | |<-----------------\ / * 286 +------+ 4.a)Redirection URI------- * 287 ^ | b)DNS Reply ^ * 288 | | * * 289 | | Trust relationship * * 290 | | * * 291 6. Content | | 5.a)Redirection URI * * 292 delivery | | b)Signed URI(after v v 293 | | DNS exchange) -------- 294 | +---------------------->/ \ [May be 295 | | dCDN | cascaded 296 +--------------------------\ / CDNs] 297 -------- 299 +-----------------------------------------+ 300 | Key | Asymmetric | Symmetric | 301 +-----------------------------------------+ 302 |HTTP |Public key (uCDN)|Shared key (uCDN)| 303 |DNS |Public key (CSP) |Shared key (CSP) | 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 CDN 310 that the CSP has a trust relationship with is the uCDN. The delivery 311 of the content may be delegated to the dCDN, which has a relationship 312 with the uCDN 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., 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., Target CDN URI) 325 provided by the CSP reaches the uCDN. After this URI has been 326 verified to be correct by the uCDN, the uCDN creates and signs a new 327 Redirection URI to redirect the UA to the dCDN. Since this new URI 328 could have a new signed JWT, a new signature can be based around the 329 trust relationship between the uCDN and dCDN, and the relationship 330 between the dCDN and CSP is not relevant. Given the fact that such a 331 relationship between uCDN and dCDN always exists, both asymmetric 332 public/private keys and symmetric shared secret keys can be used for 333 URI Signing with HTTP-based request routing. Note that the signed 334 Redirection URI MUST maintain the same, or higher, level of security 335 as the original Signed URI. 337 Two types of keys can be used for URI Signing: asymmetric keys and 338 symmetric keys. Asymmetric keys are based on a public/private key 339 pair mechanism and always contain a private key only known to the 340 entity signing the URI (either CSP or uCDN) and a public key for the 341 verification of the Signed URI. With symmetric keys, the same key is 342 used by both the signing entity for signing the URI as well as by the 343 validating entity for validating the Signed URI. Regardless of the 344 type of keys used, the validating entity has to obtain the key 345 (either the public or the symmetric key). There are very different 346 requirements for key distribution (out of scope of this document) 347 with asymmetric keys and with symmetric keys. Key distribution for 348 symmetric keys requires confidentiality to prevent another party from 349 getting access to the key, since it could then generate valid Signed 350 URIs for unauthorized requests. Key distribution for asymmetric keys 351 does not require confidentiality since public keys can typically be 352 distributed openly (because they cannot be used for URI signing) and 353 private keys are kept by the URI signing function. 355 1.4. URI Signing in a non-CDNI context 357 While the URI signing method defined in this document was primarily 358 created for the purpose of allowing URI Signing in CDNI scenarios, 359 e.g., between a uCDN and a dCDN or between a CSP and a dCDN, there is 360 nothing in the defined URI Signing method that precludes it from 361 being used in a non-CDNI context. As such, the described mechanism 362 could be used in a single-CDN scenario such as shown in Figure 1 in 363 Section 1.2, for example to allow a CSP that uses different CDNs to 364 only have to implement a single URI Signing mechanism. 366 2. JWT Format and Processing Requirements 368 The concept behind URI Signing is based on embedding a signed JSON 369 Web Token (JWT) [RFC7519] in the UA request: The signed JWT contains 370 a number of claims that can be validated to ensure the UA has 371 legitimate access to the content. 373 This document specifies the following attribute for embedding a 374 signed JWT in a Target CDN URI or Redirection URI: 376 o URI Signing Package (URISigningPackage): The URI attribute that 377 encapsulates all the URI Signing claims in a signed JWT encoded 378 format. This attribute is exposed in the Signed URI as a URI 379 query parameter or as a URL path parameter. 381 The parameter name of the URI Signing Package Attribute is defined in 382 the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is 383 not used, or does not include a parameter name for the URI Signing 384 Package Attribute, the parameter name can be set by configuration 385 (out of scope of this document). 387 The URI Signing Package will be found by searching the URI, left-to- 388 right, for the following sequence: 390 o a reserved character (as defined in [RFC3986] Section 2.2), 392 o the URI Signing Package Attribute name, 394 o if the last character of the URI Singing Package Attribute name is 395 not a reserved character, an equal symbol ('='), 397 o and a sequence of non-reserved characters that will be interpreted 398 as a signed JWT, 400 o terminated by either a reserved character or the end of the URI. 402 The first such match will be taken to provide the signed JWT; the URI 403 will not be searched for multiple signed JWTs. 405 2.1. JWT Claims 407 This section identifies the set of claims that can be used to enforce 408 the CSP distribution policy. New claims can be introduced in the 409 future to extend the distribution policy capabilities. 411 In order to provide distribution policy flexibility, the exact subset 412 of claims used in a given signed JWT is a runtime decision. Claim 413 requirements are defined in the CDNI Metadata (Section 4.4) If the 414 CDNI Metadata interface is not used, or does not include claim 415 requirements, the claim requirements can be set by configuration (out 416 of scope of this document). 418 The following claims (where the "JSON Web Token Claims" registry 419 claim name is specified in parenthesis below) are used to enforce the 420 distribution policies. All of the listed claims are mandatory to 421 implement in a URI Signing implementation, but are not mandatory to 422 use in a given signed JWT. (The "optional" and "mandatory" 423 identifiers in square brackets refer to whether or not a given claim 424 MUST be present in a URI Signing JWT.) A CDN MUST be able to parse 425 and process all of the claims listed below. If the signed JWT 426 contains any other claims which the CDN does not understand (i.e., is 427 unable to parse and process), the CDN MUST reject the request. 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. Client IP (cdniip) claim 549 Client IP (cdniip) [optional] IP address, or IP prefix, for which the 550 Signed URI is valid. This is represented in CIDR notation, with 551 dotted decimal format for IPv4 or canonical text representation for 552 IPv6 addresses [RFC5952]. The request is rejected if sourced from a 553 client outside of the specified IP range. Since the client IP is 554 considered personally identifiable information this field MUST be a 555 JSON Web Encryption (JWE [RFC7516]) Object in compact serialization 556 form. If the CDN validating the signed JWT does not support Client 557 IP validation, or if the Client IP in the signed JWT does not match 558 the source IP address in the content request, the CDN MUST reject the 559 request. The type of this claim is a JSON string that contains the 560 JWE. If the received signed JWT contains a Client IP claim, then any 561 JWT subsequently generated for CDNI redirection MUST also contain a 562 Client IP claim, and the Client IP value MUST be the same as in the 563 received signed JWT. A signed JWT generated for CDNI redirection 564 MUST NOT add a Client IP claim if no Client IP claim existed in the 565 received signed JWT. 567 2.1.10. CDNI URI Container (cdniuc) claim 569 URI Container (cdniuc) [optional] - Container for holding the URI 570 representation before a URI Signing Package is added. This 571 representation can take one of several forms detailed in 572 Section 2.1.13. If the URI regex in the signed JWT does not match 573 the URI of the content request, the CDN validating the signed JWT 574 MUST reject the request. When comparing the URI, the percent encoded 575 form as defined in [RFC3986] Section 2.1 MUST be used. When 576 redirecting a URI, the CDN generating the new signed JWT MAY change 577 the URI Container to comport with the URI being used in the 578 redirection. 580 2.1.11. CDNI Expiration Time Setting (cdniets) claim 582 CDNI Expiration Time Setting (cdniets) [optional] - The CDNI 583 Expiration Time Setting (cdniets) claim provides a means for setting 584 the value of the Expiry Time (exp) claim when generating a subsequent 585 signed JWT in Signed Token Renewal. Its type is a JSON numeric 586 value. It denotes the number of seconds to be added to the time at 587 which the JWT is validated that gives the value of the Expiry Time 588 (exp) claim of the next signed JWT. The CDNI Expiration Time Setting 589 (cdniets) SHOULD NOT be used when not using Signed Token Renewal and 590 MUST be present when using Signed Token Renewal. 592 2.1.12. CDNI Signed Token Transport (cdnistt) claim 594 CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed 595 Token Transport (cdnistt) claim provides a means of signalling the 596 method through which a new signed JWT is transported from the CDN to 597 the UA and vice versa for the purpose of Signed Token Renewal. Its 598 type is a JSON integer. Values for this claim can be defined in 599 Section 6.4. If using this claim you MUST also specify a CDNI 600 Expiration Time Setting (cdniets) as noted above. 602 2.1.13. URI Container Forms 604 The URI Container (cdniuc) claim takes one of the following forms. 605 More forms may be added in the future to extend the capabilities. 607 Before comparing a URI against this container, the signed JWT must be 608 removed from the URI. This removal is only for the purpose of 609 determining if the URI matches; all other purposes will use the 610 original URI. If the signed JWT is terminated by anything other than 611 a sub-delimiter (as definined in [RFC3986] Section 2.2), everything 612 from the reserved character (as defined in [RFC3986] Section 2.2) 613 that precedes the URI Signing Package Attribute to the last character 614 of the signed JWT will be removed, inclusive. Otherwise, everything 615 from the first character of the URI Signing Package Attribute to the 616 sub-delimiter that terminates the signed JWT will be removed, 617 inclusive. 619 2.1.13.1. URI Simple Container (uri:) 621 When prefixed with 'uri:', the string following 'uri:' is the URI 622 that MUST be matched with a simple string match to the requested URI. 624 2.1.13.2. URI Regular Expression Container (uri-regex:) 626 Prefixed with 'uri-regex:', this string is any PCRE [PCRE839] 627 compatible regular expression used to match against the requested 628 URI. 630 Note: Because '\' has special meaning in JSON [RFC7159] as the escape 631 character within JSON strings, the regular expression character '\' 632 MUST be escaped as '\\'. 634 An example of a 'uri-regex:' is the following: 636 [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\?.*)? 638 Note: Due to computational complexity of executing arbitrary regular 639 expressions, it is RECOMMENDED to only execute after validating the 640 JWT to ensure its authenticity. 642 2.1.13.3. URI Hash Container (uri-hash:) 644 Prefixed with 'uri-hash:', this string is a URL Segment form 645 ([RFC6920] Section 5) of the URI. 647 2.2. JWT Header 649 The header of the JWT MAY be passed via the CDNI Metadata interface 650 instead of being included in the URISigningPackage. The header value 651 must be transmitted in the serialized encoded form and prepended to 652 the JWT payload and signature passed in the URISigningPackage prior 653 to validation. This reduces the size of the signed JWT token. 655 3. URI Signing Token Renewal 657 3.1. Overview 659 For content that is delivered via HTTP in a segmented fashion, such 660 as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216], 661 special provisions need to be made in order to ensure URI Signing can 662 be applied. In general, segmented protocols work by breaking large 663 objects (e.g. videos) into a sequence of small independent segments. 664 Such segments are then referenced by a separate manifest file, which 665 either includes a list of URLs to the segments or specifies an 666 algorithm through which a User Agent can construct the URLs to the 667 segments. Requests for segments therefore originate from the 668 manifest file and, unless the URLs in the manifest file point to the 669 CSP, are not subjected to redirection and URI Signing. This opens up 670 the vulnerability of malicious User Agents sharing the manifest file 671 and deep-linking to the segments. 673 One method for dealing with this vulnerability would be to include, 674 in the manifest itself, Signed URIs that point to the individual 675 segments. There exist a number of issues with that approach. First, 676 it requires the CDN delivering the manifest to rewrite the manifest 677 file for each User Agent, which would require the CDN to be aware of 678 the exact segmentation protocol used. Secondly, it could also 679 require the expiration time of the Signed URIs to be valid for an 680 extended duration if the content described by the manifest is meant 681 to be consumed in real time. For instance, if the manifest file were 682 to contain a segmented video stream of more than 30 minutes in 683 length, Signed URIs would require to be valid for a at least 30 684 minutes, thereby reducing their effectiveness and that of the URI 685 Signing mechanism in general. For a more detailed analysis of how 686 segmented protocols such as HTTP Adaptive Streaming protocols affect 687 CDNI, see Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. 689 The method described in this section allows CDNs to use URI Signing 690 for segmented content without having to include the Signed URIs in 691 the manifest files themselves. 693 3.2. Signed Token Renewal mechanism 695 In order to allow for effective access control of segmented content, 696 the URI signing scheme defined in this section is based on a 697 mechanism through which subsequent segment requests can be linked 698 together. As part of the JWT validation procedure, the CDN can 699 generate a new signed JWT that the UA can use to do a subsequent 700 request. More specifically, whenever a UA successfully retrieves a 701 segment, it receives, in the HTTP 2xx Successful message, a signed 702 JWT that it can use whenever it requests the next segment. As long 703 as each successive signed JWT is correctly validated before a new one 704 is generated, the model is not broken and the User Agent can 705 successfully retrieve additional segments. Given the fact that with 706 segmented protocols, it is usually not possible to determine a priori 707 which segment will be requested next (i.e., to allow for seeking 708 within the content and for switching to a different representation), 709 the Signed Token Renewal uses the URI Regular Expression Container 710 scoping mechanisms in the URI Container (cdniuc) claim to allow a 711 signed JWT to be valid for more than one URL. 713 In order for this renewal of signed JWTs to work, it is necessary for 714 a UA to extract the signed JWT from the HTTP 2xx Successful message 715 of an earlier request and use it to retrieve the next segment. The 716 exact mechanism by which the client does this depends on the exact 717 segmented protocol and since this document is only concerned with the 718 generation and validation of incoming request, this process is 719 outside the scope of this document. However, in order to also 720 support legacy UAs that do not include any specific provisions for 721 the handling of signed JWTs, the folowing section defines a mechanism 722 using HTTP Cookies that allows such UAs to support the concept of 723 renewing signed JWTs without requiring any support on the UA side. 725 3.2.1. Required Claims 727 The cdnistt claim (Section 2.1.12) and cdniets claim (Section 2.1.11) 728 MUST both be present to utilize Signed token Renewal. Either one 729 MUST NOT appear alone. You MAY set cdnistt to a value of '0' to mean 730 no Signed Token Renewal, but you still MUST have a corresponding 731 cdniets that validates as a JSON number. However, if you do not want 732 to use Signed Token Renewal, it is RECOMMENDED to simply omit both. 734 3.3. Communicating a signed JWTs in Signed Token Renewal 736 This section assumes the value of the CDNI Signed Token Transport 737 (cdnistt) claim has been set to 1. Other values of cdnistt are out 738 of scope of this document. 740 When using the Signed Token Renewal mechanism, the signed JWT is 741 transported to the UA via a 'URISigningPackage' cookie added to the 742 HTTP 2xx Successful message along with the content being returned to 743 the UA, or to the HTTP 3xx Redirection message in case the UA is 744 redirected to a different server. 746 3.3.1. Support for cross-domain redirection 748 For security purposes, the use of cross-domain cookies is not 749 supported in some application environments. As a result, the Cookie- 750 based method for transport of the Signed Token described in the 751 previous section might break if used in combination with a HTTP 3xx 752 Redirection response where the target URL is in a different domain. 753 In such scenarios, Signed Token Renewal of a signed JWT SHOULD be 754 communicated via the query string instead, in a similar fashion to 755 how regular signed JWTs (outside of Signed Token Renewal) are 756 communicated. Note that the use of URL embedded signed JWTs SHOULD 757 NOT be used in HTTP 2xx Successful messages, since UAs might not know 758 how to extract the signed JWTs. 760 Note that the process described below only works in cases where both 761 the manifest file and segments constituting the segmented content are 762 delivered from the same domain. In other words, any redirection 763 between different domains needs to be carried out while retrieving 764 the manifest file. 766 4. Relationship with CDNI Interfaces 768 Some of the CDNI Interfaces need enhancements to support URI Signing. 769 As an example: A dCDN that supports URI Signing needs to be able to 770 advertise this capability to the uCDN. The uCDN needs to select a 771 dCDN based on such capability when the CSP requires access control to 772 enforce its distribution policy via URI Signing. Also, the uCDN 773 needs to be able to distribute via the CDNI Metadata interface the 774 information necessary to allow the dCDN to validate a Signed URI. 775 Events that pertain to URI Signing (e.g., request denial or delivery 776 after access authorization) need to be included in the logs 777 communicated through the CDNI Logging interface (Editor's Note: Is 778 this within the scope of the CDNI Logging interface?). 780 4.1. CDNI Control Interface 782 URI Signing has no impact on this interface. 784 4.2. CDNI Footprint & Capabilities Advertisement Interface 786 The CDNI Request Routing: Footprint and Capabilities Semantics 787 document [RFC8008] defines support for advertising CDNI Metadata 788 capabilities, via CDNI Payload Type. The CDNI Payload Type 789 registered in Section 6.1 can be used for capability advertisement. 791 4.3. CDNI Request Routing Redirection Interface 793 The CDNI Request Routing Redirection Interface [RFC7975] describes 794 the recursive request redirection method. For URI Signing, the uCDN 795 signs the URI provided by the dCDN. URI Signing therefore has has no 796 impact on this interface. 798 4.4. CDNI Metadata Interface 800 The CDNI Metadata Interface [RFC8006] describes the CDNI metadata 801 distribution needed to enable content acquisition and delivery. For 802 URI Signing, a new CDNI metadata object is specified. 804 The UriSigning Metadata object contains information to enable URI 805 signing and validation by a dCDN. The UriSigning properties are 806 defined below. 808 Property: enforce 810 Description: URI Signing enforcement flag. Specifically, this 811 flag indicates if the access to content is subject to URI 812 Signing. URI Signing requires the dCDN to ensure that the URI 813 must be signed and validated before delivering content. 814 Otherwise, the dCDN does not perform validation, regardless of 815 whether or not the URI is signed. 817 Type: Boolean 819 Mandatory-to-Specify: No. The default is true. 821 Property: issuers 823 Description: A list of valid Issuers against which the Issuer 824 claim in the signed JWT may be validated. 826 Type: Array of Strings 828 Mandatory-to-Specify: No. The default is an empty list. An 829 empty list means that any Issuer is acceptable. 831 Property: package-attribute 832 Description: The name to use for the URI Signing Package. 834 Type: String 836 Mandatory-to-Specify: No. Default is "URISigningPackage". 838 Property: jwt-header 840 Description: The header part of JWT that is used for generating 841 or validating a signed JWT when the JWT token in the URI 842 Signing Package does not contain a header part. 844 Type: String 846 Mandatory-to-Specify: No. A jwt-header is not essential for 847 all implementations of URI signing. 849 The following is an example of a URI Signing metadata payload with 850 all default values: 852 { 853 "generic-metadata-type": "MI.UriSigning" 854 "generic-metadata-value": {} 855 } 857 The following is an example of a URI Signing metadata payload with 858 explicit values: 860 { 861 "generic-metadata-type": "MI.UriSigning" 862 "generic-metadata-value": 863 { 864 "enforce": true, 865 "issuers": ["csp", "ucdn1", "ucdn2"], 866 "package-attribute": "usp" 867 } 868 } 870 4.5. CDNI Logging Interface 872 For URI Signing, the dCDN reports that enforcement of the access 873 control was applied to the request for content delivery. When the 874 request is denied due to enforcement of URI Signing, the reason is 875 logged. 877 The following CDNI Logging field for URI Signing SHOULD be supported 878 in the HTTP Request Logging Record as specified in CDNI Logging 879 Interface [RFC7937], using the new "cdni_http_request_v2" record-type 880 registered in Section 6.2.1. 882 o s-uri-signing (mandatory): 884 * format: 3DIGIT 886 * field value: this characterises the URI signing validation 887 performed by the Surrogate on the request. The allowed values 888 are: 890 + "000" : no signed JWT validation performed 892 + "200" : signed JWT validation performed and validated 894 + "400" : signed JWT validation performed and rejected because 895 of incorrect signature 897 + "401" : signed JWT validation performed and rejected because 898 of Expiration Time enforcement 900 + "402" : signed JWT validation performed and rejected because 901 of Client IP enforcement 903 + "403" : signed JWT validation performed and rejected because 904 of URI Regular Expression enforcement 906 + "404" : signed JWT validation performed and rejected because 907 of Issuer enforcement 909 + "405" : signed JWT validation performed and rejected because 910 of Not Before enforcement 912 + "500" : unable to perform signed JWT validation because of 913 malformed URI 915 * occurrence: there MUST be zero or exactly one instance of this 916 field. 918 o s-uri-signing-deny-reason (optional): 920 * format: QSTRING 922 * field value: a string for providing further information in case 923 the signed JWT was rejected, e.g., for debugging purposes. 925 * occurrence: there MUST be zero or exactly one instance of this 926 field. 928 5. URI Signing Message Flow 930 URI Signing supports both HTTP-based and DNS-based request routing. 931 JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of 932 representing claims to be transferred between two parties. The 933 claims in a signed JWT are encoded as a JSON object that is used as 934 the payload of a JSON Web Signature (JWS) structure or as the 935 plaintext of a JSON Web Encryption (JWE) structure, enabling the 936 claims to be digitally signed or integrity protected with a Message 937 Authentication Code (MAC) and/or encrypted. 939 5.1. HTTP Redirection 941 For HTTP-based request routing, a set of information that is unique 942 to a given end user content request is included in a signed JWT, 943 using key information that is specific to a pair of adjacent CDNI 944 hops (e.g., between the CSP and the uCDN or between the uCDN and a 945 dCDN). This allows a CDNI hop to ascertain the authenticity of a 946 given request received from a previous CDNI hop. 948 The URI signing method described below is based on the following 949 steps (assuming HTTP redirection, iterative request routing, and a 950 CDN path with two CDNs). Note that uCDN and uCDN are used 951 exchangeably. 953 End-User dCDN uCDN CSP 954 | | | | 955 | 1.CDNI FCI interface used to | | 956 | advertise URI Signing capability| | 957 | |------------------->| | 958 | | | | 959 | 2.Provides information to validate signed JWT | 960 | | |<-------------------| 961 | | | | 962 | 3.CDNI Metadata interface used to| | 963 | provide URI Signing attributes| | 964 | |<-------------------| | 965 |4.Authorization request | | 966 |------------------------------------------------------------->| 967 | | | [Apply distribution 968 | | | policy] | 969 | | | | 970 | | (ALT: Authorization decision) 971 |5.Request is denied | | | 972 |<-------------------------------------------------------------| 973 | | | | 974 |6.CSP provides signed URI | | 975 |<-------------------------------------------------------------| 976 | | | | 977 |7.Content request | | | 978 |---------------------------------------->| [Validate URI | 979 | | | signature] | 980 | | | | 981 | | (ALT: Validation result) | 982 |8.Request is denied | | | 983 |<----------------------------------------| | 984 | | | | 985 |9.Re-sign URI and redirect to | | 986 | dCDN (newly signed URI) | | 987 |<----------------------------------------| | 988 | | | | 989 |10.Content request | | | 990 |------------------->| [Validate URI | | 991 | | signature] | | 992 | | | | 993 | (ALT: Validation result) | | 994 |11.Request is denied| | | 995 |<-------------------| | | 996 | | | | 997 |12.Content delivery | | | 998 |<-------------------| | | 999 : : : : 1000 : (Later in time) : : : 1001 |13.CDNI Logging interface to include URI Signing information | 1002 | |------------------->| | 1004 Figure 3: HTTP-based Request Routing with URI Signing 1006 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1007 the dCDN advertises its capabilities including URI Signing 1008 support to the uCDN. 1010 2. CSP provides to the uCDN the information needed to validate 1011 signed JWTs from that CSP. For example, this information may 1012 include a key value. 1014 3. Using the CDNI Metadata interface, the uCDN communicates to a 1015 dCDN the information needed to validate signed JWTs from the 1016 uCDN for the given CSP. For example, this information may 1017 include the URI query string parameter name for the URI Signing 1018 Package Attribute. 1020 4. When a UA requests a piece of protected content from the CSP, 1021 the CSP makes a specific authorization decision for this unique 1022 request based on its personal distribution policy. 1024 5. If the authorization decision is negative, the CSP rejects the 1025 request and sends an error code (e.g., 403 Forbidden) in the 1026 HTTP response. 1028 6. If the authorization decision is positive, the CSP computes a 1029 Signed URI that is based on unique parameters of that request 1030 and conveys it to the end user as the URI to use to request the 1031 content. 1033 7. On receipt of the corresponding content request, the uCDN 1034 validates the signed JWT in the URI using the information 1035 provided by the CSP. 1037 8. If the validation is negative, the uCDN rejects the request and 1038 sends an error code (e.g., 403 Forbidden) in the HTTP response. 1040 9. If the validation is positive, the uCDN computes a Signed URI 1041 that is based on unique parameters of that request and provides 1042 it to the end user as the URI to use to further request the 1043 content from the dCDN. 1045 10. On receipt of the corresponding content request, the dCDN 1046 validates the signed JWT in the Signed URI using the information 1047 provided by the uCDN in the CDNI Metadata. 1049 11. If the validation is negative, the dCDN rejects the request and 1050 sends an error code (e.g., 403 Forbidden) in the HTTP response. 1052 12. If the validation is positive, the dCDN serves the request and 1053 delivers the content. 1055 13. At a later time, the dCDN reports logging events that include 1056 URI signing information. 1058 With HTTP-based request routing, URI Signing matches well the general 1059 chain of trust model of CDNI both with symmetric and asymmetric keys 1060 because the key information only needs to be specific to a pair of 1061 adjacent CDNI hops. 1063 5.2. DNS Redirection 1065 For DNS-based request routing, the CSP and uCDN must agree on a trust 1066 model appropriate to the security requirements of the CSP's 1067 particular content. Use of asymmetric public/private keys allows for 1068 unlimited distribution of the public key to dCDNs. However, if a 1069 shared secret key is preferred, then the CSP may want to restrict the 1070 distribution of the key to a (possibly empty) subset of trusted 1071 dCDNs. Authorized Delivery CDNs need to obtain the key information 1072 to validate the Signed URI. 1074 The URI signing method described below is based on the following 1075 steps (assuming iterative DNS request routing and a CDN path with two 1076 CDNs). 1078 End-User dCDN uCDN CSP 1079 | | | | 1080 | 1.CDNI FCI interface used to | | 1081 | advertise URI Signing capability| | 1082 | |------------------->| | 1083 | | | | 1084 | 2.Provides information to validate signed JWT | 1085 | | |<-------------------| 1086 | 3.CDNI Metadata interface used to| | 1087 | provide URI Signing attributes| | 1088 | |<-------------------| | 1089 |4.Authorization request | | 1090 |------------------------------------------------------------->| 1091 | | | [Apply distribution 1092 | | | policy] | 1093 | | | | 1094 | | (ALT: Authorization decision) 1095 |5.Request is denied | | | 1096 |<-------------------------------------------------------------| 1097 | | | | 1098 |6.Provides signed URI | | 1099 |<-------------------------------------------------------------| 1100 | | | | 1101 |7.DNS request | | | 1102 |---------------------------------------->| | 1103 | | | | 1104 |8.Redirect DNS to dCDN | | 1105 |<----------------------------------------| | 1106 | | | | 1107 |9.DNS request | | | 1108 |------------------->| | | 1109 | | | | 1110 |10.IP address of Surrogate | | 1111 |<-------------------| | | 1112 | | | | 1113 |11.Content request | | | 1114 |------------------->| [Validate URI | | 1115 | | signature] | | 1116 | | | | 1117 | (ALT: Validation result) | | 1118 |12.Request is denied| | | 1119 |<-------------------| | | 1120 | | | | 1121 |13.Content delivery | | | 1122 |<-------------------| | | 1123 : : : : 1124 : (Later in time) : : : 1125 |14.CDNI Logging interface to report URI Signing information | 1126 | |------------------->| | 1128 Figure 4: DNS-based Request Routing with URI Signing 1130 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1131 the dCDN advertises its capabilities including URI Signing 1132 support to the uCDN. 1134 2. CSP provides to the uCDN the information needed to validate 1135 cryptographic signatures from that CSP. For example, this 1136 information may include a key. 1138 3. Using the CDNI Metadata interface, the uCDN communicates to a 1139 dCDN the information needed to validate cryptographic signatures 1140 from the CSP (e.g., the URI query string parameter name for the 1141 URI Signing Package Attribute). In the case of symmetric key, 1142 the uCDN checks if the dCDN is allowed by CSP to obtain the 1143 shared secret key. 1145 4. When a UA requests a piece of protected content from the CSP, 1146 the CSP makes a specific authorization decision for this unique 1147 request based on its arbitrary distribution policy. 1149 5. If the authorization decision is negative, the CSP rejects the 1150 request. 1152 6. If the authorization decision is positive, the CSP computes a 1153 cryptographic signature that is based on unique parameters of 1154 that request and includes it in the URI provided to the end user 1155 to request the content. 1157 7. End user sends DNS request to the uCDN. 1159 8. On receipt of the DNS request, the uCDN redirects the request to 1160 the dCDN. 1162 9. End user sends DNS request to the dCDN. 1164 10. On receipt of the DNS request, the dCDN responds with IP address 1165 of one of its Surrogates. 1167 11. On receipt of the corresponding content request, the dCDN 1168 validates the cryptographic signature in the URI using the 1169 information provided by the uCDN in the CDNI Metadata. 1171 12. If the validation is negative, the dCDN rejects the request and 1172 sends an error code (e.g., 403) in the HTTP response. 1174 13. If the validation is positive, the dCDN serves the request and 1175 delivers the content. 1177 14. At a later time, dCDN reports logging events that includes URI 1178 signing information. 1180 With DNS-based request routing, URI Signing matches well the general 1181 chain of trust model of CDNI when used with asymmetric keys because 1182 the only key information that needs to be distributed across 1183 multiple, possibly untrusted, CDNI hops is the public key, which is 1184 generally not confidential. 1186 With DNS-based request routing, URI Signing does not match well the 1187 general chain of trust model of CDNI when used with symmetric keys 1188 because the symmetric key information needs to be distributed across 1189 multiple CDNI hops, to CDNs with which the CSP may not have a trust 1190 relationship. This raises a security concern for applicability of 1191 URI Signing with symmetric keys in case of DNS-based inter-CDN 1192 request routing. 1194 6. IANA Considerations 1196 6.1. CDNI Payload Type 1198 This document requests the registration of the following CDNI Payload 1199 Type under the IANA "CDNI Payload Type" registry: 1201 +---------------+---------------+ 1202 | Payload Type | Specification | 1203 +---------------+---------------+ 1204 | MI.UriSigning | RFCthis | 1205 +---------------+---------------+ 1207 [RFC Editor: Please replace RFCthis with the published RFC number for 1208 this document.] 1210 6.1.1. CDNI UriSigning Payload Type 1212 Purpose: The purpose of this payload type is to distinguish 1213 UriSigning MI objects (and any associated capability advertisement). 1215 Interface: MI/FCI 1217 Encoding: see Section 4.4 1219 6.2. CDNI Logging Record Type 1221 This document requests the registration of the following CDNI Logging 1222 record-type under the IANA "CDNI Logging record-types" registry: 1224 +----------------------+-----------+--------------------------------+ 1225 | record-types | Reference | Description | 1226 +----------------------+-----------+--------------------------------+ 1227 | cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | 1228 | | | Record version 1 for content | 1229 | | | delivery using HTTP, to | 1230 | | | include URI Signing logging | 1231 | | | fields | 1232 +----------------------+-----------+--------------------------------+ 1234 [RFC Editor: Please replace RFCthis with the published RFC number for 1235 this document.] 1237 6.2.1. CDNI Logging Record Version 2 for HTTP 1239 The "cdni_http_request_v2" record-type supports all of the fields 1240 supported by the "cdni_http_request_v1" record-type [RFC7937] plus 1241 the two additional fields "s-uri-signing" and "s-uri-signing-deny- 1242 reason", registered by this document in Section 6.3. The name, 1243 format, field value, and occurence information for the two new fields 1244 can be found in Section 4.5 of this document. 1246 6.3. CDNI Logging Field Names 1248 This document requests the registration of the following CDNI Logging 1249 fields under the IANA "CDNI Logging Field Names" registry: 1251 +---------------------------+-----------+ 1252 | Field Name | Reference | 1253 +---------------------------+-----------+ 1254 | s-uri-signing | RFCthis | 1255 | s-uri-signing-deny-reason | RFCthis | 1256 +---------------------------+-----------+ 1258 [RFC Editor: Please replace RFCthis with the published RFC number for 1259 this document.] 1261 6.4. CDNI URI Signing Signed Token Transport 1263 The IANA is requested to create a new "CDNI URI Signing Signed Token 1264 Transport" subregistry in the "Content Delivery Networks 1265 Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing 1266 Signed Token Transport" namespace defines the valid values that may 1267 be in the Signed Token Transport (cdnistt) JWT claim. Additions to 1268 the Signed Token Transport namespace conform to the "Specification 1269 Required" policy as defined in [RFC5226]. 1271 The following table defines the initial Enforcement Information 1272 Elements: 1274 +-------+-------------------------------------------+---------+ 1275 | Value | Description | RFC | 1276 +-------+-------------------------------------------+---------+ 1277 | 0 | Designates token transport is not enabled | RFCthis | 1278 | 1 | Designates token transport via cookie | RFCthis | 1279 +-------+-------------------------------------------+---------+ 1281 [RFC Editor: Please replace RFCthis with the published RFC number for 1282 this document.] 1284 [Ed Note: are there any special instructions to the designated expert 1285 reviewer?] 1287 6.5. JSON Web Token Claims Registration 1289 This specification registers the following Claims in the IANA "JSON 1290 Web Token Claims" registry [IANA.JWT.Claims] established by 1291 [RFC7519]. 1293 6.5.1. Registry Contents 1295 o Claim Name: "cdniv" 1296 o Claim Description: CDNI Claim Set Version 1297 o Change Controller: IESG 1298 o Specification Document(s): Section 2.1.8 of [[ this specification 1299 ]] 1301 o Claim Name: "cdniip" 1302 o Claim Description: CDNI IP Address 1303 o Change Controller: IESG 1304 o Specification Document(s): Section 2.1.9 of [[ this specification 1305 ]] 1307 o Claim Name: "cdniuc" 1308 o Claim Description: CDNI URI Container 1309 o Change Controller: IESG 1310 o Specification Document(s): Section 2.1.10 of [[ this specification 1311 ]] 1313 o Claim Name: "cdniets" 1314 o Claim Description: CDNI Expiration Time Setting for Signed Token 1315 Renewal 1316 o Change Controller: IESG 1317 o Specification Document(s): Section 2.1.11 of [[ this specification 1318 ]] 1320 o Claim Name: "cdnistt" 1321 o Claim Description: CDNI Signed Token Transport Method for Signed 1322 Token Renewal 1323 o Change Controller: IESG 1324 o Specification Document(s): Section 2.1.12 of [[ this specification 1325 ]] 1327 7. Security Considerations 1329 This document describes the concept of URI Signing and how it can be 1330 used to provide access authorization in the case of CDNI. The 1331 primary goal of URI Signing is to make sure that only authorized UAs 1332 are able to access the content, with a CSP being able to authorize 1333 every individual request. It should be noted that URI Signing is not 1334 a content protection scheme; if a CSP wants to protect the content 1335 itself, other mechanisms, such as DRM, are more appropriate. 1337 In general, it holds that the level of protection against 1338 illegitimate access can be increased by including more claims in the 1339 signed JWT. The current version of this document includes claims for 1340 enforcing Issuer, Client IP Address, Not Before time, and Expiration 1341 Time, however this list can be extended with other, more complex, 1342 attributes that are able to provide some form of protection against 1343 some of the vulnerabilities highlighted below. 1345 That said, there are a number of aspects that limit the level of 1346 security offered by URI Signing and that anybody implementing URI 1347 Signing should be aware of. 1349 o Replay attacks: A (valid) Signed URI may be used to perform replay 1350 attacks. The vulnerability to replay attacks can be reduced by 1351 picking a relatively short window between the Not Before time and 1352 Expiration Time attributes, although this is limited by the fact 1353 that any HTTP-based request needs a window of at least a couple of 1354 seconds to prevent a sudden network issues from preventing 1355 legitimate UAs access to the content. One may also reduce 1356 exposure to replay attacks by including a unique one-time access 1357 ID via the Nonce attribute (jti claim). Whenever the dCDN 1358 receives a request with a given unique ID, it adds that ID to the 1359 list of 'used' IDs. In the case an illegitimate UA tries to use 1360 the same URI through a replay attack, the dCDN can deny the 1361 request based on the already-used access ID. 1363 o Illegitimate clients behind a NAT: In cases where there are 1364 multiple users behind the same NAT, all users will have the same 1365 IP address from the point of view of the dCDN. This results in 1366 the dCDN not being able to distinguish between the different users 1367 based on Client IP Address and illegitimate users being able to 1368 access the content. One way to reduce exposure to this kind of 1369 attack is to not only check for Client IP but also for other 1370 attributes, e.g., attributes that can be found in HTTP headers. 1372 The shared key between CSP and uCDN may be distributed to dCDNs - 1373 including cascaded CDNs. Since this key can be used to legitimately 1374 sign a URL for content access authorization, it is important to know 1375 the implications of a compromised shared key. 1377 If a shared key usable for signing is compromised, an attacker can 1378 use it to perform a denial-of-service attack by forcing the CDN to 1379 evaluate prohibitively expensive regular expressions embedded in a 1380 cdniuc claim. As a result, compromised keys should be timely revoked 1381 in order to prevent exploitation. 1383 8. Privacy 1385 The privacy protection concerns described in CDNI Logging Interface 1386 [RFC7937] apply when the client's IP address (cdniip) is embedded in 1387 the Signed URI. For this reason, the mechanism described in 1388 Section 2 encrypts the Client IP before including it in the URI 1389 Signing Package (and thus the URL itself). 1391 9. Acknowledgements 1393 The authors would like to thank the following people for their 1394 contributions in reviewing this document and providing feedback: 1395 Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan 1396 York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana 1397 Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris 1398 Lemmons. 1400 10. Contributors 1402 In addition, the authors would also like to make special mentions for 1403 certain people who contributed significant sections to this document. 1405 o Matt Caulfield provided content for the CDNI Metadata Interface 1406 section. 1408 o Emmanuel Thomas provided content for HTTP Adaptive Streaming. 1410 o Matt Miller provided consultation on JWT usage as well as code to 1411 generate working JWT examples. 1413 11. References 1415 11.1. Normative References 1417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1418 Requirement Levels", BCP 14, RFC 2119, 1419 DOI 10.17487/RFC2119, March 1997, . 1422 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1423 IANA Considerations Section in RFCs", RFC 5226, 1424 DOI 10.17487/RFC5226, May 2008, . 1427 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1428 Keranen, A., and P. Hallam-Baker, "Naming Things with 1429 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1430 . 1432 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1433 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1434 2014, . 1436 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1437 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1438 . 1440 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1441 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1442 . 1444 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 1445 and R. Peterkofsky, "Content Distribution Network 1446 Interconnection (CDNI) Logging Interface", RFC 7937, 1447 DOI 10.17487/RFC7937, August 2016, . 1450 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1451 "Content Delivery Network Interconnection (CDNI) 1452 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1453 . 1455 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1456 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1457 May 2017, . 1459 11.2. Informative References 1461 [IANA.JWT.Claims] 1462 IANA, "JSON Web Token Claims", 1463 . 1465 [MPEG-DASH] 1466 ISO, "Information technology -- Dynamic adaptive streaming 1467 over HTTP (DASH) -- Part 1: Media presentation description 1468 and segment format", ISO/IEC 23009-1:2014, Edition 2, 05 1469 2014, . 1471 [PCRE839] Hazel, P., "Perl Compatible Regular Expressions", 1472 Version 8.39, June 2016, . 1474 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1475 Resource Identifier (URI): Generic Syntax", STD 66, 1476 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1477 . 1479 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1480 "Network Time Protocol Version 4: Protocol and Algorithms 1481 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1482 . 1484 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1485 Address Text Representation", RFC 5952, 1486 DOI 10.17487/RFC5952, August 2010, . 1489 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1490 Distribution Network Interconnection (CDNI) Problem 1491 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1492 2012, . 1494 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 1495 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 1496 Content Distribution Network Interconnection (CDNI)", 1497 RFC 6983, DOI 10.17487/RFC6983, July 2013, 1498 . 1500 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1501 "Framework for Content Distribution Network 1502 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1503 August 2014, . 1505 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1506 Network Interconnection (CDNI) Requirements", RFC 7337, 1507 DOI 10.17487/RFC7337, August 2014, . 1510 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1511 DOI 10.17487/RFC7517, May 2015, . 1514 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1515 "Request Routing Redirection Interface for Content 1516 Delivery Network (CDN) Interconnection", RFC 7975, 1517 DOI 10.17487/RFC7975, October 2016, . 1520 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1521 R., and K. Ma, "Content Delivery Network Interconnection 1522 (CDNI) Request Routing: Footprint and Capabilities 1523 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1524 . 1526 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 1527 RFC 8216, DOI 10.17487/RFC8216, August 2017, 1528 . 1530 Appendix A. Signed URI Package Example 1532 This section contains three examples of token usage: a simple example 1533 with only the required claim present, a complex example which 1534 demonstrates the full JWT claims set, including an encrypted Client 1535 IP (cdniip), and one that uses a Signed Token Renewal. 1537 Note: All of the examples have whitespace added to improve formatting 1538 and readability, but are not present in the generated content. 1540 All examples use the following JWK Set [RFC7517]: 1542 { "keys": [ 1543 { 1544 "kty": "EC", 1545 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1546 "use": "sig", 1547 "alg": "ES256", 1548 "crv": "P-256", 1549 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1550 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA" 1551 }, 1552 { 1553 "kty": "EC", 1554 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1555 "use": "sig", 1556 "alg": "ES256", 1557 "crv": "P-256", 1558 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1559 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", 1560 "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" 1561 }, 1562 { 1563 "kty": "oct", 1564 "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", 1565 "use": "enc", 1566 "alg": "A128GCM", 1567 "k": "4uFxxV7fhNmrtiah2d1fFg" 1568 } 1569 ]} 1571 Note: They are the public signing key, the private signing key, and 1572 the shared secret enctyption key, respectively. The public and 1573 private signing keys have the same fingerprint and only vary by the 1574 'd' parameter that is missing from the public signing key. 1576 A.1. Simple Example 1578 This example is a simple common usage example containing a minimal 1579 subset of claims that the authors find most useful. 1581 The JWT Claim Set before signing: 1583 { 1584 "exp": 1474243500, 1585 "iss": "uCDN Inc", 1586 "cdniuc": "uri:http://cdni.example/foo/bar" 1587 } 1589 The signed JWT: 1591 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1592 dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE0NzQyNDM1MDAsImlzcyI6InVDRE4gS 1593 W5jIiwiY2RuaXVjIjoidXJpOmh0dHA6Ly9jZG5pLmV4YW1wbGUvZm9vL2JhciJ9.4W 1594 xfA1ogQfeVLJYDtxrhilYctGR2KIIa1br5L6ZETTpn18_cNmsjQE4D7Cxs3tbbWAnI 1595 gVSIdcNVwBneluta5g 1597 A.2. Complex Example 1599 This example uses all fields except for those dealing with Signed 1600 Token Renewal, including Client IP (cdniip) and Subject (sub) which 1601 are encrpyted. This significantly increases the size of the signed 1602 JWT token. 1604 JWE for Client IP (cdniip) of [2001:db8::1/32]: 1606 eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj 1607 g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..hHQn6LM8Km95O0IE.KgJiy 1608 DRsW7QBQsDJrmS7Hg.cXRZ8sMJ8PKz3fnj6VXgvw 1610 JWE for Subject (sub) of "UserToken": 1612 eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj 1613 g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..ZH1hpBqhB8rgr3fD.3iEkR 1614 iaFkgwG.nzyjp7bZ3SJlYcDWv9irrQ 1616 The JWT Claim Set before signing: 1618 { 1619 "aud": "dCDN LLC", 1620 "sub": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm 1621 dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..ZH1hpBqhB8rg 1622 r3fD.3iEkRiaFkgwG.nzyjp7bZ3SJlYcDWv9irrQ", 1623 "cdniip": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQM 1624 mhmdm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..hHQn6LM8K 1625 m95O0IE.KgJiyDRsW7QBQsDJrmS7Hg.cXRZ8sMJ8PKz3fnj6VXgvw", 1626 "cdniv": 1, 1627 "exp": 1474243500, 1628 "iat": 1474243200, 1629 "iss": "uCDN Inc", 1630 "jti": "5DAafLhZAfhsbe", 1631 "nbf": 1474243200, 1632 "cdniuc": "uri-regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png" 1633 } 1635 The signed JWT: 1637 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1638 dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5SmhiR 1639 2NpT2lKa2FYSWlMQ0pyYVdRaU9pSm1MVmRpYW5oQ1F6TmtVSFZKTTJReU5HdFFNbWh 1640 tZG05ek4xRjZOamc0VlZScE5tRkNNR2hPT1RrNElpd2laVzVqSWpvaVFURXlPRWREV 1641 FNKOS4uWkgxaHBCcWhCOHJncjNmRC4zaUVrUmlhRmtnd0cubnp5anA3YlozU0psWWN 1642 EV3Y5aXJyUSIsImNkbmlpcCI6ImV5SmhiR2NpT2lKa2FYSWlMQ0pyYVdRaU9pSm1MV 1643 mRpYW5oQ1F6TmtVSFZKTTJReU5HdFFNbWhtZG05ek4xRjZOamc0VlZScE5tRkNNR2h 1644 PT1RrNElpd2laVzVqSWpvaVFURXlPRWREVFNKOS4uaEhRbjZMTThLbTk1TzBJRS5LZ 1645 0ppeURSc1c3UUJRc0RKcm1TN0hnLmNYUlo4c01KOFBLejNmbmo2VlhndnciLCJjZG5 1646 pdiI6MSwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6InVDR 1647 E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE0NzQyNDMyMDAsImN 1648 kbml1YyI6InVyaS1yZWdleDpodHRwOi8vY2RuaVxcLmV4YW1wbGUvZm9vL2Jhci9bM 1649 C05XXszfVxcLnBuZyJ9.3sKwFFMy7Hlbur1RzkeI0wDKerYXcrmBdfwJG7NP3TWS7a 1650 s52f8-F-wOFzFEIoX2UX3Z5Dinl6lbCQ__-pBgZw 1652 A.3. Signed Token Renewal Example 1654 This example uses fields for Signed Token Renewal. 1656 The JWT Claim Set before signing: 1658 { 1659 "cdniets": 30, 1660 "cdnistt": 1, 1661 "exp": 1474243500, 1662 "cdniuc": "uri-regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1663 } 1665 The signed JWT: 1667 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1668 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI 1669 joxNDc0MjQzNTAwLCJjZG5pdWMiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGF 1670 tcGxlL2Zvby9iYXIvWzAtOV17M31cXC50cyJ9.fL4S6f4FovPls_N-JBap7CKGsQsi 1671 Xhds2nFhz3EnIOVfDlrTt3mw6AA6SsHnc2fu6bqZP_3YOdwOYFYjDPTYfg 1673 Once the server validates the signed JWT it will return a new signed 1674 JWT with an updated expiry time (exp) as shown below. Note the 1675 expiry time is increased by the expiration time setting (cdniets) 1676 value. 1678 The JWT Claim Set before signing: 1680 { 1681 "cdniets": 30, 1682 "cdnistt": 1, 1683 "exp": 1474243530, 1684 "cdniuc": "uri-regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1685 } 1687 The signed JWT: 1689 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1690 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI 1691 joxNDc0MjQzNTMwLCJjZG5pdWMiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGF 1692 tcGxlL2Zvby9iYXIvWzAtOV17M31cXC50cyJ9.Zi-Xq-0ZrZ5uL2F5YCxZMXWWnaM6 1693 wS9-x9eRu5UC6WgbMBQ0yH7lJNe7UG_5Ge-QPuRggm9tz1AF4S_Ty8H9Ig 1695 Authors' Addresses 1697 Ray van Brandenburg 1698 Tiledmedia 1699 Anna van Buerenplein 1 1700 Den Haag 2595DA 1701 The Netherlands 1703 Phone: +31 88 866 7000 1704 Email: ray@tiledmedia.com 1706 Kent Leung 1707 Cisco Systems, Inc. 1708 3625 Cisco Way 1709 San Jose, CA 95134 1710 United States 1712 Phone: +1 408 526 5030 1713 Email: kleung@cisco.com 1714 Phil Sorber 1716 Email: sorber@apache.org