[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 draft-ietf-cdni-uri-signing

CDNI                                                            K. Leung
Internet-Draft                                            F. Le Faucheur
Intended status: Standards Track                           Cisco Systems
Expires: September 5, 2014                                     B. Downey
                                                            Verizon Labs
                                                      R. van Brandenburg
                                                                     TNO
                                                             S. Leibrand
                                                      Limelight Networks
                                                           March 4, 2014


               URI Signing for CDN Interconnection (CDNI)
                    draft-leung-cdni-uri-signing-05

Abstract

   This document describes how the concept of URI signing supports the
   content access control requirements of CDNI and proposes a URI
   signing scheme.

   The proposed URI signing method specifies the information needed to
   be included in the URI and the algorithm used to authorize and to
   validate access requests for the content referenced by the URI.  Some
   of the information may be accessed by the CDN via configuration or
   CDNI metadata.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 5, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Leung, et al.           Expires September 5, 2014               [Page 1]


Internet-Draft              CDNI URI Signing                  March 2014


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Background on URI Signing  . . . . . . . . . . . . . . . .  4
     1.3.  CDNI URI Signing Overview  . . . . . . . . . . . . . . . .  6
     1.4.  URI Signing in a non-CDNI context  . . . . . . . . . . . .  8
   2.  Signed URI Information Elements  . . . . . . . . . . . . . . .  8
     2.1.  Enforcement Information Elements . . . . . . . . . . . . . 10
     2.2.  Signature Computation Information Elements . . . . . . . . 11
     2.3.  URI Signature Information Elements . . . . . . . . . . . . 12
     2.4.  URI Signing Package Attribute  . . . . . . . . . . . . . . 13
   3.  Creating the Signed URI  . . . . . . . . . . . . . . . . . . . 14
     3.1.  Calculating the URI Signature  . . . . . . . . . . . . . . 14
     3.2.  Packaging the URI Signature  . . . . . . . . . . . . . . . 17
   4.  Validating a URI Signature . . . . . . . . . . . . . . . . . . 18
     4.1.  Information element validation . . . . . . . . . . . . . . 18
     4.2.  Signature validation . . . . . . . . . . . . . . . . . . . 19
   5.  Relationship with CDNI Interfaces  . . . . . . . . . . . . . . 21
     5.1.  CDNI Control Interface . . . . . . . . . . . . . . . . . . 22
     5.2.  CDNI Footprint & Capabilities Advertisement Interface  . . 22
     5.3.  CDNI Request Routing Redirection Interface . . . . . . . . 22
     5.4.  CDNI Metadata Interface  . . . . . . . . . . . . . . . . . 23
     5.5.  CDNI Logging Interface . . . . . . . . . . . . . . . . . . 24
   6.  URI Signing Message Flow . . . . . . . . . . . . . . . . . . . 24
     6.1.  HTTP Redirection . . . . . . . . . . . . . . . . . . . . . 25
     6.2.  DNS Redirection  . . . . . . . . . . . . . . . . . . . . . 27
   7.  HTTP Adaptive Streaming  . . . . . . . . . . . . . . . . . . . 30
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31
   10. Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 33
     12.2. Informative References . . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34




Leung, et al.           Expires September 5, 2014               [Page 2]


Internet-Draft              CDNI URI Signing                  March 2014


1.  Introduction

   This document describes the concept of URI Signing and how it can be
   used to provide access authorization in the case of interconnected
   CDNs (CDNI).  The primary goal of URI Signing is to make sure that
   only authorized User Agents (UAs) are able to access the content,
   with a Content Service Provider (CSP) being able to authorize every
   individual request.  It should be noted that URI Signing is not a
   content protection scheme; if a CSP wants to protect the content
   itself, other mechanisms, such as DRM, are more appropriate.

   The overall problem space for CDN Interconnection (CDNI) is described
   in CDNI Problem Statement [RFC6707].  In this document, along with
   the CDNI Requirements [I-D.ietf-cdni-requirements] document and the
   CDNI Framework [I-D.ietf-cdni-framework] the need for interconnected
   CDNs to be able to implement an access control mechanism that
   enforces the CSP's distribution policy is described.

   Specifically, CDNI Framework [I-D.ietf-cdni-framework] states:

   "The CSP may also trust the CDN operator to perform actions such as
   ..., and to enforce per-request authorization performed by the CSP
   using techniques such as URI signing."

   In particular, the following requirement is listed in CDNI
   Requirements [I-D.ietf-cdni-requirements]:

   "MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow
   signaling of authorization checks and validation that are to be
   performed by the surrogate before delivery.  For example, this could
   potentially include:

   * need to validate URI signed information (e.g.  Expiry time, Client
   IP address)."

   This document proposes a URI Signing scheme that allows Surrogates in
   interconnected CDNs to enforce a per-request authorization performed
   by the CSP.  Splitting the role of performing per-request
   authorization by CSP and the role of validation of this authorization
   by the CDN allows any arbitrary distribution policy to be enforced
   across CDNs without the need of CDNs to have any awareness of the
   actual CSP distribution policy.

1.1.  Terminology

   This document uses the terminology defined in CDNI Problem Statement
   [RFC6707].




Leung, et al.           Expires September 5, 2014               [Page 3]


Internet-Draft              CDNI URI Signing                  March 2014


   This document also uses the terminology of Keyed-Hashing for Message
   Authentication (HMAC) [RFC2104] including the following terms
   (reproduced here for convenience):

   o  MAC: message authentication code.

   o  HMAC: Hash-based message authentication code (HMAC) is a specific
      construction for calculating a MAC involving a cryptographic hash
      function in combination with a secret key.

   o  HMAC-SHA1: HMAC instantiation using SHA-1 as the cryptographic
      hash function.

   o  HMAC-MD5: HMAC instantiation using MD5 as the cryptographic hash
      function.

   In addition, the following terms are used throughout this document:

   o  URI Signature: Message digest or digital signature that is
      computed with an algorithm for protecting the URI.

   o  Original URI: The URI before URI Signing is applied.

   o  Signed URI: Any URI that contains a URI Signature.

   o  Target CDN URI: Embedded URI created by the CSP to direct UA
      towards the Upstream CDN.  The Target CDN URI can be signed by the
      CSP and verified by the Upstream CDN.

   o  Redirection URI: URI created by the Upstream CDN to redirect UA
      towards the Downstream CDN.  The Redirection URI can be signed by
      the Upstream CDN and verified by the Downstream CDN.  In a
      cascaded CDNI scenario, there can be more than one Redirection
      URI.

1.2.  Background on URI Signing

   The next section provides an overview of how URI Signing works in a
   CDNI environment.  As background information, URI Signing is first
   explained in terms of a single CDN delivering content on behalf of a
   CSP.

   A CSP and CDN are assumed to have a trust relationship that enables
   the CSP to authorize access to a content item by including a set of
   attributes in the URI before redirecting a UA to the CDN.  Using
   these attributes, it is possible for a CDN to check an incoming
   content request to see whether it was authorized by the CSP (e.g.
   based on the UA's IP address or a time window).  Of course, the



Leung, et al.           Expires September 5, 2014               [Page 4]


Internet-Draft              CDNI URI Signing                  March 2014


   attributes need to be added to the URI in a way that prevents a UA
   from changing the attributes, thereby leaving the CDN to think that
   the request was authorized by the CSP when in fact it wasn't.  For
   this reason, a URI Signing mechanism includes in the URI a message
   digest or digital signature that allows a CDN to check the
   authenticity of the URI.  The message digest or digital signature can
   be calculated based on a shared secret between the CSP and CDN or
   using CSP's asymmetric public/private key pair, respectively.

   Figure 1, shown below, presents an overview of the URI Signing
   mechanism in the case of a CSP with a single CDN.  When the UA
   browses for content on CSP's website (#1), it receives HTML web pages
   with embedded content URIs.  Upon requesting these URIs, the CSP
   redirects to a CDN, creating a Target CDN URI (#2) (alternatively,
   the Target CDN URI itself is embedded in the HTML).  The Target CDN
   URI is the Signed URI which may include the IP address of the UA
   and/or a time window and always contains the URI Signature which is
   generated by the CSP using the shared secret or a private key.  Once
   the UA receives the response with the embedded URI, it sends a new
   HTTP request using the embedded URI to the CDN (#3).  Upon receiving
   the request, the CDN checks to see if the Signed URI is authentic by
   verifying the URI signature.  In addition, it checks whether the IP
   address of the HTTP request matches that in the Signed URI and if the
   time window is still valid.  After these values are confirmed to be
   valid, the CDN delivers the content (#4).

                   --------
                  /        \
                  |   CSP  |< * * * * * * * * * * *
                  \        /        Trust         *
                   --------      relationship     *
                     ^  |                         *
                     |  |                         *
          1. Browse  |  | 2. Signed               *
               for   |  |    URI                  *
             content |  |                         *
                     |  v                         v
                   +------+ 3. Signed URI     --------
                   | User |----------------->/        \
                   | Agent|                  |  CDN   |
                   |      |<-----------------\        /
                   +------+ 4. Content        --------
                               Delivery

           Figure 1: Figure 1: URI Signing in a CDN Environment






Leung, et al.           Expires September 5, 2014               [Page 5]


Internet-Draft              CDNI URI Signing                  March 2014


1.3.  CDNI URI Signing Overview

   In a CDNI environment, URI Signing operates the same way in the
   initial steps #1 and #2 but the later steps involve multiple CDNs in
   the process of delivering the content.  The main difference from the
   single CDN case is a redirection step between the Upstream CDN and
   the Downstream CDN.  In step #3, UA may send HTTP request or DNS
   request.  Depending on whether HTTP-based or DNS-based request
   routing is used, the Upstream CDN responds by directing the UA
   towards the Downstream CDN using either a Redirection URI (which is a
   Signed URI generated by the Upstream CDN) or a DNS reply,
   respectively (#4).  Once the UA receives the response, it sends the
   Redirection URI/Target CDN URI to the Downstream CDN (#5).  The
   received URI is validated by the Downstream CDN before delivering the
   content (#6).  This is depicted in the figure below.  Note: The CDNI
   call flows are covered in Detailed URI Signing Operation (Section 6).



































Leung, et al.           Expires September 5, 2014               [Page 6]


Internet-Draft              CDNI URI Signing                  March 2014


                                      +-------------------------+
                                      |Request Redirection Modes|
                                      +-------------------------+
                                      | a) HTTP                 |
                                      | b) DNS                  |
                                      +-------------------------+
                   --------
                  /        \< * * * * * * * * * * * * * *
                  |   CSP  |< * * * * * * * * * * *     *
                  \        /        Trust         *     *
                   --------      relationship     *     *
                     ^  |                         *     *
                     |  | 2. Signed               *     *
          1. Browse  |  |    URI in               *     *
               for   |  |    HTML                 *     *
             content |  |                         *     *
                     |  v   3.a)Signed URI        v     *
                   +------+   b)DNS request   --------  * Trust
                   | User |----------------->/        \ * relationship
                   | Agent|                  |  uCDN  | * (optional)
                   |      |<-----------------\        / *
                   +------+ 4.a)Redirection URI-------  *
                     ^  |     b)DNS Reply         ^     *
                     |  |                         *     *
                     |  |      Trust relationship *     *
                     |  |                         *     *
         6. Content  |  | 5.a)Redirection URI     *     *
            delivery |  |   b)Signed URI(after    v     v
                     |  |     DNS exchange)      --------
                     |  +---------------------->/        \ [May be
                     |                          |  dCDN  |  cascaded
                     +--------------------------\        /  CDNs]
                                                 --------

                +-----------------------------------------+
                | Key |    Asymmetric   |    Symmetric    |
                +-----------------------------------------+
                |HTTP |Public key (uCDN)|Shared key (uCDN)|
                |DNS  |Public key (CSP) |Shared key (CSP) |
                +-----------------------------------------+

                Figure 2: URI Signing in a CDNI Environment

   The trust relationships between CSP, Upstream CDN, and Downstream CDN
   have direct implications for URI Signing.  In the case shown in
   Figure 2, the CDN that the CSP has a trust relationship with is the
   Upstream CDN.  The delivery of the content may be delegated to the
   Downstream CDN, which has a relationship with the Upstream CDN but



