Network Working Group M. Hubert Internet-Draft BT Intended status: Standards Track R. Murray Expires: January 03, 2014 B. Niven-Jenkins Velocix (Alcatel-Lucent) July 02, 2013 Illustrative CDNI Metadata for HTTPS Delivery draft-hubert-cdni-https-metadata-00 Abstract The CDNI Metadata specification describes generic CDNI metadata objects and properties as well as mechanisms to extend the generic/ base objects and properties to support additional standardised and/or proprietary capabilities. This document is intended to "test" the extensibility of the CDNI Metadata protocol by defining CDNI Metadata for delivery of content over HTTPS that extends the existing generic CDNI Metadata. Requirements Language 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 RFC 2119 [RFC2119]. 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 http://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 January 03, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Hubert, et al. Expires January 03, 2014 [Page 1] Internet-DraftIllustrative CDNI Metadata for HTTPS Delivery July 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2. CDNI Metadata Property Object Description . . . . . . . . . . 2 2.1. HTTPS Delivery Metadata . . . . . . . . . . . . . . . . . 2 2.1.1. Example HTTPS Delivery Metadata object . . . . . . . 4 2.2. Specifying HTTPS Delivery in CDNI Metadata . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The CDNI Metadata specification describes generic CDNI metadata objects and properties as well as mechanisms to extend the generic/ base objects and properties to support additional standardised and/or proprietary capabilities. This document is intended to "test" the extensibility of the CDNI Metadata protocol by defining CDNI Metadata for delivery of content over HTTPS that extends the existing generic CDNI Metadata defined in [I-D.ietf-cdni-metadata]. This document intends to test the extensibility of the CDNI Metadata protocol using HTTPS without client certificate authentication. 1.1. Terminology This document reuses the terminology defined in [I-D.ietf-cdni-metadata]. 2. CDNI Metadata Property Object Description CDNI Metadata property objects are defined in this section. 2.1. HTTPS Delivery Metadata Hubert, et al. Expires January 03, 2014 [Page 2] Internet-DraftIllustrative CDNI Metadata for HTTPS Delivery July 2013 HTTPS Metadata provides the dCDN with information about how to deliver content using HTTPS. All properties that apply to HTTP Delivery also apply to HTTPS delivery with the same meanings. The following HTTPS-specific properties are defined by this document. This document defines a new CDNI Metadata Object - the HTTPSDelivery metadata object which may be contained within a GenericMetadata object as defined in [I-D.ietf-cdni-metadata]. The HTTPSDelivery metadata object's type is "application/cdni.HTTPSDeliveryMetadata", its value is a dictionary of HTTPS delivery properties and the mandatory-to-enforce property MUST be True. The following HTTPS delivery properties are defined in this document. This is meant to be an illustrative set of HTTPS specific properties that would be combined with the HTTP delivery properties defined in the specification/RFC that defines HTTP delivery. [[Editor's note: Does the HTTPS metadata 'override' the HTTP metadata (e.g. duplicate properties in the HTTPS metadata object or does the dCDN need to combine the properties from each?]] Property: https.tls.version Description: List of SSL/TLS versions for which delivery is allowed. Type: List of TLSVersion. TLSVersion is a string containing an enumaration (in uppercase) of the SSL/TLS version, e.g. "TLS1.0" or "TLS1.1" etc. Mandatory-to-Specify: Yes. Property: https.ciphersuites Description: List of cipher suites for which delivery is allowed. Type: List of TLSCipherSuite. TLSCipherSuite is a string containing an enumeration of the cipher suite, e.g. "TLS_DHE_RSA_WITH_AES_256_CBC_SHA" or "TLS_RSA_WITH_AES_128_CBC_SHA" etc. Mandatory-to-Specify: Yes. Property: https.certificate Description: Server certificate to present to User Agents. Type: String containing base64 encoding of server certificate. Hubert, et al. Expires January 03, 2014 [Page 3] Internet-DraftIllustrative CDNI Metadata for HTTPS Delivery July 2013 Mandatory-to-Specify: Yes. Property: https.key Description: Private key. Type: String containing base64 encoding of server certificate. Mandatory-to-Specify: Yes. A new enumeration for HTTPS is required as Protocol metadata object as per [I-D.ietf-cdni-metadata] (section 4.3.2) 2.1.1. Example HTTPS Delivery Metadata object 2.2. Specifying HTTPS Delivery in CDNI Metadata Whether HTTP, HTTPS or both is allowed for a given hostname is controlled via a ProtocolACL (as specified by [I-D.ietf-cdni-metadata]). If the ProtocolACL specified in the HostMetadata object for a hostname contains only HTTPS then the dCDN MUST NOT deliver content associated with that HostMetadata object over HTTP. Likewise if only HTTP is specified the dCDN MUST NOT deliver content associated with that HostMetadata object over HTTPS. If both HTTP and HTTPS is specified in the HostMetadata's Protocol ACL then the dCDN MUST deliver content via the protocol is was requested over. PathMetadata objects associated with the HostMetadata can be used to control the availability/permissibility of HTTP/HTTPS/mixed delivery on a per-URI path basis (via PathMatch objects). 3. IANA Considerations Add enumeration for HTTPS to Protocol metadata object [I-D.ietf-cdni-metadata](section 4.3.2). Add type for "HTTPS Delivery Metadata" CDNI Metadata Property Object 4. Security Considerations The HTTPS private key should be embedded in the metadata in base64 encoding format. Metadata pertaining to HTTPS MUST be exchanged over secure transport i.e HTTPS, and CDNI metadata receivers MUST be authorised/authenticated. The detail of precise mechanisms to do this is out of scope of this document. The storage and manipulation of HTTPS metadata such as the private key on the dCDN itself must also be secure. The detail of precise mechanisms to do this are also out of scope of this document. Hubert, et al. Expires January 03, 2014 [Page 4] Internet-DraftIllustrative CDNI Metadata for HTTPS Delivery July 2013 5. Normative References [I-D.ietf-cdni-metadata] Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- ietf-cdni-metadata-01 (work in progress), February 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Mal Hubert BT Adastral Park Martlesham Heath, Ipswich IP5 3RE UK Email: mal.hubert@bt.com Rob Murray Velocix (Alcatel-Lucent) 3 Ely Road Milton, Cambridge CB24 6DD UK Email: rmurray@velocix.com Ben Niven-Jenkins Velocix (Alcatel-Lucent) 3 Ely Road Milton, Cambridge CB24 6DD UK Email: ben@velocix.com Hubert, et al. Expires January 03, 2014 [Page 5]