Internet DRAFT - draft-hubert-cdni-https-metadata
draft-hubert-cdni-https-metadata
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]
