idnits 2.17.1 draft-ietf-cdni-uri-signing-13.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 291 has weird spacing: '...I(after v ...' -- The document date (October 30, 2017) is 2363 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI R. van Brandenburg 3 Internet-Draft Tiledmedia 4 Intended status: Standards Track K. Leung 5 Expires: May 3, 2018 Cisco Systems, Inc. 6 P. Sorber 7 Comcast Cable Communications 8 October 30, 2017 10 URI Signing for CDN Interconnection (CDNI) 11 draft-ietf-cdni-uri-signing-13 13 Abstract 15 This document describes how the concept of URI signing supports the 16 content access control requirements of CDNI and proposes a URI 17 signing method as a JSON Web Token (JWT) [RFC7519] profile. 19 The proposed URI signing method specifies the information needed to 20 be included in the URI to transmit the signed JWT as well as the 21 claims needed by the signed JWT to authorize a UA. The mechanism 22 described can be used both in CDNI and single CDN scenarios. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 3, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Background and overview on URI Signing . . . . . . . . . 5 61 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 62 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 63 2. JWT Format and Processing Requirements . . . . . . . . . . . 9 64 2.1. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . 9 65 2.1.1. Issuer (iss) claim . . . . . . . . . . . . . . . . . 10 66 2.1.2. URI Container (sub) claim . . . . . . . . . . . . . . 10 67 2.1.3. Client IP (aud) claim . . . . . . . . . . . . . . . . 10 68 2.1.4. Expiry Time (exp) claim . . . . . . . . . . . . . . . 11 69 2.1.5. Not Before (nbf) claim . . . . . . . . . . . . . . . 11 70 2.1.6. Issued At (iat) claim . . . . . . . . . . . . . . . . 11 71 2.1.7. Nonce (jti) claim . . . . . . . . . . . . . . . . . . 12 72 2.1.8. CDNI Claim Set Version (cdniv) claim . . . . . . . . 12 73 2.1.9. CDNI Expiration Time Setting (cdniets) claim . . . . 12 74 2.1.10. CDNI Signed Token Transport (cdnistt) claim . . . . . 13 75 2.1.11. URI Container Forms . . . . . . . . . . . . . . . . . 13 76 2.1.11.1. URI Simple Container (uri:) . . . . . . . . . . 13 77 2.1.11.2. URI Pattern Container (uri-pattern:) . . . . . . 13 78 2.1.11.3. URI Regular Expression Container (uri-regex:) . 14 79 2.1.11.4. URI Hash Container (uri-hash:) . . . . . . . . . 14 80 2.2. JWT Header . . . . . . . . . . . . . . . . . . . . . . . 14 81 3. URI Signing Token Renewal . . . . . . . . . . . . . . . . . . 15 82 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 83 3.2. Signed Token Renewal mechanism . . . . . . . . . . . . . 15 84 3.3. Communicating a signed JWTs in Signed Token Renewal . . . 16 85 3.3.1. Support for cross-domain redirection . . . . . . . . 16 86 4. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 17 87 4.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 17 88 4.2. CDNI Footprint & Capabilities Advertisement Interface . . 17 89 4.3. CDNI Request Routing Redirection Interface . . . . . . . 17 90 4.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 17 91 4.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 19 92 5. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 20 93 5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 20 94 5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 23 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 96 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 26 97 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 26 98 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 26 99 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 27 100 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 27 101 6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 27 102 6.5. JSON Web Token Claims Registration . . . . . . . . . . . 28 103 6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 28 104 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 105 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 107 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 109 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 110 11.2. Informative References . . . . . . . . . . . . . . . . . 31 111 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 33 112 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 34 113 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 34 114 A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 35 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 117 1. Introduction 119 This document describes the concept of URI Signing and how it can be 120 used to provide access authorization in the case of redirection 121 between interconnected CDNs (CDNI) and between a Content Service 122 Provider (CSP) and a CDN. The primary goal of URI Signing is to make 123 sure that only authorized User Agents (UAs) are able to access the 124 content, with a CSP being able to authorize every individual request. 125 It should be noted that URI Signing is not a content protection 126 scheme; if a CSP wants to protect the content itself, other 127 mechanisms, such as Digital Rights Management (DRM), are more 128 appropriate. In addition to access control, URI Signing also has 129 benefits in reducing the impact of denial-of-service attacks. 131 The overall problem space for CDN Interconnection (CDNI) is described 132 in CDNI Problem Statement [RFC6707]. This document, along with the 133 CDNI Requirements [RFC7337] document and the CDNI Framework 134 [RFC7336], describes the need for interconnected CDNs to be able to 135 implement an access control mechanism that enforces the CSP's 136 distribution policy. 138 Specifically, CDNI Framework [RFC7336] states: 140 The CSP may also trust the CDN operator to perform actions such as 141 ..., and to enforce per-request authorization performed by the CSP 142 using techniques such as URI signing. 144 In particular, the following requirement is listed in CDNI 145 Requirements [RFC7337]: 147 MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of 148 authorization checks and validation that are to be performed by 149 the Surrogate before delivery. For example, this could 150 potentially include the need to validate information (e.g., Expiry 151 time, Client IP address) required for access authorization. 153 This document proposes a method of signing URIs that allows 154 Surrogates in interconnected CDNs to enforce a per-request 155 authorization performed by the CSP. Splitting the role of performing 156 per-request authorization by the CSP and the role of validating this 157 authorization by the CDN allows any arbitrary distribution policy to 158 be enforced across CDNs without the need of CDNs to have any 159 awareness of the actual CSP distribution policy. 161 The representation of this method is a Signed JSON Web Token (JWT) 162 [RFC7519]. 164 1.1. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 This document uses the terminology defined in CDNI Problem Statement 173 [RFC6707]. 175 This document also uses the terminology of JSON Web Token (JWT) 176 [RFC7519]. 178 In addition, the following terms are used throughout this document: 180 o Signed URI: A URI for which a signed JWT is provided. 182 o Target CDN URI: URI created by the CSP to direct a UA towards the 183 Upstream CDN (uCDN). The Target CDN URI can be signed by the CSP 184 and verified by the uCDN and possibly further Downstream CDNs 185 (dCDNs). 187 o Redirection URI: URI created by the uCDN to redirect a UA towards 188 the dCDN. The Redirection URI can be signed by the uCDN and 189 verified by the dCDN. In a cascaded CDNI scenario, there can be 190 more than one Redirection URI. 192 o Signed Token Renewal: A series of signed JWTs that are used for 193 subsequent access to a set of related resources in a CDN, such as 194 a set of HTTP Adaptive Streaming files. Every time a signed JWT 195 is used to access a particular resource, a new signed JWT is sent 196 along with the resource that can be used to request the next 197 resource in the set. When generating a new signed JWT in Signed 198 Token Renewal, parameters are carried over from one signed JWT to 199 the next. 201 1.2. Background and overview on URI Signing 203 A CSP and CDN are assumed to have a trust relationship that enables 204 the CSP to authorize access to a content item by including a set of 205 claims in the form of a signed JWT in the URI before redirecting a UA 206 to the CDN. Using these attributes, it is possible for a CDN to 207 check an incoming content request to see whether it was authorized by 208 the CSP (e.g., based on the UA's IP address or a time window). To 209 prevent the UA from altering the claims a signed JWT is REQUIRED. 211 Figure 1, shown below, presents an overview of the URI Signing 212 mechanism in the case of a CSP with a single CDN. When the UA 213 browses for content on CSP's website (#1), it receives HTML web pages 214 with embedded content URIs. Upon requesting these URIs, the CSP 215 redirects to a CDN, creating a Target CDN URI (#2) (alternatively, 216 the Target CDN URI itself is embedded in the HTML). The Target CDN 217 URI is the Signed URI which may include the IP address of the UA and/ 218 or a time window and always contains the signed JWT which is 219 generated by the CSP using a shared secret or private key. Once the 220 UA receives the response with the Signed URI, it sends a new HTTP 221 request using the Signed URI to the CDN (#3). Upon receiving the 222 request, the CDN checks to see if the Signed URI is authentic by 223 verifying the signed JWT. If applicable, it checks whether the IP 224 address of the HTTP request matches that in the Signed URI and if the 225 time window is still valid. After these claims are confirmed to be 226 valid, the CDN delivers the content (#4). 228 -------- 229 / \ 230 | CSP |< * * * * * * * * * * * 231 \ / Trust * 232 -------- relationship * 233 ^ | * 234 | | * 235 1. Browse | | 2. Signed * 236 for | | URI * 237 content | | * 238 | v v 239 +------+ 3. Signed URI -------- 240 | User |----------------->/ \ 241 | Agent| | CDN | 242 | |<-----------------\ / 243 +------+ 4. Content -------- 244 Delivery 246 Figure 1: Figure 1: URI Signing in a CDN Environment 248 1.3. CDNI URI Signing Overview 250 In a CDNI environment, URI Signing operates the same way in the 251 initial steps #1 and #2 but the later steps involve multiple CDNs in 252 the process of delivering the content. The main difference from the 253 single CDN case is a redirection step between the uCDN and the dCDN. 254 In step #3, UA may send an HTTP request or a DNS request. Depending 255 on whether HTTP-based or DNS-based request routing is used, the uCDN 256 responds by directing the UA towards the dCDN using either a 257 Redirection URI (which is a Signed URI generated by the uCDN) or a 258 DNS reply, respectively (#4). Once the UA receives the response, it 259 sends the Redirection URI/Target CDN URI to the dCDN (#5). The 260 received URI is validated by the dCDN before delivering the content 261 (#6). This is depicted in the figure below. Note: The CDNI call 262 flows are covered in Detailed URI Signing Operation (Section 5). 264 +-------------------------+ 265 |Request Redirection Modes| 266 +-------------------------+ 267 | a) HTTP | 268 | b) DNS | 269 +-------------------------+ 270 -------- 271 / \< * * * * * * * * * * * * * * 272 | CSP |< * * * * * * * * * * * * 273 \ / Trust * * 274 -------- relationship * * 275 ^ | * * 276 | | 2. Signed * * 277 1. Browse | | URI in * * 278 for | | HTML * * 279 content | | * * 280 | v 3.a)Signed URI v * 281 +------+ b)DNS request -------- * Trust 282 | User |----------------->/ \ * relationship 283 | Agent| | uCDN | * (optional) 284 | |<-----------------\ / * 285 +------+ 4.a)Redirection URI------- * 286 ^ | b)DNS Reply ^ * 287 | | * * 288 | | Trust relationship * * 289 | | * * 290 6. Content | | 5.a)Redirection URI * * 291 delivery | | b)Signed URI(after v v 292 | | DNS exchange) -------- 293 | +---------------------->/ \ [May be 294 | | dCDN | cascaded 295 +--------------------------\ / CDNs] 296 -------- 298 +-----------------------------------------+ 299 | Key | Asymmetric | Symmetric | 300 +-----------------------------------------+ 301 |HTTP |Public key (uCDN)|Shared key (uCDN)| 302 |DNS |Public key (CSP) |Shared key (CSP) | 303 +-----------------------------------------+ 305 Figure 2: URI Signing in a CDNI Environment 307 The trust relationships between CSP, uCDN, and dCDN have direct 308 implications for URI Signing. In the case shown in Figure 2, the CDN 309 that the CSP has a trust relationship with is the uCDN. The delivery 310 of the content may be delegated to the dCDN, which has a relationship 311 with the uCDN but may have no relationship with the CSP. 313 In CDNI, there are two methods for request routing: DNS-based and 314 HTTP-based. For DNS-based request routing, the Signed URI (i.e., 315 Target CDN URI) provided by the CSP reaches the dCDN directly. In 316 the case where the dCDN does not have a trust relationship with the 317 CSP, this means that either an asymmetric public/private key method 318 needs to be used for computing the signed JWT (because the CSP and 319 dCDN are not able to exchange symmetric shared secret keys), or the 320 CSP needs to allow the uCDN to redistribute shared keys to a subset 321 of their dCDNs. 323 For HTTP-based request routing, the Signed URI (i.e., Target CDN URI) 324 provided by the CSP reaches the uCDN. After this URI has been 325 verified to be correct by the uCDN, the uCDN creates and signs a new 326 Redirection URI to redirect the UA to the dCDN. Since this new URI 327 could have a new signed JWT, a new signature can be based around the 328 trust relationship between the uCDN and dCDN, and the relationship 329 between the dCDN and CSP is not relevant. Given the fact that such a 330 relationship between uCDN and dCDN always exists, both asymmetric 331 public/private keys and symmetric shared secret keys can be used for 332 URI Signing with HTTP-based request routing. Note that the signed 333 Redirection URI MUST maintain the same, or higher, level of security 334 as the original Signed URI. 336 Two types of keys can be used for URI Signing: asymmetric keys and 337 symmetric keys. Asymmetric keys are based on a public/private key 338 pair mechanism and always contain a private key only known to the 339 entity signing the URI (either CSP or uCDN) and a public key for the 340 verification of the Signed URI. With symmetric keys, the same key is 341 used by both the signing entity for signing the URI as well as by the 342 validating entity for validating the Signed URI. Regardless of the 343 type of keys used, the validating entity has to obtain the key 344 (either the public or the symmetric key). There are very different 345 requirements for key distribution (out of scope of this document) 346 with asymmetric keys and with symmetric keys. Key distribution for 347 symmetric keys requires confidentiality to prevent another party from 348 getting access to the key, since it could then generate valid Signed 349 URIs for unauthorized requests. Key distribution for asymmetric keys 350 does not require confidentiality since public keys can typically be 351 distributed openly (because they cannot be used for URI signing) and 352 private keys are kept by the URI signing function. 354 1.4. URI Signing in a non-CDNI context 356 While the URI signing method defined in this document was primarily 357 created for the purpose of allowing URI Signing in CDNI scenarios, 358 e.g., between a uCDN and a dCDN or between a CSP and a dCDN, there is 359 nothing in the defined URI Signing method that precludes it from 360 being used in a non-CDNI context. As such, the described mechanism 361 could be used in a single-CDN scenario such as shown in Figure 1 in 362 Section 1.2, for example to allow a CSP that uses different CDNs to 363 only have to implement a single URI Signing mechanism. 365 2. JWT Format and Processing Requirements 367 The concept behind URI Signing is based on embedding a signed JSON 368 Web Token (JWT) [RFC7519] in the UA request: The signed JWT contains 369 a number of claims that can be validated to ensure the UA has 370 legitimate access to the content. 372 This document specifies the following attribute for embedding a 373 signed JWT in a Target CDN URI or Redirection URI: 375 o URI Signing Package (URISigningPackage): The URI attribute that 376 encapsulates all the URI Signing claims in a signed JWT encoded 377 format. This attribute is exposed in the Signed URI as a URI 378 query parameter or as a URL path parameter. 380 The parameter name of the URI Signing Package Attribute is defined in 381 the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is 382 not used, or does not include a parameter name for the URI Signing 383 Package Attribute, the parameter name can be set by configuration 384 (out of scope of this document). 386 2.1. JWT Claims 388 This section identifies the set of claims that can be used to enforce 389 the CSP distribution policy. New claims can be introduced in the 390 future to extend the distribution policy capabilities. 392 In order to provide distribution policy flexibility, the exact subset 393 of claims used in a given signed JWT is a runtime decision. Claim 394 requirements are defined in the CDNI Metadata (Section 4.4) If the 395 CDNI Metadata interface is not used, or does not include claim 396 requirements, the claim requirements can be set by configuration (out 397 of scope of this document). 399 The following claims (where the "JSON Web Token Claims" registry 400 claim name is specified in parenthesis below) are used to enforce the 401 distribution policies. All of the listed claims are mandatory to 402 implement in a URI Signing implementation, but are not mandatory to 403 use in a given signed JWT. (The "optional" and "mandatory" 404 identifiers in square brackets refer to whether or not a given claim 405 MUST be present in a URI Signing JWT.) A CDN MUST be able to parse 406 and process all of the claims listed below. If the signed JWT 407 contains any other claims which the CDN does not understand (i.e., is 408 unable to parse and process), the CDN MUST reject the request. 410 Note: See the Security Considerations (Section 7) section on the 411 limitations of using an expiration time and client IP address for 412 distribution policy enforcement. 414 2.1.1. Issuer (iss) claim 416 Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1 417 MUST be followed. This claim MAY be used to validate authorization 418 of the issuer of a signed JWT and also MAY be used to confirm that 419 the indicated key was provided by said issuer. If the CDN validating 420 the signed JWT does not support Issuer validation, or if the Issuer 421 in the signed JWT does not match the list of known acceptable 422 Issuers, the CDN MUST reject the request. If the received signed JWT 423 contains an Issuer claim, then any JWT subsequently generated for 424 CDNI redirection MUST also contain an Issuer claim, and the Issuer 425 value MUST be updated to identify the redirecting CDN. If the 426 received signed JWT does not contain an Issuer claim, an Issuer claim 427 MAY be added to a signed JWT generated for CDNI redirection. 429 2.1.2. URI Container (sub) claim 431 URI Container (sub) [mandatory] - The semantics in [RFC7519] 432 Section 4.1.2 MUST be followed. Container for holding the URI 433 representation before a URI Signing Package is added. This 434 representation can take one of several forms detailed in 435 Section 2.1.11. If the URI pattern/regex in the signed JWT does not 436 match the URI of the content request, the CDN validating the signed 437 JWT MUST reject the request. When comparing the URI the percent 438 encoded form as defined in [RFC3986] Section 2.1 MUST be used. When 439 redirecting a URI, the CDN generating the new signed JWT MAY change 440 the URI Container to comport with the URI being used in the 441 redirection. 443 2.1.3. Client IP (aud) claim 445 Client IP (aud) [optional] - The semantics in [RFC7519] Section 4.1.3 446 MUST be followed. IP address, or IP prefix, for which the Signed URI 447 is valid. This is represented in CIDR notation, with dotted decimal 448 format for IPv4 or canonical text representation for IPv6 addresses 449 [RFC5952]. The request is rejected if sourced from a client outside 450 of the specified IP range. Since the client IP is considered 451 personally identifiable information this field MUST be a JSON Web 452 Encryption (JWE [RFC7516]) Object in compact serialization form. If 453 the CDN validating the signed JWT does not support Client IP 454 validation, or if the Client IP in the signed JWT does not match the 455 source IP address in the content request, the CDN MUST reject the 456 request. If the received signed JWT contains a Client IP claim, then 457 any JWT subsequently generated for CDNI redirection MUST also contain 458 a Client IP claim, and the Client IP value MUST be the same as in the 459 received signed JWT. A signed JWT generated for CDNI redirection 460 MUST NOT add a Client IP claim if no Client IP claim existed in the 461 received signed JWT. 463 2.1.4. Expiry Time (exp) claim 465 Expiry Time (exp) [optional] - The semantics in [RFC7519] 466 Section 4.1.4 MUST be followed, though URI Signing implementations 467 MUST NOT allow for any time synchronization "leeway". Note: The time 468 on the entities that generate and validate the signed URI SHOULD be 469 in sync. In the CDNI case, this means that CSP, uCDN, and dCDN 470 servers need to be time-synchronized. It is RECOMMENDED to use NTP 471 [RFC5905] for time synchronization. If the CDN validating the signed 472 JWT does not support Expiry Time validation, or if the Expiry Time in 473 the signed JWT corresponds to a time earlier than the time of the 474 content request, the CDN MUST reject the request. If the received 475 signed JWT contains a Expiry Time claim, then any JWT subsequently 476 generated for CDNI redirection MUST also contain an Expiry Time 477 claim, and the Expiry Time value MUST be the same as in the received 478 signed JWT. A signed JWT generated for CDNI redirection MUST NOT add 479 an Expiry Time claim if no Expiry Time claim existed in the received 480 signed JWT. 482 2.1.5. Not Before (nbf) claim 484 Not Before (nbf) [optional] - The semantics in [RFC7519] 485 Section 4.1.5 MUST be followed, though URI Signing implementations 486 MUST NOT allow for any time synchronization "leeway". Note: The time 487 on the entities that generate and validate the signed URI SHOULD be 488 in sync. In the CDNI case, this means that the CSP, uCDN, and dCDN 489 servers need to be time-synchronized. It is RECOMMENDED to use NTP 490 [RFC5905] for time synchronization. If the CDN validating the signed 491 JWT does not support Not Before time validation, or if the Not Before 492 time in the signed JWT corresponds to a time later than the time of 493 the content request, the CDN MUST reject the request. If the 494 received signed JWT contains a Not Before time claim, then any JWT 495 subsequently generated for CDNI redirection MUST also contain a Not 496 Before time claim, and the Not Before time value MUST be the same as 497 in the received signed JWT. A signed JWT generated for CDNI 498 redirection MUST NOT add a Not Before time claim if no Not Before 499 time claim existed in the received signed JWT. 501 2.1.6. Issued At (iat) claim 503 Issued At (iat) [optional] - The semantics in [RFC7519] Section 4.1.6 504 MUST be followed. Note: The time on the entities that generate and 505 validate the signed URI SHOULD be in sync. In the CDNI case, this 506 means that CSP, uCDN, and dCDN servers need to be time-synchronized. 507 It is RECOMMENDED to use NTP [RFC5905] for time synchronization. If 508 the received signed JWT contains an Issued At claim, then any JWT 509 subsequently generated for CDNI redirection MUST also contain an 510 Issued At claim, and the Issuer value MUST be updated to identify the 511 time the new JWT was generated. If the received signed JWT does not 512 contain an Issued At claim, an Issued At claim MAY be added to a 513 signed JWT generated for CDNI redirection. 515 2.1.7. Nonce (jti) claim 517 Nonce (jti) [optional] - The semantics in [RFC7519] Section 4.1.7 518 MUST be followed. A Nonce can be used to prevent replay attacks if 519 the CDN stores a list of all previously used Nonce values, and 520 validates that the Nonce in the current JWT has never been used 521 before. If the signed JWT contains a Nonce claim and the CDN 522 validating the signed JWT does not support Nonce storage, then the 523 CDN MUST reject the request. If the received signed JWT contains a 524 Nonce claim, then any JWT subsequently generated for CDNI redirection 525 MUST also contain a Nonce claim, and the Nonce value MUST be the same 526 as in the received signed JWT. If the received signed JWT does not 527 contain a Nonce claim, a Nonce claim MUST NOT be added to a signed 528 JWT generated for CDNI redirection. 530 2.1.8. CDNI Claim Set Version (cdniv) claim 532 CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set 533 Version (cdniv) claim provides a means within a signed JWT to tie the 534 claim set to a specific version of a specificiation. This is 535 intended to allow changes in and facilitate upgrades across 536 specifications. The type is JSON integer and the value MUST be set 537 to "1", for this version of the specification. In the absence of 538 this claim, the value is assumed to be "1". For future versions this 539 claim will be mandatory. Implementations MUST reject signed JWTs 540 with unsupported CDNI Claim Set versions. 542 2.1.9. CDNI Expiration Time Setting (cdniets) claim 544 CDNI Expiration Time Setting (cdniets) [optional] - The CDNI 545 Expiration Time Setting (cdniets) claim provides a means for setting 546 the value of the Expiry Time (exp) claim when generating a subsequent 547 signed JWT in Signed Token Renewal. Its type is a JSON numeric 548 value. It denotes the number of seconds to be added to the time at 549 which the JWT is validated that gives the value of the Expiry Time 550 (exp) claim of the next signed JWT. The CDNI Expiration Time Setting 551 (cdniets) SHOULD NOT be used when not using Signed Token Renewal. 553 2.1.10. CDNI Signed Token Transport (cdnistt) claim 555 CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed 556 Token Transport (cdnistt) claim provides a means of signalling the 557 method through which a new signed JWT is transported from the CDN to 558 the UA and vice versa for the purpose of Signed Token Renewal. Its 559 type is a JSON integer. This document only defines setting its value 560 to '1', which means the signed JWTs are transported via HTTP Cookies 561 in both directions. Additional values for this claim can be defined 562 in Section 6.4. 564 2.1.11. URI Container Forms 566 The URI Container (sub) claim takes one of the following forms. More 567 forms may be added in the future to extend the capabilities. 569 2.1.11.1. URI Simple Container (uri:) 571 When prefixed with 'uri:', the string following 'uri:' is the URI 572 that MUST be matched with a simple string match to the requested URI. 574 2.1.11.2. URI Pattern Container (uri-pattern:) 576 Prefixed with 'uri-pattern:', this string contains one or more URI 577 Patterns that describes for which content the Signed URI is valid. 578 Each URI Pattern contains an expression to match against the 579 requested URI, to check whether the requested content is allowed to 580 be served. Multiple URI Patterns may be concatenated in a single URI 581 Pattern by separating them with a semi-colon (';') character. Each 582 URI Pattern follows the [RFC3986] URI format, including the '://' 583 that delimits the URI scheme from the hierarchy part. The pattern 584 may include the special literals: 586 o ';' - separates individual patterns when the string contains 587 multiple URI patterns. 589 o '*' - matches any sequence of characters, including the empty 590 string. 592 o '?' - matches exactly one character. 594 o '$' - used to escape the special literals; MUST be followed by 595 exactly one of ';', '*', '?', or '$'. 597 The following is an example of a valid URI Pattern: 599 *://*/folder/content-83112371/quality_*/segment????.mp4 600 An example of two concatenated URI Patterns is the following 601 (whitespace is inserted after the ';' for readability and should not 602 be present in the actual representation): 604 http://*/folder/content-83112371/manifest/*.xml; 605 http://*/folder/content-83112371/quality_*/segment????.mp4 607 In order to increase the performance of string parsing the URI 608 Pattern, implementations can check often-used URI Pattern prefixes to 609 quickly check whether certain URI components can be ignored. For 610 example, URI Pattern prefixes '*://*/' or '*://*:*' will be used in 611 case the scheme and authority components of the URI are ignored for 612 purposes of pattern enforcement. 614 2.1.11.3. URI Regular Expression Container (uri-regex:) 616 Prefixed with 'uri-regex:', this string is any PCRE [PCRE839] 617 compatible regular expression used to match against the requested 618 URI. 620 Note: Because '\' has special meaning in JSON [RFC7159] as the escape 621 character within JSON strings, the regular expression character '\' 622 MUST be escaped as '\\'. 624 An example of a 'uri-regex:' is the following: 626 [^:]*\\://[^/]*/folder/content/quality_[^/]*/segment.{3}\\.mp4(\?.*)? 628 Note: Due to computational complexity of executing arbitrary regular 629 expressions, it is RECOMMENDED to only execute after validating the 630 JWT to ensure its authenticity. 632 2.1.11.4. URI Hash Container (uri-hash:) 634 Prefixed with 'uri-hash:', this string is a URL Segment form 635 ([RFC6920] Section 5) of the URI. 637 2.2. JWT Header 639 The header of the JWT MAY be passed via the CDNI Metadata interface 640 instead of being included in the URISigningPackage. The header value 641 must be transmitted in the serialized encoded form and prepended to 642 the JWT payload and signature passed in the URISigningPackage prior 643 to validation. This reduces the size of the signed JWT token. 645 3. URI Signing Token Renewal 647 3.1. Overview 649 For content that is delivered via HTTP in a segmented fashion, such 650 as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216], 651 special provisions need to be made in order to ensure URI Signing can 652 be applied. In general, segmented protocols work by breaking large 653 objects (e.g. videos) into a sequence of small independent segments. 654 Such segments are then referenced by a separate manifest file, which 655 either includes a list of URLs to the segments or specifies an 656 algorithm through which a User Agent can construct the URLs to the 657 segments. Requests for segments therefore originate from the 658 manifest file and, unless the URLs in the manifest file point to the 659 CSP, are not subjected to redirection and URI Signing. This opens up 660 the vulnerability of malicious User Agents sharing the manifest file 661 and deep-linking to the segments. 663 One method for dealing with this vulnerability would be to include, 664 in the manifest itself, Signed URIs that point to the individual 665 segments. There exist a number of issues with that approach. First, 666 it requires the CDN delivering the manifest to rewrite the manifest 667 file for each User Agent, which would require the CDN to be aware of 668 the exact segmentation protocol used. Secondly, it could also 669 require the expiration time of the Signed URIs to be valid for an 670 extended duration if the content described by the manifest is meant 671 to be consumed in real time. For instance, if the manifest file were 672 to contain a segmented video stream of more than 30 minutes in 673 length, Signed URIs would require to be valid for a at least 30 674 minutes, thereby reducing their effectiveness and that of the URI 675 Signing mechanism in general. For a more detailed analysis of how 676 segmented protocols such as HTTP Adaptive Streaming protocols affect 677 CDNI, see Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. 679 The method described in this section allows CDNs to use URI Signing 680 for segmented content without having to include the Signed URIs in 681 the manifest files themselves. 683 3.2. Signed Token Renewal mechanism 685 In order to allow for effective access control of segmented content, 686 the URI signing scheme defined in this section is based on a 687 mechanism through which subsequent segment requests can be linked 688 together. As part of the JWT validation procedure, the CDN can 689 generate a new signed JWT that the UA can use to do a subsequent 690 request. More specifically, whenever a UA successfully retrieves a 691 segment, it receives, in the HTTP 2xx Successful message, a signed 692 JWT that it can use whenever it requests the next segment. As long 693 as each successive signed JWT is correctly validated before a new one 694 is generated, the model is not broken and the User Agent can 695 successfully retrieve additional segments. Given the fact that with 696 segmented protocols, it is usually not possible to determine a priori 697 which segment will be requested next (i.e., to allow for seeking 698 within the content and for switching to a different representation), 699 the Signed Token Renewal uses the URI Pattern Container and/or the 700 URI Regular Expression Container scoping mechanisms in the URI 701 Container (sub) claim to allow a signed JWT to be valid for more than 702 one URL. 704 In order for this renewal of signed JWTs to work, it is necessary for 705 a UA to extract the signed JWT from the HTTP 2xx Successful message 706 of an earlier request and use it to retrieve the next segment. The 707 exact mechanism by which the client does this depends on the exact 708 segmented protocol and since this document is only concerned with the 709 generation and validation of incoming request, this process is 710 outside the scope of this document. However, in order to also 711 support legacy UAs that do not include any specific provisions for 712 the handling of signed JWTs, the folowing section defines a mechanism 713 using HTTP Cookies that allows such UAs to support the concept of 714 renewing signed JWTs without requiring any support on the UA side. 716 3.3. Communicating a signed JWTs in Signed Token Renewal 718 This section assumes the value of the CDNI Signed Token Transport 719 (cdnistt) claim has been set to 1. Other values of cdnistt are out 720 of scope of this document. 722 When using the Signed Token Renewal mechanism, the signed JWT is 723 transported to the UA via a 'URISigningPackage' cookie added to the 724 HTTP 2xx Successful message along with the content being returned to 725 the UA, or to the HTTP 3xx Redirection message in case the UA is 726 redirected to a different server. 728 3.3.1. Support for cross-domain redirection 730 For security purposes, the use of cross-domain cookies is not 731 supported in some application environments. As a result, the Cookie- 732 based method for transport of the Signed Token described in the 733 previous section might break if used in combination with a HTTP 3xx 734 Redirection response where the target URL is in a different domain. 735 In such scenarios, Signed Token Renewal of a signed JWT SHOULD be 736 communicated via the query string instead, in a similar fashion to 737 how regular signed JWTs (outside of Signed Token Renewal) are 738 communicated. Note that the use of URL embedded signed JWTs SHOULD 739 NOT be used in HTTP 2xx Successful messages, since UAs might not know 740 how to extract the signed JWTs. 742 Note that the process described below only works in cases where both 743 the manifest file and segments constituting the segmented content are 744 delivered from the same domain. In other words, any redirection 745 between different domains needs to be carried out while retrieving 746 the manifest file. 748 4. Relationship with CDNI Interfaces 750 Some of the CDNI Interfaces need enhancements to support URI Signing. 751 As an example: A dCDN that supports URI Signing needs to be able to 752 advertise this capability to the uCDN. The uCDN needs to select a 753 dCDN based on such capability when the CSP requires access control to 754 enforce its distribution policy via URI Signing. Also, the uCDN 755 needs to be able to distribute via the CDNI Metadata interface the 756 information necessary to allow the dCDN to validate a Signed URI. 757 Events that pertain to URI Signing (e.g., request denial or delivery 758 after access authorization) need to be included in the logs 759 communicated through the CDNI Logging interface (Editor's Note: Is 760 this within the scope of the CDNI Logging interface?). 762 4.1. CDNI Control Interface 764 URI Signing has no impact on this interface. 766 4.2. CDNI Footprint & Capabilities Advertisement Interface 768 The CDNI Request Routing: Footprint and Capabilities Semantics 769 document [RFC8008] defines support for advertising CDNI Metadata 770 capabilities, via CDNI Payload Type. The CDNI Payload Type 771 registered in Section 6.1 can be used for capability advertisement. 773 4.3. CDNI Request Routing Redirection Interface 775 The CDNI Request Routing Redirection Interface [RFC7975] describes 776 the recursive request redirection method. For URI Signing, the uCDN 777 signs the URI provided by the dCDN. URI Signing therefore has has no 778 impact on this interface. 780 4.4. CDNI Metadata Interface 782 The CDNI Metadata Interface [RFC8006] describes the CDNI metadata 783 distribution needed to enable content acquisition and delivery. For 784 URI Signing, a new CDNI metadata object is specified. 786 The UriSigning Metadata object contains information to enable URI 787 signing and validation by a dCDN. The UriSigning properties are 788 defined below. 790 Property: enforce 792 Description: URI Signing enforcement flag. Specifically, this 793 flag indicates if the access to content is subject to URI 794 Signing. URI Signing requires the dCDN to ensure that the URI 795 must be signed and validated before delivering content. 796 Otherwise, the dCDN does not perform validation, regardless of 797 whether or not the URI is signed. 799 Type: Boolean 801 Mandatory-to-Specify: No. The default is true. 803 Property: issuers 805 Description: A list of valid Issuers against which the Issuer 806 claim in the signed JWT may be validated. 808 Type: Array of Strings 810 Mandatory-to-Specify: No. The default is an empty list. An 811 empty list means that any Issuer is acceptable. 813 Property: package-attribute 815 Description: The name to use for the URI Signing Package. 817 Type: String 819 Mandatory-to-Specify: No. Default is "URISigningPackage". 821 Property: jwt-header 823 Description: The header part of JWT that is used for generating 824 or validating a signed JWT when the JWT token in the URI 825 Signing Package does not contain a header part. 827 Type: String 829 Mandatory-to-Specify: No. A jwt-header is not essential for 830 all implementations of URI signing. 832 The following is an example of a URI Signing metadata payload with 833 all default values: 835 { 836 "generic-metadata-type": "MI.UriSigning" 837 "generic-metadata-value": {} 838 } 840 The following is an example of a URI Signing metadata payload with 841 explicit values: 843 { 844 "generic-metadata-type": "MI.UriSigning" 845 "generic-metadata-value": 846 { 847 "enforce": true, 848 "issuers": ["csp", "ucdn1", "ucdn2"], 849 "package-attribute": "usp" 850 } 851 } 853 4.5. CDNI Logging Interface 855 For URI Signing, the dCDN reports that enforcement of the access 856 control was applied to the request for content delivery. When the 857 request is denied due to enforcement of URI Signing, the reason is 858 logged. 860 The following CDNI Logging field for URI Signing SHOULD be supported 861 in the HTTP Request Logging Record as specified in CDNI Logging 862 Interface [RFC7937], using the new "cdni_http_request_v2" record-type 863 registered in Section 6.2.1. 865 o s-uri-signing (mandatory): 867 * format: 3DIGIT 869 * field value: this characterises the URI signing validation 870 performed by the Surrogate on the request. The allowed values 871 are: 873 + "000" : no signed JWT validation performed 875 + "200" : signed JWT validation performed and validated 877 + "400" : signed JWT validation performed and rejected because 878 of incorrect signature 880 + "401" : signed JWT validation performed and rejected because 881 of Expiration Time enforcement 883 + "402" : signed JWT validation performed and rejected because 884 of Client IP enforcement 886 + "403" : signed JWT validation performed and rejected because 887 of URI Pattern enforcement 889 + "404" : signed JWT validation performed and rejected because 890 of Issuer enforcement 892 + "405" : signed JWT validation performed and rejected because 893 of Not Before enforcement 895 + "500" : unable to perform signed JWT validation because of 896 malformed URI 898 * occurrence: there MUST be zero or exactly one instance of this 899 field. 901 o s-uri-signing-deny-reason (optional): 903 * format: QSTRING 905 * field value: a string for providing further information in case 906 the signed JWT was rejected, e.g., for debugging purposes. 908 * occurrence: there MUST be zero or exactly one instance of this 909 field. 911 5. URI Signing Message Flow 913 URI Signing supports both HTTP-based and DNS-based request routing. 914 JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of 915 representing claims to be transferred between two parties. The 916 claims in a signed JWT are encoded as a JSON object that is used as 917 the payload of a JSON Web Signature (JWS) structure or as the 918 plaintext of a JSON Web Encryption (JWE) structure, enabling the 919 claims to be digitally signed or integrity protected with a Message 920 Authentication Code (MAC) and/or encrypted. 922 5.1. HTTP Redirection 924 For HTTP-based request routing, a set of information that is unique 925 to a given end user content request is included in a signed JWT, 926 using key information that is specific to a pair of adjacent CDNI 927 hops (e.g., between the CSP and the uCDN or between the uCDN and a 928 dCDN). This allows a CDNI hop to ascertain the authenticity of a 929 given request received from a previous CDNI hop. 931 The URI signing method described below is based on the following 932 steps (assuming HTTP redirection, iterative request routing, and a 933 CDN path with two CDNs). Note that uCDN and uCDN are used 934 exchangeably. 936 End-User dCDN uCDN CSP 937 | | | | 938 | 1.CDNI FCI interface used to | | 939 | advertise URI Signing capability| | 940 | |------------------->| | 941 | | | | 942 | 2.Provides information to validate signed JWT | 943 | | |<-------------------| 944 | | | | 945 | 3.CDNI Metadata interface used to| | 946 | provide URI Signing attributes| | 947 | |<-------------------| | 948 |4.Authorization request | | 949 |------------------------------------------------------------->| 950 | | | [Apply distribution 951 | | | policy] | 952 | | | | 953 | | (ALT: Authorization decision) 954 |5.Request is denied | | | 955 |<-------------------------------------------------------------| 956 | | | | 957 |6.CSP provides signed URI | | 958 |<-------------------------------------------------------------| 959 | | | | 960 |7.Content request | | | 961 |---------------------------------------->| [Validate URI | 962 | | | signature] | 963 | | | | 964 | | (ALT: Validation result) | 965 |8.Request is denied | | | 966 |<----------------------------------------| | 967 | | | | 968 |9.Re-sign URI and redirect to | | 969 | dCDN (newly signed URI) | | 970 |<----------------------------------------| | 971 | | | | 972 |10.Content request | | | 973 |------------------->| [Validate URI | | 974 | | signature] | | 975 | | | | 976 | (ALT: Validation result) | | 977 |11.Request is denied| | | 978 |<-------------------| | | 979 | | | | 980 |12.Content delivery | | | 981 |<-------------------| | | 982 : : : : 983 : (Later in time) : : : 984 |13.CDNI Logging interface to include URI Signing information | 985 | |------------------->| | 987 Figure 3: HTTP-based Request Routing with URI Signing 989 1. Using the CDNI Footprint & Capabilities Advertisement interface, 990 the dCDN advertises its capabilities including URI Signing 991 support to the uCDN. 993 2. CSP provides to the uCDN the information needed to validate 994 signed JWTs from that CSP. For example, this information may 995 include a key value. 997 3. Using the CDNI Metadata interface, the uCDN communicates to a 998 dCDN the information needed to validate signed JWTs from the 999 uCDN for the given CSP. For example, this information may 1000 include the URI query string parameter name for the URI Signing 1001 Package Attribute. 1003 4. When a UA requests a piece of protected content from the CSP, 1004 the CSP makes a specific authorization decision for this unique 1005 request based on its personal distribution policy. 1007 5. If the authorization decision is negative, the CSP rejects the 1008 request and sends an error code (e.g., 403 Forbidden) in the 1009 HTTP response. 1011 6. If the authorization decision is positive, the CSP computes a 1012 Signed URI that is based on unique parameters of that request 1013 and conveys it to the end user as the URI to use to request the 1014 content. 1016 7. On receipt of the corresponding content request, the uCDN 1017 validates the signed JWT in the URI using the information 1018 provided by the CSP. 1020 8. If the validation is negative, the uCDN rejects the request and 1021 sends an error code (e.g., 403 Forbidden) in the HTTP response. 1023 9. If the validation is positive, the uCDN computes a Signed URI 1024 that is based on unique parameters of that request and provides 1025 it to the end user as the URI to use to further request the 1026 content from the dCDN. 1028 10. On receipt of the corresponding content request, the dCDN 1029 validates the signed JWT in the Signed URI using the information 1030 provided by the uCDN in the CDNI Metadata. 1032 11. If the validation is negative, the dCDN rejects the request and 1033 sends an error code (e.g., 403 Forbidden) in the HTTP response. 1035 12. If the validation is positive, the dCDN serves the request and 1036 delivers the content. 1038 13. At a later time, the dCDN reports logging events that include 1039 URI signing information. 1041 With HTTP-based request routing, URI Signing matches well the general 1042 chain of trust model of CDNI both with symmetric and asymmetric keys 1043 because the key information only needs to be specific to a pair of 1044 adjacent CDNI hops. 1046 5.2. DNS Redirection 1048 For DNS-based request routing, the CSP and uCDN must agree on a trust 1049 model appropriate to the security requirements of the CSP's 1050 particular content. Use of asymmetric public/private keys allows for 1051 unlimited distribution of the public key to dCDNs. However, if a 1052 shared secret key is preferred, then the CSP may want to restrict the 1053 distribution of the key to a (possibly empty) subset of trusted 1054 dCDNs. Authorized Delivery CDNs need to obtain the key information 1055 to validate the Signed URI. 1057 The URI signing method described below is based on the following 1058 steps (assuming iterative DNS request routing and a CDN path with two 1059 CDNs). 1061 End-User dCDN uCDN CSP 1062 | | | | 1063 | 1.CDNI FCI interface used to | | 1064 | advertise URI Signing capability| | 1065 | |------------------->| | 1066 | | | | 1067 | 2.Provides information to validate signed JWT | 1068 | | |<-------------------| 1069 | 3.CDNI Metadata interface used to| | 1070 | provide URI Signing attributes| | 1071 | |<-------------------| | 1072 |4.Authorization request | | 1073 |------------------------------------------------------------->| 1074 | | | [Apply distribution 1075 | | | policy] | 1076 | | | | 1077 | | (ALT: Authorization decision) 1078 |5.Request is denied | | | 1079 |<-------------------------------------------------------------| 1080 | | | | 1081 |6.Provides signed URI | | 1082 |<-------------------------------------------------------------| 1083 | | | | 1084 |7.DNS request | | | 1085 |---------------------------------------->| | 1086 | | | | 1087 |8.Redirect DNS to dCDN | | 1088 |<----------------------------------------| | 1089 | | | | 1090 |9.DNS request | | | 1091 |------------------->| | | 1092 | | | | 1093 |10.IP address of Surrogate | | 1094 |<-------------------| | | 1095 | | | | 1096 |11.Content request | | | 1097 |------------------->| [Validate URI | | 1098 | | signature] | | 1099 | | | | 1100 | (ALT: Validation result) | | 1101 |12.Request is denied| | | 1102 |<-------------------| | | 1103 | | | | 1104 |13.Content delivery | | | 1105 |<-------------------| | | 1106 : : : : 1107 : (Later in time) : : : 1108 |14.CDNI Logging interface to report URI Signing information | 1109 | |------------------->| | 1111 Figure 4: DNS-based Request Routing with URI Signing 1113 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1114 the dCDN advertises its capabilities including URI Signing 1115 support to the uCDN. 1117 2. CSP provides to the uCDN the information needed to validate 1118 cryptographic signatures from that CSP. For example, this 1119 information may include a key. 1121 3. Using the CDNI Metadata interface, the uCDN communicates to a 1122 dCDN the information needed to validate cryptographic signatures 1123 from the CSP (e.g., the URI query string parameter name for the 1124 URI Signing Package Attribute). In the case of symmetric key, 1125 the uCDN checks if the dCDN is allowed by CSP to obtain the 1126 shared secret key. 1128 4. When a UA requests a piece of protected content from the CSP, 1129 the CSP makes a specific authorization decision for this unique 1130 request based on its arbitrary distribution policy. 1132 5. If the authorization decision is negative, the CSP rejects the 1133 request. 1135 6. If the authorization decision is positive, the CSP computes a 1136 cryptographic signature that is based on unique parameters of 1137 that request and includes it in the URI provided to the end user 1138 to request the content. 1140 7. End user sends DNS request to the uCDN. 1142 8. On receipt of the DNS request, the uCDN redirects the request to 1143 the dCDN. 1145 9. End user sends DNS request to the dCDN. 1147 10. On receipt of the DNS request, the dCDN responds with IP address 1148 of one of its Surrogates. 1150 11. On receipt of the corresponding content request, the dCDN 1151 validates the cryptographic signature in the URI using the 1152 information provided by the uCDN in the CDNI Metadata. 1154 12. If the validation is negative, the dCDN rejects the request and 1155 sends an error code (e.g., 403) in the HTTP response. 1157 13. If the validation is positive, the dCDN serves the request and 1158 delivers the content. 1160 14. At a later time, dCDN reports logging events that includes URI 1161 signing information. 1163 With DNS-based request routing, URI Signing matches well the general 1164 chain of trust model of CDNI when used with asymmetric keys because 1165 the only key information that needs to be distributed across 1166 multiple, possibly untrusted, CDNI hops is the public key, which is 1167 generally not confidential. 1169 With DNS-based request routing, URI Signing does not match well the 1170 general chain of trust model of CDNI when used with symmetric keys 1171 because the symmetric key information needs to be distributed across 1172 multiple CDNI hops, to CDNs with which the CSP may not have a trust 1173 relationship. This raises a security concern for applicability of 1174 URI Signing with symmetric keys in case of DNS-based inter-CDN 1175 request routing. 1177 6. IANA Considerations 1179 6.1. CDNI Payload Type 1181 This document requests the registration of the following CDNI Payload 1182 Type under the IANA "CDNI Payload Type" registry: 1184 +---------------+---------------+ 1185 | Payload Type | Specification | 1186 +---------------+---------------+ 1187 | MI.UriSigning | RFCthis | 1188 +---------------+---------------+ 1190 [RFC Editor: Please replace RFCthis with the published RFC number for 1191 this document.] 1193 6.1.1. CDNI UriSigning Payload Type 1195 Purpose: The purpose of this payload type is to distinguish 1196 UriSigning MI objects (and any associated capability advertisement). 1198 Interface: MI/FCI 1200 Encoding: see Section 4.4 1202 6.2. CDNI Logging Record Type 1204 This document requests the registration of the following CDNI Logging 1205 record-type under the IANA "CDNI Logging record-types" registry: 1207 +----------------------+-----------+--------------------------------+ 1208 | record-types | Reference | Description | 1209 +----------------------+-----------+--------------------------------+ 1210 | cdni_http_request_v2 | RFCthis | Extension to CDNI Logging | 1211 | | | Record version 1 for content | 1212 | | | delivery using HTTP, to | 1213 | | | include URI Signing logging | 1214 | | | fields | 1215 +----------------------+-----------+--------------------------------+ 1217 [RFC Editor: Please replace RFCthis with the published RFC number for 1218 this document.] 1220 6.2.1. CDNI Logging Record Version 2 for HTTP 1222 The "cdni_http_request_v2" record-type supports all of the fields 1223 supported by the "cdni_http_request_v1" record-type [RFC7937] plus 1224 the two additional fields "s-uri-signing" and "s-uri-signing-deny- 1225 reason", registered by this document in Section 6.3. The name, 1226 format, field value, and occurence information for the two new fields 1227 can be found in Section 4.5 of this document. 1229 6.3. CDNI Logging Field Names 1231 This document requests the registration of the following CDNI Logging 1232 fields under the IANA "CDNI Logging Field Names" registry: 1234 +---------------------------+-----------+ 1235 | Field Name | Reference | 1236 +---------------------------+-----------+ 1237 | s-uri-signing | RFCthis | 1238 | s-uri-signing-deny-reason | RFCthis | 1239 +---------------------------+-----------+ 1241 [RFC Editor: Please replace RFCthis with the published RFC number for 1242 this document.] 1244 6.4. CDNI URI Signing Signed Token Transport 1246 The IANA is requested to create a new "CDNI URI Signing Signed Token 1247 Transport" subregistry in the "Content Delivery Networks 1248 Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing 1249 Signed Token Transport" namespace defines the valid values that may 1250 be in the Signed Token Transport (cdnistt) JWT claim. Additions to 1251 the Signed Token Transport namespace conform to the "Specification 1252 Required" policy as defined in [RFC5226]. 1254 The following table defines the initial Enforcement Information 1255 Elements: 1257 +-------+---------------------------------------+---------+ 1258 | Value | Description | RFC | 1259 +-------+---------------------------------------+---------+ 1260 | 1 | Designates token transport via cookie | RFCthis | 1261 +-------+---------------------------------------+---------+ 1263 [RFC Editor: Please replace RFCthis with the published RFC number for 1264 this document.] 1266 [Ed Note: are there any special instructions to the designated expert 1267 reviewer?] 1269 6.5. JSON Web Token Claims Registration 1271 This specification registers the following Claims in the IANA "JSON 1272 Web Token Claims" registry [IANA.JWT.Claims] established by 1273 [RFC7519]. 1275 6.5.1. Registry Contents 1277 o Claim Name: "cdniv" 1278 o Claim Description: CDNI Claim Set Version 1279 o Change Controller: IESG 1280 o Specification Document(s): Section 2.1.8 of [[ this specification 1281 ]] 1283 o Claim Name: "cdniets" 1284 o Claim Description: CDNI Expiration Time Setting for Signed Token 1285 Renewal 1286 o Change Controller: IESG 1287 o Specification Document(s): Section 2.1.9 of [[ this specification 1288 ]] 1290 o Claim Name: "cdnistt" 1291 o Claim Description: CDNI Signed Token Transport Method for Signed 1292 Token Renewal 1293 o Change Controller: IESG 1294 o Specification Document(s): Section 2.1.10 of [[ this specification 1295 ]] 1297 7. Security Considerations 1299 This document describes the concept of URI Signing and how it can be 1300 used to provide access authorization in the case of CDNI. The 1301 primary goal of URI Signing is to make sure that only authorized UAs 1302 are able to access the content, with a CSP being able to authorize 1303 every individual request. It should be noted that URI Signing is not 1304 a content protection scheme; if a CSP wants to protect the content 1305 itself, other mechanisms, such as DRM, are more appropriate. 1307 In general, it holds that the level of protection against 1308 illegitimate access can be increased by including more claims in the 1309 signed JWT. The current version of this document includes claims for 1310 enforcing Issuer, Client IP Address, Not Before time, and Expiration 1311 Time, however this list can be extended with other, more complex, 1312 attributes that are able to provide some form of protection against 1313 some of the vulnerabilities highlighted below. 1315 That said, there are a number of aspects that limit the level of 1316 security offered by URI Signing and that anybody implementing URI 1317 Signing should be aware of. 1319 o Replay attacks: A (valid) Signed URI may be used to perform replay 1320 attacks. The vulnerability to replay attacks can be reduced by 1321 picking a relatively short window between the Not Before time and 1322 Expiration Time attributes, although this is limited by the fact 1323 that any HTTP-based request needs a window of at least a couple of 1324 seconds to prevent a sudden network issues from preventing 1325 legitimate UAs access to the content. One may also reduce 1326 exposure to replay attacks by including a unique one-time access 1327 ID via the Nonce attribute (jti claim). Whenever the dCDN 1328 receives a request with a given unique ID, it adds that ID to the 1329 list of 'used' IDs. In the case an illegitimate UA tries to use 1330 the same URI through a replay attack, the dCDN can deny the 1331 request based on the already-used access ID. 1333 o Illegitimate clients behind a NAT: In cases where there are 1334 multiple users behind the same NAT, all users will have the same 1335 IP address from the point of view of the dCDN. This results in 1336 the dCDN not being able to distinguish between the different users 1337 based on Client IP Address and illegitimate users being able to 1338 access the content. One way to reduce exposure to this kind of 1339 attack is to not only check for Client IP but also for other 1340 attributes, e.g., attributes that can be found in HTTP headers. 1342 The shared key between CSP and uCDN may be distributed to dCDNs - 1343 including cascaded CDNs. Since this key can be used to legitimately 1344 sign a URL for content access authorization, it is important to know 1345 the implications of a compromised shared key. 1347 8. Privacy 1349 The privacy protection concerns described in CDNI Logging Interface 1350 [RFC7937] apply when the client's IP address (aud) is embedded in the 1351 Signed URI. For this reason, the mechanism described in Section 2 1352 encrypts the Client IP before including it in the URI Signing Package 1353 (and thus the URL itself). 1355 9. Acknowledgements 1357 The authors would like to thank the following people for their 1358 contributions in reviewing this document and providing feedback: 1359 Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan 1360 York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana 1361 Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris 1362 Lemmons. 1364 10. Contributors 1366 In addition, the authors would also like to make special mentions for 1367 certain people who contributed significant sections to this document. 1369 o Matt Caulfield provided content for the CDNI Metadata Interface 1370 section. 1372 o Emmanuel Thomas provided content for HTTP Adaptive Streaming. 1374 o Matt Miller provided consultation on JWT usage as well as code to 1375 generate working JWT examples. 1377 11. References 1379 11.1. Normative References 1381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1382 Requirement Levels", BCP 14, RFC 2119, 1383 DOI 10.17487/RFC2119, March 1997, 1384 . 1386 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1387 IANA Considerations Section in RFCs", RFC 5226, 1388 DOI 10.17487/RFC5226, May 2008, 1389 . 1391 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1392 Keranen, A., and P. Hallam-Baker, "Naming Things with 1393 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1394 . 1396 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1397 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1398 2014, . 1400 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1401 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1402 . 1404 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1405 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1406 . 1408 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 1409 and R. Peterkofsky, "Content Distribution Network 1410 Interconnection (CDNI) Logging Interface", RFC 7937, 1411 DOI 10.17487/RFC7937, August 2016, 1412 . 1414 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1415 "Content Delivery Network Interconnection (CDNI) 1416 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1417 . 1419 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1420 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1421 May 2017, . 1423 11.2. Informative References 1425 [IANA.JWT.Claims] 1426 IANA, "JSON Web Token Claims", 1427 . 1429 [MPEG-DASH] 1430 ISO, "Information technology -- Dynamic adaptive streaming 1431 over HTTP (DASH) -- Part 1: Media presentation description 1432 and segment format", ISO/IEC 23009-1:2014, Edition 2, 05 1433 2014, . 1435 [PCRE839] Hazel, P., "Perl Compatible Regular Expressions", 1436 Version 8.39, June 2016, . 1438 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1439 Resource Identifier (URI): Generic Syntax", STD 66, 1440 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1441 . 1443 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1444 "Network Time Protocol Version 4: Protocol and Algorithms 1445 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1446 . 1448 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1449 Address Text Representation", RFC 5952, 1450 DOI 10.17487/RFC5952, August 2010, 1451 . 1453 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1454 Distribution Network Interconnection (CDNI) Problem 1455 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1456 2012, . 1458 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 1459 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 1460 Content Distribution Network Interconnection (CDNI)", 1461 RFC 6983, DOI 10.17487/RFC6983, July 2013, 1462 . 1464 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1465 "Framework for Content Distribution Network 1466 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1467 August 2014, . 1469 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1470 Network Interconnection (CDNI) Requirements", RFC 7337, 1471 DOI 10.17487/RFC7337, August 2014, 1472 . 1474 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 1475 DOI 10.17487/RFC7517, May 2015, 1476 . 1478 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 1479 "Request Routing Redirection Interface for Content 1480 Delivery Network (CDN) Interconnection", RFC 7975, 1481 DOI 10.17487/RFC7975, October 2016, 1482 . 1484 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1485 R., and K. Ma, "Content Delivery Network Interconnection 1486 (CDNI) Request Routing: Footprint and Capabilities 1487 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1488 . 1490 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 1491 RFC 8216, DOI 10.17487/RFC8216, August 2017, 1492 . 1494 Appendix A. Signed URI Package Example 1496 This section contains three examples of token usage: a simple example 1497 with only the required claim present, a complex example which 1498 demonstrates the full JWT claims set, including an encrypted Client 1499 IP (aud), and one that uses a Signed Token Renewal. 1501 Note: All of the examples have whitespace added to improve formatting 1502 and readability, but are not present in the generated content. 1504 All examples use the following JWK Set [RFC7517]: 1506 { "keys": [ 1507 { 1508 "kty": "EC", 1509 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1510 "use": "sig", 1511 "alg": "ES256", 1512 "crv": "P-256", 1513 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1514 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA" 1515 }, 1516 { 1517 "kty": "EC", 1518 "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0", 1519 "use": "sig", 1520 "alg": "ES256", 1521 "crv": "P-256", 1522 "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8", 1523 "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA", 1524 "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M" 1525 }, 1526 { 1527 "kty": "oct", 1528 "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998", 1529 "use": "enc", 1530 "alg": "A128GCM", 1531 "k": "4uFxxV7fhNmrtiah2d1fFg" 1532 } 1533 ]} 1535 Note: They are the public signing key, the private signing key, and 1536 the shared secret enctyption key, respectively. The public and 1537 private signing keys have the same fingerprint and only vary by the 1538 'd' parameter that is missing from the public signing key. 1540 A.1. Simple Example 1542 This example is the simplest possible example containing the only 1543 required field (sub). 1545 The JWT Claim Set before signing: 1547 { 1548 "sub": "uri:http://cdni.example/foo/bar/baz" 1549 } 1551 The signed JWT: 1553 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1554 dZRkRPV2tsZHVlYUltZjAifQ.eyJzdWIiOiJ1cmk6aHR0cDovL2NkbmkuZXhhbXBsZ 1555 S9mb28vYmFyL2JheiJ9.LTizGd7zCb17Qp_80ClGApLCieRIq3dCjcRckNfLqiJ4BT 1556 GSfVXoDtm0Z6L5Jx4EmwM1w-WkznNajUy11iMAcA 1558 A.2. Complex Example 1560 This example uses all optional fields except for those dealing with 1561 Signed Token Renewal, including Client IP (aud) which is encrpyted. 1562 This significantly increases the size of the signed JWT token. 1564 JWE for client IP (aud) of [2001:db8::1/32]: 1566 eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj 1567 g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..oGLsnF8fLlFcUXK0.KFfBB 1568 H_FPYFu-RBFBR3rhQ.6_MVaa4t7JiVX2IgUkZ3jA 1570 The JWT Claim Set before signing: 1572 { 1573 "aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm 1574 dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..oGLsnF8fLlFc 1575 UXK0.KFfBBH_FPYFu-RBFBR3rhQ.6_MVaa4t7JiVX2IgUkZ3jA", 1576 "cdniv": 1, 1577 "exp": 1474243500, 1578 "iat": 1474243200, 1579 "iss": "uCDN Inc", 1580 "jti": "5DAafLhZAfhsbe", 1581 "nbf": 1474243200, 1582 "sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.png" 1583 } 1584 The signed JWT: 1586 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1587 dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJleUpoYkdjaU9pSmthWElpTENKcmFXU 1588 WlPaUptTFZkaWFuaENRek5rVUhWSk0yUXlOR3RRTW1obWRtOXpOMUY2TmpnNFZWUnB 1589 ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLm9HTHNuRjhmTGxGY 1590 1VYSzAuS0ZmQkJIX0ZQWUZ1LVJCRkJSM3JoUS42X01WYWE0dDdKaVZYMklnVWtaM2p 1591 BIiwiY2RuaXYiOjEsImV4cCI6MTQ3NDI0MzUwMCwiaWF0IjoxNDc0MjQzMjAwLCJpc 1592 3MiOiJ1Q0ROIEluYyIsImp0aSI6IjVEQWFmTGhaQWZoc2JlIiwibmJmIjoxNDc0MjQ 1593 zMjAwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGxlL2Zvby9iY 1594 XIvYmF6L1swLTldezN9XFwucG5nIn0.r2FiSdfnGRw_RC2roGwh4LEYlfsWGF972-M 1595 f3He_LhGr2_3eRXP0jP_OFPj5NEtTZFY4PX_iD7vPD12_HPDJCQ 1597 A.3. Signed Token Renewal Example 1599 This example uses fields for Signed Token Renewal. 1601 The JWT Claim Set before signing: 1603 { 1604 "cdniets": 30, 1605 "cdnistt": 1, 1606 "exp": 1474243500, 1607 "sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.ts" 1608 } 1610 The signed JWT: 1612 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1613 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI 1614 joxNDc0MjQzNTAwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGx 1615 lL2Zvby9iYXIvYmF6L1swLTldezN9XFwudHMifQ.VYF7Eqk1WhRWdvDVUx5mXDJaS- 1616 r6jbjgiYuwIEAYmbLWsF2dUDohrV70sz7TC09n-oNf_ws4eeH_A6AnvF4FTQ 1618 Once the server validates the signed JWT it will return a new signed 1619 JWT with an updated expiry time (exp) as shown below. Note the 1620 expiry time is increased by the expiration time setting (cdniets) 1621 value. 1623 The JWT Claim Set before signing: 1625 { 1626 "cdniets": 30, 1627 "cdnistt": 1, 1628 "exp": 1474243530, 1629 "sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.ts" 1630 } 1631 The signed JWT: 1633 eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU 1634 dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiZXhwI 1635 joxNDc0MjQzNTMwLCJzdWIiOiJ1cmktcmVnZXg6aHR0cDovL2NkbmlcXC5leGFtcGx 1636 lL2Zvby9iYXIvYmF6L1swLTldezN9XFwudHMifQ.zzXhYg6b7_8MylW-RS97qZv3hQ 1637 QlYg-TxhC-wigdB4moxlFEjndDvv0EDxl42faQaE39BCHZq7H-DXVpBrhxTw 1639 Authors' Addresses 1641 Ray van Brandenburg 1642 Tiledmedia 1643 Anna van Buerenplein 1 1644 Den Haag 2595DA 1645 The Netherlands 1647 Phone: +31 88 866 7000 1648 Email: ray@tiledmedia.com 1650 Kent Leung 1651 Cisco Systems, Inc. 1652 3625 Cisco Way 1653 San Jose, CA 95134 1654 United States 1656 Phone: +1 408 526 5030 1657 Email: kleung@cisco.com 1659 Phil Sorber 1660 Comcast Cable Communications 1661 1401 Wynkoop Street, Suite 300 1662 Denver, CO 80202 1663 United States 1665 Phone: +1 720 502 3785 1666 Email: phillip_sorber@comcast.com