CDNI Client Access Control Metadata
draft-chaudhari-client-access-control-metadata-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Pankaj Chaudhari , Glenn Goldstein , Will Power , Arnon Warshavsky | ||
| Last updated | 2024-03-17 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chaudhari-client-access-control-metadata-01
Content Delivery Networks Interconnection P. Chaudhari
Internet-Draft Disney
Intended status: Standards Track G. Goldstein
Expires: 18 September 2024 W. Power
Lumen Technologies
A. Warshavsky
Qwilt
17 March 2024
CDNI Client Access Control Metadata
draft-chaudhari-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.
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
Chaudhari, et al. Expires 18 September 2024 [Page 1]
Internet-Draft CDNI Client Access Control Metadata March 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
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
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Iana Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 13
8.2. "CDNI Metadata Protocol Types" Registry . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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].
Chaudhari, et al. Expires 18 September 2024 [Page 2]
Internet-Draft CDNI Client Access Control Metadata March 2024
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:
Chaudhari, et al. Expires 18 September 2024 [Page 3]
Internet-Draft CDNI Client Access Control Metadata March 2024
{
"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
Chaudhari, et al. Expires 18 September 2024 [Page 4]
Internet-Draft CDNI Client Access Control Metadata March 2024
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 18 September 2024 [Page 5]
Internet-Draft CDNI Client Access Control Metadata March 2024
* 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
* 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 18 September 2024 [Page 6]
Internet-Draft CDNI Client Access Control Metadata March 2024
{
"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 18 September 2024 [Page 7]
Internet-Draft CDNI Client Access Control Metadata March 2024
* 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 18 September 2024 [Page 8]
Internet-Draft CDNI Client Access Control Metadata March 2024
* 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"
}
}
Chaudhari, et al. Expires 18 September 2024 [Page 9]
Internet-Draft CDNI Client Access Control Metadata March 2024
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:
Chaudhari, et al. Expires 18 September 2024 [Page 10]
Internet-Draft CDNI Client Access Control Metadata March 2024
{
"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
Chaudhari, et al. Expires 18 September 2024 [Page 11]
Internet-Draft CDNI Client Access Control Metadata March 2024
* 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
* 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": {}
}
}
}
}
Figure 6
Chaudhari, et al. Expires 18 September 2024 [Page 12]
Internet-Draft CDNI Client Access Control Metadata March 2024
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:
+===================================+===============+
| 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 |
+-----------------------------------+---------------+
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 18 September 2024 [Page 13]
Internet-Draft CDNI Client Access Control Metadata March 2024
+==========+====================+===============+===============+
| 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 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
Chaudhari, et al. Expires 18 September 2024 [Page 14]
Internet-Draft CDNI Client Access Control Metadata March 2024
* Alfonso Siloniz - Telefonica
* Ben Rosenblum - Vecima
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<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, December 2016,
<https://www.rfc-editor.org/info/rfc8006>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <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,
December 2015, <https://www.rfc-editor.org/info/rfc7736>.
[SVTA] SVTA, "Streaming Video Technology Alliance Home Page",
<https://www.svta.org>.
Chaudhari, et al. Expires 18 September 2024 [Page 15]
Internet-Draft CDNI Client Access Control Metadata March 2024
[SVTA2032] SVTA, "Processing Stages Metadata Specification",
<https://svta.org/documents/SVTA2032>.
Authors' Addresses
Pankaj Chaudhari
Disney
United States of America
Email: pankaj.chaudhari.pub@gmail.com
Glenn Goldstein
Lumen Technologies
United States of America
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 18 September 2024 [Page 16]