URI Signing for CDN Interconnection (CDNI)
draft-leung-cdni-uri-signing-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Kent Leung , François Le Faucheur , Matt Caulfield | ||
| Last updated | 2012-10-13 | ||
| Replaced by | draft-ietf-cdni-uri-signing, draft-ietf-cdni-uri-signing, RFC 9246 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-leung-cdni-uri-signing-00
CDNI K. Leung
Internet-Draft F. Le Faucheur
Intended status: Standards Track M. Caulfield
Expires: April 16, 2013 Cisco Systems
Oct 13, 2012
URI Signing for CDN Interconnection (CDNI)
draft-leung-cdni-uri-signing-00
Abstract
This document describes how the concept of URI signing supports the
content access control requirements of CDNI and proposes a candidate
URI signing scheme.
The proposed URI signing method specifies the information needed to
be included in the URI and the algorithm used to authorize and to
validate access request for the content referenced by the URI.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 16, 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
Leung, et al. Expires April 16, 2013 [Page 1]
Internet-Draft CDNI URI Signing Oct 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. URI Signing Overview . . . . . . . . . . . . . . . . . . . 4
2. Authorization Attributes in URI Signing . . . . . . . . . . . 4
3. URI Signing and Validation . . . . . . . . . . . . . . . . . . 6
4. Considerations for CDNI Interfaces . . . . . . . . . . . . . . 8
4.1. CDNI Capabilities Advertisement . . . . . . . . . . . . . 8
4.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 9
4.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 9
5. URI Signing Operation . . . . . . . . . . . . . . . . . . . . 9
5.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . . 10
5.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 13
6. HTTP Adaptive Bit Rate . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Leung, et al. Expires April 16, 2013 [Page 2]
Internet-Draft CDNI URI Signing Oct 2012
1. Introduction
The overall problem space for CDN Interconnection is described in
[RFC6707].
The CDNI Problem Statement [RFC6707], the CDN requirements document
[I-D.ietf-cdni-requirements] and the CDNI Framework
document[I-D.ietf-cdni-framework] discuss the need for the
interconnected CDNs to be able to implement an access control
mechanism that enforces the CSP distribution policy.
Specifically, [I-D.ietf-cdni-framework] states:
"The CSP may also trust the CDN operator to perform actions such as
..., and to enforce per-request authorization performed by the CSP
using techniques such as URI signing."
In particular, the following requirement is listed in
[I-D.ietf-cdni-requirements]:
"META-17 [HIGH] The CDNI Metadata Distribution interface shall allow
signaling of authorization checks and validation that are to be
performed by the surrogate before delivery. For example, this could
potentially include:
* need to validate URI signed information (e.g. Expiry time, Client
IP address)."
This document proposes a URI signing scheme that allows Surrogates in
interconnected CDNs to enforce a per-request authorization performed
by the CSP. Splitting the role of performing per-request
authorization by CSP and the role of validation of this authorization
by the CDN allows any arbitrary distribution policy to be enforced
across CDNs without the need of CDNs to have any awareness of the
actual CSP distribution policy.
1.1. Terminology
This document uses the terminology defined in [RFC6707].
This document also uses the terminology of [RFC2104] including the
following terms (reproduced here for convenience):
o MAC: message authentication code
o HMAC: hash-based message authentication code (HMAC)
Leung, et al. Expires April 16, 2013 [Page 3]
Internet-Draft CDNI URI Signing Oct 2012
o HMAC-SHA1: HMAC instantiation using SHA1 as the cryptographic hash
function
o HMAC-MD5: HMAC instantiation using MD5 as the cryptographic hash
function
In addition, the following terms are used throughout this document:
o URI Signature: message digest that is computed with an algorithm
that uses the key and URI as inputs to the hash function. This
value is appended in the signed URI.
1.2. URI Signing Overview
URI Signing is an authorization method for content delivery. This is
based on embedding the HTTP URI with information that can be
validated to ensure the request has legitimate access to the content.
There are two parts: 1) attributes that convey authorization
restrictions (e.g. source IP address and time period), and 2) message
digest that confirms the integrity and authenticity of the URI
provided by the URI creator. The authorization attributes can be
anything agreed upon between the entity that creates the URI and the
entity that validates the URI. A key is used by the HMAC algorithm
to generate the message digest (i.e. sign the URI) and validate the
message digest (i.e. URI signature). The two functions may or may
not use the same key.
There are two types of keys used for URI Signing: asymmetric keys and
symmetric key. Asymmetric keys always have a key pair made up of a
public key and private key. The private key and public key are used
for signing and validating the URI, respectively. A symmetric key is
the same key that is used for both functions. Regardless of the type
of key, the entity that validates the URI has to obtain the key.
Distribution for the symmetric key requires security to prevent
others from taking it. Public key can be distributed freely while
private key is kept by the URI signer.
URI Signing operates in the following way. A signed URI is provided
by the CSP (i.e. URI signer) to the user out of band. When the user
selects the URI, the HTTP request is sent to the CDN which validates
that URI before delivering the content.
2. Authorization Attributes in URI Signing
This section identifies the set of query string attributes that
provide the authorization information needed to enforce the
distribution policy of a CSP. Since the URI signing mechanism
Leung, et al. Expires April 16, 2013 [Page 4]
Internet-Draft CDNI URI Signing Oct 2012
provides flexibility in policy enforcement, the exact subset of
attributes used for URI signature in a given request is a deployment
decision. The defined keyword for each query string attribute is
specified in parenthesis below.
o Version (VER) - An integer used for identifying the version of URI
signing method with its set of capabilities.
o Expiry Time (ET) - Time in seconds when URL expires since midnight
1/1/1970 UTC (i.e. UNIX epoch).
o Client IP (CIP) - IP address of the client in a dotted decimal
format.
o Key Owner (KO) - Identifier of secret key owner in an integer
format.
o Key ID (KN) - A number that is used as an index to the key used to
validate the URI signature.
o Hash Function (HF) - A string used for identifying the hash
algorithm (e.g. "MD5", "SHA1").
o Algorithm (ALG) - An integer used for identifying the algorithm to
compute the URI signature.
o Client ID (CID) - Identifier of the client such as IMSI, MSISDN,
MEID, MAC address, etc.
The query string attributes are embedded within the content URL to
provide information needed to enforce the distribution policy. Each
of the attributes is further described below.
The Client IP attribute is used to restrict content access to a
particular user, based on the client IP address of the user for whom
the content access was authorized.
The Expiry Time attribute ensures that the content expires after a
predetermined time. This limits the time window for content access
and prevents replay of the request beyond the allotted time.
The Key Owner and Key ID attributes are used to index the key that is
retrieved as input to the HMAC algorithm to compute the message
digest for validaing the signed URI.
The Algorithm attribute indicates the HMAC algorithm to be used for
message digest computation.
Leung, et al. Expires April 16, 2013 [Page 5]
Internet-Draft CDNI URI Signing Oct 2012
The Version attribute indicates which set of capabilities are
supported (e.g. attributes and their defined values).
The Client ID attribute is used to restrict content access to a
particular user associated with this identifier. For example, it
could be the information about the subscriber, device, or network
access interface.
3. URI Signing and Validation
The keyword for the URI signature is "US".
The following steps are taken for signing an URI for the algorithms
defined in this document. Note that some steps may be skipped if the
attribute is not needed to enforce the distribution policy. The
entire URI (i.e. scheme, authority, path, query, and fragment as
defined in URI Generic Syntax [RFC3986]) is protected by the URI
signature when the algorithm (i.e. "ALG") is set to 1. The scheme
is removed from the URI when the algorithm is set to 2. This allows
the URI signature to be validated correctly in the case when a client
performs a fallback to HTTP for a content referenced by an URI with
RTSP scheme.
1. Check if the content URI already contains a query string. If
not, append a "?" character. If yes, append an "&" character.
2. Append the string "VER=0". This represents the base version of
URI Signing.
3. Append the string "&ET=".
4. Get the current time in seconds since epoch (as an integer).
Add the expiry time in seconds as an integer.
5. Append this integer.
6. Append the string "&CIP=".
7. Append the client's IP address in dotted decimal format.
8. Append the string "&KO=".
9. Append the numeric value of the key owner corresponding to the
key being used.
10. Append the string "&KN=".
Leung, et al. Expires April 16, 2013 [Page 6]
Internet-Draft CDNI URI Signing Oct 2012
11. Append the key ID number corresponding to the key being used.
12. Append the string "&HF=".
13. Append the string for the type of hash function.
14. Append the string "&ALG=".
15. Append the integer for the type of algorithm. Note: If
algorithm is "1", no additional logic needed by default. If
algorithm is "2", remove the scheme part of the URI.
16. Append the string "&US=".
17. Store this as the message (e.g. http://example.com/
content.mov?VER=0&ET=1209422976&CIP=171.71.50.123&KO=1&KN=2&
HF=1&ALG=1&US=).
18. For symmetric key, compute the message digest (i.e. URI
signature) using the algorithm with key and message as inputs ot
the hash function. For asymmetric keys, after the message
digest computation (as described previously), use the public key
to encrypt the message digest.
19. Convert the message digest to its equivalent human readable
hexidecimal value (e.g. f08b56f46075813e44b2d4888628a471).
20. Append this hexidecimal value to message. This is the complete
signed URI.
The following steps are taken for validating a signed URI. Note that
some steps may be skipped if the attributes are not embedded in the
URI. The lack of attribute indicates enforcement of its purpose is
not necessary in the distribution policy.
1. Check if the URI contains a query string. If not, it is not a
signed URI and request is denied.
2. Extract the value from "US=" part of URI. The value is the URI
signature.
3. Extract the values fom "KO=" and "KN= part of URI. Use these
values to locate the key and also key type (i.e. asymmetric or
symmetric)
4. Extract the value from "HF=" part of URI. The value is the type
of hash function.
Leung, et al. Expires April 16, 2013 [Page 7]
Internet-Draft CDNI URI Signing Oct 2012
5. Extract the value from "ALG=" part of URI. The value is the
type of algorithm.
6. Store URI excluding the part after "US=" as the message.
7. If the extracted algorithm value is "1", keep message without
change. If algorithm value is "2", remove the scheme part of
the URI in the message.
8. Compute the message digest (i.e. URI signature) using the
algorithm with key and message as inputs to the hash function
(based on the extracted hash function value).
9. For symmetric key, compare this computed value with the received
URI signature. For asymmetric keys, decrypt the URI signature
with the public key. Then compare the computed value with the
decrypted value. If the comparison is not a match, the request
is denied. Otherwise, continue with next step. Note that the
request is denied if any of the following validations failed.
10. Validate that the request came from the same IP address as
indicated in the "CIP=".
11. Validate that the request arrived before expiration time as
indicated in the "ET=" based on the current time.
4. Considerations for CDNI Interfaces
The CDNI Interfaces need enhancements to support URI Signing.
Downstream CDN that supports URI Signing needs to advertise this
capability to the Upstream CDN. Upstream CDN selects Downstream CDN
based on such capability when the CSP requires access control to
enforce its distribution policy. Also, Upstream CDN distributes
information relevant for validating a signed URI via the CDNI
Metadata interface. Events that pertain to URI Signing (e.g. request
denial or delivery after access authorization) are included in the
reports generated for the CDNI Logging interface.
4.1. CDNI Capabilities Advertisement
The Downstream CDN advertises its capability to support URI Signing
via the CDNI Request Routing interface. The version of URI Signing
should be included. TBD: subteam working on this area.
o URI Signing support and its version
Leung, et al. Expires April 16, 2013 [Page 8]
Internet-Draft CDNI URI Signing Oct 2012
o CDNI metadata for URI Signing support
4.2. CDNI Metadata Interface
The following CDNI metadata are specified for URI Signing. Note that
the Key Owner and Key ID information are not needed if only one key
is provided by CSP or Upstream CDN for the content or set of contents
covered by the CDNI metadata. Also, the CDNI metadata for HMAC
algorithm is not needed when the Algorithm attribute is embedded in
the signed URI. TBD: CDNI Metadata Interface is work in progress.
o Content access control indication.
o Type of access control. Specifically, access to content is
subject to URL signature validation
o Key (i.e. public key or shared key) along with its key index (i.e.
Key Owner and Key ID) and type (asymmetric or symmetric) used for
validating URI signature
o List of Downstream CDN authorized for key distribution (i.e. trust
relationship between CSP and CDNs)
o Algorithm for HMAC to be used for validation.
4.3. CDNI Logging Interface
The Downstream CDN reports that enforcement of the access control was
applied to the request for content delivery. TBD: CDNI Logging
interface is work in progress.
o URI signature validation events (e.g. invalid client IP address,
expired signed URI, incorrect URI signature, successful
validation)
o Delivery log with confirmation of access control enforcement (i.e
Delivery CDN enforced URI Signing before content delivery)
5. URI Signing Operation
URI Signing supports both the HTTP-based and DNS-based request
routing. HMAC [RFC2104] defines a hash-based message authentication
code allowing two parties that share a secret key to establish the
integrity and authenticity of a set of information (e.g. a message)
through a cryptographic hash function.
Leung, et al. Expires April 16, 2013 [Page 9]
Internet-Draft CDNI URI Signing Oct 2012
5.1. HTTP Redirection
For HTTP-based request routing, HMAC is applied to a set of
information that is unique to a given end user content request using
a secret key shared between adjacent CDNI hops (e.g. between the CSP
and the Authoritative CDN, between the Authoritative CDN and a
Downstream CDN). This allows a CDNI hop to ascertain the
authenticity of a given request received from a previous CDNI hop.
The URI signing scheme described below is based on the following
steps (assuming HTTP redirection, iterative request routing and a CDN
path with two CDNs). Note that Authoritative CDN and Upstream CDN
are used exchangeably.
Leung, et al. Expires April 16, 2013 [Page 10]
Internet-Draft CDNI URI Signing Oct 2012
End-User dCDN uCDN CSP
| | | |
| 1.Provides information to validate URI signature|
| | |<-------------------|
| 2.CDNI RR interface used to | |
| advertise URI Signing capability| |
| |------------------->| |
| 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| |
| |<-------------------| |
|4.Content request | | |
|------------------------------------------------------------->|
| | | [Apply distribution
| | | policy] |
| | | |
| | (ALT: Authorization decision)
|5.Request is denied | | <Negative> |
|<-------------------------------------------------------------|
| | | |
|6.Redirect to uCDN (signed URI) | <Positive> |
|<-------------------------------------------------------------|
| | | |
|7.Content request | | |
|---------------------------------------->| [Validate URI |
| | | signature] |
| | | |
| | (ALT: Validation result) |
|8.Request is denied | <Negative>| |
|<----------------------------------------| |
| | | |
|9.Re-sign URI and redirect to <Positive>| |
| dCDN (newly signed URI) | |
|<----------------------------------------| |
| | | |
|10.Content request | | |
|------------------->| [Validate URI | |
| | signature] | |
| | | |
| (ALT: Validation result) | |
|11.Request is denied| <Negative> | |
|<-------------------| | |
| | | |
|12.Content delivery | <Positive> | |
|<-------------------| | |
: : : :
: (Later in time) : : :
|13.CDNI Logging interface to report URI Signing information |
| |------------------->| |
Leung, et al. Expires April 16, 2013 [Page 11]
Internet-Draft CDNI URI Signing Oct 2012
Figure 1: HTTP-based Request Routing with URI Signing
1. CSP provides to the Authoritative CDN the information needed to
validate cryptographic signatures from that CSP. For example,
this information may include a hashing function, algorithm, and
a key.
2. Using the CDNI Request Routing interface, the Downstream CDN
advertises its capabilities including URI Signing support to the
Authoritative CDN.
3. Using the CDNI Metadata interface, the Authoritative CDN
communicates to a Downstream CDN the information needed to
validate cryptographic signatures from the Authoritative CDN for
the given CSP. For example, this information may include a
hashing algorithm and private key corresponding to the trust
relationship between the Authoritative CDN and the Downstream
CDN.
4. On receipt of a given content request on the CSP portal, the CSP
makes a specific authorization decision for this unique request
based on its arbitrary distribution policy.
5. If the authorization decision is negative, the CSP rejects the
request.
6. If the authorization decision is positive, the CSP computes a
cryptographic signature that is based on unique parameters of
that request and includes it in the URI provided to the end user
to request the content.
7. On receipt of the corresponding content request, the
authoritative CDN validates the cryptographic signature in the
URI using the information provided by the CSP.
8. If the validation is negative, the authoritative CDN rejects the
request
9. If the validation is positive, the authoritative CDN computes a
cryptographic signature that is based on unique parameters of
that request and includes it in the URI provided to the end user
to further request the content from the Downstream CDN
10. On receipt of the corresponding content request, the Downstream
CDN validates the cryptographic signature in the URI using the
information provided by the Authoritative CDN in the CDNI
Metadata
Leung, et al. Expires April 16, 2013 [Page 12]
Internet-Draft CDNI URI Signing Oct 2012
11. If the validation is negative, the Downstream CDN rejects the
request and sends an error code (e.g. 403) in the HTTP response.
12. If the validation is positive, the Downstream CDN serves the
request and delivers the content.
13. At a later time, Downstream CDN reports logging events that
includes URI signing information.
URI Signing with symmetric key or asymmetric keys works for HTTP-
based request routing because the trust relationship is between the
adjacent CDNs.
5.2. DNS Redirection
For DNS-based request routing, HMAC is applied to a set of
information that is unique to a given end user content request using
a secret key shared between CSP and the Delivery CDN. The Delivery
CDN needs to obtain the key information to validate the signed URL,
which is set by the CSP based on its distribution policy.
The URI signing scheme described below is based on the following
steps (assuming iterative DNS request routing and a CDN path with two
CDNs). Note that Authoritative CDN and Upstream CDN are used
exchangeably.
Leung, et al. Expires April 16, 2013 [Page 13]
Internet-Draft CDNI URI Signing Oct 2012
End-User dCDN uCDN CSP
| | | |
| 1.Provides information to validate URI signature|
| | |<-------------------|
| 2.CDNI RR interface used to | |
| advertise URI Signing capability| |
| |------------------->| |
| 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| |
| |<-------------------| |
|4.Content request | | |
|------------------------------------------------------------->|
| | | [Apply distribution
| | | policy] |
| | | |
| | (ALT: Authorization decision)
|5.Request is denied | | <Negative> |
|<-------------------------------------------------------------|
| | | |
|6.Redirect to uCDN (signed URI) | <Positive> |
|<-------------------------------------------------------------|
| | | |
|7.DNS request | | |
|---------------------------------------->| |
| | | |
|8.Redirect DNS to dCDN | |
|<----------------------------------------| |
| | | |
|9.DNS request | | |
|------------------->| | |
| | | |
|10.IP address of Surrogate | |
|<-------------------| | |
| | | |
|11.Content request | | |
|------------------->| [Validate URI | |
| | signature] | |
| | | |
| (ALT: Validation result) | |
|12.Request is denied| <Negative> | |
|<-------------------| | |
| | | |
|13.Content delivery | <Positive> | |
|<-------------------| | |
: : : :
: (Later in time) : : :
|14.CDNI Logging interface to report URI Signing information |
| |------------------->| |
Leung, et al. Expires April 16, 2013 [Page 14]
Internet-Draft CDNI URI Signing Oct 2012
Figure 2: DNS-based Request Routing with URI Signing
1. CSP provides to the Authoritative CDN the information needed to
validate cryptographic signatures from that CSP. For example,
this information may include a hash function, algorithm, and a
key.
2. Using the CDNI Request Routing interface, the Downstream CDN
advertises its capabilities including URI Signing support to the
Authoritative CDN.
3. Using the CDNI Metadata interface, the Authoritative CDN
communicates to a Downstream CDN the information needed to
validate cryptographic signatures from the CSP (i.e. private key
between CSP and participating CDNs). This requires a
relationship between CSP and Downstream CDN. The CDNI metadata
specifies CDNs with trust relationships according to the CSP.
The set of Downstream CDNs is limited by this criteria.
4. On receipt of a given content request on the CSP portal, the CSP
makes a specific authorization decision for this unique request
based on its arbitrary distribution policy.
5. If the authorization decision is negative, the CSP rejects the
request
6. If the authorization decision is positive, the CSP computes a
cryptographic signature that is based on unique parameters of
that request and includes it in the URI provided to the end user
to request the content.
7. End user sends DNS request to the authoritative CDN.
8. On receipt of the DNS request, the authoritative CDN redirects
the request to the Downstream CDN.
9. End user sends DNS request to the Downstream CDN.
10. On receipt of the DNS request, the Downstream CDN responds with
IP address of one of its Surrogates.
11. On receipt of the corresponding content request, the Downstream
CDN validates the cryptographic signature in the URI using the
information provided by the Authoritative CDN in the CDNI
Metadata
12. If the validation is negative, the Downstream CDN rejects the
request and sends an error code (e.g. 403) in the HTTP response.
Leung, et al. Expires April 16, 2013 [Page 15]
Internet-Draft CDNI URI Signing Oct 2012
13. If the validation is positive, the Downstream CDN serves the
request and delivers the content.
14. At a later time, Downstream CDN reports logging events that
includes URI signing information.
Note: DNS-based request routing using symmetric key is problematic
when Delivering CDN does not have trust relationship with the CSP.
URI Signing with asymmetric keys works for DNS-based request routing
because the CSP's public key can be distributed without restriction
to the Downstream CDN for validation of the signed URI.
6. HTTP Adaptive Bit Rate
TBD - HTTP ABR content introduces issues for URI Signing (reference
draft-brandenburg-cdni-has). Flexible URI Signing scheme to support
HTTP ABR content
7. IANA Considerations
This document requests IANA to create a new registry for CDNI URI
Signing. The following query string attribute names (a.k.a.
keywords) are assigned for the authorization attributes used in CDNI
URI Signing. There is no intention to claim any query string
attribute for URI beyond URI Signing context. That means the
entities that sign the URI or validate the URI signature comply to
the keywords specified in the query string for the URI Signing
function only when URI Signing is used.
o US (URI signature>
o VER (Version)
o ET (Expiry time)
o CIP (Client IP address)
o KO (Key owner)
o KN (Key ID)
o HF (Hash Function)
o ALG (Algorithm)
Leung, et al. Expires April 16, 2013 [Page 16]
Internet-Draft CDNI URI Signing Oct 2012
o CID (Client ID)
This document requests IANA to create a registry for each of the
defined query string attribute and assign the values for the
authorization attribute:
VER: 0 (Base)
HF: "MD5", "SHA1", "SHA256"
ALG: 1 (Full URI), 2 (URI without scheme)
CID: "MAC:<value>", "IMSI:<value>", "MSISDN:<value>", "MEID:<value>",
"NAI:<value>" (TBD)
8. Security Considerations
A symmetric key needs to be shared by the entity thats produces the
URI signature and the entity that validates the URI signature. In
the case of DNS-based request routing, CSP that signed the URI may
not have a relationship with the Downstream CDN that validates the
signed URI. In this case, the Upstream CDN shall select only the
Downstream CDN with a relationship with CSP. Otherwise, asymmetric
keys should be used for DNS-based request routing. The Downstream
CDN only needs to use the CSP's public key to validate the signed
URI. Asymmetric keys method does not have any require a relationship
between the two entities participating in URI Signing.
For HTTP-based request routing, the two entities participating in URI
Signing are always the adjacent Upstream CDN and Downstream CDN
because of the hop by hop nature of the redirection. Therefore,
either symmetric key or asymmetric keys can be used because the
adjacent Upstream CDN and Downstream CDN have a relationship.
The following security threats are identified (TBD):
o Client IP address spoofing
o Illegimate client behind a NAT
o Replay of request
9. Acknowledgements
TBD
Leung, et al. Expires April 16, 2013 [Page 17]
Internet-Draft CDNI URI Signing Oct 2012
10. References
10.1. Normative References
[I-D.ietf-cdni-framework]
Bertrand, G., Ed., Stephan, E., Watson, G., Burbridge, T.,
Eardley, P., and K. Ma, "Use Cases for Content Delivery
Network Interconnection, draft-ietf-cdni-use-cases-03",
January 2012.
[I-D.ietf-cdni-requirements]
Bertrand, G., Ed., Stephan, E., Watson, G., Burbridge, T.,
Eardley, P., and K. Ma, "Use Cases for Content Delivery
Network Interconnection, draft-ietf-cdni-use-cases-03",
January 2012.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012.
10.2. Informative References
[I-D.draft-bertrand-cdni-logging]
Bertrand, G., Ed. and E. Stephan, "CDNI Logging
Interface".
[I-D.draft-lefaucheur-cdni-logging-delivery]
Le Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI
Logging Formats for HTTP and HTTP Adaptive Streaming
Deliveries".
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
Leung, et al. Expires April 16, 2013 [Page 18]
Internet-Draft CDNI URI Signing Oct 2012
Authors' Addresses
Kent Leung
Cisco Systems
3625 Cisco Way
San Jose 95134
USA
Phone: +1 408 526 5030
Email: kleung@cisco.com
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
Matt Caulfield
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Phone: +1 978 936 9307
Email: mcaulfie@cisco.com
Leung, et al. Expires April 16, 2013 [Page 19]