CDNI                                                            K. Leung                                                  R. van Brandenburg
Internet-Draft                                            F. Le Faucheur                                                       TNO
Intended status: Standards Track                           Cisco Systems                                K. Leung
Expires: December 30, 2016                            R. van Brandenburg
                                                                     TNO
                                                               B. Downey
                                                            Verizon Labs April 7, 2017                               Cisco Systems, Inc.
                                                               P. Sorber
                                            Comcast Cable Communications
                                                               M. Fisher
                                                      Limelight Networks
                                                           June 28, Miller
                                                     Cisco Systems, Inc.
                                                         October 4, 2016

               URI Signing for CDN Interconnection (CDNI)
                     draft-ietf-cdni-uri-signing-09
                     draft-ietf-cdni-uri-signing-10

Abstract

   This document describes how the concept of URI signing supports the
   content access control requirements of CDNI and proposes a URI
   signing scheme. method as a JSON Web Token (JWT) [RFC7519] profile.

   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 transmit the content referenced signed JWT as well as the
   claims needed by the URI. signed JWT to authorize a UA.  The mechanism
   described can be used both in CDNI and single CDN scenarios.

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 December 30, 2016. April 7, 2017.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Background and overview on URI Signing  . . . . . . . . .   5   4
     1.3.  CDNI URI Signing Overview . . . . . . . . . . . . . . . .   6   5
     1.4.  URI Signing in a non-CDNI context . . . . . . . . . . . .   8   7
   2.  Signed URI Information Elements  JWT Format and Processing Requirements  . . . . . . . . . . .   7
     2.1.  JWT Claims  . . . .   8
     2.1.  Enforcement Information Elements . . . . . . . . . . . .  10
     2.2.  Signature Computation Information Elements . . . . . . .  12
     2.3.   8
       2.1.1.  URI Signature Information Elements Container Forms . . . . . . . . . . .  14
     2.4.  URI Signing Package Attribute . . . . . .  10
         2.1.1.1.  URI Simple Container (uri:) . . . . . . . .  15
     2.5.  User Agent Attributes . . .  11
         2.1.1.2.  URI Pattern Container (uri-pattern:)  . . . . . .  11
         2.1.1.3.  URI Regular Expression Container (uri-regex:) . .  12
   3.  Relationship with CDNI Interfaces . . . . . . .  16
   3.  Create a Signed URI . . . . . . .  12
     3.1.  CDNI Control Interface  . . . . . . . . . . . . . .  16
     3.1.  Compose URI Signing IEs with Protected URI . . .  12
     3.2.  CDNI Footprint & Capabilities Advertisement Interface . .  12
     3.3.  CDNI Request Routing Redirection Interface  . .  17
     3.2.  Compute URI Signature . . . . .  13
     3.4.  CDNI Metadata Interface . . . . . . . . . . . . .  19
     3.3.  Encode the URI Signing Package . . . .  13
     3.5.  CDNI Logging Interface  . . . . . . . . .  20
     3.4.  Assemble the Signed URI . . . . . . . .  14
   4.  URI Signing Message Flow  . . . . . . . . .  20
   4.  Validate a Signed URI . . . . . . . . .  15
     4.1.  HTTP Redirection  . . . . . . . . . . .  22
     4.1.  Extract and Decode URI Signing Package . . . . . . . . .  22  16
     4.2.  Extract URI Signing IEs . .  DNS Redirection . . . . . . . . . . . . . . .  22
     4.3.  Obtain URI Signing IEs with Protected URI . . . . . .  18
   5.  HTTP Adaptive Streaming . .  24
     4.4.  Validate URI Signature . . . . . . . . . . . . . . . . .  25
     4.5.  Distribution Policy Enforcement  21
   6.  IANA Considerations . . . . . . . . . . . . .  26
   5.  Relationship with CDNI Interfaces . . . . . . . .  21
     6.1.  CDNI Payload Type . . . . . .  27
     5.1.  CDNI Control Interface . . . . . . . . . . . . . .  21
       6.1.1.  CDNI UriSigning Payload Type  . . .  27
     5.2.  CDNI Footprint & Capabilities Advertisement Interface . .  27
     5.3.  CDNI Request Routing Redirection Interface . . . . . . .  28
     5.4.  21
     6.2.  CDNI Metadata Interface . Logging Record Type  . . . . . . . . . . . . . . . .  28
     5.5.  22
       6.2.1.  CDNI Logging Interface  . . Record Version 2 for HTTP  . . . . . . .  22
     6.3.  CDNI Logging Field Names  . . . . . . . .  32
   6.  URI Signing Message Flow . . . . . . . .  22
   7.  Security Considerations . . . . . . . . . .  33
     6.1.  HTTP Redirection . . . . . . . . .  22
   8.  Privacy . . . . . . . . . . .  33
     6.2.  DNS Redirection . . . . . . . . . . . . . . . . . . . . .  36

   7.  HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . .  39
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  39
     8.1.  CDNI Payload Type . . . . . . . . . . . . . . . . . . . .  39
       8.1.1.  CDNI UriSigning Payload Type  . . . . . . . . . . . .  39
     8.2.  CDNI Logging Record Type  . .  24
   9.  Acknowledgements  . . . . . . . . . . . . . .  40
       8.2.1.  CDNI Logging Record Version 2 for HTTP . . . . . . .  40
     8.3.  CDNI Logging Field Names .  24
   10. References  . . . . . . . . . . . . . . .  40
     8.4.  CDNI Metadata Auth Type . . . . . . . . . .  24
     10.1.  Normative References . . . . . . .  40
     8.5.  CDNI URI Signing Enforcement Information Elements . . . .  41
     8.6.  CDNI URI Signing Signature Computation Information
           Elements . . . . . . .  24
     10.2.  Informative References . . . . . . . . . . . . . . . . .  41
     8.7.  CDNI  25
   Appendix A.  Signed URI Signing Signature Information Elements . . . . .  42
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  43
   10. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . .  44
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  44
   12. References  . . . . . Package Example . . . . . . . . . . . . .  26
     A.1.  Simple Example  . . . . . . .  44
     12.1.  Normative References . . . . . . . . . . . . . .  26
     A.2.  Complex Example . . . .  44
     12.2.  Informative References . . . . . . . . . . . . . . . . .  45  27

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46  28

1.  Introduction

   This document describes the concept of URI Signing and how it can be
   used to provide access authorization in the case of redirection
   between interconnected CDNs (CDNI) and between a Content Service
   Provider (CSP) and a CDN.  The primary goal of URI Signing is to make
   sure that only authorized User Agents (UAs) are able to access the
   content, with a 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 addition to access
   control, URI Signing also has benefits in reducing the impact of
   denial-of-service attacks.

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

   Specifically, CDNI Framework [RFC7336] 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 [RFC7337]:

   "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 method of signing URIs 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 the CSP and the role of validation of validating 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

   The key words representation of this method is a Signed JSON Web Token (JWT)
   [RFC7519].

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

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

   This document also uses the terminology of Keyed-Hashing for Message
   Authentication (HMAC) [RFC2104]. JSON Web Token (JWT)
   [RFC7519].

   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  Full Original URI: The URI before URI Signing is applied.

   o  Signed URI: Any A URI that contains a URI Signature. signed JWT for itself.

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

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

1.2.  Background and overview on URI Signing

   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
   claims in the form of a signed JWT 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
   attributes need to be added to  To
   prevent 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 altering the URI.  The message digest or digital signature can
   be calculated based on claims a shared secret between the CSP and CDN or
   using CSP's asymmetric public/private key pair, respectively. signed JWT is REQUIRED.

   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 signed JWT which is
   generated by the CSP using the a shared secret or a private key.  Once the
   UA receives the response with the embedded Signed URI, it sends a new HTTP
   request using the embedded Signed 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. signed JWT.  If applicable, 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 claims 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

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 uCDN and the Downstream CDN. dCDN.
   In step #3, UA may send an HTTP request or a DNS request.  Depending
   on whether HTTP-based or DNS-based request routing is used, the Upstream CDN uCDN
   responds by directing the UA towards the Downstream CDN dCDN using either a
   Redirection URI (which is a Signed URI generated by the Upstream CDN) uCDN) or a
   DNS reply, respectively (#4).  Once the UA receives the response, it
   sends the Redirection URI/Target CDN URI to the Downstream CDN dCDN (#5).  The
   received URI is validated by the Downstream CDN dCDN 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). 4).

                                      +-------------------------+
                                      |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, uCDN, and Downstream CDN dCDN 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. uCDN.  The delivery
   of the content may be delegated to the
   Downstream CDN, dCDN, which has a relationship
   with the Upstream CDN uCDN but 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 dCDN directly.  In
   the case where the Downstream CDN dCDN does not have a trust relationship with the
   CSP, this means that only either an asymmetric public/
   private public/private key method can
   needs to be used for computing the URI Signature
   because signed JWT (because the CSP and Downstream CDN
   dCDN 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, keys), or the
   CSP may choose needs to allow the Authoritative CDN uCDN to redistribute the shared key keys to a subset
   of their Downstream CDNs dCDNs .

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

1.4.  URI Signing in a non-CDNI context

   While the URI signing scheme method 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 method 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  JWT Format and Processing Requirements

   The concept behind URI Signing is based on embedding a signed JSON
   Web Token (JWT) [RFC7519] in the Target CDN URI/Redirection URI URI.  The
   signed JWT contains a number of information elements claims 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.

   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: (URISigningPackage): The URI attribute that
      encapsulates all the URI Signing information elements claims in an a signed JWT encoded
      format.
      Only this  This attribute is exposed in the Signed URI as a URI
      query parameter or as a URL path parameter.

   Two types

   The parameter name 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 Signing Package Attribute is defined in
   the Signed URI.  With symmetric keys, CDNI Metadata.  If the same key CDNI Metadata interface is
   used by both the signing entity not used, or
   does not include a parameter name for signing the URI as well as by the
   validating entity for validating Signing Package
   Attribute, 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
   requirements for key distribution parameter name can be set by configuration (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.

   Note that all the URI Signing information elements and the URI query
   attribute are mandatory to implement, but not mandatory to use. document).

