Content Delivery Networks Interconnection P. Chaudhari Internet-Draft Disney Intended status: Standards Track G. Goldstein Expires: 7 July 2025 W. Power Lumen Technologies A. Warshavsky Qwilt 3 January 2025 CDNI Client Access Control Metadata draft-ietf-cdni-client-access-control-metadata-01 Abstract This specification adds to the basic client access control metadata in RFC8006, providing content providers and upstream content delivery networks (uCDNs) extended capabilities in defining location and time window restrictions. Support is also provided to define required Transport Layer Security (TLS) certificates and encryption levels. The specification also defines configuration metadata for the Common Access Token (CAT), developed jointly by the Streaming Video Technology Alliance (SVTA) and Consumer Technology Association Web Application Video Ecosystem (CTA-WAVE). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 July 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Chaudhari, et al. Expires 7 July 2025 [Page 1] Internet-Draft CDNI Client Access Control Metadata January 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 3. MI.LocationACLExtended . . . . . . . . . . . . . . . . . . . 3 3.1. MI.LocationRuleExtended . . . . . . . . . . . . . . . . . 5 4. MI.TimeWindowACLExtended . . . . . . . . . . . . . . . . . . 6 4.1. MI.TimeWindowRuleExtended . . . . . . . . . . . . . . . . 7 5. MI.CertificateMetadata . . . . . . . . . . . . . . . . . . . 8 5.1. MI.EncryptionLevelMetadata . . . . . . . . . . . . . . . 10 5.2. MI.CertificateCredentialsMetadata . . . . . . . . . . . . 11 6. MI.ClientAuthMetadata . . . . . . . . . . . . . . . . . . . . 12 6.1. MI.CATAuth . . . . . . . . . . . . . . . . . . . . . . . 13 6.1.1. MI.CATTokenLocator . . . . . . . . . . . . . . . . . 14 6.1.2. MI.CATTokenConfiguration . . . . . . . . . . . . . . 15 6.1.3. MI.CATTokenVerificationAction . . . . . . . . . . . . 16 6.1.4. MI.CATTokenDefinedResponse . . . . . . . . . . . . . 17 6.1.5. MI.CATIF . . . . . . . . . . . . . . . . . . . . . . 18 6.1.6. MI.CATTokenObject . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Iana Considerations . . . . . . . . . . . . . . . . . . . . . 21 8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 21 8.2. "CDNI Metadata Protocol Types" Registry . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Normative References . . . . . . . . . . . . . . . . . . . . 24 11. Informative References . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction The [RFC8006] LocationACL and TimeWindowACL objects provide basic capabilities to gate a client's access to content. This specification details alternatives to these objects (using LocationACLExtended and TimeWindowACLExtended), that allow for the configuration of a Hypertext Transfer Protocol (HTTP) response in cases where requests are denied. Additional objects allow for the specification of metadata for required TLS certificates, encryption levels, and authentication tokens leveraging the CTA-WAVE Common Access Token standard [CTA-5007] The specification also introduces Chaudhari, et al. Expires 7 July 2025 [Page 2] Internet-Draft CDNI Client Access Control Metadata January 2025 standardized names for HTTP2 and HTTP3 protocols. 2. Requirements 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 [RFC2119]. 3. MI.LocationACLExtended MI.LocationACLExtended is an alternative to the Content Delivery Network Interconnection (CDNI) standard MI.LocationACL object that defines the locations (footprints) a User Agent needs to be in, in order to be able to receive the associated content. MI.LocationACLExtended uses ACL rules of type MI.LocationRuleExtended, providing rules for handling denied requests. This object conforms to the specification defined for the behavior of MI.LocationACL and the two are mutually exclusive. Note that MI.LocationACLExtended instances that deny access are handled as terminating objects (as defined in [I-D.goldstein-processing-stages-metadata]) in that processing is terminated upon execution. Property: rules * Description: List of allow/deny rules per user location. * Type: array of MI.LocationRuleExtended objects. * Mandatory-to-Specify: Yes The following is an example of MI.LocationACLExtended with "allow/ deny" rules: Chaudhari, et al. Expires 7 July 2025 [Page 3] Internet-Draft CDNI Client Access Control Metadata January 2025 { "generic-metadata-type": "MI.LocationACLExtended", "generic-metadata-value": { "rules": [ { "locations": [ { "footprint-type": "ipv4cidr", "footprint-value": [ "10.1.1.0/24" ] } ], "action": "allow", "comment": "Support team" }, { "locations": [ { "footprint-type": "asn", "footprint-value": [ "as12345" ] } ], "action": "deny", "comment": "Viewers from Antarctica", "deny-response": { "response-status": "302", "headers": [ { "name": "Location", "value": "https: //example.com" }, { "name": "Content-Type", "value": "text/html" } ] } } ] } } Figure 1 Chaudhari, et al. Expires 7 July 2025 [Page 4] Internet-Draft CDNI Client Access Control Metadata January 2025 3.1. MI.LocationRuleExtended MI.LocationRuleExtended is a subobject of MI.LocationACLExtended that defines pairs of user locations and allow/deny actions. Property: locations * Description: An array of client footprints to match against. These footprints, defined by pairs of MI_footprinttype_ex and MI_footprintvalue_ex respectively, extend the CDNI MI_footprinttype and MI_footprintvalue On top of the four footprint types defined by the CDNI in [RFC8006] (ipv4cidr,ipv6cidr,asn,countrycode), three new types are added:(ipv4range, ipv6range, subdivisioncode) * Type: Array of MI.Footprint objects * Mandatory-to-Specify: Yes Property: action * Description: The action to take place upon a location match. * Type: String, one of (allow | deny) * Mandatory-to-Specify: No. The default is "deny". Property: comment * Description: An optional text comment for user readability and for incorporating in logging. * Type: String * Mandatory-to-Specify: No Property: deny-response * Description: The configuration of the entire response to the client in case of a "Deny" action. * Type: MI.SyntheticResponse * Mandatory-to-Specify: No. The default is { "response-status" : 403 }. Property: match-all-locations Chaudhari, et al. Expires 7 July 2025 [Page 5] Internet-Draft CDNI Client Access Control Metadata January 2025 * Description: The ACL rule match will take place only if all locations In the rule are matched, e.g., both asn and subdivisioncode. * Type: Boolean * Mandatory-to-Specify: No. The default is "False". 4. MI.TimeWindowACLExtended MI.TimeWindowACLExtended is an alternative to the CDNI standard MI.TimeWindow object for implementing time-based access restrictions. It uses ACL rules of type MI.TimeWindowRuleExtended to provide rules for handling denied requests. This object conforms to the specification defined for the behavior of MI.TimeWindowACL and the two are mutually exclusive. Note that MI.TimeWindowACLExtended instances that deny access are handled as terminating objects [I-D.goldstein-processing-stages-metadata] in that processing is terminated upon execution. Property: rules * Description: List of time window allow deny rules. * Type: An array of MI.TimeWindowRuleExtended objects. * Mandatory-to-Specify: Yes The following is an example of MI.TimeWindowACLExtended with "allow" rules: Chaudhari, et al. Expires 7 July 2025 [Page 6] Internet-Draft CDNI Client Access Control Metadata January 2025 { "generic-metadata-type": "MI.TimeWindowACLExtended", "generic-metadata-value": { "rules": [ { "windows": [ { "start": 1670976000, "end": 4294967295 } ], "action": "allow", "comment": "episode 1 launch" } ] } } Figure 2 4.1. MI.TimeWindowRuleExtended Property: windows * Description: Array of time windows to which the rule applies. * Type: Array of MI.TimeWindow objects, as defined in RFC8006], using time values expressed in seconds since the UNIX epoch (i.e., zero hours, zero minutes, zero seconds, on January 1, 1970) Coordinated Universal Time (UTC). * Mandatory-to-Specify: Yes Property: action * Description: The action to take place upon a time window match. * Type: String, one of (allow | deny) * Mandatory-to-Specify: No. The default is "deny". Property: comment * Description: An OPTIONAL text comment for user readability and for incorporating in logging. * Type: String Chaudhari, et al. Expires 7 July 2025 [Page 7] Internet-Draft CDNI Client Access Control Metadata January 2025 * Mandatory-to-Specify: No Property: deny-response * Description: The configuration of the entire response to the client in case of a "Deny" action. * Type: MI.SyntheticResponse * Mandatory-to-Specify: No. The default is { "response-status" : 403 }. 5. MI.CertificateMetadata To allow for secure delivery of content, a downstream CDN (dCDN) MUST be configured to support Hypertext Transfer Protocol Secure (HTTPs). The MI.CertificateMetadata object is used to configure the dCDN's HTTPs attributes, such as TLS certificate credentials, encryption levels, protocols, and ciphers. Property: encryption-level * Description: A reference to an MI.EncryptionLevelMetadata object that specifies the TLS protocols and ciphers to use. * Type: MI.EncryptionLevelMetadata * Mandatory-to-Specify: Yes Property: delegated-credentials * Description: A reference to the certificate's delegated credentials to use when establishing a TLS session with the client. * Type: MI.CertificateCredentialsMetadata * Mandatory-to-Specify: Yes Property: ocsp-enabled * Description: When ocsp-enabled is set to "True", the dCDN will check the revocation status of the configured certificate and include that information with the response to the client. See [RFC6066], section 8 * Type: Boolean Chaudhari, et al. Expires 7 July 2025 [Page 8] Internet-Draft CDNI Client Access Control Metadata January 2025 * Mandatory-to-Specify: No. The default is "False". Property: prefer-server-ciphers * Description: When prefer-server-ciphers is set to "False" (the default), the dCDN will prefer to use cipher suites in the order presented by the client when negotiating the TLS handshake. When prefer-server-ciphers is set to "True", cipher suites will be selected in the order preferred by the dCDN server. * Type: Boolean * Mandatory-to-Specify: No. The default is "False". The following is an example of MI.CertificateMetadata: { "generic-metadata-type": "MI.CertificateMetadata", "generic-metadata-value": { "encryption-level": { "generic-metadata-type": "MI.EncryptionLevelMetadata", "generic-metadata-value": { "encryption-level-name": "modern", "protocols": [ "TLSv1.2", "TLSv1.3" ], "ciphers": [ "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384" ] } }, "delegated-credentials": { "generic-metadata-type": "MI.CertificateCredentialsMetadata", "generic-metadata-value": { "delegated-credentials-type": "MI.ConfDelegatedCredentials", "delegated-credentials-value": { "credentials-location-uri": "https://acme.example.com/cert-123" } } }, "ocsp-enabled": "false", "prefer-server-ciphers": "false" } } Chaudhari, et al. Expires 7 July 2025 [Page 9] Internet-Draft CDNI Client Access Control Metadata January 2025 Figure 3 5.1. MI.EncryptionLevelMetadata MI.EncryptionLevelMetadata is a subobject of MI.CertificateMetadata to support HTTPS content delivery. MI.EncryptionLevelMetadata specifies the protocols and ciphers to be used by the associated MI.CertificateMetadata object. Externalizing MI.EncryptionLevelMetadata from MI.CertificateMetadata allows security policy (TLS protocols and ciphers) to be defined once and referenced by many configurations. Property: encryption-level-name * Description: A descriptive name for the MI.EncryptionLevelMetadata object. This name is expected to be used by operators to reference the MI.EncryptionLevelMetadata configuration. * Type: String * Mandatory-to-Specify: Yes Property: protocols * Description: An array that lists the allowed protocols for the TLS session. * Type: Array of enumerated values. Must be one of: "TLSv1.0", "TLSv1.1", "TLSv1.2" , "TLSv1.3", "SSLv3". * Mandatory-to-Specify: Yes Property: ciphers * Description: An array that lists the allowed ciphers for the TLS session, using cipher suite names defined in [RFC5289] For example, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384. * Type: Array of strings * Mandatory-to-Specify: Yes The following is an example of MI.EncryptionLevelMetadata: Chaudhari, et al. Expires 7 July 2025 [Page 10] Internet-Draft CDNI Client Access Control Metadata January 2025 { "generic-metadata-type": "MI.EncryptionLevelMetadata", "generic-metadata-value": { "encryption-level-name": "modern-version-1.2", "protocols": [ "TLSv1.2", "TLSv1.3" ], "ciphers": [ "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384" ] } } Figure 4 5.2. MI.CertificateCredentialsMetadata MI.CertificateCredentialsMetadata is a subobject of MI.CertificateMetadata and defines the credentials to use when establishing a TLS session between a dCDN and a client. Note: This document does not define any DelegatedCredentials methods. Individual DelegatedCredentials methods are defined separately, e.g., MI.DelegatedCredentials and Acme-Delegations (see CDNI Metadata for Delegated Credentials [ietf-cdni-https-delegation-subcerts] and CDNI extensions for HTTPS delegation [ietf-cdni-interfaces-https-delegation]). Property: delegated-credentials-type * Description: The DelegatedCredentials type (the CDNI Payload Type [RFC7736] of the GenericMetadata object contained in the delegated-credentials-value property). * Type: String * Mandatory-to-Specify: Yes Property: delegated-credentials-value * Description: An object conforming to the specification associated with the DelegatedCredentials type. * Type: GenericMetadata object Chaudhari, et al. Expires 7 July 2025 [Page 11] Internet-Draft CDNI Client Access Control Metadata January 2025 * Mandatory-to-Specify: Yes The following is an example of MI.CertificateCredentialsMetadata: { "generic-metadata-type": "MI.CertificateCredentialsMetadata", "generic-metadata-value": { "delegated-credentials-type": , "delegated-credentials-value": { } } } Figure 5 6. MI.ClientAuthMetadata The MI.ClientAuthMetadata object defines how a dCDN authenticates client requests. Property: delivery-auth * Description: Authentication method to use when granting access to a resource requested by a client. * Type: MI.Auth object, as defined in [RFC8006] section 4.2.7 * Mandatory-to-Specify: Yes Following is a simple example: { "generic-metadata-type": "MI.ClientAuthMetadata", "generic-metadata-value": { "delivery-auth": { "generic-metadata-type": "MI.Auth", "generic-metadata-value": { "auth-type": , "auth-value": {} } } } } Figure 6 Chaudhari, et al. Expires 7 July 2025 [Page 12] Internet-Draft CDNI Client Access Control Metadata January 2025 6.1. MI.CATAuth The MI.CATAuth object defines the configuration for a dCDN to authenticate client requests using the Common Access Token standard. The MI.CATAuth metadata object is used in the auth-value property of the MI.Auth object, as defined in [RFC8006] section 4.2.7, and MAY be applied to to client requests by including it under the MI.ClientAuthMetadata.delivery-auth property. Property: version * Description: Specifies the version of the CAT token. dCDN must reject a token for an unsupported version number. A rejected token results in the client response being defined by the ‘verification-action' property. * Type: Unsigned Integer. A value greater than 0 * Mandatory-to-Specify: No. The default value is 1 Property: token-object-name * Description: Specifies the name of the token object that captures the results of the token verification. The verification result is available for inspection in all processing stages [I-D.goldstein-processing-stages-metadata] * Type: MI.CATTokenObject * Mandatory-to-Specify: No Property: tokens * Description: Specifies the location in the client request where one or more tokens are present and read for evaluation. When multiple tokens are present, the tokens are read and processed per section 4.4 of [CTA-5007] * Type: Array of MI.CATTokenLocator objects * Mandatory-to-Specify: Yes Property: configuration * Description: Specifies the configuration parameters needed to verify a token. * Type: MI.CATTokenConfiguration object Chaudhari, et al. Expires 7 July 2025 [Page 13] Internet-Draft CDNI Client Access Control Metadata January 2025 * Mandatory-to-Specify: Yes Property: verification-action * Description: Specifies how an invalid token OR a valid but rejected token defines the response returned to the client. * Type: MI.CATTokenVerificationAction object * Mandatory-to-Specify: Yes 6.1.1. MI.CATTokenLocator The MI.CATTokenLocator object defines the location to read one or more tokens from the client request. Property: location * Description: Specifies the location name to find one or more tokens in the client request. Valid location names are: - "Authorization-Header" for the Authorization request header - "url-path-style-parameter" per [RFC6570], section 3.2.7. - "query-parameter" per [RFC6570], section 3.2.8 and [RFC6570], section 3.2.9 - "cookie" for HTTP Cookies * Type: String * Mandatory-to-Specify: Yes Property: scheme * Description: The scheme for the Authorization request header that contains the CAT token * Type: String * Mandatory-to-Specify: Yes, only if the location property is ‘Authorization-Header'. Otherwise, his property is ignored. Property: names * Description: The names of the url-path-style parameter, query parameter or HTTP cookies that contain one or more CAT tokens. Chaudhari, et al. Expires 7 July 2025 [Page 14] Internet-Draft CDNI Client Access Control Metadata January 2025 * Type: String * Mandatory-to-Specify: Yes, only if the location property is either ‘url-path-style-parameter', ‘query-parameter', or ‘cookie'. Otherwise, his property is ignored. 6.1.2. MI.CATTokenConfiguration The MI.TokenConfiguration object defines the configuration parameters for verifying a CAT token. Property: integrity-algo * Description: The algorithm used for integrity protection of the CAT token. The minimum set of values to support are "hs256" (see [RFC9053], section 3.1)and "es256" (see [RFC9053], section 2.1) * Type: String * Mandatory-to-Specify: Yes Property: integrity-algo-key * Description: The value of the key used for integrity protection of the CAT token. * Type: MI.SecretValue object that can either contain the hex version of the key in the clear (not recommended) or as a reference in an external key store. See the Protected Secrets Metadata standard [I-D.ietf-cdni-protected-secrets-metadata] for more details. * Mandatory-to-Specify: Yes. Property: encryption-algo * Description: The algorithm used in the ‘enc' claim. The minimum value to support is "ecdh-ss+a128kw" (see [RFC9053], section 6.4.1). * Type: MI.SecretValue object that can either contain the hex version of the symmetric key in the clear (not recommended) or as a reference in an external key store. See the Protected Secrets Metadata standard [I-D.ietf-cdni-protected-secrets-metadata] for more details. * Mandatory-to-Specify: Yes Chaudhari, et al. Expires 7 July 2025 [Page 15] Internet-Draft CDNI Client Access Control Metadata January 2025 Property: encryption-algo-key * Description: The value of the key used for encryption in the ‘enc' claim. * Type: MI.SecretValue object that can either contain the hex version of the key in the clear (not recommended) or as a reference in an external key store. See the Protected Secrets Metadata standard [I-D.ietf-cdni-protected-secrets-metadata] for more details. * Mandatory-to-Specify: Yes 6.1.3. MI.CATTokenVerificationAction The MI.CATTokenVerificationAction object defines how a client response is created for an invalid OR valid but rejected token. Property: rejected-token-action * Description: An enumeration of ways in which a client response is created. Valid values are: - "fail" for returning a HTTP 403 response. - "allow" for ignoring the result of token validation, as if the token was not present. This typically would result in serving a HTTP 200 for the requested resource. - "token-defined" for constructing the client response per the parameters defined within the token. For a valid but rejected CAT token, the ‘catif' claim is used to construct the client response. * Type: String * Mandatory-to-Specify: Yes Property: token-defined-response * Description: Specifies how the token values are used to create the client response for an invalid OR valid but rejected token. This property gets used when the value of ‘rejected-token-action' property is ‘token-defined'. Use of this property for any other value of ‘rejected-token-action' is an invalid configuration. * Type: MI.CATTokenDefinedResponse object Chaudhari, et al. Expires 7 July 2025 [Page 16] Internet-Draft CDNI Client Access Control Metadata January 2025 * Mandatory-to-Specify: Yes, if ‘rejected-token-action' property is ‘token-defined' 6.1.4. MI.CATTokenDefinedResponse The MI.CATTokenDefinedResponse object defines how a client response is constructed using the token's available ‘catif' claim or some fallback. Property: fallback-response * Description: An enumeration defining a fallback response when the token defined values are inapplicable. Valid values are: - "fail" for returning a HTTP 403 response. - "allow" for ignoring the result of token validation, as if it was not present. o A missing token. o An invalid CAT token. o A valid but rejected CAT token with: For CAT, this fallback-response will get used under the following conditions: * Type: String * Mandatory-to-Specify: No. Default value is ‘fail'. Property: catif * Description: Specifies the configuration for processing the ‘catif' claim to construct the client response for a valid but rejected CAT token. * Type: MI.CATIF object * Mandatory-to-Specify: Yes, when the rejected-token-action property for the MI.CATTokenVerificationAction object is set to ‘token- defined' Chaudhari, et al. Expires 7 July 2025 [Page 17] Internet-Draft CDNI Client Access Control Metadata January 2025 6.1.5. MI.CATIF The MI.CATIF object specifies the processing of the ‘catif' claim to construct the client response for a valid but rejected CAT token. See Section 4.9.1 of [CTA-5007] Property: response-header-names-force-add * Description: For specific named headers of a rejected claim within the ‘catif' claim, these will be added to the client response, even if headers with same names were already going to be added to the response via other means. * Type: Array of Strings * Mandatory-to-Specify: No. If not specified, header names of a rejected claim within ‘catif' claim will be skipped in the client response if similarly named headers were to be added via other means. 6.1.6. MI.CATTokenObject The MI.CATTokenObject object defines a read-only object that captures the results of the token verification. The verification result is available for inspection in all processing stages [I-D.goldstein-processing-stages-metadata] Property: status * Description: Captures the verification status of the CAT token via the following string values: - ‘success' - ‘failure' * Type: String Property: token * Description: The string literal of the token in the request. * Type: String Property: status_details Chaudhari, et al. Expires 7 July 2025 [Page 18] Internet-Draft CDNI Client Access Control Metadata January 2025 * Description: Specifies details about the token verification result when the token verification ‘status' is ‘failure', else it is an empty string. This string contains one of the following values: - Empty string for a missing token. - "Invalid CAT" when a token cannot be parsed, per [RFC8392], Section 7.2 - "Invalid Claim: " * Type: String The following example shows use of the CAT scheme as the authentication mechanism for client requests at the dCDN. Some notable points are: [ { "generic-metadata-type": "MI.ClientAuthMetadata", "generic-metadata-value": { "delivery-auth": { "generic-metadata-type": "MI.Auth", "generic-metadata-value": { "auth-type": "MI.CommonAccessToken", "auth-value": { "version": 1, "token-object-name": "cat_1", "tokens": [ { "location": "Authorization-Header", "scheme": "CAT" }, { "location": "url-path-style-parameter", "names": [ "catv1" ] }, { "location": "query-parameter", "names": [ "catv1,catv2" ] }, { "location": "cookie", Chaudhari, et al. Expires 7 July 2025 [Page 19] Internet-Draft CDNI Client Access Control Metadata January 2025 "names": [ "catv1" ] } ], "configuration": { "integrity-algo": "hs256", "integrity-algo-key": { "secret-store-id": "cat-key-vault", "secret-path": "/client-auth/cat/keys/integrity/dplus" }, "encryption-algo": "ecdh-ss+a128kw", "encryption-algo-key": { "secret-store-id": "cat-key-vault", "secret-path": "/client-auth/cat/keys/enc/dplus" } }, "verification-action": { "rejected-token-action": "token-defined", "token-defined-response": { "fallback-response": "fail", "catif": { "response-header-names-force-add": [ "x-cat-reason", "x-uCDN-name" ] } } } } } } } }, { "generic-metadata-type": "MI.ProcessingStages", "generic-metadata-value": { "client-response": [ { "match": "var.cat_1 and var.cat_1.status == 'failure'", "stage-metadata": { "response-transform": { "header-transform": { "add": [ { "name": "x-auth-error", "value": "'Invalid token' . var.cat_1.token . 'failed verification. Error:' . Chaudhari, et al. Expires 7 July 2025 [Page 20] Internet-Draft CDNI Client Access Control Metadata January 2025 var.cat_1.status_details", "value-is-expression": true } ] } } } } ] } } ] Figure 7 7. Security Considerations The FCI and MI objects defined in the this document are transferred via the interfaces defined in CDNI [RFC8006] which describes how to secure these interfaces by protecting integrity and confidentiality while ensuring the authenticity of the dCDN and uCDN. 8. Iana Considerations 8.1. CDNI Payload Types This document requests the registration of the following entries under the "CDNI Payload Types" registry hosted by IANA: Chaudhari, et al. Expires 7 July 2025 [Page 21] Internet-Draft CDNI Client Access Control Metadata January 2025 +===================================+===============+ | Payload Type | Specification | +===================================+===============+ | MI.LocationACLExtended | RFCthis | +-----------------------------------+---------------+ | MI.LocationRuleExtended | RFCthis | +-----------------------------------+---------------+ | MI.TimeWindowACLExtended | RFCthis | +-----------------------------------+---------------+ | MI.TimeWindowRuleExtended | RFCthis | +-----------------------------------+---------------+ | MI.CertificateMetadata | RFCthis | +-----------------------------------+---------------+ | MI.EncryptionLevelMetadata | RFCthis | +-----------------------------------+---------------+ | MI.CertificateCredentialsMetadata | RFCthis | +-----------------------------------+---------------+ | MI.ClientAuthMetadata | RFCthis | +-----------------------------------+---------------+ | MI.CATAuth | RFCthis | +-----------------------------------+---------------+ | MI.CATTokenLocator | RFCthis | +-----------------------------------+---------------+ | MI.CATTokenConfiguration | RFCthis | +-----------------------------------+---------------+ | MI.CATTokenVerificationAction | RFCthis | +-----------------------------------+---------------+ | MI.CATTokenDefinedResponse | RFCthis | +-----------------------------------+---------------+ | MI.CATIF | RFCthis | +-----------------------------------+---------------+ | MI.CATTokenObject | RFCthis | +-----------------------------------+---------------+ Table 1 8.2. "CDNI Metadata Protocol Types" Registry The Internet Assigned Numbers Authority (IANA) "CDNI Metadata Protocol Types" registry in the "Content Delivery Network Interconnection Parameters" registry group defines the valid Protocol object values used by the ProtocolACL object defined in [RFC8006] The following table defines the new protocol values needed for the ProtocolACL object defined in [RFC8006] such that CDN delivery restrictions can be configured for these protocols. Chaudhari, et al. Expires 7 July 2025 [Page 22] Internet-Draft CDNI Client Access Control Metadata January 2025 +==========+====================+===============+===============+ | Protocol | Description | Type | Protocol | | Type | | Specification | Specification | +==========+====================+===============+===============+ | http/2 | Hypertext Transfer | RFCthis | [RFC9113] | | | Protocol Version 2 | | | | | (unencrypted) | | | +----------+--------------------+---------------+---------------+ | https/2 | Hypertext Transfer | RFCthis | [RFC9113] | | | Protocol Version 2 | | | | | (encrypted) | | | +----------+--------------------+---------------+---------------+ | h2 | Hypertext Transfer | RFCthis | [RFC9113] | | | Protocol Version | | | | | 2, alternate name | | | +----------+--------------------+---------------+---------------+ | https/3 | Hypertext Transfer | RFCthis | [RFC9114] | | | Protocol Version 3 | | | +----------+--------------------+---------------+---------------+ | h3 | Hypertext Transfer | RFCthis | [RFC9114] | | | Protocol Version | | | | | 3, alternate name | | | +----------+--------------------+---------------+---------------+ Table 2 9. Acknowledgements The authors would like to express their gratitude to the members of the Streaming Video Technology Alliance [SVTA] Open Caching Working Group for their contributions and guidance. Particulary the following people contribute in one or other way to the content of this draft: * Guillaume Bichot - Broadpeak * Christoph Neumann - Broadpeak * Chris Lemmons - Comcast * Rajeev RK - picoNETS * Shmuel Asafi - Qwilt * Yoav Gressel - Qwilt * Nir Sopher - Qwilt Chaudhari, et al. Expires 7 July 2025 [Page 23] Internet-Draft CDNI Client Access Control Metadata January 2025 * Alfonso Siloniz - Telefonica * Ben Rosenblum - Vecima 10. Normative References [CTA-5007] CTA, "Web Application Video Ecosystem - Common Access Token (CTA-5007-A)", . [I-D.ietf-cdni-protected-secrets-metadata] Rosenblum, B., "CDNI Protected Secrets Metadata", Work in Progress, Internet-Draft, draft-ietf-cdni-protected- secrets-metadata-02, 7 July 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, DOI 10.17487/RFC5289, August 2008, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, . [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, . Chaudhari, et al. Expires 7 July 2025 [Page 24] Internet-Draft CDNI Client Access Control Metadata January 2025 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, . [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . 11. Informative References [I-D.goldstein-processing-stages-metadata] Goldstein, G., Power, W., and A. Warshavsky, "CDNI Processing Stages Metadata", Work in Progress, Internet- Draft, draft-goldstein-processing-stages-metadata-02, 3 September 2024, . [ietf-cdni-https-delegation-subcerts] IETF, "CDNI Metadata for Delegated Credentials", . [ietf-cdni-interfaces-https-delegation] IETF, "CDNI extensions for HTTPS delegation", . [SVTA] SVTA, "Streaming Video Technology Alliance Home Page", . Authors' Addresses Pankaj Chaudhari Disney United States of America Email: pankaj.chaudhari.pub@gmail.com Glenn Goldstein Lumen Technologies United States of America Chaudhari, et al. Expires 7 July 2025 [Page 25] Internet-Draft CDNI Client Access Control Metadata January 2025 Email: glenng1215@gmail.com Will Power Lumen Technologies United States of America Email: wrpower@gmail.com Arnon Warshavsky Qwilt Israel Email: arnon@qwilt.com Chaudhari, et al. Expires 7 July 2025 [Page 26]