Leung, et al.           Expires September 5, 2014               [Page 7]


Internet-Draft              CDNI URI Signing                  March 2014


   may have no relationship with the CSP.

   In CDNI, there are two methods for request routing: DNS-based and
   HTTP-based.  For DNS-based request routing, the Signed URI (i.e.
   Target CDN URI) provided by the CSP reaches the Downstream CDN
   directly.  In the case where the Downstream CDN does not have a trust
   relationship with the CSP, this means that only an asymmetric public/
   private key method can be used for computing the URI Signature
   because the CSP and Downstream CDN are not able to exchange symmetric
   shared secret keys.  Since the CSP is unlikely to have relationships
   with all the Downstream CDNs that are delegated to by the Upstream
   CDN, the CSP may choose to allow the Authoritative CDN to
   redistribute the shared key to a subset of their Downstream CDNs .

   For HTTP-based request routing, the Signed URI (i.e.  Target CDN URI)
   provided by the CSP reaches the Upstream CDN.  After this URI has
   been verified to be correct by the Upstream CDN, the Upstream CDN
   creates and signs a new Redirection URI to redirect the UA to the
   Downstream CDN.  Since this new URI also has a new URI Signature,
   this new signature can be based around the trust relationship between
   the Upstream CDN and Downstream CDN, and the relationship between the
   Downstream CDN and CSP is not relevant.  Given the fact that such a
   relationship between Upstream CDN and Downstream CDN always exists,
   both asymmetric public/private keys and symmetric shared secret keys
   can be used for URI Signing.  Note that the signed Redirection URI
   SHOULD maintain the same level of security as the original Signed
   URI.

1.4.  URI Signing in a non-CDNI context

   While the URI signing scheme defined in this document was primarily
   created for the purpose of allowing URI Signing in CDNI scenarios,
   e.g. between a uCDN and a dCDN or between a CSP and a dCDN, there is
   nothing in the defined URI Signing scheme that precludes it from
   being used in a non-CDNI context.  As such, the described mechanism
   could be used in a single-CDN scenario such as shown in Figure 1 in
   Section 1.2, for example to allow a CSP that uses different CDNs to
   only have to implement a single URI Signing mechanism.


2.  Signed URI Information Elements

   The concept behind URI Signing is based on embedding in the Target
   CDN URI/Redirection URI a number of information elements that can be
   validated to ensure the UA has legitimate access to the content.
   These information elements are appended, in an encapsulated form, to
   the original URI.




Leung, et al.           Expires September 5, 2014               [Page 8]


