CDNI Client Access Control Metadata

Introduction The 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 required TLS certificates and encryption levels for content access.

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 .

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

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

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".

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

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
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 }.

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 , section 8
Type: Boolean
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:

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.
Type: Array of strings
Mandatory-to-Specify: Yes

The following is an example of MI.EncryptionLevelMetadata:

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 and CDNI extensions for HTTPS delegation ). Property: delegated-credentials-type

Description: The DelegatedCredentials type (the CDNI Payload Type 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
Mandatory-to-Specify: Yes

The following is an example of MI.CertificateCredentialsMetadata:

, "delegated-credentials-value": { } } }]]>

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 section 4.2.7
Mandatory-to-Specify: Yes

Following is a simple example:

, "auth-value": {} } } } }]]>

The FCI and MI objects defined in the present document are transferred via the interfaces defined in CDNI which describes how to secure these interfaces protecting integrity and confidentiality while ensuring the authenticity of the dCDN and uCDN.

Iana Considerations

CDNI Payload Types This document requests the registration of the following entries under the "CDNI Payload Types" registry hosted by IANA:

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

"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 The following table defines the new protocol values needed for the ProtocolACL object defined in such that CDN delivery restrictions can be configured for these protocols.

Protocol Type	Description	Type Specification
http/2	Hypertext Transfer Protocol Version 2 (unencrypted)	RFCthis
https/2	Hypertext Transfer Protocol Version 2 (encrypted)	RFCthis
h2	Hypertext Transfer Protocol Version 2, alternate name	RFCthis
https/3	Hypertext Transfer Protocol Version 3	RFCthis
h3	Hypertext Transfer Protocol Version 3, alternate name	RFCthis

The authors would like to express their gratitude to the members of the Streaming Video Technology Alliance Open Caching Working Group for their guidance / contribution / reviews ...) 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
Alfonso Siloniz - Telefonica
Ben Rosenblum - Vecima