One document matched: draft-ietf-cdni-uri-signing-10.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-10" ipr="trust200902">
<front>
<title abbrev="CDNI URI Signing">URI Signing for CDN Interconnection
(CDNI)</title>
<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="Kent Leung" initials="K" surname="Leung">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>3625 Cisco Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>United States</country>
</postal>
<phone>+1 408 526 5030</phone>
<email>kleung@cisco.com</email>
</address>
</author>
<author fullname="Phil Sorber" initials="P" surname="Sorber">
<organization>Comcast Cable Communications</organization>
<address>
<postal>
<street>1401 Wynkoop Street, Suite 300</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>United States</country>
</postal>
<phone>+1 720 502 3785</phone>
<email>phillip_sorber@comcast.com</email>
</address>
</author>
<author fullname="Matthew Miller" initials="M. "
surname="Miller">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>United States</country>
</postal>
<email>mamille2@cisco.com</email>
</address>
</author>
<date day="" month="" year=""/>
<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
method as a <xref target="RFC7519">JSON Web Token (JWT)</xref> profile.</t>
<t>The proposed URI signing method specifies the information needed to
be included in the URI to transmit the signed JWT as well as the claims needed
by the signed JWT to authorize a UA. The
mechanism described can be used both in CDNI and single CDN
scenarios.</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 redirection between
interconnected CDNs (CDNI) and between a Content Service Provider (CSP)
and a CDN. The primary goal of URI Signing is to make sure that only
authorized User Agents (UAs) are able to access the content, with a CSP
being able to authorize every individual request. It should be noted
that URI Signing is not a content protection scheme; if a CSP wants to
protect the content itself, other mechanisms, such as DRM, are more
appropriate. In addition to access control, URI Signing also has
benefits in reducing the impact of denial-of-service attacks.</t>
<t>The overall problem space for CDN Interconnection (CDNI) is described
in <xref target="RFC6707">CDNI Problem Statement</xref>. This
document, along with the <xref target="RFC7337">CDNI Requirements</xref>
document and the <xref target="RFC7336">CDNI Framework</xref>, describes the need
for interconnected CDNs to be able to implement an access control
mechanism that enforces the CSP's distribution policy.</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 method of signing URIs that allows Surrogates in
interconnected CDNs to enforce a per-request authorization performed by
the CSP. Splitting the role of performing per-request authorization by
the CSP and the role of validating this authorization by the CDN allows
any arbitrary distribution policy to be enforced across CDNs without the
need of CDNs to have any awareness of the actual CSP distribution
policy.</t>
<t>The representation of this method is a Signed JSON Web Token (JWT) <xref target="RFC7519"/>.</t>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
<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="RFC7519">JSON Web Token (JWT)</xref>.</t>
<t>In addition, the following terms are used throughout this
document:</t>
<t><list style="symbols">
<t>Signed URI: A URI that contains a signed JWT for itself.</t>
<t>Target CDN URI: URI created by the CSP to direct UA
towards the Upstream CDN (uCDN). The Target CDN URI can be signed by the
CSP and verified by the uCDN.</t>
<t>Redirection URI: URI created by the uCDN to redirect UA
towards the Downstream CDN (dCDN). The Redirection URI can be signed by
the uCDN and verified by the dCDN. In a cascaded
CDNI scenario, there can be more than one Redirection URI.</t>
</list></t>
</section>
<section anchor="background"
title="Background and overview on URI Signing ">
<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
claims in the form of a signed JWT in the URI before redirecting a UA to the CDN. Using these
attributes, it is possible for a CDN to check an incoming content
request to see whether it was authorized by the CSP (e.g., based on the
UA's IP address or a time window). To prevent the UA from altering the claims
a signed JWT is REQUIRED.</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 signed JWT which is generated by the
CSP using a shared secret or private key. Once the UA receives the
response with the Signed URI, it sends a new HTTP request using the
Signed URI to the CDN (#3). Upon receiving the request, the CDN
checks to see if the Signed URI is authentic by verifying the signed JWT.
If applicable, it checks whether the IP address of the HTTP
request matches that in the Signed URI and if the time window is still
valid. After these claims 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>
--------
/ \
| 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 uCDN and the
dCDN. In step #3, UA may send an HTTP request or a DNS request.
Depending on whether HTTP-based or DNS-based request routing is used,
the uCDN responds by directing the UA towards the
dCDN using either a Redirection URI (which is a Signed URI generated by
the uCDN) or a DNS reply, respectively (#4). Once the UA
receives the response, it sends the Redirection URI/Target CDN URI to
the dCDN (#5). The received URI is validated by the
dCDN 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>
+-------------------------+
|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, uCDN, and
dCDN have direct implications for URI Signing. In the case shown in
Figure 2, the CDN that the CSP has a trust relationship with is the
uCDN. The delivery of the content may be delegated to the
dCDN, which has a relationship with the uCDN 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 dCDN directly. In
the case where the dCDN does not have a trust relationship
with the CSP, this means that either an asymmetric public/private key
method needs to be used for computing the signed JWT (because the CSP and
dCDN are not able to exchange symmetric shared secret keys), or
the CSP needs
to allow the uCDN to redistribute shared keys
to a subset of their dCDNs .</t>
<t>For HTTP-based request routing, the Signed URI (i.e., Target CDN
URI) provided by the CSP reaches the uCDN. After this URI has
been verified to be correct by the uCDN, the uCDN
creates and signs a new Redirection URI to redirect the UA to the
dCDN. Since this new URI also has a new signed JWT, this
new signature can be based around the trust relationship between the
uCDN and dCDN, and the relationship between the
dCDN and CSP is not relevant. Given the fact that such a
relationship between uCDN and dCDN always exists,
both asymmetric public/private keys and symmetric shared secret keys
can be used for URI Signing with HTTP-based request routing. Note that the signed Redirection URI MUST
maintain the same, or higher, level of security as the original Signed
URI.</t>
</section>
<section title="URI Signing in a non-CDNI context">
<t>While the URI signing method defined in this document was primarily
created for the purpose of allowing URI Signing in CDNI scenarios,
e.g., between a uCDN and a dCDN or between a CSP and a dCDN, there is
nothing in the defined URI Signing method that precludes it from being
used in a non-CDNI context. As such, the described mechanism could be
used in a single-CDN scenario such as shown in <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="jwt_profile" title="JWT Format and Processing Requirements">
<t>The concept behind URI Signing is based on embedding a signed <xref target="RFC7519">JSON Web Token (JWT)
</xref> in the Target
CDN URI/Redirection URI. The signed JWT contains a number of claims that can be validated to ensure the
UA has legitimate access to the content.</t>
<t>In addition, this document specifies the following URI
attribute:</t>
<t>
<list style="symbols">
<t>URI Signing Package (URISigningPackage): The URI attribute that
encapsulates all the URI Signing claims in a signed JWT encoded
format. This attribute is exposed in the Signed URI as a URI
query parameter or as a URL path parameter.</t>
</list>
</t>
<t>The parameter name of the URI Signing Package Attribute is
defined in the CDNI Metadata. If the CDNI Metadata interface
is not used, or does not include a parameter name for the URI Signing
Package Attribute, the parameter name can be set by configuration (out of
scope of this document).</t>
<section anchor="jwt_claims" title="JWT Claims">
<t>This section identifies the set of claims that can be
used to enforce the CSP distribution policy. New claims can be introduced in the future to extend the
distribution policy capabilities.</t>
<t>In order to provide distribution policy flexibility,
the exact subset of claims used in a given signed JWT is a runtime decision.
Claim requirements are defined in the
CDNI Metadata. If the CDNI Metadata interface is not used, or
does not include claim requirements, the claim requirements
can be set by configuration (out of scope of this document).</t>
<t>The following claims (where the "JSON Web Token Claims" registry
claim name is specified in parenthesis below) are used to enforce the
distribution policies. All of the listed claims are mandatory
to implement in a URI Signing implementation, but are not
mandatory to use in a given signed JWT. (The "optional" and
"mandatory" identifiers in square brackets refer to whether or
not a given claim MUST be present in a URI Signing JWT.)
A CDN MUST be able to parse and process all of the claims
listed below. If the signed JWT contains any claims which the
CDN does not understand (i.e., is unable to parse and
process), the CDN MUST reject the request.</t>
<t><list style="symbols">
<t>Issuer (iss) [optional] - The semantics in
<xref target="RFC7519"/> Section 4.1.1 MUST be followed. This
claim MAY be used to validate authorization of the issuer of a
signed JWT and also MAY be used to confirm that the indicated key
was provided by said issuer. If the CDN validating the
signed JWT does not support Issuer validation, or if the
Issuer in the signed JWT does not match the list of known
acceptable Issuers, the CDN MUST reject the request. If the
received signed JWT contains an Issuer claim, then any
JWT subsequently generated for CDNI redirection MUST also contain an Issuer
claim, and the Issuer value MUST be updated to identify the
redirecting CDN. If the received signed JWT does not
contain an Issuer claim, an Issuer claim MAY be added to
a signed JWT generated for CDNI redirection.</t>
<t>URI Container (sub) [mandatory] - The semantics in <xref target="RFC7519"/> Section 4.1.2 MUST be followed.
Container for holding the URI representation before the URI Signing Package is added. This representation can take one of several forms detailed in <xref target="uri_container_forms"/>. If the
URI pattern/regex in the signed JWT does not match the URI of
the content request, the CDN validating the
signed JWT MUST reject the request. When redirecting a URI, the CDN
generating the new signed JWT MAY change the URI Container
to comport with the URI being used in the redirection.</t>
<t>Client IP (aud) [optional] - The semantics in <xref target="RFC7519"/> Section 4.1.3 MUST be followed.
IP address, or IP prefix, for
which the Signed URI is valid. This is represented in CIDR
notation, with dotted decimal format for IPv4 or canonical text
representation for <xref target="RFC5952">IPv6 addresses</xref>.
The request is rejected if sourced from a client outside of the
specified IP range. Since the client IP is considered
personally identifiable information this field
MUST be a JSON Web Encryption (<xref target="RFC7516">JWE</xref>)
Object in compact serialization form. If the CDN validating the
signed JWT does not support Client IP validation, or if the
Client IP in the signed JWT does not match the source IP
address in the content request request, the CDN MUST
reject the request.
If the received signed JWT contains a Client IP claim, then any
JWT subsequently generated for CDNI redirection MUST also
contain a Client IP claim, and the Client IP value MUST be
the same as in the received signed JWT. A signed JWT
generated for CDNI redirection MUST NOT add a Client IP
claim if no Client IP claim existed in the received
signed JWT.</t>
<t>Expiry Time (exp) [optional] - The semantics in <xref target="RFC7519"/> Section 4.1.4 MUST be followed, though URI Signing implementations MUST not allow for any time synchronization "leeway".
Note: The time on the entities that generate and
validate the signed URI SHOULD be in sync. In the CDNI case, this
means that CSP, uCDN and dCDN servers need to be
time-synchronized. It is RECOMMENDED to use NTP for time synchronization.
If the CDN validating the signed JWT does not support
Expiry Time validation, or if the Expiry Time in the
signed JWT corresponds to a time earlier than the time of
the content request request, the CDN MUST reject the
request.
If the received signed JWT contains a Expiry Time claim, then any
JWT subsequently generated for CDNI redirection MUST also
contain an Expiry Time claim, and the Expiry Time value MUST be
the same as in the received signed JWT. A signed JWT
generated for CDNI redirection MUST NOT add an Expiry Time
claim if no Expiry Time claim existed in the received
signed JWT.</t>
<t>Not Before (nbf) [optional] - The semantics in <xref target="RFC7519"/> Section 4.1.5 MUST be followed, though URI Signing implementations MUST not allow for any time synchronization "leeway".
Note: The time on the entities that generate and
validate the signed URI SHOULD be in sync. In the CDNI case, this
means that the CSP, uCDN, and dCDN servers need to be
time-synchronized. It is RECOMMENDED to use NTP for time synchronization.
If the CDN validating the signed JWT does not support
Not Before time validation, or if the Not Before time in the
signed JWT corresponds to a time later than the time of
the content request request, the CDN MUST reject the
request.
If the received signed JWT contains a Not Before time claim, then any
JWT subsequently generated for CDNI redirection MUST also
contain a Not Before time claim, and the Not Before time value MUST be
the same as in the received signed JWT. A signed JWT
generated for CDNI redirection MUST NOT add a Not Before time
claim if no Not Before time claim existed in the received
signed JWT.</t>
<t>Issued At (iat) [optional] - The semantics in <xref target="RFC7519"/> Section 4.1.6 MUST be followed.
Note: The time on the entities that generate and
validate the signed URI SHOULD be in sync. In the CDNI case, this
means that CSP, uCDN, and dCDN servers need to be
time-synchronized. It is RECOMMENDED to use NTP for time synchronization.
If the received signed JWT contains an Issued At claim, then any
JWT subsequently generated for CDNI redirection MUST also contain an Issued At
claim, and the Issuer value MUST be updated to identify the
time the new JWT was generated. If the received signed
JWT does not contain an Issued At claim, an Issued At
claim MAY be added to a signed JWT generated for CDNI redirection.</t>
<t>Nonce (jti) [optional] - The semantics in <xref target="RFC7519"/> Section 4.1.7 MUST be followed.
Can be used to prevent replay attacks if the CDN stores a
list of all previously used Nonce values, and validates
that the Nonce in the current JWT has never been used
before. If the signed JWT contains a Nonce claim and the
CDN validating the signed JWT does not support Nonce
storage, then the CDN MUST reject the request.
If the received signed JWT contains a Nonce claim, then any
JWT subsequently generated for CDNI redirection MUST also
contain a Nonce claim, and the Nonce value MUST be the
same as in the received signed JWT.
If the received signed JWT does not contain a
Nonce claim, a Nonce claim MAY be added to a signed JWT
generated for CDNI redirection.</t>
</list></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 anchor="uri_container_forms" title="URI Container Forms">
<t>The URI Container (sub) claim takes one of the following forms. More forms may be added in the future to extend the capabilities.</t>
<section anchor="uri_container_forms_uri" title="URI Simple Container (uri:)">
<t>When prefixed with 'uri:', the string following 'uri:' is the URI that MUST be matched with a simple string match to the requested URI.</t>
</section>
<section anchor="uri_container_forms_ptn" title="URI Pattern Container (uri-pattern:)">
<t>Prefixed with 'uri-pattern:', this string contains one or more URI Patterns that describes for which content the Signed URI is valid. Each URI Pattern contains an expression to match against the requested URI, to check whether the requested content is allowed to be served. Multiple URI Patterns may be concatenated in a single URI Pattern by separating them with a semi-colon (';') character. Each URI Pattern follows the <xref target="RFC3986"/> URI format, including the '://' that delimits the URI scheme from the hierarchy part. The pattern may include the special literals:</t>
<t>
<list style="sybmols">
<t>';' - separates individual patterns when the string contains multiple URI patterns.</t>
<t>'*' - matches any sequence of characters, including the empty string.</t>
<t>'?' - matches exactly one character.</t>
<t>'$' - used to escape the special literals; MUST be followed by exactly one of ';', '*', '?', or '$'.</t>
</list>
</t>
<t>The following is an example of a valid URI Pattern:</t>
<t>
<figure>
<artwork>
*://*/folder/content-83112371/quality_*/segment????.mp4
</artwork>
</figure>
</t>
<t>An example of two concatenated URI Patterns is the following (whitespace is inserted after the ';' for readability and should not be present in the actual representation):</t>
<t>
<figure>
<artwork>
http://*/folder/content-83112371/manifest/*.xml;
http://*/folder/content-83112371/quality_*/segment????.mp4
</artwork>
</figure>
</t>
<t>In order to increase the performance of string parsing the URI Pattern, implementations can check often-used URI Pattern prefixes to quickly check whether certain URI components can be ignored. For example, URI Pattern prefixes '*://*/' or '*://*:*' will be used in case the scheme and authority components of the URI are ignored for purposes of pattern enforcement.</t>
</section>
<section anchor="uri_container_forms_regex" title="URI Regular Expression Container (uri-regex:)">
<t>Prefixed with 'uri-regex:', this string is any <xref target="PCRE839">PCRE</xref> compatible regular expression used to match against the requested URI.</t>
<t>Note: Because '\' has special meaning in JSON <xref target="RFC7159"/> as the escape character within JSON strings, the regular expression character '\' MUST be escaped as '\\'.</t>
<t>An example of a 'uri-regex:' is the following:</t>
<t>
<figure>
<artwork>
.*\\://.*/folder/content-83112371/quality_.*/segment.{3}\\.mp4
</artwork>
</figure>
</t>
<t>Note: Due to computational complexity of executing arbitrary regular expressions, it is RECOMMENDED to only execute after validating the JWT to ensure its authenticity.</t>
</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 dCDN that supports URI Signing needs to be
able to advertise this capability to the uCDN. The uCDN
needs to select a dCDN based on such capability when the CSP
requires access control to enforce its distribution policy via URI
Signing. Also, the uCDN needs to be able to distribute via the
CDNI Metadata interface the information necessary to allow the
dCDN 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 CDNI Request Routing: Footprint and Capabilities
Semantics document <xref target="I-D.ietf-cdni-footprint-capabilities-semantics"/> defines support for
advertising CDNI Metadata capabilities, via CDNI Payload
Type. The CDNI Payload Type registered in <xref target="sec.IANA.payload"/>
can be used for capability advertisement.</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 uCDN signs the URI
provided by the dCDN. URI Signing therefore has has no impact
on this interface.</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, a new
CDNI metadata object is specified.</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 dCDN to ensure
that the URI must be signed and validated before
delivering content. Otherwise, the dCDN does not perform
validation, regardless of whether or not the URI is signed.</t>
<t>Type: Boolean</t>
<t>Mandatory-to-Specify: No. The default is true.</t>
</list></t>
<t>Property: issuers<list style="empty">
<t>Description: A list of valid Issuers against which
the Issuer claim in the signed JWT may be validated.</t>
<t>Type: Array of Strings</t>
<t>Mandatory-to-Specify: No. The default is an empty
list. An empty list means that any Issuer is acceptable.</t>
</list></t>
<t>Property: package-attribute<list style="empty">
<t>Description: The name to use for the URI Signing
Package.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: No. Default is
"URISigningPackage".</t>
</list></t>
</list></t>
<t>The following is an example of a URI Signing metadata payload with all default values:</t>
<figure>
<artwork><![CDATA[
{
"generic-metadata-type": "MI.UriSigning"
"generic-metadata-value": {}
}
]]>
</artwork>
</figure>
<t>The following is an example of a URI Signing metadata payload with explicit values:</t>
<figure>
<artwork><![CDATA[
{
"generic-metadata-type": "MI.UriSigning"
"generic-metadata-value":
{
"enforce": true,
"issuers": ["csp", "ucdn1", "ucdn2"],
"package-attribute": "usp"
}
}
]]>
</artwork>
</figure>
</section>
<section anchor="logging" title="CDNI Logging Interface">
<t>For URI Signing, the dCDN 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>,
using the new "cdni_http_request_v2" record-type registered in
<xref target="sec.IANA.record_type.cdni_http_request_v2"/>.</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>"000" : no signed JWT validation performed</t>
<t>"200" : signed JWT validation performed and
validated</t>
<t>"400" : signed JWT validation performed and rejected
because of incorrect signature</t>
<t>"401" : signed JWT validation performed and rejected
because of Expiration Time enforcement</t>
<t>"402" : signed JWT validation performed and rejected
because of Client IP enforcement</t>
<t>"403" : signed JWT validation performed and rejected
because of URI Pattern enforcement</t>
<t>"404" : signed JWT validation performed and rejected
because of Issuer enforcement</t>
<t>"405" : signed JWT validation performed and rejected
because of Not Before enforcement</t>
<t>"500" : unable to perform signed JWT validation
because of malformed URI</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: a string for providing further information in
case the signed JWT was rejected, e.g., for debugging
purposes.</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="RFC7519">JSON Web Token (JWT)</xref> defines a
compact, URL-safe means of representing
claims to be transferred between two parties. The claims in a signed JWT
are encoded as a JSON object that is used as the payload of a JSON
Web Signature (JWS) structure or as the plaintext of a JSON Web
Encryption (JWE) structure, enabling the claims to be digitally
signed or integrity protected with a Message Authentication Code
(MAC) and/or encrypted.</t>
<section anchor="http" title="HTTP Redirection">
<t>For HTTP-based request routing, a set of
information that is unique to a given end user content request
is included in a signed JWT, using
key information that is specific to a pair of adjacent CDNI hops (e.g.
between the CSP and the uCDN, between the
uCDN and a dCDN). This allows a CDNI hop to ascertain the
authenticity of a given request received from a previous CDNI hop.</t>
<t>The URI signing method described below is based on the following
steps (assuming HTTP redirection, iterative request routing, and a CDN
path with two CDNs). Note that uCDN and uCDN are
used exchangeably.</t>
<figure title="Figure 3: HTTP-based Request Routing with URI Signing">
<artwork>
End-User dCDN uCDN CSP
| | | |
| 1.CDNI FCI interface used to | |
| advertise URI Signing capability| |
| |------------------->| |
| | | |
| 2.Provides information to validate signed JWT |
| | |<-------------------|
| | | |
| 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| |
| |<-------------------| |
|4.Authorization request | |
|------------------------------------------------------------->|
| | | [Apply distribution
| | | policy] |
| | | |
| | (ALT: Authorization decision)
|5.Request is denied | | <Negative> |
|<-------------------------------------------------------------|
| | | |
|6.CSP provides signed URI | <Positive> |
|<-------------------------------------------------------------|
| | | |
|7.Content request | | |
|---------------------------------------->| [Validate URI |
| | | signature] |
| | | |
| | (ALT: Validation result) |
|8.Request is denied | <Negative>| |
|<----------------------------------------| |
| | | |
|9.Re-sign URI and redirect to <Positive>| |
| dCDN (newly signed URI) | |
|<----------------------------------------| |
| | | |
|10.Content request | | |
|------------------->| [Validate URI | |
| | signature] | |
| | | |
| (ALT: Validation result) | |
|11.Request is denied| <Negative> | |
|<-------------------| | |
| | | |
|12.Content delivery | <Positive> | |
|<-------------------| | |
: : : :
: (Later in time) : : :
|13.CDNI Logging interface to include URI Signing information |
| |------------------->| |</artwork>
</figure>
<t><list style="numbers">
<t>Using the CDNI Footprint & Capabilities Advertisement
interface, the dCDN advertises its capabilities
including URI Signing support to the uCDN.</t>
<t>CSP provides to the uCDN the information needed to
validate signed JWTs from that CSP. For example, this
information may include a key
value.</t>
<t>Using the CDNI Metadata interface, the uCDN
communicates to a dCDN the information needed to
validate signed JWTs from the uCDN for the given
CSP. For example, this information may include the URI query
string parameter name for the URI Signing Package Attribute.</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
uCDN validates the signed JWT in the URI using the
information provided by the CSP.</t>
<t>If the validation is negative, the uCDN rejects
the request.</t>
<t>If the validation is positive, the uCDN computes a
Signed URI that is based on unique parameters of that request and
provides to the end user as the URI to use to further request the
content from the dCDN.</t>
<t>On receipt of the corresponding content request, the
dCDN validates the signed JWT in the Signed URI using the
information provided by the uCDN in the CDNI
Metadata.</t>
<t>If the validation is negative, the dCDN rejects the
request and sends an error code (e.g., 403 Forbidden) in the HTTP
response.</t>
<t>If the validation is positive, the dCDN serves the
request and delivers the content.</t>
<t>At a later time, dCDN 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 and
asymmetric keys because the key information only needs 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 uCDN must
agree on a trust model appropriate to the security requirements of the
CSP's particular content. Use of asymmetric public/private keys allows
for unlimited distribution of the public key to dCDNs.
However, if a shared secret key is preferred, then the CSP may want to
restrict the distribution of the key to a (possibly empty) subset of
trusted dCDNs. Authorized Delivery CDNs need to obtain the
key information to validate the Signed URI.</t>
<t>The URI signing method described below is based on the following
steps (assuming iterative DNS request routing and a CDN path with two
CDNs).</t>
<figure title="Figure 4: DNS-based Request Routing with URI Signing">
<artwork>
End-User dCDN uCDN CSP
| | | |
| 1.CDNI FCI interface used to | |
| advertise URI Signing capability| |
| |------------------->| |
| | | |
| 2.Provides information to validate signed JWT |
| | |<-------------------|
| 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| |
| |<-------------------| |
|4.Authorization request | |
|------------------------------------------------------------->|
| | | [Apply distribution
| | | policy] |
| | | |
| | (ALT: Authorization decision)
|5.Request is denied | | <Negative> |
|<-------------------------------------------------------------|
| | | |
|6.Provides signed URI | <Positive> |
|<-------------------------------------------------------------|
| | | |
|7.DNS request | | |
|---------------------------------------->| |
| | | |
|8.Redirect DNS to dCDN | |
|<----------------------------------------| |
| | | |
|9.DNS request | | |
|------------------->| | |
| | | |
|10.IP address of Surrogate | |
|<-------------------| | |
| | | |
|11.Content request | | |
|------------------->| [Validate URI | |
| | signature] | |
| | | |
| (ALT: Validation result) | |
|12.Request is denied| <Negative> | |
|<-------------------| | |
| | | |
|13.Content delivery | <Positive> | |
|<-------------------| | |
: : : :
: (Later in time) : : :
|14.CDNI Logging interface to report URI Signing information |
| |------------------->| |
</artwork>
</figure>
<t><list style="numbers">
<t>Using the CDNI Footprint & Capabilities Advertisement
interface, the dCDN advertises its capabilities
including URI Signing support to the uCDN.</t>
<t>CSP provides to the uCDN the information needed to
validate cryptographic signatures from that CSP. For example, this
information may include a key.</t>
<t>Using the CDNI Metadata interface, the uCDN
communicates to a dCDN the information needed to
validate cryptographic signatures from the CSP (e.g., the URI query
string parameter name for the URI Signing Package Attribute). In
the case of symmetric key, the uCDN checks if the
dCDN 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 uCDN.</t>
<t>On receipt of the DNS request, the uCDN redirects
the request to the dCDN.</t>
<t>End user sends DNS request to the dCDN.</t>
<t>On receipt of the DNS request, the dCDN responds with
IP address of one of its Surrogates.</t>
<t>On receipt of the corresponding content request, the
dCDN validates the cryptographic signature in the URI using the
information provided by the uCDN in the CDNI
Metadata.</t>
<t>If the validation is negative, the dCDN rejects the
request and sends an error code (e.g., 403) in the HTTP
response.</t>
<t>If the validation is positive, the dCDN serves the
request and delivers the content.</t>
<t>At a later time, dCDN 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 needs to be distributed across
multiple, possibly non-adjacent, CDNI hops is the public key, which
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 title="HTTP Adaptive Streaming">
<t>The authors note that in order to perform URI signing for individual
content segments of HTTP Adaptive Bitrate content, specific URI signing
mechanisms are needed. Such mechanisms are currently out-of-scope of
this document. More details on this topic is covered in <xref
target="RFC6983">Models for HTTP-Adaptive-Streaming-Aware CDNI</xref>. In addition,
<xref target="I-D.brandenburg-cdni-uri-signing-for-has"/> provides an extension to the algorithm defined in this document that deals specifically with URI signing of segmented content.</t>
</section>
<section anchor="sec.IANA" title="IANA Considerations">
<section anchor="sec.IANA.payload" title="CDNI Payload Type">
<t>This document requests the registration of the following CDNI
Payload Type under the IANA "CDNI Payload Type" registry:</t>
<texttable>
<ttcol align="left">Payload Type</ttcol>
<ttcol align="left">Specification</ttcol>
<c>MI.UriSigning</c>
<c>RFCthis</c>
</texttable>
<t>[RFC Editor: Please replace RFCthis with the published RFC
number for this document.]</t>
<section anchor="sec.IANA.payload.UriSigning" title="CDNI UriSigning Payload Type">
<t>Purpose: The purpose of this payload type is to distinguish
UriSigning MI objects (and any associated capability advertisement).</t>
<t>Interface: MI/FCI</t>
<t>Encoding: see <xref target="metadata"/></t>
</section>
</section>
<section anchor="sec.IANA.logging_record" title="CDNI Logging Record Type">
<t>This document requests the registration of the following CDNI
Logging record-type under the IANA "CDNI Logging record-types" registry:</t>
<texttable>
<ttcol align="left">record-types</ttcol>
<ttcol align="left">Reference</ttcol>
<ttcol align="left">Description</ttcol>
<c>cdni_http_request_v2</c>
<c>RFCthis</c>
<c>Extension to CDNI Logging Record version 1 for content
delivery using HTTP, to include URI Signing logging fields</c>
</texttable>
<t>[RFC Editor: Please replace RFCthis with the published RFC
number for this document.]</t>
<section anchor="sec.IANA.record_type.cdni_http_request_v2"
title="CDNI Logging Record Version 2 for HTTP">
<t>The "cdni_http_request_v2" record-type supports all of
the fields supported by the "cdni_http_request_v1"
record-type <xref target="I-D.ietf-cdni-logging"/> plus the
two additional fields "s-uri-signing" and
"s-uri-signing-deny-reason", registered by this document in
<xref target="sec.IANA.fields"/>. The name,
format, field value, and occurence information for the two
new fields can be found in
<xref target="logging"/> of this
document.</t>
</section>
</section>
<section anchor="sec.IANA.fields" title="CDNI Logging Field Names">
<t>This document requests the registration of the following CDNI
Logging fields under the IANA "CDNI Logging Field Names" registry:</t>
<texttable>
<ttcol align="left">Field Name</ttcol>
<ttcol align="left">Reference</ttcol>
<c>s-uri-signing</c>
<c>RFCthis</c>
<c>s-uri-signing-deny-reason</c>
<c>RFCthis</c>
</texttable>
<t>[RFC Editor: Please replace RFCthis with the published RFC
number for this document.]</t>
</section>
</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
CDNI. The primary goal of URI Signing is to make sure that only
authorized UAs are able to access the content, with a
CSP being able to authorize every individual request. It
should be noted that URI Signing is not a content protection scheme; if
a CSP wants to protect the content itself, other mechanisms, such as
DRM, are more appropriate.</t>
<t>In general, it holds that the level of protection against
illegitimate access can be increased by including more claims
in the signed JWT. The current version of this document
includes claims for enforcing Issuer, Client IP Address, Not Before time, and Expiration Time,
however this list can be extended with other, more complex, attributes
that are able to provide some form of protection against some of the
vulnerabilities highlighted below.</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: A (valid) Signed URI may be used to perform
replay attacks. The vulnerability to replay attacks can be reduced
by picking a relatively short window between the Not Before time and Expiration Time
attributes, although this is limited by the fact that any HTTP-based
request needs a window of at least a couple of seconds to prevent
a sudden network issues from preventing legitimate UAs access to
the content. One may also reduce exposure to replay attacks by
including a unique one-time access ID via the Nonce attribute (jti claim). Whenever the
dCDN receives a request with a given unique ID, it
adds that ID to the list of 'used' IDs. In the case an
illegitimate UA tries to use the same URI through a replay attack,
the dCDN can deny the request based on the already-used
access ID.</t>
<t>Illegitimate clients behind a NAT: In cases where there are
multiple users behind the same NAT, all users will have the same IP
address from the point of view of the dCDN. This results
in the dCDN not being able to distinguish between the
different users based on Client IP Address and illegitimate users
being able to access the content. One way to reduce exposure to this
kind of attack is to not only check for Client IP but also for other
attributes, e.g., attributes that can be found in HTTP headers.</t>
</list></t>
<t>The shared key between CSP and uCDN may be distributed
to dCDNs - including cascaded CDNs. Since this key can be used
to legitimately sign a URL for content access authorization, it is
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 (aud) is embedded in the Signed URI.
For this reason, the mechanism described in <xref
target="jwt_profile"/> encrypts the Client IP before
including it in the URI Signing Package (and thus the URL itself).</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,
Leif Hedstrom and Gancho Tenev. In addition, Matt Caulfield provided
content for the CDNI Metadata Interface section.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.6707'?>
<?rfc include='reference.I-D.ietf-cdni-logging'?>
<?rfc include='reference.RFC.7159'?>
<?rfc include='reference.RFC.7519'?>
<?rfc include='reference.RFC.7516'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3986'?>
<?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-footprint-capabilities-semantics'?>
<?rfc include='reference.I-D.ietf-cdni-redirection'?>
<?rfc include='reference.RFC.5952'?>
<?rfc include='reference.RFC.6983'?>
<?rfc include='reference.I-D.brandenburg-cdni-uri-signing-for-has'?>
<reference anchor="PCRE839" target="http://www.pcre.org/">
<front>
<title>Perl Compatible Regular Expressions</title>
<author surname="Hazel" initials="P"/>
<date day="17" month="June" year="2016"/>
</front>
<seriesInfo name="Version" value="8.39"/>
</reference>
</references>
<section title="Signed URI Package Example" anchor="sup_example">
<t>This section contains two examples of token usage: a simple example with only the required claims present, and a complex example which demonstrates the full JWT claims set, including an encrypted Client IP (aud).</t>
<t>Note: All of the examples have whitespace added to improve formatting and readability, but are not present in the generated content.</t>
<t>Both examples use the following signing key to generate the Signed URI Package:</t>
<figure><artwork><![CDATA[
{
"kty": "EC",
"kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0",
"use": "sig",
"crv": "P-256",
"x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8",
"y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA",
"d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M"
}
]]></artwork></figure>
<section title="Simple Example" anchor="simple_example">
<t>
This example is the simplest possible example containing
the only required field (sub).
</t>
<t>
The JWT Claim Set before signing:
</t>
<figure><artwork><![CDATA[
{
"sub": "uri:http://cdni.example/foo/bar/baz"
}
]]></artwork></figure>
<t>
The Signed JWT:
</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJzdWIiOiJ1cmk6aHR0cDovL2NkbmkuZXhhbXBsZ
S9mb28vYmFyL2JheiJ9.oC4yKwUchowx4KhMsI8MQ-Sq_1s3fC8NCi-IWcmNEE9MQz
EEQfurJ1su2Op_dtYuc_fG8NixSVubz3HWKM4Rsw
]]></artwork></figure>
</section>
<section title="Complex Example" anchor="complex_example">
<t>
This example uses all optional fields, including Client IP (aud)
which is encrpyted. This significantly increases the size of
the signed JWT token.
</t>
<t>
Shared key used for encrpyting the Client IP (aud):
</t>
<figure><artwork><![CDATA[
{
"kty": "oct",
"kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998",
"use": "enc",
"alg": "A128GCM",
"k": "4uFxxV7fhNmrtiah2d1fFg"
}
]]></artwork></figure>
<t>
JWE for client IP (aud) of [2001:db8::1/32]:
</t>
<figure><artwork><![CDATA[
eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhmdm9zN1F6Nj
g4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..Ewl05cq3jmUe1Bv1.CHif9
OMPmsMPgJ8tZgvD0A.R3I2C8nfppY2wBfc4xEPPQ
]]></artwork></figure>
<t>
The JWT Claim Set before signing:
</t>
<figure><artwork><![CDATA[
{
"aud": "eyJhbGciOiJkaXIiLCJraWQiOiJmLVdianhCQzNkUHVJM2QyNGtQMmhm
dm9zN1F6Njg4VVRpNmFCMGhOOTk4IiwiZW5jIjoiQTEyOEdDTSJ9..Ewl05cq3jmUe
1Bv1.CHif9OMPmsMPgJ8tZgvD0A.R3I2C8nfppY2wBfc4xEPPQ",
"exp": 1474243500,
"iat": 1474243200,
"iss": "Upstream CDN Inc",
"jti": "5DAafLhZAfhsbe",
"nbf": 1474243200,
"sub": "uri-regex:http://cdni\\.example/foo/bar/baz/[0-9]{3}\\.png"
}
]]></artwork></figure>
<t>
The Signed JWT:
</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJleUpoYkdjaU9pSmthWElpTENKcmFXU
WlPaUptTFZkaWFuaENRek5rVUhWSk0yUXlOR3RRTW1obWRtOXpOMUY2TmpnNFZWUnB
ObUZDTUdoT09UazRJaXdpWlc1aklqb2lRVEV5T0VkRFRTSjkuLkV3bDA1Y3Ezam1VZ
TFCdjEuQ0hpZjlPTVBtc01QZ0o4dFpndkQwQS5SM0kyQzhuZnBwWTJ3QmZjNHhFUFB
RIiwiZXhwIjoxNDc0MjQzNTAwLCJpYXQiOjE0NzQyNDMyMDAsImlzcyI6IlVwc3RyZ
WFtIENETiBJbmMiLCJqdGkiOiI1REFhZkxoWkFmaHNiZSIsIm5iZiI6MTQ3NDI0MzI
wMCwic3ViIjoidXJpLXJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL
2Jhei9bMC05XXszfVxcLnBuZyJ9.AtDNW7mwFIJPqsWAn9ojzj4imE-vTowR-FRzil
vnSQuQMz_u4sIspxe6RoXo_Ti8rVMgJ0jOdSvVnQUJZdfRUQ
]]></artwork></figure>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:26:51 |