< draft-ietf-cdni-uri-signing-25.txt   draft-ietf-cdni-uri-signing-26.txt >
CDNI R. van Brandenburg CDNI R. van Brandenburg
Internet-Draft Tiledmedia Internet-Draft Tiledmedia
Intended status: Standards Track K. Leung Intended status: Standards Track K. Leung
Expires: 8 September 2022 Expires: 23 September 2022
P. Sorber P. Sorber
Apple, Inc. Apple, Inc.
7 March 2022 22 March 2022
URI Signing for Content Delivery Network Interconnection (CDNI) URI Signing for Content Delivery Network Interconnection (CDNI)
draft-ietf-cdni-uri-signing-25 draft-ietf-cdni-uri-signing-26
Abstract Abstract
This document describes how the concept of URI Signing supports the This document describes how the concept of URI Signing supports the
content access control requirements of Content Delivery Network content access control requirements of Content Delivery Network
Interconnection (CDNI) and proposes a URI Signing method as a JSON Interconnection (CDNI) and proposes a URI Signing method as a JSON
Web Token (JWT) profile. Web Token (JWT) profile.
The proposed URI Signing method specifies the information needed to The proposed URI Signing method specifies the information needed to
be included in the URI to transmit the signed JWT, as well as the be included in the URI to transmit the signed JWT, as well as the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 September 2022. This Internet-Draft will expire on 23 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 8, line 11 skipping to change at page 8, line 11
has a trust relationship with the uCDN. The delivery of the content 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 may be delegated to a dCDN, which has a relationship with the uCDN
but may have no relationship with the CSP. but may have no relationship with the CSP.
In CDNI, there are two methods for request routing: DNS-based and 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 HTTP-based. For DNS-based request routing, the Signed URI (i.e., the
Target CDN URI) provided by the CSP reaches the CDN directly. In the Target CDN URI) provided by the CSP reaches the CDN directly. In the
case where the dCDN does not have a trust relationship with the CSP, case where the dCDN does not have a trust relationship with the CSP,
this means that either an asymmetric public/private key method needs 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 to be used for computing the signed JWT (because the CSP and dCDN are
not able to exchange symmetric shared secret keys). Shared keys not able to exchange symmetric shared secret keys). Shared keys MUST
SHOULD NOT be redistributed. NOT be redistributed.
For HTTP-based request routing, the Signed URI (i.e., the Target CDN 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 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 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 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 new signed JWT, the relationship between the dCDN and CSP is not
relevant. Because a relationship between uCDN and dCDN always relevant. Because a relationship between uCDN and dCDN always
exists, either asymmetric public/private keys or symmetric shared exists, either asymmetric public/private keys or symmetric shared
secret keys can be used for URI Signing with HTTP-based request secret keys can be used for URI Signing with HTTP-based request
routing. Note that the signed Redirection URI MUST maintain HTTPS as routing. Note that the signed Redirection URI MUST maintain HTTPS as
skipping to change at page 26, line 50 skipping to change at page 26, line 50
support to the uCDN. support to the uCDN.
2. CSP provides to the uCDN the information needed to verify Signed 2. CSP provides to the uCDN the information needed to verify Signed
JWTs from that CSP. For example, this information will include JWTs from that CSP. For example, this information will include
one or more keys used for validation. one or more keys used for validation.
3. Using the CDNI Metadata interface, the uCDN communicates to a 3. Using the CDNI Metadata interface, the uCDN communicates to a
dCDN the information needed to verify Signed JWTs from the CSP dCDN the information needed to verify Signed JWTs from the CSP
(e.g., the URI query string parameter name for the URI Signing (e.g., the URI query string parameter name for the URI Signing
Package Attribute). In the case of symmetric shared key, the Package Attribute). In the case of symmetric shared key, the
uCDN SHOULD NOT share the key with a dCDN. uCDN MUST NOT share the key with a dCDN.
4. When a UA requests a piece of protected content from the CSP, 4. When a UA requests a piece of protected content from the CSP,
the CSP makes a specific authorization decision for this unique the CSP makes a specific authorization decision for this unique
request based on its local distribution policy. request based on its local distribution policy.
5. If the authorization decision is negative, the CSP rejects the 5. If the authorization decision is negative, the CSP rejects the
request and sends an error code (e.g., 403 Forbidden) in the request and sends an error code (e.g., 403 Forbidden) in the
HTTP response. HTTP response.
6. If the authorization decision is positive, the CSP computes a 6. If the authorization decision is positive, the CSP computes a
skipping to change at page 28, line 5 skipping to change at page 28, line 5
the only key information that needs to be distributed across the only key information that needs to be distributed across
multiple, possibly untrusted, CDNI hops is the public key, which is multiple, possibly untrusted, CDNI hops is the public key, which is
generally not confidential. generally not confidential.
With DNS-based request routing, URI Signing does not match well with With DNS-based request routing, URI Signing does not match well with
the general chain of trust model of CDNI when used with symmetric the general chain of trust model of CDNI when used with symmetric
keys because the symmetric key information needs to be distributed keys because the symmetric key information needs to be distributed
across multiple CDNI hops, to CDNs with which the CSP may not have a across multiple CDNI hops, to CDNs with which the CSP may not have a
trust relationship. This raises a security concern for applicability trust relationship. This raises a security concern for applicability
of URI Signing with symmetric keys in case of DNS-based inter-CDN of URI Signing with symmetric keys in case of DNS-based inter-CDN
request routing. Due to these concerns, this architecture is NOT request routing. Due to these flaws, this architecture MUST NOT be
RECOMMENDED. implemented.
Note: While using a symmetric shared key is supported, it is NOT Note: While using a symmetric shared key is supported, it is NOT
RECOMMENDED. See the Security Considerations (Section 7) section RECOMMENDED. See the Security Considerations (Section 7) section
about the limitations of shared keys. about the limitations of shared keys.
6. IANA Considerations 6. IANA Considerations
6.1. CDNI Payload Type 6.1. CDNI Payload Type
This document requests the registration of the following CDNI Payload This document requests the registration of the following CDNI Payload
 End of changes. 7 change blocks. 
9 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/