draft-ietf-cdni-uri-signing-00.txt   draft-ietf-cdni-uri-signing-01.txt 
CDNI K. Leung CDNI K. Leung
Internet-Draft F. Le Faucheur Internet-Draft F. Le Faucheur
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 17, 2014 R. van Brandenburg Expires: March 20, 2015 R. van Brandenburg
TNO TNO
B. Downey B. Downey
Verizon Labs Verizon Labs
M. Fisher M. Fisher
Limelight Networks Limelight Networks
June 15, 2014 September 16, 2014
URI Signing for CDN Interconnection (CDNI) URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-00 draft-ietf-cdni-uri-signing-01
Abstract Abstract
This document describes how the concept of URI signing supports the This document describes how the concept of URI signing supports the
content access control requirements of CDNI and proposes a URI content access control requirements of CDNI and proposes a URI
signing scheme. signing scheme.
The proposed URI signing method specifies the information needed to The proposed URI signing method specifies the information needed to
be included in the URI and the algorithm used to authorize and to be included in the URI and the algorithm used to authorize and to
validate access requests for the content referenced by the URI. Some validate access requests for the content referenced by the URI. Some
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 17, 2014. This Internet-Draft will expire on March 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Background on URI Signing . . . . . . . . . . . . . . . . 4 1.2. Background on URI Signing . . . . . . . . . . . . . . . . 4
1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6 1.3. CDNI URI Signing Overview . . . . . . . . . . . . . . . . 6
1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8 1.4. URI Signing in a non-CDNI context . . . . . . . . . . . . 8
2. Signed URI Information Elements . . . . . . . . . . . . . . . 8 2. Signed URI Information Elements . . . . . . . . . . . . . . . 8
2.1. Enforcement Information Elements . . . . . . . . . . . . 10 2.1. Enforcement Information Elements . . . . . . . . . . . . 10
2.2. Signature Computation Information Elements . . . . . . . 10 2.2. Signature Computation Information Elements . . . . . . . 11
2.3. URI Signature Information Elements . . . . . . . . . . . 12 2.3. URI Signature Information Elements . . . . . . . . . . . 12
2.4. URI Signing Package Attribute . . . . . . . . . . . . . . 12 2.4. URI Signing Package Attribute . . . . . . . . . . . . . . 13
2.5. User Agent Attributes . . . . . . . . . . . . . . . . . . 13 2.5. User Agent Attributes . . . . . . . . . . . . . . . . . . 14
3. Creating the Signed URI . . . . . . . . . . . . . . . . . . . 14 3. Creating the Signed URI . . . . . . . . . . . . . . . . . . . 14
3.1. Calculating the URI Signature . . . . . . . . . . . . . . 14 3.1. Calculating the URI Signature . . . . . . . . . . . . . . 15
3.2. Packaging the URI Signature . . . . . . . . . . . . . . . 17 3.2. Packaging the URI Signature . . . . . . . . . . . . . . . 18
4. Validating a URI Signature . . . . . . . . . . . . . . . . . 18 4. Validating a URI Signature . . . . . . . . . . . . . . . . . 18
4.1. Information element validation . . . . . . . . . . . . . 18 4.1. Information Element Extraction . . . . . . . . . . . . . 19
4.2. Signature validation . . . . . . . . . . . . . . . . . . 19 4.2. Signature Validation . . . . . . . . . . . . . . . . . . 20
5. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 21 4.3. Distribution Policy Enforcement . . . . . . . . . . . . . 22
5. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 22
5.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 22 5.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 22
5.2. CDNI Footprint & Capabilities Advertisement Interface . . 22 5.2. CDNI Footprint & Capabilities Advertisement Interface . . 23
5.3. CDNI Request Routing Redirection Interface . . . . . . . 22 5.3. CDNI Request Routing Redirection Interface . . . . . . . 23
5.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 23 5.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 24
5.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 24 5.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 27
6. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 24 6. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 28
6.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 24 6.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 28
6.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 27 6.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 30
7. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 30 7. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
10. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Normative References . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of interconnected used to provide access authorization in the case of interconnected
CDNs (CDNI). The primary goal of URI Signing is to make sure that CDNs (CDNI). The primary goal of URI Signing is to make sure that
only authorized User Agents (UAs) are able to access the content, only authorized User Agents (UAs) are able to access the content,
with a Content Service Provider (CSP) being able to authorize every with a Content Service Provider (CSP) being able to authorize every
individual request. It should be noted that URI Signing is not a individual request. It should be noted that URI Signing is not a
content protection scheme; if a CSP wants to protect the content content protection scheme; if a CSP wants to protect the content
skipping to change at page 4, line 20 skipping to change at page 4, line 20
This document also uses the terminology of Keyed-Hashing for Message This document also uses the terminology of Keyed-Hashing for Message
Authentication (HMAC) [RFC2104] including the following terms Authentication (HMAC) [RFC2104] including the following terms
(reproduced here for convenience): (reproduced here for convenience):
o MAC: message authentication code. o MAC: message authentication code.
o HMAC: Hash-based message authentication code (HMAC) is a specific o HMAC: Hash-based message authentication code (HMAC) is a specific
construction for calculating a MAC involving a cryptographic hash construction for calculating a MAC involving a cryptographic hash
function in combination with a secret key. function in combination with a secret key.
o HMAC-SHA1: HMAC instantiation using SHA-1 as the cryptographic o HMAC-SHA256: HMAC instantiation using SHA-256 as the cryptographic
hash function. hash function.
o HMAC-MD5: HMAC instantiation using MD5 as the cryptographic hash o SHA-1: Secure Hash Algorithm 1 (SHA-1) [RFC3174] is the
function. cryptographic hash function.
In addition, the following terms are used throughout this document: In addition, the following terms are used throughout this document:
o URI Signature: Message digest or digital signature that is o URI Signature: Message digest or digital signature that is
computed with an algorithm for protecting the URI. computed with an algorithm for protecting the URI.
o Original URI: The URI before URI Signing is applied. o Original URI: The URI before URI Signing is applied.
o Signed URI: Any URI that contains a URI Signature. o Signed URI: Any URI that contains a URI Signature.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
(either the public or the symmetric key). There are very different (either the public or the symmetric key). There are very different
requirements for key distribution (out of scope of this document) requirements for key distribution (out of scope of this document)
with asymmetric keys and with symmetric keys. Key distribution for with asymmetric keys and with symmetric keys. Key distribution for
symmetric keys requires confidentiality to prevent another party from symmetric keys requires confidentiality to prevent another party from
getting access to the key, since it could then generate valid Signed getting access to the key, since it could then generate valid Signed
URIs for unauthorized requests. Key distribution for asymmetric keys URIs for unauthorized requests. Key distribution for asymmetric keys
does not require confidentiality since public keys can typically be does not require confidentiality since public keys can typically be
distributed openly (because they cannot be used for URI signing) and distributed openly (because they cannot be used for URI signing) and
private keys are kept by the URI signing function. private keys are kept by the URI signing function.
Note that all the URI Signing information elements and the URI query
attribute are mandatory to implement, but not mandatory to use.
2.1. Enforcement Information Elements 2.1. Enforcement Information Elements
This section identifies the set of information elements that may be This section identifies the set of information elements that may be
needed to enforce the CSP distribution policy. New information needed to enforce the CSP distribution policy. New information
elements may be introduced in the future to extend the capabilities elements may be introduced in the future to extend the capabilities
of the distribution policy. of the distribution policy.
In order to provide flexibility in distribution policies to be In order to provide flexibility in distribution policies to be
enforced, the exact subset of information elements used in the URI enforced, the exact subset of information elements used in the URI
Signature of a given request is a deployment decision. The defined Signature of a given request is a deployment decision. The defined
skipping to change at page 14, line 39 skipping to change at page 14, line 47
client performs a fallback to another scheme (e.g. HTTP) for a client performs a fallback to another scheme (e.g. HTTP) for a
content item referenced by a URI with a specific scheme (e.g. RTSP). content item referenced by a URI with a specific scheme (e.g. RTSP).
The benefit is that the content access is protected regardless of the The benefit is that the content access is protected regardless of the
type of transport used for delivery. If the CSP wants to ensure a type of transport used for delivery. If the CSP wants to ensure a
specific protocol is used for content delivery, that information is specific protocol is used for content delivery, that information is
passed by CDNI metadata. Note: Support for changing of the URL passed by CDNI metadata. Note: Support for changing of the URL
scheme requires that the default port is used, or that the protocols scheme requires that the default port is used, or that the protocols
must both run on the same non-standard port. must both run on the same non-standard port.
The process of generating a Signed URI can be divided into two sets The process of generating a Signed URI can be divided into two sets
of steps: calculating the URI Signature and packaging the URI of steps: first, calculating the URI Signature and then, packaging
Signature and appending it to the Original URI. Note it is possible the URI Signature and appending it to the Original URI. Note it is
to use some other algorithm and implementation as long as the same possible to use some other algorithm and implementation as long as
result is achieved. An example for the Original URI, the same result is achieved. An example for the Original URI,
"http://example.com/content.mov", is used to clarify the steps. "http://example.com/content.mov", is used to clarify the steps.
3.1. Calculating the URI Signature 3.1. Calculating the URI Signature
Calculate the URI Signature by following the procedure below. Calculate the URI Signature by following the procedure below.
1. Copy the Original URI, excluding the "scheme name" part, into a 1. Copy the Original URI, excluding the "scheme name" part, into a
buffer to hold the message for performing the operations below. buffer to hold the message for performing the operations below.
2. Check if the URI already contains a query string. If not, append 2. Check if the URI already contains a query string. If not, append
a "?" character. If yes, append an "&" character. a "?" character. If yes, append an "&" character.
3. If the version needs to be specified, then append the string 3. If the version is the default value (i.e. "1"), skip this step.
"VER=1". This represents the version of URI Signing specified by Otherwise, specify the version by appending the string "VER=#",
this document. where '#' represents the new version number. The following steps
in the procedure is based on the initial version of URI Signing
specified by this document. For other versions, reference the
associated RFC for the URI signing procedure.
4. If time window enforcement is not needed, step 4 can be skipped. 4. If time window enforcement is not needed, step 4 can be skipped.
A. Append the string "&ET=". Note in the case of re-signing a A. If an information element was added to the message, append an
URI, the attribute is carried over from the received Signed "&" character. Append the string "ET=". Note in the case of
URI. re-signing a URI, the information element is carried over
from the received Signed URI.
B. Get the current time in seconds since epoch (as an integer). B. Get the current time in seconds since epoch (as an integer).
Add the validity time in seconds as an integer. Note in the Add the validity time in seconds as an integer. Note in the
case of re-signing a URI, the value MUST remain the same as case of re-signing a URI, the value MUST remain the same as
the received Signed URI. the received Signed URI.
C. Convert this integer to a string and append to the message. C. Convert this integer to a string and append to the message.
5. If client IP enforcement is not needed, step 5 can be skipped. 5. If client IP enforcement is not needed, step 5 can be skipped.
A. Append the string "&CIP=". Note in the case of re-signing a A. If an information element was added to the message, append an
URI, the attribute is carried over from the received Signed "&" character. Append the string "CIP=". Note in the case
URI. of re-signing a URI, the attribute is carried over from the
received Signed URI.
B. Convert the client's IP address in dotted decimal notation B. Convert the client's IP address in dotted decimal notation
format (i.e. for IPv4 address) or canonical text format (i.e. for IPv4 address) or canonical text
representation (for IPv6 address [RFC5952]) to a string and representation (for IPv6 address [RFC5952]) to a string and
append to the message. Note in the case of re-signing an append to the message. Note in the case of re-signing an
URI, the value MUST remain the same as the received Signed URI, the value MUST remain the same as the received Signed
URI. URI.
6. Depending on the type of key used to sign the URI, compute the 6. Depending on the type of key used to sign the URI, compute the
message digest or digital signature for symmetric key or message digest or digital signature for symmetric key or
asymmetric keys, respectively. asymmetric keys, respectively.
A. For symmetric key, HMAC is used. A. For symmetric key, HMAC is used.
1. Obtain the shared key to be used for signing the URI. 1. Obtain the shared key to be used for signing the URI.
2. If the key identifier is not needed, skip this step. 2. If the key identifier is not needed, skip this step. If
Append the string "&KID=". Append the key identifier an information element was added to the message, append
(e.g. "example:keys:123") needed by the entity to locate an "&" character. Append the string "KID=". Append the
the shared key for validating the URI signature. key identifier (e.g. "example:keys:123") needed by the
entity to locate the shared key for validating the URI
signature.
3. Optional: If the hash function for the HMAC uses the 3. Optional: If the hash function for the HMAC uses the
default value ("SHA-256"), skip this step. Append the default value ("SHA-256"), skip this step. If an
string "&HF=". Append the string for the type of hash information element was added to the message, append an
function (e.g. "MD5", "SHA-1") to be used. Note that "&" character. append the string "HF=". Append the
re-signing a URI MUST use the same hash function as the string for the new type of hash function to be used.
received Signed URI or one of the allowable hash Note that re-signing a URI MUST use the same hash
functions designated by the CDNI metadata. function as the received Signed URI or one of the
allowable hash functions designated by the CDNI metadata.
4. Append the string "&MD=". The message now contains the 4. If an information element was added to the message,
complete section of the URI that is protected (e.g. append an "&" character. Append the string "MD=". The
"://example.com/content.mov?VER=1&ET=1209422976&CIP=192.0 message now contains the complete section of the URI that
.2.1&KID=example:keys:123&MD="). is protected (e.g. "://example.com/content.mov?ET=120942
2976&CIP=192.0.2.1&KID=example:keys:123&MD=").
5. Compute the message digest using the HMAC algorithm and 5. Compute the message digest using the HMAC algorithm and
the default SHA-256 hash function, or another hash the default SHA-256 hash function, or another hash
function if specified by the HF Information Element, with function if specified by the HF Information Element, with
the shared key and message as the two inputs to the hash the shared key and message as the two inputs to the hash
function. function.
6. Convert the message digest to its equivalent hexadecimal 6. Convert the message digest to its equivalent hexadecimal
format. format.
7. Append the string for the message digest (e.g. 7. Append the string for the message digest (e.g.
"://example.com/content.mov?VER=1&ET=1209422976&CIP=192.0 "://example.com/content.mov?ET=1209422976&CIP=192.0.2.1&K
.2.1&KID=example:keys:123&MD=1ecb1446a6431352aab0fb6e0dca ID=example:keys:123&MD=1ecb1446a6431352aab0fb6e0dca30e303
30e30356593a97acb972202120dc482bddaf"). 56593a97acb972202120dc482bddaf").
B. For asymmetric keys, EC DSA is used. B. For asymmetric keys, EC DSA is used.
1. Generate the EC private and public key pair. Store the 1. Generate the EC private and public key pair. Store the
EC public key in a location that's reachable for any EC public key in a location that's reachable for any
entity that needs to validate the URI signature. entity that needs to validate the URI signature.
2. If the key identifier is not needed, skip this step. 2. If the key identifier is not needed, skip this step. If
Append the string "&KID=". Append the key identifier an information element was added to the message, append
(e.g. "http://example.com/public/keys/123") needed by the an "&" character. Append the string "KID=". Append the
entity to locate the shared key for validating the URI key identifier (e.g. "http://example.com/public/
signature. Note the Key ID URI contains only the "scheme keys/123") needed by the entity to locate the shared key
name", "authority", and "path" parts (i.e. query string for validating the URI signature. Note the Key ID URI
is not allowed). contains only the "scheme name", "authority", and "path"
parts (i.e. query string is not allowed).
3. Optional: If the digital signature algorithm uses the 3. Optional: If the digital signature algorithm uses the
default value ("EC-DSA"), skip this step. Append the default value ("EC-DSA"), skip this step. If an
string "&DSA=". Append the string denoting the digital information element was added to the message, append an
signature function used (e.g. "RSA"). "&" character. Append the string "DSA=". Append the
string denoting the new digital signature function.
4. Append the string "&DS=". The message now contains the 4. If an information element was added to the message,
complete section of the URI that is protected. (e.g. append an "&" character. Append the string "DS=". The
"://example.com/content.mov?VER=1&ET=1209422976&CIP=192.0 message now contains the complete section of the URI that
.2.1&KID=http://example.com/public/keys/123&DS="). is protected. (e.g. "://example.com/content.mov?ET=12094
22976&CIP=192.0.2.1&KID=http://example.com/public/
keys/123&DS=").
5. Compute the message digest using SHA-1 (without a key) 5. Compute the message digest using SHA-1 (without a key)
for the message. Note: The reason the digital signature for the message. Note: The digital signature generated
calculated in the next step is calculated over the SHA-1 in the next step is calculated over the SHA-1 message
message digest, instead of over the cleartype message, is digest, instead of over the cleartype message, to reduce
to reduce the length of the digital signature, and the length of the digital signature, and thereby the
thereby the length of the URI Signing Package Attribute length of the URI Signing Package Attribute and the
and the resulting Signed URI. Since SHA-1 is not used resulting Signed URI. Since SHA-1 is not used for
for cryptographic purposes here, the security concerns cryptographic purposes here, the security concerns around
around SHA-1 do not apply. SHA-1 do not apply.
6. Compute the digital signature, using the EC-DSA algorithm 6. Compute the digital signature, using the EC-DSA algorithm
by default or another algorithm if specified by the DSA by default or another algorithm if specified by the DSA
Information Element, with the private EC key and message Information Element, with the private EC key and message
digest (obtained in previous step) as inputs. digest (obtained in previous step) as inputs.
7. Convert the digital signature to its equivalent 7. Convert the digital signature to its equivalent
hexadecimal format. hexadecimal format.
8. Append the string for the digital signature. In the case 8. Append the string for the digital signature. In the case
where EC-DSA algorithm is used, this string contains the where EC-DSA algorithm is used, this string contains the
values for the 'r' and 's' parameters, delimited by ':' values for the 'r' and 's' parameters, delimited by ':'
(e.g. "://example.com/content.mov?VER=1&ET=1209422976&CI (e.g. "://example.com/content.mov?ET=1209422976&CIP=192.
P=192.0.2.1&KID=http://example.com/public/keys/123&DS=r:C 0.2.1&KID=http://example.com/public/keys/123&DS=r:CFB03ED
FB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E0 B33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D
05668D:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA7 :s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A9
1331A929A29EA24E" ) 29A29EA24E" )
3.2. Packaging the URI Signature 3.2. Packaging the URI Signature
Apply the URI Signing Package Attribute by following the procedure Apply the URI Signing Package Attribute by following the procedure
below to generate the Signed URI. below to generate the Signed URI.
1. Remove the Original URI portion from the message to obtain all 1. Remove the Original URI portion from the message to obtain all
the URI Signing Information Elements, including the URI signature the URI Signing Information Elements, including the URI signature
(e.g. "VER=1&ET=1209422976&CIP=192.0.2.1&KID=example:keys:123&MD (e.g. "ET=1209422976&CIP=192.0.2.1&KID=example:keys:123&MD=1ecb1
=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc482bddaf 446a6431352aab0fb6e0dca30e30356593a97acb972202120dc482bddaf").
").
2. Compute the URI Signing Package Attribute using Base-64 Data 2. Compute the URI Signing Package Attribute using Base-64 Data
Encoding [RFC4648] on the message (e.g. "VkVSPTEmRVQ9MTIwOTQyMjk Encoding [RFC4648] on the message (e.g. "VkVSPTEmRVQ9MTIwOTQyMjk
3NiZDSVA9MTkyLjAuMi4xJktJRD1leGFtcGxlOmtleXM6MTIzJk1EPTFlY2IxNDQ2 3NiZDSVA9MTkyLjAuMi4xJktJRD1leGFtcGxlOmtleXM6MTIzJk1EPTFlY2IxNDQ2
YTY0MzEzNTJhYWIwZmI2ZTBkY2EzMGUzMDM1NjU5M2E5N2FjYjk3MjIwMjEyMGRjN YTY0MzEzNTJhYWIwZmI2ZTBkY2EzMGUzMDM1NjU5M2E5N2FjYjk3MjIwMjEyMGRjN
DgyYmRkYWY="). Note: This is the value for the URI Signing DgyYmRkYWY="). Note: This is the value for the URI Signing
Package Attribute. Package Attribute.
3. Copy the entire Original URI into a buffer to hold the message. 3. Copy the entire Original URI into a buffer to hold the message.
skipping to change at page 18, line 23 skipping to change at page 18, line 42
the string "SIG=" to the message. the string "SIG=" to the message.
6. Append the URI Signing token to the message (e.g. 6. Append the URI Signing token to the message (e.g.
"http://example.com/content.mov?URISigningPackage=VkVSPTEmRVQ9MTI "http://example.com/content.mov?URISigningPackage=VkVSPTEmRVQ9MTI
wOTQyMjk3NiZDSVA9MTkyLjAuMi4xJktJRD1leGFtcGxlOmtleXM6MTIzJk1EPTFl wOTQyMjk3NiZDSVA9MTkyLjAuMi4xJktJRD1leGFtcGxlOmtleXM6MTIzJk1EPTFl
Y2IxNDQ2YTY0MzEzNTJhYWIwZmI2ZTBkY2EzMGUzMDM1NjU5M2E5N2FjYjk3MjIwM Y2IxNDQ2YTY0MzEzNTJhYWIwZmI2ZTBkY2EzMGUzMDM1NjU5M2E5N2FjYjk3MjIwM
jEyMGRjNDgyYmRkYWY="). Note: this is the completed Signed URI. jEyMGRjNDgyYmRkYWY="). Note: this is the completed Signed URI.
4. Validating a URI Signature 4. Validating a URI Signature
The process of validating a Signed URI can be divided into two sets The process of validating a Signed URI can be divided into three sets
of steps: validation of the information elements embedded in the of steps: first, extraction of the URI Signing information elements,
Signed URI and validation of the URI Signature. Note it is possible then validation of the URI signature to ensure the integrity of the
to use some other algorithm and implementation as long as the same Signed URI, and finally, validation of the information elements to
result is achieved. ensure proper enforcement of the distribution policy. The integrity
of the Signed URI is confirmed before distribution policy enforcement
because validation procedure would detect the right event when the
URI is tampered with. Note it is possible to use some other
algorithm and implementation as long as the same result is achieved.
4.1. Information element validation 4.1. Information Element Extraction
Extract and validate the information elements embedded in the URI. Extract the information elements embedded in the URI. Note that some
Note that some steps are to be skipped if the corresponding URI steps are to be skipped if the corresponding URI Signing information
Signing Information Element is not embedded in the Signed URI. The elements are not embedded in the Signed URI.
absence of a given Enforcement Information Element indicates
enforcement of its purpose is not necessary in the CSP's distribution
policy.
1. Extract the value from 'URISigningPackage' attribute. This value 1. Extract the value from 'URISigningPackage' attribute. This
is the encoded URI Signing Package Attribute. If there are value is the encoded URI Signing Package Attribute. If there
multiple instances of this attribute, the first one is used and are multiple instances of this attribute, the first one is used
the remaining ones are ignored. This ensures that the Signed URI and the remaining ones are ignored. This ensures that the
can be validated despite a client appending another instance of Signed URI can be validated despite a client appending another
the 'URISigningPackage' attribute. instance of the 'URISigningPackage' attribute.
2. Decode the string using Base-64 Data Encoding [RFC4648] (or 2. Decode the string using Base-64 Data Encoding [RFC4648] to
another encoding method specified by configuration or CDNI obtain all the URI Signing information elements (e.g. "ET=12094
metadata) to obtain all the URI Signing Information Elements 22976&CIP=192.0.2.1&KID=example:keys:123&MD=1ecb1446a6431352aab0
(e.g. "VER=1&ET=1209422976&CIP=192.0.2.1&KID=example:keys:123&MD fb6e0dca30e30356593a97acb972202120dc482bddaf").
=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc482bddaf
").
3. Extract the value from "VER" if the information element exists in 3. Extract the value from "VER" if the information element exists
the query string. Determine the version of the URI Signing in the query string. Determine the version of the URI Signing
algorithm used to process the Signed URI. If the CDNI Metadata algorithm used to process the Signed URI. If the CDNI Metadata
interface is used, check to see if the used version of the URI interface is used, check to see if the used version of the URI
Signing algorithm is among the allowed set of URI Signing Signing algorithm is among the allowed set of URI Signing
versions specified by the metadata. If this is not the case, the versions specified by the metadata. If this is not the case,
request is denied. If the attribute is not in the URI, then the request is denied. If the information element is not in the
obtain the version number in another manner (e.g. configuration, URI, then obtain the version number in another manner (e.g.
CDNI metadata or default value). configuration, CDNI metadata or default value).
4. Extract the value from "CIP" if the information element exists in 4. Extract the value from "MD" if the information element exists in
the query string. Validate that the request came from the same the query string. The existence of this information element
IP address as indicated in the "CIP" attribute. If the IP indicates a symmetric key is used.
address is incorrect, then the request is denied.
5. Extract the value from "ET" if the information element exists in 5. Extract the value from "DS" if the information element exists in
the query string. Validate that the request arrived before the query string. The existence of this information element
expiration time based on the "ET" attribute. If the time indicates an asymmetric key is used.
expired, then the request is denied.
6. Extract the value from "MD" if the information element exists in 6. If neither "MD" or "DS" attribute is in the URI, then no URI
the query string. The existence of this information element Signature exists and the request is denied. If both the "MD"
indicates a symmetric key is used. and the "DS" information elements are present, the Signed URI is
considered to be malformed and the request is denied.
7. Extract the value from "DS" if the information element exists in 7. Extract the value from "CIP" if the information element exists
the query string. The existence of this information element in the query string. The existence of this information element
indicates a asymmetric key is used. indicates content delivery is enforced based on client IP
address.
8. If neither "MD" or "DS" attribute is in the URI, then no URI 8. Extract the value from "ET" if the information element exists in
Signature exists and the request is denied. If both the "MD" and the query string. The existence of this information element
the "DS" information elements are present, the Signed URI is indicates content delivery is enforced based on time.
considered to be malformed and the request is denied.
4.2. Signature validation 9. Extract the value from the "KID" information element, if it
exists. The existence of this information element indicates a
key can be referenced.
10. Extract the value from the "HF" information element, if it
exists. The existence of this information element indicates a
different hash function than the default.
11. Extract the value from the "DSA" information element, if it
exists. The existence of this information element indicates a
different digital signature algorithm than the default.
4.2. Signature Validation
Validate the URI Signature for the Signed URI. Validate the URI Signature for the Signed URI.
1. Copy the Original URI, excluding the "scheme name" part, into a 1. Copy the Original URI, excluding the "scheme name" part, into a
buffer to hold the message for performing the operations below. buffer to hold the message for performing the operations below.
2. Remove the "URISigningPackage" attribute from the message. 2. Remove the "URISigningPackage" attribute from the message.
Remove any subsequent part of the query string after the Remove any subsequent part of the query string after the
"URISigningPackage" attribute. "URISigningPackage" attribute.
3. Append the decoded value from "URISigningPackage" attribute 3. Append the decoded value from "URISigningPackage" attribute
(which contains all the URI Signing Information Elements). (which contains all the URI Signing Information Elements).
4. Depending on the type of key used to sign the URI, validate the 4. Depending on the type of key used to sign the URI, validate the
message digest or digital signature for symmetric key or message digest or digital signature for symmetric key or
asymmetric keys, respectively. asymmetric keys, respectively.
A. For symmetric key, HMAC algorithm is used. A. For symmetric key, HMAC algorithm is used.
a. Extract the value from the "KID" information element, if a. If "KID" information element exists, validate that the
it exists. Use the key identifier (e.g. key identifier is in the allowable KID set as listed in
"example:keys:123") to locate the shared key, which may the CDNI metadata or configuration. The request is
be one of the keys available to use (i.e. set by denied when the key identifier is not allowed.
configuration or CDNI metadata). If the information Otherwise, the "KID" information element is not in the
element is not in the URI Signing Package Attribute, then Signed URI. In this case, obtain the shared key via CDNI
obtain the key in another manner (e.g. configuration or metadata or configuration.
CDNI metadata). If the "KID" information element is
present but its value is not in the allowable KID set as
listed in the CDNI metadata, the request is denied.
b. Extract the value from the "HF" information element, if b. If "HF" information element exists, validate that the
it exists. Determine the type of hash function (e.g. hash function is in the allowable "HF" set as listed in
"MD5", "SHA-1", "SHA-512") to use for HMAC. If the the CDNI metadata or configuration. The request is
information element is not in the URI, the default hash denied when the hash function is not allowed. Otherwise,
function is SHA-256. If the "HF" information element is the "HF" information element is not in the Signed URI.
present but its value is not in the the allowable "HF" In this case, the default hash function is SHA-256.
set as listed in the CDNI metadata, the request is
denied.
c. Extract the value from the "MD" information element. c. Extract the value from the "MD" information element.
This is the received message digest. This is the received message digest.
d. Convert the message digest to binary format. This will d. Convert the message digest to binary format. This will
be used to compare with the computed value later. be used to compare with the computed value later.
e. Remove the value part of the "MD" information element e. Remove the value part of the "MD" information element
(but not the '=' character) from the message. The (but not the '=' character) from the message. The
message is ready for validation of the message digest message is ready for validation of the message digest
(e.g. "://example.com/content.mov?VER=1&ET=1209422976&CI (e.g. "://example.com/content.mov?ET=1209422976&CIP=192.
P=192.0.2.1&KID=example:keys:123&MD="). 0.2.1&KID=example:keys:123&MD=").
f. Compute the message digest using the HMAC algorithm with f. Compute the message digest using the HMAC algorithm with
the shared key and message as the two inputs to the hash the shared key and message as the two inputs to the hash
function. function.
g. Compare the result with the received message digest to g. Compare the result with the received message digest to
validate the Signed URI. validate the Signed URI.
B. For asymmetric keys, a digital signature function is used. B. For asymmetric keys, a digital signature function is used.
a. Extract the value from the "KID" information element, if a. If "KID" information element exists, validate that the
it exists. Use the key identifier (e.g. key identifier is in the allowable KID set as listed in
"http://example.com/public/keys/123") to obtain the EC the CDNI metadata or configuration. The request is
public key, which may be one of the keys available to use denied when the key identifier is not allowed.
(i.e. set by configuration or CDNI metadata). If the Otherwise, the "KID" information element is not in the
information element is not in the URI, then obtain the Signed URI. In this case, obtain the public key via CDNI
key in another manner (e.g. configuration or CDNI metadata or configuration.
metadata).
b. Extract the value from the "DSA" information element, if b. If "DSA" information element exists, validate that the
it exists. Determine the type of digital signature digital signature algorithm is in the allowable "DSA" set
function (e.g. "RSA", "DSA") to use for calculating the as listed in the CDNI metadata or configuration. The
Digital Signature. If the information element is not in request is denied when the DSA is not allowed.
the URI, the default digital signature function is EC- Otherwise, the "DSA" information element is not in the
DSA. If the "DSA" information element is present but its Signed URI. In this case, the default DSA is EC-DSA.
value is not in the the allowable "DSA" set as listed in
the CDNI metadata, the request is denied.
c. Extract the value from the "DS" information element. c. Extract the value from the "DS" information element.
This is the digital signature. This is the digital signature.
d. Convert the digital signature to binary format. This d. Convert the digital signature to binary format. This
will be used for verification later. will be used for verification later.
e. Remove the value part of the "DS" information element e. Remove the value part of the "DS" information element
(but not the '=' character) from the message. The (but not the '=' character) from the message. The
message is ready for validation of the digital signature message is ready for validation of the digital signature
(e.g. "://example.com/content.mov?VER=1&ET=1209422976&CI (e.g. "://example.com/content.mov?ET=1209422976&CIP=192.
P=192.0.2.1&KID=http://example.com/public/keys/123&DS="). 0.2.1&KID=http://example.com/public/keys/123&DS=").
f. Compute the message digest using SHA-1 (without a key) f. Compute the message digest using SHA-1 (without a key)
for the message. for the message.
g. Verify the digital signature using the digital signature g. Verify the digital signature using the digital signature
function (e.g. EC-DSA) with the public key, received function (e.g. EC-DSA) with the public key, received
digital signature, and message digest (obtained in digital signature, and message digest (obtained in
previous step) as inputs. This validates the Signed URI. previous step) as inputs. This validates the Signed URI.
4.3. Distribution Policy Enforcement
Note the steps are to be skipped if the corresponding URI Signing
information elements are not in the Signed URI. The absence of a
given Enforcement Information Element indicates enforcement of its
purpose is not necessary in the CSP's distribution policy.
1. If the "CIP" information element exists, validate that the
request came from the same IP address as indicated in the "CIP"
information element. If the IP address is incorrect, then the
request is denied.
2. If the "ET" information element exists, validate that the request
arrived before expiration time based on the "ET" information
element. If the time expired, then the request is denied.
5. Relationship with CDNI Interfaces 5. Relationship with CDNI Interfaces
Some of the CDNI Interfaces need enhancements to support URI Signing. Some of the CDNI Interfaces need enhancements to support URI Signing.
As an example: A Downstream CDN that supports URI Signing needs to be As an example: A Downstream CDN that supports URI Signing needs to be
able to advertise this capability to the Upstream CDN. The Upstream able to advertise this capability to the Upstream CDN. The Upstream
CDN needs to select a Downstream CDN based on such capability when CDN needs to select a Downstream CDN based on such capability when
the CSP requires access control to enforce its distribution policy the CSP requires access control to enforce its distribution policy
via URI Signing. Also, the Upstream CDN needs to be able to via URI Signing. Also, the Upstream CDN needs to be able to
distribute via the CDNI Metadata interface the information necessary distribute via the CDNI Metadata interface the information necessary
to allow the Downstream CDN to validate a Signed URI . Events that to allow the Downstream CDN to validate a Signed URI . Events that
skipping to change at page 22, line 20 skipping to change at page 23, line 12
URI Signing has no impact on this interface. URI Signing has no impact on this interface.
5.2. CDNI Footprint & Capabilities Advertisement Interface 5.2. CDNI Footprint & Capabilities Advertisement Interface
The Downstream CDN advertises its capability to support URI Signing The Downstream CDN advertises its capability to support URI Signing
via the CDNI Footprint & Capabilities Advertisement interface (FCI). via the CDNI Footprint & Capabilities Advertisement interface (FCI).
The supported version of URI Signing needs to be included to allow The supported version of URI Signing needs to be included to allow
for future extensibility. for future extensibility.
[Editor's Note: To be discussed with FCI authors] In general, new information elements introduced to enhance URI
Signing requires a draft and a new version. ForInformation Elements,
5.3. CDNI Request Routing Redirection Interface For Enforcement Information Elements, there is no need to
advertise the based information elements such as "CIP" and "ET".
[Editor's Note: Debate the approach of dCDN providing the Signed URI For Signature Computation Information Elements:
vs. uCDN performing the signing function. List the pros/cons of each
approach for the CDNI Request Routing Redirection interface (RI).
Offer recommendation?]
The two approaches: No need to advertise "VER" Information Element unless it's not
"1". In this case, a draft is needed to describe the new
version.
1. Downstream CDN provides the Signed URI Advertise value of the "HF" Information Element (i.e. SHA-256)
to indicate support for the hash function; Need IANA assignment
for new hash function.
* Key distribution is not necessary Advertise value of the "DSA" Information Element (i.e. EC-DSA)
to indicate support for the DSA; Need IANA assignment for new
digital signature algorithm.
* Downstream CDN can use any scheme for Signed URI as long as Advertise "MD" Information Element (i.e. EC-DSA) to indicate
the security level meets the CSP's expectation support for symmetric key method; A new draft is needed for an
alternative method.
2. Upstream CDN signs the URI Advertise "DS" Information Element (i.e. EC-DSA) to indicate
support for asymmetric key method; A new draft is needed for an
alternative method.
* Consistency with interative request routing method For URI Signing Package Attribute, there is no need to advertise
the base attribute.
* URI Signing works even when Downstream CDN does not have the 5.3. CDNI Request Routing Redirection Interface
signing function (which may be the case when the Downstream
CDN operates only as a delivering CDN)
* Upstream CDN can act as a conversion gateway for the The CDNI Request Routing Redirection Interface
requesting routing interface between Upstream CDN and CSP and [I-D.ietf-cdni-redirection] describes the recursive request
request routing interface between Upstream CDN and Downstream redirection method. For URI Signing, the Upstream CDN signs the URI
CDN since these two interfaces may not be the same provided by the Downstream CDN. This approach has the following
benefits:
Consistency with interative request routing method
URI Signing is fully operational even when Downstream CDN does not
have the signing function (which may be the case when the
Downstream CDN operates only as a delivering CDN)
Upstream CDN can act as a conversion gateway for the requesting
routing interface between Upstream CDN and CSP and request routing
interface between Upstream CDN and Downstream CDN since these two
interfaces may not be the same
5.4. CDNI Metadata Interface 5.4. CDNI Metadata Interface
The following CDNI Metadata objects are specified for URI Signing. The CDNI Metadata Interface [I-D.ietf-cdni-metadata] describes the
CDNI metadata distribution in order to enable content acquisition and
delivery. For URI Signing, additional CDNI metadata objects are
specified. In general, an Empty set means "all". These are the CDNI
metadata objects used for URI Signing.
o URI Signing enforcement flag. Specifically, this flag indicates The UriSigning Metadata object contains information to enable URI
if the access to content is subject to URI Signing. URI Signing signing and validation by a dCDN. The UriSigning properties are
requires the Downstream CDN to ensure that the URI must be signed defined below.
and validated before content delivery. Otherwise, Downstream CDN
does not perform validation regardless if URI is signed or not.
o Designated key identifier used for URI Signing computation when Property: enforce
the Signed URI does not contain the Key ID information element
o Allowable Key ID set that the Signed URI's Key ID information Description: URI Signing enforcement flag. Specifically, this
element can reference flag indicates if the access to content is subject to URI
Signing. URI Signing requires the Downstream CDN to ensure
that the URI must be signed and validated before content
delivery. Otherwise, Downstream CDN does not perform
validation regardless if URI is signed or not.
o Designated hash function used for URI Signing computation when the Type: Boolean
Signed URI does not contain the Hash Function information element
o Allowable Hash Function set that the Signed URI's Hash Function Mandatory-to-Specify: No. If a UriSigning object is present in
information element can reference the metadata for a piece of content (even if the object is
empty), then URI signing should be enforced. If no UriSigning
object is present in the metadata for a piece of content, then
the URI signature should not be validated.
o Designated digital signature function used for URI Signing Property: key-id
computation when the Signed URI does not contain the Digital
Signature Algorithm information element.
o Allowable digital signature function set that the Signed URI's Description: Designated key identifier used for URI Signing
Digital Signature Algorithm information element can reference. computation when the Signed URI does not contain the Key ID
information element.
o Designated version used for URI Signing computation when the Type: String
Signed URI does not contain the VER attribute
o Allowable version/algorithm set that the Signed URI's VER Mandatory-to-Specify: No. A Key ID is not essential for all
attribute can reference implementations of URI signing.
o Allowable set of Downstream CDNs that participate in URI Signing Property: key-id-set
based on the symmetric key
o Overwrite the default name for the URL Signing Package Attribute Description: Allowable Key ID set that the Signed URI's Key ID
information element can reference.
Note that the Key ID information is not needed if only one key is Type: List of Strings
provided by the CSP or the Upstream CDN for the content item or set
of content items covered by the CDNI Metadata object. In the case of Mandatory-to-Specify: No. Default is to allow any Key ID.
asymmetric keys, it's easy for any entity to sign the URI for content [Editor's note: security issue with default to allow any? Easy
with a private key and provide the public key in the Signed URI. for bad guy to put their own key ID in URI. The default should
This just confirms that the URI Signer authorized the delivery. But be key ID must be in the set or configuration?]
it's necessary for the URI Signer to be the content owner. So, the
CDNI Metadata interface MUST provide the public key for the content Property: hash-function
or information to authorize the received Key ID attribute.
Description: Designated hash function used for URI Signing
computation when the Signed URI does not contain the Hash
Function information element.
Type: String (limited to the hash function strings in the
registry defined by the IANA Considerations (Section 8)
section)
Mandatory-to-Specify: No. Default is SHA-256.
Property: hash-function-set
Description: Allowable Hash Function set that the Signed URI's
Hash Function information element can reference.
Type: List of Strings
Mandatory-to-Specify: No. Default is to allow any hash
function.
Property: digital-signature-algorithm
Description: Designated digital signature function used for URI
Signing computation when the Signed URI does not contain the
Digital Signature Algorithm information element.
Type: String (limited to the digital signature algorithm
strings in the registry defined by the IANA Considerations
(Section 8) section).
Mandatory-to-Specify: No. Default is EC-DSA.
Property: digital-signature-algorithm-set
Description: Allowable digital signature function set that the
Signed URI's Digital Signature Algorithm information element
can reference.
Type: List of Strings
Mandatory-to-Specify: No. Default is to allow any DSA.
Property: version
Description: Designated version used for URI Signing
computation when the Signed URI does not contain the VER
attribute.
Type: Integer
Mandatory-to-Specify: No. Default is 1.
Property: version-set
Description: Allowable version set that the Signed URI's VER
attribute can reference.
Type: List of Integers
Mandatory-to-Specify: No. Default is to allow any version.
Property: package-attribute
Description: Overwrite the default name for the URL Signing
Package Attribute.
Type: String
Mandatory-to-Specify: No. Default is "URISigningPackage".
Note that the Key ID information element is not needed if only one
key is provided by the CSP or the Upstream CDN for the content item
or set of content items covered by the CDNI Metadata object. In the
case of asymmetric keys, it's easy for any entity to sign the URI for
content with a private key and provide the public key in the Signed
URI. This just confirms that the URI Signer authorized the delivery.
But it's necessary for the URI Signer to be the content owner. So,
the CDNI Metadata interface or configuration MUST provide the
allowable Key ID set to authorize the Key ID information element
embedded in teh Signed URI.
5.5. CDNI Logging Interface 5.5. CDNI Logging Interface
The Downstream CDN reports that enforcement of the access control was For URI Signing, the Downstream CDN reports that enforcement of the
applied to the request for content delivery. access control was applied to the request for content delivery. When
the request is denied due to enforcement of URI Signing, the reason
is logged.
The following CDNI Logging field for URI Signing SHOULD be supported The following CDNI Logging field for URI Signing SHOULD be supported
in the HTTP Request Logging Record as specified in CDNI Logging in the HTTP Request Logging Record as specified in CDNI Logging
Interface [I-D.ietf-cdni-logging]. Interface [I-D.ietf-cdni-logging].
o s-uri-signing: o s-uri-signing (mandatory):
* format: 1DIGIT * format: 3DIGIT
* field value: this characterises the uri signing validation * field value: this characterises the uri signing validation
performed by the Surrogate on the request. The allowed values performed by the Surrogate on the request. The allowed values
are: are:
+ "0" : no uri signature validation performed + "0" : no uri signature validation performed
+ "1" : uri signature validation performed and validated + "1" : uri signature validation performed and validated
+ "2" : uri signature validation performed and rejected + "2" : uri signature validation performed and rejected
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
field. field.
[Editor's note: Need to log these URI signature validation events o s-uri-signing-deny-reason (optional):
(e.g. invalid client IP address, expired signed URI, incorrect URI
signature, successful validation)?]
TBD: CDNI Logging interface is work in progress. * format: QSTRING
* field value: the rejection reason when uri signature performed
by the Surrogate on the request. Examples:
+ "invalid client IP address"
+ "expired signed URI"
+ "incorrect URI signature"
* occurrence: there MUST be zero or exactly one instance of this
field.
6. URI Signing Message Flow 6. URI Signing Message Flow
URI Signing supports both HTTP-based and DNS-based request routing. URI Signing supports both HTTP-based and DNS-based request routing.
HMAC [RFC2104] defines a hash-based message authentication code HMAC [RFC2104] defines a hash-based message authentication code
allowing two parties that share a symmetric key or asymmetric keys to allowing two parties that share a symmetric key or asymmetric keys to
establish the integrity and authenticity of a set of information establish the integrity and authenticity of a set of information
(e.g. a message) through a cryptographic hash function. (e.g. a message) through a cryptographic hash function.
6.1. HTTP Redirection 6.1. HTTP Redirection
skipping to change at page 30, line 30 skipping to change at page 33, line 46
multiple CDNI hops including non-adjacent hops. This raises a multiple CDNI hops including non-adjacent hops. This raises a
security concern for applicability of URI Signing with symmetric keys security concern for applicability of URI Signing with symmetric keys
in case of DNS-based inter-CDN request routing. in case of DNS-based inter-CDN request routing.
7. HTTP Adaptive Streaming 7. HTTP Adaptive Streaming
The authors note that in order to perform URI signing for individual The authors note that in order to perform URI signing for individual
content segments of HTTP Adaptive Bitrate content, specific URI content segments of HTTP Adaptive Bitrate content, specific URI
signing mechanisms are needed. Such mechanisms are currently out-of- signing mechanisms are needed. Such mechanisms are currently out-of-
scope of this document. More details on this topic is covered in scope of this document. More details on this topic is covered in
Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983]. [Editor
note: DASH draft discussion]
8. IANA Considerations 8. IANA Considerations
[Editor's note: (Is there a need to) register default value for URI [Editor's note: (Is there a need to) register default value for URI
Signing Package Attribute URI query string parameter name (i.e. Signing Package Attribute URI query string parameter name (i.e.
URISigningPackage) to be used for URI Signing? Need anything from URISigningPackage) to be used for URI Signing? Need anything from
IANA?] IANA?]
[Editor's note: To do: Convert to proper IANA Registry format] [Editor's note: To do: Convert to proper IANA Registry format]
This document requests IANA to create three new registries for the This document requests IANA to create three new URI Signing
Information Elements and their defined values to be used for URI registries for the Information Elements and their defined values to
Signing. be used for URI Signing.
The following Enforcement Information Element names are allocated: The following Enforcement Information Element names are allocated:
o ET (Expiry time) o ET (Expiry time)
o CIP (Client IP address) o CIP (Client IP address)
The following Signature Computation Information Element names are The following Signature Computation Information Element names are
allocated: allocated:
o VER (Version): 1(Base) o VER (Version): 1 (Base)
o KID (Key ID) o KID (Key ID)
o HF (Hash Function): "MD5", "SHA-1", "SHA-256", "SHA-3" o HF (Hash Function): "SHA-256"
o DSA (Digital Signature Algorithm): "RSA, "DSA", "EC-DSA" o DSA (Digital Signature Algorithm): "EC-DSA"
The following URI Signature Information Element names are allocated: The following URI Signature Information Element names are allocated:
o MD (Message Digest) o MD (Message Digest for Symmetric Key)
o DS (Digital Signature) o DS (Digital Signature for Asymmetric Keys)
The IANA is requested to allocate a new entry to the CDNI Logging The IANA is requested to allocate a new entry to the CDNI Logging
Field Names Registry as specified in CDNI Logging Interface Field Names Registry as specified in CDNI Logging Interface
[I-D.ietf-cdni-logging] in accordance to the "Specification Required" [I-D.ietf-cdni-logging] in accordance to the "Specification Required"
policy [RFC5226] policy [RFC5226]
o s-url-signing o s-url-signing
The IANA is requested to allocate a new entry to the CDNI Metadata o s-url-signing-deny-reason
Field Names Registry as specified in CDNI Metadata Interface
[I-D.ietf-cdni-metadata] in accordance to the "Specification
Required" policy [RFC5226]
o URI Signing Package URI query parameter name 1 Token The IANA is requested to allocate a new entry to the "CDNI
GenericMetadata Types" Registry as specified in CDNI Metadata
Interface [I-D.ietf-cdni-metadata] in accordance to the
"Specification Required" policy [RFC5226]:
o More metadata... +------------+---------------+---------+------+------+
| Type name | Specification | Version | MTE | STR |
+------------+---------------+---------+------+------+
| UriSigning | RFCthis | 1 | true | true |
+------------+---------------+---------+------+------+
The IANA is also requested to allocate a new MIME type under the IANA
MIME Media Type registry for the UriSigning metadata object:
application/cdni.UriSigning.v1
9. Security Considerations 9. Security Considerations
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of interconnected used to provide access authorization in the case of interconnected
CDNs (CDNI). The primary goal of URI Signing is to make sure that CDNs (CDNI). The primary goal of URI Signing is to make sure that
only authorized UAs are able to access the content, with a Content only authorized UAs are able to access the content, with a Content
Service Provider (CSP) being able to authorize every individual Service Provider (CSP) being able to authorize every individual
request. It should be noted that URI Signing is not a content request. It should be noted that URI Signing is not a content
protection scheme; if a CSP wants to protect the content itself, protection scheme; if a CSP wants to protect the content itself,
skipping to change at page 32, line 33 skipping to change at page 36, line 17
Illegitimate client behind a NAT: In cases where there are Illegitimate client behind a NAT: In cases where there are
multiple users behind the same NAT, all users will have the same multiple users behind the same NAT, all users will have the same
IP address from the point of view of the Downstream CDN. This IP address from the point of view of the Downstream CDN. This
results in the Downstream CDN not being able to distinguish results in the Downstream CDN not being able to distinguish
between the different users based on Client IP Address and between the different users based on Client IP Address and
illegitimate users being able to access the content. One way to illegitimate users being able to access the content. One way to
reduce exposure to this kind of attack is to not only check for reduce exposure to this kind of attack is to not only check for
Client IP but also for other attributes that can be found in the Client IP but also for other attributes that can be found in the
HTTP headers. HTTP headers.
TBD: ...
The shared key between CSP and Authoritative CDN may be distributed The shared key between CSP and Authoritative CDN may be distributed
to Downstream CDNs - including cascaded CDNs. Since this key can be to Downstream CDNs - including cascaded CDNs. Since this key can be
used to legitimately sign a URL for content access authorization, used to legitimately sign a URL for content access authorization,
it's important to know the implications of a compromised shared key. it's important to know the implications of a compromised shared key.
[Editor's note: Threat model cover in the Security section - Prevent
client from spoofing URI (Ray) - Security implications - The scope of
protection by URI Signing - Protects against DoS (network bandwidth
and other nodes besides the edge cache); limits the time window. ]
10. Privacy 10. Privacy
The privacy protection concerns described in CDNI Logging Interface The privacy protection concerns described in CDNI Logging Interface
[I-D.ietf-cdni-logging] apply when the client's IP address (CIP [I-D.ietf-cdni-logging] apply when the client's IP address (CIP
attribute) is embedded in the Signed URI. This means that, when attribute) is embedded in the Signed URI. This means that, when
anonymization is enabled, the value of the URI Signing Package anonymization is enabled, the value of the URI Signing Package
Attribute MUST be removed from the logging record. Attribute MUST be removed from the logging record.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Scott Leibrand for his contributions The authors would like to thank the following people for their
to this document. In addition, the authors would like to thank the contributions in reviewing this document and providing feedback:
following people for reviewing this document and providing feedback:
Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan
York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar and Iuniana York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar and Iuniana
Oprescu. Oprescu. In addition, Matt Caulfield provided content for the CDNI
Metadata Interface section.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-cdni-logging] [I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R. Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-11 (work in progress), March 2014. logging-13 (work in progress), July 2014.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, September 2012.
12.2. Informative References 12.2. Informative References
[I-D.ietf-cdni-framework] [I-D.ietf-cdni-framework]
Peterson, L., Davie, B., and R. Brandenburg, "Framework Peterson, L., Davie, B., and R. Brandenburg, "Framework
for CDN Interconnection", draft-ietf-cdni-framework-14 for CDN Interconnection", draft-ietf-cdni-framework-14
(work in progress), June 2014. (work in progress), June 2014.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Niven-Jenkins, B., Murray, R., Caulfield, M., Leung, K.,
Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- and K. Ma, "CDN Interconnection Metadata", draft-ietf-
ietf-cdni-metadata-06 (work in progress), February 2014. cdni-metadata-07 (work in progress), July 2014.
[I-D.ietf-cdni-redirection]
Niven-Jenkins, B. and R. Brandenburg, "Request Routing
Redirection Interface for CDN Interconnection", draft-
ietf-cdni-redirection-03 (work in progress), August 2014.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", draft-ietf-cdni- Interconnection (CDNI) Requirements", draft-ietf-cdni-
requirements-17 (work in progress), January 2014. requirements-17 (work in progress), January 2014.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012.
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection (CDNI)", RFC Content Distribution Network Interconnection (CDNI)", RFC
6983, July 2013. 6983, July 2013.
Authors' Addresses Authors' Addresses
Kent Leung Kent Leung
Cisco Systems Cisco Systems
3625 Cisco Way 3625 Cisco Way
skipping to change at page 35, line 21 skipping to change at page 39, line 4
Email: ray.vanbrandenburg@tno.nl Email: ray.vanbrandenburg@tno.nl
Bill Downey Bill Downey
Verizon Labs Verizon Labs
60 Sylvan Road 60 Sylvan Road
Waltham, Massachusetts 02451 Waltham, Massachusetts 02451
USA USA
Phone: +1 781 466 2475 Phone: +1 781 466 2475
Email: william.s.downey@verizon.com Email: william.s.downey@verizon.com
Michel Fisher Michel Fisher
Limelight Networks Limelight Networks
222 S Mill Ave 222 S Mill Ave
Tempe, AZ 85281 Tempe, AZ 85281
USA USA
Phone: +1 360 419 5185
Email: mfisher@llnw.com Email: mfisher@llnw.com
 End of changes. 94 change blocks. 
279 lines changed or deleted 434 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/