Content Delivery Network Interconnection (CDNI) Protected Secrets Metadata

Introduction Certain objects in both the CDNI Footprint and Capabilities Interface (FCI) and Metadata Interface (MI) encapsulate sensitive values, such as credentials and access keys, which should not necessarily be accessible to all parties that can view the advertisement and configuration payloads. This document defines two mechanisms to enclose secret values in the context of other FCI and MI objects that may only be viewed by the intended recipients: embedded secrets encrypted using a certificate supplied by a counterparty, and secrets stored in an external service and referenced by a path. Either side can share secrets, and the functionality is the same for both sides, so the FCI capabilities are wrappers around the MI objects, similar to how FCI footprints (used in ) reuse the MI.Footprint and registry defined in . The public certificate for the downstream content delivery network (dCDN) is shared via FCI.SecretCertificate and the certificate for the upstream content delivery network (uCDN) is shared via MI.SecretCertificate. Overview of the workflow for embedded secrets:

uCDN retrieves an advertisement with FCI.SecretStore and FCI.SecretCertificate. The uCDN has not yet provided a certificate, so the advertisement contains no secret values.
uCDN provides configuration including MI.SecretStore, MI.SecretCertificate and MI.SecretValue with values encrypted using the dCDN certificate.
uCDN receives an updated advertisement with secret values encrypted using the uCDN certificate.

Bi-directional Protected Secrets Workflow, Embedded Store | | | |---- | | | Encrypt secrets using provided FCI.SecretCertificate | |<--- | | | | Provide MI.SecretStore, MI.SecretCertificate and | | MI.SecretValue with encrypted secrets | |--------------------------------------------------------------->| | | | ----| | Encrypt secrets using provided MI.SecretCertificate | | | --->| | | | Retrieve FCI objects with encrypted MI.SecretValue | |--------------------------------------------------------------->| | | +----+ +----+ |uCDN| |dCDN| +----+ +----+ ]]> Detailed workflow examples, including modes that reference external services or contain secret values in cleartext, are available in the Workflow Examples section. The sender of a secret validates the recipient's certificate before it uses the certificate ().

Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Long lines in examples are folded as described in .

Metadata Objects MI.SecretStore and MI.SecretCertificate are GenericMetadata objects (). An MI.SecretValue is the value of a property of another MI or FCI object.

MI.SecretStore MI.SecretStore instructs the counterparty how to dereference the value of any MI.SecretValue objects linked to the store. For embedded stores, MI.SecretStore identifies the certificate used for encrypting the values. For external stores, MI.SecretStore specifies the endpoint that is used with the secret-path property of MI.SecretValue to obtain the secret. Additional store types can be registered as CDNI Payload Types . The specification of a store type defines its secret-store-config object and how linked MI.SecretValue objects are dereferenced. A recipient that does not support the secret-store-type of an MI.SecretStore MUST treat MI.SecretValue objects linked to that store as unavailable. Property: secret-store-id

Description: An identifier for this store configuration that is referenced from linked MI.SecretValue objects. This value MUST be unique within the context of the metadata objects and the FCI advertisement.
Type: String
Mandatory-to-Specify: Yes

Property: secret-store-type

Description: The CDNI Payload Type of the object contained in the secret-store-config property.
Type: String
Mandatory-to-Specify: Yes

Property: secret-store-config

Description: An object conforming to the specification associated with the secret-store-type.
Type: Object
Mandatory-to-Specify: Yes

MI.SecretStoreTypeEmbedded MI.SecretStoreTypeEmbedded contains the configuration necessary to decrypt embedded secrets in MI.SecretValue. The encrypted message format is Cryptographic Message Syntax (CMS) as defined in . Messages MUST be CMS type "AuthEnvelopedData" . Messages MUST be base64-encoded () DER CMS ContentInfo structures. Implementations MUST support AES-128-GCM and RSAES-OAEP . RSA keys MUST be at least 2048 bits long. Other algorithms MAY be used by agreement between the parties. A cleartext format is also defined for testing purposes. In this case, the value of an MI.SecretValue object's secret-value property is the cleartext secret. It is NOT RECOMMENDED to use the cleartext format in production environments. Property: format

Description: The format of the embedded secret. Other formats require a new store type ().
Type: String. Either "cms" or "cleartext".
Mandatory-to-Specify: Yes

Property: secret-certificate-id

Description: The ID of the MI.SecretCertificate used to encrypt secret messages linked with this store configuration.
Type: String
Mandatory-to-Specify: Yes when format is "cms" and a linked MI.SecretValue contains secret-value, otherwise No.

The following is an example of MI.SecretStore with an MI.SecretStoreTypeEmbedded configuration using CMS:

MI.SecretStoreTypeExternal MI.SecretStoreTypeExternal contains the configuration necessary to reference secrets stored in an external key/value secret store. MI.SecretValue objects reference secrets stored in the external store using the secret-path property to identify the path and property key. See the MI.SecretValue section for details. This document does not define the protocol to retrieve a secret from an external store or how the recipient authenticates to the store. The parties agree on both. Store types that define them can be registered (). Property: endpoint

