idnits 2.17.1 draft-ietf-cdni-uri-signing-10.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 263 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: o Expiry Time (exp) [optional] - The semantics in [RFC7519] Section 4.1.4 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 CSP, uCDN and dCDN servers need to be time-synchronized. It is RECOMMENDED to use NTP for time synchronization. If the CDN validating the signed JWT does not support Expiry Time validation, or if the Expiry Time in the signed JWT corresponds to a time earlier than the time of the content request request, the CDN MUST reject the request. If the received signed JWT contains a Expiry Time claim, then any JWT subsequently generated for CDNI redirection MUST also contain an Expiry Time claim, and the Expiry Time value MUST be the same as in the received signed JWT. A signed JWT generated for CDNI redirection MUST NOT add an Expiry Time claim if no Expiry Time claim existed in the received signed JWT. == 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: o 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 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 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 (October 4, 2016) is 2732 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) == Missing Reference: 'HIGH' is mentioned on line 129, but not defined ** Downref: Normative reference to an Informational RFC: RFC 6707 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 3 errors (**), 0 flaws (~~), 5 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 TNO 4 Intended status: Standards Track K. Leung 5 Expires: April 7, 2017 Cisco Systems, Inc. 6 P. Sorber 7 Comcast Cable Communications 8 M. Miller 9 Cisco Systems, Inc. 10 October 4, 2016 12 URI Signing for CDN Interconnection (CDNI) 13 draft-ietf-cdni-uri-signing-10 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 April 7, 2017. 43 Copyright Notice 45 Copyright (c) 2016 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 . . . . . . . . . . . . 7 65 2. JWT Format and Processing Requirements . . . . . . . . . . . 7 66 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.1.1. URI Container Forms . . . . . . . . . . . . . . . . . 10 68 2.1.1.1. URI Simple Container (uri:) . . . . . . . . . . . 11 69 2.1.1.2. URI Pattern Container (uri-pattern:) . . . . . . 11 70 2.1.1.3. URI Regular Expression Container (uri-regex:) . . 12 71 3. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 12 72 3.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 12 73 3.2. CDNI Footprint & Capabilities Advertisement Interface . . 12 74 3.3. CDNI Request Routing Redirection Interface . . . . . . . 13 75 3.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 13 76 3.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 14 77 4. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 15 78 4.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 16 79 4.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 18 80 5. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 21 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 82 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 21 83 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 21 84 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 22 85 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 22 86 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 22 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 92 10.2. Informative References . . . . . . . . . . . . . . . . . 25 93 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 26 94 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 26 95 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 27 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 99 1. Introduction 101 This document describes the concept of URI Signing and how it can be 102 used to provide access authorization in the case of redirection 103 between interconnected CDNs (CDNI) and between a Content Service 104 Provider (CSP) and a CDN. The primary goal of URI Signing is to make 105 sure that only authorized User Agents (UAs) are able to access the 106 content, with a CSP being able to authorize every individual request. 107 It should be noted that URI Signing is not a content protection 108 scheme; if a CSP wants to protect the content itself, other 109 mechanisms, such as DRM, are more appropriate. In addition to access 110 control, URI Signing also has benefits in reducing the impact of 111 denial-of-service attacks. 113 The overall problem space for CDN Interconnection (CDNI) is described 114 in CDNI Problem Statement [RFC6707]. This document, along with the 115 CDNI Requirements [RFC7337] document and the CDNI Framework 116 [RFC7336], describes the need for interconnected CDNs to be able to 117 implement an access control mechanism that enforces the CSP's 118 distribution policy. 120 Specifically, CDNI Framework [RFC7336] states: 122 "The CSP may also trust the CDN operator to perform actions such as 123 ..., and to enforce per-request authorization performed by the CSP 124 using techniques such as URI signing." 126 In particular, the following requirement is listed in CDNI 127 Requirements [RFC7337]: 129 "MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow 130 signaling of authorization checks and validation that are to be 131 performed by the surrogate before delivery. For example, this could 132 potentially include: 134 * need to validate URI signed information (e.g., Expiry time, Client 135 IP address)." 137 This document proposes a method of signing URIs that allows 138 Surrogates in interconnected CDNs to enforce a per-request 139 authorization performed by the CSP. Splitting the role of performing 140 per-request authorization by the CSP and the role of validating this 141 authorization by the CDN allows any arbitrary distribution policy to 142 be enforced across CDNs without the need of CDNs to have any 143 awareness of the actual CSP distribution policy. 145 The representation of this method is a Signed JSON Web Token (JWT) 146 [RFC7519]. 148 1.1. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 This document uses the terminology defined in CDNI Problem Statement 155 [RFC6707]. 157 This document also uses the terminology of JSON Web Token (JWT) 158 [RFC7519]. 160 In addition, the following terms are used throughout this document: 162 o Signed URI: A URI that contains a signed JWT for itself. 164 o Target CDN URI: URI created by the CSP to direct UA towards the 165 Upstream CDN (uCDN). The Target CDN URI can be signed by the CSP 166 and verified by the uCDN. 168 o Redirection URI: URI created by the uCDN to redirect UA towards 169 the Downstream CDN (dCDN). The Redirection URI can be signed by 170 the uCDN and verified by the dCDN. In a cascaded CDNI scenario, 171 there can be more than one Redirection URI. 173 1.2. Background and overview on URI Signing 175 A CSP and CDN are assumed to have a trust relationship that enables 176 the CSP to authorize access to a content item by including a set of 177 claims in the form of a signed JWT in the URI before redirecting a UA 178 to the CDN. Using these attributes, it is possible for a CDN to 179 check an incoming content request to see whether it was authorized by 180 the CSP (e.g., based on the UA's IP address or a time window). To 181 prevent the UA from altering the claims a signed JWT is REQUIRED. 183 Figure 1, shown below, presents an overview of the URI Signing 184 mechanism in the case of a CSP with a single CDN. When the UA 185 browses for content on CSP's website (#1), it receives HTML web pages 186 with embedded content URIs. Upon requesting these URIs, the CSP 187 redirects to a CDN, creating a Target CDN URI (#2) (alternatively, 188 the Target CDN URI itself is embedded in the HTML). The Target CDN 189 URI is the Signed URI which may include the IP address of the UA and/ 190 or a time window and always contains the signed JWT which is 191 generated by the CSP using a shared secret or private key. Once the 192 UA receives the response with the Signed URI, it sends a new HTTP 193 request using the Signed URI to the CDN (#3). Upon receiving the 194 request, the CDN checks to see if the Signed URI is authentic by 195 verifying the signed JWT. If applicable, it checks whether the IP 196 address of the HTTP request matches that in the Signed URI and if the 197 time window is still valid. After these claims are confirmed to be 198 valid, the CDN delivers the content (#4). 200 -------- 201 / \ 202 | CSP |< * * * * * * * * * * * 203 \ / Trust * 204 -------- relationship * 205 ^ | * 206 | | * 207 1. Browse | | 2. Signed * 208 for | | URI * 209 content | | * 210 | v v 211 +------+ 3. Signed URI -------- 212 | User |----------------->/ \ 213 | Agent| | CDN | 214 | |<-----------------\ / 215 +------+ 4. Content -------- 216 Delivery 218 Figure 1: Figure 1: URI Signing in a CDN Environment 220 1.3. CDNI URI Signing Overview 222 In a CDNI environment, URI Signing operates the same way in the 223 initial steps #1 and #2 but the later steps involve multiple CDNs in 224 the process of delivering the content. The main difference from the 225 single CDN case is a redirection step between the uCDN and the dCDN. 226 In step #3, UA may send an HTTP request or a DNS request. Depending 227 on whether HTTP-based or DNS-based request routing is used, the uCDN 228 responds by directing the UA towards the dCDN using either a 229 Redirection URI (which is a Signed URI generated by the uCDN) or a 230 DNS reply, respectively (#4). Once the UA receives the response, it 231 sends the Redirection URI/Target CDN URI to the dCDN (#5). The 232 received URI is validated by the dCDN before delivering the content 233 (#6). This is depicted in the figure below. Note: The CDNI call 234 flows are covered in Detailed URI Signing Operation (Section 4). 236 +-------------------------+ 237 |Request Redirection Modes| 238 +-------------------------+ 239 | a) HTTP | 240 | b) DNS | 241 +-------------------------+ 242 -------- 243 / \< * * * * * * * * * * * * * * 244 | CSP |< * * * * * * * * * * * * 245 \ / Trust * * 246 -------- relationship * * 247 ^ | * * 248 | | 2. Signed * * 249 1. Browse | | URI in * * 250 for | | HTML * * 251 content | | * * 252 | v 3.a)Signed URI v * 253 +------+ b)DNS request -------- * Trust 254 | User |----------------->/ \ * relationship 255 | Agent| | uCDN | * (optional) 256 | |<-----------------\ / * 257 +------+ 4.a)Redirection URI------- * 258 ^ | b)DNS Reply ^ * 259 | | * * 260 | | Trust relationship * * 261 | | * * 262 6. Content | | 5.a)Redirection URI * * 263 delivery | | b)Signed URI(after v v 264 | | DNS exchange) -------- 265 | +---------------------->/ \ [May be 266 | | dCDN | cascaded 267 +--------------------------\ / CDNs] 268 -------- 270 +-----------------------------------------+ 271 | Key | Asymmetric | Symmetric | 272 +-----------------------------------------+ 273 |HTTP |Public key (uCDN)|Shared key (uCDN)| 274 |DNS |Public key (CSP) |Shared key (CSP) | 275 +-----------------------------------------+ 277 Figure 2: URI Signing in a CDNI Environment 279 The trust relationships between CSP, uCDN, and dCDN have direct 280 implications for URI Signing. In the case shown in Figure 2, the CDN 281 that the CSP has a trust relationship with is the uCDN. The delivery 282 of the content may be delegated to the dCDN, which has a relationship 283 with the uCDN but may have no relationship with the CSP. 285 In CDNI, there are two methods for request routing: DNS-based and 286 HTTP-based. For DNS-based request routing, the Signed URI (i.e., 287 Target CDN URI) provided by the CSP reaches the dCDN directly. In 288 the case where the dCDN does not have a trust relationship with the 289 CSP, this means that either an asymmetric public/private key method 290 needs to be used for computing the signed JWT (because the CSP and 291 dCDN are not able to exchange symmetric shared secret keys), or the 292 CSP needs to allow the uCDN to redistribute shared keys to a subset 293 of their dCDNs . 295 For HTTP-based request routing, the Signed URI (i.e., Target CDN URI) 296 provided by the CSP reaches the uCDN. After this URI has been 297 verified to be correct by the uCDN, the uCDN creates and signs a new 298 Redirection URI to redirect the UA to the dCDN. Since this new URI 299 also has a new signed JWT, this new signature can be based around the 300 trust relationship between the uCDN and dCDN, and the relationship 301 between the dCDN and CSP is not relevant. Given the fact that such a 302 relationship between uCDN and dCDN always exists, both asymmetric 303 public/private keys and symmetric shared secret keys can be used for 304 URI Signing with HTTP-based request routing. Note that the signed 305 Redirection URI MUST maintain the same, or higher, level of security 306 as the original Signed URI. 308 1.4. URI Signing in a non-CDNI context 310 While the URI signing method defined in this document was primarily 311 created for the purpose of allowing URI Signing in CDNI scenarios, 312 e.g., between a uCDN and a dCDN or between a CSP and a dCDN, there is 313 nothing in the defined URI Signing method that precludes it from 314 being used in a non-CDNI context. As such, the described mechanism 315 could be used in a single-CDN scenario such as shown in Figure 1 in 316 Section 1.2, for example to allow a CSP that uses different CDNs to 317 only have to implement a single URI Signing mechanism. 319 2. JWT Format and Processing Requirements 321 The concept behind URI Signing is based on embedding a signed JSON 322 Web Token (JWT) [RFC7519] in the Target CDN URI/Redirection URI. The 323 signed JWT contains a number of claims that can be validated to 324 ensure the UA has legitimate access to the content. 326 In addition, this document specifies the following URI attribute: 328 o URI Signing Package (URISigningPackage): The URI attribute that 329 encapsulates all the URI Signing claims in a signed JWT encoded 330 format. This attribute is exposed in the Signed URI as a URI 331 query parameter or as a URL path parameter. 333 The parameter name of the URI Signing Package Attribute is defined in 334 the CDNI Metadata. If the CDNI Metadata interface is not used, or 335 does not include a parameter name for the URI Signing Package 336 Attribute, the parameter name can be set by configuration (out of 337 scope of this document). 339 2.1. JWT Claims 341 This section identifies the set of claims that can be used to enforce 342 the CSP distribution policy. New claims can be introduced in the 343 future to extend the distribution policy capabilities. 345 In order to provide distribution policy flexibility, the exact subset 346 of claims used in a given signed JWT is a runtime decision. Claim 347 requirements are defined in the CDNI Metadata. If the CDNI Metadata 348 interface is not used, or does not include claim requirements, the 349 claim requirements can be set by configuration (out of scope of this 350 document). 352 The following claims (where the "JSON Web Token Claims" registry 353 claim name is specified in parenthesis below) are used to enforce the 354 distribution policies. All of the listed claims are mandatory to 355 implement in a URI Signing implementation, but are not mandatory to 356 use in a given signed JWT. (The "optional" and "mandatory" 357 identifiers in square brackets refer to whether or not a given claim 358 MUST be present in a URI Signing JWT.) A CDN MUST be able to parse 359 and process all of the claims listed below. If the signed JWT 360 contains any claims which the CDN does not understand (i.e., is 361 unable to parse and process), the CDN MUST reject the request. 363 o Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1 364 MUST be followed. This claim MAY be used to validate 365 authorization of the issuer of a signed JWT and also MAY be used 366 to confirm that the indicated key was provided by said issuer. If 367 the CDN validating the signed JWT does not support Issuer 368 validation, or if the Issuer in the signed JWT does not match the 369 list of known acceptable Issuers, the CDN MUST reject the request. 370 If the received signed JWT contains an Issuer claim, then any JWT 371 subsequently generated for CDNI redirection MUST also contain an 372 Issuer claim, and the Issuer value MUST be updated to identify the 373 redirecting CDN. If the received signed JWT does not contain an 374 Issuer claim, an Issuer claim MAY be added to a signed JWT 375 generated for CDNI redirection. 377 o URI Container (sub) [mandatory] - The semantics in [RFC7519] 378 Section 4.1.2 MUST be followed. Container for holding the URI 379 representation before the URI Signing Package is added. This 380 representation can take one of several forms detailed in 381 Section 2.1.1. If the URI pattern/regex in the signed JWT does 382 not match the URI of the content request, the CDN validating the 383 signed JWT MUST reject the request. When redirecting a URI, the 384 CDN generating the new signed JWT MAY change the URI Container to 385 comport with the URI being used in the redirection. 387 o Client IP (aud) [optional] - The semantics in [RFC7519] 388 Section 4.1.3 MUST be followed. IP address, or IP prefix, for 389 which the Signed URI is valid. This is represented in CIDR 390 notation, with dotted decimal format for IPv4 or canonical text 391 representation for IPv6 addresses [RFC5952]. The request is 392 rejected if sourced from a client outside of the specified IP 393 range. Since the client IP is considered personally identifiable 394 information this field MUST be a JSON Web Encryption (JWE 395 [RFC7516]) Object in compact serialization form. If the CDN 396 validating the signed JWT does not support Client IP validation, 397 or if the Client IP in the signed JWT does not match the source IP 398 address in the content request request, the CDN MUST reject the 399 request. If the received signed JWT contains a Client IP claim, 400 then any JWT subsequently generated for CDNI redirection MUST also 401 contain a Client IP claim, and the Client IP value MUST be the 402 same as in the received signed JWT. A signed JWT generated for 403 CDNI redirection MUST NOT add a Client IP claim if no Client IP 404 claim existed in the received signed JWT. 406 o Expiry Time (exp) [optional] - The semantics in [RFC7519] 407 Section 4.1.4 MUST be followed, though URI Signing implementations 408 MUST not allow for any time synchronization "leeway". Note: The 409 time on the entities that generate and validate the signed URI 410 SHOULD be in sync. In the CDNI case, this means that CSP, uCDN 411 and dCDN servers need to be time-synchronized. It is RECOMMENDED 412 to use NTP for time synchronization. If the CDN validating the 413 signed JWT does not support Expiry Time validation, or if the 414 Expiry Time in the signed JWT corresponds to a time earlier than 415 the time of the content request request, the CDN MUST reject the 416 request. If the received signed JWT contains a Expiry Time claim, 417 then any JWT subsequently generated for CDNI redirection MUST also 418 contain an Expiry Time claim, and the Expiry Time value MUST be 419 the same as in the received signed JWT. A signed JWT generated 420 for CDNI redirection MUST NOT add an Expiry Time claim if no 421 Expiry Time claim existed in the received signed JWT. 423 o Not Before (nbf) [optional] - The semantics in [RFC7519] 424 Section 4.1.5 MUST be followed, though URI Signing implementations 425 MUST not allow for any time synchronization "leeway". Note: The 426 time on the entities that generate and validate the signed URI 427 SHOULD be in sync. In the CDNI case, this means that the CSP, 428 uCDN, and dCDN servers need to be time-synchronized. It is 429 RECOMMENDED to use NTP for time synchronization. If the CDN 430 validating the signed JWT does not support Not Before time 431 validation, or if the Not Before time in the signed JWT 432 corresponds to a time later than the time of the content request 433 request, the CDN MUST reject the request. If the received signed 434 JWT contains a Not Before time claim, then any JWT subsequently 435 generated for CDNI redirection MUST also contain a Not Before time 436 claim, and the Not Before time value MUST be the same as in the 437 received signed JWT. A signed JWT generated for CDNI redirection 438 MUST NOT add a Not Before time claim if no Not Before time claim 439 existed in the received signed JWT. 441 o Issued At (iat) [optional] - The semantics in [RFC7519] 442 Section 4.1.6 MUST be followed. Note: The time on the entities 443 that generate and validate the signed URI SHOULD be in sync. In 444 the CDNI case, this means that CSP, uCDN, and dCDN servers need to 445 be time-synchronized. It is RECOMMENDED to use NTP for time 446 synchronization. If the received signed JWT contains an Issued At 447 claim, then any JWT subsequently generated for CDNI redirection 448 MUST also contain an Issued At claim, and the Issuer value MUST be 449 updated to identify the time the new JWT was generated. If the 450 received signed JWT does not contain an Issued At claim, an Issued 451 At claim MAY be added to a signed JWT generated for CDNI 452 redirection. 454 o Nonce (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 455 MUST be followed. Can be used to prevent replay attacks if the 456 CDN stores a list of all previously used Nonce values, and 457 validates that the Nonce in the current JWT has never been used 458 before. If the signed JWT contains a Nonce claim and the CDN 459 validating the signed JWT does not support Nonce storage, then the 460 CDN MUST reject the request. If the received signed JWT contains 461 a Nonce claim, then any JWT subsequently generated for CDNI 462 redirection MUST also contain a Nonce claim, and the Nonce value 463 MUST be the same as in the received signed JWT. If the received 464 signed JWT does not contain a Nonce claim, a Nonce claim MAY be 465 added to a signed JWT generated for CDNI redirection. 467 Note: See the Security Considerations (Section 7) section on the 468 limitations of using an expiration time and client IP address for 469 distribution policy enforcement. 471 2.1.1. URI Container Forms 473 The URI Container (sub) claim takes one of the following forms. More 474 forms may be added in the future to extend the capabilities. 476 2.1.1.1. URI Simple Container (uri:) 478 When prefixed with 'uri:', the string following 'uri:' is the URI 479 that MUST be matched with a simple string match to the requested URI. 481 2.1.1.2. URI Pattern Container (uri-pattern:) 483 Prefixed with 'uri-pattern:', this string contains one or more URI 484 Patterns that describes for which content the Signed URI is valid. 485 Each URI Pattern contains an expression to match against the 486 requested URI, to check whether the requested content is allowed to 487 be served. Multiple URI Patterns may be concatenated in a single URI 488 Pattern by separating them with a semi-colon (';') character. Each 489 URI Pattern follows the [RFC3986] URI format, including the '://' 490 that delimits the URI scheme from the hierarchy part. The pattern 491 may include the special literals: 493 ';' - separates individual patterns when the string contains 494 multiple URI patterns. 496 '*' - matches any sequence of characters, including the empty 497 string. 499 '?' - matches exactly one character. 501 '$' - used to escape the special literals; MUST be followed by 502 exactly one of ';', '*', '?', or '$'. 504 The following is an example of a valid URI Pattern: 506 *://*/folder/content-83112371/quality_*/segment????.mp4 508 An example of two concatenated URI Patterns is the following 509 (whitespace is inserted after the ';' for readability and should not 510 be present in the actual representation): 512 http://*/folder/content-83112371/manifest/*.xml; 513 http://*/folder/content-83112371/quality_*/segment????.mp4 515 In order to increase the performance of string parsing the URI 516 Pattern, implementations can check often-used URI Pattern prefixes to 517 quickly check whether certain URI components can be ignored. For 518 example, URI Pattern prefixes '*://*/' or '*://*:*' will be used in 519 case the scheme and authority components of the URI are ignored for 520 purposes of pattern enforcement. 522 2.1.1.3. URI Regular Expression Container (uri-regex:) 524 Prefixed with 'uri-regex:', this string is any PCRE [PCRE839] 525 compatible regular expression used to match against the requested 526 URI. 528 Note: Because '\' has special meaning in JSON [RFC7159] as the escape 529 character within JSON strings, the regular expression character '\' 530 MUST be escaped as '\\'. 532 An example of a 'uri-regex:' is the following: 534 .*\\://.*/folder/content-83112371/quality_.*/segment.{3}\\.mp4 536 Note: Due to computational complexity of executing arbitrary regular 537 expressions, it is RECOMMENDED to only execute after validating the 538 JWT to ensure its authenticity. 540 3. Relationship with CDNI Interfaces 542 Some of the CDNI Interfaces need enhancements to support URI Signing. 543 As an example: A dCDN that supports URI Signing needs to be able to 544 advertise this capability to the uCDN. The uCDN needs to select a 545 dCDN based on such capability when the CSP requires access control to 546 enforce its distribution policy via URI Signing. Also, the uCDN 547 needs to be able to distribute via the CDNI Metadata interface the 548 information necessary to allow the dCDN to validate a Signed URI. 549 Events that pertain to URI Signing (e.g., request denial or delivery 550 after access authorization) need to be included in the logs 551 communicated through the CDNI Logging interface (Editor's Note: Is 552 this within the scope of the CDNI Logging interface?). 554 3.1. CDNI Control Interface 556 URI Signing has no impact on this interface. 558 3.2. CDNI Footprint & Capabilities Advertisement Interface 560 The CDNI Request Routing: Footprint and Capabilities Semantics 561 document [I-D.ietf-cdni-footprint-capabilities-semantics] defines 562 support for advertising CDNI Metadata capabilities, via CDNI Payload 563 Type. The CDNI Payload Type registered in Section 6.1 can be used 564 for capability advertisement. 566 3.3. CDNI Request Routing Redirection Interface 568 The CDNI Request Routing Redirection Interface 569 [I-D.ietf-cdni-redirection] describes the recursive request 570 redirection method. For URI Signing, the uCDN signs the URI provided 571 by the dCDN. URI Signing therefore has has no impact on this 572 interface. 574 3.4. CDNI Metadata Interface 576 The CDNI Metadata Interface [I-D.ietf-cdni-metadata] describes the 577 CDNI metadata distribution in order to enable content acquisition and 578 delivery. For URI Signing, a new CDNI metadata object is specified. 580 The UriSigning Metadata object contains information to enable URI 581 signing and validation by a dCDN. The UriSigning properties are 582 defined below. 584 Property: enforce 586 Description: URI Signing enforcement flag. Specifically, this 587 flag indicates if the access to content is subject to URI 588 Signing. URI Signing requires the dCDN to ensure that the URI 589 must be signed and validated before delivering content. 590 Otherwise, the dCDN does not perform validation, regardless of 591 whether or not the URI is signed. 593 Type: Boolean 595 Mandatory-to-Specify: No. The default is true. 597 Property: issuers 599 Description: A list of valid Issuers against which the Issuer 600 claim in the signed JWT may be validated. 602 Type: Array of Strings 604 Mandatory-to-Specify: No. The default is an empty list. An 605 empty list means that any Issuer is acceptable. 607 Property: package-attribute 609 Description: The name to use for the URI Signing Package. 611 Type: String 613 Mandatory-to-Specify: No. Default is "URISigningPackage". 615 The following is an example of a URI Signing metadata payload with 616 all default values: 618 { 619 "generic-metadata-type": "MI.UriSigning" 620 "generic-metadata-value": {} 621 } 623 The following is an example of a URI Signing metadata payload with 624 explicit values: 626 { 627 "generic-metadata-type": "MI.UriSigning" 628 "generic-metadata-value": 629 { 630 "enforce": true, 631 "issuers": ["csp", "ucdn1", "ucdn2"], 632 "package-attribute": "usp" 633 } 634 } 636 3.5. CDNI Logging Interface 638 For URI Signing, the dCDN reports that enforcement of the access 639 control was applied to the request for content delivery. When the 640 request is denied due to enforcement of URI Signing, the reason is 641 logged. 643 The following CDNI Logging field for URI Signing SHOULD be supported 644 in the HTTP Request Logging Record as specified in CDNI Logging 645 Interface [I-D.ietf-cdni-logging], using the new 646 "cdni_http_request_v2" record-type registered in Section 6.2.1. 648 o s-uri-signing (mandatory): 650 * format: 3DIGIT 652 * field value: this characterises the URI signing validation 653 performed by the Surrogate on the request. The allowed values 654 are: 656 + "000" : no signed JWT validation performed 658 + "200" : signed JWT validation performed and validated 659 + "400" : signed JWT validation performed and rejected because 660 of incorrect signature 662 + "401" : signed JWT validation performed and rejected because 663 of Expiration Time enforcement 665 + "402" : signed JWT validation performed and rejected because 666 of Client IP enforcement 668 + "403" : signed JWT validation performed and rejected because 669 of URI Pattern enforcement 671 + "404" : signed JWT validation performed and rejected because 672 of Issuer enforcement 674 + "405" : signed JWT validation performed and rejected because 675 of Not Before enforcement 677 + "500" : unable to perform signed JWT validation because of 678 malformed URI 680 * occurrence: there MUST be zero or exactly one instance of this 681 field. 683 o s-uri-signing-deny-reason (optional): 685 * format: QSTRING 687 * field value: a string for providing further information in case 688 the signed JWT was rejected, e.g., for debugging purposes. 690 * occurrence: there MUST be zero or exactly one instance of this 691 field. 693 4. URI Signing Message Flow 695 URI Signing supports both HTTP-based and DNS-based request routing. 696 JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of 697 representing claims to be transferred between two parties. The 698 claims in a signed JWT are encoded as a JSON object that is used as 699 the payload of a JSON Web Signature (JWS) structure or as the 700 plaintext of a JSON Web Encryption (JWE) structure, enabling the 701 claims to be digitally signed or integrity protected with a Message 702 Authentication Code (MAC) and/or encrypted. 704 4.1. HTTP Redirection 706 For HTTP-based request routing, a set of information that is unique 707 to a given end user content request is included in a signed JWT, 708 using key information that is specific to a pair of adjacent CDNI 709 hops (e.g. between the CSP and the uCDN, between the uCDN and a 710 dCDN). This allows a CDNI hop to ascertain the authenticity of a 711 given request received from a previous CDNI hop. 713 The URI signing method described below is based on the following 714 steps (assuming HTTP redirection, iterative request routing, and a 715 CDN path with two CDNs). Note that uCDN and uCDN are used 716 exchangeably. 718 End-User dCDN uCDN CSP 719 | | | | 720 | 1.CDNI FCI interface used to | | 721 | advertise URI Signing capability| | 722 | |------------------->| | 723 | | | | 724 | 2.Provides information to validate signed JWT | 725 | | |<-------------------| 726 | | | | 727 | 3.CDNI Metadata interface used to| | 728 | provide URI Signing attributes| | 729 | |<-------------------| | 730 |4.Authorization request | | 731 |------------------------------------------------------------->| 732 | | | [Apply distribution 733 | | | policy] | 734 | | | | 735 | | (ALT: Authorization decision) 736 |5.Request is denied | | | 737 |<-------------------------------------------------------------| 738 | | | | 739 |6.CSP provides signed URI | | 740 |<-------------------------------------------------------------| 741 | | | | 742 |7.Content request | | | 743 |---------------------------------------->| [Validate URI | 744 | | | signature] | 745 | | | | 746 | | (ALT: Validation result) | 747 |8.Request is denied | | | 748 |<----------------------------------------| | 749 | | | | 750 |9.Re-sign URI and redirect to | | 751 | dCDN (newly signed URI) | | 752 |<----------------------------------------| | 753 | | | | 754 |10.Content request | | | 755 |------------------->| [Validate URI | | 756 | | signature] | | 757 | | | | 758 | (ALT: Validation result) | | 759 |11.Request is denied| | | 760 |<-------------------| | | 761 | | | | 762 |12.Content delivery | | | 763 |<-------------------| | | 764 : : : : 765 : (Later in time) : : : 766 |13.CDNI Logging interface to include URI Signing information | 767 | |------------------->| | 769 Figure 3: HTTP-based Request Routing with URI Signing 771 1. Using the CDNI Footprint & Capabilities Advertisement interface, 772 the dCDN advertises its capabilities including URI Signing 773 support to the uCDN. 775 2. CSP provides to the uCDN the information needed to validate 776 signed JWTs from that CSP. For example, this information may 777 include a key value. 779 3. Using the CDNI Metadata interface, the uCDN communicates to a 780 dCDN the information needed to validate signed JWTs from the 781 uCDN for the given CSP. For example, this information may 782 include the URI query string parameter name for the URI Signing 783 Package Attribute. 785 4. When a UA requests a piece of protected content from the CSP, 786 the CSP makes a specific authorization decision for this unique 787 request based on its arbitrary distribution policy. 789 5. If the authorization decision is negative, the CSP rejects the 790 request. 792 6. If the authorization decision is positive, the CSP computes a 793 Signed URI that is based on unique parameters of that request 794 and conveys it to the end user as the URI to use to request the 795 content. 797 7. On receipt of the corresponding content request, the uCDN 798 validates the signed JWT in the URI using the information 799 provided by the CSP. 801 8. If the validation is negative, the uCDN rejects the request. 803 9. If the validation is positive, the uCDN computes a Signed URI 804 that is based on unique parameters of that request and provides 805 to the end user as the URI to use to further request the content 806 from the dCDN. 808 10. On receipt of the corresponding content request, the dCDN 809 validates the signed JWT in the Signed URI using the information 810 provided by the uCDN in the CDNI Metadata. 812 11. If the validation is negative, the dCDN rejects the request and 813 sends an error code (e.g., 403 Forbidden) in the HTTP response. 815 12. If the validation is positive, the dCDN serves the request and 816 delivers the content. 818 13. At a later time, dCDN reports logging events that includes URI 819 signing information. 821 With HTTP-based request routing, URI Signing matches well the general 822 chain of trust model of CDNI both with symmetric and asymmetric keys 823 because the key information only needs to be specific to a pair of 824 adjacent CDNI hops. 826 4.2. DNS Redirection 828 For DNS-based request routing, the CSP and uCDN must agree on a trust 829 model appropriate to the security requirements of the CSP's 830 particular content. Use of asymmetric public/private keys allows for 831 unlimited distribution of the public key to dCDNs. However, if a 832 shared secret key is preferred, then the CSP may want to restrict the 833 distribution of the key to a (possibly empty) subset of trusted 834 dCDNs. Authorized Delivery CDNs need to obtain the key information 835 to validate the Signed URI. 837 The URI signing method described below is based on the following 838 steps (assuming iterative DNS request routing and a CDN path with two 839 CDNs). 841 End-User dCDN uCDN CSP 842 | | | | 843 | 1.CDNI FCI interface used to | | 844 | advertise URI Signing capability| | 845 | |------------------->| | 846 | | | | 847 | 2.Provides information to validate signed JWT | 848 | | |<-------------------| 849 | 3.CDNI Metadata interface used to| | 850 | provide URI Signing attributes| | 851 | |<-------------------| | 852 |4.Authorization request | | 853 |------------------------------------------------------------->| 854 | | | [Apply distribution 855 | | | policy] | 856 | | | | 857 | | (ALT: Authorization decision) 858 |5.Request is denied | | | 859 |<-------------------------------------------------------------| 860 | | | | 861 |6.Provides signed URI | | 862 |<-------------------------------------------------------------| 863 | | | | 864 |7.DNS request | | | 865 |---------------------------------------->| | 866 | | | | 867 |8.Redirect DNS to dCDN | | 868 |<----------------------------------------| | 869 | | | | 870 |9.DNS request | | | 871 |------------------->| | | 872 | | | | 873 |10.IP address of Surrogate | | 874 |<-------------------| | | 875 | | | | 876 |11.Content request | | | 877 |------------------->| [Validate URI | | 878 | | signature] | | 879 | | | | 880 | (ALT: Validation result) | | 881 |12.Request is denied| | | 882 |<-------------------| | | 883 | | | | 884 |13.Content delivery | | | 885 |<-------------------| | | 886 : : : : 887 : (Later in time) : : : 888 |14.CDNI Logging interface to report URI Signing information | 889 | |------------------->| | 891 Figure 4: DNS-based Request Routing with URI Signing 893 1. Using the CDNI Footprint & Capabilities Advertisement interface, 894 the dCDN advertises its capabilities including URI Signing 895 support to the uCDN. 897 2. CSP provides to the uCDN the information needed to validate 898 cryptographic signatures from that CSP. For example, this 899 information may include a key. 901 3. Using the CDNI Metadata interface, the uCDN communicates to a 902 dCDN the information needed to validate cryptographic signatures 903 from the CSP (e.g., the URI query string parameter name for the 904 URI Signing Package Attribute). In the case of symmetric key, 905 the uCDN checks if the dCDN is allowed by CSP to obtain the 906 shared secret key. 908 4. When a UA requests a piece of protected content from the CSP, 909 the CSP makes a specific authorization decision for this unique 910 request based on its arbitrary distribution policy. 912 5. If the authorization decision is negative, the CSP rejects the 913 request. 915 6. If the authorization decision is positive, the CSP computes a 916 cryptographic signature that is based on unique parameters of 917 that request and includes it in the URI provided to the end user 918 to request the content. 920 7. End user sends DNS request to the uCDN. 922 8. On receipt of the DNS request, the uCDN redirects the request to 923 the dCDN. 925 9. End user sends DNS request to the dCDN. 927 10. On receipt of the DNS request, the dCDN responds with IP address 928 of one of its Surrogates. 930 11. On receipt of the corresponding content request, the dCDN 931 validates the cryptographic signature in the URI using the 932 information provided by the uCDN in the CDNI Metadata. 934 12. If the validation is negative, the dCDN rejects the request and 935 sends an error code (e.g., 403) in the HTTP response. 937 13. If the validation is positive, the dCDN serves the request and 938 delivers the content. 940 14. At a later time, dCDN reports logging events that includes URI 941 signing information. 943 With DNS-based request routing, URI Signing matches well the general 944 chain of trust model of CDNI when used with asymmetric keys because 945 the only key information that needs to be distributed across 946 multiple, possibly non-adjacent, CDNI hops is the public key, which 947 is generally not confidential. 949 With DNS-based request routing, URI Signing does not match well the 950 general chain of trust model of CDNI when used with symmetric keys 951 because the symmetric key information needs to be distributed across 952 multiple CDNI hops, including non-adjacent hops. This raises a 953 security concern for applicability of URI Signing with symmetric keys 954 in case of DNS-based inter-CDN request routing. 956 5. HTTP Adaptive Streaming 958 The authors note that in order to perform URI signing for individual 959 content segments of HTTP Adaptive Bitrate content, specific URI 960 signing mechanisms are needed. Such mechanisms are currently out-of- 961 scope of this document. More details on this topic is covered in 962 Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. In 963 addition, [I-D.brandenburg-cdni-uri-signing-for-has] provides an 964 extension to the algorithm defined in this document that deals 965 specifically with URI signing of segmented content. 967 6. IANA Considerations 969 6.1. CDNI Payload Type 971 This document requests the registration of the following CDNI Payload 972 Type under the IANA "CDNI Payload Type" registry: 974 +---------------+---------------+ 975 | Payload Type | Specification | 976 +---------------+---------------+ 977 | MI.UriSigning | RFCthis | 978 +---------------+---------------+ 980 [RFC Editor: Please replace RFCthis with the published RFC number for 981 this document.] 983 6.1.1. CDNI UriSigning Payload Type 985 Purpose: The purpose of this payload type is to distinguish 986 UriSigning MI objects (and any associated capability advertisement). 988 Interface: MI/FCI 990 Encoding: see Section 3.4 992 6.2. CDNI Logging Record Type 994 This document requests the registration of the following CDNI Logging 995 record-type under the IANA "CDNI Logging record-types" registry: 997 +----------------------+-----------+--------------------------------+ 998 | record-types | Reference | Description | 999 +----------------------+-----------+--------------------------------+ 1000 | cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | 1001 | | | Record version 1 for content | 1002 | | | delivery using HTTP, to | 1003 | | | include URI Signing logging | 1004 | | | fields | 1005 +----------------------+-----------+--------------------------------+ 1007 [RFC Editor: Please replace RFCthis with the published RFC number for 1008 this document.] 1010 6.2.1. CDNI Logging Record Version 2 for HTTP 1012 The "cdni_http_request_v2" record-type supports all of the fields 1013 supported by the "cdni_http_request_v1" record-type 1014 [I-D.ietf-cdni-logging] plus the two additional fields "s-uri- 1015 signing" and "s-uri-signing-deny-reason", registered by this document 1016 in Section 6.3. The name, format, field value, and occurence 1017 information for the two new fields can be found in Section 3.5 of 1018 this document. 1020 6.3. CDNI Logging Field Names 1022 This document requests the registration of the following CDNI Logging 1023 fields under the IANA "CDNI Logging Field Names" registry: 1025 +---------------------------+-----------+ 1026 | Field Name | Reference | 1027 +---------------------------+-----------+ 1028 | s-uri-signing | RFCthis | 1029 | s-uri-signing-deny-reason | RFCthis | 1030 +---------------------------+-----------+ 1032 [RFC Editor: Please replace RFCthis with the published RFC number for 1033 this document.] 1035 7. Security Considerations 1037 This document describes the concept of URI Signing and how it can be 1038 used to provide access authorization in the case of CDNI. The 1039 primary goal of URI Signing is to make sure that only authorized UAs 1040 are able to access the content, with a CSP being able to authorize 1041 every individual request. It should be noted that URI Signing is not 1042 a content protection scheme; if a CSP wants to protect the content 1043 itself, other mechanisms, such as DRM, are more appropriate. 1045 In general, it holds that the level of protection against 1046 illegitimate access can be increased by including more claims in the 1047 signed JWT. The current version of this document includes claims for 1048 enforcing Issuer, Client IP Address, Not Before time, and Expiration 1049 Time, however this list can be extended with other, more complex, 1050 attributes that are able to provide some form of protection against 1051 some of the vulnerabilities highlighted below. 1053 That said, there are a number of aspects that limit the level of 1054 security offered by URI Signing and that anybody implementing URI 1055 Signing should be aware of. 1057 Replay attacks: A (valid) Signed URI may be used to perform replay 1058 attacks. The vulnerability to replay attacks can be reduced by 1059 picking a relatively short window between the Not Before time and 1060 Expiration Time attributes, although this is limited by the fact 1061 that any HTTP-based request needs a window of at least a couple of 1062 seconds to prevent a sudden network issues from preventing 1063 legitimate UAs access to the content. One may also reduce 1064 exposure to replay attacks by including a unique one-time access 1065 ID via the Nonce attribute (jti claim). Whenever the dCDN 1066 receives a request with a given unique ID, it adds that ID to the 1067 list of 'used' IDs. In the case an illegitimate UA tries to use 1068 the same URI through a replay attack, the dCDN can deny the 1069 request based on the already-used access ID. 1071 Illegitimate clients behind a NAT: In cases where there are 1072 multiple users behind the same NAT, all users will have the same 1073 IP address from the point of view of the dCDN. This results in 1074 the dCDN not being able to distinguish between the different users 1075 based on Client IP Address and illegitimate users being able to 1076 access the content. One way to reduce exposure to this kind of 1077 attack is to not only check for Client IP but also for other 1078 attributes, e.g., attributes that can be found in HTTP headers. 1080 The shared key between CSP and uCDN may be distributed to dCDNs - 1081 including cascaded CDNs. Since this key can be used to legitimately 1082 sign a URL for content access authorization, it is important to know 1083 the implications of a compromised shared key. 1085 In the case where asymmetric keys are used, the KID information 1086 element might contain the URL to the public key. To prevent 1087 malicious clients from signing their own URIs and inserting the 1088 associated public key URL in the KID field, thereby passing URI 1089 validation, it is important that CDNs check whether the URI conveyed 1090 in the KID field is in the allowable set of KIDs as listed in the 1091 CDNI metadata or set via configuration. 1093 8. Privacy 1095 The privacy protection concerns described in CDNI Logging Interface 1096 [I-D.ietf-cdni-logging] apply when the client's IP address (aud) is 1097 embedded in the Signed URI. For this reason, the mechanism described 1098 in Section 2 encrypts the Client IP before including it in the URI 1099 Signing Package (and thus the URL itself). 1101 9. Acknowledgements 1103 The authors would like to thank the following people for their 1104 contributions in reviewing this document and providing feedback: 1105 Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan 1106 York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana 1107 Oprescu, Leif Hedstrom and Gancho Tenev. In addition, Matt Caulfield 1108 provided content for the CDNI Metadata Interface section. 1110 10. References 1112 10.1. Normative References 1114 [I-D.ietf-cdni-logging] 1115 Faucheur, F., Bertrand, G., Oprescu, I., and R. 1116 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 1117 logging-27 (work in progress), June 2016. 1119 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1120 Requirement Levels", BCP 14, RFC 2119, 1121 DOI 10.17487/RFC2119, March 1997, 1122 . 1124 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1125 Distribution Network Interconnection (CDNI) Problem 1126 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1127 2012, . 1129 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1130 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1131 2014, . 1133 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1134 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1135 . 1137 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1138 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1139 . 1141 10.2. Informative References 1143 [I-D.brandenburg-cdni-uri-signing-for-has] 1144 Brandenburg, R., "URI Signing for HTTP Adaptive Streaming 1145 (HAS)", draft-brandenburg-cdni-uri-signing-for-has-03 1146 (work in progress), June 2016. 1148 [I-D.ietf-cdni-footprint-capabilities-semantics] 1149 Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., 1150 and K. Ma, "CDNI Request Routing: Footprint and 1151 Capabilities Semantics", draft-ietf-cdni-footprint- 1152 capabilities-semantics-20 (work in progress), May 2016. 1154 [I-D.ietf-cdni-metadata] 1155 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1156 "CDN Interconnection Metadata", draft-ietf-cdni- 1157 metadata-21 (work in progress), August 2016. 1159 [I-D.ietf-cdni-redirection] 1160 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 1161 Redirection interface for CDN Interconnection", draft- 1162 ietf-cdni-redirection-20 (work in progress), August 2016. 1164 [PCRE839] Hazel, P., "Perl Compatible Regular Expressions", 1165 Version 8.39, June 2016, . 1167 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1168 Resource Identifier (URI): Generic Syntax", STD 66, 1169 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1170 . 1172 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1173 Address Text Representation", RFC 5952, 1174 DOI 10.17487/RFC5952, August 2010, 1175 . 1177 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 1178 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 1179 Content Distribution Network Interconnection (CDNI)", 1180 RFC 6983, DOI 10.17487/RFC6983, July 2013, 1181 . 1183 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1184 "Framework for Content Distribution Network 1185 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1186 August 2014, . 1188 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1189 Network Interconnection (CDNI) Requirements", RFC 7337, 1190 DOI 10.17487/RFC7337, August 2014, 1191 . 1193 Appendix A. Signed URI Package Example 1195 This section contains two examples of token usage: a simple example 1196 with only the required claims present, and a complex example which 1197 demonstrates the full JWT claims set, including an encrypted Client 1198 IP (aud). 1200 Note: All of the examples have whitespace added to improve formatting 1201 and readability, but are not present in the generated content. 1203 Both examples use the following signing key to generate the Signed 1204 URI Package: 1206 { 1207 "kty": "EC", 1208 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1209 "use": "sig", 1210 "crv": "P-256", 1211 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1212 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", 1213 "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" 1214 } 1216 A.1. Simple Example 1218 This example is the simplest possible example containing the only 1219 required field (sub). 1221 The JWT Claim Set before signing: 1223 { 1224 "sub": "uri:http://cdni.example/foo/bar/baz" 1225 } 1227 The Signed JWT: 1229 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1230 dZRkRPV2tsZHVlYUltZjAifQ.eyJzdWIiOiJ1cmk6aHR0cDovL2NkbmkuZXhhbXBsZ 1231 S9mb28vYmFyL2JheiJ9.oC4yKwUchowx4KhMsI8MQ-Sq_1s3fC8NCi-IWcmNEE9MQz 1232 EEQfurJ1su2Op_dtYuc_fG8NixSVubz3HWKM4Rsw 1234 A.2. Complex Example 1236 This example uses all optional fields, including Client IP (aud) 1237 which is encrpyted. This significantly increases the size of the 1238 signed JWT token. 1240 Shared key used for encrpyting the Client IP (aud): 1242 { 1243 "kty": "oct", 1244 "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", 1245 "use": "enc", 1246 "alg": "A128GCM", 1247 "k": "4uFxxV7fhNmrtiah2d1fFg" 1248 } 1250 JWE for client IP (aud) of [2001:db8::1/32]: 1252 eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj 1253 g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..Ewl05cq3jmUe1Bv1.CHif9 1254 OMPmsMPgJ8tZgvD0A.R3I2C8nfppY2wBfc4xEPPQ 1256 The JWT Claim Set before signing: 1258 { 1259 "aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm 1260 dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..Ewl05cq3jmUe 1261 1Bv1.CHif9OMPmsMPgJ8tZgvD0A.R3I2C8nfppY2wBfc4xEPPQ", 1262 "exp": 1474243500, 1263 "iat": 1474243200, 1264 "iss": "Upstream CDN Inc", 1265 "jti": "5DAafLhZAfhsbe", 1266 "nbf": 1474243200, 1267 "sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.png" 1268 } 1270 The Signed JWT: 1272 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1273 dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJleUpoYkdjaU9pSmthWElpTENKcmFXU 1274 WlPaUptTFZkaWFuaENRek5rVUhWSk0yUXlOR3RRTW1obWRtOXpOMUY2TmpnNFZWUnB 1275 ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLkV3bDA1Y3Ezam1VZ 1276 TFCdjEuQ0hpZjlPTVBtc01QZ0o4dFpndkQwQS5SM0kyQzhuZnBwWTJ3QmZjNHhFUFB 1277 RIiwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6IlVwc3RyZ 1278 WFtIENETiBJbmMiLCJqdGkiOiI1REFhZkxoWkFmaHNiZSIsIm5iZiI6MTQ3NDI0MzI 1279 wMCwic3ViIjoidXJpLXJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL 1280 2Jhei9bMC05XXszfVxcLnBuZyJ9.AtDNW7mwFIJPqsWAn9ojzj4imE-vTowR-FRzil 1281 vnSQuQMz_u4sIspxe6RoXo_Ti8rVMgJ0jOdSvVnQUJZdfRUQ 1283 Authors' Addresses 1285 Ray van Brandenburg 1286 TNO 1287 Anna van Buerenplein 1 1288 Den Haag 2595DC 1289 the Netherlands 1291 Phone: +31 88 866 7000 1292 Email: ray.vanbrandenburg@tno.nl 1294 Kent Leung 1295 Cisco Systems, Inc. 1296 3625 Cisco Way 1297 San Jose, CA 95134 1298 United States 1300 Phone: +1 408 526 5030 1301 Email: kleung@cisco.com 1303 Phil Sorber 1304 Comcast Cable Communications 1305 1401 Wynkoop Street, Suite 300 1306 Denver, CO 80202 1307 United States 1309 Phone: +1 720 502 3785 1310 Email: phillip_sorber@comcast.com 1311 Matthew Miller 1312 Cisco Systems, Inc. 1313 1899 Wynkoop Street, Suite 600 1314 Denver, CO 80202 1315 United States 1317 Email: mamille2@cisco.com