URI Signing for Content Delivery Network Interconnection
(CDNI)TiledmediaAnna van Buerenplein 1Den Haag2595DAThe Netherlands+31 88 866 7000ray@tiledmedia.commail4kentl@gmail.comApple, Inc.1800 Wazee StreetSuite 410DenverCO80202United Statessorber@apple.comCDNIThis document describes how the concept of URI Signing supports the
content access control requirements of Content Delivery Network Interconnection (CDNI) and proposes a URI Signing
method as a JSON Web Token (JWT) profile.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 User Agent (UA). The
mechanism described can be used both in CDNI and single Content Delivery Network (CDN)
scenarios.This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of redirection between
cooperating CDNs and between a Content Service Provider (CSP)
and a CDN. 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 Digital Rights Management (DRM), are more
appropriate. In addition to access control, URI Signing also has
benefits in reducing the impact of denial-of-service attacks.The overall problem space for CDN Interconnection (CDNI) is described
in CDNI Problem Statement. This
document, along with the CDNI Requirements
document and the CDNI Framework, describes the need
for interconnected CDNs to be able to implement an access control
mechanism that enforces a CSP's distribution policies.Specifically, the CDNI Framework
states:The CSP may also trust the CDN operator to perform actions such as
delegating traffic to additional downstream CDNs, and to enforce per-request authorization performed by the CSP using
techniques such as URI Signing.In particular, the following requirement is listed in the CDNI Requirements:MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of
authorization checks and verification that are to be performed by the
Surrogate before delivery. For example, this could potentially
include the need to verify information (e.g., Expiry time, Client
IP address) required for access authorization.This document defines a method of signing URIs that allows Surrogates in
interconnected CDNs to enforce a per-request authorization initiated by
the CSP. Splitting the role of initiating per-request authorization by
the CSP and the role of verifying 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 specific CSP distribution
policies.The method is implemented using Signed JSON Web Tokens (JWTs) .The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.This document uses the terminology defined in the CDNI Problem Statement.This document also uses the terminology of the JSON Web Token (JWT).In addition, the following terms are used throughout this
document:Signed URI: A URI for which a signed JWT is provided.Target CDN URI: URI created by the CSP to direct a UA
towards the Upstream CDN (uCDN). The Target CDN URI can be signed by the
CSP and verified by the uCDN and possibly further Downstream CDNs (dCDNs).Redirection URI: URI created by the uCDN to redirect a UA
towards the 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.Signed Token Renewal: A series of signed JWTs that are used for subsequent
access to a set of related resources in a CDN, such as a set of HTTP
Adaptive Streaming files. Every time a signed JWT is used to
access a particular resource, a new signed JWT is sent along
with the resource that can be used to request the next resource
in the set. When generating a new signed JWT in Signed Token Renewal,
parameters are carried over from one signed JWT to the next.A CSP and CDN are assumed to have a trust relationship that enables
the CSP to authorize access to a content item, which is
realized in practice by including a set of claims in 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 JWT MUST be signed., 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. The signed URI always contains a signed JWT 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
authenticates the Signed URI by verifying the signed JWT.
If applicable, the CDN checks whether the source IP address of the HTTP
request matches the one in the Signed URI and/or if the time window is still
valid. After these claims are verified, the CDN delivers
the content (#4).Note: While using a symmetric shared key is supported, it is NOT RECOMMENDED.
See the Security Considerations section about the
limitations of shared keys.In a CDNI environment, as shown in below, URI Signing operates the same way in the
initial steps #1 and #2 but the later steps involve multiple CDNs
delivering the content. The main difference from the
single CDN case is a redirection step between the uCDN and the
dCDN. In step #3, the 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 (i.e., 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 verified by the
dCDN before delivering the content (#6). Note: The CDNI call flows are covered in Detailed URI Signing Operation.The trust relationships between CSP, uCDN, and
dCDN have direct implications for URI Signing. In the case shown in
, the CSP has a trust relationship with the
uCDN. The delivery of the content may be delegated to a
dCDN, which has a relationship with the uCDN but may
have no relationship with the CSP.In CDNI, there are two methods for request routing: DNS-based and
HTTP-based. For DNS-based request routing, the Signed URI (i.e., the 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.For HTTP-based request routing, the Signed URI (i.e., the Target CDN
URI) provided by the CSP reaches the uCDN. After this URI has
been verified by the uCDN, the uCDN
creates and signs a new Redirection URI, redirecting the UA to the
dCDN. Since this new URI can have a new signed JWT, the relationship between the
dCDN and CSP is not relevant. Because a
relationship between uCDN and dCDN always exists,
either asymmetric public/private keys or symmetric shared secret keys
can be used for URI Signing with HTTP-based request routing. Note that the signed Redirection URI MUST
maintain HTTPS as the scheme if it was present in the original and it MAY be upgraded from HTTP to HTTPS.Two types of keys can be used for URI Signing: asymmetric keys and
symmetric shared keys. Asymmetric keys are based on a public/private key pair
mechanism and always contain a private key known only 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 and the
verifying entity for verifying the Signed URI. Regardless of the type
of keys used, the verifying entity has to obtain the key in a manner that allows trust to
be placed in the assertions made using that key (either the
public or the symmetric key). There are very different requirements
(outside the scope of this document) for distributing asymmetric keys
and symmetric keys. Key distribution for symmetric keys requires
confidentiality to prevent third parties from getting access to the key,
since they 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 to sign URIs) and the corresponding private keys are kept
secret by the URI signer.Note: While using a symmetric shared key is supported, it is NOT RECOMMENDED.
See the Security Considerations section about the
limitations of shared keys.While the URI Signing method defined in this document was primarily
created for the purpose of allowing URI Signing in CDNI scenarios,
i.e., between a uCDN 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
in , for example
to allow a CSP that uses different CDNs to only have to implement a
single URI Signing mechanism.The concept behind URI Signing is based on embedding a signed JSON Web Token (JWT)
in an HTTP or HTTPS URI (see [RFC7230] Section 2.7). The signed JWT contains a number of
claims that can be verified to ensure the UA has legitimate access to the content.This document specifies the following attribute for embedding a signed JWT in a Target CDN URI or Redirection URI: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 path-style parameter
or a form-style parameter.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).The URI Signing Package will be found by parsing any path-style parameters and
form-style parameters looking for a key name matching the URI Signing Package Attribute.
Both parameter styles MUST be supported to allow flexibility of operation.
The first matching parameter SHOULD be taken to provide the signed JWT, though providing
more than one matching key is undefined behavior. Path-style parameters generated in the
form indicated by Section 3.2.7 of MUST be supported.
Form-style parameters generated in the form indicated by Sections 3.2.8 and 3.2.9 of
MUST be supported.The following is an example where the URI Signing Package Attribute name is "token" and the signed JWT is "SIGNEDJWT":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.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).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.)Note: The time on the entities that generate and
verify the signed URI MUST 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.Note: See the Security
Considerations section on the limitations of using an
expiration time and client IP address for distribution policy
enforcement.Issuer (iss) [optional] - The semantics in
Section 4.1.1 MUST be followed. If this
claim is used, it MUST be used to confirm that the indicated key
was provided by said issuer and used to sign the JWT. If the CDN verifying the
signed JWT does not support Issuer verification, 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.Subject (sub) [optional] - The semantics in Section 4.1.2 MUST be followed.
If this claim is used, it MUST be a JSON Web Encryption (JWE)
Object in compact serialization form, because it contains
personally identifiable information. This claim contains
information about the subject (for example, a user or an agent)
that MAY be used to verify the signed JWT.
If the received signed JWT contains a Subject claim, then any
JWT subsequently generated for CDNI redirection MUST also
contain a Subject claim, and the Subject value MUST be the same
as in the received signed JWT. A signed JWT generated for CDNI
redirection MUST NOT add a Subject claim if no Subject claim
existed in the received signed JWT.Audience (aud) [optional] - The semantics in Section 4.1.3 MUST be followed.
This claim is used to ensure that the CDN verifying the JWT is an intended recipient
of the request. The claim MUST contain an identity on behalf of whom the CDN can verify the token (e.g.,
the CSP or any CDN in the chain). A CDN MAY modify the claim as long it can generate a valid signature.Expiry Time (exp) [optional] - The semantics in Section 4.1.4 MUST be followed,
though URI Signing implementations MUST NOT allow for any time synchronization "leeway".
If this claim is used and the CDN verifying the signed JWT does not support
Expiry Time verification, or if the Expiry Time in the
signed JWT corresponds to a time equal to or earlier than the time of
the content 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.Not Before (nbf) [optional] - The semantics in Section 4.1.5 MUST be followed,
though URI Signing implementations MUST NOT allow for any time synchronization "leeway".
If this claim is used and the CDN verifying the signed JWT does not support
Not Before time verification, or if the Not Before time in the
signed JWT corresponds to a time later than the time of
the content 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.Issued At (iat) [optional] - The semantics in Section 4.1.6 MUST be followed.
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 Issued At 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.JWT ID (jti) [optional] - The semantics in Section 4.1.7 MUST be followed.
A JWT ID can be used to prevent replay attacks if the CDN stores a
list of all previously used values, and verifies
that the value in the current JWT has never been used
before. If the signed JWT contains a JWT ID claim and the
CDN verifying the signed JWT either does not support JWT ID
storage or has previously seen the value used in a request for the same content, then the CDN MUST reject the request.
If the received signed JWT contains a JWT ID claim, then any
JWT subsequently generated for CDNI redirection MUST also
contain a JWT ID claim, and the value MUST be the
same as in the received signed JWT.
If the received signed JWT does not contain a
JWT ID claim, a JWT ID claim MUST NOT be added to a signed JWT
generated for CDNI redirection. Sizing of the JWT ID is application
dependent given the desired security constraints.CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set Version (cdniv)
claim provides a means within a signed JWT to tie the claim set to a specific version
of this specification. The cdniv claim is intended to allow changes in and facilitate
upgrades across specifications. The type is JSON integer and the value MUST be set to "1",
for this version of the specification. In the absence of this claim, the value is assumed
to be "1". For future versions this claim will be mandatory. Implementations MUST reject
signed JWTs with unsupported CDNI Claim Set versions.CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical Claims Set (cdnicrit) claim
indicates that extensions to this specification are being used that
MUST be understood and processed. Its value is a comma separated listing
of claims in the Signed JWT that use those extensions.
If any of the listed extension claims are not understood
and supported by the recipient, then the Signed JWT MUST be rejected. Producers
MUST NOT include claim names defined by this specification, duplicate names, or names that do not
occur as claim names within the Signed JWT in the cdnicrit
list. Producers MUST NOT use the empty list "" as the cdnicrit
value. Recipients MAY consider the Signed JWT to be invalid if the cdnicrit
list contains any claim names defined by this
specification or if any other constraints
on its use are violated. This claim MUST be understood and processed by all implementations.Client IP (cdniip) [optional] - The Client IP (cdniip) claim holds an IP address or IP prefix for
which the Signed URI is valid. This is represented in CIDR
notation, with dotted decimal format for IPv4 addresses or canonical text
representation for IPv6 addresses.
The request MUST be 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 (JWE)
Object in compact serialization form. If the CDN verifying the
signed JWT does not support Client IP verification, or if the
Client IP in the signed JWT does not match the source IP
address in the content request, the CDN MUST
reject the request. The type of this claim is a JSON string that
contains the JWE.
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.It should be noted that use of this claim can cause issues, for example,
in situations with dual-stack IPv4 and IPv6 networks, MPTCP, QUIC, and
mobile clients switching from WiFi to Cellular networks where the client's
source address can change, even between address families. This claim exists
mainly for legacy feature parity reasons, therefore use of this claim should
be done judiciously. An example of a reasonable use case would be making a
signed JWT for an internal preview of an asset where the end consumer understands
that they must be originated from the same IP for the entirety of the session.
Using this claim at large is NOT RECOMMENDED.URI Container (cdniuc) [mandatory] - The URI Container (cdniuc)
holds the URI representation before a URI Signing Package is
added. This representation can take one of several forms detailed in
. If the URI Container used in the signed
JWT does not match the URI of the content request, the CDN verifying the
signed JWT MUST reject the request. When comparing the URI, the percent encoded
form as defined in Section 2.1 MUST be used. 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.CDNI Expiration Time Setting (cdniets) [optional] - The CDNI Expiration
Time Setting (cdniets) claim provides a means for setting the value
of the Expiry Time (exp) claim when generating a subsequent signed JWT
in Signed Token Renewal. Its type is a JSON numeric value. It
denotes the number of seconds to be added to the time at which the JWT is verified
that gives the value of the Expiry Time (exp) claim of the next signed JWT.
The CDNI Expiration Time Setting (cdniets) SHOULD NOT be used when not using Signed Token Renewal
and MUST be present when using Signed Token Renewal.CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed Token Transport (cdnistt) claim
provides a means of signalling the method through which a new signed JWT
is transported from the CDN to the UA and vice versa for the purpose of Signed Token Renewal. Its type is a JSON integer.
Values for this claim are defined in . If using
this claim you MUST also specify a CDNI Expiration Time Setting (cdniets) as noted above.CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token Depth (cdnistd) claim is used to
associate a subsequent signed JWT, generated as the result of a CDNI Signed Token Transport claim,
with a specific URI subset. Its type is a JSON integer. Signed JWTs MUST NOT use a negative
value for the CDNI Signed Token Depth claim.If the transport used for Signed Token Transport allows the CDN to associate the path component of a
URI with tokens (e.g., an HTTP Cookie Path as described in section 4.1.2.4 of ),
the CDNI Signed Token Depth value is the number of path segments that should be
considered significant for this association. A CDNI Signed Token Depth of zero means that the
client SHOULD be directed to return the token with requests for any path. If the CDNI Signed
Token Depth is greater than zero, then the client SHOULD be directed to return the token for
future requests wherein the first CDNI Signed Token Depth segments of the path match the first
CDNI Signed Token Depth segments of the signed URI path. This matching MUST use the URI with the
token removed, as specified in .If the URI path to match contains fewer segments than the CDNI Signed Token Depth claim, a signed JWT
MUST NOT be generated for the purposes of Signed Token Renewal. If the CDNI Signed Token Depth
claim is omitted, it means the same thing as if its value were zero. If the received signed JWT
contains a CDNI Signed Token Depth claim, then any JWT subsequently generated for CDNI
redirection or Signed Token Transport MUST also contain a CDNI Signed Token Depth claim, and the
value MUST be the same as in the received signed JWT.The URI Container (cdniuc) claim takes one of the following forms: 'hash:' or 'regex:'. More forms may be added in the future to extend the capabilities.Before comparing a URI with contents of this container, the following steps MUST be performed:
Prior to verification, remove the signed JWT from
the URI. This removal is only for the purpose of determining if the URI matches; all
other purposes will use the original URI. If the signed JWT is terminated by anything
other than a sub-delimiter (as defined in Section 2.2),
everything from the reserved character (as defined in Section 2.2)
that precedes the URI Signing Package Attribute to the last character of the signed
JWT will be removed, inclusive. Otherwise, everything from the first character of the
URI Signing Package Attribute to the sub-delimiter that terminates the signed
JWT will be removed, inclusive.Normalize the URI according to section 2.7.3 and
sections 6.2.2 and 6.2.3. This applies to both generation
and verification of the signed JWT.Prefixed with 'hash:', this string is a URL Segment form ( Section 5) of the URI.Prefixed with 'regex:', this string is any POSIX Section 9 Extended
Regular Expression compatible regular expression used to match against the requested URI.
These regular expressions MUST be evaluated in the POSIX locale (POSIX Section 7.2).
Note: Because '\' has special meaning in JSON as the escape character within JSON strings, the regular expression character '\' MUST be escaped as '\\'.An example of a 'regex:' is the following:Note: Due to computational complexity of executing arbitrary regular expressions, it is RECOMMENDED to only execute after verifying the JWT to ensure its authenticity.The header of the JWT MAY be passed via the CDNI Metadata interface instead of
being included in the URISigningPackage. The header value MUST be transmitted in
the serialized encoded form and prepended to the JWT payload and signature passed in
the URISigningPackage prior to verification. This reduces the size of the signed JWT
token.For content that is delivered via HTTP in a segmented fashion,
such as MPEG-DASH or HTTP Live Streaming (HLS),
special provisions need to be made in order to ensure URI Signing can be
applied. In general, segmented protocols work by breaking large objects
(e.g., videos) into a sequence of small independent segments. Such segments
are then referenced by a separate manifest file, which either includes
a list of URLs to the segments or specifies an algorithm through which
a User Agent can construct the URLs to the segments. Requests for segments
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 a vulnerability to malicious User Agents sharing the
manifest file and deep-linking to the segments.One method for dealing with this vulnerability would be to include, in
the manifest itself, Signed URIs that point to the individual segments.
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 segmentation protocol
used. Secondly, it could also require the expiration time of the
Signed URIs to be valid for an extended duration if the content
described by the manifest is meant to be consumed in real time. For instance, if the manifest file were
to contain a segmented video stream of more than 30 minutes in length,
Signed URIs would require to be valid for a at least 30 minutes, thereby reducing
their effectiveness and that of the URI Signing mechanism in general.
For a more detailed analysis of how segmented protocols such as HTTP Adaptive Streaming protocols affect CDNI,
see Models for HTTP-Adaptive-Streaming-Aware CDNI.The method described in this section allows CDNs to use URI Signing
for segmented content without
having to include the Signed URIs in the manifest files themselves.In order to allow for effective access control of segmented content, the
URI Signing mechanism defined in this section is based on a method
through which subsequent segment requests can be linked together.
As part of the JWT verification procedure, the CDN can generate a new
signed JWT that the UA can use to do a subsequent request. More specifically,
whenever a UA successfully retrieves a segment, it receives, in the
HTTP 2xx Successful message, a signed JWT that it can use whenever it
requests the next segment. As long as each successive signed JWT
is correctly verified before a new one is generated, the model is not
broken and the User Agent can successfully retrieve additional segments.
Given the fact that with segmented protocols, it is usually not possible to
determine a priori which segment will be requested next (i.e., to allow for
seeking within the content and for switching to a different representation),
the Signed Token Renewal uses the
URI Regular Expression Container scoping mechanisms in the URI Container
(cdniuc) claim to allow a signed JWT to be valid for more than one URL.In order for this renewal of signed JWTs to work, it is necessary for
a UA to extract the signed JWT from the HTTP 2xx Successful message of an
earlier request and use it to retrieve the next segment. The exact mechanism
by which the client does this 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 JWTs,
defines a mechanism using HTTP Cookies that allows such UAs to support
the concept of renewing signed JWTs without requiring any additional UA support.The cdnistt claim and cdniets claim
MUST both be present for Signed Token Renewal. cdnistt MAY be set to
a value of '0' to mean no Signed Token Renewal, but there still MUST be a corresponding cdniets that verifies as
a JSON number. However, if use of Signed Token Renewal is not desired, it is RECOMMENDED to simply omit both.This section assumes the value of the CDNI Signed Token Transport (cdnistt) claim
has been set to 1.When using the Signed Token Renewal mechanism, the signed JWT is
transported to the UA via a 'URISigningPackage' cookie added to the
HTTP 2xx Successful message along with the content being returned to
the UA, or to the HTTP 3xx Redirection message in case the UA is
redirected to a different server.For security purposes, the use of cross-domain cookies is not supported
in some application environments. As a result, the Cookie-based
method for transport of the Signed Token described in
might break if used in combination with an HTTP 3xx Redirection
response where the target URL is in a different domain. In such
scenarios, Signed Token Renewal of a signed JWT SHOULD be communicated
via the query string instead, in a similar fashion to how regular
signed JWTs (outside of Signed Token Renewal) are communicated. Note
the value of the CDNI Signed Token Transport (cdnistt) claim
MUST be set to 2.Note that the process described herein only works in cases where both the manifest
file and segments constituting the segmented content are delivered from
the same domain. In other words, any redirection between different domains needs to be
carried out while retrieving the manifest file.Some of the CDNI Interfaces need enhancements to support URI Signing.
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 verify a Signed URI. Events that pertain to URI
Signing (e.g., request denial or delivery after an access authorization decision has been made)
need to be included in the logs communicated through the CDNI Logging
interface.URI Signing has no impact on this interface.The CDNI Request Routing: Footprint and Capabilities
Semantics document defines support for
advertising CDNI Metadata capabilities, via CDNI Payload
Type. The CDNI Payload Type registered in
can be used for capability advertisement.The CDNI Request Routing
Redirection Interface describes the recursive request
redirection method. For URI Signing, the uCDN signs the URI
provided by the dCDN. URI Signing therefore has no impact
on this interface.The CDNI Metadata
Interface describes the CDNI metadata distribution needed to
enable content acquisition and delivery. For URI Signing, a new
CDNI metadata object is specified.The UriSigning Metadata object contains information to enable URI
Signing and verification by a dCDN. The UriSigning properties are
defined below.Property: enforceDescription: 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 is signed and verified before
delivering content. Otherwise, the dCDN does not perform
verification, regardless of whether or not the URI is signed.Type: BooleanMandatory-to-Specify: No. The default is true.Property: issuersDescription: A list of valid Issuers against which
the Issuer claim in the signed JWT may be cross-referenced.Type: Array of StringsMandatory-to-Specify: No. The default is an empty
list. An empty list means that any Issuer is acceptable.Property: package-attributeDescription: The attribute name to use for the URI Signing
Package.Type: StringMandatory-to-Specify: No. The default is
"URISigningPackage".Property: jwt-headerDescription: The header part of JWT that is used for
verifying a signed JWT when the JWT token in the URI Signing
Package does not contain a header part.Type: StringMandatory-to-Specify: No. By default, the header is assumed to be included in the JWT token.The following is an example of a URI Signing metadata payload with all default values:The following is an example of a URI Signing metadata payload with explicit values: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.The following CDNI Logging field for URI Signing SHOULD be
supported in the HTTP Request Logging Record as specified in CDNI Logging Interface,
using the new "cdni_http_request_v2" record-type registered in
.s-uri-signing (mandatory): format: 3DIGITfield value: this characterises the URI Signing verification
performed by the Surrogate on the request. The allowed values
are registered in .occurrence: there MUST be zero or exactly one instance of
this field.s-uri-signing-deny-reason (optional): format: QSTRINGfield value: a string for providing further information in
case the signed JWT was rejected, e.g., for debugging
purposes.occurrence: there MUST be zero or exactly one instance of
this field.URI Signing supports both HTTP-based and DNS-based request routing.
JSON Web Token (JWT) 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 enabling the claims to be digitally
signed or integrity protected with a Message Authentication Code
(MAC).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 or 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.The URI Signing method
(assuming HTTP redirection, iterative request routing, and a CDN
path with two CDNs) includes the following steps:Using the CDNI Footprint & Capabilities Advertisement
interface, the dCDN advertises its capabilities
including URI Signing support to the uCDN.CSP provides to the uCDN the information needed to
verify signed URIs from that CSP. For example, this
information will include one or more keys used for validation.Using the CDNI Metadata interface, the uCDN
communicates to a dCDN the information needed to
verify signed URIs 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
in addition to keys used for validation.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 local distribution policy.If the authorization decision is negative, the CSP rejects the
request and sends an error code (e.g., 403 Forbidden) in the HTTP
response.If the authorization decision is positive, the CSP computes a
Signed JWT 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.On receipt of the corresponding content request, the
uCDN verifies the Signed JWT in the URI using the
information provided by the CSP.If the verification result is negative, the uCDN rejects
the request and sends an error code 403 Forbidden in the HTTP
response.If the verification result is positive, the uCDN computes a
Signed JWT that is based on unique parameters of that request and
provides it to the end user as the URI to use to further request the
content from the dCDN.On receipt of the corresponding content request, the
dCDN verifies the Signed JWT in the signed URI using the
information provided by the uCDN in the CDNI
Metadata.If the verification result is negative, the dCDN rejects the
request and sends an error code 403 Forbidden in the HTTP
response.If the verification result is positive, the dCDN serves the
request and delivers the content.At a later time, the dCDN reports logging events that
include URI Signing information.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.Note: While using a symmetric shared key is supported, it is NOT RECOMMENDED.
See the Security Considerations section about the
limitations of shared keys.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 verify the signed URI.Note: While using a symmetric shared key is supported, it is NOT RECOMMENDED.
See the Security Considerations section about the
limitations of shared keys.The URI Signing method
(assuming iterative DNS request routing and a CDN path with two
CDNs) includes the following steps.Using the CDNI Footprint & Capabilities Advertisement
interface, the dCDN advertises its capabilities
including URI Signing support to the uCDN.CSP provides to the uCDN the information needed to
verify Signed JWTs from that CSP. For example, this
information will include one or more keys used for validation.Using the CDNI Metadata interface, the uCDN
communicates to a dCDN the information needed to
verify Signed JWTs from the CSP (e.g., the URI query
string parameter name for the URI Signing Package Attribute). In
the case of symmetric shared key, the uCDN checks if the
dCDN is allowed by CSP to obtain the shared secret
key.Note: While using a symmetric shared key is supported, it is NOT RECOMMENDED.
See the Security Considerations section about the
limitations of shared keys.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 local distribution policy.If the authorization decision is negative, the CSP rejects the
request and sends an error code (e.g., 403 Forbidden) in the HTTP
response.If the authorization decision is positive, the CSP computes a
Signed JWT that is based on unique parameters of that
request and includes it in the URI provided to the end user to
request the content.End user sends DNS request to the uCDN.On receipt of the DNS request, the uCDN redirects
the request to the dCDN.End user sends DNS request to the dCDN.On receipt of the DNS request, the dCDN responds with
IP address of one of its Surrogates.On receipt of the corresponding content request, the
dCDN verifies the Signed JWT in the URI using the
information provided by the uCDN in the CDNI
Metadata.If the verification result is negative, the dCDN rejects the
request and sends an error code 403 Forbidden in the HTTP
response.If the verification result is positive, the dCDN serves the
request and delivers the content.At a later time, dCDN reports logging events that
includes URI Signing information.With DNS-based request routing, URI Signing matches well the
general chain of trust model of CDNI when used with asymmetric keys
because the only key information that needs to be distributed across
multiple, possibly untrusted, CDNI hops is the public key, which
is generally not confidential.With DNS-based request routing, URI Signing does not match well with 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, to CDNs with which the CSP may not have a trust
relationship. This raises a security concern for applicability of URI
Signing with symmetric keys in case of DNS-based inter-CDN request
routing. Due to these concerns, this architecture is NOT RECOMMENDED.This document requests the registration of the following CDNI
Payload Type under the IANA "CDNI Payload Types" registry:Payload TypeSpecificationMI.UriSigningRFCthis[RFC Editor: Please replace RFCthis with the published RFC
number for this document.]Purpose: The purpose of this payload type is to distinguish
UriSigning MI objects (and any associated capability advertisement).Interface: MI/FCIEncoding: see This document requests the registration of the following CDNI
Logging record-type under the IANA "CDNI Logging record-types" registry:record-typesReferenceDescriptioncdni_http_request_v2RFCthisExtension to CDNI Logging Record version 1 for content
delivery using HTTP, to include URI Signing logging fields[RFC Editor: Please replace RFCthis with the published RFC
number for this document.]The "cdni_http_request_v2" record-type supports all of
the fields supported by the "cdni_http_request_v1"
record-type plus the
two additional fields "s-uri-signing" and
"s-uri-signing-deny-reason", registered by this document in
. The name,
format, field value, and occurence information for the two
new fields can be found in
of this
document.This document requests the registration of the following CDNI
Logging fields under the IANA "CDNI Logging Field Names" registry:Field NameReferences-uri-signingRFCthiss-uri-signing-deny-reasonRFCthis[RFC Editor: Please replace RFCthis with the published RFC
number for this document.]The IANA is requested to create a new "CDNI URI Signing Verification Code" subregistry, in the
"Content Delivery Networks Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing Verification Code"
namespace defines the valid values associated with the s-uri-signing CDNI Logging Field. The CDNI URI Signing
Verification Code is a 3DIGIT value as defined in . Additions to the CDNI URI Signing
Verification Code namespace will conform to the "Specification Required" policy as defined in
. Updates to this subregistry are expected to be infrequent.ValueReferenceDescription000RFCthisNo signed JWT verification performed200RFCthisSigned JWT verification performed and verified400RFCthisSigned JWT verification performed and rejected because of incorrect signature401RFCthisSigned JWT verification performed and rejected because of Issuer enforcement402RFCthisSigned JWT verification performed and rejected because of Subject enforcement403RFCthisSigned JWT verification performed and rejected because of Audience enforcement404RFCthisSigned JWT verification performed and rejected because of Expiration Time enforcement405RFCthisSigned JWT verification performed and rejected because of Not Before enforcement406RFCthisSigned JWT verification performed and rejected because only one of CDNI Signed Token Transport or CDNI Expiration Time Setting present.407RFCthisSigned JWT verification performed and rejected because of JWT ID enforcement408RFCthisSigned JWT verification performed and rejected because of Version enforcement409RFCthisSigned JWT verification performed and rejected because of Critical Extension enforcement410RFCthisSigned JWT verification performed and rejected because of Client IP enforcement411RFCthisSigned JWT verification performed and rejected because of URI Container enforcement500RFCthisUnable to perform signed JWT verification because of malformed URI[RFC Editor: Please replace RFCthis with the published RFC
number for this document.]The IANA is requested to create a new "CDNI URI Signing
Signed Token Transport" subregistry in the "Content
Delivery Networks Interconnection (CDNI) Parameters" registry.
The "CDNI URI Signing Signed Token Transport"
namespace defines the valid values
that may be in the Signed Token Transport (cdnistt) JWT claim.
Additions to the Signed Token Transport namespace conform to the
"Specification Required" policy as defined in .
Updates to this subregistry are expected to be infrequent.The following table defines the initial Enforcement
Information Elements:ValueDescriptionRFC0Designates token transport is not enabledRFCthis1Designates token transport via cookieRFCthis2Designates token transport via query stringRFCthis[RFC Editor: Please replace RFCthis with the published RFC
number for this document.]
This specification registers the following Claims
in the IANA "JSON Web Token Claims" registry
established by .
Claim Name: cdnivClaim Description: CDNI Claim Set VersionChange Controller: IESGSpecification Document(s): of [[ this specification ]]Claim Name: cdnicritClaim Description: CDNI Critical Claims SetChange Controller: IESGSpecification Document(s): of [[ this specification ]]Claim Name: cdniipClaim Description: CDNI IP AddressChange Controller: IESGSpecification Document(s): of [[ this specification ]]Claim Name: cdniucClaim Description: CDNI URI ContainerChange Controller: IESGSpecification Document(s): of [[ this specification ]]Claim Name: cdnietsClaim Description: CDNI Expiration Time Setting for Signed Token RenewalChange Controller: IESGSpecification Document(s): of [[ this specification ]]Claim Name: cdnisttClaim Description: CDNI Signed Token Transport Method for Signed Token RenewalChange Controller: IESGSpecification Document(s): of [[ this specification ]]Claim Name: cdnistdClaim Description: CDNI Signed Token DepthChange Controller: IESGSpecification Document(s): of [[ this specification ]]Generally speaking, we should determine the registration has a rational justification
and does not duplicate a previous registration. Early assignment should be permissible as long
as there is a reasonable expectation that the specification will become formalized. Expert
Reviewers should be empowered to make determinations, but generally speaking they should allow
new claims that do not otherwise introduce conflicts with implementation or things that may lead
to confusion. They should also follow the guidelines of Section 5 when sensible.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.CDNI URI Signing Signed Tokens leverage JSON Web Tokens and thus guidelines in
are applicable for all JWT interactions.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.That said, there are a number of aspects that limit the level of
security offered by URI Signing and that anybody implementing URI
Signing should be aware of.Replay attacks: 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
sudden network issues from denying legitimate UAs access to
the content. One may also reduce exposure to replay attacks by
including a unique one-time access ID via the JWT ID 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. This list should be kept bounded. A reasonable approach
would be to expire the entries based on the exp claim value. If no exp claim is present
then a simple LRU could be used, however this would allow values to eventually be reused.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
different users based on Client IP Address which can lead to 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.
However, this may be easily circumvented by a sophisticated attacker.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. While
using a shared key scheme can be convenient, this architecture is NOT
RECOMMENDED due to the risks associated. It is included for legacy
feature parity and is highly discouraged in new implementations.If a shared key usable for signing is compromised, an attacker
can use it to perform a denial-of-service attack by forcing the CDN to
evaluate prohibitively expensive regular expressions embedded in a
URI Container (cdniuc) claim. As a result, compromised keys should be timely revoked
in order to prevent exploitation.The URI Container (cdniuc) claim can be given a wildcard value. This, combined
with the fact that it is the only mandatory claim, means you can effectively make
a skeleton key. Doing this does not sufficiently limit the scope of the JWT and is
NOT RECOMMENDED. The only way to prevent such a key from being used after it is
distributed is to revoke the signing key so it no longer validates.The privacy protection concerns described in CDNI Logging Interface apply when
the client's IP address (cdniip) or Subject (sub) is embedded in the Signed URI.
For this reason, the mechanism described in encrypts the Client IP or Subject before
including it in the URI Signing Package (and thus the URL itself).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, Gancho Tenev, Brian Campbell, and Chris Lemmons.In addition, the authors would also like to make special mentions for certain
people who contributed significant sections to this document.Matt Caulfield provided content for the CDNI Metadata Interface
section.Emmanuel Thomas provided content for HTTP Adaptive Streaming.Matt Miller provided consultation on JWT usage as well as code to
generate working JWT examples.The Open Group Base Specifications Issue 7JSON Web Token ClaimsIANAInformation technology -- Dynamic adaptive streaming
over HTTP (DASH) -- Part 1: Media presentation description
and segment formatISOThis section contains three examples of token usage: a simple example with only the
required claim present, a complex example which demonstrates the full JWT claims set,
including an encrypted Client IP (cdniip), and one that uses a Signed Token Renewal.Note: All of the examples have whitespace added to improve formatting and readability,
but are not present in the generated content.All examples use the following JWK Set :Note: They are the public signing key, the private signing
key, and the shared secret enctyption key, respectively. The public and private signing
keys have the same fingerprint and only vary by the 'd' parameter that is missing from the
public signing key.
This example is a simple common usage example containing
a minimal subset of claims that the authors find most useful.
The JWT Claim Set before signing:
Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the URL Segment form
( Section 5) of "http://cdni.example/foo/bar".
The signed JWT:
This example uses all fields except for those dealing
with Signed Token Renewal, including Client IP (cdniip) and Subject (sub) which are
encrpyted. This significantly increases the size of the signed
JWT token.
JWE for Client IP (cdniip) of [2001:db8::1/32]:
JWE for Subject (sub) of "UserToken":
The JWT Claim Set before signing:
The signed JWT:
This example uses fields for Signed Token Renewal.
The JWT Claim Set before signing:
The signed JWT:
Once the server verifies the signed JWT it will return a
new signed JWT with an updated expiry time (exp) as shown
below. Note the expiry time is increased by the expiration
time setting (cdniets) value.
The JWT Claim Set before signing:
The signed JWT: