idnits 2.17.1 draft-ietf-cdni-uri-signing-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7519]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 274 has weird spacing: '...I(after v ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Not Before (nbf) [optional] - The semantics in [RFC7519] Section 4.1.5 MUST be followed, though URI Signing implementations MUST not allow for any time synchronization "leeway". Note: The time on the entities that generate and validate the signed URI SHOULD be in sync. In the CDNI case, this means that the CSP, uCDN, and dCDN servers need to be time-synchronized. It is RECOMMENDED to use NTP [RFC5905] for time synchronization. If the CDN validating the signed JWT does not support Not Before time validation, or if the Not Before time in the signed JWT corresponds to a time later than the time of the content request, the CDN MUST reject the request. If the received signed JWT contains a Not Before time claim, then any JWT subsequently generated for CDNI redirection MUST also contain a Not Before time claim, and the Not Before time value MUST be the same as in the received signed JWT. A signed JWT generated for CDNI redirection MUST NOT add a Not Before time claim if no Not Before time claim existed in the received signed JWT. -- The document date (May 18, 2017) is 2534 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6707 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 3 errors (**), 0 flaws (~~), 3 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 19, 2017 Cisco Systems, Inc. 6 P. Sorber 7 Comcast Cable Communications 8 M. Miller 9 Mozilla 10 May 18, 2017 12 URI Signing for CDN Interconnection (CDNI) 13 draft-ietf-cdni-uri-signing-11 15 Abstract 17 This document describes how the concept of URI signing supports the 18 content access control requirements of CDNI and proposes a URI 19 signing method as a JSON Web Token (JWT) [RFC7519] profile. 21 The proposed URI signing method specifies the information needed to 22 be included in the URI to transmit the signed JWT as well as the 23 claims needed by the signed JWT to authorize a UA. The mechanism 24 described can be used both in CDNI and single CDN scenarios. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 19, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Background and overview on URI Signing . . . . . . . . . 4 63 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 5 64 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 65 2. JWT Format and Processing Requirements . . . . . . . . . . . 8 66 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9 67 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 9 68 2.1.2. URI Container (sub) claim . . . . . . . . . . . . . . 10 69 2.1.3. Client IP (aud) claim . . . . . . . . . . . . . . . . 10 70 2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 10 71 2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11 72 2.1.6. Issued At (ait) claim . . . . . . . . . . . . . . . . 11 73 2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 11 74 2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12 75 2.1.9. URI Container Forms . . . . . . . . . . . . . . . . . 12 76 2.1.9.1. URI Simple Container (uri:) . . . . . . . . . . . 12 77 2.1.9.2. URI Pattern Container (uri-pattern:) . . . . . . 12 78 2.1.9.3. URI Regular Expression Container (uri-regex:) . . 13 79 2.1.9.4. URI Hash Container (uri-hash:) . . . . . . . . . 13 80 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 14 81 3. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 14 82 3.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 14 83 3.2. CDNI Footprint & Capabilities Advertisement Interface . . 14 84 3.3. CDNI Request Routing Redirection Interface . . . . . . . 14 85 3.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 14 86 3.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 16 87 4. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 17 88 4.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 17 89 4.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 20 90 5. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 23 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 92 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 23 93 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 23 94 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 24 95 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 24 97 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 24 98 6.4. JSON Web Token Claims Registration . . . . . . . . . . . 24 99 6.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 25 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 101 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 104 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 105 10.2. Informative References . . . . . . . . . . . . . . . . . 27 106 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 28 107 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 29 108 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 29 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 111 1. Introduction 113 This document describes the concept of URI Signing and how it can be 114 used to provide access authorization in the case of redirection 115 between interconnected CDNs (CDNI) and between a Content Service 116 Provider (CSP) and a CDN. The primary goal of URI Signing is to make 117 sure that only authorized User Agents (UAs) are able to access the 118 content, with a CSP being able to authorize every individual request. 119 It should be noted that URI Signing is not a content protection 120 scheme; if a CSP wants to protect the content itself, other 121 mechanisms, such as Digital Rights Management (DRM), are more 122 appropriate. In addition to access control, URI Signing also has 123 benefits in reducing the impact of denial-of-service attacks. 125 The overall problem space for CDN Interconnection (CDNI) is described 126 in CDNI Problem Statement [RFC6707]. This document, along with the 127 CDNI Requirements [RFC7337] document and the CDNI Framework 128 [RFC7336], describes the need for interconnected CDNs to be able to 129 implement an access control mechanism that enforces the CSP's 130 distribution policy. 132 Specifically, CDNI Framework [RFC7336] states: 134 "The CSP may also trust the CDN operator to perform actions such as 135 ..., and to enforce per-request authorization performed by the CSP 136 using techniques such as URI signing." 138 In particular, the following requirement is listed in CDNI 139 Requirements [RFC7337]: 141 MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of 142 authorization checks and validation that are to be performed by the 143 Surrogate before delivery. For example, this could potentially 144 include the need to validate information (e.g., Expiry time, Client 145 IP address) required for access authorization. 147 This document proposes a method of signing URIs that allows 148 Surrogates in interconnected CDNs to enforce a per-request 149 authorization performed by the CSP. Splitting the role of performing 150 per-request authorization by the CSP and the role of validating this 151 authorization by the CDN allows any arbitrary distribution policy to 152 be enforced across CDNs without the need of CDNs to have any 153 awareness of the actual CSP distribution policy. 155 The representation of this method is a Signed JSON Web Token (JWT) 156 [RFC7519]. 158 1.1. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 This document uses the terminology defined in CDNI Problem Statement 165 [RFC6707]. 167 This document also uses the terminology of JSON Web Token (JWT) 168 [RFC7519]. 170 In addition, the following terms are used throughout this document: 172 o Signed URI: A URI for which a signed JWT is provided. 174 o Target CDN URI: URI created by the CSP to direct a UA towards the 175 Upstream CDN (uCDN). The Target CDN URI can be signed by the CSP 176 and verified by the uCDN and possibly further Downstream CDNs 177 (dCDNs). 179 o Redirection URI: URI created by the uCDN to redirect a UA towards 180 the dCDN. The Redirection URI can be signed by the uCDN and 181 verified by the dCDN. In a cascaded CDNI scenario, there can be 182 more than one Redirection URI. 184 1.2. Background and overview on URI Signing 186 A CSP and CDN are assumed to have a trust relationship that enables 187 the CSP to authorize access to a content item by including a set of 188 claims in the form of a signed JWT in the URI before redirecting a UA 189 to the CDN. Using these attributes, it is possible for a CDN to 190 check an incoming content request to see whether it was authorized by 191 the CSP (e.g., based on the UA's IP address or a time window). To 192 prevent the UA from altering the claims a signed JWT is REQUIRED. 194 Figure 1, shown below, presents an overview of the URI Signing 195 mechanism in the case of a CSP with a single CDN. When the UA 196 browses for content on CSP's website (#1), it receives HTML web pages 197 with embedded content URIs. Upon requesting these URIs, the CSP 198 redirects to a CDN, creating a Target CDN URI (#2) (alternatively, 199 the Target CDN URI itself is embedded in the HTML). The Target CDN 200 URI is the Signed URI which may include the IP address of the UA and/ 201 or a time window and always contains the signed JWT which is 202 generated by the CSP using a shared secret or private key. Once the 203 UA receives the response with the Signed URI, it sends a new HTTP 204 request using the Signed URI to the CDN (#3). Upon receiving the 205 request, the CDN checks to see if the Signed URI is authentic by 206 verifying the signed JWT. If applicable, it checks whether the IP 207 address of the HTTP request matches that in the Signed URI and if the 208 time window is still valid. After these claims are confirmed to be 209 valid, the CDN delivers the content (#4). 211 -------- 212 / \ 213 | CSP |< * * * * * * * * * * * 214 \ / Trust * 215 -------- relationship * 216 ^ | * 217 | | * 218 1. Browse | | 2. Signed * 219 for | | URI * 220 content | | * 221 | v v 222 +------+ 3. Signed URI -------- 223 | User |----------------->/ \ 224 | Agent| | CDN | 225 | |<-----------------\ / 226 +------+ 4. Content -------- 227 Delivery 229 Figure 1: Figure 1: URI Signing in a CDN Environment 231 1.3. CDNI URI Signing Overview 233 In a CDNI environment, URI Signing operates the same way in the 234 initial steps #1 and #2 but the later steps involve multiple CDNs in 235 the process of delivering the content. The main difference from the 236 single CDN case is a redirection step between the uCDN and the dCDN. 237 In step #3, UA may send an HTTP request or a DNS request. Depending 238 on whether HTTP-based or DNS-based request routing is used, the uCDN 239 responds by directing the UA towards the dCDN using either a 240 Redirection URI (which is a Signed URI generated by the uCDN) or a 241 DNS reply, respectively (#4). Once the UA receives the response, it 242 sends the Redirection URI/Target CDN URI to the dCDN (#5). The 243 received URI is validated by the dCDN before delivering the content 244 (#6). This is depicted in the figure below. Note: The CDNI call 245 flows are covered in Detailed URI Signing Operation (Section 4). 247 +-------------------------+ 248 |Request Redirection Modes| 249 +-------------------------+ 250 | a) HTTP | 251 | b) DNS | 252 +-------------------------+ 253 -------- 254 / \< * * * * * * * * * * * * * * 255 | CSP |< * * * * * * * * * * * * 256 \ / Trust * * 257 -------- relationship * * 258 ^ | * * 259 | | 2. Signed * * 260 1. Browse | | URI in * * 261 for | | HTML * * 262 content | | * * 263 | v 3.a)Signed URI v * 264 +------+ b)DNS request -------- * Trust 265 | User |----------------->/ \ * relationship 266 | Agent| | uCDN | * (optional) 267 | |<-----------------\ / * 268 +------+ 4.a)Redirection URI------- * 269 ^ | b)DNS Reply ^ * 270 | | * * 271 | | Trust relationship * * 272 | | * * 273 6. Content | | 5.a)Redirection URI * * 274 delivery | | b)Signed URI(after v v 275 | | DNS exchange) -------- 276 | +---------------------->/ \ [May be 277 | | dCDN | cascaded 278 +--------------------------\ / CDNs] 279 -------- 281 +-----------------------------------------+ 282 | Key | Asymmetric | Symmetric | 283 +-----------------------------------------+ 284 |HTTP |Public key (uCDN)|Shared key (uCDN)| 285 |DNS |Public key (CSP) |Shared key (CSP) | 286 +-----------------------------------------+ 288 Figure 2: URI Signing in a CDNI Environment 290 The trust relationships between CSP, uCDN, and dCDN have direct 291 implications for URI Signing. In the case shown in Figure 2, the CDN 292 that the CSP has a trust relationship with is the uCDN. The delivery 293 of the content may be delegated to the dCDN, which has a relationship 294 with the uCDN but may have no relationship with the CSP. 296 In CDNI, there are two methods for request routing: DNS-based and 297 HTTP-based. For DNS-based request routing, the Signed URI (i.e., 298 Target CDN URI) provided by the CSP reaches the dCDN directly. In 299 the case where the dCDN does not have a trust relationship with the 300 CSP, this means that either an asymmetric public/private key method 301 needs to be used for computing the signed JWT (because the CSP and 302 dCDN are not able to exchange symmetric shared secret keys), or the 303 CSP needs to allow the uCDN to redistribute shared keys to a subset 304 of their dCDNs. 306 For HTTP-based request routing, the Signed URI (i.e., Target CDN URI) 307 provided by the CSP reaches the uCDN. After this URI has been 308 verified to be correct by the uCDN, the uCDN creates and signs a new 309 Redirection URI to redirect the UA to the dCDN. Since this new URI 310 could have a new signed JWT, a new signature can be based around the 311 trust relationship between the uCDN and dCDN, and the relationship 312 between the dCDN and CSP is not relevant. Given the fact that such a 313 relationship between uCDN and dCDN always exists, both asymmetric 314 public/private keys and symmetric shared secret keys can be used for 315 URI Signing with HTTP-based request routing. Note that the signed 316 Redirection URI MUST maintain the same, or higher, level of security 317 as the original Signed URI. 319 1.4. URI Signing in a non-CDNI context 321 While the URI signing method defined in this document was primarily 322 created for the purpose of allowing URI Signing in CDNI scenarios, 323 e.g., between a uCDN and a dCDN or between a CSP and a dCDN, there is 324 nothing in the defined URI Signing method that precludes it from 325 being used in a non-CDNI context. As such, the described mechanism 326 could be used in a single-CDN scenario such as shown in Figure 1 in 327 Section 1.2, for example to allow a CSP that uses different CDNs to 328 only have to implement a single URI Signing mechanism. 330 2. JWT Format and Processing Requirements 332 The concept behind URI Signing is based on embedding a signed JSON 333 Web Token (JWT) [RFC7519] in the UA request: The signed JWT contains 334 a number of claims that can be validated to ensure the UA has 335 legitimate access to the content. 337 This document specifies the following attribute for embedding a 338 signed JWT in a Target CDN URI or Redirection URI: 340 o URI Signing Package (URISigningPackage): The URI attribute that 341 encapsulates all the URI Signing claims in a signed JWT encoded 342 format. This attribute is exposed in the Signed URI as a URI 343 query parameter or as a URL path parameter. 345 The parameter name of the URI Signing Package Attribute is defined in 346 the CDNI Metadata (Section 3.4). If the CDNI Metadata interface is 347 not used, or does not include a parameter name for the URI Signing 348 Package Attribute, the parameter name can be set by configuration 349 (out of scope of this document). 351 2.1. JWT Claims 353 This section identifies the set of claims that can be used to enforce 354 the CSP distribution policy. New claims can be introduced in the 355 future to extend the distribution policy capabilities. 357 In order to provide distribution policy flexibility, the exact subset 358 of claims used in a given signed JWT is a runtime decision. Claim 359 requirements are defined in the CDNI Metadata (Section 3.4) If the 360 CDNI Metadata interface is not used, or does not include claim 361 requirements, the claim requirements can be set by configuration (out 362 of scope of this document). 364 The following claims (where the "JSON Web Token Claims" registry 365 claim name is specified in parenthesis below) are used to enforce the 366 distribution policies. All of the listed claims are mandatory to 367 implement in a URI Signing implementation, but are not mandatory to 368 use in a given signed JWT. (The "optional" and "mandatory" 369 identifiers in square brackets refer to whether or not a given claim 370 MUST be present in a URI Signing JWT.) A CDN MUST be able to parse 371 and process all of the claims listed below. If the signed JWT 372 contains any other claims which the CDN does not understand (i.e., is 373 unable to parse and process), the CDN MUST reject the request. 375 Note: See the Security Considerations (Section 7) section on the 376 limitations of using an expiration time and client IP address for 377 distribution policy enforcement. 379 2.1.1. Issuer (iss) claim 381 Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1 382 MUST be followed. This claim MAY be used to validate authorization 383 of the issuer of a signed JWT and also MAY be used to confirm that 384 the indicated key was provided by said issuer. If the CDN validating 385 the signed JWT does not support Issuer validation, or if the Issuer 386 in the signed JWT does not match the list of known acceptable 387 Issuers, the CDN MUST reject the request. If the received signed JWT 388 contains an Issuer claim, then any JWT subsequently generated for 389 CDNI redirection MUST also contain an Issuer claim, and the Issuer 390 value MUST be updated to identify the redirecting CDN. If the 391 received signed JWT does not contain an Issuer claim, an Issuer claim 392 MAY be added to a signed JWT generated for CDNI redirection. 394 2.1.2. URI Container (sub) claim 396 URI Container (sub) [mandatory] - The semantics in [RFC7519] 397 Section 4.1.2 MUST be followed. Container for holding the URI 398 representation before a URI Signing Package is added. This 399 representation can take one of several forms detailed in 400 Section 2.1.9. If the URI pattern/regex in the signed JWT does not 401 match the URI of the content request, the CDN validating the signed 402 JWT MUST reject the request. When comparing the URI the percent 403 encoded form as defined in [RFC3986] Section 2.1 MUST be used. When 404 redirecting a URI, the CDN generating the new signed JWT MAY change 405 the URI Container to comport with the URI being used in the 406 redirection. 408 2.1.3. Client IP (aud) claim 410 Client IP (aud) [optional] - The semantics in [RFC7519] Section 4.1.3 411 MUST be followed. IP address, or IP prefix, for which the Signed URI 412 is valid. This is represented in CIDR notation, with dotted decimal 413 format for IPv4 or canonical text representation for IPv6 addresses 414 [RFC5952]. The request is rejected if sourced from a client outside 415 of the specified IP range. Since the client IP is considered 416 personally identifiable information this field MUST be a JSON Web 417 Encryption (JWE [RFC7516]) Object in compact serialization form. If 418 the CDN validating the signed JWT does not support Client IP 419 validation, or if the Client IP in the signed JWT does not match the 420 source IP address in the content request, the CDN MUST reject the 421 request. If the received signed JWT contains a Client IP claim, then 422 any JWT subsequently generated for CDNI redirection MUST also contain 423 a Client IP claim, and the Client IP value MUST be the same as in the 424 received signed JWT. A signed JWT generated for CDNI redirection 425 MUST NOT add a Client IP claim if no Client IP claim existed in the 426 received signed JWT. 428 2.1.4. Expiry Time (exp) claim 430 Expiry Time (exp) [optional] - The semantics in [RFC7519] 431 Section 4.1.4 MUST be followed, though URI Signing implementations 432 MUST NOT allow for any time synchronization "leeway". Note: The time 433 on the entities that generate and validate the signed URI SHOULD be 434 in sync. In the CDNI case, this means that CSP, uCDN, and dCDN 435 servers need to be time-synchronized. It is RECOMMENDED to use NTP 436 [RFC5905] for time synchronization. If the CDN validating the signed 437 JWT does not support Expiry Time validation, or if the Expiry Time in 438 the signed JWT corresponds to a time earlier than the time of the 439 content request, the CDN MUST reject the request. If the received 440 signed JWT contains a Expiry Time claim, then any JWT subsequently 441 generated for CDNI redirection MUST also contain an Expiry Time 442 claim, and the Expiry Time value MUST be the same as in the received 443 signed JWT. A signed JWT generated for CDNI redirection MUST NOT add 444 an Expiry Time claim if no Expiry Time claim existed in the received 445 signed JWT. 447 2.1.5. Not Before (nbf) claim 449 Not Before (nbf) [optional] - The semantics in [RFC7519] 450 Section 4.1.5 MUST be followed, though URI Signing implementations 451 MUST not allow for any time synchronization "leeway". Note: The time 452 on the entities that generate and validate the signed URI SHOULD be 453 in sync. In the CDNI case, this means that the CSP, uCDN, and dCDN 454 servers need to be time-synchronized. It is RECOMMENDED to use NTP 455 [RFC5905] for time synchronization. If the CDN validating the signed 456 JWT does not support Not Before time validation, or if the Not Before 457 time in the signed JWT corresponds to a time later than the time of 458 the content request, the CDN MUST reject the request. If the 459 received signed JWT contains a Not Before time claim, then any JWT 460 subsequently generated for CDNI redirection MUST also contain a Not 461 Before time claim, and the Not Before time value MUST be the same as 462 in the received signed JWT. A signed JWT generated for CDNI 463 redirection MUST NOT add a Not Before time claim if no Not Before 464 time claim existed in the received signed JWT. 466 2.1.6. Issued At (ait) claim 468 Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6 469 MUST be followed. Note: The time on the entities that generate and 470 validate the signed URI SHOULD be in sync. In the CDNI case, this 471 means that CSP, uCDN, and dCDN servers need to be time-synchronized. 472 It is RECOMMENDED to use NTP [RFC5905] for time synchronization. If 473 the received signed JWT contains an Issued At claim, then any JWT 474 subsequently generated for CDNI redirection MUST also contain an 475 Issued At claim, and the Issuer value MUST be updated to identify the 476 time the new JWT was generated. If the received signed JWT does not 477 contain an Issued At claim, an Issued At claim MAY be added to a 478 signed JWT generated for CDNI redirection. 480 2.1.7. Nonce (jti) claim 482 Nonce (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 483 MUST be followed. A Nonce can be used to prevent replay attacks if 484 the CDN stores a list of all previously used Nonce values, and 485 validates that the Nonce in the current JWT has never been used 486 before. If the signed JWT contains a Nonce claim and the CDN 487 validating the signed JWT does not support Nonce storage, then the 488 CDN MUST reject the request. If the received signed JWT contains a 489 Nonce claim, then any JWT subsequently generated for CDNI redirection 490 MUST also contain a Nonce claim, and the Nonce value MUST be the same 491 as in the received signed JWT. If the received signed JWT does not 492 contain a Nonce claim, a Nonce claim MUST NOT be added to a signed 493 JWT generated for CDNI redirection. 495 2.1.8. CDNI Claim Set Version (cdniv) claim 497 CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set 498 Version (cdniv) claim provides a means within a signed JWT to tie the 499 claim set to a specific version of a specificiation. This is 500 intended to allow changes in and facilitate upgrades across 501 specifications. The type is JSON integer and the value MUST be set 502 to "1", for this version of the specification. In the absence of 503 this claim, the value is assumed to be "1". For future versions this 504 claim will be mandatory. Implementations MUST reject signed JWTs 505 with unsupported CDNI Claim Set versions. 507 2.1.9. URI Container Forms 509 The URI Container (sub) claim takes one of the following forms. More 510 forms may be added in the future to extend the capabilities. 512 2.1.9.1. URI Simple Container (uri:) 514 When prefixed with 'uri:', the string following 'uri:' is the URI 515 that MUST be matched with a simple string match to the requested URI. 517 2.1.9.2. URI Pattern Container (uri-pattern:) 519 Prefixed with 'uri-pattern:', this string contains one or more URI 520 Patterns that describes for which content the Signed URI is valid. 521 Each URI Pattern contains an expression to match against the 522 requested URI, to check whether the requested content is allowed to 523 be served. Multiple URI Patterns may be concatenated in a single URI 524 Pattern by separating them with a semi-colon (';') character. Each 525 URI Pattern follows the [RFC3986] URI format, including the '://' 526 that delimits the URI scheme from the hierarchy part. The pattern 527 may include the special literals: 529 ';' - separates individual patterns when the string contains 530 multiple URI patterns. 532 '*' - matches any sequence of characters, including the empty 533 string. 535 '?' - matches exactly one character. 537 '$' - used to escape the special literals; MUST be followed by 538 exactly one of ';', '*', '?', or '$'. 540 The following is an example of a valid URI Pattern: 542 *://*/folder/content-83112371/quality_*/segment????.mp4 544 An example of two concatenated URI Patterns is the following 545 (whitespace is inserted after the ';' for readability and should not 546 be present in the actual representation): 548 http://*/folder/content-83112371/manifest/*.xml; 549 http://*/folder/content-83112371/quality_*/segment????.mp4 551 In order to increase the performance of string parsing the URI 552 Pattern, implementations can check often-used URI Pattern prefixes to 553 quickly check whether certain URI components can be ignored. For 554 example, URI Pattern prefixes '*://*/' or '*://*:*' will be used in 555 case the scheme and authority components of the URI are ignored for 556 purposes of pattern enforcement. 558 2.1.9.3. URI Regular Expression Container (uri-regex:) 560 Prefixed with 'uri-regex:', this string is any PCRE [PCRE839] 561 compatible regular expression used to match against the requested 562 URI. 564 Note: Because '\' has special meaning in JSON [RFC7159] as the escape 565 character within JSON strings, the regular expression character '\' 566 MUST be escaped as '\\'. 568 An example of a 'uri-regex:' is the following: 570 .*\\://.*/folder/content-83112371/quality_.*/segment.{3}\\.mp4 572 Note: Due to computational complexity of executing arbitrary regular 573 expressions, it is RECOMMENDED to only execute after validating the 574 JWT to ensure its authenticity. 576 2.1.9.4. URI Hash Container (uri-hash:) 578 Prefixed with 'uri-hash:', this string is a URL Segment form 579 ([RFC6920] Section 5) of the URI. 581 2.2. JWT Header 583 The header of the JWT MAY be passed via the CDNI Metadata interface 584 instead of being included in the URISigningPackage. The header value 585 must be transmitted in the serialized encoded form and prepended to 586 the JWT payload and signature passed in the URISigningPackage prior 587 to validation. This reduces the size of the signed JWT token. 589 3. Relationship with CDNI Interfaces 591 Some of the CDNI Interfaces need enhancements to support URI Signing. 592 As an example: A dCDN that supports URI Signing needs to be able to 593 advertise this capability to the uCDN. The uCDN needs to select a 594 dCDN based on such capability when the CSP requires access control to 595 enforce its distribution policy via URI Signing. Also, the uCDN 596 needs to be able to distribute via the CDNI Metadata interface the 597 information necessary to allow the dCDN to validate a Signed URI. 598 Events that pertain to URI Signing (e.g., request denial or delivery 599 after access authorization) need to be included in the logs 600 communicated through the CDNI Logging interface (Editor's Note: Is 601 this within the scope of the CDNI Logging interface?). 603 3.1. CDNI Control Interface 605 URI Signing has no impact on this interface. 607 3.2. CDNI Footprint & Capabilities Advertisement Interface 609 The CDNI Request Routing: Footprint and Capabilities Semantics 610 document [RFC8008] defines support for advertising CDNI Metadata 611 capabilities, via CDNI Payload Type. The CDNI Payload Type 612 registered in Section 6.1 can be used for capability advertisement. 614 3.3. CDNI Request Routing Redirection Interface 616 The CDNI Request Routing Redirection Interface [RFC7975] describes 617 the recursive request redirection method. For URI Signing, the uCDN 618 signs the URI provided by the dCDN. URI Signing therefore has has no 619 impact on this interface. 621 3.4. CDNI Metadata Interface 623 The CDNI Metadata Interface [RFC8006] describes the CDNI metadata 624 distribution needed to enable content acquisition and delivery. For 625 URI Signing, a new CDNI metadata object is specified. 627 The UriSigning Metadata object contains information to enable URI 628 signing and validation by a dCDN. The UriSigning properties are 629 defined below. 631 Property: enforce 633 Description: URI Signing enforcement flag. Specifically, this 634 flag indicates if the access to content is subject to URI 635 Signing. URI Signing requires the dCDN to ensure that the URI 636 must be signed and validated before delivering content. 637 Otherwise, the dCDN does not perform validation, regardless of 638 whether or not the URI is signed. 640 Type: Boolean 642 Mandatory-to-Specify: No. The default is true. 644 Property: issuers 646 Description: A list of valid Issuers against which the Issuer 647 claim in the signed JWT may be validated. 649 Type: Array of Strings 651 Mandatory-to-Specify: No. The default is an empty list. An 652 empty list means that any Issuer is acceptable. 654 Property: package-attribute 656 Description: The name to use for the URI Signing Package. 658 Type: String 660 Mandatory-to-Specify: No. Default is "URISigningPackage". 662 Property: jwt-header 664 Description: The header part of JWT that is used for generating 665 or validating a signed JWT when the JWT token in the URI 666 Signing Package does not contain a header part. 668 Type: String 670 Mandatory-to-Specify: No. A jwt-header is not essential for 671 all implementations of URI signing. 673 The following is an example of a URI Signing metadata payload with 674 all default values: 676 { 677 "generic-metadata-type": "MI.UriSigning" 678 "generic-metadata-value": {} 679 } 681 The following is an example of a URI Signing metadata payload with 682 explicit values: 684 { 685 "generic-metadata-type": "MI.UriSigning" 686 "generic-metadata-value": 687 { 688 "enforce": true, 689 "issuers": ["csp", "ucdn1", "ucdn2"], 690 "package-attribute": "usp" 691 } 692 } 694 3.5. CDNI Logging Interface 696 For URI Signing, the dCDN reports that enforcement of the access 697 control was applied to the request for content delivery. When the 698 request is denied due to enforcement of URI Signing, the reason is 699 logged. 701 The following CDNI Logging field for URI Signing SHOULD be supported 702 in the HTTP Request Logging Record as specified in CDNI Logging 703 Interface [RFC7937], using the new "cdni_http_request_v2" record-type 704 registered in Section 6.2.1. 706 o s-uri-signing (mandatory): 708 * format: 3DIGIT 710 * field value: this characterises the URI signing validation 711 performed by the Surrogate on the request. The allowed values 712 are: 714 + "000" : no signed JWT validation performed 716 + "200" : signed JWT validation performed and validated 718 + "400" : signed JWT validation performed and rejected because 719 of incorrect signature 721 + "401" : signed JWT validation performed and rejected because 722 of Expiration Time enforcement 724 + "402" : signed JWT validation performed and rejected because 725 of Client IP enforcement 727 + "403" : signed JWT validation performed and rejected because 728 of URI Pattern enforcement 730 + "404" : signed JWT validation performed and rejected because 731 of Issuer enforcement 733 + "405" : signed JWT validation performed and rejected because 734 of Not Before enforcement 736 + "500" : unable to perform signed JWT validation because of 737 malformed URI 739 * occurrence: there MUST be zero or exactly one instance of this 740 field. 742 o s-uri-signing-deny-reason (optional): 744 * format: QSTRING 746 * field value: a string for providing further information in case 747 the signed JWT was rejected, e.g., for debugging purposes. 749 * occurrence: there MUST be zero or exactly one instance of this 750 field. 752 4. URI Signing Message Flow 754 URI Signing supports both HTTP-based and DNS-based request routing. 755 JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of 756 representing claims to be transferred between two parties. The 757 claims in a signed JWT are encoded as a JSON object that is used as 758 the payload of a JSON Web Signature (JWS) structure or as the 759 plaintext of a JSON Web Encryption (JWE) structure, enabling the 760 claims to be digitally signed or integrity protected with a Message 761 Authentication Code (MAC) and/or encrypted. 763 4.1. HTTP Redirection 765 For HTTP-based request routing, a set of information that is unique 766 to a given end user content request is included in a signed JWT, 767 using key information that is specific to a pair of adjacent CDNI 768 hops (e.g., between the CSP and the uCDN or between the uCDN and a 769 dCDN). This allows a CDNI hop to ascertain the authenticity of a 770 given request received from a previous CDNI hop. 772 The URI signing method described below is based on the following 773 steps (assuming HTTP redirection, iterative request routing, and a 774 CDN path with two CDNs). Note that uCDN and uCDN are used 775 exchangeably. 777 End-User dCDN uCDN CSP 778 | | | | 779 | 1.CDNI FCI interface used to | | 780 | advertise URI Signing capability| | 781 | |------------------->| | 782 | | | | 783 | 2.Provides information to validate signed JWT | 784 | | |<-------------------| 785 | | | | 786 | 3.CDNI Metadata interface used to| | 787 | provide URI Signing attributes| | 788 | |<-------------------| | 789 |4.Authorization request | | 790 |------------------------------------------------------------->| 791 | | | [Apply distribution 792 | | | policy] | 793 | | | | 794 | | (ALT: Authorization decision) 795 |5.Request is denied | | | 796 |<-------------------------------------------------------------| 797 | | | | 798 |6.CSP provides signed URI | | 799 |<-------------------------------------------------------------| 800 | | | | 801 |7.Content request | | | 802 |---------------------------------------->| [Validate URI | 803 | | | signature] | 804 | | | | 805 | | (ALT: Validation result) | 806 |8.Request is denied | | | 807 |<----------------------------------------| | 808 | | | | 809 |9.Re-sign URI and redirect to | | 810 | dCDN (newly signed URI) | | 811 |<----------------------------------------| | 812 | | | | 813 |10.Content request | | | 814 |------------------->| [Validate URI | | 815 | | signature] | | 816 | | | | 817 | (ALT: Validation result) | | 818 |11.Request is denied| | | 819 |<-------------------| | | 820 | | | | 821 |12.Content delivery | | | 822 |<-------------------| | | 823 : : : : 824 : (Later in time) : : : 825 |13.CDNI Logging interface to include URI Signing information | 826 | |------------------->| | 828 Figure 3: HTTP-based Request Routing with URI Signing 830 1. Using the CDNI Footprint & Capabilities Advertisement interface, 831 the dCDN advertises its capabilities including URI Signing 832 support to the uCDN. 834 2. CSP provides to the uCDN the information needed to validate 835 signed JWTs from that CSP. For example, this information may 836 include a key value. 838 3. Using the CDNI Metadata interface, the uCDN communicates to a 839 dCDN the information needed to validate signed JWTs from the 840 uCDN for the given CSP. For example, this information may 841 include the URI query string parameter name for the URI Signing 842 Package Attribute. 844 4. When a UA requests a piece of protected content from the CSP, 845 the CSP makes a specific authorization decision for this unique 846 request based on its personal distribution policy. 848 5. If the authorization decision is negative, the CSP rejects the 849 request and sends an error code (e.g., 403 Forbidden) in the 850 HTTP response. 852 6. If the authorization decision is positive, the CSP computes a 853 Signed URI that is based on unique parameters of that request 854 and conveys it to the end user as the URI to use to request the 855 content. 857 7. On receipt of the corresponding content request, the uCDN 858 validates the signed JWT in the URI using the information 859 provided by the CSP. 861 8. If the validation is negative, the uCDN rejects the request and 862 sends an error code (e.g., 403 Forbidden) in the HTTP response. 864 9. If the validation is positive, the uCDN computes a Signed URI 865 that is based on unique parameters of that request and provides 866 it to the end user as the URI to use to further request the 867 content from the dCDN. 869 10. On receipt of the corresponding content request, the dCDN 870 validates the signed JWT in the Signed URI using the information 871 provided by the uCDN in the CDNI Metadata. 873 11. If the validation is negative, the dCDN rejects the request and 874 sends an error code (e.g., 403 Forbidden) in the HTTP response. 876 12. If the validation is positive, the dCDN serves the request and 877 delivers the content. 879 13. At a later time, the dCDN reports logging events that include 880 URI signing information. 882 With HTTP-based request routing, URI Signing matches well the general 883 chain of trust model of CDNI both with symmetric and asymmetric keys 884 because the key information only needs to be specific to a pair of 885 adjacent CDNI hops. 887 4.2. DNS Redirection 889 For DNS-based request routing, the CSP and uCDN must agree on a trust 890 model appropriate to the security requirements of the CSP's 891 particular content. Use of asymmetric public/private keys allows for 892 unlimited distribution of the public key to dCDNs. However, if a 893 shared secret key is preferred, then the CSP may want to restrict the 894 distribution of the key to a (possibly empty) subset of trusted 895 dCDNs. Authorized Delivery CDNs need to obtain the key information 896 to validate the Signed URI. 898 The URI signing method described below is based on the following 899 steps (assuming iterative DNS request routing and a CDN path with two 900 CDNs). 902 End-User dCDN uCDN CSP 903 | | | | 904 | 1.CDNI FCI interface used to | | 905 | advertise URI Signing capability| | 906 | |------------------->| | 907 | | | | 908 | 2.Provides information to validate signed JWT | 909 | | |<-------------------| 910 | 3.CDNI Metadata interface used to| | 911 | provide URI Signing attributes| | 912 | |<-------------------| | 913 |4.Authorization request | | 914 |------------------------------------------------------------->| 915 | | | [Apply distribution 916 | | | policy] | 917 | | | | 918 | | (ALT: Authorization decision) 919 |5.Request is denied | | | 920 |<-------------------------------------------------------------| 921 | | | | 922 |6.Provides signed URI | | 923 |<-------------------------------------------------------------| 924 | | | | 925 |7.DNS request | | | 926 |---------------------------------------->| | 927 | | | | 928 |8.Redirect DNS to dCDN | | 929 |<----------------------------------------| | 930 | | | | 931 |9.DNS request | | | 932 |------------------->| | | 933 | | | | 934 |10.IP address of Surrogate | | 935 |<-------------------| | | 936 | | | | 937 |11.Content request | | | 938 |------------------->| [Validate URI | | 939 | | signature] | | 940 | | | | 941 | (ALT: Validation result) | | 942 |12.Request is denied| | | 943 |<-------------------| | | 944 | | | | 945 |13.Content delivery | | | 946 |<-------------------| | | 947 : : : : 948 : (Later in time) : : : 949 |14.CDNI Logging interface to report URI Signing information | 950 | |------------------->| | 952 Figure 4: DNS-based Request Routing with URI Signing 954 1. Using the CDNI Footprint & Capabilities Advertisement interface, 955 the dCDN advertises its capabilities including URI Signing 956 support to the uCDN. 958 2. CSP provides to the uCDN the information needed to validate 959 cryptographic signatures from that CSP. For example, this 960 information may include a key. 962 3. Using the CDNI Metadata interface, the uCDN communicates to a 963 dCDN the information needed to validate cryptographic signatures 964 from the CSP (e.g., the URI query string parameter name for the 965 URI Signing Package Attribute). In the case of symmetric key, 966 the uCDN checks if the dCDN is allowed by CSP to obtain the 967 shared secret key. 969 4. When a UA requests a piece of protected content from the CSP, 970 the CSP makes a specific authorization decision for this unique 971 request based on its arbitrary distribution policy. 973 5. If the authorization decision is negative, the CSP rejects the 974 request. 976 6. If the authorization decision is positive, the CSP computes a 977 cryptographic signature that is based on unique parameters of 978 that request and includes it in the URI provided to the end user 979 to request the content. 981 7. End user sends DNS request to the uCDN. 983 8. On receipt of the DNS request, the uCDN redirects the request to 984 the dCDN. 986 9. End user sends DNS request to the dCDN. 988 10. On receipt of the DNS request, the dCDN responds with IP address 989 of one of its Surrogates. 991 11. On receipt of the corresponding content request, the dCDN 992 validates the cryptographic signature in the URI using the 993 information provided by the uCDN in the CDNI Metadata. 995 12. If the validation is negative, the dCDN rejects the request and 996 sends an error code (e.g., 403) in the HTTP response. 998 13. If the validation is positive, the dCDN serves the request and 999 delivers the content. 1001 14. At a later time, dCDN reports logging events that includes URI 1002 signing information. 1004 With DNS-based request routing, URI Signing matches well the general 1005 chain of trust model of CDNI when used with asymmetric keys because 1006 the only key information that needs to be distributed across 1007 multiple, possibly untrusted, CDNI hops is the public key, which is 1008 generally not confidential. 1010 With DNS-based request routing, URI Signing does not match well the 1011 general chain of trust model of CDNI when used with symmetric keys 1012 because the symmetric key information needs to be distributed across 1013 multiple CDNI hops, to CDNs with which the CSP may not have a trust 1014 relationship. This raises a security concern for applicability of 1015 URI Signing with symmetric keys in case of DNS-based inter-CDN 1016 request routing. 1018 5. HTTP Adaptive Streaming 1020 The authors note that in order to perform URI signing for individual 1021 content segments of HTTP Adaptive Bitrate content, specific URI 1022 signing mechanisms are needed. Such mechanisms are currently out-of- 1023 scope of this document. More details on this topic is covered in 1024 Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. In 1025 addition, [I-D.brandenburg-cdni-uri-signing-for-has] provides an 1026 extension to the algorithm defined in this document that deals 1027 specifically with URI signing of segmented content. 1029 6. IANA Considerations 1031 6.1. CDNI Payload Type 1033 This document requests the registration of the following CDNI Payload 1034 Type under the IANA "CDNI Payload Type" registry: 1036 +---------------+---------------+ 1037 | Payload Type | Specification | 1038 +---------------+---------------+ 1039 | MI.UriSigning | RFCthis | 1040 +---------------+---------------+ 1042 [RFC Editor: Please replace RFCthis with the published RFC number for 1043 this document.] 1045 6.1.1. CDNI UriSigning Payload Type 1047 Purpose: The purpose of this payload type is to distinguish 1048 UriSigning MI objects (and any associated capability advertisement). 1050 Interface: MI/FCI 1052 Encoding: see Section 3.4 1054 6.2. CDNI Logging Record Type 1056 This document requests the registration of the following CDNI Logging 1057 record-type under the IANA "CDNI Logging record-types" registry: 1059 +----------------------+-----------+--------------------------------+ 1060 | record-types | Reference | Description | 1061 +----------------------+-----------+--------------------------------+ 1062 | cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | 1063 | | | Record version 1 for content | 1064 | | | delivery using HTTP, to | 1065 | | | include URI Signing logging | 1066 | | | fields | 1067 +----------------------+-----------+--------------------------------+ 1069 [RFC Editor: Please replace RFCthis with the published RFC number for 1070 this document.] 1072 6.2.1. CDNI Logging Record Version 2 for HTTP 1074 The "cdni_http_request_v2" record-type supports all of the fields 1075 supported by the "cdni_http_request_v1" record-type [RFC7937] plus 1076 the two additional fields "s-uri-signing" and "s-uri-signing-deny- 1077 reason", registered by this document in Section 6.3. The name, 1078 format, field value, and occurence information for the two new fields 1079 can be found in Section 3.5 of this document. 1081 6.3. CDNI Logging Field Names 1083 This document requests the registration of the following CDNI Logging 1084 fields under the IANA "CDNI Logging Field Names" registry: 1086 +---------------------------+-----------+ 1087 | Field Name | Reference | 1088 +---------------------------+-----------+ 1089 | s-uri-signing | RFCthis | 1090 | s-uri-signing-deny-reason | RFCthis | 1091 +---------------------------+-----------+ 1093 [RFC Editor: Please replace RFCthis with the published RFC number for 1094 this document.] 1096 6.4. JSON Web Token Claims Registration 1098 This specification registers the following Claims in the IANA "JSON 1099 Web Token Claims" registry [IANA.JWT.Claims] established by 1100 [RFC7519]. 1102 6.4.1. Registry Contents 1104 o Claim Name: "cdniv" 1105 o Claim Description: CDNI Claim Set Version 1106 o Change Controller: IESG 1107 o Specification Document(s): Section 2.1.8 of [[ this specification 1108 ]] 1110 7. Security Considerations 1112 This document describes the concept of URI Signing and how it can be 1113 used to provide access authorization in the case of CDNI. The 1114 primary goal of URI Signing is to make sure that only authorized UAs 1115 are able to access the content, with a CSP being able to authorize 1116 every individual request. It should be noted that URI Signing is not 1117 a content protection scheme; if a CSP wants to protect the content 1118 itself, other mechanisms, such as DRM, are more appropriate. 1120 In general, it holds that the level of protection against 1121 illegitimate access can be increased by including more claims in the 1122 signed JWT. The current version of this document includes claims for 1123 enforcing Issuer, Client IP Address, Not Before time, and Expiration 1124 Time, however this list can be extended with other, more complex, 1125 attributes that are able to provide some form of protection against 1126 some of the vulnerabilities highlighted below. 1128 That said, there are a number of aspects that limit the level of 1129 security offered by URI Signing and that anybody implementing URI 1130 Signing should be aware of. 1132 Replay attacks: A (valid) Signed URI may be used to perform replay 1133 attacks. The vulnerability to replay attacks can be reduced by 1134 picking a relatively short window between the Not Before time and 1135 Expiration Time attributes, although this is limited by the fact 1136 that any HTTP-based request needs a window of at least a couple of 1137 seconds to prevent a sudden network issues from preventing 1138 legitimate UAs access to the content. One may also reduce 1139 exposure to replay attacks by including a unique one-time access 1140 ID via the Nonce attribute (jti claim). Whenever the dCDN 1141 receives a request with a given unique ID, it adds that ID to the 1142 list of 'used' IDs. In the case an illegitimate UA tries to use 1143 the same URI through a replay attack, the dCDN can deny the 1144 request based on the already-used access ID. 1146 Illegitimate clients behind a NAT: In cases where there are 1147 multiple users behind the same NAT, all users will have the same 1148 IP address from the point of view of the dCDN. This results in 1149 the dCDN not being able to distinguish between the different users 1150 based on Client IP Address and illegitimate users being able to 1151 access the content. One way to reduce exposure to this kind of 1152 attack is to not only check for Client IP but also for other 1153 attributes, e.g., attributes that can be found in HTTP headers. 1155 The shared key between CSP and uCDN may be distributed to dCDNs - 1156 including cascaded CDNs. Since this key can be used to legitimately 1157 sign a URL for content access authorization, it is important to know 1158 the implications of a compromised shared key. 1160 8. Privacy 1162 The privacy protection concerns described in CDNI Logging Interface 1163 [RFC7937] apply when the client's IP address (aud) is embedded in the 1164 Signed URI. For this reason, the mechanism described in Section 2 1165 encrypts the Client IP before including it in the URI Signing Package 1166 (and thus the URL itself). 1168 9. Acknowledgements 1170 The authors would like to thank the following people for their 1171 contributions in reviewing this document and providing feedback: 1172 Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan 1173 York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana 1174 Oprescu, Leif Hedstrom, Gancho Tenev, and Brian Campbell. In 1175 addition, Matt Caulfield provided content for the CDNI Metadata 1176 Interface section. 1178 10. References 1180 10.1. Normative References 1182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1183 Requirement Levels", BCP 14, RFC 2119, 1184 DOI 10.17487/RFC2119, March 1997, 1185 . 1187 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1188 Distribution Network Interconnection (CDNI) Problem 1189 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1190 2012, . 1192 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1193 Keranen, A., and P. Hallam-Baker, "Naming Things with 1194 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1195 . 1197 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1198 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1199 2014, . 1201 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1202 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1203 . 1205 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1206 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1207 . 1209 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 1210 and R. Peterkofsky, "Content Distribution Network 1211 Interconnection (CDNI) Logging Interface", RFC 7937, 1212 DOI 10.17487/RFC7937, August 2016, 1213 . 1215 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1216 "Content Delivery Network Interconnection (CDNI) 1217 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1218 . 1220 10.2. Informative References 1222 [I-D.brandenburg-cdni-uri-signing-for-has] 1223 Brandenburg, R., "URI Signing for HTTP Adaptive Streaming 1224 (HAS)", draft-brandenburg-cdni-uri-signing-for-has-03 1225 (work in progress), June 2016. 1227 [IANA.JWT.Claims] 1228 IANA, "JSON Web Token Claims", 1229 . 1231 [PCRE839] Hazel, P., "Perl Compatible Regular Expressions", 1232 Version 8.39, June 2016, . 1234 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1235 Resource Identifier (URI): Generic Syntax", STD 66, 1236 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1237 . 1239 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1240 "Network Time Protocol Version 4: Protocol and Algorithms 1241 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1242 . 1244 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1245 Address Text Representation", RFC 5952, 1246 DOI 10.17487/RFC5952, August 2010, 1247 . 1249 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 1250 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 1251 Content Distribution Network Interconnection (CDNI)", 1252 RFC 6983, DOI 10.17487/RFC6983, July 2013, 1253 . 1255 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1256 "Framework for Content Distribution Network 1257 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1258 August 2014, . 1260 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1261 Network Interconnection (CDNI) Requirements", RFC 7337, 1262 DOI 10.17487/RFC7337, August 2014, 1263 . 1265 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1266 "Request Routing Redirection Interface for Content 1267 Delivery Network (CDN) Interconnection", RFC 7975, 1268 DOI 10.17487/RFC7975, October 2016, 1269 . 1271 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1272 R., and K. Ma, "Content Delivery Network Interconnection 1273 (CDNI) Request Routing: Footprint and Capabilities 1274 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1275 . 1277 Appendix A. Signed URI Package Example 1279 This section contains two examples of token usage: a simple example 1280 with only the required claims present, and a complex example which 1281 demonstrates the full JWT claims set, including an encrypted Client 1282 IP (aud). 1284 Note: All of the examples have whitespace added to improve formatting 1285 and readability, but are not present in the generated content. 1287 Both examples use the following signing key to generate the Signed 1288 URI Package: 1290 { 1291 "kty": "EC", 1292 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1293 "use": "sig", 1294 "crv": "P-256", 1295 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1296 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", 1297 "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" 1298 } 1300 A.1. Simple Example 1302 This example is the simplest possible example containing the only 1303 required field (sub). 1305 The JWT Claim Set before signing: 1307 { 1308 "cdniv": 1, 1309 "sub": "uri:http://cdni.example/foo/bar/baz" 1310 } 1312 The Signed JWT: 1314 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1315 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pdiI6MSwic3ViIjoidXJpOmh0dHA6Ly9jZ 1316 G5pLmV4YW1wbGUvZm9vL2Jhci9iYXoifQ.RMPznuLnO3B9jTYJRQE_HFXD4CTBfTLZ 1317 M03BkHK7wTMSSOOhJL6dORy1Avx3BJW2NNa-SsytYzM7tGCcsAJUFA 1319 A.2. Complex Example 1321 This example uses all optional fields, including Client IP (aud) 1322 which is encrpyted. This significantly increases the size of the 1323 signed JWT token. 1325 Shared key used for encrpyting the Client IP (aud): 1327 { 1328 "kty": "oct", 1329 "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", 1330 "use": "enc", 1331 "alg": "A128GCM", 1332 "k": "4uFxxV7fhNmrtiah2d1fFg" 1333 } 1335 JWE for client IP (aud) of [2001:db8::1/32]: 1337 eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj 1338 g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..iirjVvKXFc_NzZkm.SJcZ7 1339 g5hXas-eDNsCOIQLQ._Hwi9VSHsWQGuataOdQJYQ 1341 The JWT Claim Set before signing: 1343 { 1344 "aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm 1345 dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..iirjVvKXFc_N 1346 zZkm.SJcZ7g5hXas-eDNsCOIQLQ._Hwi9VSHsWQGuataOdQJYQ", 1347 "cdniv": 1, 1348 "exp": 1474243500, 1349 "iat": 1474243200, 1350 "iss": "uCDN Inc", 1351 "jti": "5DAafLhZAfhsbe", 1352 "nbf": 1474243200, 1353 "sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.png" 1354 } 1356 The Signed JWT: 1358 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1359 dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJleUpoYkdjaU9pSmthWElpTENKcmFXU 1360 WlPaUptTFZkaWFuaENRek5rVUhWSk0yUXlOR3RRTW1obWRtOXpOMUY2TmpnNFZWUnB 1361 ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLmlpcmpWdktYRmNfT 1362 npaa20uU0pjWjdnNWhYYXMtZUROc0NPSVFMUS5fSHdpOVZTSHNXUUd1YXRhT2RRSll 1363 RIiwiY2RuaXYiOjEsImV4cCI6MTQ3NDI0MzUwMCwiaWF0IjoxNDc0MjQzMjAwLCJpc 1364 3MiOiJ1Q0ROIEluYyIsImp0aSI6IjVEQWFmTGhaQWZoc2JlIiwibmJmIjoxNDc0MjQ 1365 zMjAwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGxlL2Zvby9iY 1366 XIvYmF6L1swLTldezN9XFwucG5nIn0.k_lX_z_E4-rdzjJ6DuSnoVtvifaz-W4xN0I 1367 PdU6IoDZvBeu_lv39xsgfnvTO_wcflaO9MkbWyzarw3MtnITxQA 1369 Authors' Addresses 1371 Ray van Brandenburg 1372 Tiledmedia 1373 Anna van Buerenplein 1 1374 Den Haag 2595DA 1375 The Netherlands 1377 Phone: +31 88 866 7000 1378 Email: ray@tiledmedia.com 1379 Kent Leung 1380 Cisco Systems, Inc. 1381 3625 Cisco Way 1382 San Jose, CA 95134 1383 United States 1385 Phone: +1 408 526 5030 1386 Email: kleung@cisco.com 1388 Phil Sorber 1389 Comcast Cable Communications 1390 1401 Wynkoop Street, Suite 300 1391 Denver, CO 80202 1392 United States 1394 Phone: +1 720 502 3785 1395 Email: phillip_sorber@comcast.com 1397 Matthew Miller 1398 Mozilla 1400 Email: linuxwolf@outer-planes.net