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