Internet-Draft              CDNI URI Signing                  March 2014


   For the purposes of the URI signing mechanism described in this
   document, three types of information elements may be embedded in the
   URI:

   o  Enforcement Information Elements: Information Elements that are
      used to enforce a distribution policy defined by the CSP.
      Examples of enforcement attributes are IP address of the UA and
      time window.

   o  Signature Computation Information Elements: Information Elements
      that are used by the CDN to verify the URI signature embedded in
      the received URI.  In order to verify a URI Signature, the CDN
      requires some information elements that describe how the URI
      Signature was generated.  Examples of Signature Computation
      Elements include the used HMACs hash function and/or the key
      identifier.

   o  URI Signature Information Elements: The information elements that
      carry the actual message digest or digital signature representing
      the URI signature used for checking the integrity and authenticity
      of the URI.  A typical Signed URI will only contain one embedded
      URI Signature Information Element.

   In addition, the this document specifies the following URI attribute:

   o  URI Signing Package Attribute: The URI attribute that encapsulates
      all the URI Signing information elements in an encoded format.
      Only this attribute is exposed in the Signed URI as a URI query
      parameter.

   If the UA or another entity needs to add one or more attributes to
   the Signed URI for purposes other than URI Signing, those attributes
   MUST be appended after the URI Signing Packacke Attribute.  Any
   attributes appended in such way after the URI Signature has been
   calculated are not validated for the purpose of content access
   authorization.  Note that adding any such attributes to the Signed
   URI before the URI Signing Packacke Attribute will cause the URI
   Signing validation to fail.

   Two types of keys can be used for URI Signing: asymmetric keys and
   symmetric keys.  Asymmetric keys are based on a public/private key
   pair mechanism and always contain a private key only known to the
   entity signing the URI (either CSP or uCDN) and a public key for the
   verification of the Signed URI.  With symmetric keys, the same key is
   used by both the signing entity for signing the URI as well as by the
   validating entity for validating the Signed URI.  Regardless of the
   type of keys used, the validating entity has to obtain the key
   (either the public or the symmetric key).  There are very different



Leung, et al.           Expires September 5, 2014               [Page 9]


Internet-Draft              CDNI URI Signing                  March 2014


   requirements for key distribution (out of scope of this document)
   with asymmetric keys and with symmetric keys.  Key distribution for
   symmetric keys requires confidentiality to prevent another party from
   getting access to the key, since it could then generate valid Signed
   URIs for unauthorized requests.  Key distribution for asymmetric keys
   does not require confidentiality since public keys can typically be
   distributed openly (because they cannot be used for URI signing) and
   private keys are kept by the URI signing function.

2.1.  Enforcement Information Elements

   This section identifies the set of information elements that may be
   needed to enforce the CSP distribution policy.  New information
   elements may be introduced in the future to extend the capabilities
   of the distribution policy.

   In order to provide flexibility in distribution policies to be
   enforced, the exact subset of information elements used in the URI
   Signature of a given request is a deployment decision.  The defined
   keyword for each information element is specified in parenthesis
   below.

   The following information elements are used to enforce the
   distribution policy:

   o  Expiry Time (ET) [optional] - Time when the Signed URI expires.
      This is represented as an integer denoting the number of seconds
      since midnight 1/1/1970 UTC (i.e.  UNIX epoch).  The request is
      rejected if the received time is later than this timestamp.  Note:
      The time, including time zone, on the entities that generate and
      validate the signed URI need to be in sync (e.g.  NTP is used).

   o  Client IP (CIP) [optional] - IP address of the client for which
      this Signed URI is generated.  This is represented in dotted
      decimal format for IPv4 or canonical text representation for IPv6
      address [RFC5952] .  The request is rejected if sourced from a
      client with a different IP address.

   The Expiry Time Information Element ensures that the content
   authorization expires after a predetermined time.  This limits the
   time window for content access and prevents replay of the request
   beyond the authorized time window.

   The Client IP Information Element is used to restrict content access
   to a particular User Agent, based on its IP address for whom the
   content access was authorized.

   Note: See the Security Considerations (Section 9) section on the



Leung, et al.           Expires September 5, 2014              [Page 10]


Internet-Draft              CDNI URI Signing                  March 2014


   limitations of using an expiration time and client IP address for
   distribution policy enforcement.

2.2.  Signature Computation Information Elements

   This section identifies the set of information elements that may be
   needed to verify the URI (signature).  New information elements may
   be introduced in the future if new URI signing algorithms are
   developed.

   The defined keyword for each information element is specified in
   parenthesis below.

   The following information elements are used to validate the URI by
   recreating the URI Signature.

   o  Version (VER) [optional] - An integer used for identifying the
      version of URI signing method.  If this Information Element is not
      present in the URI Signing Package Attribute, the default version
      is 1.

   o  Key ID (KID) [optiona] - A string used for obtaining the key (e.g.
      database lookup, URI reference) which is needed to validate the
      URI signature.

   o  Hash Function (HF) [optional] - A string used for identifying the
      hash function to compute the URI signature (e.g.  "MD5", "SHA-1",
      "SHA-256", "SHA-3") with HMAC.  If this Information Element is not
      present in the URI Signing Package Attribute, the default hash
      function is SHA-1.

   o  Digital Signature Algorithm (DSA) [optional] - Algorithm used to
      calculate the Digital Signature (e.g.  "RSA", "DSA", "EC-DSA").
      If this Information Element is not present in the URI Signing
      Package Attribute, the default is EC-DSA.

   The Version Information Element indicates which version of URI
   signing scheme is used (including which attributes and algorithms are
   supported).  The present document specifies Version 1.  If the
   Version attribute is not present in the Signed URI, then the version
   is obtained from the CDNI metadata, else it is considered to have
   been set to the default value.  More versions may be defined in the
   future.

   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
   method used for obtaining the actual key from the reference included
   in the Key ID Information Element is outside the scope of this



Leung, et al.           Expires September 5, 2014              [Page 11]


Internet-Draft              CDNI URI Signing                  March 2014


   document.

   The Hash Function Information Element indicates the hash function to
   be used for HMAC-based message digest computation.  The Hash Function
   Information Element is used in combination with the Message Digest
   Information Element defined in section Section 2.3.

   The Digital Signature Algorithm Information Element indicates the
   digital signature function to be in the case asymmetric keys are
   used.  The Digital Signature Algorithm Information Element is used in
   combination with the Digital Signature Information Element defined in
   section Section 2.3.

2.3.  URI Signature Information Elements

   This section identifies the set of information elements that carry
   the URI Signature that is used for checking the integrity and
   authenticity of the URI.

   The defined keyword for each information element is specified in
   parenthesis below.

   The following information elements are used to carry the actual URI
   Signature.

   o  Message Digest (MD) [mandatory for symmetric key] - A string used
      for the message digest generated by the URI signing entity.

   o  Digital Signature (DS) [mandatory for asymmetric keys] - A string
      used for the digital signature provided by the URI signing entity.

   The Message Digest attribute contains the message digest used to
   validate the Signed URI when symmetric keys are used.

   The Digital Signature attribute contains the digital signature used
   to verify the Signed URI when asymmetric keys are used.

   In the case of symmetric key, HMAC algorithm is used for the
   following reasons: 1) Ability to use hash functions (i.e. no changes
   needed) with well understood cryptographic properties that perform
   well and for which code is freely and widely available, 2) Easy to
   replace the embedded hash function in case faster or more secure hash
   functions are found or required, 3) Original performance of the hash
   function is maintained without incurring a significant degradation,
   and 4) Simple way to use and handle keys.

   In the case of asymmetric keys, Elliptic Curve Digital Signature
   Algorithm (EC DSA) - a variant of DSA - is used because of the



Leung, et al.           Expires September 5, 2014              [Page 12]


Internet-Draft              CDNI URI Signing                  March 2014


   following reasons: 1) Key size is small while still offering good
   security, 2) Key is easy to store, and 3) Computation is faster than
   DSA or RSA.