2.1.  Enforcement Information Elements  JWT Claims

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

   In order to provide flexibility in distribution policies to be
   enforced, policy flexibility, the exact subset
   of information elements claims used in the URI
   Signature of a given request signed JWT is a deployment runtime decision.  The  Claim
   requirements are defined
   keyword for each information element in the CDNI Metadata.  If the CDNI Metadata
   interface is not used, or does not include claim requirements, the
   claim requirements can be set by configuration (out of scope of this
   document).

   The following claims (where the "JSON Web Token Claims" registry
   claim name is specified in parenthesis
   below.

   The following information elements below) 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 policies.  All 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 listed claims are mandatory to
   implement in a URI need Signing implementation, but are not mandatory to be
   use in sync.  In the CDNI case,
      this means that servers at both the CSP, uCDN a given signed JWT.  (The "optional" and dCDN need "mandatory"
   identifiers in square brackets refer to be
      time-synchronized.  It whether or not a given claim
   MUST be present in a URI Signing JWT.)  A CDN MUST be able to parse
   and process all of the claims listed below.  If the signed JWT
   contains any claims which the CDN does not understand (i.e., is RECOMMENDED
   unable to use NTP parse and process), the CDN MUST reject the request.

   o  Issuer (iss) [optional] - The semantics in [RFC7519] Section 4.1.1
      MUST be followed.  This claim MAY be used to validate
      authorization of the issuer of a signed JWT and also MAY be used
      to confirm that the indicated key was provided by said issuer.  If
      the CDN validating the signed JWT does not support Issuer
      validation, or if the Issuer in the signed JWT does not match the
      list of known acceptable Issuers, the CDN MUST reject the request.
      If the received signed JWT contains an Issuer claim, then any JWT
      subsequently generated for CDNI redirection MUST also contain an
      Issuer claim, and the Issuer value MUST be updated to identify the
      redirecting CDN.  If the received signed JWT does not contain an
      Issuer claim, an Issuer claim MAY be added to a signed JWT
      generated for CDNI redirection.

   o  URI Container (sub) [mandatory] - The semantics in [RFC7519]
      Section 4.1.2 MUST be followed.  Container for this. holding the URI
      representation before the URI Signing Package is added.  This
      representation can take one of several forms detailed in
      Section 2.1.1.  If the URI pattern/regex in the signed JWT does
      not match the URI of the content request, the CDN validating the
      signed JWT MUST reject the request.  When redirecting a URI, the
      CDN generating the new signed JWT MAY change the URI Container to
      comport with the URI being used in the redirection.

   o  Client IP (CIP) (aud) [optional] - The semantics in [RFC7519]
      Section 4.1.3 MUST be followed.  IP address, or IP prefix, for
      which the Signed URI is valid.  This is represented in CIDR
      notation, with dotted decimal format for IPv4 or canonical text
      representation for IPv6 addresses [RFC5952].  The request is
      rejected if sourced from a client outside of the specified IP
      range.

   o  Original URI Container (OUC) [optional] - Container for holding
      the Full Original URI while  Since the URI signature client IP is calculated.  The
      Original URI Container considered personally identifiable
      information element is not transmitted as
      part of the URI Signing Package Attribute.  If the Original URI
      Container information element is used, the URI Pattern Sequence
      information element this field MUST NOT be used.

   o  URI Pattern Container (UPC) [optional] - Percent-encoded container
      for one or more URI Patterns that describes for which content a JSON Web Encryption (JWE
      [RFC7516]) Object in compact serialization form.  If the
      Signed URI is valid.  The URI Pattern Container contains an
      expression to match against CDN
      validating the requested URI to check whether signed JWT does not support Client IP validation,
      or if the
      requested content is allowed to be requested.  Multiple URI
      Patterns may be concatenated Client IP in a single URI Pattern Container
      information element by separating them with a semi-colon (';')
      character.  Each URI Pattern follows the [RFC3986] URI format,
      including signed JWT does not match the '://' that delimits source IP
      address in the URI scheme from content request request, the
      hierarchy part.  The pattern may include CDN MUST reject the wildcards '*' and
      '?', where '*' matches any sequence of characters (including
      request.  If the
      empty string) and '?' matches exactly one character.  The three
      literals '$', '*' received signed JWT contains a Client IP claim,
      then any JWT subsequently generated for CDNI redirection MUST also
      contain a Client IP claim, and '?' should the Client IP value MUST be escaped as '$$', '$*' and
      '$?'.  All other characters are treated as literals.  The
      following is an example of a valid URI Pattern: '*://*/folder/
      content-83112371/quality_*/segment????.mp4'.  In its final
      percent-encoded form, this is equal to
      '%2A%3A%2F%2F%2A%2Ffolder%2Fcontent-
      83112371%2Fquality_%2A%2Fsegment%3F%3F%3F%3F.mp4'.  An example of
      two concatenated URI Patterns is the following: 'http://*/folder/
      content-83112371/manifest/*.xml;http://*/folder/content-83112371/
      quality_*/segment????.mp4', which
      same as in percent-encoded form is:
      'http%3A%2F%2F%2A%2Ffolder%2Fcontent-83112371%2Fmanifest%2F%2A.xml
      %3Bhttp%3A%2F%2F%2A%2Ffolder%2Fcontent-
      83112371%2Fquality_%2A%2Fsegment%3F%3F%3F%3F.mp4' If the UPC is
      used, the Original URI Container information element received signed JWT.  A signed JWT generated for
      CDNI redirection MUST NOT be
      used.

   The Expiry Time Information Element ensures that the content
   authorization expires after add 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 IP address or set of IP addresses based on the claim if no Client IP
   address for whom
      claim existed in the content access was authorized. received signed JWT.

   o  Expiry Time (exp) [optional] - The semantics in [RFC7519]
      Section 4.1.4 MUST be followed, though URI Signing
   mechanism described in this document will communicate the IP address
   in the URI.  To prevent the IP address from being logged, the Client
   IP information element is transmitted in encrypted form. implementations
      MUST not allow for any time synchronization "leeway".  Note: The Original URI Container is used to limit access to
      time on the Original
   URI only.

   The entities that generate and validate the signed URI Pattern Container Information Element is used to restrict
   content access to a particular set of URIs.
      SHOULD be in sync.  In order to increase performance of string parsing of the UPC,
   implementations can check often-used UPC prefixes CDNI case, this means that CSP, uCDN
      and dCDN servers need to quickly check
   whether certain URI components can be ignored.  For example, UPC
   prefixes '*://*/' time-synchronized.  It is RECOMMENDED
      to use NTP for time synchronization.  If the CDN validating the
      signed JWT does not support Expiry Time validation, or '*://*:*' will be used if the
      Expiry Time in case the scheme and
   authority components of signed JWT corresponds to a time earlier than
      the URI are ignored for purposes time of UPC
   enforcement.

   Note: See the Security Considerations (Section 9) section on content request request, the
   limitations of using CDN MUST reject the
      request.  If the received signed JWT contains a Expiry Time claim,
      then any JWT subsequently generated for CDNI redirection MUST also
      contain an expiration time Expiry Time claim, and client IP address for
   distribution policy enforcement.

