idnits 2.17.1 draft-ietf-cdni-uri-signing-17.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 (March 11, 2019) is 1873 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: September 12, 2019 Cisco Systems, Inc. 6 P. Sorber 7 Apple, Inc. 8 March 11, 2019 10 URI Signing for CDN Interconnection (CDNI) 11 draft-ietf-cdni-uri-signing-17 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 September 12, 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 non-reserved characters that will be interpreted 401 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. It should be 468 appropriately set to an identiy that the validating CDN understands 469 itself to be capable of validating on behalf of. This may be the CSP 470 identity, or any CDN in the chain and can also be modified as needed 471 by any entity in the chain as long as they can generate a valid 472 signature. 474 2.1.4. Expiry Time (exp) claim 476 Expiry Time (exp) [optional] - The semantics in [RFC7519] 477 Section 4.1.4 MUST be followed, though URI Signing implementations 478 MUST NOT allow for any time synchronization "leeway". Note: The time 479 on the entities that generate and verify the signed URI SHOULD be in 480 sync. In the CDNI case, this means that CSP, uCDN, and dCDN servers 481 need to be time-synchronized. It is RECOMMENDED to use NTP [RFC5905] 482 for time synchronization. If the CDN verifying the signed JWT does 483 not support Expiry Time verification, or if the Expiry Time in the 484 signed JWT corresponds to a time equal to or earlier than the time of 485 the content request, the CDN MUST reject the request. If the 486 received signed JWT contains a Expiry Time claim, then any JWT 487 subsequently generated for CDNI redirection MUST also contain an 488 Expiry Time claim, and the Expiry Time value MUST be the same as in 489 the received signed JWT. A signed JWT generated for CDNI redirection 490 MUST NOT add an Expiry Time claim if no Expiry Time claim existed in 491 the received signed JWT. 493 2.1.5. Not Before (nbf) claim 495 Not Before (nbf) [optional] - The semantics in [RFC7519] 496 Section 4.1.5 MUST be followed, though URI Signing implementations 497 MUST NOT allow for any time synchronization "leeway". Note: The time 498 on the entities that generate and verify the signed URI SHOULD be in 499 sync. In the CDNI case, this means that the CSP, uCDN, and dCDN 500 servers need to be time-synchronized. It is RECOMMENDED to use NTP 501 [RFC5905] for time synchronization. If the CDN verifying the signed 502 JWT does not support Not Before time verification, or if the Not 503 Before time in the signed JWT corresponds to a time later than the 504 time of the content request, the CDN MUST reject the request. If the 505 received signed JWT contains a Not Before time claim, then any JWT 506 subsequently generated for CDNI redirection MUST also contain a Not 507 Before time claim, and the Not Before time value MUST be the same as 508 in the received signed JWT. A signed JWT generated for CDNI 509 redirection MUST NOT add a Not Before time claim if no Not Before 510 time claim existed in the received signed JWT. 512 2.1.6. Issued At (iat) claim 514 Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6 515 MUST be followed. Note: The time on the entities that generate and 516 verify the signed URI SHOULD be in sync. In the CDNI case, this 517 means that CSP, uCDN, and dCDN servers need to be time-synchronized. 518 It is RECOMMENDED to use NTP [RFC5905] for time synchronization. If 519 the received signed JWT contains an Issued At claim, then any JWT 520 subsequently generated for CDNI redirection MUST also contain an 521 Issued At claim, and the Issuer value MUST be updated to identify the 522 time the new JWT was generated. If the received signed JWT does not 523 contain an Issued At claim, an Issued At claim MAY be added to a 524 signed JWT generated for CDNI redirection. 526 2.1.7. Nonce (jti) claim 528 Nonce (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 529 MUST be followed. A Nonce can be used to prevent replay attacks if 530 the CDN stores a list of all previously used Nonce values, and 531 verifies that the Nonce in the current JWT has never been used 532 before. If the signed JWT contains a Nonce claim and the CDN 533 verifying the signed JWT either does not support Nonce storage or has 534 previously seen the nonce used in a request for the same content, 535 then the CDN MUST reject the request. If the received signed JWT 536 contains a Nonce claim, then any JWT subsequently generated for CDNI 537 redirection MUST also contain a Nonce claim, and the Nonce value MUST 538 be the same as in the received signed JWT. If the received signed 539 JWT does not contain a Nonce claim, a Nonce claim MUST NOT be added 540 to a signed JWT generated for CDNI redirection. 542 2.1.8. CDNI Claim Set Version (cdniv) claim 544 CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set 545 Version (cdniv) claim provides a means within a signed JWT to tie the 546 claim set to a specific version of this specification. The cdniv 547 claim is intended to allow changes in and facilitate upgrades across 548 specifications. The type is JSON integer and the value MUST be set 549 to "1", for this version of the specification. In the absence of 550 this claim, the value is assumed to be "1". For future versions this 551 claim will be mandatory. Implementations MUST reject signed JWTs 552 with unsupported CDNI Claim Set versions. 554 2.1.9. CDNI Critical Claims Set (cdnicrit) claim 556 CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical 557 Claims Set (cdnicrit) claim indicates that extensions to this 558 specification are being used that MUST be understood and processed. 559 Its value is a comma separated listing of claims in the Signed JWT 560 that use those extensions. If any of the listed extension claims are 561 not understood and supported by the recipient, then the Signed JWT is 562 invalid. Producers MUST NOT include claim names defined by this 563 specification, duplicate names, or names that do not occur as claim 564 names within the Signed JWT in the cdnicrit list. Producers MUST NOT 565 use the empty list "" as the cdnicrit value. Recipients MAY consider 566 the Signed JWT to be invalid if the cdnicrit list contains any claim 567 names defined by this specification or if any other constraints on 568 its use are violated. This claim MUST be understood and processed by 569 all implementations. 571 2.1.10. Client IP (cdniip) claim 573 Client IP (cdniip) [optional] - The Client IP (cdniip) claim hold an 574 IP address or IP prefix for which the Signed URI is valid. This is 575 represented in CIDR notation, with dotted decimal format for IPv4 576 addresses [RFC0791] or canonical text representation for IPv6 577 addresses [RFC5952]. The request MUST be rejected if sourced from a 578 client outside of the specified IP range. Since the client IP is 579 considered personally identifiable information this field MUST be a 580 JSON Web Encryption (JWE [RFC7516]) Object in compact serialization 581 form. If the CDN verifying the signed JWT does not support Client IP 582 verification, or if the Client IP in the signed JWT does not match 583 the source IP address in the content request, the CDN MUST reject the 584 request. The type of this claim is a JSON string that contains the 585 JWE. If the received signed JWT contains a Client IP claim, then any 586 JWT subsequently generated for CDNI redirection MUST also contain a 587 Client IP claim, and the Client IP value MUST be the same as in the 588 received signed JWT. A signed JWT generated for CDNI redirection 589 MUST NOT add a Client IP claim if no Client IP claim existed in the 590 received signed JWT. 592 2.1.11. CDNI URI Container (cdniuc) claim 594 URI Container (cdniuc) [optional] - The URI Container (cdniuc) holds 595 the URI representation before a URI Signing Package is added. This 596 representation can take one of several forms detailed in 597 Section 2.1.15. If the URI Container used in the signed JWT does not 598 match the URI of the content request, the CDN verifying the signed 599 JWT MUST reject the request. When comparing the URI, the percent 600 encoded form as defined in [RFC3986] Section 2.1 MUST be used. When 601 redirecting a URI, the CDN generating the new signed JWT MAY change 602 the URI Container to comport with the URI being used in the 603 redirection. 605 2.1.12. CDNI Expiration Time Setting (cdniets) claim 607 CDNI Expiration Time Setting (cdniets) [optional] - The CDNI 608 Expiration Time Setting (cdniets) claim provides a means for setting 609 the value of the Expiry Time (exp) claim when generating a subsequent 610 signed JWT in Signed Token Renewal. Its type is a JSON numeric 611 value. It denotes the number of seconds to be added to the time at 612 which the JWT is verified that gives the value of the Expiry Time 613 (exp) claim of the next signed JWT. The CDNI Expiration Time Setting 614 (cdniets) SHOULD NOT be used when not using Signed Token Renewal and 615 MUST be present when using Signed Token Renewal. 617 2.1.13. CDNI Signed Token Transport (cdnistt) claim 619 CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed 620 Token Transport (cdnistt) claim provides a means of signalling the 621 method through which a new signed JWT is transported from the CDN to 622 the UA and vice versa for the purpose of Signed Token Renewal. Its 623 type is a JSON integer. Values for this claim are defined in 624 Section 6.4. If using this claim you MUST also specify a CDNI 625 Expiration Time Setting (cdniets) as noted above. 627 2.1.14. CDNI Signed Token Depth (cdnistd) claim 629 CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token 630 Depth (cdnistd) claim is used to associate a subsequent signed JWT, 631 generated as the result of a CDNI Signed Token Transport claim, with 632 a specific URI subset. Its type is a JSON integer. Signed JWTs MUST 633 NOT use a negative value for the CDNI Signed Token Depth claim. 635 If the transport used for Signed Token Transport allows the CDN to 636 associate the path component of a URI with tokens (e.g., an HTTP 637 Cookie Path as described in section 4.1.2.4 of [RFC6265]), the CDNI 638 Signed Token Depth value is the number of path segments that should 639 be considered significant for this association. A CDNI Signed Token 640 Depth of zero means that the client SHOULD be directed to return the 641 token with requests for any path. If the CDNI Signed Token Depth is 642 greater than zero, then the client SHOULD be directed to return the 643 token for future requests wherein the first CDNI Signed Token Depth 644 segments of the path match the first CDNI Signed Token Depth segments 645 of the signed URI path. This matching MUST use the URI with the 646 token removed, as specified in Section 2.1.15. 648 If the URI path to match contains fewer segments than the CDNI Signed 649 Token Depth claim, a signed JWT MUST NOT be generated for the 650 purposes of Signed Token Renewal. If the CDNI Signed Token Depth 651 claim is omitted, it means the same thing as if its value were zero. 652 If the received signed JWT contains a CDNI Signed Token Depth claim, 653 then any JWT subsequently generated for CDNI redirection or Signed 654 Token Transport MUST also contain a CDNI Signed Token Depth claim, 655 and the value MUST be the same as in the received signed JWT. 657 2.1.15. URI Container Forms 659 The URI Container (cdniuc) claim takes one of the following forms: 660 'hash:' or 'regex:'. More forms may be added in the future to extend 661 the capabilities. 663 Before comparing a URI with contents of this container, the following 664 steps MUST be performed: 666 o Prior to verification, remove the signed JWT from the URI. This 667 removal is only for the purpose of determining if the URI matches; 668 all other purposes will use the original URI. If the signed JWT 669 is terminated by anything other than a sub-delimiter (as definined 670 in [RFC3986] Section 2.2), everything from the reserved character 671 (as defined in [RFC3986] Section 2.2) that precedes the URI 672 Signing Package Attribute to the last character of the signed JWT 673 will be removed, inclusive. Otherwise, everything from the first 674 character of the URI Signing Package Attribute to the sub- 675 delimiter that terminates the signed JWT will be removed, 676 inclusive. 678 o Normalize the URI according to section 2.7.3 [RFC7230] and 679 sections 6.2.2 and 6.2.3 [RFC3986]. This applies to both 680 generation and verification of the signed JWT. 682 2.1.15.1. URI Hash Container (hash:) 684 Prefixed with 'hash:', this string is a URL Segment form ([RFC6920] 685 Section 5) of the URI. 687 2.1.15.2. URI Regular Expression Container (regex:) 689 Prefixed with 'regex:', this string is any POSIX Section 9 [POSIX.1] 690 Extended Regular Expression compatible regular expression used to 691 match against the requested URI. These regular expressions MUST be 692 evaluated in the POSIX locale (POSIX Section 7.2 [POSIX.1]). 694 Note: Because '\' has special meaning in JSON [RFC8259] as the escape 695 character within JSON strings, the regular expression character '\' 696 MUST be escaped as '\\'. 698 An example of a 'regex:' is the following: 700 [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)? 702 Note: Due to computational complexity of executing arbitrary regular 703 expressions, it is RECOMMENDED to only execute after verifying the 704 JWT to ensure its authenticity. 706 2.2. JWT Header 708 The header of the JWT MAY be passed via the CDNI Metadata interface 709 instead of being included in the URISigningPackage. The header value 710 must be transmitted in the serialized encoded form and prepended to 711 the JWT payload and signature passed in the URISigningPackage prior 712 to verification. This reduces the size of the signed JWT token. 714 3. URI Signing Token Renewal 716 3.1. Overview 718 For content that is delivered via HTTP in a segmented fashion, such 719 as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216], 720 special provisions need to be made in order to ensure URI Signing can 721 be applied. In general, segmented protocols work by breaking large 722 objects (e.g., videos) into a sequence of small independent segments. 723 Such segments are then referenced by a separate manifest file, which 724 either includes a list of URLs to the segments or specifies an 725 algorithm through which a User Agent can construct the URLs to the 726 segments. Requests for segments therefore originate from the 727 manifest file and, unless the URLs in the manifest file point to the 728 CSP, are not subjected to redirection and URI Signing. This opens up 729 a vulnerability to malicious User Agents sharing the manifest file 730 and deep-linking to the segments. 732 One method for dealing with this vulnerability would be to include, 733 in the manifest itself, Signed URIs that point to the individual 734 segments. There exist a number of issues with that approach. First, 735 it requires the CDN delivering the manifest to rewrite the manifest 736 file for each User Agent, which would require the CDN to be aware of 737 the exact segmentation protocol used. Secondly, it could also 738 require the expiration time of the Signed URIs to be valid for an 739 extended duration if the content described by the manifest is meant 740 to be consumed in real time. For instance, if the manifest file were 741 to contain a segmented video stream of more than 30 minutes in 742 length, Signed URIs would require to be valid for a at least 30 743 minutes, thereby reducing their effectiveness and that of the URI 744 Signing mechanism in general. For a more detailed analysis of how 745 segmented protocols such as HTTP Adaptive Streaming protocols affect 746 CDNI, see Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. 748 The method described in this section allows CDNs to use URI Signing 749 for segmented content without having to include the Signed URIs in 750 the manifest files themselves. 752 3.2. Signed Token Renewal mechanism 754 In order to allow for effective access control of segmented content, 755 the URI signing mechanism defined in this section is based on a 756 method through which subsequent segment requests can be linked 757 together. As part of the JWT verification procedure, the CDN can 758 generate a new signed JWT that the UA can use to do a subsequent 759 request. More specifically, whenever a UA successfully retrieves a 760 segment, it receives, in the HTTP 2xx Successful message, a signed 761 JWT that it can use whenever it requests the next segment. As long 762 as each successive signed JWT is correctly verified before a new one 763 is generated, the model is not broken and the User Agent can 764 successfully retrieve additional segments. Given the fact that with 765 segmented protocols, it is usually not possible to determine a priori 766 which segment will be requested next (i.e., to allow for seeking 767 within the content and for switching to a different representation), 768 the Signed Token Renewal uses the URI Regular Expression Container 769 scoping mechanisms in the URI Container (cdniuc) claim to allow a 770 signed JWT to be valid for more than one URL. 772 In order for this renewal of signed JWTs to work, it is necessary for 773 a UA to extract the signed JWT from the HTTP 2xx Successful message 774 of an earlier request and use it to retrieve the next segment. The 775 exact mechanism by which the client does this is outside the scope of 776 this document. However, in order to also support legacy UAs that do 777 not include any specific provisions for the handling of signed JWTs, 778 the following section defines a mechanism using HTTP Cookies 779 [RFC6265] that allows such UAs to support the concept of renewing 780 signed JWTs without requiring any additional UA support. 782 3.2.1. Required Claims 784 The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12) 785 MUST both be present for Signed Token Renewal. You MAY set cdnistt 786 to a value of '0' to mean no Signed Token Renewal, but you still MUST 787 have a corresponding cdniets that verifies as a JSON number. 788 However, if you do not want to use Signed Token Renewal, it is 789 RECOMMENDED to simply omit both. 791 3.3. Communicating a signed JWTs in Signed Token Renewal 793 This section assumes the value of the CDNI Signed Token Transport 794 (cdnistt) claim has been set to 1. Other values of cdnistt are out 795 of scope of this document. 797 When using the Signed Token Renewal mechanism, the signed JWT is 798 transported to the UA via a 'URISigningPackage' cookie added to the 799 HTTP 2xx Successful message along with the content being returned to 800 the UA, or to the HTTP 3xx Redirection message in case the UA is 801 redirected to a different server. 803 3.3.1. Support for cross-domain redirection 805 For security purposes, the use of cross-domain cookies is not 806 supported in some application environments. As a result, the Cookie- 807 based method for transport of the Signed Token described in the 808 previous section might break if used in combination with an HTTP 3xx 809 Redirection response where the target URL is in a different domain. 810 In such scenarios, Signed Token Renewal of a signed JWT SHOULD be 811 communicated via the query string instead, in a similar fashion to 812 how regular signed JWTs (outside of Signed Token Renewal) are 813 communicated. Note that the use of URL embedded signed JWTs SHOULD 814 NOT be used in HTTP 2xx Successful messages, since UAs might not know 815 how to extract the signed JWTs. 817 Note that the process described herein only works in cases where both 818 the manifest file and segments constituting the segmented content are 819 delivered from the same domain. In other words, any redirection 820 between different domains needs to be carried out while retrieving 821 the manifest file. 823 4. Relationship with CDNI Interfaces 825 Some of the CDNI Interfaces need enhancements to support URI Signing. 826 A dCDN that supports URI Signing needs to be able to advertise this 827 capability to the uCDN. The uCDN needs to select a dCDN based on 828 such capability when the CSP requires access control to enforce its 829 distribution policy via URI Signing. Also, the uCDN needs to be able 830 to distribute via the CDNI Metadata interface the information 831 necessary to allow the dCDN to verify a Signed URI. Events that 832 pertain to URI Signing (e.g., request denial or delivery after access 833 authorization) need to be included in the logs communicated through 834 the CDNI Logging interface. 836 4.1. CDNI Control Interface 838 URI Signing has no impact on this interface. 840 4.2. CDNI Footprint & Capabilities Advertisement Interface 842 The CDNI Request Routing: Footprint and Capabilities Semantics 843 document [RFC8008] defines support for advertising CDNI Metadata 844 capabilities, via CDNI Payload Type. The CDNI Payload Type 845 registered in Section 6.1 can be used for capability advertisement. 847 4.3. CDNI Request Routing Redirection Interface 849 The CDNI Request Routing Redirection Interface [RFC7975] describes 850 the recursive request redirection method. For URI Signing, the uCDN 851 signs the URI provided by the dCDN. URI Signing therefore has has no 852 impact on this interface. 854 4.4. CDNI Metadata Interface 856 The CDNI Metadata Interface [RFC8006] describes the CDNI metadata 857 distribution needed to enable content acquisition and delivery. For 858 URI Signing, a new CDNI metadata object is specified. 860 The UriSigning Metadata object contains information to enable URI 861 signing and verification by a dCDN. The UriSigning properties are 862 defined below. 864 Property: enforce 866 Description: URI Signing enforcement flag. Specifically, this 867 flag indicates if the access to content is subject to URI 868 Signing. URI Signing requires the dCDN to ensure that the URI 869 is signed and verified before delivering content. Otherwise, 870 the dCDN does not perform verification, regardless of whether 871 or not the URI is signed. 873 Type: Boolean 875 Mandatory-to-Specify: No. The default is true. 877 Property: issuers 879 Description: A list of valid Issuers against which the Issuer 880 claim in the signed JWT may be verified. 882 Type: Array of Strings 883 Mandatory-to-Specify: No. The default is an empty list. An 884 empty list means that any Issuer is acceptable. 886 Property: package-attribute 888 Description: The name to use for the URI Signing Package. 890 Type: String 892 Mandatory-to-Specify: No. The default is "URISigningPackage". 894 Property: jwt-header 896 Description: The header part of JWT that is used for generating 897 or verifying a signed JWT when the JWT token in the URI Signing 898 Package does not contain a header part. 900 Type: String 902 Mandatory-to-Specify: No. By default, the header is assumed to 903 be included in the JWT token. 905 The following is an example of a URI Signing metadata payload with 906 all default values: 908 { 909 "generic-metadata-type": "MI.UriSigning" 910 "generic-metadata-value": {} 911 } 913 The following is an example of a URI Signing metadata payload with 914 explicit values: 916 { 917 "generic-metadata-type": "MI.UriSigning" 918 "generic-metadata-value": 919 { 920 "enforce": true, 921 "issuers": ["csp", "ucdn1", "ucdn2"], 922 "package-attribute": "usp", 923 "jwt-header": "1234abcd" 924 } 925 } 927 4.5. CDNI Logging Interface 929 For URI Signing, the dCDN reports that enforcement of the access 930 control was applied to the request for content delivery. When the 931 request is denied due to enforcement of URI Signing, the reason is 932 logged. 934 The following CDNI Logging field for URI Signing SHOULD be supported 935 in the HTTP Request Logging Record as specified in CDNI Logging 936 Interface [RFC7937], using the new "cdni_http_request_v2" record-type 937 registered in Section 6.2.1. 939 o s-uri-signing (mandatory): 941 * format: 3DIGIT 943 * field value: this characterises the URI signing verification 944 performed by the Surrogate on the request. The allowed values 945 are: 947 + "000" : no signed JWT verification performed 949 + "200" : signed JWT verification performed and verified 951 + "400" : signed JWT verification performed and rejected 952 because of incorrect signature 954 + "401" : signed JWT verification performed and rejected 955 because of Expiration Time enforcement 957 + "402" : signed JWT verification performed and rejected 958 because of Client IP enforcement 960 + "403" : signed JWT verification performed and rejected 961 because of URI Container enforcement 963 + "404" : signed JWT verification performed and rejected 964 because of Issuer enforcement 966 + "405" : signed JWT verification performed and rejected 967 because of Not Before enforcement 969 + "406" : signed JWT verification performed and rejected 970 because of Subject enforcement 972 + "407" : signed JWT verification performed and rejected 973 because of Audience enforcement 975 + "408" : signed JWT verification performed and rejected 976 because of Nonce enforcement 978 + "409" : signed JWT verification performed and rejected 979 because of Version enforcement 981 + "410" : signed JWT verification performed and rejected 982 because of Critical Extention enforcement 984 + "500" : unable to perform signed JWT verification because of 985 malformed URI 987 * occurrence: there MUST be zero or exactly one instance of this 988 field. 990 o s-uri-signing-deny-reason (optional): 992 * format: QSTRING 994 * field value: a string for providing further information in case 995 the signed JWT was rejected, e.g., for debugging purposes. 997 * occurrence: there MUST be zero or exactly one instance of this 998 field. 1000 5. URI Signing Message Flow 1002 URI Signing supports both HTTP-based and DNS-based request routing. 1003 JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of 1004 representing claims to be transferred between two parties. The 1005 claims in a signed JWT are encoded as a JSON object that is used as 1006 the payload of a JSON Web Signature (JWS) structure or as the 1007 plaintext of a JSON Web Encryption (JWE) structure, enabling the 1008 claims to be digitally signed or integrity protected with a Message 1009 Authentication Code (MAC) and/or encrypted. 1011 5.1. HTTP Redirection 1013 For HTTP-based request routing, a set of information that is unique 1014 to a given end user content request is included in a signed JWT, 1015 using key information that is specific to a pair of adjacent CDNI 1016 hops (e.g., between the CSP and the uCDN or between the uCDN and a 1017 dCDN). This allows a CDNI hop to ascertain the authenticity of a 1018 given request received from a previous CDNI hop. 1020 The URI signing method (assuming HTTP redirection, iterative request 1021 routing, and a CDN path with two CDNs) includes the following steps: 1023 End-User dCDN uCDN CSP 1024 | | | | 1025 | 1.CDNI FCI interface used to | | 1026 | advertise URI Signing capability| | 1027 | |------------------->| | 1028 | | | | 1029 | 2.Provides information to verify signed JWT | 1030 | | |<-------------------| 1031 | | | | 1032 | 3.CDNI Metadata interface used to| | 1033 | provide URI Signing attributes| | 1034 | |<-------------------| | 1035 : : : : 1036 : (Later in time) : : : 1037 |4.Authorization request | | 1038 |------------------------------------------------------------->| 1039 | | | [Apply distribution 1040 | | | policy] | 1041 | | | | 1042 | | (ALT: Authorization decision) 1043 |5.Request is denied | | | 1044 |<-------------------------------------------------------------| 1045 | | | | 1046 |6.CSP provides signed URI | | 1047 |<-------------------------------------------------------------| 1048 | | | | 1049 |7.Content request | | | 1050 |---------------------------------------->| [Verifiy URI | 1051 | | | signature] | 1052 | | | | 1053 | | (ALT: Verification result) | 1054 |8.Request is denied | | | 1055 |<----------------------------------------| | 1056 | | | | 1057 |9.Re-sign URI and redirect to | | 1058 | dCDN (newly signed URI) | | 1059 |<----------------------------------------| | 1060 | | | | 1061 |10.Content request | | | 1062 |------------------->| [Verify URI | | 1063 | | signature] | | 1064 | | | | 1065 | (ALT: Verification result) | | 1066 |11.Request is denied| | | 1067 |<-------------------| | | 1068 | | | | 1069 |12.Content delivery | | | 1070 |<-------------------| | | 1071 : : : : 1072 : (Later in time) : : : 1073 |13.CDNI Logging interface to include URI Signing information | 1074 | |------------------->| | 1076 Figure 4: HTTP-based Request Routing with URI Signing 1078 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1079 the dCDN advertises its capabilities including URI Signing 1080 support to the uCDN. 1082 2. CSP provides to the uCDN the information needed to verify signed 1083 JWTs from that CSP. For example, this information may include a 1084 key value. 1086 3. Using the CDNI Metadata interface, the uCDN communicates to a 1087 dCDN the information needed to verify signed JWTs from the uCDN 1088 for the given CSP. For example, this information may include 1089 the URI query string parameter name for the URI Signing Package 1090 Attribute. 1092 4. When a UA requests a piece of protected content from the CSP, 1093 the CSP makes a specific authorization decision for this unique 1094 request based on its personal distribution policy. 1096 5. If the authorization decision is negative, the CSP rejects the 1097 request and sends an error code (e.g., 403 Forbidden) in the 1098 HTTP response. 1100 6. If the authorization decision is positive, the CSP computes a 1101 Signed URI that is based on unique parameters of that request 1102 and conveys it to the end user as the URI to use to request the 1103 content. 1105 7. On receipt of the corresponding content request, the uCDN 1106 verifies the signed JWT in the URI using the information 1107 provided by the CSP. 1109 8. If the verification is negative, the uCDN rejects the request 1110 and sends an error code 403 Forbidden in the HTTP response. 1112 9. If the verification is positive, the uCDN computes a Signed URI 1113 that is based on unique parameters of that request and provides 1114 it to the end user as the URI to use to further request the 1115 content from the dCDN. 1117 10. On receipt of the corresponding content request, the dCDN 1118 verifies the signed JWT in the Signed URI using the information 1119 provided by the uCDN in the CDNI Metadata. 1121 11. If the verification is negative, the dCDN rejects the request 1122 and sends an error code 403 Forbidden in the HTTP response. 1124 12. If the verification is positive, the dCDN serves the request and 1125 delivers the content. 1127 13. At a later time, the dCDN reports logging events that include 1128 URI signing information. 1130 With HTTP-based request routing, URI Signing matches well the general 1131 chain of trust model of CDNI both with symmetric and asymmetric keys 1132 because the key information only needs to be specific to a pair of 1133 adjacent CDNI hops. 1135 5.2. DNS Redirection 1137 For DNS-based request routing, the CSP and uCDN must agree on a trust 1138 model appropriate to the security requirements of the CSP's 1139 particular content. Use of asymmetric public/private keys allows for 1140 unlimited distribution of the public key to dCDNs. However, if a 1141 shared secret key is preferred, then the CSP may want to restrict the 1142 distribution of the key to a (possibly empty) subset of trusted 1143 dCDNs. Authorized Delivery CDNs need to obtain the key information 1144 to verify the Signed URI. 1146 The URI signing method (assuming iterative DNS request routing and a 1147 CDN path with two CDNs) includes the following steps. 1149 End-User dCDN uCDN CSP 1150 | | | | 1151 | 1.CDNI FCI interface used to | | 1152 | advertise URI Signing capability| | 1153 | |------------------->| | 1154 | | | | 1155 | 2.Provides information to verify signed JWT | 1156 | | |<-------------------| 1157 | 3.CDNI Metadata interface used to| | 1158 | provide URI Signing attributes| | 1159 | |<-------------------| | 1160 : : : : 1161 : (Later in time) : : : 1162 |4.Authorization request | | 1163 |------------------------------------------------------------->| 1164 | | | [Apply distribution 1165 | | | policy] | 1166 | | | | 1167 | | (ALT: Authorization decision) 1168 |5.Request is denied | | | 1169 |<-------------------------------------------------------------| 1170 | | | | 1171 |6.Provides signed URI | | 1172 |<-------------------------------------------------------------| 1173 | | | | 1174 |7.DNS request | | | 1175 |---------------------------------------->| | 1176 | | | | 1177 |8.Redirect DNS to dCDN | | 1178 |<----------------------------------------| | 1179 | | | | 1180 |9.DNS request | | | 1181 |------------------->| | | 1182 | | | | 1183 |10.IP address of Surrogate | | 1184 |<-------------------| | | 1185 | | | | 1186 |11.Content request | | | 1187 |------------------->| [Verify URI | | 1188 | | signature] | | 1189 | | | | 1190 | (ALT: Verification result) | | 1191 |12.Request is denied| | | 1192 |<-------------------| | | 1193 | | | | 1194 |13.Content delivery | | | 1195 |<-------------------| | | 1196 : : : : 1197 : (Later in time) : : : 1198 |14.CDNI Logging interface to report URI Signing information | 1199 | |------------------->| | 1201 Figure 5: DNS-based Request Routing with URI Signing 1203 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1204 the dCDN advertises its capabilities including URI Signing 1205 support to the uCDN. 1207 2. CSP provides to the uCDN the information needed to verify 1208 cryptographic signatures from that CSP. For example, this 1209 information may include a key. 1211 3. Using the CDNI Metadata interface, the uCDN communicates to a 1212 dCDN the information needed to verify cryptographic signatures 1213 from the CSP (e.g., the URI query string parameter name for the 1214 URI Signing Package Attribute). In the case of symmetric key, 1215 the uCDN checks if the dCDN is allowed by CSP to obtain the 1216 shared secret key. 1218 4. When a UA requests a piece of protected content from the CSP, 1219 the CSP makes a specific authorization decision for this unique 1220 request based on its arbitrary distribution policy. 1222 5. If the authorization decision is negative, the CSP rejects the 1223 request and sends an error code (e.g., 403 Forbidden) in the 1224 HTTP response. 1226 6. If the authorization decision is positive, the CSP computes a 1227 cryptographic signature that is based on unique parameters of 1228 that request and includes it in the URI provided to the end user 1229 to request the content. 1231 7. End user sends DNS request to the uCDN. 1233 8. On receipt of the DNS request, the uCDN redirects the request to 1234 the dCDN. 1236 9. End user sends DNS request to the dCDN. 1238 10. On receipt of the DNS request, the dCDN responds with IP address 1239 of one of its Surrogates. 1241 11. On receipt of the corresponding content request, the dCDN 1242 verifies the cryptographic signature in the URI using the 1243 information provided by the uCDN in the CDNI Metadata. 1245 12. If the verification is negative, the dCDN rejects the request 1246 and sends an error code 403 Forbidden in the HTTP response. 1248 13. If the verification is positive, the dCDN serves the request and 1249 delivers the content. 1251 14. At a later time, dCDN reports logging events that includes URI 1252 signing information. 1254 With DNS-based request routing, URI Signing matches well the general 1255 chain of trust model of CDNI when used with asymmetric keys because 1256 the only key information that needs to be distributed across 1257 multiple, possibly untrusted, CDNI hops is the public key, which is 1258 generally not confidential. 1260 With DNS-based request routing, URI Signing does not match well the 1261 general chain of trust model of CDNI when used with symmetric keys 1262 because the symmetric key information needs to be distributed across 1263 multiple CDNI hops, to CDNs with which the CSP may not have a trust 1264 relationship. This raises a security concern for applicability of 1265 URI Signing with symmetric keys in case of DNS-based inter-CDN 1266 request routing. 1268 6. IANA Considerations 1270 6.1. CDNI Payload Type 1272 This document requests the registration of the following CDNI Payload 1273 Type under the IANA "CDNI Payload Types" registry: 1275 +---------------+---------------+ 1276 | Payload Type | Specification | 1277 +---------------+---------------+ 1278 | MI.UriSigning | RFCthis | 1279 +---------------+---------------+ 1281 [RFC Editor: Please replace RFCthis with the published RFC number for 1282 this document.] 1284 6.1.1. CDNI UriSigning Payload Type 1286 Purpose: The purpose of this payload type is to distinguish 1287 UriSigning MI objects (and any associated capability advertisement). 1289 Interface: MI/FCI 1291 Encoding: see Section 4.4 1293 6.2. CDNI Logging Record Type 1295 This document requests the registration of the following CDNI Logging 1296 record-type under the IANA "CDNI Logging record-types" registry: 1298 +----------------------+-----------+--------------------------------+ 1299 | record-types | Reference | Description | 1300 +----------------------+-----------+--------------------------------+ 1301 | cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | 1302 | | | Record version 1 for content | 1303 | | | delivery using HTTP, to | 1304 | | | include URI Signing logging | 1305 | | | fields | 1306 +----------------------+-----------+--------------------------------+ 1308 [RFC Editor: Please replace RFCthis with the published RFC number for 1309 this document.] 1311 6.2.1. CDNI Logging Record Version 2 for HTTP 1313 The "cdni_http_request_v2" record-type supports all of the fields 1314 supported by the "cdni_http_request_v1" record-type [RFC7937] plus 1315 the two additional fields "s-uri-signing" and "s-uri-signing-deny- 1316 reason", registered by this document in Section 6.3. The name, 1317 format, field value, and occurence information for the two new fields 1318 can be found in Section 4.5 of this document. 1320 6.3. CDNI Logging Field Names 1322 This document requests the registration of the following CDNI Logging 1323 fields under the IANA "CDNI Logging Field Names" registry: 1325 +---------------------------+-----------+ 1326 | Field Name | Reference | 1327 +---------------------------+-----------+ 1328 | s-uri-signing | RFCthis | 1329 | s-uri-signing-deny-reason | RFCthis | 1330 +---------------------------+-----------+ 1332 [RFC Editor: Please replace RFCthis with the published RFC number for 1333 this document.] 1335 6.4. CDNI URI Signing Signed Token Transport 1337 The IANA is requested to create a new "CDNI URI Signing Signed Token 1338 Transport" subregistry in the "Content Delivery Networks 1339 Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing 1340 Signed Token Transport" namespace defines the valid values that may 1341 be in the Signed Token Transport (cdnistt) JWT claim. Additions to 1342 the Signed Token Transport namespace conform to the "Specification 1343 Required" policy as defined in [RFC8126]. 1345 The following table defines the initial Enforcement Information 1346 Elements: 1348 +-------+-------------------------------------------+---------+ 1349 | Value | Description | RFC | 1350 +-------+-------------------------------------------+---------+ 1351 | 0 | Designates token transport is not enabled | RFCthis | 1352 | 1 | Designates token transport via cookie | RFCthis | 1353 +-------+-------------------------------------------+---------+ 1355 [RFC Editor: Please replace RFCthis with the published RFC number for 1356 this document.] 1358 6.5. JSON Web Token Claims Registration 1360 This specification registers the following Claims in the IANA "JSON 1361 Web Token Claims" registry [IANA.JWT.Claims] established by 1362 [RFC7519]. 1364 6.5.1. Registry Contents 1366 o Claim Name: "cdniv" 1367 o Claim Description: CDNI Claim Set Version 1368 o Change Controller: IESG 1369 o Specification Document(s): Section 2.1.8 of [[ this specification 1370 ]] 1372 o Claim Name: "cdnicrit" 1373 o Claim Description: CDNI Critical Claims Set 1374 o Change Controller: IESG 1375 o Specification Document(s): Section 2.1.9 of [[ this specification 1376 ]] 1378 o Claim Name: "cdniip" 1379 o Claim Description: CDNI IP Address 1380 o Change Controller: IESG 1381 o Specification Document(s): Section 2.1.10 of [[ this specification 1382 ]] 1384 o Claim Name: "cdniuc" 1385 o Claim Description: CDNI URI Container 1386 o Change Controller: IESG 1387 o Specification Document(s): Section 2.1.11 of [[ this specification 1388 ]] 1390 o Claim Name: "cdniets" 1391 o Claim Description: CDNI Expiration Time Setting for Signed Token 1392 Renewal 1393 o Change Controller: IESG 1394 o Specification Document(s): Section 2.1.12 of [[ this specification 1395 ]] 1397 o Claim Name: "cdnistt" 1398 o Claim Description: CDNI Signed Token Transport Method for Signed 1399 Token Renewal 1400 o Change Controller: IESG 1401 o Specification Document(s): Section 2.1.13 of [[ this specification 1402 ]] 1404 o Claim Name: "cdnistd" 1405 o Claim Description: CDNI Signed Token Depth 1406 o Change Controller: IESG 1407 o Specification Document(s): Section 2.1.14 of [[ this specification 1408 ]] 1410 7. Security Considerations 1412 This document describes the concept of URI Signing and how it can be 1413 used to provide access authorization in the case of CDNI. The 1414 primary goal of URI Signing is to make sure that only authorized UAs 1415 are able to access the content, with a CSP being able to authorize 1416 every individual request. It should be noted that URI Signing is not 1417 a content protection scheme; if a CSP wants to protect the content 1418 itself, other mechanisms, such as DRM, are more appropriate. 1420 In general, it holds that the level of protection against 1421 illegitimate access can be increased by including more claims in the 1422 signed JWT. The current version of this document includes claims for 1423 enforcing Issuer, Client IP Address, Not Before time, and Expiration 1424 Time, however this list can be extended with other, more complex, 1425 attributes that are able to provide some form of protection against 1426 some of the vulnerabilities highlighted below. 1428 That said, there are a number of aspects that limit the level of 1429 security offered by URI Signing and that anybody implementing URI 1430 Signing should be aware of. 1432 o Replay attacks: A (valid) Signed URI may be used to perform replay 1433 attacks. The vulnerability to replay attacks can be reduced by 1434 picking a relatively short window between the Not Before time and 1435 Expiration Time attributes, although this is limited by the fact 1436 that any HTTP-based request needs a window of at least a couple of 1437 seconds to prevent a sudden network issues from denying legitimate 1438 UAs access to the content. One may also reduce exposure to replay 1439 attacks by including a unique one-time access ID via the Nonce 1440 attribute (jti claim). Whenever the dCDN receives a request with 1441 a given unique ID, it adds that ID to the list of 'used' IDs. In 1442 the case an illegitimate UA tries to use the same URI through a 1443 replay attack, the dCDN can deny the request based on the already- 1444 used access ID. 1446 o Illegitimate clients behind a NAT: In cases where there are 1447 multiple users behind the same NAT, all users will have the same 1448 IP address from the point of view of the dCDN. This results in 1449 the dCDN not being able to distinguish between different users 1450 based on Client IP Address which can lead to illegitimate users 1451 being able to access the content. One way to reduce exposure to 1452 this kind of attack is to not only check for Client IP but also 1453 for other attributes, e.g., attributes that can be found in HTTP 1454 headers. 1456 The shared key between CSP and uCDN may be distributed to dCDNs - 1457 including cascaded CDNs. Since this key can be used to legitimately 1458 sign a URL for content access authorization, it is important to know 1459 the implications of a compromised shared key. 1461 If a shared key usable for signing is compromised, an attacker can 1462 use it to perform a denial-of-service attack by forcing the CDN to 1463 evaluate prohibitively expensive regular expressions embedded in a 1464 cdniuc claim. As a result, compromised keys should be timely revoked 1465 in order to prevent exploitation. 1467 8. Privacy 1469 The privacy protection concerns described in CDNI Logging Interface 1470 [RFC7937] apply when the client's IP address (cdniip) is embedded in 1471 the Signed URI. For this reason, the mechanism described in 1472 Section 2 encrypts the Client IP before including it in the URI 1473 Signing Package (and thus the URL itself). 1475 9. Acknowledgements 1477 The authors would like to thank the following people for their 1478 contributions in reviewing this document and providing feedback: 1479 Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan 1480 York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana 1481 Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris 1482 Lemmons. 1484 10. Contributors 1486 In addition, the authors would also like to make special mentions for 1487 certain people who contributed significant sections to this document. 1489 o Matt Caulfield provided content for the CDNI Metadata Interface 1490 section. 1492 o Emmanuel Thomas provided content for HTTP Adaptive Streaming. 1494 o Matt Miller provided consultation on JWT usage as well as code to 1495 generate working JWT examples. 1497 11. References 1499 11.1. Normative References 1501 [POSIX.1] "The Open Group Base Specifications Issue 7", IEEE 1502 Std 1003.1 2018 Edition, Jan 2018, 1503 . 1505 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1506 DOI 10.17487/RFC0791, September 1981, 1507 . 1509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1510 Requirement Levels", BCP 14, RFC 2119, 1511 DOI 10.17487/RFC2119, March 1997, 1512 . 1514 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1515 Resource Identifier (URI): Generic Syntax", STD 66, 1516 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1517 . 1519 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1520 Address Text Representation", RFC 5952, 1521 DOI 10.17487/RFC5952, August 2010, 1522 . 1524 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1525 DOI 10.17487/RFC6265, April 2011, 1526 . 1528 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1529 Keranen, A., and P. Hallam-Baker, "Naming Things with 1530 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1531 . 1533 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1534 Protocol (HTTP/1.1): Message Syntax and Routing", 1535 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1536 . 1538 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1539 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1540 . 1542 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1543 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1544 . 1546 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 1547 and R. Peterkofsky, "Content Distribution Network 1548 Interconnection (CDNI) Logging Interface", RFC 7937, 1549 DOI 10.17487/RFC7937, August 2016, 1550 . 1552 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1553 "Content Delivery Network Interconnection (CDNI) 1554 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1555 . 1557 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1558 Writing an IANA Considerations Section in RFCs", BCP 26, 1559 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1560 . 1562 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1563 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1564 May 2017, . 1566 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1567 Interchange Format", STD 90, RFC 8259, 1568 DOI 10.17487/RFC8259, December 2017, 1569 . 1571 11.2. Informative References 1573 [IANA.JWT.Claims] 1574 IANA, "JSON Web Token Claims", 1575 . 1577 [MPEG-DASH] 1578 ISO, "Information technology -- Dynamic adaptive streaming 1579 over HTTP (DASH) -- Part 1: Media presentation description 1580 and segment format", ISO/IEC 23009-1:2014, Edition 2, 05 1581 2014, . 1583 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1584 "Network Time Protocol Version 4: Protocol and Algorithms 1585 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1586 . 1588 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1589 Distribution Network Interconnection (CDNI) Problem 1590 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1591 2012, . 1593 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 1594 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 1595 Content Distribution Network Interconnection (CDNI)", 1596 RFC 6983, DOI 10.17487/RFC6983, July 2013, 1597 . 1599 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1600 "Framework for Content Distribution Network 1601 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1602 August 2014, . 1604 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1605 Network Interconnection (CDNI) Requirements", RFC 7337, 1606 DOI 10.17487/RFC7337, August 2014, 1607 . 1609 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1610 DOI 10.17487/RFC7517, May 2015, 1611 . 1613 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1614 "Request Routing Redirection Interface for Content 1615 Delivery Network (CDN) Interconnection", RFC 7975, 1616 DOI 10.17487/RFC7975, October 2016, 1617 . 1619 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1620 R., and K. Ma, "Content Delivery Network Interconnection 1621 (CDNI) Request Routing: Footprint and Capabilities 1622 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1623 . 1625 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 1626 RFC 8216, DOI 10.17487/RFC8216, August 2017, 1627 . 1629 Appendix A. Signed URI Package Example 1631 This section contains three examples of token usage: a simple example 1632 with only the required claim present, a complex example which 1633 demonstrates the full JWT claims set, including an encrypted Client 1634 IP (cdniip), and one that uses a Signed Token Renewal. 1636 Note: All of the examples have whitespace added to improve formatting 1637 and readability, but are not present in the generated content. 1639 All examples use the following JWK Set [RFC7517]: 1641 { "keys": [ 1642 { 1643 "kty": "EC", 1644 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1645 "use": "sig", 1646 "alg": "ES256", 1647 "crv": "P-256", 1648 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1649 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA" 1650 }, 1651 { 1652 "kty": "EC", 1653 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1654 "use": "sig", 1655 "alg": "ES256", 1656 "crv": "P-256", 1657 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1658 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", 1659 "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" 1660 }, 1661 { 1662 "kty": "oct", 1663 "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", 1664 "use": "enc", 1665 "alg": "A128GCM", 1666 "k": "4uFxxV7fhNmrtiah2d1fFg" 1667 } 1668 ]} 1670 Note: They are the public signing key, the private signing key, and 1671 the shared secret enctyption key, respectively. The public and 1672 private signing keys have the same fingerprint and only vary by the 1673 'd' parameter that is missing from the public signing key. 1675 A.1. Simple Example 1677 This example is a simple common usage example containing a minimal 1678 subset of claims that the authors find most useful. 1680 The JWT Claim Set before signing: 1682 Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the 1683 URL Segment form ([RFC6920] Section 5) of "http://cdni.example/foo/ 1684 bar". 1686 { 1687 "exp": 1474243500, 1688 "iss": "uCDN Inc", 1689 "cdniuc": "hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" 1690 } 1692 The signed JWT: 1694 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1695 dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE0NzQyNDM1MDAsImlzcyI6InVDRE4gS 1696 W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV 1697 wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.qzzAB9akC-HoEzQrkOoODWjMC0PEZRrmWz 1698 2rSMcpLtvxyxVodlB2xcpl4J4ABhLLOJzgzL9B39TljTqZApSOpQ 1700 A.2. Complex Example 1702 This example uses all fields except for those dealing with Signed 1703 Token Renewal, including Client IP (cdniip) and Subject (sub) which 1704 are encrpyted. This significantly increases the size of the signed 1705 JWT token. 1707 JWE for Client IP (cdniip) of [2001:db8::1/32]: 1709 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1710 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..SuzoOnfg-GVh-BOc.wQ9iS 1711 R1sTj-A04CiDmvcgg.9Ts_cIEUw6Yc6U5HaH1UPQ 1713 JWE for Subject (sub) of "UserToken": 1715 eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST 1716 NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..XsJ7ySeChORSIojp.R1U8E 1717 SGU2NnW.DWR8pTbeCwQZca6SitfX_g 1719 The JWT Claim Set before signing: 1721 { 1722 "aud": "dCDN LLC", 1723 "sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4 1724 QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..XsJ7ySeChORS 1725 Iojp.R1U8ESGU2NnW.DWR8pTbeCwQZca6SitfX_g", 1726 "cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY 1727 mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..SuzoOnfg- 1728 GVh-BOc.wQ9iSR1sTj-A04CiDmvcgg.9Ts_cIEUw6Yc6U5HaH1UPQ", 1729 "cdniv": 1, 1730 "exp": 1474243500, 1731 "iat": 1474243200, 1732 "iss": "uCDN Inc", 1733 "jti": "5DAafLhZAfhsbe", 1734 "nbf": 1474243200, 1735 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png" 1736 } 1738 The signed JWT: 1740 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1741 dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib 1742 U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA 1743 0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T 1744 0NKOS4uWHNKN3lTZUNoT1JTSW9qcC5SMVU4RVNHVTJOblcuRFdSOHBUYmVDd1FaY2E 1745 2U2l0ZlhfZyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja 1746 m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp 1747 2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uU3V6b09uZmctR1ZoLUJPYy53U 1748 TlpU1Ixc1RqLUEwNENpRG12Y2dnLjlUc19jSUVVdzZZYzZVNUhhSDFVUFEiLCJjZG5 1749 pdiI6MSwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6InVDR 1750 E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE0NzQyNDMyMDAsImN 1751 kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde 1752 zN9XFwucG5nIn0.XEi1NeP8Lzh6ECcbp6EoqYlnJGikaGp6F3lIJ7ZJt3bim6tOtuD 1753 pCQxmEQxobzIpWOCNdpB8kvxM_s95brKjNQ 1755 A.3. Signed Token Renewal Example 1757 This example uses fields for Signed Token Renewal. 1759 The JWT Claim Set before signing: 1761 { 1762 "cdniets": 30, 1763 "cdnistt": 1, 1764 "cdnistd": 2, 1765 "exp": 1474243500, 1766 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1767 } 1768 The signed JWT: 1770 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1771 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1772 XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTAwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1773 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.wsSvwxY8mtRax7HK_ 1774 dro_l6m-mM-HYdeaUoTSgVS5XTIhXBsCPsYQncsradmgmOWHDDOxsSMVVTjHe5E5YH 1775 ZlQ 1777 Once the server verifies the signed JWT it will return a new signed 1778 JWT with an updated expiry time (exp) as shown below. Note the 1779 expiry time is increased by the expiration time setting (cdniets) 1780 value. 1782 The JWT Claim Set before signing: 1784 { 1785 "cdniets": 30, 1786 "cdnistt": 1, 1787 "cdnistd": 2, 1788 "exp": 1474243530, 1789 "cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts" 1790 } 1792 The signed JWT: 1794 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1795 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua 1796 XN0ZCI6MiwiZXhwIjoxNDc0MjQzNTMwLCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R 1797 uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.SITeoIVZ8-yeE_GBV 1798 jYEo1P2LN-EId1gEJ6baR3Au7Dzh2o_O7LhH3k6wHY081sYMdXHucB0P5ocp-r7gqe 1799 ruQ 1801 Authors' Addresses 1803 Ray van Brandenburg 1804 Tiledmedia 1805 Anna van Buerenplein 1 1806 Den Haag 2595DA 1807 The Netherlands 1809 Phone: +31 88 866 7000 1810 Email: ray@tiledmedia.com 1811 Kent Leung 1812 Cisco Systems, Inc. 1813 3625 Cisco Way 1814 San Jose, CA 95134 1815 United States 1817 Phone: +1 408 526 5030 1818 Email: kleung@cisco.com 1820 Phil Sorber 1821 Apple, Inc. 1822 1800 Wazee Street 1823 Suite 410 1824 Denver, CO 80202 1825 United States 1827 Email: sorber@apple.com