Description: The base URL of the external secret store. The URL MUST use the "https" scheme ().
Type: String
Mandatory-to-Specify: Yes

The following is an example of MI.SecretStore with an MI.SecretStoreTypeExternal configuration:

MI.SecretValue MI.SecretValue may be used in any FCI or MI object where sensitive data must be transmitted only to intended recipients. An MI.SecretValue MUST NOT contain both secret-value and secret-path. With MI.SecretStoreTypeEmbedded, an MI.SecretValue without secret-value indicates that the secret is not available, for example before the recipient has provided a certificate or after it has removed its certificate. The recipient MUST treat such an MI.SecretValue as unavailable. Property: secret-store-id

Description: The ID of MI.SecretStore that contains the configuration defining how to decrypt or access the referenced secret.
Type: String
Mandatory-to-Specify: Yes

Property: secret-value

Description: Used only for embedded secrets. Format is one of the following:
- The cleartext string
- The base64-encoded DER CMS message, as specified in .
Type: String
Mandatory-to-Specify: No

Property: secret-path

Description: Used only for external store secrets, the path to the secret, including the key of the particular property to access as the last path parameter.
Type: String
Mandatory-to-Specify: Yes when the store type is MI.SecretStoreTypeExternal, No when it is MI.SecretStoreTypeEmbedded.

Property: timeout

Description: If this property is present and the elapsed time since last retrieving the secret value has exceeded this timeout, any cached instance of this secret value MUST be discarded and fetched again from the associated secret store. If this property is absent, the sender sets no limit on how long the recipient caches the secret value. This value has no effect when using an embedded store.
Type: Integer duration in seconds.
Mandatory-to-Specify: No

The following is an example of MI.SecretValue specifying an embedded value:

The following is an example of MI.SecretValue for an external store:

MI.SecretCertificate MI.SecretCertificate is used to share an X.509 certificate to be utilized for encrypting embedded secret messages. Before the sender of a secret uses a certificate to encrypt the secret, it MUST validate the certificate in one of these ways:

Certification path validation () to a trust anchor agreed between the parties, and a check that the certificate identifies the counterparty.
Comparison with a certificate or public key that the parties exchanged out of band.

The certificate-value property contains one certificate; the parties agree how the sender obtains any intermediate certificates. Property: certificate-id

Description: An identifier for this MI.SecretCertificate that is referenced by the secret-certificate-id property of a counterparty's MI.SecretStoreTypeEmbedded configuration. This value MUST be unique within the context of the metadata objects and the FCI advertisement.
Type: String
Mandatory-to-Specify: Yes

Property: certificate-value

Description: The base64-encoded () DER certificate.
Type: String
Mandatory-to-Specify: Yes

The following is an example of MI.SecretCertificate:

Capabilities Objects These objects are FCI capability objects () whose capability-value is the corresponding MI object defined in .

FCI.SecretStore FCI.SecretStore instructs the uCDN how to dereference the value of any MI.SecretValue objects linked to the store from other FCI objects via an embedded MI.SecretStore object. For further details, see the MI.SecretStore section. The following is an example of FCI.SecretStore before the uCDN has provided a certificate (step 1 in ):

FCI.SecretCertificate FCI.SecretCertificate is used to share an X.509 certificate to be utilized for encrypting embedded secret messages via an embedded MI.SecretCertificate object. For further details, see the MI.SecretCertificate section. The following is an example of FCI.SecretCertificate:

Workflow Examples The facilities in this document can be used for simple and bidirectional exchange of secret values between a uCDN and a dCDN. The embedded model provides for a secret exchange without reference to out-of-band services, while the external store support allows for reference to secrets stored in an external key/value store. Other secret distribution methods can be supported by defining new store types (). Provided below are workflow examples for uCDN -> dCDN and dCDN -> uCDN exchanges of secret values. In the embedded model, the RECOMMENDED procedure for key rollover, for example before a certificate expires, is as follows:

The recipient of a secret provides an MI.SecretCertificate with the same certificate-id and a new certificate-value, and keeps the previous private key.
The sender of the secret SHOULD then encrypt the linked secrets with the new certificate and update the secret-value properties.
The recipient can discard the previous private key when no secret-value that it holds uses it. The RecipientInfo of each CMS message identifies the certificate used ().

To revoke a certificate, for example after a key compromise, the recipient removes the MI.SecretCertificate. The sender SHOULD then remove the secret-value property from the linked MI.SecretValue objects, as in the initial state before any certificate has been provided.

Workflow: dCDN -> uCDN Embedded

The dCDN advertises FCI.SecretStore with a secret-store-type of MI.SecretStoreTypeEmbedded; other FCI objects may contain MI.SecretValue objects that reference the secret-store-id. MI.SecretValue objects do not presently contain a secret-value property.
The uCDN pushes the MI configuration with an MI.SecretCertificate.
The dCDN updates the advertised FCI.SecretStore with a secret-certificate-id property that references the uCDN MI.SecretCertificate provided in step 2; any MI.SecretValue objects in other FCI objects now contain a secret-value property with the CMS encrypted secret.