2.2.  Signature Computation Information Elements

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

   The defined keyword received signed JWT.  A signed JWT generated
      for each information element is specified CDNI redirection MUST NOT add an Expiry Time claim if no
      Expiry Time claim existed in
   parenthesis below.

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

   o  Version (VER)  Not Before (nbf) [optional] - An 8-bit unsigned integer used The semantics in [RFC7519]
      Section 4.1.5 MUST be followed, though URI Signing implementations
      MUST not allow for
      identifying any time synchronization "leeway".  Note: The
      time on the version of entities that generate and validate the signed URI signing method.  If this
      Information Element is not present
      SHOULD be in sync.  In the URI Signing Package
      Attribute, CDNI case, this means that the default version CSP,
      uCDN, and dCDN servers need to be time-synchronized.  It is 1.

   o  Key ID (KID) [optional] - A string used
      RECOMMENDED to use NTP for obtaining time synchronization.  If the key
      (e.g., database lookup, URI reference) which is needed CDN
      validating the signed JWT does not support Not Before time
      validation, or if the Not Before time in the signed JWT
      corresponds to validate a time later than the URI signature.  The KID time of the content request
      request, the CDN MUST reject the request.  If the received signed
      JWT contains a Not Before time claim, then any JWT subsequently
      generated for CDNI redirection MUST also contain a Not Before time
      claim, and KID_NUM information elements the Not Before time value 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 in the
      received signed JWT.  A signed JWT generated for KID.  The KID and KID_NUM
      information elements CDNI redirection
      MUST NOT be present add a Not Before time claim if no Not Before time claim
      existed in the same URI Signing
      Package Attribute. received signed JWT.

   o  Hash Function (HF)  Issued At (iat) [optional] - A string used for identifying The semantics in [RFC7519]
      Section 4.1.6 MUST be followed.  Note: The time on the
      hash function to compute entities
      that generate and validate the signed URI signature with HMAC.  If this
      Information Element is not present SHOULD be in sync.  In
      the URI Signing Package
      Attribute, the default hash function is "SHA-256".  For
      interoperability purposes, any hash function signalled via CDNI case, this
      Information Element SHALL use the notation as used by NIST (e.g.
      "SHA-256" instead of "SHA256", as defined in [FIPS.180-1.1995]).

   o  Digital Signature Algorithm (DSA) [optional] - Algorithm used means that CSP, uCDN, and dCDN servers need to
      calculate the Digital Signature.  If this Information Element
      be time-synchronized.  It is
      not present in the URI Signing Package Attribute, RECOMMENDED to use NTP for time
      synchronization.  If the default is
      "ECDSA".  For interoperability purposes, received signed JWT contains an Issued At
      claim, then any digital signature
      algorithm signalled via this Information Element SHALL use JWT subsequently generated for CDNI redirection
      MUST also contain an Issued At claim, and the
      notation as used by NIST (e.g.  "ECDSA" instead of "EC-DSA", as
      defined in [FIPS.186-4.2013]).

   o  Client IP Encryption Algorithm (CEA) [optional] - Algorithm used Issuer value MUST be
      updated to encrypt the Client IP.  If this Information Element is not
      present in identify the URI Signing Package Attribute, time the default is "AES-
      128".  For interoperability purposes, any encryption algorithm
      signalled via this Information Element SHALL use new JWT was generated.  If the notation as
      used by NIST (e.g.  "AES-128" instead of "AES128", as defined in
      [FIPS.197.2001]").
      received signed JWT does not contain an Issued At claim, an Issued
      At claim MAY be added to a signed JWT generated for CDNI
      redirection.

   o  Client IP Key ID (CKI)  Nonce (jti) [optional] - A 64-bit unsigned integer used
      for obtaining the key (e.g., database lookup) The semantics in [RFC7519] Section 4.1.7
      MUST be followed.  Can be used for encrypting/
      decrypting to prevent replay attacks if the Client IP.

   The Version Information Element indicates which version
      CDN stores a list of URI
   signing scheme is all previously used (including which attributes Nonce values, and algorithms are
   supported).  The present document specifies Version 1.  If
      validates that the
   Version attribute is not present Nonce in the Signed URI, then the version
   is obtained from the CDNI metadata, else it is considered to have current JWT has never been set to the default value of 1.  More versions may be defined in
   the future.

   The Key ID Information Element is used to retrieved
      before.  If the key which is
   needed as input to signed JWT contains a Nonce claim and the algorithm for CDN
      validating the Signed URI.  The
   method used for obtaining the actual key from the reference included
   in signed JWT does not support Nonce storage, then the Key ID Information Element is outside
      CDN MUST reject the scope of this
   document.  Instead of using request.  If the KID element, which is received signed JWT contains
      a string, it is
   possible to use the KID_NUM element Nonce claim, then any JWT subsequently generated for numerical Key identifiers
   instead.  The KID_NUM element is CDNI
      redirection MUST also contain 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
   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 Nonce claim, and the
   digital signature function to Nonce value
      MUST be in the case asymmetric keys are
   used.  The Digital Signature Algorithm Information Element is used same as in
   combination with the Digital Signature Information Element defined in
   section Section 2.3.

   The Client IP Encryption Algorithm Information Element indicates received signed JWT.  If the
   encryption algorithm to received
      signed JWT does not contain a Nonce claim, a Nonce claim MAY be used
      added to a signed JWT generated for CDNI redirection.

   Note: See the Client IP.  The Client IP
   Encryption Algorithm Information Element is used in combination with
   the Client IP Information Element defined in Security Considerations (Section 7) section Section 2.1.

   The Client IP Key ID is used to retrieved on the key which is used for
   encrypting
   limitations of using an expiration time and decrypting the Client IP.  The method used client IP address for
   obtaining the actual key from
   distribution policy enforcement.

2.1.1.  URI Container Forms

   The URI Container (sub) claim takes one of the reference included following forms.  More
   forms may be added in the Key ID
   Information Element is outside the scope of this document.  The
   Client IP Encryption Algorithm Information Element is used in
   combination with future to extend the Client IP Information Element defined in section
   Section 2.1.

2.3. capabilities.

2.1.1.1.  URI Signature Information Elements

   This section identifies Simple Container (uri:)

   When prefixed with 'uri:', the set of information elements that carry string following 'uri:' is the URI Signature
   that is used for checking the integrity and
   authenticity of MUST be matched with a simple string match to the requested URI.

   The defined keyword

2.1.1.2.  URI Pattern Container (uri-pattern:)

   Prefixed with 'uri-pattern:', this string contains one or more URI
   Patterns that describes for each information element which content the Signed URI is specified in
   parenthesis below.

   The following information elements are used valid.
   Each URI Pattern contains an expression to carry match against the actual URI
   Signature.

   o  Message Digest (MD) [mandatory for symmetric key] - A string used
      for
   requested URI, to check whether the message digest generated requested content is allowed to
   be served.  Multiple URI Patterns may be concatenated in a single URI
   Pattern by separating them with a semi-colon (';') character.  Each
   URI Pattern follows the [RFC3986] URI signing entity.

   o  Digital Signature (DS) [mandatory for asymmetric keys] - A string
      used for format, including the digital signature provided by '://'
   that delimits the URI signing entity.

   The Message Digest attribute contains scheme from the message digest used to
   validate hierarchy part.  The pattern
   may include the Signed URI special literals:

      ';' - separates individual patterns when symmetric keys are used.

   The Digital Signature attribute the string contains
      multiple URI patterns.

      '*' - matches any sequence of characters, including the digital signature empty
      string.

      '?' - matches exactly one character.

      '$' - used to verify escape the Signed special literals; MUST be followed by
      exactly one of ';', '*', '?', or '$'.

   The following is an example of a valid URI when asymmetric keys are used.

   In the case Pattern:

   *://*/folder/content-83112371/quality_*/segment????.mp4

   An example of symmetric key, HMAC algorithm two concatenated URI Patterns 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
   (whitespace is freely inserted after the ';' for readability and widely available, 2) Easy should not
   be present in the actual representation):

   http://*/folder/content-83112371/manifest/*.xml;
   http://*/folder/content-83112371/quality_*/segment????.mp4

   In order to
   replace increase the embedded hash function in case faster or more secure hash
   functions are found or required, 3) Original performance of string parsing the hash
   function is maintained without incurring a significant degradation,
   and 4) Simple way URI
   Pattern, implementations can check often-used URI Pattern prefixes to use and handle keys.  The default HMAC algorithm
   used is SHA-256.

   In the
   quickly check whether certain URI components can be ignored.  For
   example, URI Pattern prefixes '*://*/' or '*://*:*' will be used in
   case the scheme and authority components of asymmetric keys, Elliptic Curve Digital Signature
   Algorithm (EC DSA) - a variant the URI are ignored for
   purposes of DSA - pattern enforcement.

2.1.1.3.  URI Regular Expression Container (uri-regex:)

   Prefixed with 'uri-regex:', this string is any PCRE [PCRE839]
   compatible regular expression used because of to match against the
   following reasons: 1) Key size is small while still offering good
   security, 2) Key requested
   URI.

   Note: Because '\' has special meaning in JSON [RFC7159] as the escape
   character within JSON strings, the regular expression character '\'
   MUST be escaped as '\\'.

   An example of a 'uri-regex:' is easy the following:

   .*\\://.*/folder/content-83112371/quality_.*/segment.{3}\\.mp4

   Note: Due to store, and 3) Computation computational complexity of executing arbitrary regular
   expressions, it is faster than
   DSA or RSA.

2.4.  URI Signing Package Attribute

   The RECOMMENDED to only execute after validating the
   JWT to ensure its authenticity.

3.  Relationship with CDNI Interfaces

   Some of the CDNI Interfaces need enhancements to support URI Signing Package Attribute is Signing.
   As an encapsulation container for
   the example: A dCDN that supports URI Signing Information Elements defined in needs to be able to
   advertise this capability to the previous
   sections. uCDN.  The URI Signing Information Elements are encoded and
   stored in this attribute.  URI Signing Package Attribute is appended uCDN needs to select a
   dCDN based on such capability when the Original CSP requires access control to
   enforce its distribution policy via URI Signing.  Also, the uCDN
   needs to be able to distribute via the CDNI Metadata interface the
   information necessary to create allow the dCDN to validate a Signed URI.

   The primary advantage of the URI Signing Package Attribute is
   Events that it
   avoids having pertain to expose the URI Signing Information Elements directly (e.g., request denial or delivery
   after access authorization) need to be included in the query string of the URI, thereby reducing logs
   communicated through the potential for a
   namespace collision space CDNI Logging interface (Editor's Note: Is
   this within the URI query string (or the URL
   path in case path parameters are used).  A side-benefit of the
   attribute is the obfuscation performed by scope of the CDNI Logging interface?).

3.1.  CDNI Control Interface

   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, has no impact on 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 interface.

3.2.  CDNI Footprint & Capabilities Advertisement Interface

   The CDNI Request Routing: Footprint and hence do not affect URI Signing. Capabilities Semantics
   document [I-D.ietf-cdni-footprint-capabilities-semantics] defines
   support for advertising CDNI Metadata capabilities, via CDNI Payload
   Type.  The following attribute is CDNI Payload Type registered in Section 6.1 can be used to carry
   for capability advertisement.

3.3.  CDNI Request Routing Redirection Interface

   The CDNI Request Routing Redirection Interface
   [I-D.ietf-cdni-redirection] describes the encoded set of recursive request
   redirection method.  For URI
   Signing attributes in Signing, the Signed URI.

   o uCDN signs the URI provided
   by the dCDN.  URI Signing Package (URISigningPackage) - therefore has has no impact on this
   interface.

