CDNI Client Access Control Metadata

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 18 September 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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

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¶

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

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

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¶

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

{
  "generic-metadata-type": "MI.TimeWindowACLExtended",
  "generic-metadata-value": {
    "rules": [
      {
        "windows": [
          {
            "start": 1670976000,
            "end": 4294967295
          }
        ],
        "action": "allow",
        "comment": "episode 1 launch"
      }
    ]
  }
}

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¶

• 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": [
          "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"
  }
}

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

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

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

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

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

• 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¶

Authors' Addresses