URI Signing for Content Delivery Network Interconnection (CDNI)
Extracted elements (31)
Asymmetric public/private keys are strongly preferred over symmetric shared keys because symmetric key distribution requires confidentiality across all verifying CDNs, whereas public keys can be distributed openly. A compromised symmetric key allows an attacker to generate valid Signed URIs and also to embed computationally expensive regular expressions to cause denial-of-service against CDN verifiers.
Signed Token Renewal was introduced to support URI Signing for segmented content (MPEG-DASH, HLS) without embedding pre-signed URIs in manifest files. Embedding signed URIs in manifests would require CDNs to understand each segmentation protocol and would force long expiration windows (e.g., 30+ minutes for live streams), undermining the security value of short-lived tokens.
The Client IP (cdniip) claim exists mainly for legacy feature parity. Its use is NOT RECOMMENDED at large because IP addresses can change mid-session (dual-stack, MPTCP, QUIC, Wi-Fi-to-cellular handoff) and the claim only makes sense for controlled internal preview scenarios where the client IP is stable.
Cross-domain cookie restrictions in some application environments can break the cookie-based Signed Token Renewal mechanism (cdnistt=1) when used with HTTP 3xx redirection to a different domain. In such scenarios, Signed Token Renewal SHOULD instead be communicated via the query string (cdnistt=2). This mechanism only works when both manifest and segments are served from the same domain.
The JWT header MAY be passed out-of-band via the CDNI Metadata interface (the 'jwt-header' property) rather than included in the URISigningPackage token in the URI. This reduces the size of the signed JWT token embedded in the URI.
Both cdnistt and cdniets claims MUST be present for Signed Token Renewal. cdnistt MAY be set to 0 to mean no renewal, but a corresponding numeric cdniets MUST still be present in that case. If Signed Token Renewal is not desired, it is RECOMMENDED to simply omit both.
Both path-style parameters (per RFC 6570 Section 3.2.7) and form-style parameters (per RFC 6570 Sections 3.2.8 and 3.2.9) MUST be supported when locating the URI Signing Package Attribute. The first matching parameter SHOULD be taken as the signed JWT.
Prior to URI comparison, the signed JWT MUST be removed from the URI and the URI MUST be normalized per RFC 7230 Section 2.7.3 and RFC 3986 Sections 6.2.2 and 6.2.3. Percent-encoded form per RFC 3986 Section 2.1 MUST be used when comparing URIs.
Shared symmetric keys MUST NOT be redistributed from the entity that received them. In DNS-based routing, the uCDN MUST NOT share a symmetric key with a dCDN.
The Client IP Address (cdniip) claim MUST be a JSON Web Encryption (JWE) Object in compact serialization form because it contains personally identifiable information. The Subject (sub) claim MUST also be a JWE Object in compact serialization form for the same reason.
The JWT MUST be signed to prevent the UA from altering the claims. The CDNI URI Container (cdniuc) claim is the only mandatory claim and MUST be present in every URI Signing JWT.
URI Signing implementations MUST NOT allow for any time-synchronization 'leeway' for the Not Before (nbf) claim. If the Not Before time is later than the request time, the CDN MUST reject the request.
When a received signed JWT contains Expiry Time, Not Before, Subject, Client IP, JWT ID, or Signed Token Depth claims, any subsequently generated JWT for CDNI redirection MUST also contain those claims with the same values. A redirection JWT MUST NOT add these claims if they were absent in the received JWT.
With DNS-based request routing, symmetric shared keys MUST NOT be used across CDNI hops because the key must be distributed to CDNs with which the CSP may have no trust relationship. This architecture MUST NOT be implemented.
When a client's IP address (cdniip) or Subject (sub) is embedded in the Signed URI, the privacy protections described in RFC 7937 apply. Both fields MUST be encrypted as JWE objects in compact serialization before inclusion in the URI Signing Package to prevent exposure of personally identifiable information in the URL.
The CDNI Claim Set Version (cdniv) claim is a JSON integer that ties the claim set to a specific version of the specification. For this version its value MUST be '1'; in the absence of this claim the value is assumed to be '1'. Implementations MUST reject signed JWTs with unsupported cdniv values.
The CDNI Critical Claims Set (cdnicrit) claim is a comma-separated list of extension claims that MUST be understood and processed by the recipient. If any listed claim is not understood, the Signed JWT MUST be rejected. Producers MUST NOT include standard claim names or an empty list.
The CDNI URI Container (cdniuc) claim is the sole mandatory claim; it holds the URI representation before a URI Signing Package is added. It takes one of two forms: 'hash:' (a URL Segment hash per RFC 6920) or 'regex:' (a POSIX Extended Regular Expression).
The Signed Token Renewal mechanism uses three CDNI-specific claims: cdniets (Expiration Time Setting, a JSON numeric seconds offset for the next JWT's exp), cdnistt (Signed Token Transport, a JSON integer indicating cookie=1 or query-string=2), and cdnistd (Signed Token Depth, a non-negative JSON integer scoping the token to a URI path prefix).
The URI Signing Package (URISigningPackage) is the URI attribute that encapsulates all URI Signing claims in a signed JWT encoded format. It is exposed in the Signed URI as a path-style parameter or a form-style parameter, with the parameter name defined in CDNI Metadata or by configuration.
The UriSigning Metadata object (type MI.UriSigning) distributed via the CDNI Metadata Interface carries four optional properties: 'enforce' (Boolean, default true), 'issuers' (array of strings, default empty), 'package-attribute' (string, default 'URISigningPackage'), and 'jwt-header' (string for out-of-band JWT header transmission).
Two CDNI Logging fields are defined for URI Signing: 's-uri-signing' (mandatory, 3DIGIT format, characterizes the JWT verification result) and 's-uri-signing-deny-reason' (optional, QSTRING, provides further information on rejection). Both may appear zero or one time per log record.
IANA created the 'CDNI URI Signing Signed Token Transport' subregistry under 'CDNI Parameters' with Specification Required policy. Initial values: 0 (transport not enabled), 1 (transport via cookie), 2 (transport via query string).
IANA created the 'CDNI URI Signing Verification Code' subregistry under 'CDNI Parameters' with Specification Required policy. Initial values span 000 (no verification), 200 (verified), 400–411 (rejected for specific claim failures including signature, issuer, subject, audience, expiry, nbf, cdnistt/cdniets pairing, jti, version, critical extension, client IP, and URI container), and 500 (malformed URI).
IANA registered 'cdni_http_request_v2' in the 'CDNI Logging record-types' registry. This record type extends the v1 HTTP logging record with two new URI Signing fields: s-uri-signing (3DIGIT verification code) and s-uri-signing-deny-reason (QSTRING).
IANA registered 'MI.UriSigning' in the 'CDNI Payload Types' registry to identify UriSigning Metadata Interface objects and associated capability advertisement on the MI/FCI interfaces.
RFC 9246 registers seven new claims in the IANA 'JSON Web Token Claims' registry: cdniv (CDNI Claim Set Version), cdnicrit (CDNI Critical Claims Set), cdniip (CDNI IP Address), cdniuc (CDNI URI Container), cdniets (CDNI Expiration Time Setting), cdnistt (CDNI Signed Token Transport Method), and cdnistd (CDNI Signed Token Depth).
A compromised symmetric signing key allows an attacker to embed arbitrarily expensive regular expressions in the cdniuc claim, forcing CDN verifiers to execute them and causing a denial-of-service. The document RECOMMENDS verifying JWT authenticity before evaluating regex patterns, and timely revocation of compromised keys.
A valid Signed URI is vulnerable to replay attacks. Mitigations include short exp/nbf windows and the jti (JWT ID) claim: the CDN stores all used jti values and MUST reject requests whose jti has been seen before. The jti list should be bounded by expiring entries based on the exp claim or using an LRU cache.
Setting cdniuc to a wildcard value creates a 'skeleton key' that is effectively valid for any URI. Because cdniuc is the only mandatory claim, doing so removes all URI scoping. This is NOT RECOMMENDED; the only mitigation after distribution is to revoke the signing key.
The URI Hash Container is prefixed with 'hash:' followed by a URL Segment form (RFC 6920 Section 5) of the URI. The URI Regular Expression Container is prefixed with 'regex:' followed by a POSIX Extended Regular Expression; the backslash character MUST be escaped as '\\' due to JSON string encoding.