3.4.  CDNI Metadata Interface

   The encoded attribute
      containing all CDNI Metadata Interface [I-D.ietf-cdni-metadata] describes the
   CDNI metadata distribution in order to enable content acquisition and
   delivery.  For URI Signing Information Elements used for
      URI Signing. Signing, a new CDNI metadata object is specified.

   The URI Signing Package Attribute UriSigning Metadata object contains the information to enable URI Signing
   Information Elements in the Base-64 encoding with URL
   signing and Filename
   Safe Alphabet (a.k.a. "base64url") as specified in the Base-64 Data
   Encoding [RFC4648] document. validation by a dCDN.  The UriSigning properties are
   defined below.

      Property: enforce

         Description: URI Signing Package Attribute is enforcement flag.  Specifically, this
         flag indicates if the only access to content is subject to URI
         Signing.  URI Signing attribute exposed in requires the Signed URI.  If dCDN to ensure that the
   Signed URI is communicated via the URI query string, the attribute
   MUST
         must be signed and validated before delivering content.
         Otherwise, the last parameter in the query string dCDN does not perform validation, regardless of
         whether or not the URI when the
   Signed URI is generated.  However, a client or CDN may append other
   query parameters unrelated to URI Signing to signed.

         Type: Boolean

         Mandatory-to-Specify: No.  The default is true.

      Property: issuers

         Description: A list of valid Issuers against which the Signed URI.  Such
   additional query parameters SHOULD NOT use Issuer
         claim in the same signed JWT may be validated.

         Type: Array of Strings

         Mandatory-to-Specify: No.  The default is an empty list.  An
         empty list means that any Issuer is acceptable.

      Property: package-attribute

         Description: The name as the URI
   Signing Package Attribute to avoid namespace collision and potential
   failure of use for the URI Signing validation. Package.

         Type: String

         Mandatory-to-Specify: No.  Default is "URISigningPackage".

   The parameter name following is an example of the a URI Signing Package Attribute shall be
   defined in the CDNI Metadata interface.  If the CDNI Metadata
   interface metadata payload with
   all default values:

   {
     "generic-metadata-type": "MI.UriSigning"
     "generic-metadata-value": {}
   }

   The following is not used, or does not include an example of a parameter name for the URI Signing Package Attribute, metadata payload with
   explicit values:

   {
     "generic-metadata-type": "MI.UriSigning"
     "generic-metadata-value":
       {
         "enforce": true,
         "issuers": ["csp", "ucdn1", "ucdn2"],
         "package-attribute": "usp"
       }
   }

3.5.  CDNI Logging Interface

   For URI Signing, the parameter name is set by
   configuration (out of scope dCDN reports that enforcement of this document).

2.5.  User Agent Attributes

   For some use cases, such as logging, it might be useful to allow the
   UA, or another entity, add one or more attributes access
   control was applied to the Signed URI request for purposes other than content delivery.  When the
   request is denied due to enforcement of URI Signing without causing Signing, the reason is
   logged.

   The following CDNI Logging field for URI Signing to
   fail.  In order to do so, such attributes MUST SHOULD be appended after supported
   in the
   URI Signing Packacke Attribute.  Any attributes appended HTTP Request Logging Record as specified in such way
   after CDNI Logging
   Interface [I-D.ietf-cdni-logging], using the new
   "cdni_http_request_v2" record-type registered in Section 6.2.1.

   o  s-uri-signing (mandatory):

      *  format: 3DIGIT

      *  field value: this characterises the URI Signature has been calculated are not validated for signing validation
         performed by the
   purpose Surrogate on the request.  The allowed values
         are:

         +  "000" : no signed JWT validation performed

         +  "200" : signed JWT validation performed and validated
         +  "400" : signed JWT validation performed and rejected because
            of content access authorization.  Adding any such attributes incorrect signature

         +  "401" : signed JWT validation performed and rejected because
            of Expiration Time enforcement

         +  "402" : signed JWT validation performed and rejected because
            of Client IP enforcement

         +  "403" : signed JWT validation performed and rejected because
            of URI Pattern enforcement

         +  "404" : signed JWT validation performed and rejected because
            of Issuer enforcement

         +  "405" : signed JWT validation performed and rejected because
            of Not Before enforcement

         +  "500" : unable to the Signed perform signed JWT validation because of
            malformed URI before

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

   o  s-uri-signing-deny-reason (optional):

      *  format: QSTRING

      *  field value: a string for providing further information in case
         the signed JWT was rejected, e.g., for debugging purposes.

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

4.  URI Signing Packacke Attribute will
   cause the Message Flow

   URI Signing validation to fail.

   Note that supports both HTTP-based and DNS-based request routing.
   JSON Web Token (JWT) [RFC7519] defines a malicious UA might potentially use the ability to append
   attributes compact, URL-safe means of
   representing claims to the Signed URI be transferred between two parties.  The
   claims in order to try to influence the content a signed JWT are encoded as a JSON object that is delivered.  For example, the UA might append '&quality=HD' to
   try to make used as
   the dCDN deliver an HD version payload of a JSON Web Signature (JWS) structure or as the requested content.
   Since such an additional attribute is appended after the URI Signing
   Package Attribute it is not validated and will not affect the outcome
   plaintext of a JSON Web Encryption (JWE) structure, enabling the URI validation.  In order
   claims to deal be digitally signed or integrity protected with this vulnerability, a
   dCDN Message
   Authentication Code (MAC) and/or encrypted.

4.1.  HTTP Redirection

   For HTTP-based request routing, a set of information that is RECOMMENDED unique
   to ignore any query strings appended after the
   URI Signing Package Attribute for the purpose of a given end user content selection.

3.  Create request is included in a Signed URI

   The following procedure for signing signed JWT,
   using key information that is specific to a URI defines the algorithms in
   this version pair of URI Signing.  Note that some steps may be skipped if adjacent CDNI
   hops (e.g.  between 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 uCDN, between the following parts: scheme
   name, authority, path, query, uCDN and fragment.  If the Original URI
   Container information element is used, all components except for the
   scheme part are protected by the URI Signature. a
   dCDN).  This allows the URI
   signature to be validated correctly in the case when a client
   performs a fallback CDNI hop to another scheme (e.g., HTTP) for a content item
   referenced by ascertain the authenticity of a URI with
   given request received from a specific scheme (e.g., RTSP).  In case the previous CDNI hop.

   The URI Pattern Container information element signing method described below is used, based on the CSP has full
   flexibility to specify which elements of the URI (including the
   scheme part) are protected by the URI.

   The process of generating a Signed URI can be divided into four sets
   of steps: 1) Compose URI Signing IEs with original URI / URI pattern,
   2) Compute the URI Signature, 3) Encode the URI Signing Package, and
   4) Assemble the parts to create the Signed URI.  Note it is possible
   to use some other algorithm and implementation as long as the same
   result is achieved.  An example for the Full Original URI,
   "http://example.com/content.mov", is used to clarify the steps.

3.1.  Compose URI Signing IEs with Protected URI

   Calculate the URI Signature by following the procedure below.

   1.  Create an empty buffer for performing the operations below.

   2.  If the version is not the default value (i.e.  "1"), perform this
       step.  Specify the version by appending the string "VER=#" to the
       buffer, where '#' represents the new version number.  The
       following steps in the procedure are based on the initial version
       of URI Signing specified by this document.  For other versions,
       reference the associated RFC for the URI signing procedure.

   3.  If time window enforcement is needed, perform this step.

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

       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 buffer.

   4.  If client IP enforcement is needed, perform this step.

       A.  Skip this step when the Client IP Encryption Algorithm used
           is the default ("AES-128").  If an information element was
           added to the buffer, append an "&" character.  Append the
           string "CEA=".  Append the string for the Client IP
           Encryption Algorithm to be used.

       B.  If the Client IP Key Identifier is needed, perform this step.
           If an information element was added to the buffer, append an
           "&" character.  Append the string "CKI=".  Append the Client
           IP key identifier (e.g., "56128239") needed by the entity to
           locate the shared key for decrypting the Client IP.

       C.  If an information element was added to the buffer, append an
           "&" character.  Append the string "CIP=".

       D.  Convert the client's IP address in CIDR notation (dotted
           decimal format for IPv4 or canonical text representation for
           IPv6 [RFC5952]) to a string and encrypt it using AES-128 (in
           ECB mode) or another algorithm if specified by the CEA
           Information Element.  Note in the case of re-signing a URI,
           the client IP that is encrypted MUST be equal to the
           unencrypted value of the Client IP as received in the Signed
           URI, see step 1 in Section 4.5.

       E.  Convert the encrypted Client IP to its equivalent hexadecimal
           format.

       F.  Append the value computed in the previous step to the buffer.

   5.  If a Key ID information element is needed, perform this step.  If
       an information element was added to the buffer, append an "&"
       character.  Append the string "KID=" in case a 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 signature.

   6.  If symmetric shared key is used, perform this step.  However,
       skip this step when the hash function for the HMAC uses the
       default value ("SHA-256").  If an information element was added
       to the buffer, append an "&" character.  Append the string "HF=".
       Append the string for the new hash function to be used.  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.

   7.  If asymmetric private/public keys are used, perform this step.
       However, skip this step when the digital signature algorithm uses
       the default value ("ECDSA").  If an information element was added
       to the buffer, append an "&" character.  Append the string
       "DSA=".  Append the string for the digital signature function.
       Note that re-signing a URI MUST use the same digital signature
       algorithm as the received Signed URI or one of the allowable
       digital signature algorithms designated by the CDNI metadata.

   8.  Depending on the type of URI enforcement used (Full Original URI
       or URI Pattern), add the appropriate information element.

       A.  If enforcement based on the Full Original URI, perform this
           step.  If an information element was added to the buffer,
           append an "&" character.  Append the string "OUC=".  Append
           the Original URI, excluding the "scheme name" part and the
           "://" delimiter, to the buffer.  Note: the Original URI
           Container information element MUST be the last information
           element in the buffer before the signature information
           element.

       B.  If enforcement based on a URI Pattern, perform this step.  If
           an information element was added to the buffer, append an "&"
           character.  Append the string "UPC=".  Append the URI Pattern
           Container in the form of a percent-encoded string to the
           buffer.

