One document matched: draft-ietf-cdni-uri-signing-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-cdni-uri-signing-04" ipr="trust200902">
<front>
<title abbrev="CDNI URI Signing">URI Signing for CDN Interconnection
(CDNI)</title>
<author fullname="Kent Leung" initials="K" surname="Leung">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>3625 Cisco Way</street>
<city>San Jose</city>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 526 5030</phone>
<email>kleung@cisco.com</email>
</address>
</author>
<author fullname="Francois Le Faucheur" initials="F. "
surname="Le Faucheur">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Greenside, 400 Avenue de Roumanille</street>
<city>Sophia Antipolis</city>
<code>06410</code>
<country>France</country>
</postal>
<phone>+33 4 97 23 26 19</phone>
<email>flefauch@cisco.com</email>
</address>
</author>
<author fullname="Ray van Brandenburg" initials="R"
surname="van Brandenburg">
<organization>TNO</organization>
<address>
<postal>
<street>Anna van Buerenplein 1</street>
<city>Den Haag</city>
<region/>
<code>2595DC</code>
<country>the Netherlands</country>
</postal>
<phone>+31 88 866 7000</phone>
<email>ray.vanbrandenburg@tno.nl</email>
</address>
</author>
<author fullname="Bill Downey" initials="B" surname="Downey">
<organization>Verizon Labs</organization>
<address>
<postal>
<street>60 Sylvan Road</street>
<city>Waltham</city>
<region>Massachusetts</region>
<code>02451</code>
<country>USA</country>
</postal>
<phone>+1 781 466 2475</phone>
<email>william.s.downey@verizon.com</email>
</address>
</author>
<author fullname="Michel Fisher" initials="M" surname="Fisher">
<organization>Limelight Networks</organization>
<address>
<postal>
<street>222 S Mill Ave</street>
<city>Tempe</city>
<region>AZ</region>
<code>85281</code>
<country>USA</country>
</postal>
<phone>+1 360 419 5185</phone>
<email>mfisher@llnw.com</email>
</address>
</author>
<date day="1" month="June" year="2015"/>
<workgroup>CDNI</workgroup>
<abstract>
<t>This document describes how the concept of URI signing supports the
content access control requirements of CDNI and proposes a URI signing
scheme.</t>
<t>The proposed URI signing method specifies the information needed to
be included in the URI and the algorithm used to authorize and to
validate access requests for the content referenced by the URI. The algorithm includes specific provisions for allowing access control of HTTP Adaptive Streaming content that is characterized by independent chunks referenced by a manifest file.</t>
<t>The proposed mechanism is also applicable in a non-CDNI context.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of interconnected CDNs
(CDNI). The primary goal of URI Signing is to make sure that only
authorized User Agents (UAs) are able to access the content, with a
Content Service Provider (CSP) being able to authorize every individual
request. It should be noted that URI Signing is not a content protection
scheme; if a CSP wants to protect the content itself, other mechanisms,
such as DRM, are more appropriate.</t>
<t/>
<t>The overall problem space for CDN Interconnection (CDNI) is described
in <xref target="RFC6707">CDNI Problem Statement</xref>. In this
document, along with the <xref target="RFC7337">CDNI Requirements</xref>
document and the <xref target="RFC7336">CDNI Framework </xref> the need
for interconnected CDNs to be able to implement an access control
mechanism that enforces the CSP's distribution policy is described.</t>
<t>Specifically, <xref target="RFC7336">CDNI Framework</xref>
states:</t>
<t>"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."</t>
<t>In particular, the following requirement is listed in <xref
target="RFC7337">CDNI Requirements</xref>:</t>
<t>"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:</t>
<t>* need to validate URI signed information (e.g. Expiry time, Client
IP address)."</t>
<t>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.</t>
<section title="Terminology">
<t>This document uses the terminology defined in <xref
target="RFC6707">CDNI Problem Statement </xref>.</t>
<t>This document also uses the terminology of <xref
target="RFC2104">Keyed-Hashing for Message Authentication
(HMAC)</xref> including the following terms (reproduced here for
convenience):</t>
<t><list style="symbols">
<t>MAC: message authentication code.</t>
<t>HMAC: Hash-based message authentication code (HMAC) is a
specific construction for calculating a MAC involving a
cryptographic hash function in combination with a secret key.</t>
<t>HMAC-SHA256: HMAC instantiation using SHA-256 as the
cryptographic hash function.</t>
<t>SHA-1: <xref target="RFC3174">Secure Hash Algorithm 1
(SHA-1)</xref> is the cryptographic hash function.</t>
</list></t>
<t>In addition, the following terms are used throughout this
document:</t>
<t><list style="symbols">
<t>URI Signature: Message digest or digital signature that is
computed with an algorithm for protecting the URI and/or a set of URI Signing Information Elements.</t>
<t>URI Signing Information Element: An element containing information used in the URI Signature validation process that is signalled along with the URI Signature in either the Signed URI or in a Signed Token. It is protected by the URI Signature.</t>
<t>Original URI: The URI before URI Signing is applied.</t>
<t>Signed URI: Any URI that contains a URI Signature. It can be used to retrieve one particular resource, indicated by the URI.</t>
<t>Signed Token: A set of URI Signing Information Elements protected by a URI Signature that can be used to retrieve a pre-determined set of resources. It can be communicated via a URL, an HTTP Header or a Cookie. A Signed Token differs from a Signed URI in the sense that the token is valid for multiple resources and it's embedded URI Signature thus does not protect a particular URI. It can be used to form a Signed Token Chain in the case of HTTP Adaptive Streaming content.</t>
<t>Target CDN URI: Embedded URI created by the CSP to direct UA
towards the Upstream CDN. The Target CDN URI can be signed by the
CSP and verified by the Upstream CDN.</t>
<t>Redirection URI: URI created by the Upstream CDN to redirect UA
towards the Downstream CDN. The Redirection URI can be signed by
the Upstream CDN and verified by the Downstream CDN. In a cascaded
CDNI scenario, there can be more than one Redirection URI.</t>
</list></t>
</section>
<section anchor="background" title="Background on URI Signing ">
<t>The next section provides an overview of how URI Signing works in a
CDNI environment. As background information, URI Signing is first
explained in terms of a single CDN delivering content on behalf of a
CSP.</t>
<t>A CSP and CDN are assumed to have a trust relationship that enables
the CSP to authorize access to a content item by including a set of
attributes in the URI before redirecting a UA to the CDN. Using these
attributes, it is possible for a CDN to check an incoming content
request to see whether it was authorized by the CSP (e.g. based on the
UA's IP address or a time window). Of course, the attributes need to
be added to the URI in a way that prevents a UA from changing the
attributes, thereby leaving the CDN to think that the request was
authorized by the CSP when in fact it wasn't. For this reason, a URI
Signing mechanism includes in the URI a message digest or digital
signature that allows a CDN to check the authenticity of the URI. The
message digest or digital signature can be calculated based on a
shared secret between the CSP and CDN or using CSP's asymmetric
public/private key pair, respectively.</t>
<t>Figure 1, shown below, presents an overview of the URI Signing
mechanism in the case of a CSP with a single CDN. When the UA browses
for content on CSP's website (#1), it receives HTML web pages with
embedded content URIs. Upon requesting these URIs, the CSP redirects
to a CDN, creating a Target CDN URI (#2) (alternatively, the Target
CDN URI itself is embedded in the HTML). The Target CDN URI is the
Signed URI which may include the IP address of the UA and/or a time
window and always contains the URI Signature which is generated by the
CSP using the shared secret or a private key. Once the UA receives the
response with the embedded URI, it sends a new HTTP request using the
embedded URI to the CDN (#3). Upon receiving the request, the CDN
checks to see if the Signed URI is authentic by verifying the URI
signature. In addition, it checks whether the IP address of the HTTP
request matches that in the Signed URI and if the time window is still
valid. After these values are confirmed to be valid, the CDN delivers
the content (#4).</t>
<figure anchor="fig_single_cdn"
title="Figure 1: URI Signing in a CDN Environment">
<artwork><![CDATA[
--------
/ \
| CSP |< * * * * * * * * * * *
\ / Trust *
-------- relationship *
^ | *
| | *
1. Browse | | 2. Signed *
for | | URI *
content | | *
| v v
+------+ 3. Signed URI --------
| User |----------------->/ \
| Agent| | CDN |
| |<-----------------\ /
+------+ 4. Content --------
Delivery
]]></artwork>
</figure>
</section>
<section title="CDNI URI Signing Overview">
<t>In a CDNI environment, URI Signing operates the same way in the
initial steps #1 and #2 but the later steps involve multiple CDNs in
the process of delivering the content. The main difference from the
single CDN case is a redirection step between the Upstream CDN and the
Downstream CDN. In step #3, UA may send HTTP request or DNS request.
Depending on whether HTTP-based or DNS-based request routing is used,
the Upstream CDN responds by directing the UA towards the Downstream
CDN using either a Redirection URI (which is a Signed URI generated by
the Upstream CDN) or a DNS reply, respectively (#4). Once the UA
receives the response, it sends the Redirection URI/Target CDN URI to
the Downstream CDN (#5). The received URI is validated by the
Downstream CDN before delivering the content (#6). This is depicted in
the figure below. Note: The CDNI call flows are covered in <xref
target="operation">Detailed URI Signing Operation</xref>.</t>
<figure title="Figure 2: URI Signing in a CDNI Environment">
<artwork><![CDATA[
+-------------------------+
|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) |
+-----------------------------------------+
]]></artwork>
</figure>
<t>The trust relationships between CSP, Upstream CDN, and Downstream
CDN have direct implications for URI Signing. In the case shown in
Figure 2, the CDN that the CSP has a trust relationship with is the
Upstream CDN. The delivery of the content may be delegated to the
Downstream CDN, which has a relationship with the Upstream CDN but may
have no relationship with the CSP.</t>
<t>In CDNI, there are two methods for request routing: DNS-based and
HTTP-based. For DNS-based request routing, the Signed URI (i.e. Target
CDN URI) provided by the CSP reaches the Downstream CDN directly. In
the case where the Downstream CDN does not have a trust relationship
with the CSP, this means that only an asymmetric public/private key
method can be used for computing the URI Signature because the CSP and
Downstream CDN are not able to exchange symmetric shared secret keys.
Since the CSP is unlikely to have relationships with all the
Downstream CDNs that are delegated to by the Upstream CDN, the CSP may
choose to allow the Authoritative CDN to redistribute the shared key
to a subset of their Downstream CDNs .</t>
<t>For HTTP-based request routing, the Signed URI (i.e. Target CDN
URI) provided by the CSP reaches the Upstream CDN. After this URI has
been verified to be correct by the Upstream CDN, the Upstream CDN
creates and signs a new Redirection URI to redirect the UA to the
Downstream CDN. Since this new URI also has a new URI Signature, this
new signature can be based around the trust relationship between the
Upstream CDN and Downstream CDN, and the relationship between the
Downstream CDN and CSP is not relevant. Given the fact that such a
relationship between Upstream CDN and Downstream CDN always exists,
both asymmetric public/private keys and symmetric shared secret keys
can be used for URI Signing. Note that the signed Redirection URI
SHOULD maintain the same level of security as the original Signed
URI.</t>
</section>
<section title="URI Signing in a non-CDNI context">
<t>While the URI signing scheme defined in this document was primarily
created for the purpose of allowing URI Signing in CDNI scenarios,
e.g. between a uCDN and a dCDN or between a CSP and a dCDN, there is
nothing in the defined URI Signing scheme that precludes it from being
used in a non-CDNI context. As such, the described mechanism could be
used in a single-CDN scenario such as shown in <xref
target="fig_single_cdn"/> in <xref target="background"/>, for example
to allow a CSP that uses different CDNs to only have to implement a
single URI Signing mechanism.</t>
</section>
</section>
<section anchor="http_adaptive_streaming" title="URI Signing and HTTP Adaptive Streaming">
<t>For content that is delivered via an HTTP Adaptive Streaming (HAS) protocol, such as MPEG DASH [Editor's Note: Include reference], special provisions need to be made in order to ensure URI Signing can be applied. In general, HAS protocols work by breaking large objects (e.g. videos), into a sequence of small, independent chunks. Such chunks are then referenced by a separate manifest file, which either includes a list of URLs to the chunks or specifies an algorithm through which a User Agent can construct the URLs to the chunks. Requests for chunks therefore originate from the manifest file and, unless the URLs in the manifest file point to the CSP, are not subjected to redirection and URI Signing. This opens up the vulnerability of malicious User Agents sharing the manifest file and deep-linking to the chunks.</t>
<t>One method for dealing with this vulnerability would be to include in the manifest itself Signed URIs that point to the individual chunks. There exist a number of issues with that approach. First, it requires the CDN delivering the manifest to rewrite the manifest file for each User Agent, which would require the CDN to be aware of the exact HAS protocol and version used. Secondly, it would require the expiration time of the Signed URIs to be valid for at least the full duration of the content described by the manifest. Since it is not uncommon for a manifest file to contain a video item of more than 30 minutes in length, this would require the Signed URIs to be valid for a long time, thereby reducing their effectiveness and that of the URI Signing mechanism in general. For a more detailed analysis of how HAS protocols affect CDNI, see <xref target="RFC6983">Models for HTTP-Adaptive-Streaming-Aware CDNI</xref>.</t>
<t>In order to allow for effective access control of HAS content, the URI signing scheme defined in this document instead supports a mechanism through which subsequent chunk requests can be chained together. As part of the URI validation procedure, the CDN can generate a Signed Token that the UA can use to do a subsequent request. More specifically, whenever a UA successfully retrieves a chunk, it receives, in the HTTP 2xx Successful message, a Signed Token that it can use whenever it requests the next chunk. As long as each Signed Token in the chain is correctly validated before a new one is generated, the chain is not broken and the User Agent can successfully retrieve additional chunks. Given the fact that with HAS protocols, it is usually not possible to determine a priori which chunk will be requested next (i.e. to allow for seeking within the content and for switching to a different quality level), the Signed Token includes a scoping mechanism that allows it to be valid for more than one URL.</t>
<t>In order for this chaining of Signed Tokens to work, it is necessary for a UA to extract the Signed Token from the HTTP 2xx Successful message of an earlier request and use it to retrieve the next chunk. The exact mechanism by which the client does this depends on the exact HAS protocol and since this document is only concerned with the generation and validation of incoming request, this process is outside the scope of this document. However, in order to also support legacy UAs that do not include any specific provisions for the handling of Signed Tokens, this document does define a legacy mechanism using HTTP Cookies that allows such UAs to support the concept of chained Signed Tokens without requiring any support on the UA side.</t>
</section>
<section anchor="uri_format" title="Signed URI Information Elements">
<t>The concept behind URI Signing is based on embedding in either the Signed URI or Signed Token a number of information elements that can be validated to ensure the UA has legitimate access to the content. These information elements are appended, in an encapsulated form, to the Original URI to form the Signed URI. Alternatively, the encapsulated elements are placed in the Signed Token.</t>
<t>For the purposes of the URI signing mechanism described in this
document, three types of information elements may be embedded in the
URI:</t>
<t><list style="symbols">
<t>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. Another example is the Path Pattern information element that is used to define the scope of a Signed Token.</t>
<t>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.</t>
<t>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 Signed URI or Signed Token. A typical Signed URI or Token will only contain one embedded URI
Signature Information Element.</t>
</list></t>
<t>In addition, the this document specifies the following URI
attribute:</t>
<t><list style="symbols">
<t>URI Signing Package Attribute: The URI attribute is a container that encapsulates all the URI Signing Information Elements in an encoded format. In the case of a Signed URI, only this attribute is exposed as a URI query string parameter. In the case of a Signed Token, this attribute constitutes the Signed Token and is communicated in either the URI, a dedicated header, or as an HTTP Cookie.</t>
</list></t>
<t>Two types of keys can be used for URI Signing: asymmetric keys and
symmetric keys. Asymmetric keys are based on a public/private key pair
mechanism and always contain a private key only known to the entity
signing the URI (either CSP or uCDN) and a public key for the
verification of the Signed URI. With symmetric keys, the same key is
used by both the signing entity for signing the URI as well as by the
validating entity for validating the Signed URI. Regardless of the type
of keys used, the validating entity has to obtain the key (either the
public or the symmetric key). There are very different requirements for
key distribution (out of scope of this document) with asymmetric keys
and with symmetric keys. Key distribution for symmetric keys requires
confidentiality to prevent another party from getting access to the key,
since it could then generate valid Signed URIs for unauthorized
requests. Key distribution for asymmetric keys does not require
confidentiality since public keys can typically be distributed openly
(because they cannot be used for URI signing) and private keys are kept
by the URI signing function.</t>
<t>Note that all the URI Signing Information Elements and the URI Signing Package Attribute query string
attribute are mandatory to implement, but not mandatory to use.</t>
<section anchor="enforce_attributes"
title="Enforcement Information Elements">
<t>This section identifies the set of information elements that may be needed to enforce the CSP distribution policy. New information
elements may be introduced in the future to extend the capabilities of
the distribution policy.</t>
<t>In order to provide flexibility in distribution policies to be enforced, the exact subset of information elements used in a Signed URI or Signed Token is a deployment decision. The defined keyword for each information element is specified in parenthesis below.</t>
<t>The following information elements are used to enforce the
distribution policy:</t>
<t><list style="symbols">
<t>Expiry Time (ET) [optional] - Time when the Signed URI or Signed Token expires. This is represented as an integer denoting the number of seconds since midnight 1/1/1970 UTC (i.e. UNIX epoch). The request is rejected if the received time is later than this timestamp. Note: The time, including time zone, on the entities that generate and validate the Signed URI or Signed Token need to be in sync (e.g. NTP is used).</t>
<t>Client IP (CIP) [optional] - IP address of the client for which this Signed URI or Signed Token is generated. This is represented in dotted decimal format for IPv4 or canonical text representation for <xref target="RFC5952">IPv6 address</xref> . The request is rejected if sourced from a client with a different IP address.</t>
<t>Path Pattern (PP) [mandatory for Signed Token] - Path Pattern that describes for which content the Signed Token is valid. The Path Pattern contains an expression to match against the requested URI path to check whether the requested content is allowed to be requested with the Signed Token. A Path Pattern contains a sequence of one or more path segments seperated by a slash ('/') character. The pattern may include the wildcards '*' and '?', where '*' matches any sequence of characters (including the empty string) and '?' matches exactly one character. The three literals '\', '*' and '?' should be escaped as '\\', '\*' and '\?'. All other characters are treated as literals. The following is an example of a valid Path Pattern: '*/folder/content-83112371/quality_*/segment????.mp4'. The Path Pattern Information Element MUST NOT be used in a Signed URI.</t>
</list></t>
<t>The Expiry Time Information Element ensures that the content
authorization expires after a predetermined time. This limits the time
window for content access and prevents replay of the request beyond
the authorized time window.</t>
<t>The Client IP Information Element is used to restrict content
access to a particular User Agent, based on its IP address for whom
the content access was authorized.</t>
<t>The Path Pattern Information Element is used to restrict content access to a particular set of URLs, based on the path component of the URI on which it is available. This is primarily useful for content delivered via an HTTP Adaptive Streaming protocol using a manifest file, where it is often not known a priori which segment will be requested next.</t>
<t>Note: See the <xref target="security">Security Considerations</xref> section on the limitations of using an expiration time and client IP address for distribution policy enforcement.</t>
</section>
<section anchor="compute_attributes"
title="Signature Computation Information Elements">
<t>This section identifies the set of information elements that may be needed to verify the URI Signature and/or calculate a new Signed Token. New information elements may be introduced in the future if new URI signing algorithms are developed.</t>
<t>The defined keyword for each information element is specified in
parenthesis below.</t>
<t>The following information elements are used to validate the URI by
recreating the URI Signature and/or calculate a new Signed Token.</t>
<t><list style="symbols">
<t>Version (VER) [optional] - An 8-bit unsigned integer used for identifying the
version of URI signing method. If this Information Element is not
present in the Signed URI or Signed Token, the default version
is 1.</t>
<t>Key ID (KID) [optional] - A string used for obtaining the key (e.g. database lookup, URI reference) which is needed to validate the URI Signature. The KID and KID_NUM information elements MUST NOT be present in the same Signed URI or Signed Token.</t>
<t>Numerical Key ID (KID_NUM) [optional] - A 64-bit unsigned integer used as an optional alternative for KID. The KID and KID_NUM information elements MUST NOT be present in the same Signed URI or Signed Token.</t>
<t>Hash Function (HF) [optional] - A string used for identifying
the hash function to compute the URI signature with HMAC. If this
Information Element is not present in the Signed URI or Signed Token, the default hash function is SHA-256.</t>
<t>Digital Signature Algorithm (DSA) [optional] - Algorithm used
to calculate the Digital Signature. If this Information Element is
not present in the Signed URI or Signed Token, the default is
EC-DSA.</t>
<t>URI Signing Cookie Flag (USCF) [optional] - The presence of this flag indicates the URI Signing Information Elements contents of the URI Signing Package Attribute are communicated via the Cookie header of the HTTP request instead of via the query string component of the URI.</t>
<t>Expiration Time Setting (ETS) [optional] - An 16-bit unsigned integer (in seconds) used for setting the value of the Expiry Time information element in newly generated Signed Tokens in case a chain of Signed Tokens is used.</t>
</list></t>
<t>The Version Information Element indicates which version of URI
signing scheme is used (including which attributes and algorithms are
supported). The present document specifies Version 1. If the Version
attribute is not present in the Signed URI or Signed Token, then the version is
obtained from the CDNI metadata, else it is considered to have been
set to the default value of 1. More versions may be defined in the
future.</t>
<t>The Key ID Information Element is used to retrieved the key which is needed as input to the algorithm for validating the Signed URI or Signed Token. The method used for obtaining the actual key from the reference included in the Key ID Information Element is outside the scope of this document. Instead of using the KID element, which is a string, it is possible to use the KID_NUM element for numerical Key identifiers instead. The KID_NUM element is a 64-bit unsigned integer. In cases where numerical KEY IDs are used, it is RECOMMENDED to use KID_NUM instead of KID.</t>
<t>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 <xref
target="signature_attributes"/>.</t>
<t>The Digital Signature Algorithm Information Element indicates the
digital signature function to be in the case asymmetric keys are used.
The Digital Signature Algorithm Information Element is used in
combination with the Digital Signature Information Element defined in
section <xref target="signature_attributes"/>.</t>
<t>The URI Signing Cookie Flag Information Element is used to indicate the contents of the URI Signing Package attribute is communicated via the Cookie header of the HTTP request instead of via the query string component of the URI. The primary use case for this is the case where the chained Signed Token mechanism described in <xref target="http_adaptive_streaming"/> is used in combination with legacy UAs.</t>
<t>The Expiration Time Setting Information Element is used to communicate to the CDN to which duration the Expiry Time information element should be set whenever a new Signed Token is generated. This information element is only used in combination with the chained Signed Token mechanism for HTTP Adaptive Streaming content as described in <xref target="http_adaptive_streaming"/>.</t>
</section>
<section anchor="signature_attributes"
title="URI Signature Information Elements">
<t>This section identifies the set of information elements that carry
the URI Signature that is used for checking the integrity and
authenticity of the URI.</t>
<t>The defined keyword for each information element is specified in
parenthesis below.</t>
<t>The following information elements are used to carry the actual URI
Signature.</t>
<t><list style="symbols">
<t>Message Digest (MD) [mandatory for symmetric key] - A string
used for the message digest generated by the URI signing
entity.</t>
<t>Digital Signature (DS) [mandatory for asymmetric keys] - A
string used for the digital signature provided by the URI signing
entity.</t>
</list></t>
<t>The Message Digest attribute contains the message digest used to
validate the Signed URI or Signed Token when symmetric keys are used.</t>
<t>The Digital Signature attribute contains the digital signature used
to verify the Signed URI or Signed Token when asymmetric keys are used.</t>
<t>In the case of symmetric key, HMAC algorithm is used for the
following reasons: 1) Ability to use hash functions (i.e. no changes
needed) with well understood cryptographic properties that perform
well and for which code is freely and widely available, 2) Easy to
replace the embedded hash function in case faster or more secure hash
functions are found or required, 3) Original performance of the hash
function is maintained without incurring a significant degradation,
and 4) Simple way to use and handle keys. The default HMAC algorithm
used is SHA-256.</t>
<t>In the case of asymmetric keys, Elliptic Curve Digital Signature
Algorithm (EC DSA) - a variant of DSA - is used because of the
following reasons: 1) Key size is small while still offering good
security, 2) Key is easy to store, and 3) Computation is faster than
DSA or RSA.</t>
</section>
<section anchor="token_attribute" title="URI Signing Package Attribute">
<t>The URI Signing Package Attribute is an encapsulation container for
the URI Signing Information Elements defined in the previous sections.
The URI Signing Information Elements are encoded and stored in this
attribute. In the case of a Signed URI, the URI Signing Package Attribute is appended to the Original
URI to create the Signed URI. In the case of a Signed Token, the URI Signing Package Attribute can be communicated via the query string component of a URI, via a dedicated HTTP header, or as an HTTP Cookie. </t>
<t>The primary advantage of the URI Signing Package Attribute is that
it avoids having to expose the URI Signing Information Elements
directly in the query string of the URI, thereby reducing the
potential for a namespace collision space within the URI query string.
A side-benefit of the attribute is the obfuscation performed by the
URI Signing Package Attribute hides the information (e.g. client IP
address) from view of the common user, who is not aware of the
encoding scheme. Obviously, this is not a security method since anyone
who knows the encoding scheme is able to obtain the clear text. Note
that any parameters appended to the query string after the URI Signing
Package Attribute are not validated and hence do not affect URI
Signing.</t>
<t>The following attribute is used to carry the encoded set of URI
Signing Information Elementsin the Signed URI or the Signed Token.</t>
<t><list style="symbols">
<t>URI Signing Package (URISigningPackage) - The encoded attribute
containing all the CDNI URI Signing Information Elements used for
URI Signing.</t>
</list></t>
<t>The URI Signing Package Attribute contains the URI Signing
Information Elements in the Base-64 encoding with URL and Filename
Safe Alphabet (a.k.a. "base64url") as specified in the <xref
target="RFC4648">Base-64 Data Encoding</xref> document. The URI
Signing Package Attribute is the only URI Signing Information Element exposed in
a Signed URI. The attribute MUST be the last parameter in the query
string component of the URI when the Signed URI is generated. However, a client
or CDN may append other query parameters unrelated to URI Signing to
the Signed URI. Such additional query parameters SHOULD NOT use the
same name as the URI Signing Package Attribute to avoid namespace
collision and potential failure of the URI Signing validation. In the case of a Signed Token, the URI Signing Package Attribute fully constitutes the Signed Token.</t>
<t>The query string parameter name of the URI Signing Package Attribute shall be defined in the CDNI Metadata interface. If the CDNI Metadata interface is not used, or does not include a parameter name for the URI Signing Package Attribute, the parameter name is set by configuration (out of scope of this document).</t>
</section>
<section title="User Agent Attributes">
<t>For some use cases, such as logging, it might be useful to allow
the UA, or another entity, add one or more attributes to the Signed
URI for purposes other than URI Signing without causing URI Signing to
fail. In order to do so, such attributes MUST be appended after the
URI Signing Packacke Attribute. Any attributes appended in such way
after the URI Signature has been calculated are not validated for the
purpose of content access authorization. Adding any such attributes to
the Signed URI before the URI Signing Packacke Attribute will cause
the URI Signing validation to fail.</t>
<t>Note that a malicious UA might potentially use the ability to
append attributes to the Signed URI in order to try to influence the
content that is delivered. For example, the UA might append
'&quality=HD' to try to make the dCDN deliver an HD version of 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 of the URI validation. In order to deal with
this vulnerability, a dCDN is RECOMMENDED to ignore any query strings
appended after the URI Signing Package Attribute for the purpose of
content selection.</t>
</section>
</section>
<section anchor="signing_uri" title="Generating a URI Signature">
<t>This section describes the process of generating a URI Signature. The nature of this process depends on whether a Signed URI or Signed Token is being generated. A Signed Token will typically be used as part of a chain of Signed Tokens for the delivery of HTTP Adaptive Streaming content (see <xref target="http_adaptive_streaming"/>). <xref target="regular_signing"/> defines creating a regular Signed URI. <xref target="initial_signed_token"/> defines creating the initial Signed Token for HAS content.</t>
<section anchor="regular_signing" title="Creating a Signed URI">
<t>The following procedure defines the URI Signing algorithm for creating a Signed URI for regular (i.e. non-HTTP Adaptive Streaming) content in which the Path Pattern information element is not used. Note that some steps may be skipped if the CSP does not enforce a distribution policy and the Enforcement Information Elements are therefore not necessary. A URI (as defined in <xref target="RFC3986">URI Generic Syntax</xref>) contains the following parts: scheme name, authority, path, query, and fragment. In a Signed URI, the entire URI except the "scheme name" part is protected by the URI signature. This allows the URI signature to be validated correctly in the case when a client performs a fallback to another scheme (e.g. HTTP) for a content item referenced by a URI with a specific scheme (e.g. RTSP). The benefit is that the content access is protected regardless of the type of transport used for delivery. If the CSP wants to ensure a specific protocol is used for content delivery, that information is passed by CDNI metadata. Note: Support for changing of the URL scheme requires that the default port is used, or that the protocols must both run on the same non-standard port.</t>
<t>The process of generating a Signed URI can be divided into two sets of steps: first, calculating the URI Signature and then, packaging the URI Signature along with the URI Signing Information Elements into a URI Signing Package Attribute and appending it to the Original URI. Note it is possible to use some other algorithm and implementation as long as the same result is achieved. An example for the Original URI, "http://example.com/content.mov", is used to clarify the steps.</t>
<section title="Calculating the URI Signature (Signed URI)">
<t>Calculate the URI Signature for use with a Signed URI by following the procedure below.</t>
<t><list style="numbers">
<t>Copy the Original URI, excluding the "scheme name" part, into a buffer to hold the message for performing the operations below.</t>
<t>Check if the Original URI already contains a query string. If not, append a "?" character. If yes, append an "&" character.</t>
<t>If the version is the default value (i.e. "1"), skip this step. Otherwise, specify the version by appending the string "VER=#", where '#' represents the new version number. The following steps in the procedure is based on the initial version of URI Signing specified by this document. For other versions, reference the associated RFC for the URI signing procedure.</t>
<t>If time window enforcement is not needed, skip this step.<list style="letters">
<t>If an information element was added to the message, append an "&" character. Append the string "ET=". Note in the case of re-signing a URI, the information element is carried over from the received Signed URI.</t>
<t>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.</t>
<t>Convert this integer to a string and append to the message.</t>
</list></t>
<t>If client IP enforcement is not needed, skip this step.<list style="letters">
<t>If an information element was added to the message, append an "&" character. Append the string "CIP=". Note in the case of re-signing a URI, the attribute is carried over from the received Signed URI.</t>
<t>Convert the client's IP address in dotted decimal notation format (i.e. for IPv4 address) or canonical text representation (for <xref target="RFC5952">IPv6 address</xref>) to a string and append to the message. Note in the case of re-signing an URI, the value MUST remain the same as the received Signed URI.</t>
</list></t>
<t>Depending on the type of key used to sign the URI, compute the message digest or digital signature for symmetric key or asymmetric keys, respectively.<list style="letters">
<t>For symmetric key, HMAC is used.<list style="numbers">
<t>Obtain the shared key to be used for signing the URI.</t>
<t>If the key identifier is not needed, skip this step. If an information element was added to the message, 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.</t>
<t>Optional: If the hash function for the HMAC uses the default value ("SHA-256"), skip this step. If an information element was added to the message, append an "&" character. append the string "HF=". Append the string for the new type of 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.</t>
<t>If an information element was added to the message, append an "&" character. Append the string "MD=". The message now contains the complete section of the URI that is protected (e.g. "://example.com/content.mov?ET=1209422976&CIP=192.0.2.1&KID=example:keys:123&MD=").</t>
<t>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.</t>
<t>Convert the message digest to its equivalent hexadecimal format.</t>
<t>Append the string for the message digest (e.g. "://example.com/content.mov?ET=1209422976&CIP=192.0.2.1&KID=example:keys:123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc482bddaf").</t>
</list></t>
<t>For asymmetric keys, EC DSA is used.<list style="numbers">
<t>Generate the EC private and public key pair. Store the EC public key in a location that's reachable for any entity that needs to validate the URI signature.</t>
<t>If the key identifier is not needed, skip this step. If an information element was added to the message, 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. "http://example.com/public/keys/123") needed by the entity to locate the shared key for validating the URI signature. Note that in the case the Key ID URI is a URL to a public key, the Key ID URI SHOULD only contain the "scheme name", "authority", and "path" parts (i.e. query string is not allowed).</t>
<t>Optional: If the digital signature algorithm uses the default value ("EC-DSA"), skip this step. If an information element was added to the message, append an "&" character. Append the string "DSA=". Append the string denoting the new digital signature function.</t>
<t>If an information element was added to the message, append an "&" character. Append the string "DS=". The message now contains the complete section of the URI that is protected. (e.g. "://example.com/content.mov?ET=1209422976&CIP=192.0.2.1&KID=http://example.com/public/keys/123&DS=").</t>
<t>Compute the message digest using SHA-1 (without a key) for the message. Note: The digital signature generated in the next step is calculated over the SHA-1 message digest, instead of over the cleartype message, to reduce the length of the digital signature, and thereby the length of 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.</t>
<t>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.</t>
<t>Convert the digital signature to its equivalent hexadecimal format.</t>
<t>Append the string for the digital signature. In the case where EC-DSA algorithm is used, this string contains the values for the 'r' and 's' parameters, delimited by ':' (e.g. "://example.com/content.mov?ET=1209422976&CIP=192.0.2.1&KID=http://example.com/public/keys/123&DS=r:CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24E"
)</t>
</list></t>
</list></t>
</list></t>
</section>
<section title="Packaging the URI Signature (Signed URI)">
<t>Apply the URI Signing Package Attribute by following the procedure below to generate the Signed URI.</t>
<t><list style="numbers">
<t>Remove the Original URI portion from the message to obtain all
the URI Signing Information Elements, including the URI signature
(e.g.
"ET=1209422976&CIP=192.0.2.1&KID=example:keys:123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc482bddaf").</t>
<t>Compute the URI Signing Package Attribute using <xref target="RFC4648">Base-64 Data Encoding</xref> on the message (e.g. "VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTkyLjAuMi4xJktJRD1leGFtcGxlOmtleXM6MTIzJk1EPTFlY2IxNDQ2YTY0MzEzNTJhYWIwZmI2ZTBkY2EzMGUzMDM1NjU5M2E5N2FjYjk3MjIwMjEyMGRjNDgyYmRkYWY="). Note: This is the value for the URI Signing Package Attribute.</t>
<t>Copy the entire Original URI into a buffer to hold the
message.</t>
<t>Check if the Original URI already contains a query string. If
not, append a "?" character. If yes, append an "&"
character.</t>
<t>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.</t>
<t>Append the URI Signing token to the message (e.g. "http://example.com/content.mov?URISigningPackage=VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTkyLjAuMi4xJktJRD1leGFtcGxlOmtleXM6MTIzJk1EPTFlY2IxNDQ2YTY0MzEzNTJhYWIwZmI2ZTBkY2EzMGUzMDM1NjU5M2E5N2FjYjk3MjIwMjEyMGRjNDgyYmRkYWY="). Note: this is the completed Signed URI.</t>
</list></t>
</section>
</section>
<section anchor="initial_signed_token" title="Creating an initial Signed Token">
<t>The following procedure defines the algorithm for creating the initial Signed Token of a Signed Token chain as for example used with HTTP Adaptive Streaming content. Note that the process described in this section is only performed for creating the initial Signed Token of a particular chain. Subsequent Signed Tokens forming the same chain are generated as part of the URI Signature Validation process described in <xref target="validating_uri"/>. The creation of the initial Signed Token will typically be done by the CSP the first time a particular UA requests the manifest file. Choosing appropriate values of the Enforcement Information Elements in the initial Signed Token requires some knowledge of the structure of the HTTP Adapative Streaming content that is being requested.</t>
<t>In contrast with a Signed URI, where the URI Signature is calculated over the Original URI, a Signed Token does not protect the Original URI. Instead, the Path Pattern Information Element is used to convey the set of resources for which the particular Signed Token is valid.</t>
<t>The process of generating a initial Signed Token can be divided into two sets of steps: first, calculating the URI Signature and then, packaging the URI Signature along with the URI Signing Information Elements into a URI Signing Package to construct a Signed Token and appending the Signed Token to the message. Note it is possible to use some other algorithm and implementation as long as the same result is achieved. An example for the Original URI, "http://example.com/folder/content-83112371/manifest.xml", is used to clarify the steps.</t>
<section title="Calculating the URI Signature (initial Signed Token)">
<t>Calculate the URI Signature for use with a Signed Token by following the procedure below.</t>
<t><list style="numbers">
<t>Create a new buffer for constructing the Signed Token in the steps below.</t>
<t>If the URI Signing version used is the default one (i.e. "1"), skip this step. Otherwise, specify the version by appending the string "VER=#", where '#' represents the new version number. The following steps in the procedure is based on the initial version of URI Signing specified by this document. For other versions, reference the associated RFC for the URI signing procedure.</t>
<t>If time window enforcement is not needed, this step can be skipped.<list style="letters">
<t>If an information element was added to the message, append an "&" character. Append the string "ET=".</t>
<t>Get the current time in seconds since epoch (as an integer). Add the validity time of the initial Signed Token in seconds as an integer.</t>
<t>Convert this integer to a string and append to the message.</t>
<t>Append an "&" character. Append the string "ETS=".</t>
<t>Append the Expiration Time Setting (in seconds) in the form of a string to the message. Note: the length of the Expiration Time Setting should be appropriate given the segment duration of the HTTP Adaptive Streaming content in question. As an example, if the segment duration is 10 seconds, the Expiration Time Setting should be at minimum 10 seconds, and preferably a bit more.</t>
</list></t>
<t>If client IP enforcement is not needed, this step can be skipped.<list style="letters">
<t>If an information element was added to the message, append an "&" character. Append the string "CIP=".</t>
<t>Convert the client's IP address in dotted decimal notation format (i.e. for IPv4 address) or canonical text representation (for <xref target="RFC5952">IPv6 address</xref>) to a string and append to the message.</t>
</list></t>
<t>If an information element was added to the message, append an "&" character. Append the string "PP=". </t>
<t>Append the value of the Path Pattern in the form of a string to the message. Note: the value of the Path Pattern element should be appropriate given the file and folder structure of the HTTP Adaptive Streaming content in question. As an example, if the Original URI for the manifest file is 'http://example.com/folder/content-83112371/manifest.xml', a suitable Path Pattern might be '*/content-83112371/*/segment????.mp4'.</t>
<t>Depending on the type of key used to sign the
URI, compute the message digest or digital signature for symmetric
key or asymmetric keys, respectively.<list style="letters">
<t>For symmetric key, HMAC is used.<list style="numbers">
<t>Obtain the shared key to be used for signing the
URI.</t>
<t>If the key identifier is not needed, skip this step. If an information element was added to the message, 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.</t>
<t>Optional: If the hash function for the HMAC uses the default value ("SHA-256"), skip this step. If an information element was added to the message, append an "&" character. append the string "HF=". Append the string for the new type of hash function to be used. Note one MUST use the same hash function as communicated in the original concatenated information element string or one of the allowable hash functions designated by the CDNI metadata.</t>
<t>If an information element was added to the message,
append an "&" character. Append the string "MD=". The message now contains the complete set of URI Signing Information Elements over which the URI Signature is computed (e.g. "ET=1209422976&ETS=15&CIP=192.0.2.1&PP=*/content-83112371/*/segment????.mp4&KID=example:keys:123&MD=").</t>
<t>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.</t>
<t>Convert the message digest to its equivalent
hexadecimal format.</t>
<t>Append the string for the message digest (e.g.
"ET=1209422976&ETS=15&CIP=192.0.2.1&PP=*/content-83112371/*/segment????.mp4&KID=example:keys:123&MD=d6117d7db8a68bd59f6e7e3343484831acd8f23bbaa7f44b285a2f3bb6f02cfd").</t>
</list></t>
<t>For asymmetric keys, EC DSA is used.<list style="numbers">
<t>Generate the EC private and public key pair. Store the
EC public key in a location that's reachable for any
entity that needs to validate the URI signature.</t>
<t>If the key identifier is not needed, skip this step. If an information element was added to the message, 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. "http://example.com/public/keys/123") needed by the entity to locate the shared key for validating the URI signature. Note that in the case the Key ID URI is a URL to a public key, the Key ID URI SHOULD only contain the "scheme name", "authority", and "path" parts (i.e. query string is not allowed).</t>
<t>Optional: If the digital signature algorithm uses the
default value ("EC-DSA"), skip this step. If an
information element was added to the message, append an
"&" character. Append the string "DSA=". Append the
string denoting the new digital signature function.</t>
<t>If an information element was added to the message,
append an "&" character. Append the string "DS=". The message now contains the complete set of URI Signing Information Elements over which the URI Signature is computed (e.g.
"ET=1209422976&ETS=15&CIP=192.0.2.1&PP=*/content-83112371/*/segment????.mp4&KID=example:keys:123&DS=").</t>
<t>Compute the message digest using SHA-1 (without a key)
for the message. Note: The digital signature generated in
the next step is calculated over the SHA-1 message digest,
instead of over the cleartype message, to reduce the
length of the digital signature, and thereby the length of
the Signed Token. Since SHA-1 is not used for cryptographic purposes
here, the security concerns around SHA-1 do not apply.</t>
<t>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.</t>
<t>Convert the digital signature to its equivalent
hexadecimal format.</t>
<t>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&ETS=15&CIP=192.0.2.1&PP=*/content-83112371/*/segment????.mp4&KID=example:keys:123&DS=r:CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24E"
)</t>
</list></t>
</list></t>
</list></t>
</section>
<section title="Packaging the URI Signature (initial Signed Token)">
<t>The following steps depend on whether the Signed Token is communicated to the UA via an HTTP 3xx Redirection message or via an HTTP 2xx Successful message. In the case of a redirection response, the Signed Token can be communicated as part of the query string component of the URL signalled via the Location header of the Redirection message. In the case of a 2xx Successful message, the Signed Token can be communicated via either a dedicated header or, for legacy UAs, via the Set-Cookie header.</t>
<section title="Communicating the Signed Token in a HTTP 3xx Redirection message">
<t>The following steps describe how the Signed Token can be communicated to the UA via an HTTP 3xx Redirection message.<list style="numbers">
<t>Copy the entire Original URI into a buffer to hold the message.</t>
<t>Check if the Original URI already contains a query string. If not, append a "?" character. If yes, append an "&" character.</t>
<t>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.</t>
<t>Encode the Signed Token by applying <xref target="RFC4648">Base-64 Data Encoding</xref> on the value of the Signed Token (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").</t>
<t>Append the URI Signing token to the message (e.g. "http://example.com/folder/content-83112371/manifest.xml?URISigningPackage=RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").</t>
<t>Place the message in the Location header of the HTTP 3xx Redirection message returned to the UA.</t>
</list></t>
</section>
<section title="Communicating the Signed Token in a HTTP 2xx Successful message">
<t>The following steps describe how the Signed Token can be communicated to the UA via an HTTP 2xx Successful message.</t>
<section title="Header-based">
<t>The following steps are used in case the UA is expected to implement a mechanisms for extracting the Signed Token from the dedicated URI Signing HTTP Header and place in the query string component of the next request.<list style="numbers">
<t>Encode the Signed Token by applying <xref target="RFC4648">Base-64 Data Encoding</xref> on the value of the Signed Token (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").</t>
<t>Place the value of the encoded Signed Token in the URI Signing Header of the HTTP 2xx Successful message of the content being returned to the UA. Note: The HTTP Header name to use is communicated via the CDNI Metadata Interface or set via configuration. Otherwise, it defaults to 'URISigningPackage'.</t>
</list></t>
</section>
<section title="Cookie-based">
<t>The following steps are used in combination with legacy UAs that do not support a dedicated URI Signing HTTP header.<list style="numbers">
<t>Encode the Signed Token by applying <xref target="RFC4648">Base-64 Data Encoding</xref> on the value of the Signed Token (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").</t>
<t>Add a 'URISigningPackage' cookie to the HTTP 2xx Successful message of the content being returned to the UA, with the value set to the encoded Signed Token.</t>
</list></t>
</section>
</section>
</section>
</section>
</section>
<section anchor="validating_uri" title="Validating a URI Signature">
<t>The process of validating a Signed URI or Signed Token can be divided into three sets of steps: first, extraction of the URI Signing information elements, then validation of the URI signature to ensure the integrity of the Signed URI or Signed Token, and finally, validation of the information elements to ensure proper enforcement of the distribution policy. In case the chained Signed Token mechanism for HTTP Adaptive Streaming, as defined in <xref target="http_adaptive_streaming"/>, is used, a fourth step for constructing and communicating the next Signed Token, is added. Note the first three steps in the algorithm described below apply irrespective of whether a Signed URI or Signed Token is received.</t>
<t>In the algorithm below, the integrity of the Signed URI or Signed Token is confirmed before distribution policy enforcement because validation procedure would detect the right event when the URI is tampered with. Note it is possible to use some other algorithm and implementation as long as the same result is achieved.</t>
<section title="Information Element Extraction">
<t>Extract the information elements embedded in the Signed URI or Signed Token. Note that some steps are to be skipped if the corresponding URI Signing Information Elements are not embedded in the Signed URI or Signed Token. <list style="numbers">
<t>Check if the query string component of the received URI contains the 'URISigningPackage' 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 URI Signing Package attribute. If the query string component of the received URI does not contain the URI Signing Package attribute, check if the HTTP request contains a 'URISigningPackage' cookie and use that as the URI Signing Package in the following steps. If the request does not contain the URI Signing Package query string attribute and does not contain a URISigningPackage cookie, the request is denied.</t>
<t>Decode the URI Signing Package using <xref target="RFC4648">Base-64 Data Encoding</xref> to obtain all the URI Signing Information Elements in the form of a concatenated string (e.g. "ET=1209422976&CIP=192.0.2.1&KID=example:keys:123&MD=1ecb1446a6431352aab0fb6e0dca30e30356593a97acb972202120dc482bddaf").</t>
<t>Extract the value from "VER", if the information element exists. Determine the version of the URI Signing algorithm used to process the Signed URI or Signed Token. 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 information elements string, then obtain the version number in another manner (e.g. configuration, CDNI metadata or default value).</t>
<t>Extract the value from "MD", if the information element exists. The existence of this information element
indicates a symmetric key is used.</t>
<t>Extract the value from "DS", if the information element exists. The existence of this information element
indicates an asymmetric key is used.</t>
<t>If neither the "MD" or "DS" attribute exists, 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.</t>
<t>Extract the value from "CIP", if the information element exists. The existence of this information element
indicates content delivery is enforced based on client IP
address.</t>
<t>Extract the value from "ET", if the information element exists. The existence of this information element
indicates content delivery is enforced based on time.</t>
<t>Extract the value from "PP", if the information element exists. The existence of this information element indicates content delivery is enforced based on whether there is a match between the path of the requested resource and the Path Pattern information element. The existence of this element further indicates that a chain of Signed Tokens is used, and a new Signed Token should be generated and communicated upon successful validation.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Extract the value from "USCF", if the information element exists. The existence of this information element indicates cookie-based communication for legacy UAs should be used for signalling the next Signed Token in case a HTTP 2xx Succcessful message is sent to the user.</t>
<t>Extract the value from "ETS", if the information element exists. This information element indicates the validity time of the next Signed Token in the chain.</t>
</list></t>
</section>
<section title="Signature Validation">
<t>Validate the URI Signature for the Signed URI or Signed Token.</t>
<t><list style="numbers">
<t>Create a new buffer for validating the Signed URI or Signed Token in the steps below.</t>
<t>If the received URI Signing Package contains the Path Pattern Information Element, this step can be skipped.<list style="letters">
<t>Copy the received URI, excluding the "scheme name" part, into the buffer.</t>
<t>Remove the "URISigningPackage" attribute from the message, if it exists. Remove any subsequent part of the query string after the "URISigningPackage" attribute.</t>
<t>Append the decoded value from the "URISigningPackage" attribute (which contains all the URI Signing Information Elements).</t>
</list></t>
<t>If the received URI Signing Package does NOT contain the Path Pattern Information Element, this step can be skipped. Copy the decoded contents of the Signed Token in the buffer.</t>
<t>Depending on the type of key used to create the Signed URI or Signed Token, validate the message digest or digital signature for symmetric key or asymmetric keys, respectively.<list style="letters">
<t>For symmetric key, HMAC algorithm is used.<list>
<t>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 received URI Signing Package, obtain the shared key via CDNI metadata or configuration.</t>
<t>If the "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. If the "HF" information element is not in the received URI Signing Package, the default hash function is SHA-256.</t>
<t>Extract the value from the "MD" information element. This is the received message digest.</t>
<t>Convert the message digest to binary format. This will be used to compare with the computed value later.</t>
<t>Remove the value part of the "MD" information element (but not the '=' character) from the message. The message is ready for validation of the message digest (e.g. "://example.com/content.mov?ET=1209422976&CIP=192.0.2.1&KID=example:keys:123&MD=").</t>
<t>Compute the message digest using the HMAC algorithm with the shared key and message as the two inputs to the hash function.</t>
<t>Compare the result with the received message digest to validate the Signed URI or Signed Token. If there is no match, the request is denied.</t>
</list></t>
<t>For asymmetric keys, a digital signature function is
used.<list>
<t>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 received URI Signing Package, obtain the public key via CDNI metadata or configuration.</t>
<t>If the "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. If the "DSA" information element is not in the received URI Signing Package, the default DSA is EC-DSA.</t>
<t>Extract the value from the "DS" information element. This is the received digital signature.</t>
<t>Convert the digital signature to binary format. This will be used for verification later.</t>
<t>Remove the value part of the "DS" information element (but not the '=' character) from the message. The message is ready for validation of the digital signature (e.g. "://example.com/content.mov?ET=1209422976&CIP=192.0.2.1&KID=http://example.com/public/keys/123&DS=").</t>
<t>Compute the message digest using SHA-1 (without a key) for the message.</t>
<t>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 or Signed Token. If signature is determined to be invalid, the request is denied.</t>
</list></t>
</list></t>
</list></t>
</section>
<section title="Distribution Policy Enforcement">
<t>Note the associated steps are to be skipped if the corresponding URI Signing Information Elements are not in the received URI Signing Package. The absence of a given Enforcement Information Element indicates enforcement of its purpose is not necessary in the CSP's distribution policy. The exception is the Path Pattern Information Element, which is mandatory for Signed Tokens.<list
style="numbers">
<t>If the "CIP" information element exists, validate that the request came from the same IP address as indicated in the "CIP" information element. If the IP address is incorrect, the request is denied.</t>
<t>If the "ET" information element exists, validate that the request arrived before expiration time based on the "ET" information element. If the time expired, the request is denied.</t>
<t>If the "PP" information element exists, validate that the requested resource is in the allowed set by matching the received URI against the Path Pattern information element. If there is no match, the request is denied.</t>
</list></t>
</section>
<section title="Subsequent Signed Token Generation">
<t>The following steps describe how to generate a subsequent Signed Token in a chain of Signed Tokens and are to be skipped in case the chained Signed Token mechanism for HTTP Adaptive Streaming content is not used. Note that the process for generating an initial Signed Token is described in <xref target="initial_signed_token"/> and the process below is used for generating all subsequent tokens after the initial one.</t>
<t>The process of generating a subsequent Signed Token can be divided into two sets of steps: first, calculating the URI Signature and then, packaging the URI Signature along with the URI Signing Information Elements into a URI Signing Package to construct a new Signed Token and appending the Signed Token to the message. Note it is possible to use some other algorithm and implementation as long as the same result is achieved.</t>
<section title="Calculating the URI Signature (subsequent Signed Token)">
<t>Calculate the URI Signature for use with the new Signed Token by following the procedure below.</t>
<t><list style="numbers">
<t>Create a new buffer for constructing the new Signed Token in the steps below.</t>
<t>If the URI Signing version used in the received URI Signing Package is the default one (i.e. "1"), skip this step. Otherwise, specify the version by appending the string "VER=#", where '#' represents the version number. The following steps in the procedure is based on the initial version of URI Signing specified by this document. For other versions, reference the associated RFC for the URI signing procedure.</t>
<t>If the received URI Signing Package does not contain the "ET" information element, skip this step.<list style="letters">
<t>If an information element was added to the message, append an "&" character. Append the string "ET=".</t>
<t>If the received URI Signing Package contains the "ETS" information element, perform this step.<list style="numbers">
<t>Get the value of the "ETS" information element and convert it to an integer.</t>
<t>Get the current time in seconds sinds epoch (as an integer) and add the value of the "ETS" information element as seconds.</t>
<t>Convert the result to a string and append it to the message.</t>
<t>Append the "&" character and the "ETS=" string.</t>
<t>Append the value of the "ETS" information element in the received URI Signing Package.</t>
</list></t>
<t>If the received URI Signing Package does not contain the "ETS" information element, perform this step. Get the value of the "ET" information element from the original concatenated information element string and append it to the message.</t>
</list></t>
<t>If the received URI Signing Package does not contain the "CIP" information element, skip this step.<list style="letters">
<t>If an information element was added to the message, append an "&" character. Append the string "CIP=".</t>
<t>Append the value of the "CIP" information element in the received URI Signing Package.</t>
</list></t>
<t>If an information element was added to the message, append an "&" character. Append the string "PP=". Append the value of the "PP" information element in the received URI Signing Package.</t>
<t>Depending on the type of key used to sign the received Signed Token, compute the message digest or digital signature for symmetric key or asymmetric keys, respectively.<list style="letters">
<t>For symmetric key, HMAC is used.<list style="numbers">
<t>Obtain the shared key to be used for signing the Signed Token.</t>
<t>If the key identifier is not needed, skip this step. If an information element was added to the message, 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.</t>
<t>Optional: If the hash function for the HMAC uses the default value ("SHA-256"), skip this step. If an information element was added to the message, append an "&" character. append the string "HF=". Append the string for the new type of hash function to be used. Note one MUST use the same hash function as communicated in the received URI Signing Package or one of the allowable hash functions designated by the CDNI metadata.</t>
<t>If an information element was added to the message, append an "&" character. Append the string "MD=". The message now contains the complete set of URI Signing Information Elements over which the URI Signature is computed (e.g. "ET=1209422976&ETS=15&CIP=192.0.2.1&PP=*/content-83112371/*/segment????.mp4&KID=example:keys:123&MD=").</t>
<t>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.</t>
<t>Convert the message digest to its equivalent hexadecimal format.</t>
<t>Append the string for the message digest (e.g.
"ET=1209422976&ETS=15&CIP=192.0.2.1&PP=*/content-83112371/*/segment????.mp4&KID=example:keys:123&MD=d6117d7db8a68bd59f6e7e3343484831acd8f23bbaa7f44b285a2f3bb6f02cfd").</t>
</list></t>
<t>For asymmetric keys, EC DSA is used.<list style="numbers">
<t>Generate the EC private and public key pair. Store the
EC public key in a location that's reachable for any
entity that needs to validate the URI signature.</t>
<t>If the key identifier is not needed, skip this step. If an information element was added to the message, 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. "http://example.com/public/keys/123") needed by the entity to locate the shared key for validating the URI signature. Note that in the case the Key ID URI is a URL to a public key, the Key ID URI SHOULD only contain the "scheme name", "authority", and "path" parts (i.e. query string is not allowed).</t>
<t>Optional: If the digital signature algorithm uses the
default value ("EC-DSA"), skip this step. If an
information element was added to the message, append an
"&" character. Append the string "DSA=". Append the
string denoting the new digital signature function.</t>
<t>If an information element was added to the message, append an "&" character. Append the string "DS=". The message now contains the complete set of URI Signing Information Elements over which the URI Signature is computed (e.g. "ET=1209422976&ETS=15&CIP=192.0.2.1&PP=*/content-83112371/*/segment????.mp4&KID=example:keys:123&DS=").</t>
<t>Compute the message digest using SHA-1 (without a key)
for the message. Note: The digital signature generated in
the next step is calculated over the SHA-1 message digest,
instead of over the cleartype message, to reduce the
length of the digital signature, and thereby the length of
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.</t>
<t>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.</t>
<t>Convert the digital signature to its equivalent
hexadecimal format.</t>
<t>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&ETS=15&CIP=192.0.2.1&PP=*/content-83112371/*/segment????.mp4&KID=example:keys:123&DS=r:CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D:s:57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24E"
)</t>
</list></t>
</list></t>
</list></t>
</section>
<section title="Packaging the URI Signature (subsequent Signed Token)">
<t>The following steps depend on whether the Signed Token is communicated to the UA via an HTTP 3xx Redirection message or via an HTTP 2xx Successful message. In the case of a redirection response, the Signed Token can be communicated as part of the query string component of the URL signalled via the Location header of the Redirection message. In the case of a 2xx Successful message, the Signed Token can be communicated via either a dedicated HTTP header or, for legacy UAs, via the Set-Cookie header. If the received URI Signing Package contains the 'USCF' Information Element, the new Signed Token MUST be communicated via the Cookie method. If the received URI Signing Package does NOT contain the 'USCF' Information Element, the new Signed Token SHALL be communicated via the dedicated HTTP header.</t>
<section title="Communicating the Signed Token in a HTTP 3xx Redirection message">
<t>The following steps describe how the new Signed Token can be communicated to the UA via an HTTP 3xx Redirection message.<list style="numbers">
<t>Copy the target URI of the HTTP 3xx Redirection message into a buffer to hold the message.</t>
<t>Check if the URI already contains a query string. If not, append a "?" character. If yes, append an "&" character.</t>
<t>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.</t>
<t>Encode the Signed Token by applying <xref target="RFC4648">Base-64 Data Encoding</xref> on the value of the Signed Token (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").</t>
<t>Append the URI Signing token to the message (e.g. "http://example.com/folder/content-83112371/manifest.xml?URISigningPackage=RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").</t>
<t>Place the message in the Location header of the HTTP 3xx Redirection message returned to the UA.</t>
</list></t>
</section>
<section title="Communicating the Signed Token in a HTTP 2xx Successful message">
<t>The following steps describe how the new Signed Token can be communicated to the UA via an HTTP 2xx Successful message.</t>
<section title="Header-based">
<t>If the received URI Signing Package does NOT contain the 'USCF' Information Element, the new Signed Token SHALL be communicated via the following method. <list style="numbers">
<t>Encode the Signed Token by applying <xref target="RFC4648">Base-64 Data Encoding</xref> on the value of the Signed Token (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").</t>
<t>Place the value of the encoded Signed Token in the URI Signing Header of the HTTP 2xx Successful message of the content being returned to the UA. Note: The HTTP Header name to use is communicated via the CDNI Metadata Interface or set via configuration. Otherwise, it defaults to 'URISigningPackage'.</t>
</list></t>
</section>
<section title="Cookie-based">
<t>If the received URI Signing Package contains the 'USCF' Information Element, the new Signed Token MUST be communicated via the following method.<list style="numbers">
<t>Encode the Signed Token by applying <xref target="RFC4648">Base-64 Data Encoding</xref> on the value of the Signed Token (e.g. "RVQ9MTIwOTQyMjk3NiZhbXA7RVRTPTE1JmFtcDtDSVA9MTkyLjAuMi4xJmFtcDtQUD0qL2NvbnRlbnQtODMxMTIzNzEvKi9zZWdtZW50Pz8/Py5tcDQmYW1wO0tJRD1leGFtcGxlOmtleXM6MTIzJmFtcDtNRD1kNjExN2Q3ZGI4YTY4YmQ1OWY2ZTdlMzM0MzQ4NDgzMWFjZDhmMjNiYmFhN2Y0NGIyODVhMmYzYmI2ZjAyY2Zk").</t>
<t>Add a 'URISigningPackage' cookie to the HTTP 2xx Successful message of the content being returned to the UA, with the value set to the encoded Signed Token.</t>
</list></t>
</section>
</section>
</section>
</section>
</section>
<section anchor="cdni_interfaces"
title="Relationship with CDNI Interfaces">
<t>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?).</t>
<section anchor="control" title="CDNI Control Interface">
<t>URI Signing has no impact on this interface.</t>
</section>
<section anchor="advertisement"
title="CDNI Footprint & Capabilities Advertisement Interface">
<t>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.</t>
<t>In general, new information elements introduced to enhance URI
Signing requires a draft and a new version. ForInformation
Elements,</t>
<t><list>
<t>For Enforcement Information Elements, there is no need to
advertise the based information elements such as "CIP" and
"ET".</t>
<t>For Signature Computation Information Elements:<list>
<t>No need to advertise "VER" Information Element unless it's
not "1". In this case, a draft is needed to describe the new
version.</t>
<t>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.</t>
<t>Advertise value of the "DSA" Information Element (i.e.
EC-DSA) to indicate support for the DSA; Need IANA assignment
for new digital signature algorithm.</t>
<t>Advertise "MD" Information Element (i.e. EC-DSA) to
indicate support for symmetric key method; A new draft is
needed for an alternative method.</t>
<t>Advertise "DS" Information Element (i.e. EC-DSA) to
indicate support for asymmetric key method; A new draft is
needed for an alternative method.</t>
</list></t>
<t>For URI Signing Package Attribute, there is no need to
advertise the base attribute.</t>
</list></t>
</section>
<section anchor="redirection"
title="CDNI Request Routing Redirection Interface">
<t>The <xref target="I-D.ietf-cdni-redirection">CDNI Request Routing
Redirection Interface</xref> 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:<list>
<t>Consistency with interative request routing method</t>
<t>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)</t>
<t>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</t>
</list></t>
</section>
<section anchor="metadata" title="CDNI Metadata Interface">
<t>The <xref target="I-D.ietf-cdni-metadata">CDNI Metadata
Interface</xref> 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.</t>
<t>The UriSigning Metadata object contains information to enable URI
signing and validation by a dCDN. The UriSigning properties are
defined below.</t>
<t><list style="empty">
<t>Property: enforce<list style="empty">
<t>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.</t>
<t>Type: Boolean</t>
<t>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.</t>
</list></t>
<t>Property: key-id<list style="empty">
<t>Description: Designated key identifier used for URI Signing
computation when the Signed URI does not contain the Key ID
information element.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: No. A Key ID is not essential for all
implementations of URI signing.</t>
</list></t>
<t>Property: key-id-set<list style="empty">
<t>Description: Allowable Key ID set that the Signed URI's Key
ID information element can reference.</t>
<t>Type: List of Strings</t>
<t>Mandatory-to-Specify: No. Default is to allow any Key ID.</t>
</list></t>
<t>Property: hash-function<list style="empty">
<t>Description: Designated hash function used for URI Signing
computation when the Signed URI does not contain the Hash
Function information element.</t>
<t>Type: String (limited to the hash function strings in the
registry defined by the <xref target="IANA">IANA
Considerations</xref> section)</t>
<t>Mandatory-to-Specify: No. Default is SHA-256.</t>
</list></t>
<t>Property: hash-function-set<list style="empty">
<t>Description: Allowable Hash Function set that the Signed
URI's Hash Function information element can reference.</t>
<t>Type: List of Strings</t>
<t>Mandatory-to-Specify: No. Default is to allow any hash
function.</t>
</list></t>
<t>Property: digital-signature-algorithm<list style="empty">
<t>Description: Designated digital signature function used for
URI Signing computation when the Signed URI does not contain
the Digital Signature Algorithm information element.</t>
<t>Type: String (limited to the digital signature algorithm
strings in the registry defined by the <xref
target="IANA">IANA Considerations</xref> section).</t>
<t>Mandatory-to-Specify: No. Default is EC-DSA.</t>
</list></t>
<t>Property: digital-signature-algorithm-set<list style="empty">
<t>Description: Allowable digital signature function set that
the Signed URI's Digital Signature Algorithm information
element can reference.</t>
<t>Type: List of Strings</t>
<t>Mandatory-to-Specify: No. Default is to allow any DSA.</t>
</list></t>
<t>Property: version<list style="empty">
<t>Description: Designated version used for URI Signing
computation when the Signed URI does not contain the VER
attribute.</t>
<t>Type: Integer</t>
<t>Mandatory-to-Specify: No. Default is 1.</t>
</list></t>
<t>Property: version-set<list style="empty">
<t>Description: Allowable version set that the Signed URI's
VER attribute can reference.</t>
<t>Type: List of Integers</t>
<t>Mandatory-to-Specify: No. Default is to allow any
version.</t>
</list></t>
<t>Property: package-attribute<list style="empty">
<t>Description: Overwrite the default name for the URL Signing
Package Attribute.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: No. Default is
"URISigningPackage".</t>
</list></t>
</list></t>
<t>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.</t>
</section>
<section anchor="logging" title="CDNI Logging Interface">
<t>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.</t>
<t>The following CDNI Logging field for URI Signing SHOULD be
supported in the HTTP Request Logging Record as specified in <xref
target="I-D.ietf-cdni-logging">CDNI Logging Interface</xref>.</t>
<t><list style="symbols">
<t>s-uri-signing (mandatory): <list>
<t>format: 3DIGIT</t>
<t>field value: this characterises the uri signing validation
performed by the Surrogate on the request. The allowed values
are:<list>
<t>"0" : no uri signature validation performed</t>
<t>"1" : uri signature validation performed and
validated</t>
<t>"2" : uri signature validation performed and
rejected</t>
</list></t>
<t>occurrence: there MUST be zero or exactly one instance of
this field.</t>
</list></t>
<t>s-uri-signing-deny-reason (optional): <list>
<t>format: QSTRING</t>
<t>field value: the rejection reason when uri signature
performed by the Surrogate on the request. Examples:<list>
<t>"invalid client IP address"</t>
<t>"expired signed URI"</t>
<t>"incorrect URI signature"</t>
</list></t>
<t>occurrence: there MUST be zero or exactly one instance of
this field.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="operation" title="URI Signing Message Flow">
<t>URI Signing supports both HTTP-based and DNS-based request routing.
<xref target="RFC2104">HMAC</xref> 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.</t>
<section anchor="http" title="HTTP Redirection">
<t>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.</t>
<t>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.</t>
<figure title="Figure 3: HTTP-based Request Routing with URI Signing">
<artwork><![CDATA[
End-User dCDN uCDN CSP
| | | |
| 1.CDNI FCI interface used to | |
| advertise URI Signing capability| |
| |------------------->| |
| | | |
| 2.Provides information to validate URI signature|
| | |<-------------------|
| | | |
| 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| |
| |<-------------------| |
|4.Authorization request | |
|------------------------------------------------------------->|
| | | [Apply distribution
| | | policy] |
| | | |
| | (ALT: Authorization decision)
|5.Request is denied | | <Negative> |
|<-------------------------------------------------------------|
| | | |
|6.CSP provides signed URI | <Positive> |
|<-------------------------------------------------------------|
| | | |
|7.Content request | | |
|---------------------------------------->| [Validate URI |
| | | signature] |
| | | |
| | (ALT: Validation result) |
|8.Request is denied | <Negative>| |
|<----------------------------------------| |
| | | |
|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 |
| |------------------->| |]]></artwork>
</figure>
<t><list style="numbers">
<t>Using the CDNI Footprint & Capabilities Advertisement
interface, the Downstream CDN advertises its capabilities
including URI Signing support to the Authoritative CDN.</t>
<t>CSP provides to the Authoritative CDN the information needed to
validate URI signatures from that CSP. For example, this
information may include a hashing function, algorithm, and a key
value.</t>
<t>Using the CDNI Metadata interface, the Authoritative CDN
communicates to a Downstream CDN the information needed to
validate URI signatures from the Authoritative CDN for the given
CSP. For example, this information may include the URI query
string parameter name for the URI Signing Package Attribute, a
hashing algorithm and/or a key corresponding to the trust
relationship between the Authoritative CDN and the Downstream
CDN.</t>
<t>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</t>
<t>If the authorization decision is negative, the CSP rejects the
request.</t>
<t>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.</t>
<t>On receipt of the corresponding content request, the
authoritative CDN validates the URI Signature in the URI using the
information provided by the CSP.</t>
<t>If the validation is negative, the authoritative CDN rejects
the request</t>
<t>If the validation is positive, the authoritative CDN computes a
Signed URI that is based on unique parameters of that request and
provides to the end user as the URI to use to further request the
content from the Downstream CDN</t>
<t>On receipt of the corresponding content request, the Downstream
CDN validates the URI Signature in the Signed URI using the
information provided by the Authoritative CDN in the CDNI
Metadata</t>
<t>If the validation is negative, the Downstream CDN rejects the
request and sends an error code (e.g. 403) in the HTTP
response.</t>
<t>If the validation is positive, the Downstream CDN serves the
request and delivers the content.</t>
<t>At a later time, Downstream CDN reports logging events that
includes URI signing information.</t>
</list></t>
<t>With HTTP-based request routing, URI Signing matches well the
general chain of trust model of CDNI both with symmetric key and
asymmetric keys because the key information only need to be specific
to a pair of adjacent CDNI hops.</t>
</section>
<section anchor="dns" title="DNS Redirection">
<t>For DNS-based request routing, the CSP and Authoritative CDN must
agree on a trust model appropriate to the security requirements of the
CSP's particular content. Use of asymmetric public/private keys allows
for unlimited distribution of the public key to Downstream CDNs.
However, if a shared secret key is preferred, then the CSP may want to
restrict the distribution of the key to a (possibly empty) subset of
trusted Downstream CDNs. Authorized Delivery CDNs need to obtain the
key information to validate the Signed UR, which is computed by the
CSP based on its distribution policy.</t>
<t>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.</t>
<figure title="Figure 4: DNS-based Request Routing with URI Signing">
<artwork><![CDATA[
End-User dCDN uCDN CSP
| | | |
| 1.CDNI FCI interface used to | |
| advertise URI Signing capability| |
| |------------------->| |
| | | |
| 2.Provides information to validate URI signature|
| | |<-------------------|
| 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| |
| |<-------------------| |
|4.Authorization request | |
|------------------------------------------------------------->|
| | | [Apply distribution
| | | policy] |
| | | |
| | (ALT: Authorization decision)
|5.Request is denied | | <Negative> |
|<-------------------------------------------------------------|
| | | |
|6.Provides signed URI | <Positive> |
|<-------------------------------------------------------------|
| | | |
|7.DNS request | | |
|---------------------------------------->| |
| | | |
|8.Redirect DNS to dCDN | |
|<----------------------------------------| |
| | | |
|9.DNS request | | |
|------------------->| | |
| | | |
|10.IP address of Surrogate | |
|<-------------------| | |
| | | |
|11.Content request | | |
|------------------->| [Validate URI | |
| | signature] | |
| | | |
| (ALT: Validation result) | |
|12.Request is denied| <Negative> | |
|<-------------------| | |
| | | |
|13.Content delivery | <Positive> | |
|<-------------------| | |
: : : :
: (Later in time) : : :
|14.CDNI Logging interface to report URI Signing information |
| |------------------->| |
]]></artwork>
</figure>
<t><list style="numbers">
<t>Using the CDNI Footprint & Capabilities Advertisement
interface, the Downstream CDN advertises its capabilities
including URI Signing support to the Authoritative CDN.</t>
<t>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.</t>
<t>Using the CDNI Metadata interface, the Authoritative CDN
communicates to a Downstream CDN the information needed to
validate cryptographic signatures from the CSP (e.g. the URI query
string parameter name for the URI Signing Package Attribute). In
the case of symmetric key, the Authoritative CDN checks if the
Downstream CDN is allowed by CSP to obtain the shared secret
key.</t>
<t>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.</t>
<t>If the authorization decision is negative, the CSP rejects the
request</t>
<t>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.</t>
<t>End user sends DNS request to the authoritative CDN.</t>
<t>On receipt of the DNS request, the authoritative CDN redirects
the request to the Downstream CDN.</t>
<t>End user sends DNS request to the Downstream CDN.</t>
<t>On receipt of the DNS request, the Downstream CDN responds with
IP address of one of its Surrogates.</t>
<t>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</t>
<t>If the validation is negative, the Downstream CDN rejects the
request and sends an error code (e.g. 403) in the HTTP
response.</t>
<t>If the validation is positive, the Downstream CDN serves the
request and delivers the content.</t>
<t>At a later time, Downstream CDN reports logging events that
includes URI signing information.</t>
</list></t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>[Editor's note: (Is there a need to) register default value for URI
Signing Package Attribute URI query string parameter name (i.e.
URISigningPackage) to be used for URI Signing? Need anything from
IANA?]</t>
<t>[Editor's note: To do: Convert to proper IANA Registry format]</t>
<t>This document requests IANA to create three new URI Signing
registries for the Information Elements and their defined values to be
used for URI Signing.</t>
<t>The following Enforcement Information Element names are
allocated:<list style="symbols">
<t>ET (Expiry time)</t>
<t>CIP (Client IP address)</t>
</list></t>
<t>The following Signature Computation Information Element names are
allocated:<list style="symbols">
<t>VER (Version): 1 (Base)</t>
<t>KID (Key ID)</t>
<t>KID_NUM (Numerical Key ID)</t>
<t>HF (Hash Function): "SHA-256"</t>
<t>DSA (Digital Signature Algorithm): "EC-DSA"</t>
</list></t>
<t>The following URI Signature Information Element names are
allocated:<list style="symbols">
<t>MD (Message Digest for Symmetric Key)</t>
<t>DS (Digital Signature for Asymmetric Keys)</t>
</list></t>
<t>The IANA is requested to allocate a new entry to the CDNI Logging
Field Names Registry as specified in <xref
target="I-D.ietf-cdni-logging">CDNI Logging Interface</xref> in
accordance to the "Specification Required" policy <xref
target="RFC5226"/><list style="symbols">
<t>s-url-signing</t>
<t>s-url-signing-deny-reason</t>
</list></t>
<t>The IANA is requested to allocate a new entry to the "CDNI
GenericMetadata Types" Registry as specified in <xref
target="I-D.ietf-cdni-metadata">CDNI Metadata Interface</xref> in
accordance to the "Specification Required" policy <xref
target="RFC5226"/>:</t>
<texttable>
<ttcol align="left">Type name</ttcol>
<ttcol align="left">Specification</ttcol>
<ttcol align="left">Version</ttcol>
<ttcol align="left">MTE</ttcol>
<ttcol align="left">STR</ttcol>
<c>UriSigning</c>
<c>RFCthis</c>
<c>1</c>
<c>true</c>
<c>true</c>
</texttable>
<t>The IANA is also requested to allocate a new MIME type under the IANA
MIME Media Type registry for the UriSigning metadata object:<list
style="empty">
<t>application/cdni.UriSigning.v1</t>
</list></t>
</section>
<section anchor="security" title="Security Considerations">
<t>This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of interconnected CDNs
(CDNI). The primary goal of URI Signing is to make sure that only
authorized UAs are able to access the content, with a Content Service
Provider (CSP) being able to authorize every individual request. It
should be noted that URI Signing is not a content protection scheme; if
a CSP wants to protect the content itself, other mechanisms, such as
DRM, are more appropriate.</t>
<t>In general, it holds that the level of protection against
illegitimate access can be increased by including more Enforcement
Information Elements in the URI. The current version of this document
includes elements for enforcing Client IP Address and Expiration Time,
however this list can be extended with other, more complex, attributes
that are able to provide some form of protection against some of the
vulnerabilities highlighted below.</t>
<t>That said, there are a number of aspects that limit the level of
security offered by URI signing and that anybody implementing URI
signing should be aware of.</t>
<t><list>
<t>Replay attacks: Any (valid) Signed URI can be used to perform
replay attacks. The vulnerability to replay attacks can be reduced
by picking a relatively short window for the Expiration Time
attribute, although this is limited by the fact that any HTTP-based
request needs a window of at least a couple of seconds to prevent
any sudden network issues from preventing legitimate UAs access to
the content. One way to reduce exposure to replay attacks is to
include in the URI a unique one-time access ID. Whenever the
Downstream CDN receives a request with a given unique access ID, it
adds that access ID to the list of 'used' IDs. In the case an
illegitimate UA tries to use the same URI through a replay attack,
the Downstream CDN can deny the request based on the already-used
access ID.</t>
<t>Illegitimate client behind a NAT: In cases where there are
multiple users behind the same NAT, all users will have the same IP
address from the point of view of the Downstream CDN. This results
in the Downstream CDN not being able to distinguish between the
different users based on Client IP Address and illegitimate users
being able to access the content. One way to reduce exposure to this
kind of attack is to not only check for Client IP but also for other
attributes that can be found in the HTTP headers.</t>
</list></t>
<t>The shared key between CSP and Authoritative CDN may be distributed
to Downstream CDNs - including cascaded CDNs. Since this key can be used
to legitimately sign a URL for content access authorization, it's important to know the implications of a compromised shared key.</t>
<t>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.</t>
</section>
<section title="Privacy">
<t>The privacy protection concerns described in <xref
target="I-D.ietf-cdni-logging">CDNI Logging Interface</xref> apply when
the client's IP address (CIP attribute) is embedded in the Signed URI.
This means that, when anonymization is enabled, the value of the URI
Signing Package Attribute MUST be removed from the logging record.</t>
</section>
<section title="Acknowledgements">
<t>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 and
Leif Hedstrom. In addition, Matt Caulfield provided content for the CDNI
Metadata Interface section.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6707'?>
<?rfc include='reference.RFC.5226'?>
<?rfc include='reference.I-D.ietf-cdni-logging'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3986'?>
<?rfc include='reference.RFC.3174'?>
<?rfc include='reference.RFC.7336'?>
<?rfc include='reference.RFC.7337'?>
<?rfc include='reference.I-D.ietf-cdni-metadata'?>
<?rfc include='reference.I-D.ietf-cdni-redirection'?>
<?rfc include='reference.RFC.5952'?>
<?rfc include='reference.RFC.4648'?>
<?rfc include='reference.RFC.2104'?>
<?rfc include='reference.RFC.6983'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:26:23 |