dCDN -> uCDN Workflow, Embedded Store | | | | Provide MI.SecretCertificate | |--------------------------------------------------------------->| | | | ----| | Encrypt secrets using provided MI.SecretCertificate | | | --->| | | | Retrieve FCI objects with encrypted MI.SecretValue | |--------------------------------------------------------------->| | | +----+ +----+ |uCDN| |dCDN| +----+ +----+ ]]>

Workflow: uCDN -> dCDN Embedded

The dCDN advertises an FCI.SecretCertificate.
The uCDN pushes the MI configuration containing MI.SecretStore with a secret-store-type of MI.SecretStoreTypeEmbedded and a secret-certificate-id referencing the FCI.SecretCertificate advertised by the dCDN. Other MI objects may contain MI.SecretValue objects with a secret-value property containing the CMS encrypted secret.

uCDN -> dCDN Workflow, Embedded Store | | | |---- | | | Encrypt secrets using provided FCI.SecretCertificate | |<--- | | | | Provide MI.SecretStore and MI.SecretValue objects | |--------------------------------------------------------------->| | | +----+ +----+ |uCDN| |dCDN| +----+ +----+ ]]>

Workflow: Embedded Cleartext (uCDN and dCDN)

An MI.SecretStore has an MI.SecretStoreTypeEmbedded configuration with format "cleartext".
Any MI.SecretValue objects that reference the cleartext store contain a secret-value property with the unencrypted secret.

Embedded Cleartext Workflow | | | | Provide MI.SecretStore ("cleartext") and MI.SecretValue | |--------------------------------------------------------------->| | | +----+ +----+ |uCDN| |dCDN| +----+ +----+ ]]>

Workflow: dCDN -> uCDN External Store The dCDN advertises an FCI.SecretStore with an appropriate configuration for accessing an external secret store accessible to the uCDN. Other FCI objects may contain MI.SecretValue objects that reference the FCI.SecretStore and a secret-path property specifying the secret to retrieve.

dCDN -> uCDN Workflow, External Store | | | | | | Retrieve secrets using path provided | | | in MI.SecretValue objects | | |----------------------------------------------------|---------->| | | | +----+ +----+ +-----+ |uCDN| |dCDN| |Store| +----+ +----+ +-----+ ]]>

Workflow: uCDN -> dCDN External Store The uCDN provides the MI configuration, including an MI.SecretStore with appropriate configuration for accessing an external secret store accessible to the dCDN. Other MI objects may contain MI.SecretValue objects that reference the MI.SecretStore and a secret-path property specifying the secret to retrieve.

Security Considerations The objects defined in this document are carried in the FCI and the MI, and the security considerations of and apply. Both require authentication of the peers and protection of the integrity and confidentiality of the objects. An attacker that can insert, delete, modify or replay MI or FCI objects can, for example, add its own secrets, replace a certificate or a store endpoint, remove a secret, or bring back a replaced secret. As assumes, the parties have a preexisting relationship; misuse of a secret by a party authorized to hold it is out of scope. finds no apparent need for further object-level security in bilateral CDNI relationships. The confidentiality of secrets is an exception: MI and FCI payloads are visible to more systems and people than the component that uses a secret, for example when they are stored, logged or shown in management tools. With the "cms" format, only the holder of the recipient's private key can read a secret; with an external store, the secret is not in the payload. AuthEnvelopedData protects the confidentiality and integrity of a secret but does not authenticate the sender (): anyone who has the recipient's certificate can create a valid message. The security considerations of , , and apply. The "cleartext" format provides no protection beyond that of the interfaces. An attacker that replaces the certificate in an MI.SecretCertificate or FCI.SecretCertificate with its own receives every secret later encrypted to it; the validation in protects against this. Removing a certificate () does not protect secrets already encrypted to it, so after a compromise of the recipient's private key the sender SHOULD replace the affected secrets with new values. For external stores, the endpoint is an "https" URL (), so the recipient verifies the identity of the store (); the parties agree how the recipient authenticates to the store. The sender supplies the endpoint, so a recipient can be made to send requests, possibly with its store credentials, to other systems, including systems in its own network. Recipients SHOULD send requests only to endpoints agreed between the parties. The availability of a secret in an external store depends on the store; a longer timeout () reduces this dependence but keeps a replaced secret in use for longer. A recipient that uses an empty or default value in place of an unavailable secret can remove the protection that the secret provides. Implementations SHOULD NOT log secrets.

IANA Considerations

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

Payload Type	Specification
MI.SecretStore	RFCthis
MI.SecretStoreTypeEmbedded	RFCthis
MI.SecretStoreTypeExternal	RFCthis
MI.SecretValue	RFCthis
MI.SecretCertificate	RFCthis
FCI.SecretStore	RFCthis
FCI.SecretCertificate	RFCthis

[RFC Editor: Please replace RFCthis with the published RFC number for this document.]

Acknowledgements The authors would like to express their gratitude to the members of the Streaming Video Technology Alliance Open Caching Working Group for their contributions and guidance. The following people contributed to this document:

Chris Lemmons (Comcast)
Rajeev RK (picoNETS)
Yoav Gressel (Qwilt)
Arnon Warshavsky (Qwilt)
Alfonso Siloniz (Telefonica)