Internet DRAFT - draft-ni-cdni-url-signing
draft-ni-cdni-url-signing
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://<host>:<port>/<path>/<filename>?<param1>=<value1>&...&<par
amN>=<valueN>&<hash>=<hash>
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]
