CDNI Working Group Wei Ni Internet Draft Yana Bi Intended status: Standards Track Yunfei Zhang Expires: January 2013 China Mobile July 9, 2012 Models for URL Signing and Validation in CDNI draft-ni-cdni-url-signing-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 9, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Ni et all Expires January 9, 2013 [Page 1 Internet-Draft URL Signing and Validation July 2012 Abstract In CDNI deployment, URL signing mechanism should continue to function for content access restriction. Previous CDNI documents have described the basic of URL signing. However, in some cases that the key cannot be distributed from the Authoritative CDN to the Delivering CDN, the URL validation requirement cannot be fulfilled. This document gives some supplementary description concerning URL signing and validation mechanism in case of DNS based Request Routing, and as a result, a compliment for authorization object in metadata interface is presented. Table of Contents 1. Introduction ................................................ 3 1.1. Terminology ............................................ 3 1.2. Abbreviations .......................................... 3 2. Conventions used in this document ........................... 3 3. URL Signing ................................................. 3 4. URL Validating in CDNI Deployment ........................... 4 5. Authorization Object......................................... 7 6. Security Considerations ..................................... 8 7. IANA Considerations ......................................... 8 8. References .................................................. 8 8.1. Normative References ................................... 8 8.2. Informative References ................................. 8 9. Acknowledgments ............................................. 9 Ni et all Expires January 9, 2013 [Page 2] Internet-Draft URL Signing and Validation July 2012 1. Introduction CSPs may perform per-request authentication decision to restrict content access to a particular user, and it should continue to function in CDNI environments. Previous CDNI documents have described basic of URL signing. However, different types of URL signing have been used in real applications. In some cases the key cannot be distributed from the Authoritative CDN to the Delivering CDN, so the URL validation requirements cannot be fulfilled. This document gives some additional description concerning URL signing and validation mechanism in case of DNS based Request Routing. For this consideration is likely to affect the CDNI interface, as a result, a discussion for the options of authorization object in metadata interface for URL signing is provided for discussion. 1.1. Terminology This document reuses the terminology defined in [I-D.draft-cdni- problem-statement] and [I-D. draft-cdni-framework]. 1.2. Abbreviations o UE: User Equipment o MSISDN: Mobile Subscriber ISDN Number 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3. URL Signing CSP usually need to restrict access to content to protect the copyright. To full this requirement, a usually used method is to embed the UE's IP address and a timestamp within the URL, and then validated by the content server. Because URL is inherently open, it can be modified manually, shared with unauthorized users, or Ni et all Expires January 9, 2013 [Page 3] Internet-Draft URL Signing and Validation July 2012 continue to access beyond the time limit. Therefore a good way is to attach an encrypted signature to the URL, which is signed for a particular user. Once receiving the HTTP request, the content server could validate the signature with the authorization parameters extracting from the request URL as inputs. Only if the computation result matches with the signature in the request URL, the user's request has legitimate access to the content. The authorization parameters must be agreed upon between the URL signer and validating entity (e.g., source IP address, MSISDN provided by NSP's Internet Gateway, allotted timestamp or time period). The following is an example of URL signing rules used for the Mobile Video Service in China Mobile. Protocal://://?=&...&=&= Example1: rtsp://video.exmaple.com/test.3gp?msisdn=13888888888&ip=10.25.113.32 &key=D832AC16CC54615E313723538AF6F278 Example2: http://video.example.com/test.mov?msisdn=13888888888×tamp=20120 301122549&ip=10.5.7.34&key=5E313T23538AF6F234E96M3X53EA9H46 To generate the signature and validate the URL, it relies on a set of secret keys that share between the URL signer and validating entity. There are two types of URL signing: O Symmetric key URL signing: the same key is adopted for both signature generation and validation; O Asymmetric key URL signing: a key pair consisting of a public key and private key is adopted, where the private key is used for signing and the public key is used for validation. 4. URL Validating in CDNI Deployment In CDNI deployment, a signed URL could be provided by CSP to the user agent during website navigation. Under condition of DNS request Ni et all Expires January 9, 2013 [Page 4] Internet-Draft URL Signing and Validation July 2012 routing, the user's HTTP request is redirected by the Authoritative CDN via DNS, and finally the request is sent from user to a surrogate of the Delivering CDN, where the URL validation should be made before content delivering. The validation for content URLs should be supported by the upstream CDN and downstream CDN, and the validating entity must obtain the key. However, in the case of symmetric URL signing, the keys and the signing algorithm (eg., which parameters are used for the hash value computation) are usually top-level secret of CSP. In most cases, CSPs only share keys and algorithms with the Authoritative CDN that it has a business relationship with. CSPs usually don't allow the symmetric keys distributed to the Delivering CDN that it has no direct relationship with. On this condition, the Delivering CDN could not obtain enough authorization information via current metadata interface. Therefore, two types of URL validation mechanism should be supported. Case 1: Validating by the Delivering CDN. In this case, the key could be distributed from the Authoritative CDN to the Delivering CDN. The URL validation is made by the Delivering CDN. After DNS based request routing process, the user's request is sent to a surrogate of the Delivering CDN. Depending on the configured rules obtained from the metadata interface, the Delivering CDN determines that this URL should be validated by itself. It then makes the key hash computing with parameters extracting from the URL and the keys. If the computing result is matched with the signature embedded in URL and the content has already been distributed to the Delivering CDN, it directly delivers the content data to the user agent. If the Delivering CDN missed, it just acts as a proxy and requests the content from the Authoritative CDN. If the signature is not matched, the Delivering CDN should respond to the user's content request with a 403 Forbidden status code. Ni et all Expires January 9, 2013 [Page 5] Internet-Draft URL Signing and Validation July 2012 End-User Delivering CDN Authoritative CDN CSP | | | | | HTTP GET video.cp.example/url_signing | |--------------------------------------------------------->| | | | | | | | | +---------------------|-------------------|--------------------+ | DNS based Request Routing | | | +---------------- ----|-------------------|--------------------+ | | | | |HTTP GET video.cp. | | | |example/url_signing| | | |------------------>| | | | | | | | Data | | | |<------------------| | | | | | | Figure 1. URL Validating by the Delivering CDN Case 2: Validating by the Authoritative CDN. In this case, the URL validation is made by the Authoritative CDN, and it does not need key provisioning and distribution. After DNS based request routing process, content request is sent to a surrogate of the Delivering CDN. Depending on the configured rules obtained from the metadata interface, the Delivering CDN determines that this URL should be validated by the Authoritative CDN. It then directly transmits the request to the Authoritative CDN. The Authoritative CDN makes the hash computing with parameters extracting from the URL and the keys. If the computing result is matched with the signature embedded in URL, which means that this request is from a valid user, a HTTP 200 OK message is sent from the Authoritative CDN to the Delivering CDN, the Delivering CDN then delivers the content data to the user agent. If the signature is not matched, the Authoritative CDN should respond to the content request with a 403 Forbidden status code. Upon receiving this message from the Authoritative CDN, the Delivering CDN also send a response message with a 403 Forbidden status code to the user. Ni et all Expires January 9, 2013 [Page 6] Internet-Draft URL Signing and Validation July 2012 End-User Delivering CDN Authoritative CDN CSP | | | | | HTTP GET video.cp.example/url_signing | |--------------------------------------------------------->| | | | | | | | | +---------------------|-------------------|--------------------+ | DNS based Request Routing | | | +---------------------|-------------------|--------------------+ | | | | |HTTP GET video.cp. | | | |example/url_signing| | | |------------------>| | | | |HTTP GET video.cp. | | | |example/url_signing| | | |------------------>| | | | | | | |HTTP RESPONSE200 OK| | | |<------------------| | | Data | | | |<------------------| | | | | | | Figure 2. URL Validating by the Authoritative CDN 5. Authorization Object The authorization object describes an authorization type and the corresponding parameters. It provides information for content delivery such that the user agent can be authenticated when requesting content from the Delivering CDN. To support the above different type of validation mode (by the Delivering CDN or the Authoritative CDN), the authorization object should contains the following fields: O type - a string containing the authorization type "url-signing" or "url-token". O validation -a string indicating which entity to make the validation (e.g., "Authoritative CDN", "Delivering CDN"). O algo - a string containing the signature algorithm (e.g. "md5", "sha-1", etc.). O symmetric - a boolean if true, URL signing uses symmetric keys, otherwise asymmetric. Ni et all Expires January 9, 2013 [Page 7] Internet-Draft URL Signing and Validation July 2012 O key - a number containing the public key for verifying signatures, only valid if "symmetric" field is set to false. The following is an example of authorization object in case of URL validating by the Authoritative CDN. It can be seen that only the validation information needs to be transmitted via the metadata interface, other fields could be blank. { "metadataType": "Authorization", "object": { "type": "url-signing", "validation": "Authoritative CDN", "algorithm": "", "symmetric": "", "key": "" } } 6. Security Considerations TBD. 7. IANA Considerations This document makes no request of IANA. 8. References 8.1. Normative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 8.2. Informative References [I-D.draft-cdni-problem-statement] "Content Distribution Network Interconnection (CDNI) Problem Ni et all Expires January 9, 2013 [Page 8] Internet-Draft URL Signing and Validation July 2012 Statement", B. Niven-Jenkins, F. Le Faucheur, N. Bitar, June, 2012. [I-D.draft-cdni-requirements] "Content Distribution Network Interconnection (CDNI) Requirements", K. Leung, Y. Lee, September, 2011. [I-D.davie-cdni-framework] B. Davie, and L. Peterson, "Framework for CDN Interconnection", draft-davie-cdni-framework-00 (work in progress), April 2012. [I-D. caulfield-cdni-metadata-core] M. Caulfield, and K. Leung, " Content Distribution Network Interconnection (CDNI) Core Metadata", draft-caulfield-cdni- metadata-core-00 (work in progress), October, 2011. 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Ni et all Expires January 9, 2013 [Page 9] Internet-Draft URL Signing and Validation July 2012 Authors' Addresses Wei Ni China Mobile Communication Corporation. niwei@chinamobile.com Yana Bi China Mobile Communication Corporation. biyana@chinamobile.com Yunfei Zhang China Mobile Communication Corporation zhangyunfei@chinamobile.com Ni et all Expires January 9, 2013 [Page 10]