3.2.  Compute URI Signature

   Compute the URI Signature by following the procedure below.  The
   buffer from the previous section is used.

   1.  If symmetric shared key is used, perform this step.

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

       B.  Append the string "MD=".  The buffer now contains the
           complete section of the URI that is protected (e.g.  "ET=1209
           422976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=examp
           le:keys:123&OUC=example.com/content.mov&MD=").

       C.  Compute the message digest using the HMAC algorithm and the
           default SHA-256 hash function, or another hash function if
           specified by the HF Information Element, with the shared key
           and message as the two inputs to the hash function.

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

       E.  Append the string for the message digest (e.g.  "ET=120942297
           6&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:ke
           ys:123&OUC=example.com/content.mov&MD=1ecb1446a6431352aab0fb6
           e0dca30e30356593a97acb972202120dc482bddaf").

   2.  If asymmetric private/public keys are used, perform this step.

       A.  Obtain the private key to be used for signing the URI.

       B.  If an information element was added to the buffer, append an
           "&" character.  Append the string "DS=".  The buffer now
           contains the complete section of the URI that is protected.
           (e.g.  "ET=1209422976&CKI=311&CIP=90C913977933FC650E7186361A9
           3D6C3&KID=example:keys:123&OUC=example.com/content.mov&DS=").

       C.  Compute the message digest using SHA-1 (without a key) for
           the buffer.  Note: The digital signature generated in the
           next step is calculated over the SHA-1 message digest,
           instead of over the full cleartext buffer.  This is done to
           reduce the length of the digital signature, the URI Signing
           Package Attribute, and the resulting Signed URI.  Since SHA-1
           is not used for cryptographic purposes here, the security
           concerns around SHA-1 do not apply.

       D.  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.

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

       F.  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.
           "ET=1209422976&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&K
           ID=example:keys:123&OUC=example.com/content.mov&DS=r:CFB03EDB
           33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D:s:57
           ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24
           E")

3.3.  Encode the URI Signing Package

   Encode the URI Signing Package by following the procedure below.  The
   buffer from the previous section is used.

   1.  If enforcement is based on the Full Original URI, this step is
       performed.  Remove the Original URI Container Attribute from the
       buffer, including the preceding "&" character (e.g.  "ET=12094229
       76&CKI=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:keys:
       123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc48
       2bddaf").  Note: This attribute is not needed in the encoded URI
       Signing Package because the Full Original URI is part of the
       Signed URI.

   2.  Compute the URI Signing Package Attribute using Base-64 Data
       Encoding [RFC4648] on the message (e.g.  "RVQ9MTIwOTQyMjk3NiZhbXA
       7Q0tJPTMxMSZhbXA7Q0lQPTkwQzkxMzk3NzkzM0ZDNjUwRTcxODYzNjFBOTNENkMz
       JmFtcDtLSUQ9ZXhhbXBsZTprZXlzOjEyMyZhbXA7TUQ9MWVjYjE0NDZhNjQzMTM1M
       mFhYjBmYjZlMGRjYTMwZTMwMzU2NTkzYTk3YWNiOTcyMjAyMTIwZGM0ODJiZGRhZg
       ==").  Note: This is the value for the URI Signing Package
       Attribute.

3.4.  Assemble the Signed URI

   Assemble the parts to create the Signed URI by following the
   procedure below.

   1.  Copy the entire Full Original URI into a new empty buffer.

   2.  If the Signed URI is communicated via the URI query string,
       perform this step.

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

       B.  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.

       C.  Append the URI Signing Package that was generated in previous
           section (e.g. "http://example.com/content.mov?URISigningPacka
           ge=RVQ9MTIwOTQyMjk3NiZhbXA7Q0tJPTMxMSZhbXA7Q0lQPTkwQzkxMzk3Nz
           kzM0ZDNjUwRTcxODYzNjFBOTNENkMzJmFtcDtLSUQ9ZXhhbXBsZTprZXlzOjE
           yMyZhbXA7TUQ9MWVjYjE0NDZhNjQzMTM1MmFhYjBmYjZlMGRjYTMwZTMwMzU2
           NTkzYTk3YWNiOTcyMjAyMTIwZGM0ODJiZGRhZg==").  Note: this is
           the completed Signed URI.

   3.  If the Signed URI is communicated via a URL path parameter,
       perform this step.

       A.  Check if the Full Original URI already contains a path
           parameter.  If not, add "/;" before the last path component
           indicating the file to be retrieved.  If yes, character at
           the last append a "?" character.  If yes, append an ";"
           character after the last path parameter.

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

       C.  Append the URI Signing Package that was generated in previous
           section after the "=" character (e.g. "http://example.com/;UR
           ISigningPackage=RVQ9MTIwOTQyMjk3NiZhbXA7Q0tJPTMxMSZhbXA7Q0lQP
           TkwQzkxMzk3NzkzM0ZDNjUwRTcxODYzNjFBOTNENkMzJmFtcDtLSUQ9ZXhhbX
           BsZTprZXlzOjEyMyZhbXA7TUQ9MWVjYjE0NDZhNjQzMTM1MmFhYjBmYjZlMGR
           jYTMwZTMwMzU2NTkzYTk3YWNiOTcyMjAyMTIwZGM0ODJiZGRhZg==/content
           .mov").  Note: this is the completed Signed URI.

4.  Validate a Signed URI

   The process of validating a Signed URI can be divided into five sets
   of steps: 1) Extract and decode URI Signing Package from the Signed
   URI, 2) Extract the URI Signing information elements, 3) Obtain the
   Protected URI, 4) Validate URI signature to ensure integrity of
   Signed URI, and 5) Ensure proper enforcement of the distribution
   policy.  The integrity of the Signed URI is confirmed before
   distribution policy enforcement because validation procedure will
   detect first if the URI has been tampered with.  Note it is possible
   to use some other algorithm and implementation as long as the same
   result is achieved.

4.1.  Extract and Decode URI Signing Package

   Extract the encoded URI Signing Package Attribute from the Signed
   URI.  The attribute is decoded for subsequent processing by the
   Downstream CDN.

   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] to obtain
       all the URI Signing information elements (e.g.  "ET=1209422976&CK
       I=311&CIP=90C913977933FC650E7186361A93D6C3&KID=example:keys:123&M
       D=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc482bdda
       f").

4.2.  Extract URI Signing IEs

   Extract the information elements in the URI Signing Package
   Attribute.  Note that some steps are to be skipped if the
   corresponding URI Signing information elements are not embedded in
   the attribute.  Some of the information elements will be used to
   validate the URI signature in the subsequent section.

   1.   Extract the value from "VER" if the information element exists
        in the decoded URI Signing Package.  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 information element is
        not in the URI, then obtain the version number in another manner
        (e.g., configuration, CDNI metadata or default value).

   2.   Extract the value from "MD" if the information element exists in
        the decoded URI Signing Package.  The existence of this
        information element indicates a symmetric key is used.

   3.   Extract the value from "DS" if the information element exists in
        the decoded URI Signing Package.  The existence of this
        information element indicates an asymmetric key is used.

   4.   If neither "MD" or "DS" attribute is in the decoded URI Signing
        Package, 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.

   5.   Extract the value from "UPC" if the information element exists
        in the decoded URI Signing Package and convert it from its
        percent-encoded form to a regular string.  The existence of this
        information element indicates content delivery is enforced based
        on a (set of) URI pattern(s) instead of the Full Original URI.

   6.   Extract the value from "CIP" if the information element exists
        in the decoded URI Signing Package.  The existence of this
        information element indicates content delivery is enforced based
        on client IP address.

   7.   Extract the value from "ET" if the information element exists in
        the decoded URI Signing Package.  The existence of this
        information element indicates content delivery is enforced based
        on time.

   8.   Extract the value from the "KID" or "KID_NUM" information
        element, if they exist.  The existence of either of these
        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.

   9.   Extract the value from the "HF" information element, if it
        exists.  The existence of this information element indicates a
        different hash function than the default.

   10.  Extract the value from the "DSA" information element, if it
        exists.  The existence of this information element indicates a
        different digital signature algorithm than the default.

   11.  Extract the value from the "CEA" information element, if it
        exists.  The existence of this information element indicates a
        different Client IP Encryption Algorithm than the default.

   12.  Extract the value from the "CKI" information element, if it
        exists.  The existence of this information element indicates a
        key can be referenced using which the Client IP was encrypted.

4.3.  Obtain URI Signing IEs with Protected URI

   Obtain the message that contains the URI Signing Information Elements
   and Protected URI (either Full Original URI or URI pattern).  This is
   the content that was used to generate the URI signature, which is
   validated by Downstream CDN in the next section.

   1.  Copy the decoded URI Signing Package into a new buffer to hold
       the message for performing the operations below.  Note: The
       attribute contains all the URI Signing Information Elements and
       may also include the URI Pattern Container.

   2.  Remove the value part of the "MD" or "DS" information element
       from the message.  The part of information element that remains
       is "MD=" or "DS=".

   3.  When UPC information element exists, the Protected URI is a set
       of URIs (i.e., URI Pattern which is conveyed in the value of the
       UPC IE).  Otherwise, the Protected URI is the Full Original URI.

       A.  For URI Pattern, the message already contains the Protected
           URI.  Therefore, no additional operation is needed to create
           the protected URI.

       B.  For Full Original URI, the message is missing the Full
           Original URI in the URI Signing Package.  Perform the
           following steps.

           1.  Remove the string "MD=" or "DS=".

           2.  Append the string "OUC=".  Append the Full Original URI,
               excluding the "scheme name" part and the "://" delimiter,
               to the buffer.

           3.  Append the "&" character.  Append "MD=" or "DS=",
               depending on which of the two was present in the URI
               Signing Package.  The message is ready for validation of
               the message digest (e.g.  "ET=1209422976&CIP=90C913977933
               FC650E7186361A93D6C3&KID=example:keys:123&OUC=example.com
               /content.mov&MD=").

4.4.  Validate URI Signature

   Validate the URI Signature for the Signed URI.  The message used for
   computation is obtained from previous section.

   1.  The received message signature is the value extracted from the
       "MD" or "DS" information element.  Convert the message signature
       to binary format.  This will be used to compare with the computed
       value later.

   2.  Based on the presence of either the MD or DS information element
       in the URI Signing Package, validate the message digest or
       digital signature for symmetric key or asymmetric keys,
       respectively.

       A.  For MD, an HMAC algorithm is used.

           1.  If either the "KID" or "KID_NUM" information element
               exists, validate that the key identifier is in the
               allowable KID set as listed in the CDNI metadata or
               configuration.  The request is denied when the key
               identifier is not allowed.  If neither the "KID" or
               "KID_NUM" information element is present in the Signed
               URI, obtain the shared key via CDNI metadata or
               configuration.

           2.  If "HF" information element exists, validate that the
               hash function is in the allowable "HF" set as listed in
               the CDNI metadata or configuration.  The request is
               denied when the hash function is not allowed.  Otherwise,
               the "HF" information element is not in the Signed URI.
               In this case, the default hash function is SHA-256.

           3.  Compute the message digest using the HMAC algorithm with
               the shared key and message as the two inputs to the hash
               function.

           4.  Compare the result with the received message signature to
               validate the Signed URI.

       B.  For DS, a digital signature function is used.

           1.  If either the "KID" or "KID_NUM" information element
               exists, validate that the key identifier is in the
               allowable KID set as listed in the CDNI metadata or
               configuration.  The request is denied when the key
               identifier is not allowed.  If neither the "KID" or
               "KID_NUM" information element is present in the Signed
               URI, obtain the public key via CDNI metadata or
               configuration.

           2.  If "DSA" information element exists, validate that the
               digital signature algorithm is in the allowable "DSA" set
               as listed in the CDNI metadata or configuration.  The
               request is denied when the DSA is not allowed.
               Otherwise, the "DSA" information element is not in the
               Signed URI.  In this case, the default DSA is EC-DSA.

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

           4.  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.

4.5.  Distribution Policy Enforcement

   Note that the absence of a given Enforcement Information Element
   indicates enforcement of its purpose is not necessary in the CSP's
   distribution policy.

   1.  If the "CIP" information element does not exist, this step can be
       skipped.

       A.  Obtain the key for decrypting the Client IP, as indicated by
           the Client IP Key Index information element or set via
           configuration.

       B.  Decrypt the encrypted Client IP address obtained in step 6
           using AES-128, or the algorithm specified by the Client IP
           Encryption Algorithm information element.

       C.  Verify, using CIDR matching, that the request came from an IP
           address within the range indicated by the decrypted Client IP
           information element.  If the IP address is incorrect, the
           request is denied.

   2.  If the "ET" information element exists, validate that the request
       arrived before expiration time based on the "ET" information
       element.  If the time expired, then the request is denied.

   3.  If the "UPC" information element exists, validate that the
       requested resource is in the allowed set by matching the received
       URI against each of the Patterns in the URI Pattern Container
       information element until a match is found.  If there is no
       match, the request is denied.

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
   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.

   In general, new information elements introduced to enhance URI
   Signing requires a draft and a new version.

      For Enforcement Information Elements, there is no need to
      advertise the based information elements such as "CIP" and "ET".

      For Signature Computation Information Elements:

         No need to advertise "VER" Information Element unless it's not
         "1".  In this case, a draft is needed to describe the new
         version.

         Advertise value of the "HF" Information Element (i.e.  SHA-256)
         to indicate support for the hash function; Need IANA assignment
         for new hash function.

         Advertise value of the "DSA" Information Element (i.e.
         "ECDSA") to indicate support for the DSA; Need IANA assignment
         for new digital signature algorithm.

         Advertise "MD" Information Element (i.e., SHA-256) to indicate
         support for symmetric key method; A new draft is needed for an
         alternative method.

         Advertise "DS" Information Element (i.e., "ECDSA") to indicate
         support for asymmetric key method; A new draft is needed for an
         alternative method.

      For URI Signing Package Attribute, there is no need to advertise
      the base attribute.

5.3.  CDNI Request Routing Redirection Interface

   The CDNI Request Routing Redirection Interface
   [I-D.ietf-cdni-redirection] describes the recursive request
   redirection method.  For URI Signing, the Upstream CDN signs the URI
   provided by the Downstream CDN.  This approach has the following
   benefits:

      Consistency with interative request routing method

      URI Signing is fully operational even when Downstream CDN does not
      have the signing function (which may be the case when the
      Downstream CDN operates only as a delivering CDN)

      Upstream CDN can act as a conversion gateway for the requesting
      routing interface between Upstream CDN and CSP and request routing
      interface between Upstream CDN and Downstream CDN since these two
      interfaces may not be the same

5.4.  CDNI Metadata Interface

   The CDNI Metadata Interface [I-D.ietf-cdni-metadata] describes the
   CDNI metadata distribution in order to enable content acquisition and
   delivery.  For URI Signing, additional CDNI metadata objects are
   specified.  In general, an Empty set means "all".  These are the CDNI
   metadata objects used for URI Signing.

   The UriSigning Metadata object contains information to enable URI
   signing and validation by a dCDN.  The UriSigning properties are
   defined below.

      Property: enforce

         Description: 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.

         Type: Boolean

         Mandatory-to-Specify: No.  If a UriSigning object is present in
         the metadata for a piece of content (even if the object is
         empty), then URI signing should be enforced.  If no UriSigning
         object is present in the metadata for a piece of content, then
         the URI signature should not be validated.

      Property: key-id

         Description: Designated key identifier used for URI Signing
         computation when the Signed URI does not contain the Key ID
         information element.

         Type: String

         Mandatory-to-Specify: No.  A Key ID is not essential for all
         implementations of URI signing.

      Property: key-id-set

         Description: Allowable Key ID set that the Signed URI's Key ID
         information element can reference.

         Type: List of Strings

         Mandatory-to-Specify: No.  Default is to allow any Key ID.

      Property: hash-function

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

         Type: String (limited to the hash function strings in the
         registry defined by the IANA Considerations (Section 8)
         section)

         Mandatory-to-Specify: No.  Default is SHA-256.

      Property: hash-function-set

         Description: Allowable Hash Function set that the Signed URI's
         Hash Function information element can reference.

         Type: List of Strings

         Mandatory-to-Specify: No.  Default is to allow any hash
         function.

      Property: digital-signature-algorithm

         Description: Designated digital signature function used for URI
         Signing computation when the Signed URI does not contain the
         Digital Signature Algorithm information element.

         Type: String (limited to the digital signature algorithm
         strings in the registry defined by the IANA Considerations
         (Section 8) section).

         Mandatory-to-Specify: No.  Default is "ECDSA".

      Property: digital-signature-algorithm-set

         Description: Allowable digital signature function set that the
         Signed URI's Digital Signature Algorithm information element
         can reference.

         Type: List of Strings

         Mandatory-to-Specify: No.  Default is to allow any DSA.

      Property: version

         Description: Designated version used for URI Signing
         computation when the Signed URI does not contain the VER
         attribute.

         Type: Integer

         Mandatory-to-Specify: No.  Default is 1.

      Property: version-set

         Description: Allowable version set that the Signed URI's VER
         attribute can reference.

         Type: List of Integers

         Mandatory-to-Specify: No.  Default is to allow any version.

      Property: package-attribute

         Description: Overwrite the default name for the URL Signing
         Package Attribute.

         Type: String

         Mandatory-to-Specify: No.  Default is "URISigningPackage".

   Note that the Key ID information element is not needed if only one
   key is provided by the CSP or the Upstream CDN for the content item
   or set of content items covered by the CDNI Metadata object.  In the
   case of asymmetric keys, it's easy for any entity to sign the URI for
   content with a private key and provide the public key in the Signed
   URI.  This just confirms that the URI Signer authorized the delivery.
   But it's necessary for the URI Signer to be the content owner.  So,
   the CDNI Metadata interface or configuration MUST provide the
   allowable Key ID set to authorize the Key ID information element
   embedded in the Signed URI.

   The following is an example of a URI Signing metadata payload with
   all default values:

   {
     "generic-metadata-type": "MI.UriSigning.v1"
     "generic-metadata-value": {}
   }

   The following is an example of a URI Signing metadata payload with
   explicit values:

   {
     "generic-metadata-type": "MI.UriSigning.v1"
     "generic-metadata-value":
       {
         "enforce": true,
         "key-id": "1",
         "key-id-set": ["1", "2", "3"],
         "hash-function": "SHA-512",
         "hash-function-set": ["SHA-384", "SHA-512"],
         "digital-signature-algorithm": "ECDSA",
         "digital-signature-algorithm-set": ["ECDSA"],
         "version": 1,
         "version-set": [1],
         "package-attribute": "usp"
       }
   }

5.5.  CDNI Logging Interface

   For URI Signing, the Downstream CDN reports that enforcement of the
   access control was applied to the request for content delivery.  When
   the request is denied due to enforcement of URI Signing, the reason
   is logged.

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

   o  s-uri-signing (mandatory):

      *  format: 3DIGIT

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

         +  "000" : no URI signature validation performed

         +  "200" : URI signature validation performed and validated

         +  "400" : URI signature validation performed and rejected
            because of incorrect signature

         +  "401" : URI signature validation performed and rejected
            because of Expiration Time enforcement

         +  "402" : URI signature validation performed and rejected
            because of Client IP enforcement

         +  "403" : URI signature validation performed and rejected
            because of URI Pattern enforcement

         +  "500" : unable to perform URI signature validation because
            of malformed URI

         +  "501" : unable to perform URI signature validation because
            of unsupported version number

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

   o  s-uri-signing-deny-reason (optional):

      *  format: QSTRING

      *  field value: a string for providing further information in case
         the URI signature was rejected, e.g., for debugging purposes.

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

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
   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 following
   steps (assuming HTTP redirection, iterative request routing, and a
   CDN path with two CDNs).  Note that uCDN and uCDN 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| signed JWT   |
        |                    |                    |<-------------------|
        |                    |                    |                    |
        |        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>|                    |
        |<----------------------------------------|                    |
        |                    |                    |                    |
        |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 dCDN advertises its capabilities including URI Signing
        support to the Authoritative CDN. uCDN.

   2.   CSP provides to the Authoritative CDN uCDN the information needed to validate URI signatures
        signed JWTs 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 uCDN communicates to a Downstream CDN
        dCDN the information needed to validate URI signatures signed JWTs from the Authoritative CDN
        uCDN 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. Attribute.

   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 policy.

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

   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 uCDN
        validates the URI Signature signed JWT in the URI using the information
        provided by the CSP.

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

   9.   If the validation is positive, the authoritative CDN uCDN 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 dCDN.

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

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

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

   13.  At a later time, Downstream CDN dCDN 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 needs to be specific to a pair of
   adjacent CDNI hops.

6.2.

4.2.  DNS Redirection

   For DNS-based request routing, the CSP and Authoritative CDN uCDN 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. dCDNs.  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.
   dCDNs.  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. URI.

   The URI signing scheme method 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| signed JWT   |
        |                    |                    |<-------------------|
        |        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>         |                    |
        |<-------------------|                    |                    |
        |                    |                    |                    |
        |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 dCDN advertises its capabilities including URI Signing
        support to the Authoritative CDN. uCDN.

   2.   CSP provides to the Authoritative CDN uCDN 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 uCDN communicates to a Downstream CDN
        dCDN 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 uCDN checks if the Downstream CDN dCDN 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
        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. uCDN.

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

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

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

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

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

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

   14.  At a later time, Downstream CDN dCDN 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].  In
   addition, [I-D.brandenburg-cdni-uri-signing-for-has] provides an
   extension to the algorithm defined in this document that deals
   specifically with URI signing of segmented content.

8.  IANA Considerations

8.1.  CDNI Payload Type

   This document requests the registration of the following CDNI Payload
   Type under the IANA "CDNI Payload Type" registry:

                   +------------------+---------------+
                   | Payload Type     | Specification |
                   +------------------+---------------+
                   | MI.UriSigning.v1 | RFCthis       |
                   +------------------+---------------+

   [RFC Editor: Please replace RFCthis with the published RFC number for
   this document.]

8.1.1.  CDNI UriSigning Payload Type

   Purpose: The purpose of this payload type is to distinguish
   UriSigning MI objects (and any associated capability advertisement).

   Interface: MI/FCI

   Encoding: see Section 5.4

8.2. needs to be distributed across
   multiple, possibly non-adjacent, CDNI Logging Record Type

   This document requests hops is the registration of public key, which
   is generally not confidential.

   With DNS-based request routing, URI Signing does not match well the following
   general chain of trust model of CDNI Logging
   record-type under when used with symmetric keys
   because the IANA "CDNI Logging record-types" registry:

   +----------------------+-----------+--------------------------------+
   | record-types         | Reference | Description                    |
   +----------------------+-----------+--------------------------------+
   | cdni_http_request_v2 | RFCthis   | Extension symmetric key information needs to be distributed across
   multiple CDNI Logging      |
   |                      |           | Record version 1 hops, including non-adjacent hops.  This raises a
   security concern for content   |
   |                      |           | delivery using HTTP, to        |
   |                      |           | include applicability of URI Signing logging    |
   |                      |           | fields                         |
   +----------------------+-----------+--------------------------------+

   [RFC Editor: Please replace RFCthis with the published RFC number for
   this document.]

8.2.1.  CDNI Logging Record Version 2 for symmetric keys
   in case of DNS-based inter-CDN request routing.

5.  HTTP Adaptive Streaming

   The "cdni_http_request_v2" record-type supports all of the fields
   supported by the "cdni_http_request_v1" record-type
   [I-D.ietf-cdni-logging] plus the two additional fields "s-uri-
   signing" and "s-uri-signing-deny-reason", registered by this document authors note that in Section 8.3.  The name, format, field value, and occurence
   information order to perform URI signing for the two new fields can be found in Section 5.5 of
   this document.

8.3.  CDNI Logging Field Names

   This document requests the registration individual
   content segments of the following CDNI Logging
   fields under the IANA "CDNI Logging Field Names" registry:

                 +---------------------------+-----------+
                 | Field Name                | Reference |
                 +---------------------------+-----------+
                 | s-uri-signing             | RFCthis   |
                 | s-uri-signing-deny-reason | RFCthis   |
                 +---------------------------+-----------+

   [RFC Editor: Please replace RFCthis with the published RFC number 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].  In
   addition, [I-D.brandenburg-cdni-uri-signing-for-has] provides an
   extension to the algorithm defined in this document.]

8.4. document that deals
   specifically with URI signing of segmented content.

6.  IANA Considerations

6.1.  CDNI Metadata Auth Payload Type

   This document requests the registration of the following CDNI
   Metadata Auth type Payload
   Type under the IANA "CDNI Metadata Auth Types" Payload Type" registry:

       +------------------+-----------------------+---------------+
       | Auth type

                     +---------------+---------------+
                     | Description Payload Type  | Specification |
       +------------------+-----------------------+---------------+
                     +---------------+---------------+
                     | MI.UriSigning.v1 | URI Signing version 1 MI.UriSigning | RFCthis       |
       +------------------+-----------------------+---------------+
                     +---------------+---------------+

   [RFC Editor: Please replace RFCthis with the published RFC number for
   this document.]

8.5.

6.1.1.  CDNI URI Signing Enforcement Information Elements UriSigning Payload Type

   Purpose: The IANA purpose of this payload type is requested to create a new "CDNI URI Signing Enforcement
   Information Elements" subregistry in the "Content Delivery Networks
   Interconnection (CDNI) Parameters" registry.  The "CDNI URI Signing
   Enforcement Information Elements" namespace defines the valid
   Enforcement Information Elements that may be included in a URI
   Signing token.  Additions to the Enforcement Information Elements
   namespace conform to the "Specification Required" policy as defined
   in [RFC5226].

   The following table defines the initial Enforcement Information
   Elements:

       +-----------------------+------------------------+---------+
       | Element               | Description            | RFC     |
       +-----------------------+------------------------+---------+
       | ET                    | Expiry Time            | RFCthis |
       | CIP                   | Client IP Address      | RFCthis |
       | OUC                   | Original URI Container | RFCthis |
       | URI Pattern Container | Client IP Address      | RFCthis |
       +-----------------------+------------------------+---------+

   [RFC Editor: Please replace RFCthis with the published RFC number for
   this document.]

   [Ed Note: are there distinguish
   UriSigning MI objects (and any special instructions to the designated expert
   reviewer?]

8.6. associated capability advertisement).

   Interface: MI/FCI

   Encoding: see Section 3.4

6.2.  CDNI URI Signing Signature Computation Information Elements

   The IANA is requested to create a new "CDNI URI Signing Signature
   Computation Information Elements" subregistry in the "Content
   Delivery Networks Interconnection (CDNI) Parameters" registry.  The
   "CDNI URI Signing Signature Computation Information Elements"
   namespace defines the valid Signature Computation Information
   Elements that may be included in a URI Signing token.  Additions to Logging Record Type

   This document requests the Signature Computation Information Elements namespace conform to registration of the "Specification Required" policy as defined in [RFC5226].

   The following table defines CDNI Logging
   record-type under the initial Signature Computation
   Information Elements:

        +---------+-------------------------------------+---------+
        | Element | Description                         | RFC     |
        +---------+-------------------------------------+---------+
        | VER IANA "CDNI Logging record-types" registry:

   +----------------------+-----------+--------------------------------+
   | Version Number record-types         | RFCthis Reference | Description                    | KID
   +----------------------+-----------+--------------------------------+
   | Non-numerical Key Identifier cdni_http_request_v2 | RFCthis   |
        | KID_NUM | Numerical Key Identifier            | RFCthis Extension to CDNI Logging      |
   | HF                      | Hash Function           | RFCthis Record version 1 for content   |
   | DSA                      | Digital Signature Algorithm           | RFCthis delivery using HTTP, to        |
   | CEA                      | Client IP Encryption Algorithm           | RFCthis include URI Signing logging    |
   | CKI                      | Client IP Encryption Key Identifier           | RFCthis fields                         |
        +---------+-------------------------------------+---------+
   +----------------------+-----------+--------------------------------+

   [RFC Editor: Please replace RFCthis with the published RFC number for
   this document.]

   [Ed Note: are there any special instructions to the designated expert
   reviewer?]

8.7.

6.2.1.  CDNI URI Signing Signature Information Elements Logging Record Version 2 for HTTP

   The IANA is requested to create a new "CDNI URI Signing Signature
   Information Elements" subregistry in "cdni_http_request_v2" record-type supports all of the "Content Delivery Networks
   Interconnection (CDNI) Parameters" registry. fields
   supported by the "cdni_http_request_v1" record-type
   [I-D.ietf-cdni-logging] plus the two additional fields "s-uri-
   signing" and "s-uri-signing-deny-reason", registered by this document
   in Section 6.3.  The "CDNI URI Signing
   Signature Information Elements" namespace defines name, format, field value, and occurence
   information for the valid Signature
   Information Elements that may two new fields can be included found in a URI Signing token.
   Additions to Section 3.5 of
   this document.

6.3.  CDNI Logging Field Names

   This document requests the Signature Information Elements namespace conform to registration of the "Specification Required" policy as defined in [RFC5226].

   The following table defines CDNI Logging
   fields under the initial Signature Information
   Elements:

       +---------+---------------------------------------+---------+
       | Element | Description IANA "CDNI Logging Field Names" registry:

                 +---------------------------+-----------+
                 | RFC Field Name                |
       +---------+---------------------------------------+---------+ Reference | MD
                 +---------------------------+-----------+
                 | Message Digest for Symmetric Key s-uri-signing             | RFCthis   |
                 | DS      | Digital Signature for Asymmetric Keys s-uri-signing-deny-reason | RFCthis   |
       +---------+---------------------------------------+---------+
                 +---------------------------+-----------+

   [RFC Editor: Please replace RFCthis with the published RFC number for
   this document.]

   [Ed Note: are there any special instructions to the designated expert
   reviewer?]

9.

7.  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
   CDNs (CDNI). 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) 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 claims in the URI.
   signed JWT.  The current version of this document includes elements claims for
   enforcing Issuer, Client IP Address Address, Not Before time, 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 Signing and that anybody implementing URI
   signing
   Signing should be aware of.

      Replay attacks: Any A (valid) Signed URI can may be used to perform replay
      attacks.  The vulnerability to replay attacks can be reduced by
      picking a relatively short window for between the Not Before time and
      Expiration Time attribute, attributes, 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 a sudden network issues from preventing
      legitimate UAs access to the content.  One way to may also reduce
      exposure to replay attacks is to include in the URI by including a unique one-time access ID.
      ID via the Nonce attribute (jti claim).  Whenever the Downstream CDN dCDN
      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 dCDN can deny the
      request based on the already-used access ID.

      Illegitimate client clients 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. dCDN.  This results in
      the Downstream CDN dCDN 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, e.g., attributes that can be found in the HTTP headers.

   The shared key between CSP and Authoritative CDN uCDN may be distributed to Downstream CDNs dCDNs -
   including cascaded CDNs.  Since this key can be used to legitimately
   sign a URL for content access authorization,
   it's it is 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.

