Internet-Draft CDNI Client Access Control Metadata July 2024
Chaudhari, et al. Expires 23 January 2025 [Page]
Workgroup:
Content Delivery Networks Interconnection
Published:
Intended Status:
Standards Track
Expires:
Authors:
P. Chaudhari
Disney
G. Goldstein
Lumen Technologies
W. Power
Lumen Technologies
A. Warshavsky
Qwilt

CDNI Client Access Control Metadata

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.

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 23 January 2025.

Table of Contents

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

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 [SVTA2032] in that processing is terminated upon execution.

Property: rules

The following is an example of MI.LocationACLExtended with "allow/deny" rules:

{
  "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: //svta.org"
            },
            {
              "name": "Content-Type",
              "value": "text/html"
            }
          ]
        }
      }
    ]
  }
}
Figure 1

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

  • 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 [SVTA2032] in that processing is terminated upon execution.

Property: rules

The following is an example of MI.TimeWindowACLExtended with "allow" rules:

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

  • 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

Property: delegated-credentials

Property: ocsp-enabled

Property: prefer-server-ciphers

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": [
          "ECDHE-ECDSA-AES128-GCM-SHA256",
          "ECDHE-RSA-AES128-GCM-SHA256",
          "ECDHE-ECDSA-AES256-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"
  }
}
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.

  • Type: Array of strings

  • Mandatory-to-Specify: Yes

The following is an example of MI.EncryptionLevelMetadata:

{
  "generic-metadata-type": "MI.EncryptionLevelMetadata",
  "generic-metadata-value": {
    "encryption-level-name": "modern-version-1.2",
    "protocols": [
      "TLSv1.2",
      "TLSv1.3"
    ],
    "ciphers": [
      "ECDHE-ECDSA-AES128-GCM-SHA256",
      "ECDHE-RSA-AES128-GCM-SHA256",
      "ECDHE-ECDSA-AES256-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

  • Mandatory-to-Specify: Yes

The following is an example of MI.CertificateCredentialsMetadata:

{
  "generic-metadata-type": "MI.CertificateCredentialsMetadata",
  "generic-metadata-value": {
    "delegated-credentials-type":
      <CDNI Payload Type of this DelegatedCredentials object>,
    "delegated-credentials-value": {
      <Properties of this DelegatedCredentials object>
    }
  }
}
Figure 5

6. MI.ClientAuthMetadata

The MI.ClientAuthMetadata object defines how a dCDN authenticates client requests.

Property: delivery-auth

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": <CDNI Payload Type of this Auth object>,
        "auth-value": {}
      }
    }
  }
}
Figure 6

7. Security Considerations

The FCI and MI objects defined in the present document are transferred via the interfaces defined in CDNI [RFC8006] which describes how to secure these interfaces 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:

Table 1
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

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.

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

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 guidance / contribution / reviews ...)

Particulary the following people contribute in one or other way to the content of this draft:

10. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6066]
Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, , <https://www.rfc-editor.org/info/rfc6066>.
[RFC8006]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, , <https://www.rfc-editor.org/info/rfc8006>.
[RFC9113]
Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, , <https://www.rfc-editor.org/info/rfc9113>.
[RFC9114]
Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, , <https://www.rfc-editor.org/info/rfc9114>.

11. Informative References

[ietf-cdni-https-delegation-subcerts]
IETF, "CDNI Metadata for Delegated Credentials", <https://datatracker.ietf.org/doc/draft-ietf-cdni-https-delegation-subcerts/>.
[ietf-cdni-interfaces-https-delegation]
IETF, "CDNI extensions for HTTPS delegation", <https://datatracker.ietf.org/doc/html/draft-ietf-cdni-interfaces-https-delegation>.
[RFC7736]
Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, , <https://www.rfc-editor.org/info/rfc7736>.
[SVTA]
SVTA, "Streaming Video Technology Alliance Home Page", <https://www.svta.org>.
[SVTA2032]
SVTA, "Processing Stages Metadata Specification", <https://svta.org/documents/SVTA2032>.

Authors' Addresses

Pankaj Chaudhari
Disney
United States of America
Glenn Goldstein
Lumen Technologies
United States of America
Will Power
Lumen Technologies
United States of America
Arnon Warshavsky
Qwilt
Israel