draft-ietf-cdni-uri-signing-02.txt   draft-ietf-cdni-uri-signing-03.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: September 27, 2015 R. van Brandenburg Expires: October 16, 2015 R. van Brandenburg
TNO TNO
B. Downey B. Downey
Verizon Labs Verizon Labs
M. Fisher M. Fisher
Limelight Networks Limelight Networks
March 26, 2015 April 14, 2015
URI Signing for CDN Interconnection (CDNI) URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-02 draft-ietf-cdni-uri-signing-03
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 September 27, 2015. This Internet-Draft will expire on October 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 36 skipping to change at page 2, line 36
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 . . . . . . . 11 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 . . . . . . . . . . . . . . 13 2.4. URI Signing Package Attribute . . . . . . . . . . . . . . 13
2.5. User Agent Attributes . . . . . . . . . . . . . . . . . . 14 2.5. User Agent Attributes . . . . . . . . . . . . . . . . . . 14
3. Creating the Signed URI . . . . . . . . . . . . . . . . . . . 14 3. Creating the Signed URI . . . . . . . . . . . . . . . . . . . 14
3.1. Calculating the URI Signature . . . . . . . . . . . . . . 15 3.1. Calculating the URI Signature . . . . . . . . . . . . . . 15
3.2. Packaging the URI Signature . . . . . . . . . . . . . . . 18 3.2. Packaging the URI Signature . . . . . . . . . . . . . . . 18
4. Validating a URI Signature . . . . . . . . . . . . . . . . . 18 4. Validating a URI Signature . . . . . . . . . . . . . . . . . 19
4.1. Information Element Extraction . . . . . . . . . . . . . 19 4.1. Information Element Extraction . . . . . . . . . . . . . 19
4.2. Signature Validation . . . . . . . . . . . . . . . . . . 20 4.2. Signature Validation . . . . . . . . . . . . . . . . . . 20
4.3. Distribution Policy Enforcement . . . . . . . . . . . . . 22 4.3. Distribution Policy Enforcement . . . . . . . . . . . . . 22
5. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 22 5. Relationship with CDNI Interfaces . . . . . . . . . . . . . . 23
5.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 22 5.1. CDNI Control Interface . . . . . . . . . . . . . . . . . 23
5.2. CDNI Footprint & Capabilities Advertisement Interface . . 23 5.2. CDNI Footprint & Capabilities Advertisement Interface . . 23
5.3. CDNI Request Routing Redirection Interface . . . . . . . 23 5.3. CDNI Request Routing Redirection Interface . . . . . . . 24
5.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 24 5.4. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 24
5.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 27 5.5. CDNI Logging Interface . . . . . . . . . . . . . . . . . 27
6. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 28 6. URI Signing Message Flow . . . . . . . . . . . . . . . . . . 28
6.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 28 6.1. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 28
6.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 30 6.2. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 31
7. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 33 7. HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
10. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.1. Normative References . . . . . . . . . . . . . . . . . . 36 12.1. Normative References . . . . . . . . . . . . . . . . . . 37
12.2. Informative References . . . . . . . . . . . . . . . . . 37 12.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 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
itself, other mechanisms, such as DRM, are more appropriate. itself, other mechanisms, such as DRM, are more appropriate.
The overall problem space for CDN Interconnection (CDNI) is described The overall problem space for CDN Interconnection (CDNI) is described
in CDNI Problem Statement [RFC6707]. In this document, along with in CDNI Problem Statement [RFC6707]. In this document, along with
the CDNI Requirements [I-D.ietf-cdni-requirements] document and the the CDNI Requirements [RFC7337] document and the CDNI Framework
CDNI Framework [I-D.ietf-cdni-framework] the need for interconnected [RFC7336] the need for interconnected CDNs to be able to implement an
CDNs to be able to implement an access control mechanism that access control mechanism that enforces the CSP's distribution policy
enforces the CSP's distribution policy is described. is described.
Specifically, CDNI Framework [I-D.ietf-cdni-framework] states: Specifically, CDNI Framework [RFC7336] states:
"The CSP may also trust the CDN operator to perform actions such as "The CSP may also trust the CDN operator to perform actions such as
..., and to enforce per-request authorization performed by the CSP ..., and to enforce per-request authorization performed by the CSP
using techniques such as URI signing." using techniques such as URI signing."
In particular, the following requirement is listed in CDNI In particular, the following requirement is listed in CDNI
Requirements [I-D.ietf-cdni-requirements]: Requirements [RFC7337]:
"MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow "MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow
signaling of authorization checks and validation that are to be signaling of authorization checks and validation that are to be
performed by the surrogate before delivery. For example, this could performed by the surrogate before delivery. For example, this could
potentially include: potentially include:
* need to validate URI signed information (e.g. Expiry time, Client * need to validate URI signed information (e.g. Expiry time, Client
IP address)." IP address)."
This document proposes a URI Signing scheme that allows Surrogates in This document proposes a URI Signing scheme that allows Surrogates in
skipping to change at page 11, line 18 skipping to change at page 11, line 18
needed to verify the URI (signature). New information elements may needed to verify the URI (signature). New information elements may
be introduced in the future if new URI signing algorithms are be introduced in the future if new URI signing algorithms are
developed. developed.
The defined keyword for each information element is specified in The defined keyword for each information element is specified in
parenthesis below. parenthesis below.
The following information elements are used to validate the URI by The following information elements are used to validate the URI by
recreating the URI Signature. recreating the URI Signature.
o Version (VER) [optional] - An integer used for identifying the o Version (VER) [optional] - An 8-bit unsigned integer used for
version of URI signing method. If this Information Element is not identifying the version of URI signing method. If this
present in the URI Signing Package Attribute, the default version Information Element is not present in the URI Signing Package
is 1. Attribute, the default version is 1.
o Key ID (KID) [optiona] - A string used for obtaining the key (e.g. o Key ID (KID) [optional] - A string used for obtaining the key
database lookup, URI reference) which is needed to validate the (e.g. database lookup, URI reference) which is needed to validate
URI signature. the URI signature. The KID and KID_NUM information elements MUST
NOT be present in the same URI Signing Package Attribute.
o Numerical Key ID (KID_NUM) [optional] - A 64-bit unsigned integer
used as an optional alternative for KID. The KID and KID_NUM
information elements MUST NOT be present in the same URI Signing
Package Attribute.
o Hash Function (HF) [optional] - A string used for identifying the o Hash Function (HF) [optional] - A string used for identifying the
hash function to compute the URI signature with HMAC. If this hash function to compute the URI signature with HMAC. If this
Information Element is not present in the URI Signing Package Information Element is not present in the URI Signing Package
Attribute, the default hash function is SHA-256. Attribute, the default hash function is SHA-256.
o Digital Signature Algorithm (DSA) [optional] - Algorithm used to o Digital Signature Algorithm (DSA) [optional] - Algorithm used to
calculate the Digital Signature. If this Information Element is calculate the Digital Signature. If this Information Element is
not present in the URI Signing Package Attribute, the default is not present in the URI Signing Package Attribute, the default is
EC-DSA. EC-DSA.
skipping to change at page 11, line 49 skipping to change at page 12, line 6
supported). The present document specifies Version 1. If the supported). The present document specifies Version 1. If the
Version attribute is not present in the Signed URI, then the version Version attribute is not present in the Signed URI, then the version
is obtained from the CDNI metadata, else it is considered to have is obtained from the CDNI metadata, else it is considered to have
been set to the default value of 1. More versions may be defined in been set to the default value of 1. More versions may be defined in
the future. the future.
The Key ID Information Element is used to retrieved the key which is The Key ID Information Element is used to retrieved the key which is
needed as input to the algorithm for validating the Signed URI. The needed as input to the algorithm for validating the Signed URI. The
method used for obtaining the actual key from the reference included method used for obtaining the actual key from the reference included
in the Key ID Information Element is outside the scope of this in the Key ID Information Element is outside the scope of this
document. document. Instead of using the KID element, which is a string, it is
possible to use the KID_NUM element for numerical Key identifiers
instead. The KID_NUM element is a 64-bit unsigned integer. In cases
where numerical KEY IDs are used, it is RECOMMENDED to use KID_NUM
instead of KID.
The Hash Function Information Element indicates the hash function to The Hash Function Information Element indicates the hash function to
be used for HMAC-based message digest computation. The Hash Function be used for HMAC-based message digest computation. The Hash Function
Information Element is used in combination with the Message Digest Information Element is used in combination with the Message Digest
Information Element defined in section Section 2.3. Information Element defined in section Section 2.3.
The Digital Signature Algorithm Information Element indicates the The Digital Signature Algorithm Information Element indicates the
digital signature function to be in the case asymmetric keys are digital signature function to be in the case asymmetric keys are
used. The Digital Signature Algorithm Information Element is used in used. The Digital Signature Algorithm Information Element is used in
combination with the Digital Signature Information Element defined in combination with the Digital Signature Information Element defined in
skipping to change at page 13, line 47 skipping to change at page 14, line 9
the only URI Signing attribute exposed in the Signed URI. The the only URI Signing attribute exposed in the Signed URI. The
attribute MUST be the last parameter in the query string of the URI attribute MUST be the last parameter in the query string of the URI
when the Signed URI is generated. However, a client or CDN may when the Signed URI is generated. However, a client or CDN may
append other query parameters unrelated to URI Signing to the Signed append other query parameters unrelated to URI Signing to the Signed
URI. Such additional query parameters SHOULD NOT use the same name URI. Such additional query parameters SHOULD NOT use the same name
as the URI Signing Package Attribute to avoid namespace collision and as the URI Signing Package Attribute to avoid namespace collision and
potential failure of the URI Signing validation. potential failure of the URI Signing validation.
The parameter name of the URI Signing Package Attribute shall be The parameter name of the URI Signing Package Attribute shall be
defined in the CDNI Metadata interface. If the CDNI Metadata defined in the CDNI Metadata interface. If the CDNI Metadata
interface does not include a parameter name for the URI Signing interface is not used, or does not include a parameter name for the
Package Attribute, the parameter name is set by configuration ((out URI Signing Package Attribute, the parameter name is set by
of scope of this document). configuration (out of scope of this document).
2.5. User Agent Attributes 2.5. User Agent Attributes
For some use cases, such as logging, it might be useful to allow the For some use cases, such as logging, it might be useful to allow the
UA, or another entity, add one or more attributes to the Signed URI UA, or another entity, add one or more attributes to the Signed URI
for purposes other than URI Signing without causing URI Signing to for purposes other than URI Signing without causing URI Signing to
fail. In order to do so, such attributes MUST be appended after the fail. In order to do so, such attributes MUST be appended after the
URI Signing Packacke Attribute. Any attributes appended in such way URI Signing Packacke Attribute. Any attributes appended in such way
after the URI Signature has been calculated are not validated for the after the URI Signature has been calculated are not validated for the
purpose of content access authorization. Adding any such attributes purpose of content access authorization. Adding any such attributes
skipping to change at page 16, line 11 skipping to change at page 16, line 22
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. If 2. If the key identifier is not needed, skip this step. If
an information element was added to the message, append an information element was added to the message, append
an "&" character. Append the string "KID=". Append the an "&" character. Append the string "KID=" in case a
key identifier (e.g. "example:keys:123") needed by the string-based Key ID is used, or "KID_NUM=" in case a
numerical Key ID is used. Append the key identifier
(e.g. "example:keys:123" or "56128239") needed by the
entity to locate the shared key for validating the URI entity to locate the shared key for validating the URI
signature. 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. If an default value ("SHA-256"), skip this step. If an
information element was added to the message, append an information element was added to the message, append an
"&" character. append the string "HF=". Append the "&" character. append the string "HF=". Append the
string for the new type of hash function to be used. string for the new type of hash function to be used.
Note that re-signing a URI MUST use the same hash Note that re-signing a URI MUST use the same hash
function as the received Signed URI or one of the function as the received Signed URI or one of the
skipping to change at page 17, line 4 skipping to change at page 17, line 18
56593a97acb972202120dc482bddaf"). 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. If 2. If the key identifier is not needed, skip this step. If
an information element was added to the message, append an information element was added to the message, append
an "&" character. Append the string "KID=". Append the an "&" character. Append the string "KID=" in case a
key identifier (e.g. "http://example.com/public/ string-based Key ID is used, or "KID_NUM=" in case a
keys/123") needed by the entity to locate the shared key numerical Key ID is used. Append the key identifier
for validating the URI signature. Note the Key ID URI (e.g. "http://example.com/public/keys/123") needed by the
contains only the "scheme name", "authority", and "path" entity to locate the shared key for validating the URI
parts (i.e. query string is not allowed). signature. Note that in the case the Key ID URI is a URL
to a public key, the Key ID URI SHOULD only contain 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. If an default value ("EC-DSA"), skip this step. If an
information element was added to the message, append an information element was added to the message, append an
"&" character. Append the string "DSA=". Append the "&" character. Append the string "DSA=". Append the
string denoting the new digital signature function. string denoting the new digital signature function.
4. If an information element was added to the message, 4. If an information element was added to the message,
append an "&" character. Append the string "DS=". The append an "&" character. Append the string "DS=". The
message now contains the complete section of the URI that message now contains the complete section of the URI that
skipping to change at page 20, line 9 skipping to change at page 20, line 23
7. Extract the value from "CIP" if the information element exists 7. Extract the value from "CIP" if the information element exists
in the query string. The existence of this information element in the query string. The existence of this information element
indicates content delivery is enforced based on client IP indicates content delivery is enforced based on client IP
address. address.
8. Extract the value from "ET" if the information element exists in 8. Extract the value from "ET" if the information element exists in
the query string. The existence of this information element the query string. The existence of this information element
indicates content delivery is enforced based on time. indicates content delivery is enforced based on time.
9. Extract the value from the "KID" information element, if it 9. Extract the value from the "KID" or "KID_NUM" information
exists. The existence of this information element indicates a element, if they exist. The existence of either of these
key can be referenced. information elements indicates a key can be referenced. If both
the "KID" and the "KID_NUM" information elements are present,
the Signed URI is considered to be malformed and the request is
denied.
10. Extract the value from the "HF" information element, if it 10. Extract the value from the "HF" information element, if it
exists. The existence of this information element indicates a exists. The existence of this information element indicates a
different hash function than the default. different hash function than the default.
11. Extract the value from the "DSA" information element, if it 11. Extract the value from the "DSA" information element, if it
exists. The existence of this information element indicates a exists. The existence of this information element indicates a
different digital signature algorithm than the default. different digital signature algorithm than the default.
4.2. Signature Validation 4.2. Signature Validation
skipping to change at page 20, line 41 skipping to change at page 21, line 11
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. If "KID" information element exists, validate that the a. If either the "KID" or "KID_NUM" information element
key identifier is in the allowable KID set as listed in exists, validate that the key identifier is in the
the CDNI metadata or configuration. The request is allowable KID set as listed in the CDNI metadata or
denied when the key identifier is not allowed. configuration. The request is denied when the key
Otherwise, the "KID" information element is not in the identifier is not allowed. If neither the "KID" or
Signed URI. In this case, obtain the shared key via CDNI "KID_NUM" information element is present in the Signed
metadata or configuration. URI, obtain the shared key via CDNI metadata or
configuration.
b. If "HF" information element exists, validate that the b. If "HF" information element exists, validate that the
hash function is in the allowable "HF" set as listed in hash function is in the allowable "HF" set as listed in
the CDNI metadata or configuration. The request is the CDNI metadata or configuration. The request is
denied when the hash function is not allowed. Otherwise, denied when the hash function is not allowed. Otherwise,
the "HF" information element is not in the Signed URI. the "HF" information element is not in the Signed URI.
In this case, the default hash function is SHA-256. In this case, the default hash function is SHA-256.
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.
skipping to change at page 21, line 28 skipping to change at page 21, line 48
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. If "KID" information element exists, validate that the a. If either the "KID" or "KID_NUM" information element
key identifier is in the allowable KID set as listed in exists, validate that the key identifier is in the
the CDNI metadata or configuration. The request is allowable KID set as listed in the CDNI metadata or
denied when the key identifier is not allowed. configuration. The request is denied when the key
Otherwise, the "KID" information element is not in the identifier is not allowed. If neither the "KID" or
Signed URI. In this case, obtain the public key via CDNI "KID_NUM" information element is present in the Signed
metadata or configuration. URI, obtain the public key via CDNI metadata or
configuration.
b. If "DSA" information element exists, validate that the b. If "DSA" information element exists, validate that the
digital signature algorithm is in the allowable "DSA" set digital signature algorithm is in the allowable "DSA" set
as listed in the CDNI metadata or configuration. The as listed in the CDNI metadata or configuration. The
request is denied when the DSA is not allowed. request is denied when the DSA is not allowed.
Otherwise, the "DSA" information element is not in the Otherwise, the "DSA" information element is not in the
Signed URI. In this case, the default DSA is EC-DSA. Signed URI. In this case, the default DSA is EC-DSA.
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.
skipping to change at page 25, line 13 skipping to change at page 25, line 34
implementations of URI signing. implementations of URI signing.
Property: key-id-set Property: key-id-set
Description: Allowable Key ID set that the Signed URI's Key ID Description: Allowable Key ID set that the Signed URI's Key ID
information element can reference. information element can reference.
Type: List of Strings Type: List of Strings
Mandatory-to-Specify: No. Default is to allow any Key ID. Mandatory-to-Specify: No. Default is to allow any Key ID.
[Editor's note: security issue with default to allow any? Easy
for bad guy to put their own key ID in URI. The default should
be key ID must be in the set or configuration?]
Property: hash-function Property: hash-function
Description: Designated hash function used for URI Signing Description: Designated hash function used for URI Signing
computation when the Signed URI does not contain the Hash computation when the Signed URI does not contain the Hash
Function information element. Function information element.
Type: String (limited to the hash function strings in the Type: String (limited to the hash function strings in the
registry defined by the IANA Considerations (Section 8) registry defined by the IANA Considerations (Section 8)
section) section)
skipping to change at page 26, line 49 skipping to change at page 27, line 20
Note that the Key ID information element is not needed if only one 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 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 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 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 content with a private key and provide the public key in the Signed
URI. This just confirms that the URI Signer authorized the delivery. 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, But it's necessary for the URI Signer to be the content owner. So,
the CDNI Metadata interface or configuration MUST provide the the CDNI Metadata interface or configuration MUST provide the
allowable Key ID set to authorize the Key ID information element allowable Key ID set to authorize the Key ID information element
embedded in teh Signed URI. embedded in the Signed URI.
5.5. CDNI Logging Interface 5.5. CDNI Logging Interface
For URI Signing, the Downstream CDN reports that enforcement of the For URI Signing, the Downstream CDN reports that enforcement of the
access control was applied to the request for content delivery. When access control was applied to the request for content delivery. When
the request is denied due to enforcement of URI Signing, the reason the request is denied due to enforcement of URI Signing, the reason
is logged. 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
skipping to change at page 28, line 28 skipping to change at page 28, line 42
(e.g. between the CSP and the Authoritative CDN, between the (e.g. between the CSP and the Authoritative CDN, between the
Authoritative CDN and a Downstream CDN). This allows a CDNI hop to Authoritative CDN and a Downstream CDN). This allows a CDNI hop to
ascertain the authenticity of a given request received from a ascertain the authenticity of a given request received from a
previous CDNI hop. previous CDNI hop.
The URI signing scheme described below is based on the following The URI signing scheme described below is based on the following
steps (assuming HTTP redirection, iterative request routing and a CDN steps (assuming HTTP redirection, iterative request routing and a CDN
path with two CDNs). Note that Authoritative CDN and Upstream CDN path with two CDNs). Note that Authoritative CDN and Upstream CDN
are used exchangeably. are used exchangeably.
End-User dCDN uCDN CSP End-User dCDN uCDN CSP
| | | | | | | |
| 1.CDNI FCI interface used to | | | 1.CDNI FCI interface used to | |
| advertise URI Signing capability| | | advertise URI Signing capability| |
| |------------------->| | | |------------------->| |
| | | | | | | |
| 2.Provides information to validate URI signature| | 2.Provides information to validate URI signature|
| | |<-------------------| | | |<-------------------|
| | | | | | | |
| 3.CDNI Metadata interface used to| | | 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| | | provide URI Signing attributes| |
| |<-------------------| | | |<-------------------| |
|4.Authorization request | | |4.Authorization request | |
|------------------------------------------------------------->| |------------------------------------------------------------->|
| | | [Apply distribution | | | [Apply distribution
| | | policy] | | | | policy] |
| | | | | | | |
| | (ALT: Authorization decision) | | (ALT: Authorization decision)
|5.Request is denied | | <Negative> | |5.Request is denied | | <Negative> |
|<-------------------------------------------------------------| |<-------------------------------------------------------------|
| | | | | | | |
|6.CSP provides signed URI | <Positive> | |6.CSP provides signed URI | <Positive> |
|<-------------------------------------------------------------| |<-------------------------------------------------------------|
| | | | | | | |
|7.Content request | | | |7.Content request | | |
|---------------------------------------->| [Validate URI | |---------------------------------------->| [Validate URI |
| | | signature] | | | | signature] |
| | | | | | | |
| | (ALT: Validation result) | | | (ALT: Validation result) |
|8.Request is denied | <Negative>| | |8.Request is denied | <Negative>| |
|<----------------------------------------| | |<----------------------------------------| |
| | | | | | | |
|9.Re-sign URI and redirect to <Positive>| | |9.Re-sign URI and redirect to <Positive>| |
| dCDN (newly signed URI) | | | dCDN (newly signed URI) | |
|<----------------------------------------| | |<----------------------------------------| |
| | | | | | | |
|10.Content request | | | |10.Content request | | |
|------------------->| [Validate URI | | |------------------->| [Validate URI | |
| | signature] | | | | signature] | |
| | | | | | | |
| (ALT: Validation result) | | | (ALT: Validation result) | |
|11.Request is denied| <Negative> | | |11.Request is denied| <Negative> | |
|<-------------------| | | |<-------------------| | |
| | | | | | | |
|12.Content delivery | <Positive> | | |12.Content delivery | <Positive> | |
|<-------------------| | | |<-------------------| | |
: : : : : : : :
: (Later in time) : : : : (Later in time) : : :
|13.CDNI Logging interface to include URI Signing information | |13.CDNI Logging interface to include URI Signing information |
| |------------------->| | | |------------------->| |
Figure 3: HTTP-based Request Routing with URI Signing Figure 3: HTTP-based Request Routing with URI Signing
1. Using the CDNI Footprint & Capabilities Advertisement interface, 1. Using the CDNI Footprint & Capabilities Advertisement interface,
the Downstream CDN advertises its capabilities including URI the Downstream CDN advertises its capabilities including URI
Signing support to the Authoritative CDN. Signing support to the Authoritative CDN.
2. CSP provides to the Authoritative CDN the information needed to 2. CSP provides to the Authoritative CDN the information needed to
validate URI signatures from that CSP. For example, this validate URI signatures from that CSP. For example, this
information may include a hashing function, algorithm, and a key information may include a hashing function, algorithm, and a key
skipping to change at page 31, line 16 skipping to change at page 31, line 30
want to restrict the distribution of the key to a (possibly empty) want to restrict the distribution of the key to a (possibly empty)
subset of trusted Downstream CDNs. Authorized Delivery CDNs need to subset of trusted Downstream CDNs. Authorized Delivery CDNs need to
obtain the key information to validate the Signed UR, which is obtain the key information to validate the Signed UR, which is
computed by the CSP based on its distribution policy. computed by the CSP based on its distribution policy.
The URI signing scheme described below is based on the following The URI signing scheme described below is based on the following
steps (assuming iterative DNS request routing and a CDN path with two steps (assuming iterative DNS request routing and a CDN path with two
CDNs). Note that Authoritative CDN and Upstream CDN are used CDNs). Note that Authoritative CDN and Upstream CDN are used
exchangeably. exchangeably.
End-User dCDN uCDN CSP End-User dCDN uCDN CSP
| | | | | | | |
| 1.CDNI FCI interface used to | | | 1.CDNI FCI interface used to | |
| advertise URI Signing capability| | | advertise URI Signing capability| |
| |------------------->| | | |------------------->| |
| | | | | | | |
| 2.Provides information to validate URI signature| | 2.Provides information to validate URI signature|
| | |<-------------------| | | |<-------------------|
| 3.CDNI Metadata interface used to| | | 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| | | provide URI Signing attributes| |
| |<-------------------| | | |<-------------------| |
|4.Authorization request | | |4.Authorization request | |
|------------------------------------------------------------->| |------------------------------------------------------------->|
| | | [Apply distribution | | | [Apply distribution
| | | policy] | | | | policy] |
| | | | | | | |
| | (ALT: Authorization decision) | | (ALT: Authorization decision)
|5.Request is denied | | <Negative> | |5.Request is denied | | <Negative> |
|<-------------------------------------------------------------| |<-------------------------------------------------------------|
| | | | | | | |
|6.Provides signed URI | <Positive> | |6.Provides signed URI | <Positive> |
|<-------------------------------------------------------------| |<-------------------------------------------------------------|
| | | | | | | |
|7.DNS request | | | |7.DNS request | | |
|---------------------------------------->| | |---------------------------------------->| |
| | | | | | | |
|8.Redirect DNS to dCDN | | |8.Redirect DNS to dCDN | |
|<----------------------------------------| | |<----------------------------------------| |
| | | | | | | |
|9.DNS request | | | |9.DNS request | | |
|------------------->| | | |------------------->| | |
| | | | | | | |
|10.IP address of Surrogate | | |10.IP address of Surrogate | |
|<-------------------| | | |<-------------------| | |
| | | | | | | |
|11.Content request | | | |11.Content request | | |
|------------------->| [Validate URI | | |------------------->| [Validate URI | |
| | signature] | | | | signature] | |
| | | | | | | |
| (ALT: Validation result) | | | (ALT: Validation result) | |
|12.Request is denied| <Negative> | | |12.Request is denied| <Negative> | |
|<-------------------| | | |<-------------------| | |
| | | | | | | |
|13.Content delivery | <Positive> | | |13.Content delivery | <Positive> | |
|<-------------------| | | |<-------------------| | |
: : : : : : : :
: (Later in time) : : : : (Later in time) : : :
|14.CDNI Logging interface to report URI Signing information | |14.CDNI Logging interface to report URI Signing information |
| |------------------->| | | |------------------->| |
Figure 4: DNS-based Request Routing with URI Signing Figure 4: DNS-based Request Routing with URI Signing
1. Using the CDNI Footprint & Capabilities Advertisement interface, 1. Using the CDNI Footprint & Capabilities Advertisement interface,
the Downstream CDN advertises its capabilities including URI the Downstream CDN advertises its capabilities including URI
Signing support to the Authoritative CDN. Signing support to the Authoritative CDN.
2. CSP provides to the Authoritative CDN the information needed to 2. CSP provides to the Authoritative CDN the information needed to
validate cryptographic signatures from that CSP. For example, validate cryptographic signatures from that CSP. For example,
this information may include a hash function, algorithm, and a this information may include a hash function, algorithm, and a
skipping to change at page 34, line 31 skipping to change at page 34, line 40
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 KID_NUM (Numerical Key ID)
o HF (Hash Function): "SHA-256" o HF (Hash Function): "SHA-256"
o DSA (Digital Signature Algorithm): "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 for Symmetric Key) o MD (Message Digest for Symmetric Key)
o DS (Digital Signature for Asymmetric Keys) 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
o s-url-signing-deny-reason o s-url-signing-deny-reason
The IANA is requested to allocate a new entry to the "CDNI The IANA is requested to allocate a new entry to the "CDNI
skipping to change at page 36, line 22 skipping to change at page 36, line 34
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.
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.
In the case where asymmetric keys are used, the KID information
element might contain the URL to the public key. To prevent
malicious clients from signing their own URIs and inserting the
associated public key URL in the KID field, thereby passing URI
validation, it is important that CDNs check whether the URI conveyed
in the KID field is in the allowable set of KIDs as listed in the
CDNI metadata or set via configuration.
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 the following people for their The authors would like to thank the following people for their
contributions in reviewing this document and providing feedback: contributions in 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, Iuniana
Oprescu. In addition, Matt Caulfield provided content for the CDNI Oprescu and Leif Hedstrom. In addition, Matt Caulfield provided
Metadata Interface section. 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-18 (work in progress), March 2015. logging-18 (work in progress), March 2015.
[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]
Peterson, L., Davie, B., and R. Brandenburg, "Framework
for CDN Interconnection", draft-ietf-cdni-framework-14
(work in progress), June 2014.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni- "CDN Interconnection Metadata", draft-ietf-cdni-
metadata-09 (work in progress), March 2015. metadata-09 (work in progress), March 2015.
[I-D.ietf-cdni-redirection] [I-D.ietf-cdni-redirection]
Niven-Jenkins, B. and R. Brandenburg, "Request Routing Niven-Jenkins, B. and R. Brandenburg, "Request Routing
Redirection Interface for CDN Interconnection", draft- Redirection Interface for CDN Interconnection", draft-
ietf-cdni-redirection-08 (work in progress), February ietf-cdni-redirection-08 (work in progress), February
2015. 2015.
[I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", draft-ietf-cdni-
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 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001. (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.
skipping to change at page 38, line 5 skipping to change at page 38, line 20
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.
[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.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg,
"Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, August 2014.
[RFC7337] Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", RFC 7337, August
2014.
Authors' Addresses Authors' Addresses
Kent Leung Kent Leung
Cisco Systems Cisco Systems
3625 Cisco Way 3625 Cisco Way
San Jose 95134 San Jose 95134
USA USA
Phone: +1 408 526 5030 Phone: +1 408 526 5030
Email: kleung@cisco.com Email: kleung@cisco.com
skipping to change at page 38, line 24 skipping to change at page 39, line 4
Email: kleung@cisco.com Email: kleung@cisco.com
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com Email: flefauch@cisco.com
Ray van Brandenburg Ray van Brandenburg
TNO TNO
Brassersplein 2 Anna van Buerenplein 1
Delft 2612CT Den Haag 2595DC
the Netherlands the Netherlands
Phone: +31 88 866 7000 Phone: +31 88 866 7000
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
 End of changes. 34 change blocks. 
175 lines changed or deleted 198 lines changed or added

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