8.  Privacy

   The privacy protection concerns described in CDNI Logging Interface
   [I-D.ietf-cdni-logging] apply when the client's IP address (CIP
   attribute) (aud) is
   embedded in the Signed URI.  For this reason, the mechanism described
   in Section 3.1 2 encrypts the Client IP before including it in the URI
   Signing Package (and thus the URL itself).

11.

9.  Acknowledgements

   The authors would like to thank the following people for their
   contributions in reviewing this document and providing feedback:
   Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan
   York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana
   Oprescu, Leif Hedstrom, Phil Sorber Hedstrom and Gancho Tenev.  In addition, Matt Caulfield
   provided content for the CDNI Metadata Interface section.

12.

10.  References

12.1.

10.1.  Normative References

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, DOI 10.17487/RFC6707, September
              2012, <http://www.rfc-editor.org/info/rfc6707>.

12.2.  Informative References

   [FIPS.180-1.1995]
              National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS PUB 180-1, April 1995,
              <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.

   [FIPS.186-4.2013]
              National Institute of Standards and Technology, "Digital
              Signature Standard", FIPS PUB 186-1, December 1998,
              <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.184-4.pdf>.

   [FIPS.197.2001]
              National Institute of Standards

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <http://www.rfc-editor.org/info/rfc7159>.

   [RFC7516]  Jones, M. and Technology, "Advanced J. Hildebrand, "JSON Web Encryption Standard (AES)", FIPS PUB 197, November 2001,
              <http://csrc.nist.gov/publications/fips/fips197/
              fips-197.pdf>. (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <http://www.rfc-editor.org/info/rfc7516>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <http://www.rfc-editor.org/info/rfc7519>.

10.2.  Informative References

   [I-D.brandenburg-cdni-uri-signing-for-has]
              Brandenburg, R., "URI Signing for HTTP Adaptive Streaming
              (HAS)", draft-brandenburg-cdni-uri-signing-for-has-03
              (work in progress), June 2016.

   [I-D.ietf-cdni-footprint-capabilities-semantics]
              Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R.,
              and K. Ma, "CDNI Request Routing: Footprint and
              Capabilities Semantics", draft-ietf-cdni-footprint-
              capabilities-semantics-20 (work in progress), May 2016.

   [I-D.ietf-cdni-metadata]
              Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
              "CDN Interconnection Metadata", draft-ietf-cdni-
              metadata-18
              metadata-21 (work in progress), June August 2016.

   [I-D.ietf-cdni-redirection]
              Niven-Jenkins, B. and R. Brandenburg, "Request Routing
              Redirection interface for CDN Interconnection", draft-
              ietf-cdni-redirection-18
              ietf-cdni-redirection-20 (work in progress), April August 2016.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <http://www.rfc-editor.org/info/rfc2104>.

   [PCRE839]  Hazel, P., "Perl Compatible Regular Expressions",
              Version 8.39, June 2016, <http://www.pcre.org/>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <http://www.rfc-editor.org/info/rfc3986>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <http://www.rfc-editor.org/info/rfc4648>.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952,
              DOI 10.17487/RFC5952, August 2010,
              <http://www.rfc-editor.org/info/rfc5952>.

   [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, DOI 10.17487/RFC6983, July 2013,
              <http://www.rfc-editor.org/info/rfc6983>.

   [RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
              "Framework for Content Distribution Network
              Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
              August 2014, <http://www.rfc-editor.org/info/rfc7336>.

   [RFC7337]  Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
              Network Interconnection (CDNI) Requirements", RFC 7337,
              DOI 10.17487/RFC7337, August 2014,
              <http://www.rfc-editor.org/info/rfc7337>.

Appendix A.  Signed URI Package Example

   This section contains two examples of token usage: a simple example
   with only the required claims present, and a complex example which
   demonstrates the full JWT claims set, including an encrypted Client
   IP (aud).

   Note: All of the examples have whitespace added to improve formatting
   and readability, but are not present in the generated content.

   Both examples use the following signing key to generate the Signed
   URI Package:

   {
     "kty": "EC",
     "kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0",
     "use": "sig",
     "crv": "P-256",
     "x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8",
     "y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA",
     "d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M"
   }

A.1.  Simple Example

   This example is the simplest possible example containing the only
   required field (sub).

   The JWT Claim Set before signing:

   {
     "sub": "uri:http://cdni.example/foo/bar/baz"
   }

   The Signed JWT:

   eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
   dZRkRPV2tsZHVlYUltZjAifQ.eyJzdWIiOiJ1cmk6aHR0cDovL2NkbmkuZXhhbXBsZ
   S9mb28vYmFyL2JheiJ9.oC4yKwUchowx4KhMsI8MQ-Sq_1s3fC8NCi-IWcmNEE9MQz
   EEQfurJ1su2Op_dtYuc_fG8NixSVubz3HWKM4Rsw

A.2.  Complex Example

   This example uses all optional fields, including Client IP (aud)
   which is encrpyted.  This significantly increases the size of the
   signed JWT token.

   Shared key used for encrpyting the Client IP (aud):

   {
     "kty": "oct",
     "kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998",
     "use": "enc",
     "alg": "A128GCM",
     "k": "4uFxxV7fhNmrtiah2d1fFg"
   }

   JWE for client IP (aud) of [2001:db8::1/32]:

   eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj
   g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..Ewl05cq3jmUe1Bv1.CHif9
   OMPmsMPgJ8tZgvD0A.R3I2C8nfppY2wBfc4xEPPQ

   The JWT Claim Set before signing:

   {
     "aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm
   dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..Ewl05cq3jmUe
   1Bv1.CHif9OMPmsMPgJ8tZgvD0A.R3I2C8nfppY2wBfc4xEPPQ",
     "exp": 1474243500,
     "iat": 1474243200,
     "iss": "Upstream CDN Inc",
     "jti": "5DAafLhZAfhsbe",
     "nbf": 1474243200,
     "sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.png"
   }

   The Signed JWT:

   eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
   dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJleUpoYkdjaU9pSmthWElpTENKcmFXU
   WlPaUptTFZkaWFuaENRek5rVUhWSk0yUXlOR3RRTW1obWRtOXpOMUY2TmpnNFZWUnB
   ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLkV3bDA1Y3Ezam1VZ
   TFCdjEuQ0hpZjlPTVBtc01QZ0o4dFpndkQwQS5SM0kyQzhuZnBwWTJ3QmZjNHhFUFB
   RIiwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6IlVwc3RyZ
   WFtIENETiBJbmMiLCJqdGkiOiI1REFhZkxoWkFmaHNiZSIsIm5iZiI6MTQ3NDI0MzI
   wMCwic3ViIjoidXJpLXJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL
   2Jhei9bMC05XXszfVxcLnBuZyJ9.AtDNW7mwFIJPqsWAn9ojzj4imE-vTowR-FRzil
   vnSQuQMz_u4sIspxe6RoXo_Ti8rVMgJ0jOdSvVnQUJZdfRUQ

Authors' Addresses

   Kent Leung
   Cisco Systems
   3625 Cisco Way
   San Jose  95134
   USA

   Phone: +1 408 526 5030
   Email: kleung@cisco.com
   Francois Le Faucheur
   Cisco Systems
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis  06410
   France

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

   Ray van Brandenburg
   TNO
   Anna van Buerenplein 1
   Den Haag  2595DC
   the Netherlands

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

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

   Kent Leung
   Cisco Systems, Inc.
   3625 Cisco Way
   San Jose, CA  95134
   United States

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

   Michel Fisher
   Limelight Networks
   222 S Mill Ave
   Tempe, AZ  85281
   USA kleung@cisco.com

   Phil Sorber
   Comcast Cable Communications
   1401 Wynkoop Street, Suite 300
   Denver, CO  80202
   United States

   Phone: +1 360 419 5185 720 502 3785
   Email: phillip_sorber@comcast.com
   Matthew Miller
   Cisco Systems, Inc.
   1899 Wynkoop Street, Suite 600
   Denver, CO  80202
   United States

   Email: mfisher@llnw.com mamille2@cisco.com