idnits 2.17.1 draft-leung-cdni-uri-signing-05.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 329: '... SHOULD maintain the same level of s...' RFC 2119 keyword, line 383: '... MUST be appended after the URI Sign...' RFC 2119 keyword, line 580: '... attribute MUST be the last paramete...' RFC 2119 keyword, line 583: '...query parameters SHOULD NOT use the sa...' RFC 2119 keyword, line 641: '...a URI, the value MUST remain the same ...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 283 has weird spacing: '...I(after v ...' -- The document date (March 4, 2014) is 3677 days in the past. Is this intentional? 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 124, but not defined == Unused Reference: 'RFC6770' is defined on line 1568, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-10 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6707 == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-10 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-06 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI K. Leung 3 Internet-Draft F. Le Faucheur 4 Intended status: Standards Track Cisco Systems 5 Expires: September 5, 2014 B. Downey 6 Verizon Labs 7 R. van Brandenburg 8 TNO 9 S. Leibrand 10 Limelight Networks 11 March 4, 2014 13 URI Signing for CDN Interconnection (CDNI) 14 draft-leung-cdni-uri-signing-05 16 Abstract 18 This document describes how the concept of URI signing supports the 19 content access control requirements of CDNI and proposes a URI 20 signing scheme. 22 The proposed URI signing method specifies the information needed to 23 be included in the URI and the algorithm used to authorize and to 24 validate access requests for the content referenced by the URI. Some 25 of the information may be accessed by the CDN via configuration or 26 CDNI metadata. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 5, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Background on URI Signing . . . . . . . . . . . . . . . . 4 65 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 66 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 67 2. Signed URI Information Elements . . . . . . . . . . . . . . . 8 68 2.1. Enforcement Information Elements . . . . . . . . . . . . . 10 69 2.2. Signature Computation Information Elements . . . . . . . . 11 70 2.3. URI Signature Information Elements . . . . . . . . . . . . 12 71 2.4. URI Signing Package Attribute . . . . . . . . . . . . . . 13 72 3. Creating the Signed URI . . . . . . . . . . . . . . . . . . . 14 73 3.1. Calculating the URI Signature . . . . . . . . . . . . . . 14 74 3.2. Packaging the URI Signature . . . . . . . . . . . . . . . 17 75 4. Validating a URI Signature . . . . . . . . . . . . . . . . . . 18 76 4.1. Information element validation . . . . . . . . . . . . . . 18 77 4.2. Signature validation . . . . . . . . . . . . . . . . . . . 19 78 5. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 21 79 5.1. CDNI Control Interface . . . . . . . . . . . . . . . . . . 22 80 5.2. CDNI Footprint & Capabilities Advertisement Interface . . 22 81 5.3. CDNI Request Routing Redirection Interface . . . . . . . . 22 82 5.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 23 83 5.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 24 84 6. URI Signing Message Flow . . . . . . . . . . . . . . . . . . . 24 85 6.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . . 25 86 6.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 27 87 7. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 30 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 90 10. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 93 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 94 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 97 1. Introduction 99 This document describes the concept of URI Signing and how it can be 100 used to provide access authorization in the case of interconnected 101 CDNs (CDNI). The primary goal of URI Signing is to make sure that 102 only authorized User Agents (UAs) are able to access the content, 103 with a Content Service Provider (CSP) being able to authorize every 104 individual request. It should be noted that URI Signing is not a 105 content protection scheme; if a CSP wants to protect the content 106 itself, other mechanisms, such as DRM, are more appropriate. 108 The overall problem space for CDN Interconnection (CDNI) is described 109 in CDNI Problem Statement [RFC6707]. In this document, along with 110 the CDNI Requirements [I-D.ietf-cdni-requirements] document and the 111 CDNI Framework [I-D.ietf-cdni-framework] the need for interconnected 112 CDNs to be able to implement an access control mechanism that 113 enforces the CSP's distribution policy is described. 115 Specifically, CDNI Framework [I-D.ietf-cdni-framework] states: 117 "The CSP may also trust the CDN operator to perform actions such as 118 ..., and to enforce per-request authorization performed by the CSP 119 using techniques such as URI signing." 121 In particular, the following requirement is listed in CDNI 122 Requirements [I-D.ietf-cdni-requirements]: 124 "MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow 125 signaling of authorization checks and validation that are to be 126 performed by the surrogate before delivery. For example, this could 127 potentially include: 129 * need to validate URI signed information (e.g. Expiry time, Client 130 IP address)." 132 This document proposes a URI Signing scheme that allows Surrogates in 133 interconnected CDNs to enforce a per-request authorization performed 134 by the CSP. Splitting the role of performing per-request 135 authorization by CSP and the role of validation of this authorization 136 by the CDN allows any arbitrary distribution policy to be enforced 137 across CDNs without the need of CDNs to have any awareness of the 138 actual CSP distribution policy. 140 1.1. Terminology 142 This document uses the terminology defined in CDNI Problem Statement 143 [RFC6707]. 145 This document also uses the terminology of Keyed-Hashing for Message 146 Authentication (HMAC) [RFC2104] including the following terms 147 (reproduced here for convenience): 149 o MAC: message authentication code. 151 o HMAC: Hash-based message authentication code (HMAC) is a specific 152 construction for calculating a MAC involving a cryptographic hash 153 function in combination with a secret key. 155 o HMAC-SHA1: HMAC instantiation using SHA-1 as the cryptographic 156 hash function. 158 o HMAC-MD5: HMAC instantiation using MD5 as the cryptographic hash 159 function. 161 In addition, the following terms are used throughout this document: 163 o URI Signature: Message digest or digital signature that is 164 computed with an algorithm for protecting the URI. 166 o Original URI: The URI before URI Signing is applied. 168 o Signed URI: Any URI that contains a URI Signature. 170 o Target CDN URI: Embedded URI created by the CSP to direct UA 171 towards the Upstream CDN. The Target CDN URI can be signed by the 172 CSP and verified by the Upstream CDN. 174 o Redirection URI: URI created by the Upstream CDN to redirect UA 175 towards the Downstream CDN. The Redirection URI can be signed by 176 the Upstream CDN and verified by the Downstream CDN. In a 177 cascaded CDNI scenario, there can be more than one Redirection 178 URI. 180 1.2. Background on URI Signing 182 The next section provides an overview of how URI Signing works in a 183 CDNI environment. As background information, URI Signing is first 184 explained in terms of a single CDN delivering content on behalf of a 185 CSP. 187 A CSP and CDN are assumed to have a trust relationship that enables 188 the CSP to authorize access to a content item by including a set of 189 attributes in the URI before redirecting a UA to the CDN. Using 190 these attributes, it is possible for a CDN to check an incoming 191 content request to see whether it was authorized by the CSP (e.g. 192 based on the UA's IP address or a time window). Of course, the 193 attributes need to be added to the URI in a way that prevents a UA 194 from changing the attributes, thereby leaving the CDN to think that 195 the request was authorized by the CSP when in fact it wasn't. For 196 this reason, a URI Signing mechanism includes in the URI a message 197 digest or digital signature that allows a CDN to check the 198 authenticity of the URI. The message digest or digital signature can 199 be calculated based on a shared secret between the CSP and CDN or 200 using CSP's asymmetric public/private key pair, respectively. 202 Figure 1, shown below, presents an overview of the URI Signing 203 mechanism in the case of a CSP with a single CDN. When the UA 204 browses for content on CSP's website (#1), it receives HTML web pages 205 with embedded content URIs. Upon requesting these URIs, the CSP 206 redirects to a CDN, creating a Target CDN URI (#2) (alternatively, 207 the Target CDN URI itself is embedded in the HTML). The Target CDN 208 URI is the Signed URI which may include the IP address of the UA 209 and/or a time window and always contains the URI Signature which is 210 generated by the CSP using the shared secret or a private key. Once 211 the UA receives the response with the embedded URI, it sends a new 212 HTTP request using the embedded URI to the CDN (#3). Upon receiving 213 the request, the CDN checks to see if the Signed URI is authentic by 214 verifying the URI signature. In addition, it checks whether the IP 215 address of the HTTP request matches that in the Signed URI and if the 216 time window is still valid. After these values are confirmed to be 217 valid, the CDN delivers the content (#4). 219 -------- 220 / \ 221 | CSP |< * * * * * * * * * * * 222 \ / Trust * 223 -------- relationship * 224 ^ | * 225 | | * 226 1. Browse | | 2. Signed * 227 for | | URI * 228 content | | * 229 | v v 230 +------+ 3. Signed URI -------- 231 | User |----------------->/ \ 232 | Agent| | CDN | 233 | |<-----------------\ / 234 +------+ 4. Content -------- 235 Delivery 237 Figure 1: Figure 1: URI Signing in a CDN Environment 239 1.3. CDNI URI Signing Overview 241 In a CDNI environment, URI Signing operates the same way in the 242 initial steps #1 and #2 but the later steps involve multiple CDNs in 243 the process of delivering the content. The main difference from the 244 single CDN case is a redirection step between the Upstream CDN and 245 the Downstream CDN. In step #3, UA may send HTTP request or DNS 246 request. Depending on whether HTTP-based or DNS-based request 247 routing is used, the Upstream CDN responds by directing the UA 248 towards the Downstream CDN using either a Redirection URI (which is a 249 Signed URI generated by the Upstream CDN) or a DNS reply, 250 respectively (#4). Once the UA receives the response, it sends the 251 Redirection URI/Target CDN URI to the Downstream CDN (#5). The 252 received URI is validated by the Downstream CDN before delivering the 253 content (#6). This is depicted in the figure below. Note: The CDNI 254 call flows are covered in Detailed URI Signing Operation (Section 6). 256 +-------------------------+ 257 |Request Redirection Modes| 258 +-------------------------+ 259 | a) HTTP | 260 | b) DNS | 261 +-------------------------+ 262 -------- 263 / \< * * * * * * * * * * * * * * 264 | CSP |< * * * * * * * * * * * * 265 \ / Trust * * 266 -------- relationship * * 267 ^ | * * 268 | | 2. Signed * * 269 1. Browse | | URI in * * 270 for | | HTML * * 271 content | | * * 272 | v 3.a)Signed URI v * 273 +------+ b)DNS request -------- * Trust 274 | User |----------------->/ \ * relationship 275 | Agent| | uCDN | * (optional) 276 | |<-----------------\ / * 277 +------+ 4.a)Redirection URI------- * 278 ^ | b)DNS Reply ^ * 279 | | * * 280 | | Trust relationship * * 281 | | * * 282 6. Content | | 5.a)Redirection URI * * 283 delivery | | b)Signed URI(after v v 284 | | DNS exchange) -------- 285 | +---------------------->/ \ [May be 286 | | dCDN | cascaded 287 +--------------------------\ / CDNs] 288 -------- 290 +-----------------------------------------+ 291 | Key | Asymmetric | Symmetric | 292 +-----------------------------------------+ 293 |HTTP |Public key (uCDN)|Shared key (uCDN)| 294 |DNS |Public key (CSP) |Shared key (CSP) | 295 +-----------------------------------------+ 297 Figure 2: URI Signing in a CDNI Environment 299 The trust relationships between CSP, Upstream CDN, and Downstream CDN 300 have direct implications for URI Signing. In the case shown in 301 Figure 2, the CDN that the CSP has a trust relationship with is the 302 Upstream CDN. The delivery of the content may be delegated to the 303 Downstream CDN, which has a relationship with the Upstream CDN but 304 may have no relationship with the CSP. 306 In CDNI, there are two methods for request routing: DNS-based and 307 HTTP-based. For DNS-based request routing, the Signed URI (i.e. 308 Target CDN URI) provided by the CSP reaches the Downstream CDN 309 directly. In the case where the Downstream CDN does not have a trust 310 relationship with the CSP, this means that only an asymmetric public/ 311 private key method can be used for computing the URI Signature 312 because the CSP and Downstream CDN are not able to exchange symmetric 313 shared secret keys. Since the CSP is unlikely to have relationships 314 with all the Downstream CDNs that are delegated to by the Upstream 315 CDN, the CSP may choose to allow the Authoritative CDN to 316 redistribute the shared key to a subset of their Downstream CDNs . 318 For HTTP-based request routing, the Signed URI (i.e. Target CDN URI) 319 provided by the CSP reaches the Upstream CDN. After this URI has 320 been verified to be correct by the Upstream CDN, the Upstream CDN 321 creates and signs a new Redirection URI to redirect the UA to the 322 Downstream CDN. Since this new URI also has a new URI Signature, 323 this new signature can be based around the trust relationship between 324 the Upstream CDN and Downstream CDN, and the relationship between the 325 Downstream CDN and CSP is not relevant. Given the fact that such a 326 relationship between Upstream CDN and Downstream CDN always exists, 327 both asymmetric public/private keys and symmetric shared secret keys 328 can be used for URI Signing. Note that the signed Redirection URI 329 SHOULD maintain the same level of security as the original Signed 330 URI. 332 1.4. URI Signing in a non-CDNI context 334 While the URI signing scheme defined in this document was primarily 335 created for the purpose of allowing URI Signing in CDNI scenarios, 336 e.g. between a uCDN and a dCDN or between a CSP and a dCDN, there is 337 nothing in the defined URI Signing scheme that precludes it from 338 being used in a non-CDNI context. As such, the described mechanism 339 could be used in a single-CDN scenario such as shown in Figure 1 in 340 Section 1.2, for example to allow a CSP that uses different CDNs to 341 only have to implement a single URI Signing mechanism. 343 2. Signed URI Information Elements 345 The concept behind URI Signing is based on embedding in the Target 346 CDN URI/Redirection URI a number of information elements that can be 347 validated to ensure the UA has legitimate access to the content. 348 These information elements are appended, in an encapsulated form, to 349 the original URI. 351 For the purposes of the URI signing mechanism described in this 352 document, three types of information elements may be embedded in the 353 URI: 355 o Enforcement Information Elements: Information Elements that are 356 used to enforce a distribution policy defined by the CSP. 357 Examples of enforcement attributes are IP address of the UA and 358 time window. 360 o Signature Computation Information Elements: Information Elements 361 that are used by the CDN to verify the URI signature embedded in 362 the received URI. In order to verify a URI Signature, the CDN 363 requires some information elements that describe how the URI 364 Signature was generated. Examples of Signature Computation 365 Elements include the used HMACs hash function and/or the key 366 identifier. 368 o URI Signature Information Elements: The information elements that 369 carry the actual message digest or digital signature representing 370 the URI signature used for checking the integrity and authenticity 371 of the URI. A typical Signed URI will only contain one embedded 372 URI Signature Information Element. 374 In addition, the this document specifies the following URI attribute: 376 o URI Signing Package Attribute: The URI attribute that encapsulates 377 all the URI Signing information elements in an encoded format. 378 Only this attribute is exposed in the Signed URI as a URI query 379 parameter. 381 If the UA or another entity needs to add one or more attributes to 382 the Signed URI for purposes other than URI Signing, those attributes 383 MUST be appended after the URI Signing Packacke Attribute. Any 384 attributes appended in such way after the URI Signature has been 385 calculated are not validated for the purpose of content access 386 authorization. Note that adding any such attributes to the Signed 387 URI before the URI Signing Packacke Attribute will cause the URI 388 Signing validation to fail. 390 Two types of keys can be used for URI Signing: asymmetric keys and 391 symmetric keys. Asymmetric keys are based on a public/private key 392 pair mechanism and always contain a private key only known to the 393 entity signing the URI (either CSP or uCDN) and a public key for the 394 verification of the Signed URI. With symmetric keys, the same key is 395 used by both the signing entity for signing the URI as well as by the 396 validating entity for validating the Signed URI. Regardless of the 397 type of keys used, the validating entity has to obtain the key 398 (either the public or the symmetric key). There are very different 399 requirements for key distribution (out of scope of this document) 400 with asymmetric keys and with symmetric keys. Key distribution for 401 symmetric keys requires confidentiality to prevent another party from 402 getting access to the key, since it could then generate valid Signed 403 URIs for unauthorized requests. Key distribution for asymmetric keys 404 does not require confidentiality since public keys can typically be 405 distributed openly (because they cannot be used for URI signing) and 406 private keys are kept by the URI signing function. 408 2.1. Enforcement Information Elements 410 This section identifies the set of information elements that may be 411 needed to enforce the CSP distribution policy. New information 412 elements may be introduced in the future to extend the capabilities 413 of the distribution policy. 415 In order to provide flexibility in distribution policies to be 416 enforced, the exact subset of information elements used in the URI 417 Signature of a given request is a deployment decision. The defined 418 keyword for each information element is specified in parenthesis 419 below. 421 The following information elements are used to enforce the 422 distribution policy: 424 o Expiry Time (ET) [optional] - Time when the Signed URI expires. 425 This is represented as an integer denoting the number of seconds 426 since midnight 1/1/1970 UTC (i.e. UNIX epoch). The request is 427 rejected if the received time is later than this timestamp. Note: 428 The time, including time zone, on the entities that generate and 429 validate the signed URI need to be in sync (e.g. NTP is used). 431 o Client IP (CIP) [optional] - IP address of the client for which 432 this Signed URI is generated. This is represented in dotted 433 decimal format for IPv4 or canonical text representation for IPv6 434 address [RFC5952] . The request is rejected if sourced from a 435 client with a different IP address. 437 The Expiry Time Information Element ensures that the content 438 authorization expires after a predetermined time. This limits the 439 time window for content access and prevents replay of the request 440 beyond the authorized time window. 442 The Client IP Information Element is used to restrict content access 443 to a particular User Agent, based on its IP address for whom the 444 content access was authorized. 446 Note: See the Security Considerations (Section 9) section on the 447 limitations of using an expiration time and client IP address for 448 distribution policy enforcement. 450 2.2. Signature Computation Information Elements 452 This section identifies the set of information elements that may be 453 needed to verify the URI (signature). New information elements may 454 be introduced in the future if new URI signing algorithms are 455 developed. 457 The defined keyword for each information element is specified in 458 parenthesis below. 460 The following information elements are used to validate the URI by 461 recreating the URI Signature. 463 o Version (VER) [optional] - An integer used for identifying the 464 version of URI signing method. If this Information Element is not 465 present in the URI Signing Package Attribute, the default version 466 is 1. 468 o Key ID (KID) [optiona] - A string used for obtaining the key (e.g. 469 database lookup, URI reference) which is needed to validate the 470 URI signature. 472 o Hash Function (HF) [optional] - A string used for identifying the 473 hash function to compute the URI signature (e.g. "MD5", "SHA-1", 474 "SHA-256", "SHA-3") with HMAC. If this Information Element is not 475 present in the URI Signing Package Attribute, the default hash 476 function is SHA-1. 478 o Digital Signature Algorithm (DSA) [optional] - Algorithm used to 479 calculate the Digital Signature (e.g. "RSA", "DSA", "EC-DSA"). 480 If this Information Element is not present in the URI Signing 481 Package Attribute, the default is EC-DSA. 483 The Version Information Element indicates which version of URI 484 signing scheme is used (including which attributes and algorithms are 485 supported). The present document specifies Version 1. If the 486 Version attribute is not present in the Signed URI, then the version 487 is obtained from the CDNI metadata, else it is considered to have 488 been set to the default value. More versions may be defined in the 489 future. 491 The Key ID Information Element is used to retrieved the key which is 492 needed as input to the algorithm for validating the Signed URI. The 493 method used for obtaining the actual key from the reference included 494 in the Key ID Information Element is outside the scope of this 495 document. 497 The Hash Function Information Element indicates the hash function to 498 be used for HMAC-based message digest computation. The Hash Function 499 Information Element is used in combination with the Message Digest 500 Information Element defined in section Section 2.3. 502 The Digital Signature Algorithm Information Element indicates the 503 digital signature function to be in the case asymmetric keys are 504 used. The Digital Signature Algorithm Information Element is used in 505 combination with the Digital Signature Information Element defined in 506 section Section 2.3. 508 2.3. URI Signature Information Elements 510 This section identifies the set of information elements that carry 511 the URI Signature that is used for checking the integrity and 512 authenticity of the URI. 514 The defined keyword for each information element is specified in 515 parenthesis below. 517 The following information elements are used to carry the actual URI 518 Signature. 520 o Message Digest (MD) [mandatory for symmetric key] - A string used 521 for the message digest generated by the URI signing entity. 523 o Digital Signature (DS) [mandatory for asymmetric keys] - A string 524 used for the digital signature provided by the URI signing entity. 526 The Message Digest attribute contains the message digest used to 527 validate the Signed URI when symmetric keys are used. 529 The Digital Signature attribute contains the digital signature used 530 to verify the Signed URI when asymmetric keys are used. 532 In the case of symmetric key, HMAC algorithm is used for the 533 following reasons: 1) Ability to use hash functions (i.e. no changes 534 needed) with well understood cryptographic properties that perform 535 well and for which code is freely and widely available, 2) Easy to 536 replace the embedded hash function in case faster or more secure hash 537 functions are found or required, 3) Original performance of the hash 538 function is maintained without incurring a significant degradation, 539 and 4) Simple way to use and handle keys. 541 In the case of asymmetric keys, Elliptic Curve Digital Signature 542 Algorithm (EC DSA) - a variant of DSA - is used because of the 543 following reasons: 1) Key size is small while still offering good 544 security, 2) Key is easy to store, and 3) Computation is faster than 545 DSA or RSA. 547 2.4. URI Signing Package Attribute 549 The URI Signing Package Attribute is an encapsulation container for 550 the URI Signing Information Elements defined in the previous 551 sections. The URI Signing Information Elements are encoded and 552 stored in this attribute. URI Signing Package Attribute is appended 553 to the Original URI to create the Signed URI. 555 The primary advantage of the URI Signing Package Attribute is that it 556 avoids having to expose the URI Signing Information Elements directly 557 in the query string of the URI, thereby reducing the potential for a 558 namespace collision space within the URI query string. A side 559 benefit of the attribute is the obfuscation performed by the URI 560 Signing Package Attribute hides the information (e.g. client IP 561 address) from view of the common user, who is not aware of the 562 encoding scheme. Obviously, this is not a security method since 563 anyone who knows the encoding scheme is able to obtain the clear 564 text. Note that any parameters appended to the query string after 565 the URI Signing Package Attribute are not validated and hence do not 566 affect URI Signing. 568 The following attribute is used to carry the encoded set of URI 569 Signing attributes in the Signed URI. 571 o URI Signing Package (URISigningPackage) - The encoded attribute 572 containing all the CDNI URI Signing Information Elements used for 573 URI Signing. 575 The URI Signing Package Attribute contains the URI Signing 576 Information Elements in the Base-64 encoding with URL and Filename 577 Safe Alphabet (a.k.a. "base64url") as specified in the Base-64 Data 578 Encoding [RFC4648] document. The URI Signing Package Attribute is 579 the only URI Signing attribute exposed in the Signed URI. The 580 attribute MUST be the last parameter in the query string of the URI 581 when the Signed URI is generated. However, a client or CDN may 582 append other query parameters unrelated to URI Signing to the Signed 583 URI. Such additional query parameters SHOULD NOT use the same name 584 as the URI Signing Package Attribute to avoid namespace collision and 585 potential failure of the URI Signing validation. 587 The parameter name of the URI Signing Package Attribute shall be 588 defined in the CDNI Metadata interface. If the CDNI Metadata 589 interface does not include a parameter name for the URI Signing 590 Package Attribute, the parameter name is set by configuration ((out 591 of scope of this document). 593 3. Creating the Signed URI 595 The following procedure for signing a URI defines the algorithms in 596 this version of URI Signing. Note that some steps may be skipped if 597 the CSP does not enforce a distribution policy and the Enforcement 598 Information Elements are therefore not necessary. A URI (as defined 599 in URI Generic Syntax [RFC3986]) contains the following parts: scheme 600 name, authority, path, query, and fragment. The entire URI except 601 the "scheme name" part is protected by the URI signature. This 602 allows the URI signature to be validated correctly in the case when a 603 client performs a fallback to another scheme (e.g. HTTP) for a 604 content item referenced by a URI with a specific scheme (e.g. RTSP). 605 The benefit is that the content access is protected regardless of the 606 type of transport used for delivery. If the CSP wants to ensure a 607 specific protocol is used for content delivery, that information is 608 passed by CDNI metadata. Note: Support for changing of the URL 609 scheme requires that the default port is used, or that the protocols 610 must both run on the same non-standard port. 612 The process of generating a Signed URI can be divided into two sets 613 of steps: calculating the URI Signature and packaging the URI 614 Signature and appending it to the Original URI. Note it is possible 615 to use some other algorithm and implementation as long as the same 616 result is achieved. An example for the Original URI, 617 "http://example.com/content.mov", is used to clarify the steps. 619 3.1. Calculating the URI Signature 621 Calculate the URI Signature by following the procedure below. 623 1. Copy the Original URI, excluding the "scheme name" part, into a 624 buffer to hold the message for performing the operations below. 626 2. Check if the URI already contains a query string. If not, append 627 a "?" character. If yes, append an "&" character. 629 3. If the version is the default value, skip this step. Append the 630 string "VER=". Append the string for the version number. 632 4. If time window enforcement is not needed, step 4 can be skipped. 634 A. If an attribute was added to the URI, append an "&" 635 character. Append the string "ET=". Note in the case of re- 636 signing a URI, the attribute is carried over from the 637 received Signed URI. 639 B. Get the current time in seconds since epoch (as an integer). 640 Add the validity time in seconds as an integer. Note in the 641 case of re-signing a URI, the value MUST remain the same as 642 the received Signed URI. 644 C. Convert this integer to a string and append to the message. 646 5. If client IP enforcement is not needed, step 5 can be skipped. 648 A. If an attribute was added to the URI, append an "&" 649 character. Append the string "CIP=". Note in the case of 650 re-signing a URI, the attribute is carried over from the 651 received Signed URI. 653 B. Convert the client's IP address in dotted decimal notation 654 format (i.e. for IPv4 address) or canonical text 655 representation (for IPv6 address [RFC5952]) to a string and 656 append to the message. Note in the case of re-signing an 657 URI, the value MUST remain the same as the received Signed 658 URI. 660 6. Depending on the type of key used to sign the URI, compute the 661 message digest or digital signature for symmetric key or 662 asymmetric keys, respectively. 664 A. For symmetric key, HMAC is used. 666 1. Obtain the shared key to be used for signing the URI. 668 2. If the key identifier is provided by the CDNI metadata, 669 skip this step. If an attribute was added to the URI, 670 append an "&" character. Append the string "KID=". 671 Append the key identifier (e.g. "example:keys:123") 672 needed by the entity to locate the shared key for 673 validating the URI signature. 675 3. If the hash function for the HMAC uses the default value 676 (SHA-1), skip this step. If an attribute was added to 677 the URI, append an "&" character. Append the string 678 "HF=". Append the string for the type of hash function. 679 Note that re-signing a URI MUST use the same hash 680 function as the received Signed URI or one of the 681 allowable hash functions designated by the CDNI metadata. 683 4. If an attribute was added to the URI, append an "&" 684 character. Append the string "MD=". The message now 685 contains the complete section of the URI that is 686 protected (e.g. "://example.com/ 687 content.mov?ET=1209422976&CIP=10.0.0.1& 688 KID=example:keys:123&MD="). 690 5. Compute the message digest using the HMAC algorithm with 691 the shared key (e.g. "secretkey" and message as the two 692 inputs to the hash function which is specified by the 693 "HF" attribute. 695 6. Convert the message digest to its equivalent hexadecimal 696 format. 698 7. Append the string for the message digest (e.g. ":// 699 example.com/ 700 content.mov?ET=1209422976&CIP=10.0.0.1& 701 KID=example:keys:123& 702 MD=da58513e8b309c1e8a9695baceba629d180b50b8"). 704 B. For asymmetric keys, EC DSA is used. 706 1. Generate the EC private and public key pair (e.g. private 707 key is "8b5b417336492707a83836b02ceee55b3847be5ec1521e494 708 9977b224950e708", public key is "04840b1be11cfd1404c2fc58 709 8d30150a4103cadcc4172e786bcaf15d7feeb6d246f7d8a91fa055cb1 710 0efb2f52860d1d1b2f339244e9ad79a23e10ed9b720f6157f"). 711 Store the EC public key in a location that's reachable 712 for any entity that needs to validate the URI signature. 714 2. If the key identifier is provided by the CDNI metadata, 715 skip this step. If an attribute was added to the URI, 716 append an "&" character. Append the string "KID=". 717 Append the key identifier (e.g. 718 "http://example.com/public/keys/123") needed by the 719 entity to locate the shared key for validating the URI 720 signature. Note the Key ID URI contains only the "scheme 721 name", "authority", and "path" parts (i.e. query string 722 is not allowed). 724 3. If the digital signature algorithm uses the default value 725 (EC-DSA), skip this step. If an attribute was added to 726 the URI, append an "&" character. Append the string 727 "DSA=". Append the string denoting the digital signature 728 function used. 730 4. If an attribute was added to the URI, append an "&" 731 character. Append the string "DS=". The message now 732 contains the complete section of the URI that is 733 protected. (e.g. "://example.com/ 734 content.mov?ET=1209422976&CIP=10.0.0.1&KID=http:// 735 example.com/public/keys/123&DS="). 737 5. Compute the message digest using SHA-1 (without a key) 738 for the message (e.g. message digest is 739 "b95cb62f1d30ad03969619e9574a925fbfe9aeaf"). Note: The 740 reason the digital signature calculated in the next step 741 is calculated over the SHA-1 message digest, instead of 742 over the cleartype message, is to reduce the length of 743 the digital signature, and thereby the length of the URI 744 Signing Package Attribute and the resulting Signed URI. 746 6. Compute the digital signature, using the EC-DSA algorithm 747 by default or another algorithm if specified by the DSA 748 Information Element, with the private EC key and message 749 digest obtained in previous step as inputs. 751 7. Convert the digital signature to its equivalent 752 hexadecimal format. 754 8. Append the string for the digital signature. In the case 755 where EC-DSA algorithm is used, this string contains the 756 values for the 'r' and 's' parameters, delimited by ':' 757 (e.g. "://example.com/ 758 content.mov?ET=1209422976&CIP=10.0.0.1&KID=http:// 759 example.com/public/keys/ 760 123& 761 DS=r: 762 CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E 763 005668D:s: 764 57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A 765 29EA24E" ) 767 3.2. Packaging the URI Signature 769 Apply the URI Signing Package Attribute by following the procedure 770 below to generate the Signed URI. 772 1. Remove the Original URI portion from the message to obtain all 773 the URI Signing Information Elements, including the URI signature 774 (e.g. "ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&& 775 MD=da58513e8b309c1e8a9695baceba629d180b50b8"). 777 2. Compute the URI Signing Package Attribute using Base-64 Data 778 Encoding [RFC4648] on the message (e.g. "RVQ9MTIwOTQyMjk3NiZDSVA 779 9MTAuMC4wLjEmS0lEPWV4YW1wbGU6a2V5czoxMjMmJk1EPWRhNTg1MTNlOGIzMDlj 780 MWU4YTk2OTViYWNlYmE2MjlkMTgwYjUwYjg="). Note: This is the value 781 for the URI Signing Package Attribute. 783 3. Copy the entire Original URI into a buffer to hold the message. 785 4. Check if the Original URI already contains a query string. If 786 not, append a "?" character. If yes, append an "&" character. 788 5. Append the parameter name used to indicate the URI Signing 789 Package Attribute, as communicated via the CDNI Metadata 790 interface, followed by an "=". If none is communicated by the 791 CDNI Metadata interface, it defaults to "URISigningPackage". For 792 example, if the CDNI Metadata interface specifies "SIG", append 793 the string "SIG=" to the message. 795 6. Append the URI Signing token to the message (e.g. "http:// 796 example.com/ 797 content.mov?URISigningPackage=RVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjE 798 mS0lEPWV4YW1wbGU6a2V5czoxMjMmJk1EPWRhNTg1MTNlOGIzMDljMWU4YTk2OTVi 799 YWNlYmE2MjlkMTgwYjUwYjg="). Note: this is the completed Signed 800 URI. 802 4. Validating a URI Signature 804 The process of validating a Signed URI can be divided into two sets 805 of steps: validation of the information elements embedded in the 806 Signed URI and validation of the URI Signature. Note it is possible 807 to use some other algorithm and implementation as long as the same 808 result is achieved. 810 4.1. Information element validation 812 Extract and validate the information elements embedded in the URI. 813 Note that some steps are to be skipped if the corresponding URI 814 Signing Information Element is not embedded in the Signed URI. The 815 absence of a given Enforcement Information Element indicates 816 enforcement of its purpose is not necessary in the CSP's distribution 817 policy. 819 1. Extract the value from 'URISigningPackage' attribute. This value 820 is the encoded URI Signing Package Attribute. If there are 821 multiple instances of this attribute, the first one is used and 822 the remaining ones are ignored. This ensures that the Signed URI 823 can be validated despite a client appending another instance of 824 the 'URISigningPackage' attribute. 826 2. Decode the string using Base-64 Data Encoding [RFC4648] (or 827 another encoding method specified by configuration or CDNI 828 metadata) to obtain all the URI Signing Information Elements 829 (e.g. "ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&& 830 MD=da58513e8b309c1e8a9695baceba629d180b50b8"). 832 3. Extract the value from "VER" if the information element exists in 833 the query string. Determine the version of the URI Signing 834 algorithm used to process the Signed URI. If the CDNI Metadata 835 interface is used, check to see if the used version of the URI 836 Signing algorithm is among the allowed set of URI Signing 837 versions specified by the metadata. If this is not the case, the 838 request is denied. If the attribute is not in the URI, then 839 obtain the version number in another manner (e.g. configuration, 840 CDNI metadata or default value). 842 4. Extract the value from "CIP" if the information element exists in 843 the query string. Validate that the request came from the same 844 IP address as indicated in the "CIP" attribute. If the IP 845 address is incorrect, then the request is denied. 847 5. Extract the value from "ET" if the information element exists in 848 the query string. Validate that the request arrived before 849 expiration time based on the "ET" attribute. If the time 850 expired, then the request is denied. 852 6. Extract the value from "MD" if the information element exists in 853 the query string. The existence of this information element 854 indicates a symmetric key is used. 856 7. Extract the value from "DS" if the information element exists in 857 the query string. The existence of this information element 858 indicates a asymmetric key is used. 860 8. If neither "MD" or "DS" attribute is in the URI, then no URI 861 Signature exists and the request is denied. If both the "MD" and 862 the "DS" information elements are present, the Signed URI is 863 considered to be malformed and the request is denied. 865 4.2. Signature validation 867 Validate the URI Signature for the Signed URI. 869 1. Copy the Original URI, excluding the "scheme name" part, into a 870 buffer to hold the message for performing the operations below. 872 2. Remove the "URISigningPackage" attribute from the message. 873 Remove any subsequent part of the query string after the 874 "URISigningPackage" attribute. 876 3. Append the decoded value from "URISigningPackage" attribute 877 (which contains all the URI Signing Information Elements). 879 4. Depending on the type of key used to sign the URI, validate the 880 message digest or digital signature for symmetric key or 881 asymmetric keys, respectively. 883 A. For symmetric key, HMAC algorithm is used. 885 a. Extract the value from the "KID" information element, if 886 it exists. Use the key identifier (e.g. "example:keys: 887 123") to locate the shared key, which may be one of the 888 keys available to use (i.e. set by configuration or CDNI 889 metadata). If the information element is not in the URI 890 Signing Package Attribute, then obtain the key in another 891 manner (e.g. configuration or CDNI metadata). If the 892 "KID" information element is present but its value is not 893 in the allowable KID set as listed in the CDNI metadata, 894 the request is denied. 896 b. Extract the value from the "HF" information element, if 897 it exists. Determine the type of hash function (e.g. 898 "MD5", "SHA-1", "SHA-256", "SHA-3") to use for HMAC. If 899 the information element is not in the URI, the default 900 hash function is SHA-1. If the "HF" information element 901 is present but its value is not in the the allowable "HF" 902 set as listed in the CDNI metadata, the request is 903 denied. 905 c. Extract the value from the "MD" information element. 906 This is the received message digest. 908 d. Convert the message digest to binary format. This will 909 be used to compare with the computed value later. 911 e. Remove the value part of the "MD" information element 912 (but not the '=' character) from the message. The 913 message is ready for validation of the message digest 914 (e.g. "://example.com/ 915 content.mov?ET=1209422976&CIP=10.0.0.1& 916 KID=example:keys:123&MD="). 918 f. Compute the message digest using the HMAC algorithm with 919 the shared key and message as the two inputs to the hash 920 function which is specified by the "HF" attribute. 922 g. Compare the result with the received message digest to 923 validate the Signed URI. 925 B. For asymmetric keys, a digital signature function is used. 927 a. Extract the value from the "KID" information element, if 928 it exists. Use the key identifier (e.g. 929 "http://example.com/public/keys/123") to obtain the EC 930 public key, which may be one of the keys available to use 931 (i.e. set by configuration or CDNI metadata). If the 932 information element is not in the URI, then obtain the 933 key in another manner (e.g. configuration or CDNI 934 metadata). 936 b. Extract the value from the "DSA" information element, if 937 it exists. Determine the type of digital signature 938 function (e.g. "RSA", "DSA", "EC-DSA") to use for 939 calculating the Digital Signature. If the information 940 element is not in the URI, the default digital signature 941 function is EC-DSA. If the "DSA" information element is 942 present but its value is not in the the allowable "EC- 943 DSA" set as listed in the CDNI metadata, the request is 944 denied. 946 c. Extract the value from the "DS" information element. 947 This is the digital signature. 949 d. Convert the digital signature to binary format. This 950 will be used for verification later. 952 e. Remove the value part of the "DS" information element 953 (but not the '=' character) from the message. The 954 message is ready for validation of the digital signature 955 (e.g. "://example.com/ 956 content.mov?ET=1209422976&CIP=10.0.0.1&KID=http:// 957 example.com/public/keys/123&DS="). 959 f. Compute the message digest using SHA-1 (without a key) 960 for the message. 962 g. Verify the digital signature using the digital signature 963 function (e.g. EC-DSA) with the public key, received 964 digital signature, and message digest (obtained in 965 previous step) as inputs. This validates the Signed URI. 967 5. Relationship with CDNI Interfaces 969 Some of the CDNI Interfaces need enhancements to support URI Signing. 970 As an example: A Downstream CDN that supports URI Signing needs to be 971 able to advertise this capability to the Upstream CDN. The Upstream 972 CDN needs to select a Downstream CDN based on such capability when 973 the CSP requires access control to enforce its distribution policy 974 via URI Signing. Also, the Upstream CDN needs to be able to 975 distribute via the CDNI Metadata interface the information necessary 976 to allow the Downstream CDN to validate a Signed URI . Events that 977 pertain to URI Signing (e.g. request denial or delivery after access 978 authorization) need to be included in the logs communicated through 979 the CDNI Logging interface (Editor's Note: Is this within the scope 980 of the CDNI Logging interface?). 982 5.1. CDNI Control Interface 984 URI Signing has no impact on this interface. 986 5.2. CDNI Footprint & Capabilities Advertisement Interface 988 The Downstream CDN advertises its capability to support URI Signing 989 via the CDNI Footprint & Capabilities Advertisement interface (FCI). 990 The supported version of URI Signing needs to be included to allow 991 for future extensibility. 993 [Editor's Note: To be discussed with FCI authors] 995 5.3. CDNI Request Routing Redirection Interface 997 [Editor's Note: Debate the approach of dCDN providing the Signed URI 998 vs. uCDN performing the signing function. List the pros/cons of each 999 approach for the CDNI Request Routing Redirection interface (RI). 1000 Offer recommendation?] 1002 The two approaches: 1004 1. Downstream CDN provides the Signed URI 1006 * Key distribution is not necessary 1008 * Downstream CDN can use any scheme for Signed URI as long as 1009 the security level meets the CSP's expectation 1011 2. Upstream CDN signs the URI 1013 * Consistency with interative request routing method 1015 * URI Signing works even when Downstream CDN does not have the 1016 signing function (which may be the case when the Downstream 1017 CDN operates only as a delivering CDN) 1019 * Upstream CDN can act as a conversion gateway for the 1020 requesting routing interface between Upstream CDN and CSP and 1021 request routing interface between Upstream CDN and Downstream 1022 CDN since these two interfaces may not be the same 1024 5.4. CDNI Metadata Interface 1026 The following CDNI Metadata objects are specified for URI Signing. 1028 o URI Signing enforcement flag. Specifically, this flag indicates 1029 if the access to content is subject to URI Signing. URI Signing 1030 requires the Downstream CDN to ensure that the URI must be signed 1031 and validated before content delivery. Otherwise, Downstream CDN 1032 does not perform validation regardless if URI is signed or not. 1034 o Designated key identifier used for URI Signing computation when 1035 the Signed URI does not contain the Key ID information element 1037 o Allowable Key ID set that the Signed URI's Key ID information 1038 element can reference 1040 o Designated hash function used for URI Signing computation when the 1041 Signed URI does not contain the Hash Function information element 1043 o Allowable Hash Function set that the Signed URI's Hash Function 1044 information element can reference 1046 o Designated digital signature function used for URI Signing 1047 computation when the Signed URI does not contain the Digital 1048 Signature Algorithm information element. 1050 o Allowable digital signature function set that the Signed URI's 1051 Digital Signature Algorithm information element can reference. 1053 o Designated version used for URI Signing computation when the 1054 Signed URI does not contain the VER attribute 1056 o Allowable version/algorithm set that the Signed URI's VER 1057 attribute can reference 1059 o Allowable set of Downstream CDNs that participate in URI Signing 1060 based on the symmetric key 1062 o Overwrite the default encoding method for URI Signing Attribute 1063 Set attribute? [Editor's Note: Do we need this?] 1065 o Overwrite the default name for the URL Signing Attribute Set 1066 attribute? [Editor's Note: Do we need this?] 1068 Note that the Key ID information is not needed if only one key is 1069 provided by the CSP or the Upstream CDN for the content item or set 1070 of content items covered by the CDNI Metadata object. In the case of 1071 asymmetric keys, it's easy for any entity to sign the URI for content 1072 with a private key and provide the public key in the Signed URI. 1073 This just confirms that the URI Signer authorized the delivery. But 1074 it's necessary for the URI Signer to be the content owner. So, the 1075 CDNI Metadata interface MUST provide the public key for the content 1076 or information to authorize the received Key ID attribute. 1078 5.5. CDNI Logging Interface 1080 The Downstream CDN reports that enforcement of the access control was 1081 applied to the request for content delivery. 1083 The following CDNI Logging field for URI Signing SHOULD be supported 1084 in the HTTP Request Logging Record as specified in CDNI Logging 1085 Interface [I-D.ietf-cdni-logging]. 1087 o s-uri-signing: 1089 * format: 1DIGIT 1091 * field value: this characterises the uri signing validation 1092 performed by the Surrogate on the request. The allowed values 1093 are: 1095 + "0" : no uri signature validation performed 1097 + "1" : uri signature validation performed and validated 1099 + "2" : uri signature validation performed and rejected 1101 * occurrence: there MUST be zero or exactly one instance of this 1102 field. 1104 [Editor's note: Need to log these URI signature validation events 1105 (e.g. invalid client IP address, expired signed URI, incorrect URI 1106 signature, successful validation)?] 1108 TBD: CDNI Logging interface is work in progress. 1110 6. URI Signing Message Flow 1112 URI Signing supports both HTTP-based and DNS-based request routing. 1113 HMAC [RFC2104] defines a hash-based message authentication code 1114 allowing two parties that share a symmetric key or asymmetric keys to 1115 establish the integrity and authenticity of a set of information 1116 (e.g. a message) through a cryptographic hash function. 1118 6.1. HTTP Redirection 1120 For HTTP-based request routing, HMAC is applied to a set of 1121 information that is unique to a given end user content request using 1122 key information that is specific to a pair of adjacent CDNI hops 1123 (e.g. between the CSP and the Authoritative CDN, between the 1124 Authoritative CDN and a Downstream CDN). This allows a CDNI hop to 1125 ascertain the authenticity of a given request received from a 1126 previous CDNI hop. 1128 The URI signing scheme described below is based on the following 1129 steps (assuming HTTP redirection, iterative request routing and a CDN 1130 path with two CDNs). Note that Authoritative CDN and Upstream CDN 1131 are used exchangeably. 1133 End-User dCDN uCDN CSP 1134 | | | | 1135 | 1.CDNI FCI interface used to | | 1136 | advertise URI Signing capability| | 1137 | |------------------->| | 1138 | | | | 1139 | 2.Provides information to validate URI signature| 1140 | | |<-------------------| 1141 | | | | 1142 | 3.CDNI Metadata interface used to| | 1143 | provide URI Signing attributes| | 1144 | |<-------------------| | 1145 |4.Authorization request | | 1146 |------------------------------------------------------------->| 1147 | | | [Apply distribution 1148 | | | policy] | 1149 | | | | 1150 | | (ALT: Authorization decision) 1151 |5.Request is denied | | | 1152 |<-------------------------------------------------------------| 1153 | | | | 1154 |6.CSP provides signed URI | | 1155 |<-------------------------------------------------------------| 1156 | | | | 1157 |7.Content request | | | 1158 |---------------------------------------->| [Validate URI | 1159 | | | signature] | 1160 | | | | 1161 | | (ALT: Validation result) | 1162 |8.Request is denied | | | 1163 |<----------------------------------------| | 1164 | | | | 1165 |9.Re-sign URI and redirect to | | 1166 | dCDN (newly signed URI) | | 1167 |<----------------------------------------| | 1168 | | | | 1169 |10.Content request | | | 1170 |------------------->| [Validate URI | | 1171 | | signature] | | 1172 | | | | 1173 | (ALT: Validation result) | | 1174 |11.Request is denied| | | 1175 |<-------------------| | | 1176 | | | | 1177 |12.Content delivery | | | 1178 |<-------------------| | | 1179 : : : : 1180 : (Later in time) : : : 1181 |13.CDNI Logging interface to include URI Signing information | 1182 | |------------------->| | 1184 Figure 3: HTTP-based Request Routing with URI Signing 1186 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1187 the Downstream CDN advertises its capabilities including URI 1188 Signing support to the Authoritative CDN. 1190 2. CSP provides to the Authoritative CDN the information needed to 1191 validate URI signatures from that CSP. For example, this 1192 information may include a hashing function, algorithm, and a key 1193 value. 1195 3. Using the CDNI Metadata interface, the Authoritative CDN 1196 communicates to a Downstream CDN the information needed to 1197 validate URI signatures from the Authoritative CDN for the given 1198 CSP. For example, this information may include the URI query 1199 string parameter name for the URI Signing Package Attribute, a 1200 hashing algorithm and/or a key corresponding to the trust 1201 relationship between the Authoritative CDN and the Downstream 1202 CDN. 1204 4. When a UA requests a piece of protected content from the CSP, 1205 the CSP makes a specific authorization decision for this unique 1206 request based on its arbitrary distribution policy 1208 5. If the authorization decision is negative, the CSP rejects the 1209 request. 1211 6. If the authorization decision is positive, the CSP computes a 1212 Signed URI that is based on unique parameters of that request 1213 and conveys it to the end user as the URI to use to request the 1214 content. 1216 7. On receipt of the corresponding content request, the 1217 authoritative CDN validates the URI Signature in the URI using 1218 the information provided by the CSP. 1220 8. If the validation is negative, the authoritative CDN rejects the 1221 request 1223 9. If the validation is positive, the authoritative CDN computes a 1224 Signed URI that is based on unique parameters of that request 1225 and provides to the end user as the URI to use to further 1226 request the content from the Downstream CDN 1228 10. On receipt of the corresponding content request, the Downstream 1229 CDN validates the URI Signature in the Signed URI using the 1230 information provided by the Authoritative CDN in the CDNI 1231 Metadata 1233 11. If the validation is negative, the Downstream CDN rejects the 1234 request and sends an error code (e.g. 403) in the HTTP response. 1236 12. If the validation is positive, the Downstream CDN serves the 1237 request and delivers the content. 1239 13. At a later time, Downstream CDN reports logging events that 1240 includes URI signing information. 1242 With HTTP-based request routing, URI Signing matches well the general 1243 chain of trust model of CDNI both with symmetric key and asymmetric 1244 keys because the key information only need to be specific to a pair 1245 of adjacent CDNI hops. 1247 6.2. DNS Redirection 1249 For DNS-based request routing, the CSP and Authoritative CDN must 1250 agree on a trust model appropriate to the security requirements of 1251 the CSP's particular content. Use of asymmetric public/private keys 1252 allows for unlimited distribution of the public key to Downstream 1253 CDNs. However, if a shared secret key is preferred, then the CSP may 1254 want to restrict the distribution of the key to a (possibly empty) 1255 subset of trusted Downstream CDNs. Authorized Delivery CDNs need to 1256 obtain the key information to validate the Signed UR, which is 1257 computed by the CSP based on its distribution policy. 1259 The URI signing scheme described below is based on the following 1260 steps (assuming iterative DNS request routing and a CDN path with two 1261 CDNs). Note that Authoritative CDN and Upstream CDN are used 1262 exchangeably. 1264 End-User dCDN uCDN CSP 1265 | | | | 1266 | 1.CDNI FCI interface used to | | 1267 | advertise URI Signing capability| | 1268 | |------------------->| | 1269 | | | | 1270 | 2.Provides information to validate URI signature| 1271 | | |<-------------------| 1272 | 3.CDNI Metadata interface used to| | 1273 | provide URI Signing attributes| | 1274 | |<-------------------| | 1275 |4.Authorization request | | 1276 |------------------------------------------------------------->| 1277 | | | [Apply distribution 1278 | | | policy] | 1279 | | | | 1280 | | (ALT: Authorization decision) 1281 |5.Request is denied | | | 1282 |<-------------------------------------------------------------| 1283 | | | | 1284 |6.Provides signed URI | | 1285 |<-------------------------------------------------------------| 1286 | | | | 1287 |7.DNS request | | | 1288 |---------------------------------------->| | 1289 | | | | 1290 |8.Redirect DNS to dCDN | | 1291 |<----------------------------------------| | 1292 | | | | 1293 |9.DNS request | | | 1294 |------------------->| | | 1295 | | | | 1296 |10.IP address of Surrogate | | 1297 |<-------------------| | | 1298 | | | | 1299 |11.Content request | | | 1300 |------------------->| [Validate URI | | 1301 | | signature] | | 1302 | | | | 1303 | (ALT: Validation result) | | 1304 |12.Request is denied| | | 1305 |<-------------------| | | 1306 | | | | 1307 |13.Content delivery | | | 1308 |<-------------------| | | 1309 : : : : 1310 : (Later in time) : : : 1311 |14.CDNI Logging interface to report URI Signing information | 1312 | |------------------->| | 1314 Figure 4: DNS-based Request Routing with URI Signing 1316 1. Using the CDNI Footprint & Capabilities Advertisement interface, 1317 the Downstream CDN advertises its capabilities including URI 1318 Signing support to the Authoritative CDN. 1320 2. CSP provides to the Authoritative CDN the information needed to 1321 validate cryptographic signatures from that CSP. For example, 1322 this information may include a hash function, algorithm, and a 1323 key. 1325 3. Using the CDNI Metadata interface, the Authoritative CDN 1326 communicates to a Downstream CDN the information needed to 1327 validate cryptographic signatures from the CSP (e.g. the URI 1328 query string parameter name for the URI Signing Package 1329 Attribute). In the case of symmetric key, the Authoritative CDN 1330 checks if the Downstream CDN is allowed by CSP to obtain the 1331 shared secret key. 1333 4. When a UA requests a piece of protected content from the CSP, 1334 the CSP makes a specific authorization decision for this unique 1335 request based on its arbitrary distribution policy. 1337 5. If the authorization decision is negative, the CSP rejects the 1338 request 1340 6. If the authorization decision is positive, the CSP computes a 1341 cryptographic signature that is based on unique parameters of 1342 that request and includes it in the URI provided to the end user 1343 to request the content. 1345 7. End user sends DNS request to the authoritative CDN. 1347 8. On receipt of the DNS request, the authoritative CDN redirects 1348 the request to the Downstream CDN. 1350 9. End user sends DNS request to the Downstream CDN. 1352 10. On receipt of the DNS request, the Downstream CDN responds with 1353 IP address of one of its Surrogates. 1355 11. On receipt of the corresponding content request, the Downstream 1356 CDN validates the cryptographic signature in the URI using the 1357 information provided by the Authoritative CDN in the CDNI 1358 Metadata 1360 12. If the validation is negative, the Downstream CDN rejects the 1361 request and sends an error code (e.g. 403) in the HTTP response. 1363 13. If the validation is positive, the Downstream CDN serves the 1364 request and delivers the content. 1366 14. At a later time, Downstream CDN reports logging events that 1367 includes URI signing information. 1369 With DNS-based request routing, URI Signing matches well the general 1370 chain of trust model of CDNI when used with asymmetric keys because 1371 the only key information that need to be distributed across multiple 1372 CDNI hops including non-adjacent hops is the public key, that is 1373 generally not confidential. 1375 With DNS-based request routing, URI Signing does not match well the 1376 general chain of trust model of CDNI when used with symmetric keys 1377 because the symmetric key information needs to be distributed across 1378 multiple CDNI hops including non-adjacent hops. This raises a 1379 security concern for applicability of URI Signing with symmetric keys 1380 in case of DNS-based inter-CDN request routing. 1382 7. HTTP Adaptive Streaming 1384 The authors note that in order to perform URI signing for individual 1385 content segments of HTTP Adaptive Bitrate content, specific URI 1386 signing mechanisms are needed. Such mechanisms are currently out-of- 1387 scope of this document. More details on this topic is covered in 1388 Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. 1390 8. IANA Considerations 1392 [Editor's note: (Is there a need to) register default value for URI 1393 Signing Package Attribute URI query string parameter name (i.e. 1394 URISigningPackage) to be used for URI Signing? Need anything from 1395 IANA?] 1397 [Editor's note: To do: Convert to proper IANA Registry format] 1399 This document requests IANA to create three new registries for the 1400 Information Elements and their defined values to be used for URI 1401 Signing. 1403 The following Enforcement Information Element names are allocated: 1405 o ET (Expiry time) 1407 o CIP (Client IP address) 1409 The following Signature Computation Information Element names are 1410 allocated: 1412 o VER (Version): 1(Base) 1414 o KID (Key ID) 1416 o HF (Hash Function): "MD5", "SHA-1", "SHA-256", "SHA-3" 1418 o DSA (Digital Signature Algorithm): "RSA, "DSA", "EC-DSA" 1420 The following URI Signature Information Element names are allocated: 1422 o MD (Message Digest) 1424 o DS (Digital Signature) 1426 The IANA is requested to allocate a new entry to the CDNI Logging 1427 Field Names Registry as specified in CDNI Logging Interface 1428 [I-D.ietf-cdni-logging] in accordance to the "Specification Required" 1429 policy [RFC5226] 1431 o s-url-signing 1433 o [Editor's note: logging error codes are needed for URI Signing?] 1435 The IANA is requested to allocate a new entry to the CDNI Metadata 1436 Field Names Registry as specified in CDNI Metadata Interface 1437 [I-D.ietf-cdni-metadata] in accordance to the "Specification 1438 Required" policy [RFC5226] 1440 o URI Signing Package URI query parameter name 1 Token 1442 o More metadata... 1444 9. Security Considerations 1446 This document describes the concept of URI Signing and how it can be 1447 used to provide access authorization in the case of interconnected 1448 CDNs (CDNI). The primary goal of URI Signing is to make sure that 1449 only authorized UAs are able to access the content, with a Content 1450 Service Provider (CSP) being able to authorize every individual 1451 request. It should be noted that URI Signing is not a content 1452 protection scheme; if a CSP wants to protect the content itself, 1453 other mechanisms, such as DRM, are more appropriate. 1455 In general, it holds that the level of protection against 1456 illegitimate access can be increased by including more Enforcement 1457 Information Elements in the URI. The current version of this 1458 document includes elements for enforcing Client IP Address and 1459 Expiration Time, however this list can be extended with other, more 1460 complex, attributes that are able to provide some form of protection 1461 against some of the vulnerabilities highlighted below. 1463 That said, there are a number of aspects that limit the level of 1464 security offered by URI signing and that anybody implementing URI 1465 signing should be aware of. 1467 Replay attacks: Any (valid) Signed URI can be used to perform 1468 replay attacks. The vulnerability to replay attacks can be 1469 reduced by picking a relatively short window for the Expiration 1470 Time attribute, although this is limited by the fact that any 1471 HTTP-based request needs a window of at least a couple of seconds 1472 to prevent any sudden network issues from preventing legitimate 1473 UAs access to the content. One way to reduce exposure to replay 1474 attacks is to include in the URI a unique one-time access ID. 1475 Whenever the Downstream CDN receives a request with a given unique 1476 access ID, it adds that access ID to the list of 'used' IDs. In 1477 the case an illegitimate UA tries to use the same URI through a 1478 replay attack, the Downstream CDN can deny the request based on 1479 the already-used access ID. 1481 Illegitimate client behind a NAT: In cases where there are 1482 multiple users behind the same NAT, all users will have the same 1483 IP address from the point of view of the Downstream CDN. This 1484 results in the Downstream CDN not being able to distinguish 1485 between the different users based on Client IP Address and 1486 illegitimate users being able to access the content. One way to 1487 reduce exposure to this kind of attack is to not only check for 1488 Client IP but also for other attributes that can be found in the 1489 HTTP headers. 1491 TBD: ... 1493 The shared key between CSP and Authoritative CDN may be distributed 1494 to Downstream CDNs - including cascaded CDNs. Since this key can be 1495 used to legitimately sign a URL for content access authorization, 1496 it's important to know the implications of a compromised shared key. 1498 [Editor's note: Threat model cover in the Security section - Prevent 1499 client from spoofing URI (Ray) - Security implications - The scope of 1500 protection by URI Signing - Protects against DoS (network bandwidth 1501 and other nodes besides the edge cache); limits the time window. ] 1503 10. Privacy 1505 The privacy protection concerns described in CDNI Logging Interface 1506 [I-D.ietf-cdni-logging] apply when the client's IP address (CIP 1507 attribute) is embedded in the Signed URI. This means that, when 1508 anonymization is enabled, the URI Signing Package Attribute MUST be 1509 removed from the logging record. 1511 11. Acknowledgements 1513 The authors would like to thank the following people for their 1514 contributions in reviewing this document and providing feedback: 1515 Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan York, Bhaskar 1516 Bhupalam, Matt Caulfield, and Samuel Rajakumar . 1518 12. References 1520 12.1. Normative References 1522 [I-D.ietf-cdni-logging] 1523 Faucheur, F., Bertrand, G., Oprescu, I., and R. 1524 Peterkofsky, "CDNI Logging Interface", 1525 draft-ietf-cdni-logging-10 (work in progress), March 2014. 1527 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1528 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1529 May 2008. 1531 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1532 Distribution Network Interconnection (CDNI) Problem 1533 Statement", RFC 6707, September 2012. 1535 12.2. Informative References 1537 [I-D.ietf-cdni-framework] 1538 Peterson, L., Davie, B., and R. Brandenburg, "Framework 1539 for CDN Interconnection", draft-ietf-cdni-framework-10 1540 (work in progress), March 2014. 1542 [I-D.ietf-cdni-metadata] 1543 Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., 1544 Leung, K., and K. Ma, "CDN Interconnect Metadata", 1545 draft-ietf-cdni-metadata-06 (work in progress), 1546 February 2014. 1548 [I-D.ietf-cdni-requirements] 1549 Leung, K. and Y. Lee, "Content Distribution Network 1550 Interconnection (CDNI) Requirements", 1551 draft-ietf-cdni-requirements-17 (work in progress), 1552 January 2014. 1554 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1555 Hashing for Message Authentication", RFC 2104, 1556 February 1997. 1558 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1559 Resource Identifier (URI): Generic Syntax", STD 66, 1560 RFC 3986, January 2005. 1562 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1563 Encodings", RFC 4648, October 2006. 1565 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1566 Address Text Representation", RFC 5952, August 2010. 1568 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 1569 K., and G. Watson, "Use Cases for Content Delivery Network 1570 Interconnection", RFC 6770, November 2012. 1572 [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., 1573 and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware 1574 Content Distribution Network Interconnection (CDNI)", 1575 RFC 6983, July 2013. 1577 Authors' Addresses 1579 Kent Leung 1580 Cisco Systems 1581 3625 Cisco Way 1582 San Jose 95134 1583 USA 1585 Phone: +1 408 526 5030 1586 Email: kleung@cisco.com 1587 Francois Le Faucheur 1588 Cisco Systems 1589 Greenside, 400 Avenue de Roumanille 1590 Sophia Antipolis 06410 1591 France 1593 Phone: +33 4 97 23 26 19 1594 Email: flefauch@cisco.com 1596 Bill Downey 1597 Verizon Labs 1598 60 Sylvan Road 1599 Waltham, Massachusetts 02451 1600 USA 1602 Phone: +1 781 466 2475 1603 Email: william.s.downey@verizon.com 1605 Ray van Brandenburg 1606 TNO 1607 Brassersplein 2 1608 Delft, 2612CT 1609 the Netherlands 1611 Phone: +31 88 866 7000 1612 Email: ray.vanbrandenburg@tno.nl 1614 Scott Leibrand 1615 Limelight Networks 1616 222 S Mill Ave 1617 Tempe, AZ 85281 1618 USA 1620 Phone: +1 360 419 5185 1621 Email: sleibrand@llnw.com