| < 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/ | ||||