2.4.  URI Signing Package Attribute

   The URI Signing Package Attribute is an encapsulation container for
   the URI Signing Information Elements defined in the previous
   sections.  The URI Signing Information Elements are encoded and
   stored in this attribute.  URI Signing Package Attribute is appended
   to the Original URI to create the Signed URI.

   The primary advantage of the URI Signing Package Attribute is that it
   avoids having to expose the URI Signing Information Elements directly
   in the query string of the URI, thereby reducing the potential for a
   namespace collision space within the URI query string.  A side
   benefit of the attribute is the obfuscation performed by the URI
   Signing Package Attribute hides the information (e.g. client IP
   address) from view of the common user, who is not aware of the
   encoding scheme.  Obviously, this is not a security method since
   anyone who knows the encoding scheme is able to obtain the clear
   text.  Note that any parameters appended to the query string after
   the URI Signing Package Attribute are not validated and hence do not
   affect URI Signing.

   The following attribute is used to carry the encoded set of URI
   Signing attributes in the Signed URI.

   o  URI Signing Package (URISigningPackage) - The encoded attribute
      containing all the CDNI URI Signing Information Elements used for
      URI Signing.

   The URI Signing Package Attribute contains the URI Signing
   Information Elements in the Base-64 encoding with URL and Filename
   Safe Alphabet (a.k.a. "base64url") as specified in the Base-64 Data
   Encoding [RFC4648] document.  The URI Signing Package Attribute is
   the only URI Signing attribute exposed in the Signed URI.  The
   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
   append other query parameters unrelated to URI Signing to the Signed
   URI.  Such additional query parameters SHOULD NOT use the same name
   as the URI Signing Package Attribute to avoid namespace collision and
   potential failure of the URI Signing validation.

   The parameter name of the URI Signing Package Attribute shall be
   defined in the CDNI Metadata interface.  If the CDNI Metadata
   interface does not include a parameter name for the URI Signing
   Package Attribute, the parameter name is set by configuration ((out



Leung, et al.           Expires September 5, 2014              [Page 13]


Internet-Draft              CDNI URI Signing                  March 2014


   of scope of this document).


3.  Creating the Signed URI

   The following procedure for signing a URI defines the algorithms in
   this version of URI Signing.  Note that some steps may be skipped if
   the CSP does not enforce a distribution policy and the Enforcement
   Information Elements are therefore not necessary.  A URI (as defined
   in URI Generic Syntax [RFC3986]) contains the following parts: scheme
   name, authority, path, query, and fragment.  The entire URI except
   the "scheme name" part is protected by the URI signature.  This
   allows the URI signature to be validated correctly in the case when 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).
   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
   specific protocol is used for content delivery, that information is
   passed by CDNI metadata.  Note: Support for changing of the URL
   scheme requires that the default port is used, or that the protocols
   must both run on the same non-standard port.

   The process of generating a Signed URI can be divided into two sets
   of steps: calculating the URI Signature and packaging the URI
   Signature and appending it to the Original URI.  Note it is possible
   to use some other algorithm and implementation as long as the same
   result is achieved.  An example for the Original URI,
   "http://example.com/content.mov", is used to clarify the steps.

3.1.  Calculating the URI Signature

   Calculate the URI Signature by following the procedure below.

   1.  Copy the Original URI, excluding the "scheme name" part, into a
       buffer to hold the message for performing the operations below.

   2.  Check if the URI already contains a query string.  If not, append
       a "?" character.  If yes, append an "&" character.

   3.  If the version is the default value, skip this step.  Append the
       string "VER=".  Append the string for the version number.

   4.  If time window enforcement is not needed, step 4 can be skipped.

       A.  If an attribute was added to the URI, append an "&"
           character.  Append the string "ET=".  Note in the case of re-
           signing a URI, the attribute is carried over from the
           received Signed URI.



Leung, et al.           Expires September 5, 2014              [Page 14]


