idnits 2.17.1 draft-ietf-cdni-uri-signing-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 295 has weird spacing: '...I(after v ...' -- The document date (May 7, 2019) is 1816 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 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 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: November 8, 2019 Cisco Systems, Inc. 6 P. Sorber 7 Apple, Inc. 8 May 7, 2019 10 URI Signing for CDN Interconnection (CDNI) 11 draft-ietf-cdni-uri-signing-18 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) 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 November 8, 2019. 41 Copyright Notice 43 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . 13 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 . . . . 14 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 . . . 18 88 3.3.1. Support for cross-domain redirection . . . . . . . . 18 89 4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 18 90 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . 21 95 5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 22 96 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 22 97 5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 25 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 99 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . 29 103 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 29 104 6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 29 105 6.5. JSON Web Token Claims Registration . . . . . . . . . . . 30 106 6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 30 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 108 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 109 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 110 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 111 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 112 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 113 11.2. Informative References . . . . . . . . . . . . . . . . . 34 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 a CSP's 139 distribution policies. 141 Specifically, the CDNI Framework [RFC7336] states: 143 The CSP may also trust the CDN operator to perform actions such as 144 delegating traffic to additional downstream CDNs, and to enforce 145 per-request authorization performed by the CSP using techniques 146 such as URI signing. 148 In particular, the following requirement is listed in the CDNI 149 Requirements [RFC7337]: 151 MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of 152 authorization checks and verification that are to be performed by 153 the Surrogate before delivery. For example, this could 154 potentially include the need to verify information (e.g., Expiry 155 time, Client IP address) required for access authorization. 157 This document defines a method of signing URIs that allows Surrogates 158 in interconnected CDNs to enforce a per-request authorization 159 initiated by the CSP. Splitting the role of initiating per-request 160 authorization by the CSP and the role of verifying this authorization 161 by the CDN allows any arbitrary distribution policy to be enforced 162 across CDNs without the need of CDNs to have any awareness of the 163 specific CSP distribution policies. 165 The method is implemented using Signed JSON Web Tokens (JWTs) 166 [RFC7519]. 168 1.1. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in BCP 173 14 [RFC2119] [RFC8174] when, and only when, they appear in all 174 capitals, as shown here. 176 This document uses the terminology defined in the CDNI Problem 177 Statement [RFC6707]. 179 This document also uses the terminology of the JSON Web Token (JWT) 180 [RFC7519]. 182 In addition, the following terms are used throughout this document: 184 o Signed URI: A URI for which a signed JWT is provided. 186 o Target CDN URI: URI created by the CSP to direct a UA towards the 187 Upstream CDN (uCDN). The Target CDN URI can be signed by the CSP 188 and verified by the uCDN and possibly further Downstream CDNs 189 (dCDNs). 191 o Redirection URI: URI created by the uCDN to redirect a UA towards 192 the dCDN. The Redirection URI can be signed by the uCDN and 193 verified by the dCDN. In a cascaded CDNI scenario, there can be 194 more than one Redirection URI. 196 o Signed Token Renewal: A series of signed JWTs that are used for 197 subsequent access to a set of related resources in a CDN, such as 198 a set of HTTP Adaptive Streaming files. Every time a signed JWT 199 is used to access a particular resource, a new signed JWT is sent 200 along with the resource that can be used to request the next 201 resource in the set. When generating a new signed JWT in Signed 202 Token Renewal, parameters are carried over from one signed JWT to 203 the next. 205 1.2. Background and overview on URI Signing 207 A CSP and CDN are assumed to have a trust relationship that enables 208 the CSP to authorize access to a content item by including a set of 209 claims in the form of a signed JWT in the URI before redirecting a UA 210 to the CDN. Using these attributes, it is possible for a CDN to 211 check an incoming content request to see whether it was authorized by 212 the CSP (e.g., based on the UA's IP address or a time window). To 213 prevent the UA from altering the claims a JWT MUST be signed. 215 Figure 1, shown below, presents an overview of the URI Signing 216 mechanism in the case of a CSP with a single CDN. When the UA 217 browses for content on CSP's website (#1), it receives HTML web pages 218 with embedded content URIs. Upon requesting these URIs, the CSP 219 redirects to a CDN, creating a Target CDN URI (#2) (alternatively, 220 the Target CDN URI itself is embedded in the HTML). The Target CDN 221 URI is the Signed URI which may include the IP address of the UA and/ 222 or a time window. The signed URI always contains a signed JWT 223 generated by the CSP using a shared secret or private key. Once the 224 UA receives the response with the Signed URI, it sends a new HTTP 225 request using the Signed URI to the CDN (#3). Upon receiving the 226 request, the CDN authenticates the Signed URI by verifying the signed 227 JWT. If applicable, the CDN checks whether the source IP address of 228 the HTTP request matches the one in the Signed URI and/or if the time 229 window is still valid. After these claims are verified, the CDN 230 delivers the content (#4). 232 -------- 233 / \ 234 | CSP |< * * * * * * * * * * * 235 \ / Trust * 236 -------- relationship * 237 ^ | * 238 | | * 239 1. Browse | | 2. Signed * 240 for | | URI * 241 content | | * 242 | v v 243 +------+ 3. Signed URI -------- 244 | User |----------------->/ \ 245 | Agent| | CDN | 246 | |<-----------------\ / 247 +------+ 4. Content -------- 248 Delivery 250 Figure 1: Figure 1: URI Signing in a CDN Environment 252 1.3. CDNI URI Signing Overview 254 In a CDNI environment, as shown in Figure 2 below, URI Signing 255 operates the same way in the initial steps #1 and #2 but the later 256 steps involve multiple CDNs delivering the content. The main 257 difference from the single CDN case is a redirection step between the 258 uCDN and the dCDN. In step #3, the UA may send an HTTP request or a 259 DNS request. Depending on whether HTTP-based or DNS-based request 260 routing is used. The uCDN responds by directing the UA towards the 261 dCDN using either a Redirection URI (i.e., a Signed URI generated by 262 the uCDN) or a DNS reply, respectively (#4). Once the UA receives 263 the response, it sends the Redirection URI/Target CDN URI to the dCDN 264 (#5). The received URI is verified by the dCDN before delivering the 265 content (#6). Note: The CDNI call flows are covered in Detailed URI 266 Signing Operation (Section 5). 268 +-------------------------+ 269 |Request Redirection Modes| 270 +-------------------------+ 271 | a) HTTP | 272 | b) DNS | 273 +-------------------------+ 274 -------- 275 / \< * * * * * * * * * * * * * * 276 | CSP |< * * * * * * * * * * * * 277 \ / Trust * * 278 -------- relationship * * 279 ^ | * * 280 | | 2. Signed * * 281 1. Browse | | URI in * * 282 for | | HTML * * 283 content | | * * 284 | v 3.a)Signed URI v * 285 +------+ b)DNS request -------- * Trust 286 | User |----------------->/ \ * relationship 287 | Agent| | uCDN | * (optional) 288 | |<-----------------\ / * 289 +------+ 4.a)Redirection URI------- * 290 ^ | b)DNS Reply ^ * 291 | | * * 292 | | Trust relationship * * 293 | | * * 294 6. Content | | 5.a)Redirection URI * * 295 delivery | | b)Signed URI(after v v 296 | | DNS exchange) -------- 297 | +---------------------->/ \ [May be 298 | | dCDN | cascaded 299 +--------------------------\ / CDNs] 300 -------- 302 Figure 2: URI Signing in a CDNI Environment 304 The trust relationships between CSP, uCDN, and dCDN have direct 305 implications for URI Signing. In the case shown in Figure 2, the CSP 306 has a trust relationship with the uCDN. The delivery of the content 307 may be delegated to a dCDN, which has a relationship with the uCDN 308 but may have no relationship with the CSP. 310 In CDNI, there are two methods for request routing: DNS-based and 311 HTTP-based. For DNS-based request routing, the Signed URI (i.e., the 312 Target CDN URI) provided by the CSP reaches the dCDN directly. In 313 the case where the dCDN does not have a trust relationship with the 314 CSP, this means that either an asymmetric public/private key method 315 needs to be used for computing the signed JWT (because the CSP and 316 dCDN are not able to exchange symmetric shared secret keys), or the 317 CSP needs to allow the uCDN to redistribute shared keys to a subset 318 of their dCDNs. 320 For HTTP-based request routing, the Signed URI (i.e., the Target CDN 321 URI) provided by the CSP reaches the uCDN. After this URI has been 322 verified by the uCDN, the uCDN creates and signs a new Redirection 323 URI, redirecting the UA to the dCDN. Since this new URI can have a 324 new signed JWT, the relationship between the dCDN and CSP is not 325 relevant. Because a relationship between uCDN and dCDN always 326 exists, either asymmetric public/private keys or symmetric shared 327 secret keys can be used for URI Signing with HTTP-based request 328 routing. Note that the signed Redirection URI MUST maintain the same 329 (or higher) level of security as the original Signed URI. 331 +------------------------------------------+ 332 | Mode | Asymmetric Key | Symmetric Key | 333 +------------------------------------------+ 334 |HTTP |Public key (uCDN)|Shared key (uCDN)| 335 |DNS |Public key (CSP) |Shared key (CSP) | 336 +------------------------------------------+ 338 Figure 3: CDNI URI Signing Key 340 Two types of keys can be used for URI Signing: asymmetric keys and 341 symmetric keys. Asymmetric keys are based on a public/private key 342 pair mechanism and always contain a private key known only to the 343 entity signing the URI (either CSP or uCDN) and a public key for the 344 verification of the Signed URI. With symmetric keys, the same key is 345 used by both the signing entity for signing the URI as well as by the 346 verifying entity for verifying the Signed URI. Regardless of the 347 type of keys used, the verifying entity has to obtain the key (either 348 the public or the symmetric key). There are very different 349 requirements (outside the scope of this document) for distributing 350 asymmetric keys and symmetric keys. Key distribution for symmetric 351 keys requires confidentiality to prevent third parties from getting 352 access to the key, since they could then generate valid Signed URIs 353 for unauthorized requests. Key distribution for asymmetric keys does 354 not require confidentiality since public keys can typically be 355 distributed openly (because they cannot be used to sign URIs) and 356 private keys are kept secret by the URI signer. 358 1.4. URI Signing in a non-CDNI context 360 While the URI signing method defined in this document was primarily 361 created for the purpose of allowing URI Signing in CDNI scenarios, 362 i.e., between a uCDN and a dCDN, there is nothing in the defined URI 363 Signing method that precludes it from being used in a non-CDNI 364 context. As such, the described mechanism could be used in a single- 365 CDN scenario such as shown in Figure 1 in Section 1.2, for example to 366 allow a CSP that uses different CDNs to only have to implement a 367 single URI Signing mechanism. 369 2. JWT Format and Processing Requirements 371 The concept behind URI Signing is based on embedding a signed JSON 372 Web Token (JWT) [RFC7519] in an HTTP or HTTPS URI [RFC7230] 373 (Section 2.7). The signed JWT contains a number of claims that can 374 be verified to ensure the UA has legitimate access to the content. 376 This document specifies the following attribute for embedding a 377 signed JWT in a Target CDN URI or Redirection URI: 379 o URI Signing Package (URISigningPackage): The URI attribute that 380 encapsulates all the URI Signing claims in a signed JWT encoded 381 format. This attribute is exposed in the Signed URI as a URI 382 query parameter or as a URL path parameter. 384 The parameter name of the URI Signing Package Attribute is defined in 385 the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is 386 not used, or does not include a parameter name for the URI Signing 387 Package Attribute, the parameter name can be set by configuration 388 (out of scope of this document). 390 The URI Signing Package will be found by searching the URI, left-to- 391 right, for the following sequence: 393 o a reserved character (as defined in [RFC3986] Section 2.2), 395 o the URI Signing Package Attribute name, 397 o if the last character of the URI Signing Package Attribute name is 398 not a reserved character, an equal symbol ('='), 400 o and a sequence of zero or more non-reserved characters that will 401 be interpreted as a signed JWT, 403 o terminated by either a reserved character or the end of the URI. 405 The first such match will be taken to provide the signed JWT; the URI 406 will not be searched for multiple signed JWTs. 408 2.1. JWT Claims 410 This section identifies the set of claims that can be used to enforce 411 the CSP distribution policy. New claims can be introduced in the 412 future to extend the distribution policy capabilities. 414 In order to provide distribution policy flexibility, the exact subset 415 of claims used in a given signed JWT is a runtime decision. Claim 416 requirements are defined in the CDNI Metadata (Section 4.4). If the 417 CDNI Metadata interface is not used, or does not include claim 418 requirements, the claim requirements can be set by configuration (out 419 of scope of this document). 421 The following claims (where the "JSON Web Token Claims" registry 422 claim name is specified in parenthesis below) are used to enforce the 423 distribution policies. All of the listed claims are mandatory to 424 implement in a URI Signing implementation, but are not mandatory to 425 use in a given signed JWT. (The "optional" and "mandatory" 426 identifiers in square brackets refer to whether or not a given claim 427 MUST be present in a URI Signing JWT.) A CDN MUST be able to parse 428 and process all of the claims listed below. 430 Note: See the Security Considerations (Section 7) section on the 431 limitations of using an expiration time and client IP address for 432 distribution policy enforcement. 434 2.1.1. Issuer (iss) claim 436 Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1 437 MUST be followed. This claim MAY be used to verify authorization of 438 the issuer of a signed JWT and also MAY be used to confirm that the 439 indicated key was provided by said issuer. If the CDN verifying the 440 signed JWT does not support Issuer verification, or if the Issuer in 441 the signed JWT does not match the list of known acceptable Issuers, 442 the CDN MUST reject the request. If the received signed JWT contains 443 an Issuer claim, then any JWT subsequently generated for CDNI 444 redirection MUST also contain an Issuer claim, and the Issuer value 445 MUST be updated to identify the redirecting CDN. If the received 446 signed JWT does not contain an Issuer claim, an Issuer claim MAY be 447 added to a signed JWT generated for CDNI redirection. 449 2.1.2. Subject (sub) claim 451 Subject (sub) [optional] - The semantics in [RFC7519] Section 4.1.2 452 MUST be followed. If this claim is used, it MUST be a JSON Web 453 Encryption (JWE [RFC7516]) Object in compact serialization form, 454 because it contains personally identifiable information. This claim 455 contains information about the subject (for example, a user or an 456 agent) that MAY be used to verify the signed JWT. If the received 457 signed JWT contains a Subject claim, then any JWT subsequently 458 generated for CDNI redirection MUST also contain a Subject claim, and 459 the Subject value MUST be the same as in the received signed JWT. A 460 signed JWT generated for CDNI redirection MUST NOT add a Subject 461 claim if no Subject claim existed in the received signed JWT. 463 2.1.3. Audience (aud) claim 465 Audience (aud) [optional] - The semantics in [RFC7519] Section 4.1.3 466 MUST be followed. This claim is used to ensure that the CDN verifing 467 the JWT is an intended recipient of the request. The claim should 468 contain an identity on behalf of whom the CDN can verify the token 469 (e.g., the CSP or any uCDN in the chain). A dCDN MAY modify the 470 claim as long it can generate a valid signature. 472 2.1.4. Expiry Time (exp) claim 474 Expiry Time (exp) [optional] - The semantics in [RFC7519] 475 Section 4.1.4 MUST be followed, though URI Signing implementations 476 MUST NOT allow for any time synchronization "leeway". Note: The time 477 on the entities that generate and verify the signed URI SHOULD be in 478 sync. In the CDNI case, this means that CSP, uCDN, and dCDN servers 479 need to be time-synchronized. It is RECOMMENDED to use NTP [RFC5905] 480 for time synchronization. If the CDN verifying the signed JWT does 481 not support Expiry Time verification, or if the Expiry Time in the 482 signed JWT corresponds to a time equal to or earlier than the time of 483 the content request, the CDN MUST reject the request. If the 484 received signed JWT contains a Expiry Time claim, then any JWT 485 subsequently generated for CDNI redirection MUST also contain an 486 Expiry Time claim, and the Expiry Time value MUST be the same as in 487 the received signed JWT. A signed JWT generated for CDNI redirection 488 MUST NOT add an Expiry Time claim if no Expiry Time claim existed in 489 the received signed JWT. 491 2.1.5. Not Before (nbf) claim 493 Not Before (nbf) [optional] - The semantics in [RFC7519] 494 Section 4.1.5 MUST be followed, though URI Signing implementations 495 MUST NOT allow for any time synchronization "leeway". Note: The time 496 on the entities that generate and verify the signed URI SHOULD be in 497 sync. In the CDNI case, this means that the CSP, uCDN, and dCDN 498 servers need to be time-synchronized. It is RECOMMENDED to use NTP 499 [RFC5905] for time synchronization. If the CDN verifying the signed 500 JWT does not support Not Before time verification, or if the Not 501 Before time in the signed JWT corresponds to a time later than the 502 time of the content request, the CDN MUST reject the request. If the 503 received signed JWT contains a Not Before time claim, then any JWT 504 subsequently generated for CDNI redirection MUST also contain a Not 505 Before time claim, and the Not Before time value MUST be the same as 506 in the received signed JWT. A signed JWT generated for CDNI 507 redirection MUST NOT add a Not Before time claim if no Not Before 508 time claim existed in the received signed JWT. 510 2.1.6. Issued At (iat) claim 512 Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6 513 MUST be followed. Note: The time on the entities that generate and 514 verify the signed URI SHOULD be in sync. In the CDNI case, this 515 means that CSP, uCDN, and dCDN servers need to be time-synchronized. 516 It is RECOMMENDED to use NTP [RFC5905] for time synchronization. If 517 the received signed JWT contains an Issued At claim, then any JWT 518 subsequently generated for CDNI redirection MUST also contain an 519 Issued At claim, and the Issuer value MUST be updated to identify the 520 time the new JWT was generated. If the received signed JWT does not 521 contain an Issued At claim, an Issued At claim MAY be added to a 522 signed JWT generated for CDNI redirection. 524 2.1.7. Nonce (jti) claim 526 Nonce (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 527 MUST be followed. A Nonce can be used to prevent replay attacks if 528 the CDN stores a list of all previously used Nonce values, and 529 verifies that the Nonce in the current JWT has never been used 530 before. If the signed JWT contains a Nonce claim and the CDN 531 verifying the signed JWT either does not support Nonce storage or has 532 previously seen the nonce used in a request for the same content, 533 then the CDN MUST reject the request. If the received signed JWT 534 contains a Nonce claim, then any JWT subsequently generated for CDNI 535 redirection MUST also contain a Nonce claim, and the Nonce value MUST 536 be the same as in the received signed JWT. If the received signed 537 JWT does not contain a Nonce claim, a Nonce claim MUST NOT be added 538 to a signed JWT generated for CDNI redirection. 540 2.1.8. CDNI Claim Set Version (cdniv) claim 542 CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set 543 Version (cdniv) claim provides a means within a signed JWT to tie the 544 claim set to a specific version of this specification. The cdniv 545 claim is intended to allow changes in and facilitate upgrades across 546 specifications. The type is JSON integer and the value MUST be set 547 to "1", for this version of the specification. In the absence of 548 this claim, the value is assumed to be "1". For future versions this 549 claim will be mandatory. Implementations MUST reject signed JWTs 550 with unsupported CDNI Claim Set versions. 552 2.1.9. CDNI Critical Claims Set (cdnicrit) claim 554 CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical 555 Claims Set (cdnicrit) claim indicates that extensions to this 556 specification are being used that MUST be understood and processed. 557 Its value is a comma separated listing of claims in the Signed JWT 558 that use those extensions. If any of the listed extension claims are 559 not understood and supported by the recipient, then the Signed JWT is 560 invalid. Producers MUST NOT include claim names defined by this 561 specification, duplicate names, or names that do not occur as claim 562 names within the Signed JWT in the cdnicrit list. Producers MUST NOT 563 use the empty list "" as the cdnicrit value. Recipients MAY consider 564 the Signed JWT to be invalid if the cdnicrit list contains any claim 565 names defined by this specification or if any other constraints on 566 its use are violated. This claim MUST be understood and processed by 567 all implementations. 569 2.1.10. Client IP (cdniip) claim 571 Client IP (cdniip) [optional] - The Client IP (cdniip) claim hold an 572 IP address or IP prefix for which the Signed URI is valid. This is 573 represented in CIDR notation, with dotted decimal format for IPv4 574 addresses [RFC0791] or canonical text representation for IPv6 575 addresses [RFC5952]. The request MUST be rejected if sourced from a 576 client outside of the specified IP range. Since the client IP is 577 considered personally identifiable information this field MUST be a 578 JSON Web Encryption (JWE [RFC7516]) Object in compact serialization 579 form. If the CDN verifying the signed JWT does not support Client IP 580 verification, or if the Client IP in the signed JWT does not match 581 the source IP address in the content request, the CDN MUST reject the 582 request. The type of this claim is a JSON string that contains the 583 JWE. If the received signed JWT contains a Client IP claim, then any 584 JWT subsequently generated for CDNI redirection MUST also contain a 585 Client IP claim, and the Client IP value MUST be the same as in the 586 received signed JWT. A signed JWT generated for CDNI redirection 587 MUST NOT add a Client IP claim if no Client IP claim existed in the 588 received signed JWT. 590 2.1.11. CDNI URI Container (cdniuc) claim 592 URI Container (cdniuc) [optional] - The URI Container (cdniuc) holds 593 the URI representation before a URI Signing Package is added. This 594 representation can take one of several forms detailed in 595 Section 2.1.15. If the URI Container used in the signed JWT does not 596 match the URI of the content request, the CDN verifying the signed 597 JWT MUST reject the request. When comparing the URI, the percent 598 encoded form as defined in [RFC3986] Section 2.1 MUST be used. When 599 redirecting a URI, the CDN generating the new signed JWT MAY change 600 the URI Container to comport with the URI being used in the 601 redirection. 603 2.1.12. CDNI Expiration Time Setting (cdniets) claim 605 CDNI Expiration Time Setting (cdniets) [optional] - The CDNI 606 Expiration Time Setting (cdniets) claim provides a means for setting 607 the value of the Expiry Time (exp) claim when generating a subsequent 608 signed JWT in Signed Token Renewal. Its type is a JSON numeric 609 value. It denotes the number of seconds to be added to the time at 610 which the JWT is verified that gives the value of the Expiry Time 611 (exp) claim of the next signed JWT. The CDNI Expiration Time Setting 612 (cdniets) SHOULD NOT be used when not using Signed Token Renewal and 613 MUST be present when using Signed Token Renewal. 615 2.1.13. CDNI Signed Token Transport (cdnistt) claim 617 CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed 618 Token Transport (cdnistt) claim provides a means of signalling the 619 method through which a new signed JWT is transported from the CDN to 620 the UA and vice versa for the purpose of Signed Token Renewal. Its 621 type is a JSON integer. Values for this claim are defined in 622 Section 6.4. If using this claim you MUST also specify a CDNI 623 Expiration Time Setting (cdniets) as noted above. 625 2.1.14. CDNI Signed Token Depth (cdnistd) claim 627 CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token 628 Depth (cdnistd) claim is used to associate a subsequent signed JWT, 629 generated as the result of a CDNI Signed Token Transport claim, with 630 a specific URI subset. Its type is a JSON integer. Signed JWTs MUST 631 NOT use a negative value for the CDNI Signed Token Depth claim. 633 If the transport used for Signed Token Transport allows the CDN to 634 associate the path component of a URI with tokens (e.g., an HTTP 635 Cookie Path as described in section 4.1.2.4 of [RFC6265]), the CDNI 636 Signed Token Depth value is the number of path segments that should 637 be considered significant for this association. A CDNI Signed Token 638 Depth of zero means that the client SHOULD be directed to return the 639 token with requests for any path. If the CDNI Signed Token Depth is 640 greater than zero, then the client SHOULD be directed to return the 641 token for future requests wherein the first CDNI Signed Token Depth 642 segments of the path match the first CDNI Signed Token Depth segments 643 of the signed URI path. This matching MUST use the URI with the 644 token removed, as specified in Section 2.1.15. 646 If the URI path to match contains fewer segments than the CDNI Signed 647 Token Depth claim, a signed JWT MUST NOT be generated for the 648 purposes of Signed Token Renewal. If the CDNI Signed Token Depth 649 claim is omitted, it means the same thing as if its value were zero. 650 If the received signed JWT contains a CDNI Signed Token Depth claim, 651 then any JWT subsequently generated for CDNI redirection or Signed 652 Token Transport MUST also contain a CDNI Signed Token Depth claim, 653 and the value MUST be the same as in the received signed JWT. 655 2.1.15. URI Container Forms 657 The URI Container (cdniuc) claim takes one of the following forms: 658 'hash:' or 'regex:'. More forms may be added in the future to extend 659 the capabilities. 661 Before comparing a URI with contents of this container, the following 662 steps MUST be performed: 664 o Prior to verification, remove the signed JWT from the URI. This 665 removal is only for the purpose of determining if the URI matches; 666 all other purposes will use the original URI. If the signed JWT 667 is terminated by anything other than a sub-delimiter (as definined 668 in [RFC3986] Section 2.2), everything from the reserved character 669 (as defined in [RFC3986] Section 2.2) that precedes the URI 670 Signing Package Attribute to the last character of the signed JWT 671 will be removed, inclusive. Otherwise, everything from the first 672 character of the URI Signing Package Attribute to the sub- 673 delimiter that terminates the signed JWT will be removed, 674 inclusive. 676 o Normalize the URI according to section 2.7.3 [RFC7230] and 677 sections 6.2.2 and 6.2.3 [RFC3986]. This applies to both 678 generation and verification of the signed JWT. 680 2.1.15.1. URI Hash Container (hash:) 682 Prefixed with 'hash:', this string is a URL Segment form ([RFC6920] 683 Section 5) of the URI. 685 2.1.15.2. URI Regular Expression Container (regex:) 687 Prefixed with 'regex:', this string is any POSIX Section 9 [POSIX.1] 688 Extended Regular Expression compatible regular expression used to 689 match against the requested URI. These regular expressions MUST be 690 evaluated in the POSIX locale (POSIX Section 7.2 [POSIX.1]). 692 Note: Because '\' has special meaning in JSON [RFC8259] as the escape 693 character within JSON strings, the regular expression character '\' 694 MUST be escaped as '\\'. 696 An example of a 'regex:' is the following: 698 [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)? 700 Note: Due to computational complexity of executing arbitrary regular 701 expressions, it is RECOMMENDED to only execute after verifying the 702 JWT to ensure its authenticity. 704 2.2. JWT Header 706 The header of the JWT MAY be passed via the CDNI Metadata interface 707 instead of being included in the URISigningPackage. The header value 708 must be transmitted in the serialized encoded form and prepended to 709 the JWT payload and signature passed in the URISigningPackage prior 710 to verification. This reduces the size of the signed JWT token. 712 3. URI Signing Token Renewal 714 3.1. Overview 716 For content that is delivered via HTTP in a segmented fashion, such 717 as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216], 718 special provisions need to be made in order to ensure URI Signing can 719 be applied. In general, segmented protocols work by breaking large 720 objects (e.g., videos) into a sequence of small independent segments. 721 Such segments are then referenced by a separate manifest file, which 722 either includes a list of URLs to the segments or specifies an 723 algorithm through which a User Agent can construct the URLs to the 724 segments. Requests for segments therefore originate from the 725 manifest file and, unless the URLs in the manifest file point to the 726 CSP, are not subjected to redirection and URI Signing. This opens up 727 a vulnerability to malicious User Agents sharing the manifest file 728 and deep-linking to the segments. 730 One method for dealing with this vulnerability would be to include, 731 in the manifest itself, Signed URIs that point to the individual 732 segments. There exist a number of issues with that approach. First, 733 it requires the CDN delivering the manifest to rewrite the manifest 734 file for each User Agent, which would require the CDN to be aware of 735 the exact segmentation protocol used. Secondly, it could also 736 require the expiration time of the Signed URIs to be valid for an 737 extended duration if the content described by the manifest is meant 738 to be consumed in real time. For instance, if the manifest file were 739 to contain a segmented video stream of more than 30 minutes in 740 length, Signed URIs would require to be valid for a at least 30 741 minutes, thereby reducing their effectiveness and that of the URI 742 Signing mechanism in general. For a more detailed analysis of how 743 segmented protocols such as HTTP Adaptive Streaming protocols affect 744 CDNI, see Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. 746 The method described in this section allows CDNs to use URI Signing 747 for segmented content without having to include the Signed URIs in 748 the manifest files themselves. 750 3.2. Signed Token Renewal mechanism 752 In order to allow for effective access control of segmented content, 753 the URI signing mechanism defined in this section is based on a 754 method through which subsequent segment requests can be linked 755 together. As part of the JWT verification procedure, the CDN can 756 generate a new signed JWT that the UA can use to do a subsequent 757 request. More specifically, whenever a UA successfully retrieves a 758 segment, it receives, in the HTTP 2xx Successful message, a signed 759 JWT that it can use whenever it requests the next segment. As long 760 as each successive signed JWT is correctly verified before a new one 761 is generated, the model is not broken and the User Agent can 762 successfully retrieve additional segments. Given the fact that with 763 segmented protocols, it is usually not possible to determine a priori 764 which segment will be requested next (i.e., to allow for seeking 765 within the content and for switching to a different representation), 766 the Signed Token Renewal uses the URI Regular Expression Container 767 scoping mechanisms in the URI Container (cdniuc) claim to allow a 768 signed JWT to be valid for more than one URL. 770 In order for this renewal of signed JWTs to work, it is necessary for 771 a UA to extract the signed JWT from the HTTP 2xx Successful message 772 of an earlier request and use it to retrieve the next segment. The 773 exact mechanism by which the client does this is outside the scope of 774 this document. However, in order to also support legacy UAs that do 775 not include any specific provisions for the handling of signed JWTs, 776 the following section defines a mechanism using HTTP Cookies 777 [RFC6265] that allows such UAs to support the concept of renewing 778 signed JWTs without requiring any additional UA support. 780 3.2.1. Required Claims 782 The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12) 783 MUST both be present for Signed Token Renewal. You MAY set cdnistt 784 to a value of '0' to mean no Signed Token Renewal, but you still MUST 785 have a corresponding cdniets that verifies as a JSON number. 786 However, if you do not want to use Signed Token Renewal, it is 787 RECOMMENDED to simply omit both. 789 3.3. Communicating a signed JWTs in Signed Token Renewal 791 This section assumes the value of the CDNI Signed Token Transport 792 (cdnistt) claim has been set to 1. Other values of cdnistt are out 793 of scope of this document. 795 When using the Signed Token Renewal mechanism, the signed JWT is 796 transported to the UA via a 'URISigningPackage' cookie added to the 797 HTTP 2xx Successful message along with the content being returned to 798 the UA, or to the HTTP 3xx Redirection message in case the UA is 799 redirected to a different server. 801 3.3.1. Support for cross-domain redirection 803 For security purposes, the use of cross-domain cookies is not 804 supported in some application environments. As a result, the Cookie- 805 based method for transport of the Signed Token described in the 806 previous section might break if used in combination with an HTTP 3xx 807 Redirection response where the target URL is in a different domain. 808 In such scenarios, Signed Token Renewal of a signed JWT SHOULD be 809 communicated via the query string instead, in a similar fashion to 810 how regular signed JWTs (outside of Signed Token Renewal) are 811 communicated. Note that the use of URL embedded signed JWTs SHOULD 812 NOT be used in HTTP 2xx Successful messages, since UAs might not know 813 how to extract the signed JWTs. 815 Note that the process described herein only works in cases where both 816 the manifest file and segments constituting the segmented content are 817 delivered from the same domain. In other words, any redirection 818 between different domains needs to be carried out while retrieving 819 the manifest file. 821 4. Relationship with CDNI Interfaces 823 Some of the CDNI Interfaces need enhancements to support URI Signing. 824 A dCDN that supports URI Signing needs to be able to advertise this 825 capability to the uCDN. The uCDN needs to select a dCDN based on 826 such capability when the CSP requires access control to enforce its 827 distribution policy via URI Signing. Also, the uCDN needs to be able 828 to distribute via the CDNI Metadata interface the information 829 necessary to allow the dCDN to verify a Signed URI. Events that 830 pertain to URI Signing (e.g., request denial or delivery after access 831 authorization) need to be included in the logs communicated through 832 the CDNI Logging interface. 834 4.1. CDNI Control Interface 836 URI Signing has no impact on this interface. 838 4.2. CDNI Footprint & Capabilities Advertisement Interface 840 The CDNI Request Routing: Footprint and Capabilities Semantics 841 document [RFC8008] defines support for advertising CDNI Metadata 842 capabilities, via CDNI Payload Type. The CDNI Payload Type 843 registered in Section 6.1 can be used for capability advertisement. 845 4.3. CDNI Request Routing Redirection Interface 847 The CDNI Request Routing Redirection Interface [RFC7975] describes 848 the recursive request redirection method. For URI Signing, the uCDN 849 signs the URI provided by the dCDN. URI Signing therefore has has no 850 impact on this interface. 852 4.4. CDNI Metadata Interface 854 The CDNI Metadata Interface [RFC8006] describes the CDNI metadata 855 distribution needed to enable content acquisition and delivery. For 856 URI Signing, a new CDNI metadata object is specified. 858 The UriSigning Metadata object contains information to enable URI 859 signing and verification by a dCDN. The UriSigning properties are 860 defined below. 862 Property: enforce 864 Description: URI Signing enforcement flag. Specifically, this 865 flag indicates if the access to content is subject to URI 866 Signing. URI Signing requires the dCDN to ensure that the URI 867 is signed and verified before delivering content. Otherwise, 868 the dCDN does not perform verification, regardless of whether 869 or not the URI is signed. 871 Type: Boolean 873 Mandatory-to-Specify: No. The default is true. 875 Property: issuers 877 Description: A list of valid Issuers against which the Issuer 878 claim in the signed JWT may be verified. 880 Type: Array of Strings 881 Mandatory-to-Specify: No. The default is an empty list. An 882 empty list means that any Issuer is acceptable. 884 Property: package-attribute 886 Description: The name to use for the URI Signing Package. 888 Type: String 890 Mandatory-to-Specify: No. The default is "URISigningPackage". 892 Property: jwt-header 894 Description: The header part of JWT that is used for generating 895 or verifying a signed JWT when the JWT token in the URI Signing 896 Package does not contain a header part. 898 Type: String 900 Mandatory-to-Specify: No. By default, the header is assumed to 901 be included in the JWT token. 903 The following is an example of a URI Signing metadata payload with 904 all default values: 906 { 907 "generic-metadata-type": "MI.UriSigning" 908 "generic-metadata-value": {} 909 } 911 The following is an example of a URI Signing metadata payload with 912 explicit values: 914 { 915 "generic-metadata-type": "MI.UriSigning" 916 "generic-metadata-value": 917 { 918 "enforce": true, 919 "issuers": ["csp", "ucdn1", "ucdn2"], 920 "package-attribute": "usp", 921 "jwt-header": "1234abcd" 922 } 923 } 925 4.5. CDNI Logging Interface 927 For URI Signing, the dCDN reports that enforcement of the access 928 control was applied to the request for content delivery. When the 929 request is denied due to enforcement of URI Signing, the reason is 930 logged. 932 The following CDNI Logging field for URI Signing SHOULD be supported 933 in the HTTP Request Logging Record as specified in CDNI Logging 934 Interface [RFC7937], using the new "cdni_http_request_v2" record-type 935 registered in Section 6.2.1. 937 o s-uri-signing (mandatory): 939 * format: 3DIGIT 941 * field value: this characterises the URI signing verification 942 performed by the Surrogate on the request. The allowed values 943 are: 945 + "000" : no signed JWT verification performed 947 + "200" : signed JWT verification performed and verified 949 + "400" : signed JWT verification performed and rejected 950 because of incorrect signature 952 + "401" : signed JWT verification performed and rejected 953 because of Issuer enforcement 955 + "402" : signed JWT verification performed and rejected 956 because of Subject enforcement 958 + "403" : signed JWT verification performed and rejected 959 because of Audience enforcement 961 + "404" : signed JWT verification performed and rejected 962 because of Expiration Time enforcement 964 + "405" : signed JWT verification performed and rejected 965 because of Not Before enforcement 967 + "406" : signed JWT verification performed and rejected 968 because of Issued At enforcement 970 + "407" : signed JWT verification performed and rejected 971 because of Nonce enforcement 973 + "408" : signed JWT verification performed and rejected 974 because of Version enforcement 976 + "409" : signed JWT verification performed and rejected 977 because of Critical Extention enforcement 979 + "410" : signed JWT verification performed and rejected 980 because of Client IP enforcement 982 + "411" : signed JWT verification performed and rejected 983 because of URI Container enforcement 985 + "500" : unable to perform signed JWT verification because of 986 malformed URI 988 * occurrence: there MUST be zero or exactly one instance of this 989 field. 991 o s-uri-signing-deny-reason (optional): 993 * format: QSTRING 995 * field value: a string for providing further information in case 996 the signed JWT was rejected, e.g., for debugging purposes. 998 * occurrence: there MUST be zero or exactly one instance of this 999 field. 1001 5. URI Signing Message Flow 1003 URI Signing supports both HTTP-based and DNS-based request routing. 1004 JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of 1005 representing claims to be transferred between two parties. The 1006 claims in a signed JWT are encoded as a JSON object that is used as 1007 the payload of a JSON Web Signature (JWS) structure or as the 1008 plaintext of a JSON Web Encryption (JWE) structure, enabling the 1009 claims to be digitally signed or integrity protected with a Message 1010 Authentication Code (MAC) and/or encrypted. 1012 5.1. HTTP Redirection 1014 For HTTP-based request routing, a set of information that is unique 1015 to a given end user content request is included in a signed JWT, 1016 using key information that is specific to a pair of adjacent CDNI 1017 hops (e.g., between the CSP and the uCDN or between the uCDN and a 1018 dCDN). This allows a CDNI hop to ascertain the authenticity of a 1019 given request received from a previous CDNI hop. 1021 The URI signing method (assuming HTTP redirection, iterative request 1022 routing, and a CDN path with two CDNs) includes the following steps: 1024 End-User dCDN uCDN CSP 1025 | | | | 1026 | 1.CDNI FCI interface used to | | 1027 | advertise URI Signing capability| | 1028 | |------------------->| | 1029 | | | | 1030 | 2.Provides information to verify signed JWT | 1031 | | |<-------------------| 1032 | | | | 1033 | 3.CDNI Metadata interface used to| | 1034 | provide URI Signing attributes| | 1035 | |<-------------------| | 1036 : : : : 1037 : (Later in time) : : : 1038 |4.Authorization request | | 1039 |------------------------------------------------------------->| 1040 | | | [Apply distribution 1041 | | | policy] | 1042 | | | | 1043 | | (ALT: Authorization decision) 1044 |5.Request is denied | | | 1045 |<-------------------------------------------------------------| 1046 | | | | 1047 |6.CSP provides signed URI | | 1048 |<-------------------------------------------------------------| 1049 | | | | 1050 |7.Content request | | | 1051 |---------------------------------------->| [Verifiy URI | 1052 | | | signature] | 1053 | | | | 1054 | | (ALT: Verification result) | 1055 |8.Request is denied | | | 1056 |<----------------------------------------| | 1057 | | | | 1058 |9.Re-sign URI and redirect to | | 1059 | dCDN (newly signed URI) | | 1060 |<----------------------------------------| | 1061 | | | | 1062 |10.Content request | | | 1063 |------------------->| [Verify URI | | 1064 | | signature] | | 1065 | | | | 1066 | (ALT: Verification result) | | 1067 |11.Request is denied| | | 1068 |<-------------------| | | 1069 | | | | 1070 |12.Content delivery | | | 1071 |<-------------------| | | 1072 : : : : 1073 : (Later in time) : : : 1074 |13.CDNI Logging interface to include URI Signing information | 1075 | |------------------->| | 1077 Figure 4: HTTP-based Request Routing with URI Signing 1079 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1080 the dCDN advertises its capabilities including URI Signing 1081 support to the uCDN. 1083 2. CSP provides to the uCDN the information needed to verify signed 1084 JWTs from that CSP. For example, this information may include a 1085 key value. 1087 3. Using the CDNI Metadata interface, the uCDN communicates to a 1088 dCDN the information needed to verify signed JWTs from the uCDN 1089 for the given CSP. For example, this information may include 1090 the URI query string parameter name for the URI Signing Package 1091 Attribute. 1093 4. When a UA requests a piece of protected content from the CSP, 1094 the CSP makes a specific authorization decision for this unique 1095 request based on its personal distribution policy. 1097 5. If the authorization decision is negative, the CSP rejects the 1098 request and sends an error code (e.g., 403 Forbidden) in the 1099 HTTP response. 1101 6. If the authorization decision is positive, the CSP computes a 1102 Signed URI that is based on unique parameters of that request 1103 and conveys it to the end user as the URI to use to request the 1104 content. 1106 7. On receipt of the corresponding content request, the uCDN 1107 verifies the signed JWT in the URI using the information 1108 provided by the CSP. 1110 8. If the verification is negative, the uCDN rejects the request 1111 and sends an error code 403 Forbidden in the HTTP response. 1113 9. If the verification is positive, the uCDN computes a Signed URI 1114 that is based on unique parameters of that request and provides 1115 it to the end user as the URI to use to further request the 1116 content from the dCDN. 1118 10. On receipt of the corresponding content request, the dCDN 1119 verifies the signed JWT in the Signed URI using the information 1120 provided by the uCDN in the CDNI Metadata. 1122 11. If the verification is negative, the dCDN rejects the request 1123 and sends an error code 403 Forbidden in the HTTP response. 1125 12. If the verification is positive, the dCDN serves the request and 1126 delivers the content. 1128 13. At a later time, the dCDN reports logging events that include 1129 URI signing information. 1131 With HTTP-based request routing, URI Signing matches well the general 1132 chain of trust model of CDNI both with symmetric and asymmetric keys 1133 because the key information only needs to be specific to a pair of 1134 adjacent CDNI hops. 1136 5.2. DNS Redirection 1138 For DNS-based request routing, the CSP and uCDN must agree on a trust 1139 model appropriate to the security requirements of the CSP's 1140 particular content. Use of asymmetric public/private keys allows for 1141 unlimited distribution of the public key to dCDNs. However, if a 1142 shared secret key is preferred, then the CSP may want to restrict the 1143 distribution of the key to a (possibly empty) subset of trusted 1144 dCDNs. Authorized Delivery CDNs need to obtain the key information 1145 to verify the Signed URI. 1147 The URI signing method (assuming iterative DNS request routing and a 1148 CDN path with two CDNs) includes the following steps. 1150 End-User dCDN uCDN CSP 1151 | | | | 1152 | 1.CDNI FCI interface used to | | 1153 | advertise URI Signing capability| | 1154 | |------------------->| | 1155 | | | | 1156 | 2.Provides information to verify signed JWT | 1157 | | |<-------------------| 1158 | 3.CDNI Metadata interface used to| | 1159 | provide URI Signing attributes| | 1160 | |<-------------------| | 1161 : : : : 1162 : (Later in time) : : : 1163 |4.Authorization request | | 1164 |------------------------------------------------------------->| 1165 | | | [Apply distribution 1166 | | | policy] | 1167 | | | | 1168 | | (ALT: Authorization decision) 1169 |5.Request is denied | | | 1170 |<-------------------------------------------------------------| 1171 | | | | 1172 |6.Provides signed URI | | 1173 |<-------------------------------------------------------------| 1174 | | | | 1175 |7.DNS request | | | 1176 |---------------------------------------->| | 1177 | | | | 1178 |8.Redirect DNS to dCDN | | 1179 |<----------------------------------------| | 1180 | | | | 1181 |9.DNS request | | | 1182 |------------------->| | | 1183 | | | | 1184 |10.IP address of Surrogate | | 1185 |<-------------------| | | 1186 | | | | 1187 |11.Content request | | | 1188 |------------------->| [Verify URI | | 1189 | | signature] | | 1190 | | | | 1191 | (ALT: Verification result) | | 1192 |12.Request is denied| | | 1193 |<-------------------| | | 1194 | | | | 1195 |13.Content delivery | | | 1196 |<-------------------| | | 1197 : : : : 1198 : (Later in time) : : : 1199 |14.CDNI Logging interface to report URI Signing information | 1200 | |------------------->| | 1202 Figure 5: DNS-based Request Routing with URI Signing 1204 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1205 the dCDN advertises its capabilities including URI Signing 1206 support to the uCDN. 1208 2. CSP provides to the uCDN the information needed to verify 1209 cryptographic signatures from that CSP. For example, this 1210 information may include a key. 1212 3. Using the CDNI Metadata interface, the uCDN communicates to a 1213 dCDN the information needed to verify cryptographic signatures 1214 from the CSP (e.g., the URI query string parameter name for the 1215 URI Signing Package Attribute). In the case of symmetric key, 1216 the uCDN checks if the dCDN is allowed by CSP to obtain the 1217 shared secret key. 1219 4. When a UA requests a piece of protected content from the CSP, 1220 the CSP makes a specific authorization decision for this unique 1221 request based on its arbitrary distribution policy. 1223 5. If the authorization decision is negative, the CSP rejects the 1224 request and sends an error code (e.g., 403 Forbidden) in the 1225 HTTP response. 1227 6. If the authorization decision is positive, the CSP computes a 1228 cryptographic signature that is based on unique parameters of 1229 that request and includes it in the URI provided to the end user 1230 to request the content. 1232 7. End user sends DNS request to the uCDN. 1234 8. On receipt of the DNS request, the uCDN redirects the request to 1235 the dCDN. 1237 9. End user sends DNS request to the dCDN. 1239 10. On receipt of the DNS request, the dCDN responds with IP address 1240 of one of its Surrogates. 1242 11. On receipt of the corresponding content request, the dCDN 1243 verifies the cryptographic signature in the URI using the 1244 information provided by the uCDN in the CDNI Metadata. 1246 12. If the verification is negative, the dCDN rejects the request 1247 and sends an error code 403 Forbidden in the HTTP response. 1249 13. If the verification is positive, the dCDN serves the request and 1250 delivers the content. 1252 14. At a later time, dCDN reports logging events that includes URI 1253 signing information. 1255 With DNS-based request routing, URI Signing matches well the general 1256 chain of trust model of CDNI when used with asymmetric keys because 1257 the only key information that needs to be distributed across 1258 multiple, possibly untrusted, CDNI hops is the public key, which is 1259 generally not confidential. 1261 With DNS-based request routing, URI Signing does not match well the 1262 general chain of trust model of CDNI when used with symmetric keys 1263 because the symmetric key information needs to be distributed across 1264 multiple CDNI hops, to CDNs with which the CSP may not have a trust 1265 relationship. This raises a security concern for applicability of 1266 URI Signing with symmetric keys in case of DNS-based inter-CDN 1267 request routing. 1269 6. IANA Considerations 1271 6.1. CDNI Payload Type 1273 This document requests the registration of the following CDNI Payload 1274 Type under the IANA "CDNI Payload Types" registry: 1276 +---------------+---------------+ 1277 | Payload Type | Specification | 1278 +---------------+---------------+ 1279 | MI.UriSigning | RFCthis | 1280 +---------------+---------------+ 1282 [RFC Editor: Please replace RFCthis with the published RFC number for 1283 this document.] 1285 6.1.1. CDNI UriSigning Payload Type 1287 Purpose: The purpose of this payload type is to distinguish 1288 UriSigning MI objects (and any associated capability advertisement). 1290 Interface: MI/FCI 1292 Encoding: see Section 4.4 1294 6.2. CDNI Logging Record Type 1296 This document requests the registration of the following CDNI Logging 1297 record-type under the IANA "CDNI Logging record-types" registry: 1299 +----------------------+-----------+--------------------------------+ 1300 | record-types | Reference | Description | 1301 +----------------------+-----------+--------------------------------+ 1302 | cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | 1303 | | | Record version 1 for content | 1304 | | | delivery using HTTP, to | 1305 | | | include URI Signing logging | 1306 | | | fields | 1307 +----------------------+-----------+--------------------------------+ 1309 [RFC Editor: Please replace RFCthis with the published RFC number for 1310 this document.] 1312 6.2.1. CDNI Logging Record Version 2 for HTTP 1314 The "cdni_http_request_v2" record-type supports all of the fields 1315 supported by the "cdni_http_request_v1" record-type [RFC7937] plus 1316 the two additional fields "s-uri-signing" and "s-uri-signing-deny- 1317 reason", registered by this document in Section 6.3. The name, 1318 format, field value, and occurence information for the two new fields 1319 can be found in Section 4.5 of this document. 1321 6.3. CDNI Logging Field Names 1323 This document requests the registration of the following CDNI Logging 1324 fields under the IANA "CDNI Logging Field Names" registry: 1326 +---------------------------+-----------+ 1327 | Field Name | Reference | 1328 +---------------------------+-----------+ 1329 | s-uri-signing | RFCthis | 1330 | s-uri-signing-deny-reason | RFCthis | 1331 +---------------------------+-----------+ 1333 [RFC Editor: Please replace RFCthis with the published RFC number for 1334 this document.] 1336 6.4. CDNI URI Signing Signed Token Transport 1338 The IANA is requested to create a new "CDNI URI Signing Signed Token 1339 Transport" subregistry in the "Content Delivery Networks 1340 Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing 1341 Signed Token Transport" namespace defines the valid values that may 1342 be in the Signed Token Transport (cdnistt) JWT claim. Additions to 1343 the Signed Token Transport namespace conform to the "Specification 1344 Required" policy as defined in [RFC8126]. 1346 The following table defines the initial Enforcement Information 1347 Elements: 1349 +-------+-------------------------------------------+---------+ 1350 | Value | Description | RFC | 1351 +-------+-------------------------------------------+---------+ 1352 | 0 | Designates token transport is not enabled | RFCthis | 1353 | 1 | Designates token transport via cookie | RFCthis | 1354 +-------+-------------------------------------------+---------+ 1356 [RFC Editor: Please replace RFCthis with the published RFC number for 1357 this document.] 1359 6.5. JSON Web Token Claims Registration 1361 This specification registers the following Claims in the IANA "JSON 1362 Web Token Claims" registry [IANA.JWT.Claims] established by 1363 [RFC7519]. 1365 6.5.1. Registry Contents 1367 o Claim Name: "cdniv" 1368 o Claim Description: CDNI Claim Set Version 1369 o Change Controller: IESG 1370 o Specification Document(s): Section 2.1.8 of [[ this specification 1371 ]] 1373 o Claim Name: "cdnicrit" 1374 o Claim Description: CDNI Critical Claims Set 1375 o Change Controller: IESG 1376 o Specification Document(s): Section 2.1.9 of [[ this specification 1377 ]] 1379 o Claim Name: "cdniip" 1380 o Claim Description: CDNI IP Address 1381 o Change Controller: IESG 1382 o Specification Document(s): Section 2.1.10 of [[ this specification 1383 ]] 1385 o Claim Name: "cdniuc" 1386 o Claim Description: CDNI URI Container 1387 o Change Controller: IESG 1388 o Specification Document(s): Section 2.1.11 of [[ this specification 1389 ]] 1391 o Claim Name: "cdniets" 1392 o Claim Description: CDNI Expiration Time Setting for Signed Token 1393 Renewal 1394 o Change Controller: IESG 1395 o Specification Document(s): Section 2.1.12 of [[ this specification 1396 ]] 1398 o Claim Name: "cdnistt" 1399 o Claim Description: CDNI Signed Token Transport Method for Signed 1400 Token Renewal 1401 o Change Controller: IESG 1402 o Specification Document(s): Section 2.1.13 of [[ this specification 1403 ]] 1405 o Claim Name: "cdnistd" 1406 o Claim Description: CDNI Signed Token Depth 1407 o Change Controller: IESG 1408 o Specification Document(s): Section 2.1.14 of [[ this specification 1409 ]] 1411 7. Security Considerations 1413 This document describes the concept of URI Signing and how it can be 1414 used to provide access authorization in the case of CDNI. The 1415 primary goal of URI Signing is to make sure that only authorized UAs 1416 are able to access the content, with a CSP being able to authorize 1417 every individual request. It should be noted that URI Signing is not 1418 a content protection scheme; if a CSP wants to protect the content 1419 itself, other mechanisms, such as DRM, are more appropriate. 1421 In general, it holds that the level of protection against 1422 illegitimate access can be increased by including more claims in the 1423 signed JWT. The current version of this document includes claims for 1424 enforcing Issuer, Client IP Address, Not Before time, and Expiration 1425 Time, however this list can be extended with other, more complex, 1426 attributes that are able to provide some form of protection against 1427 some of the vulnerabilities highlighted below. 1429 That said, there are a number of aspects that limit the level of 1430 security offered by URI Signing and that anybody implementing URI 1431 Signing should be aware of. 1433 o Replay attacks: A (valid) Signed URI may be used to perform replay 1434 attacks. The vulnerability to replay attacks can be reduced by 1435 picking a relatively short window between the Not Before time and 1436 Expiration Time attributes, although this is limited by the fact 1437 that any HTTP-based request needs a window of at least a couple of 1438 seconds to prevent a sudden network issues from denying legitimate 1439 UAs access to the content. One may also reduce exposure to replay 1440 attacks by including a unique one-time access ID via the Nonce 1441 attribute (jti claim). Whenever the dCDN receives a request with 1442 a given unique ID, it adds that ID to the list of 'used' IDs. In 1443 the case an illegitimate UA tries to use the same URI through a 1444 replay attack, the dCDN can deny the request based on the already- 1445 used access ID. 1447 o Illegitimate clients behind a NAT: In cases where there are 1448 multiple users behind the same NAT, all users will have the same 1449 IP address from the point of view of the dCDN. This results in 1450 the dCDN not being able to distinguish between different users 1451 based on Client IP Address which can lead to illegitimate users 1452 being able to access the content. One way to reduce exposure to 1453 this kind of attack is to not only check for Client IP but also 1454 for other attributes, e.g., attributes that can be found in HTTP 1455 headers. 1457 The shared key between CSP and uCDN may be distributed to dCDNs - 1458 including cascaded CDNs. Since this key can be used to legitimately 1459 sign a URL for content access authorization, it is important to know 1460 the implications of a compromised shared key. 1462 If a shared key usable for signing is compromised, an attacker can 1463 use it to perform a denial-of-service attack by forcing the CDN to 1464 evaluate prohibitively expensive regular expressions embedded in a 1465 cdniuc claim. As a result, compromised keys should be timely revoked 1466 in order to prevent exploitation. 1468 8. Privacy 1470 The privacy protection concerns described in CDNI Logging Interface 1471 [RFC7937] apply when the client's IP address (cdniip) is embedded in 1472 the Signed URI. For this reason, the mechanism described in 1473 Section 2 encrypts the Client IP before including it in the URI 1474 Signing Package (and thus the URL itself). 1476 9. Acknowledgements 1478 The authors would like to thank the following people for their 1479 contributions in reviewing this document and providing feedback: 1480 Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan 1481 York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana 1482 Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris 1483 Lemmons. 1485 10. Contributors 1487 In addition, the authors would also like to make special mentions for 1488 certain people who contributed significant sections to this document. 1490 o Matt Caulfield provided content for the CDNI Metadata Interface 1491 section. 1493 o Emmanuel Thomas provided content for HTTP Adaptive Streaming. 1495 o Matt Miller provided consultation on JWT usage as well as code to 1496 generate working JWT examples. 1498 11. References 1500 11.1. Normative References 1502 [POSIX.1] "The Open Group Base Specifications Issue 7", IEEE 1503 Std 1003.1 2018 Edition, Jan 2018, 1504 . 1506 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1507 DOI 10.17487/RFC0791, September 1981, 1508 . 1510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1511 Requirement Levels", BCP 14, RFC 2119, 1512 DOI 10.17487/RFC2119, March 1997, 1513 . 1515 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1516 Resource Identifier (URI): Generic Syntax", STD 66, 1517 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1518 . 1520 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1521 Address Text Representation", RFC 5952, 1522 DOI 10.17487/RFC5952, August 2010, 1523 . 1525 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1526 DOI 10.17487/RFC6265, April 2011, 1527 . 1529 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1530 Keranen, A., and P. Hallam-Baker, "Naming Things with 1531 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1532 . 1534 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1535 Protocol (HTTP/1.1): Message Syntax and Routing", 1536 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1537 . 1539 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1540 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1541 . 1543 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1544 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1545 . 1547 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 1548 and R. Peterkofsky, "Content Distribution Network 1549 Interconnection (CDNI) Logging Interface", RFC 7937, 1550 DOI 10.17487/RFC7937, August 2016, 1551 . 1553 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1554 "Content Delivery Network Interconnection (CDNI) 1555 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1556 . 1558 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1559 Writing an IANA Considerations Section in RFCs", BCP 26, 1560 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1561 . 1563 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1564 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1565 May 2017, . 1567 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1568 Interchange Format", STD 90, RFC 8259, 1569 DOI 10.17487/RFC8259, December 2017, 1570 . 1572 11.2. Informative References 1574 [IANA.JWT.Claims] 1575 IANA, "JSON Web Token Claims", 1576 . 1578 [MPEG-DASH] 1579 ISO, "Information technology -- Dynamic adaptive streaming 1580 over HTTP (DASH) -- Part 1: Media presentation description 1581 and segment format", ISO/IEC 23009-1:2014, Edition 2, 05 1582 2014, . 1584 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1585 "Network Time Protocol Version 4: Protocol and Algorithms 1586 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1587 . 1589 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1590 Distribution Network Interconnection (CDNI) Problem 1591 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1592 2012, . 1594 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 1595 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 1596 Content Distribution Network Interconnection (CDNI)", 1597 RFC 6983, DOI 10.17487/RFC6983, July 2013, 1598 . 1600 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1601 "Framework for Content Distribution Network 1602 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1603 August 2014, . 1605 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1606 Network Interconnection (CDNI) Requirements", RFC 7337, 1607 DOI 10.17487/RFC7337, August 2014, 1608 . 1610 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1611 DOI 10.17487/RFC7517, May 2015, 1612 . 1614 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1615 "Request Routing Redirection Interface for Content 1616 Delivery Network (CDN) Interconnection", RFC 7975, 1617 DOI 10.17487/RFC7975, October 2016, 1618 . 1620 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1621 R., and K. Ma, "Content Delivery Network Interconnection 1622 (CDNI) Request Routing: Footprint and Capabilities 1623 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1624 . 1626 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 1627 RFC 8216, DOI 10.17487/RFC8216, August 2017, 1628 . 1630 Appendix A. Signed URI Package Example 1632 This section contains three examples of token usage: a simple example 1633 with only the required claim present, a complex example which 1634 demonstrates the full JWT claims set, including an encrypted Client 1635 IP (cdniip), and one that uses a Signed Token Renewal. 1637 Note: All of the examples have whitespace added to improve formatting 1638 and readability, but are not present in the generated content. 1640 All examples use the following JWK Set [RFC7517]: 1642 { "keys": [ 1643 { 1644 "kty": "EC", 1645 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1646 "use": "sig", 1647 "alg": "ES256", 1648 "crv": "P-256", 1649 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1650 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA" 1651 }, 1652 { 1653 "kty": "EC", 1654 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1655 "use": "sig", 1656 "alg": "ES256", 1657 "crv": "P-256", 1658 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1659 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", 1660 "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" 1661 }, 1662 { 1663 "kty": "oct", 1664 "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", 1665 "use": "enc", 1666 "alg": "A128GCM", 1667 "k": "4uFxxV7fhNmrtiah2d1fFg" 1668 } 1669 ]} 1671 Note: They are the public signing key, the private signing key, and 1672 the shared secret enctyption key, respectively. The public and 1673 private signing keys have the same fingerprint and only vary by the 1674 'd' parameter that is missing from the public signing key. 1676 A.1. Simple Example 1678 This example is a simple common usage example containing a minimal 1679 subset of claims that the authors find most useful. 1681 The JWT Claim Set before signing: 1683 Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the 1684 URL Segment form ([RFC6920] Section 5) of "http://cdni.example/foo/ 1685 bar". 1687 { 1688 "exp": 1474243500, 1689 "iss": "uCDN Inc", 1690 "cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" 1691 } 1693 The signed JWT: 1695 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1696 dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE0NzQyNDM1MDAsImlzcyI6InVDRE4gS 1697 W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV 1698 wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.qzzAB9akC-HoEzQrkOoODWjMC0PEZRrmWz 1699 2rSMcpLtvxyxVodlB2xcpl4J4ABhLLOJzgzL9B39TljTqZApSOpQ 1701 A.2. Complex Example 1703 This example uses all fields except for those dealing with Signed 1704 Token Renewal, including Client IP (cdniip) and Subject (sub) which 1705 are encrpyted. This significantly increases the size of the signed 1706 JWT token. 1708 JWE for Client IP (cdniip) of [2001:db8::1/32]: 1710 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1711 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..SuzoOnfg-GVh-BOc.wQ9iS 1712 R1sTj-A04CiDmvcgg.9Ts_cIEUw6Yc6U5HaH1UPQ 1714 JWE for Subject (sub) of "UserToken": 1716 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1717 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..XsJ7ySeChORSIojp.R1U8E 1718 SGU2NnW.DWR8pTbeCwQZca6SitfX_g 1720 The JWT Claim Set before signing: 1722 { 1723 "aud": "dCDN LLC", 1724 "sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4 1725 QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..XsJ7ySeChORS 1726 Iojp.R1U8ESGU2NnW.DWR8pTbeCwQZca6SitfX_g", 1727 "cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY 1728 mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..SuzoOnfg- 1729 GVh-BOc.wQ9iSR1sTj-A04CiDmvcgg.9Ts_cIEUw6Yc6U5HaH1UPQ", 1730 "cdniv": 1, 1731 "exp": 1474243500, 1732 "iat": 1474243200, 1733 "iss": "uCDN Inc", 1734 "jti": "5DAafLhZAfhsbe", 1735 "nbf": 1474243200, 1736 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png" 1737 } 1739 The signed JWT: 1741 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1742 dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib 1743 U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA 1744 0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T 1745 0NKOS4uWHNKN3lTZUNoT1JTSW9qcC5SMVU4RVNHVTJOblcuRFdSOHBUYmVDd1FaY2E 1746 2U2l0ZlhfZyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja 1747 m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp 1748 2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uU3V6b09uZmctR1ZoLUJPYy53U 1749 TlpU1Ixc1RqLUEwNENpRG12Y2dnLjlUc19jSUVVdzZZYzZVNUhhSDFVUFEiLCJjZG5 1750 pdiI6MSwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6InVDR 1751 E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE0NzQyNDMyMDAsImN 1752 kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde 1753 zN9XFwucG5nIn0.XEi1NeP8Lzh6ECcbp6EoqYlnJGikaGp6F3lIJ7ZJt3bim6tOtuD 1754 pCQxmEQxobzIpWOCNdpB8kvxM_s95brKjNQ 1756 A.3. Signed Token Renewal Example 1758 This example uses fields for Signed Token Renewal. 1760 The JWT Claim Set before signing: 1762 { 1763 "cdniets": 30, 1764 "cdnistt": 1, 1765 "cdnistd": 2, 1766 "exp": 1474243500, 1767 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1768 } 1769 The signed JWT: 1771 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1772 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1773 XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTAwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1774 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.wsSvwxY8mtRax7HK_ 1775 dro_l6m-mM-HYdeaUoTSgVS5XTIhXBsCPsYQncsradmgmOWHDDOxsSMVVTjHe5E5YH 1776 ZlQ 1778 Once the server verifies the signed JWT it will return a new signed 1779 JWT with an updated expiry time (exp) as shown below. Note the 1780 expiry time is increased by the expiration time setting (cdniets) 1781 value. 1783 The JWT Claim Set before signing: 1785 { 1786 "cdniets": 30, 1787 "cdnistt": 1, 1788 "cdnistd": 2, 1789 "exp": 1474243530, 1790 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1791 } 1793 The signed JWT: 1795 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1796 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1797 XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTMwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1798 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.SITeoIVZ8-yeE_GBV 1799 jYEo1P2LN-EId1gEJ6baR3Au7Dzh2o_O7LhH3k6wHY081sYMdXHucB0P5ocp-r7gqe 1800 ruQ 1802 Authors' Addresses 1804 Ray van Brandenburg 1805 Tiledmedia 1806 Anna van Buerenplein 1 1807 Den Haag 2595DA 1808 The Netherlands 1810 Phone: +31 88 866 7000 1811 Email: ray@tiledmedia.com 1812 Kent Leung 1813 Cisco Systems, Inc. 1814 3625 Cisco Way 1815 San Jose, CA 95134 1816 United States 1818 Phone: +1 408 526 5030 1819 Email: kleung@cisco.com 1821 Phil Sorber 1822 Apple, Inc. 1823 1800 Wazee Street 1824 Suite 410 1825 Denver, CO 80202 1826 United States 1828 Email: sorber@apple.com