Internet-Draft              CDNI URI Signing                  March 2014


       B.  Get the current time in seconds since epoch (as an integer).
           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
           the received Signed URI.

       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.

       A.  If an attribute was added to the URI, append an "&"
           character.  Append the string "CIP=".  Note in the case 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
           format (i.e. for IPv4 address) or canonical text
           representation (for IPv6 address [RFC5952]) to a string and
           append to the message.  Note in the case of re-signing an
           URI, the value MUST remain the same as the received Signed
           URI.

   6.  Depending on the type of key used to sign the URI, compute the
       message digest or digital signature for symmetric key or
       asymmetric keys, respectively.

       A.  For symmetric key, HMAC is used.

           1.  Obtain the shared key to be used for signing the URI.

           2.  If the key identifier is provided by the CDNI metadata,
               skip this step.  If an attribute was added to the URI,
               append an "&" character.  Append the string "KID=".
               Append the key identifier (e.g. "example:keys:123")
               needed by the entity to locate the shared key for
               validating the URI signature.

           3.  If the hash function for the HMAC uses the default value
               (SHA-1), skip this step.  If an attribute was added to
               the URI, append an "&" character.  Append the string
               "HF=".  Append the string for the type of hash function.
               Note that re-signing a URI MUST use the same hash
               function as the received Signed URI or one of the
               allowable hash functions designated by the CDNI metadata.

           4.  If an attribute was added to the URI, append an "&"
               character.  Append the string "MD=".  The message now
               contains the complete section of the URI that is
               protected (e.g. "://example.com/



Leung, et al.           Expires September 5, 2014              [Page 15]


Internet-Draft              CDNI URI Signing                  March 2014


               content.mov?ET=1209422976&CIP=10.0.0.1&
               KID=example:keys:123&MD=").

           5.  Compute the message digest using the HMAC algorithm with
               the shared key (e.g. "secretkey" and message as the two
               inputs to the hash function which is specified by the
               "HF" attribute.

           6.  Convert the message digest to its equivalent hexadecimal
               format.

           7.  Append the string for the message digest (e.g. "://
               example.com/
               content.mov?ET=1209422976&CIP=10.0.0.1&
               KID=example:keys:123&
               MD=da58513e8b309c1e8a9695baceba629d180b50b8").

       B.  For asymmetric keys, EC DSA is used.

           1.  Generate the EC private and public key pair (e.g. private
               key is "8b5b417336492707a83836b02ceee55b3847be5ec1521e494
               9977b224950e708", public key is "04840b1be11cfd1404c2fc58
               8d30150a4103cadcc4172e786bcaf15d7feeb6d246f7d8a91fa055cb1
               0efb2f52860d1d1b2f339244e9ad79a23e10ed9b720f6157f").
               Store the EC public key in a location that's reachable
               for any entity that needs to validate the URI signature.

           2.  If the key identifier is provided by the CDNI metadata,
               skip this step.  If an attribute was added to the URI,
               append an "&" character.  Append the string "KID=".
               Append the key identifier (e.g.
               "http://example.com/public/keys/123") needed by the
               entity to locate the shared key for validating the URI
               signature.  Note the Key ID URI contains only the "scheme
               name", "authority", and "path" parts (i.e. query string
               is not allowed).

           3.  If the digital signature algorithm uses the default value
               (EC-DSA), skip this step.  If an attribute was added to
               the URI, append an "&" character.  Append the string
               "DSA=".  Append the string denoting the digital signature
               function used.

           4.  If an attribute was added to the URI, append an "&"
               character.  Append the string "DS=".  The message now
               contains the complete section of the URI that is
               protected. (e.g. "://example.com/
               content.mov?ET=1209422976&CIP=10.0.0.1&KID=http://



Leung, et al.           Expires September 5, 2014              [Page 16]


Internet-Draft              CDNI URI Signing                  March 2014


               example.com/public/keys/123&DS=").

           5.  Compute the message digest using SHA-1 (without a key)
               for the message (e.g. message digest is
               "b95cb62f1d30ad03969619e9574a925fbfe9aeaf").  Note: The
               reason the digital signature calculated in the next step
               is calculated over the SHA-1 message digest, instead of
               over the cleartype message, is to reduce the length of
               the digital signature, and thereby the length of the URI
               Signing Package Attribute and the resulting Signed URI.

           6.  Compute the digital signature, using the EC-DSA algorithm
               by default or another algorithm if specified by the DSA
               Information Element, with the private EC key and message
               digest obtained in previous step as inputs.

           7.  Convert the digital signature to its equivalent
               hexadecimal format.

           8.  Append the string for the digital signature.  In the case
               where EC-DSA algorithm is used, this string contains the
               values for the 'r' and 's' parameters, delimited by ':'
               (e.g. "://example.com/
               content.mov?ET=1209422976&CIP=10.0.0.1&KID=http://
               example.com/public/keys/
               123&
               DS=r:
               CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E
               005668D:s:
               57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A
               29EA24E" )

3.2.  Packaging the URI Signature

   Apply the URI Signing Package Attribute by following the procedure
   below to generate the Signed URI.

   1.  Remove the Original URI portion from the message to obtain all
       the URI Signing Information Elements, including the URI signature
       (e.g.  "ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&&
       MD=da58513e8b309c1e8a9695baceba629d180b50b8").

   2.  Compute the URI Signing Package Attribute using Base-64 Data
       Encoding [RFC4648] on the message (e.g.  "RVQ9MTIwOTQyMjk3NiZDSVA
       9MTAuMC4wLjEmS0lEPWV4YW1wbGU6a2V5czoxMjMmJk1EPWRhNTg1MTNlOGIzMDlj
       MWU4YTk2OTViYWNlYmE2MjlkMTgwYjUwYjg=").  Note: This is the value
       for the URI Signing Package Attribute.




Leung, et al.           Expires September 5, 2014              [Page 17]


Internet-Draft              CDNI URI Signing                  March 2014


   3.  Copy the entire Original URI into a buffer to hold the message.

   4.  Check if the Original URI already contains a query string.  If
       not, append a "?" character.  If yes, append an "&" character.

   5.  Append the parameter name used to indicate the URI Signing
       Package Attribute, as communicated via the CDNI Metadata
       interface, followed by an "=".  If none is communicated by the
       CDNI Metadata interface, it defaults to "URISigningPackage".  For
       example, if the CDNI Metadata interface specifies "SIG", append
       the string "SIG=" to the message.

   6.  Append the URI Signing token to the message (e.g. "http://
       example.com/
       content.mov?URISigningPackage=RVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjE
       mS0lEPWV4YW1wbGU6a2V5czoxMjMmJk1EPWRhNTg1MTNlOGIzMDljMWU4YTk2OTVi
       YWNlYmE2MjlkMTgwYjUwYjg=").  Note: this is the completed Signed
       URI.


4.  Validating a URI Signature

   The process of validating a Signed URI can be divided into two sets
   of steps: validation of the information elements embedded in the
   Signed URI and validation of the URI Signature.  Note it is possible
   to use some other algorithm and implementation as long as the same
   result is achieved.

4.1.  Information element validation

   Extract and validate the information elements embedded in the URI.
   Note that some steps are to be skipped if the corresponding URI
   Signing Information Element is not embedded 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.  Extract the value from 'URISigningPackage' attribute.  This value
       is the encoded URI Signing Package Attribute.  If there are
       multiple instances of this attribute, the first one is used and
       the remaining ones are ignored.  This ensures that the Signed URI
       can be validated despite a client appending another instance of
       the 'URISigningPackage' attribute.

   2.  Decode the string using Base-64 Data Encoding [RFC4648] (or
       another encoding method specified by configuration or CDNI
       metadata) to obtain all the URI Signing Information Elements
       (e.g.  "ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&&



Leung, et al.           Expires September 5, 2014              [Page 18]


Internet-Draft              CDNI URI Signing                  March 2014


       MD=da58513e8b309c1e8a9695baceba629d180b50b8").

   3.  Extract the value from "VER" if the information element exists in
       the query string.  Determine the version of the URI Signing
       algorithm used to process the Signed URI.  If the CDNI Metadata
       interface is used, check to see if the used version of the URI
       Signing algorithm is among the allowed set of URI Signing
       versions specified by the metadata.  If this is not the case, the
       request is denied.  If the attribute is not in the URI, then
       obtain the version number in another manner (e.g. configuration,
       CDNI metadata or default value).

   4.  Extract the value from "CIP" if the information element exists in
       the query string.  Validate that the request came from the same
       IP address as indicated in the "CIP" attribute.  If the IP
       address is incorrect, then the request is denied.

   5.  Extract the value from "ET" if the information element exists in
       the query string.  Validate that the request arrived before
       expiration time based on the "ET" attribute.  If the time
       expired, then the request is denied.

   6.  Extract the value from "MD" if the information element exists in
       the query string.  The existence of this information element
       indicates a symmetric key is used.

   7.  Extract the value from "DS" if the information element exists in
       the query string.  The existence of this information element
       indicates a asymmetric key is used.

   8.  If neither "MD" or "DS" attribute is in the URI, then no URI
       Signature exists and the request is denied.  If both the "MD" and
       the "DS" information elements are present, the Signed URI is
       considered to be malformed and the request is denied.

4.2.  Signature validation

   Validate the URI Signature for the Signed URI.

   1.  Copy the Original URI, excluding the "scheme name" part, into a
       buffer to hold the message for performing the operations below.

   2.  Remove the "URISigningPackage" attribute from the message.
       Remove any subsequent part of the query string after the
       "URISigningPackage" attribute.

   3.  Append the decoded value from "URISigningPackage" attribute
       (which contains all the URI Signing Information Elements).



Leung, et al.           Expires September 5, 2014              [Page 19]


Internet-Draft              CDNI URI Signing                  March 2014


   4.  Depending on the type of key used to sign the URI, validate the
       message digest or digital signature for symmetric key or
       asymmetric keys, respectively.

       A.  For symmetric key, HMAC algorithm is used.

           a.  Extract the value from the "KID" information element, if
               it exists.  Use the key identifier (e.g. "example:keys:
               123") to locate the shared key, which may be one of the
               keys available to use (i.e. set by configuration or CDNI
               metadata).  If the information element is not in the URI
               Signing Package Attribute, then obtain the key in another
               manner (e.g. configuration or 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
               it exists.  Determine the type of hash function (e.g.
               "MD5", "SHA-1", "SHA-256", "SHA-3") to use for HMAC.  If
               the information element is not in the URI, the default
               hash function is SHA-1.  If the "HF" information element
               is present but its value is not in the the allowable "HF"
               set as listed in the CDNI metadata, the request is
               denied.

           c.  Extract the value from the "MD" information element.
               This is the received message digest.

           d.  Convert the message digest to binary format.  This will
               be used to compare with the computed value later.

           e.  Remove the value part of the "MD" information element
               (but not the '=' character) from the message.  The
               message is ready for validation of the message digest
               (e.g. "://example.com/
               content.mov?ET=1209422976&CIP=10.0.0.1&
               KID=example:keys:123&MD=").

           f.  Compute the message digest using the HMAC algorithm with
               the shared key and message as the two inputs to the hash
               function which is specified by the "HF" attribute.

           g.  Compare the result with the received message digest to
               validate the Signed URI.






Leung, et al.           Expires September 5, 2014              [Page 20]


Internet-Draft              CDNI URI Signing                  March 2014


       B.  For asymmetric keys, a digital signature function is used.

           a.  Extract the value from the "KID" information element, if
               it exists.  Use the key identifier (e.g.
               "http://example.com/public/keys/123") to obtain the EC
               public key, which may be one of the keys available to use
               (i.e. set by configuration or CDNI metadata).  If the
               information element is not in the URI, then obtain the
               key in another manner (e.g. configuration or CDNI
               metadata).

           b.  Extract the value from the "DSA" information element, if
               it exists.  Determine the type of digital signature
               function (e.g.  "RSA", "DSA", "EC-DSA") to use for
               calculating the Digital Signature.  If the information
               element is not in the URI, the default digital signature
               function is EC-DSA.  If the "DSA" information element is
               present but its value is not in the the allowable "EC-
               DSA" set as listed in the CDNI metadata, the request is
               denied.

           c.  Extract the value from the "DS" information element.
               This is the digital signature.

           d.  Convert the digital signature to binary format.  This
               will be used for verification later.

           e.  Remove the value part of the "DS" information element
               (but not the '=' character) from the message.  The
               message is ready for validation of the digital signature
               (e.g. "://example.com/
               content.mov?ET=1209422976&CIP=10.0.0.1&KID=http://
               example.com/public/keys/123&DS=").

           f.  Compute the message digest using SHA-1 (without a key)
               for the message.

           g.  Verify the digital signature using the digital signature
               function (e.g.  EC-DSA) with the public key, received
               digital signature, and message digest (obtained in
               previous step) as inputs.  This validates the Signed URI.


5.  Relationship with CDNI Interfaces

   Some of the CDNI Interfaces need enhancements to support URI Signing.
   As an example: A Downstream CDN that supports URI Signing needs to be
   able to advertise this capability to the Upstream CDN.  The Upstream



Leung, et al.           Expires September 5, 2014              [Page 21]


Internet-Draft              CDNI URI Signing                  March 2014


   CDN needs to select a Downstream CDN based on such capability when
   the CSP requires access control to enforce its distribution policy
   via URI Signing.  Also, the Upstream CDN needs to be able to
   distribute via the CDNI Metadata interface the information necessary
   to allow the Downstream CDN to validate a Signed URI .  Events that
   pertain to URI Signing (e.g. request denial or delivery after access
   authorization) need to be included in the logs communicated through
   the CDNI Logging interface (Editor's Note: Is this within the scope
   of the CDNI Logging interface?).

5.1.  CDNI Control Interface

   URI Signing has no impact on this interface.

5.2.  CDNI Footprint & Capabilities Advertisement Interface

   The Downstream CDN advertises its capability to support URI Signing
   via the CDNI Footprint & Capabilities Advertisement interface (FCI).
   The supported version of URI Signing needs to be included to allow
   for future extensibility.

   [Editor's Note: To be discussed with FCI authors]

5.3.  CDNI Request Routing Redirection Interface

   [Editor's Note: Debate the approach of dCDN providing the Signed URI
   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:

   1.  Downstream CDN provides the Signed URI

       *  Key distribution is not necessary

       *  Downstream CDN can use any scheme for Signed URI as long as
          the security level meets the CSP's expectation

   2.  Upstream CDN signs the URI

       *  Consistency with interative request routing method

       *  URI Signing works 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)





Leung, et al.           Expires September 5, 2014              [Page 22]


Internet-Draft              CDNI URI Signing                  March 2014


       *  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

   The following CDNI Metadata objects are specified for URI Signing.

   o  URI Signing enforcement flag.  Specifically, this 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 key identifier used for URI Signing computation when
      the Signed URI does not contain the Key ID information element

   o  Allowable Key ID set that the Signed URI's Key ID information
      element can reference

   o  Designated hash function used for URI Signing computation when the
      Signed URI does not contain the Hash Function information element

   o  Allowable Hash Function set that the Signed URI's Hash Function
      information element can reference

   o  Designated digital signature function used for URI Signing
      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
      Digital Signature Algorithm information element can reference.

   o  Designated version used for URI Signing computation when the
      Signed URI does not contain the VER attribute

   o  Allowable version/algorithm set that the Signed URI's VER
      attribute can reference

   o  Allowable set of Downstream CDNs that participate in URI Signing
      based on the symmetric key

   o  Overwrite the default encoding method for URI Signing Attribute
      Set attribute?  [Editor's Note: Do we need this?]

   o  Overwrite the default name for the URL Signing Attribute Set
      attribute?  [Editor's Note: Do we need this?]



Leung, et al.           Expires September 5, 2014              [Page 23]


Internet-Draft              CDNI URI Signing                  March 2014


   Note that the Key ID information 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 MUST provide the public key for the content
   or information to authorize the received Key ID attribute.

5.5.  CDNI Logging Interface

   The Downstream CDN reports that enforcement of the access control was
   applied to the request for content delivery.

   The following CDNI Logging field for URI Signing SHOULD be supported
   in the HTTP Request Logging Record as specified in CDNI Logging
   Interface [I-D.ietf-cdni-logging].

   o  s-uri-signing:

      *  format: 1DIGIT

      *  field value: this characterises the uri signing validation
         performed by the Surrogate on the request.  The allowed values
         are:

         +  "0" : no uri signature validation performed

         +  "1" : uri signature validation performed and validated

         +  "2" : uri signature validation performed and rejected

      *  occurrence: there MUST be zero or exactly one instance of this
         field.

   [Editor's note: Need to log these URI signature validation events
   (e.g. invalid client IP address, expired signed URI, incorrect URI
   signature, successful validation)?]

   TBD: CDNI Logging interface is work in progress.


6.  URI Signing Message Flow

   URI Signing supports both HTTP-based and DNS-based request routing.
   HMAC [RFC2104] defines a hash-based message authentication code
   allowing two parties that share a symmetric key or asymmetric keys to



Leung, et al.           Expires September 5, 2014              [Page 24]


Internet-Draft              CDNI URI Signing                  March 2014


   establish the integrity and authenticity of a set of information
   (e.g. a message) through a cryptographic hash function.

6.1.  HTTP Redirection

   For HTTP-based request routing, HMAC is applied to a set of
   information that is unique to a given end user content request using
   key information that is specific to a pair of adjacent CDNI hops
   (e.g. between the CSP and the Authoritative CDN, between the
   Authoritative CDN and a Downstream CDN).  This allows a CDNI hop to
   ascertain the authenticity of a given request received from a
   previous CDNI hop.

   The URI signing scheme described below is based on the following
   steps (assuming HTTP redirection, iterative request routing and a CDN
   path with two CDNs).  Note that Authoritative CDN and Upstream CDN
   are used exchangeably.

    End-User              dCDN                 uCDN                  CSP
       |                    |                    |                    |
       |            1.CDNI FCI interface used to |                    |
       |         advertise URI Signing capability|                    |
       |                    |------------------->|                    |
       |                    |                    |                    |
       |              2.Provides information to validate URI signature|
       |                    |                    |<-------------------|
       |                    |                    |                    |
       |        3.CDNI Metadata interface used to|                    |
       |           provide URI Signing attributes|                    |
       |                    |<-------------------|                    |
       |4.Authorization request                  |                    |
       |------------------------------------------------------------->|
       |                    |                    |  [Apply distribution
       |                    |                    |   policy]          |
       |                    |                    |                    |
       |                    |              (ALT: Authorization decision)
       |5.Request is denied |                    |      <Negative>    |
       |<-------------------------------------------------------------|
       |                    |                    |                    |
       |6.CSP provides signed URI                |      <Positive>    |
       |<-------------------------------------------------------------|
       |                    |                    |                    |
       |7.Content request   |                    |                    |
       |---------------------------------------->| [Validate URI      |
       |                    |                    |  signature]        |
       |                    |                    |                    |
       |                    |    (ALT: Validation result)             |
       |8.Request is denied |          <Negative>|                    |



Leung, et al.           Expires September 5, 2014              [Page 25]


Internet-Draft              CDNI URI Signing                  March 2014


       |<----------------------------------------|                    |
       |                    |                    |                    |
       |9.Re-sign URI and redirect to  <Positive>|                    |
       |  dCDN (newly signed URI)                |                    |
       |<----------------------------------------|                    |
       |                    |                    |                    |
       |10.Content request  |                    |                    |
       |------------------->| [Validate URI      |                    |
       |                    |  signature]        |                    |
       |                    |                    |                    |
       |    (ALT: Validation result)             |                    |
       |11.Request is denied| <Negative>         |                    |
       |<-------------------|                    |                    |
       |                    |                    |                    |
       |12.Content delivery | <Positive>         |                    |
       |<-------------------|                    |                    |
       :                    :                    :                    :
       :   (Later in time)  :                    :                    :
       |13.CDNI Logging interface to include URI Signing information  |
       |                    |------------------->|                    |

           Figure 3: HTTP-based Request Routing with URI Signing

   1.   Using the CDNI Footprint & Capabilities Advertisement interface,
        the Downstream CDN advertises its capabilities including URI
        Signing support to the Authoritative CDN.

   2.   CSP provides to the Authoritative CDN the information needed to
        validate URI signatures from that CSP.  For example, this
        information may include a hashing function, algorithm, and a key
        value.

   3.   Using the CDNI Metadata interface, the Authoritative CDN
        communicates to a Downstream CDN the information needed to
        validate URI signatures from the Authoritative CDN for the given
        CSP.  For example, this information may include the URI query
        string parameter name for the URI Signing Package Attribute, a
        hashing algorithm and/or a key corresponding to the trust
        relationship between the Authoritative CDN and the Downstream
        CDN.

   4.   When a UA requests a piece of protected content from the CSP,
        the CSP makes a specific authorization decision for this unique
        request based on its arbitrary distribution policy

   5.   If the authorization decision is negative, the CSP rejects the
        request.




Leung, et al.           Expires September 5, 2014              [Page 26]


Internet-Draft              CDNI URI Signing                  March 2014


   6.   If the authorization decision is positive, the CSP computes a
        Signed URI that is based on unique parameters of that request
        and conveys it to the end user as the URI to use to request the
        content.

   7.   On receipt of the corresponding content request, the
        authoritative CDN validates the URI Signature in the URI using
        the information provided by the CSP.

   8.   If the validation is negative, the authoritative CDN rejects the
        request

   9.   If the validation is positive, the authoritative CDN computes a
        Signed URI that is based on unique parameters of that request
        and provides to the end user as the URI to use to further
        request the content from the Downstream CDN

   10.  On receipt of the corresponding content request, the Downstream
        CDN validates the URI Signature in the Signed URI using the
        information provided by the Authoritative CDN in the CDNI
        Metadata

   11.  If the validation is negative, the Downstream CDN rejects the
        request and sends an error code (e.g. 403) in the HTTP response.

   12.  If the validation is positive, the Downstream CDN serves the
        request and delivers the content.

   13.  At a later time, Downstream CDN reports logging events that
        includes URI signing information.

   With HTTP-based request routing, URI Signing matches well the general
   chain of trust model of CDNI both with symmetric key and asymmetric
   keys because the key information only need to be specific to a pair
   of adjacent CDNI hops.

6.2.  DNS Redirection

   For DNS-based request routing, the CSP and Authoritative CDN must
   agree on a trust model appropriate to the security requirements of
   the CSP's particular content.  Use of asymmetric public/private keys
   allows for unlimited distribution of the public key to Downstream
   CDNs.  However, if a shared secret key is preferred, then the CSP may
   want to restrict the distribution of the key to a (possibly empty)
   subset of trusted Downstream CDNs.  Authorized Delivery CDNs need to
   obtain the key information to validate the Signed UR, which is
   computed by the CSP based on its distribution policy.




Leung, et al.           Expires September 5, 2014              [Page 27]


Internet-Draft              CDNI URI Signing                  March 2014


   The URI signing scheme described below is based on the following
   steps (assuming iterative DNS request routing and a CDN path with two
   CDNs).  Note that Authoritative CDN and Upstream CDN are used
   exchangeably.

    End-User              dCDN                 uCDN                  CSP
       |                    |                    |                    |
       |            1.CDNI FCI interface used to |                    |
       |         advertise URI Signing capability|                    |
       |                    |------------------->|                    |
       |                    |                    |                    |
       |              2.Provides information to validate URI signature|
       |                    |                    |<-------------------|
       |        3.CDNI Metadata interface used to|                    |
       |           provide URI Signing attributes|                    |
       |                    |<-------------------|                    |
       |4.Authorization request                  |                    |
       |------------------------------------------------------------->|
       |                    |                    |  [Apply distribution
       |                    |                    |   policy]          |
       |                    |                    |                    |
       |                    |              (ALT: Authorization decision)
       |5.Request is denied |                    |      <Negative>    |
       |<-------------------------------------------------------------|
       |                    |                    |                    |
       |6.Provides signed URI                    |      <Positive>    |
       |<-------------------------------------------------------------|
       |                    |                    |                    |
       |7.DNS request       |                    |                    |
       |---------------------------------------->|                    |
       |                    |                    |                    |
       |8.Redirect DNS to dCDN                   |                    |
       |<----------------------------------------|                    |
       |                    |                    |                    |
       |9.DNS request       |                    |                    |
       |------------------->|                    |                    |
       |                    |                    |                    |
       |10.IP address of Surrogate               |                    |
       |<-------------------|                    |                    |
       |                    |                    |                    |
       |11.Content request  |                    |                    |
       |------------------->| [Validate URI      |                    |
       |                    |  signature]        |                    |
       |                    |                    |                    |
       |    (ALT: Validation result)             |                    |
       |12.Request is denied| <Negative>         |                    |
       |<-------------------|                    |                    |
       |                    |                    |                    |



Leung, et al.           Expires September 5, 2014              [Page 28]


Internet-Draft              CDNI URI Signing                  March 2014


       |13.Content delivery | <Positive>         |                    |
       |<-------------------|                    |                    |
       :                    :                    :                    :
       :   (Later in time)  :                    :                    :
       |14.CDNI Logging interface to report URI Signing information   |
       |                    |------------------->|                    |

           Figure 4: DNS-based Request Routing with URI Signing

   1.   Using the CDNI Footprint & Capabilities Advertisement interface,
        the Downstream CDN advertises its capabilities including URI
        Signing support to the Authoritative CDN.

   2.   CSP provides to the Authoritative CDN the information needed to
        validate cryptographic signatures from that CSP.  For example,
        this information may include a hash function, algorithm, and a
        key.

   3.   Using the CDNI Metadata interface, the Authoritative CDN
        communicates to a Downstream CDN the information needed to
        validate cryptographic signatures from the CSP (e.g. the URI
        query string parameter name for the URI Signing Package
        Attribute).  In the case of symmetric key, the Authoritative CDN
        checks if the Downstream CDN is allowed by CSP to obtain the
        shared secret key.

   4.   When a UA requests a piece of protected content from the CSP,
        the CSP makes a specific authorization decision for this unique
        request based on its arbitrary distribution policy.

   5.   If the authorization decision is negative, the CSP rejects the
        request

   6.   If the authorization decision is positive, the CSP computes a
        cryptographic signature that is based on unique parameters of
        that request and includes it in the URI provided to the end user
        to request the content.

   7.   End user sends DNS request to the authoritative CDN.

   8.   On receipt of the DNS request, the authoritative CDN redirects
        the request to the Downstream CDN.

   9.   End user sends DNS request to the Downstream CDN.

   10.  On receipt of the DNS request, the Downstream CDN responds with
        IP address of one of its Surrogates.




Leung, et al.           Expires September 5, 2014              [Page 29]


Internet-Draft              CDNI URI Signing                  March 2014


   11.  On receipt of the corresponding content request, the Downstream
        CDN validates the cryptographic signature in the URI using the
        information provided by the Authoritative CDN in the CDNI
        Metadata

   12.  If the validation is negative, the Downstream CDN rejects the
        request and sends an error code (e.g. 403) in the HTTP response.

   13.  If the validation is positive, the Downstream CDN serves the
        request and delivers the content.

   14.  At a later time, Downstream CDN reports logging events that
        includes URI signing information.

   With DNS-based request routing, URI Signing matches well the general
   chain of trust model of CDNI when used with asymmetric keys because
   the only key information that need to be distributed across multiple
   CDNI hops including non-adjacent hops is the public key, that is
   generally not confidential.

   With DNS-based request routing, URI Signing does not match well the
   general chain of trust model of CDNI when used with symmetric keys
   because the symmetric key information needs to be distributed across
   multiple CDNI hops including non-adjacent hops.  This raises a
   security concern for applicability of URI Signing with symmetric keys
   in case of DNS-based inter-CDN request routing.


7.  HTTP Adaptive Streaming

   The authors note that in order to perform URI signing for individual
   content segments of HTTP Adaptive Bitrate content, specific URI
   signing mechanisms are needed.  Such mechanisms are currently out-of-
   scope of this document.  More details on this topic is covered in
   Models for HTTP-Adaptive-Streaming-Aware CDNI [RFC6983].


8.  IANA Considerations

   [Editor's note: (Is there a need to) register default value for URI
   Signing Package Attribute URI query string parameter name (i.e.
   URISigningPackage) to be used for URI Signing?  Need anything from
   IANA?]

   [Editor's note: To do: Convert to proper IANA Registry format]

   This document requests IANA to create three new registries for the
   Information Elements and their defined values to be used for URI



Leung, et al.           Expires September 5, 2014              [Page 30]


Internet-Draft              CDNI URI Signing                  March 2014


   Signing.

   The following Enforcement Information Element names are allocated:

   o  ET (Expiry time)

   o  CIP (Client IP address)

   The following Signature Computation Information Element names are
   allocated:

   o  VER (Version): 1(Base)

   o  KID (Key ID)

   o  HF (Hash Function): "MD5", "SHA-1", "SHA-256", "SHA-3"

   o  DSA (Digital Signature Algorithm): "RSA, "DSA", "EC-DSA"

   The following URI Signature Information Element names are allocated:

   o  MD (Message Digest)

   o  DS (Digital Signature)

   The IANA is requested to allocate a new entry to the CDNI Logging
   Field Names Registry as specified in CDNI Logging Interface
   [I-D.ietf-cdni-logging] in accordance to the "Specification Required"
   policy [RFC5226]

   o  s-url-signing

   o  [Editor's note: logging error codes are needed for URI Signing?]

   The IANA is requested to allocate a new entry to the CDNI Metadata
   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

   o  More metadata...


9.  Security Considerations

   This document describes the concept of URI Signing and how it can be
   used to provide access authorization in the case of interconnected



Leung, et al.           Expires September 5, 2014              [Page 31]


Internet-Draft              CDNI URI Signing                  March 2014


   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
   Service Provider (CSP) being able to authorize every individual
   request.  It should be noted that URI Signing is not a content
   protection scheme; if a CSP wants to protect the content itself,
   other mechanisms, such as DRM, are more appropriate.

   In general, it holds that the level of protection against
   illegitimate access can be increased by including more Enforcement
   Information Elements in the URI.  The current version of this
   document includes elements for enforcing Client IP Address and
   Expiration Time, however this list can be extended with other, more
   complex, attributes that are able to provide some form of protection
   against some of the vulnerabilities highlighted below.

   That said, there are a number of aspects that limit the level of
   security offered by URI signing and that anybody implementing URI
   signing should be aware of.

      Replay attacks: Any (valid) Signed URI can be used to perform
      replay attacks.  The vulnerability to replay attacks can be
      reduced by picking a relatively short window for the Expiration
      Time attribute, although this is limited by the fact that any
      HTTP-based request needs a window of at least a couple of seconds
      to prevent any sudden network issues from preventing legitimate
      UAs access to the content.  One way to reduce exposure to replay
      attacks is to include in the URI a unique one-time access ID.
      Whenever the Downstream CDN receives a request with a given unique
      access ID, it adds that access ID to the list of 'used' IDs.  In
      the case an illegitimate UA tries to use the same URI through a
      replay attack, the Downstream CDN can deny the request based on
      the already-used access ID.

      Illegitimate client behind a NAT: In cases where there are
      multiple users behind the same NAT, all users will have the same
      IP address from the point of view of the Downstream CDN.  This
      results in the Downstream CDN not being able to distinguish
      between the different users based on Client IP Address and
      illegitimate users being able to access the content.  One way to
      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
      HTTP headers.

      TBD: ...

   The shared key between CSP and Authoritative CDN may be distributed
   to Downstream CDNs - including cascaded CDNs.  Since this key can be
   used to legitimately sign a URL for content access authorization,



Leung, et al.           Expires September 5, 2014              [Page 32]


Internet-Draft              CDNI URI Signing                  March 2014


   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

   The privacy protection concerns described in CDNI Logging Interface
   [I-D.ietf-cdni-logging] apply when the client's IP address (CIP
   attribute) is embedded in the Signed URI.  This means that, when
   anonymization is enabled, the URI Signing Package Attribute MUST be
   removed from the logging record.


11.  Acknowledgements

   The authors would like to thank the following people for their
   contributions in reviewing this document and providing feedback:
   Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan York, Bhaskar
   Bhupalam, Matt Caulfield, and Samuel Rajakumar .


12.  References

12.1.  Normative References

   [I-D.ietf-cdni-logging]
              Faucheur, F., Bertrand, G., Oprescu, I., and R.
              Peterkofsky, "CDNI Logging Interface",
              draft-ietf-cdni-logging-10 (work in progress), March 2014.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, September 2012.

12.2.  Informative References

   [I-D.ietf-cdni-framework]
              Peterson, L., Davie, B., and R. Brandenburg, "Framework
              for CDN Interconnection", draft-ietf-cdni-framework-10
              (work in progress), March 2014.



Leung, et al.           Expires September 5, 2014              [Page 33]


Internet-Draft              CDNI URI Signing                  March 2014


   [I-D.ietf-cdni-metadata]
              Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
              Leung, K., and K. Ma, "CDN Interconnect Metadata",
              draft-ietf-cdni-metadata-06 (work in progress),
              February 2014.

   [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-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              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.,
              and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
              Content Distribution Network Interconnection (CDNI)",
              RFC 6983, July 2013.


Authors' Addresses

   Kent Leung
   Cisco Systems
   3625 Cisco Way
   San Jose  95134
   USA

   Phone: +1 408 526 5030
   Email: kleung@cisco.com





Leung, et al.           Expires September 5, 2014              [Page 34]


Internet-Draft              CDNI URI Signing                  March 2014


   Francois Le Faucheur
   Cisco Systems
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis  06410
   France

   Phone: +33 4 97 23 26 19
   Email: flefauch@cisco.com


   Bill Downey
   Verizon Labs
   60 Sylvan Road
   Waltham, Massachusetts  02451
   USA

   Phone: +1 781 466 2475
   Email: william.s.downey@verizon.com


   Ray van Brandenburg
   TNO
   Brassersplein 2
   Delft,   2612CT
   the Netherlands

   Phone: +31 88 866 7000
   Email: ray.vanbrandenburg@tno.nl


   Scott Leibrand
   Limelight Networks
   222 S Mill Ave
   Tempe, AZ  85281
   USA

   Phone: +1 360 419 5185
   Email: sleibrand@llnw.com













Leung, et al.           Expires September 5, 2014              [Page 35]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/