Annex A
(normative)
Transport Security

A.1   Introduction

For most CDMI™ implementations, the Hypertext Transfer Protocol (HTTP) is the underlying communications protocol used to transfer CDMI messages. This appendix identifies the details associated with securing this underlying transport.

A.2   General Requirements for HTTP Implementations

The security requirements for HTTP implementations apply to both CDMI servers and clients. A CDMI client shall comply with all security requirements for HTTP that apply to clients. The following general requirements support security when using HTTP.

   Either HTTP basic authentication or HTTP digest authentication should be implemented.

   To minimize compromising user identities and credentials, such as passwords, implementations should use HTTP basic authentication ONLY in conjunction with Transport Layer Security (TLS).

   A user identity and credential used with one type of HTTP authentication (i.e., basic or digest) should never be subsequently used with the other type of HTTP authentication. To avoid compromising the integrity of a stronger scheme, established good security practices avoid the reuse of identity and credential information across schemes of different strengths.

   TLS 1.0 shall be implemented by CDMI entities and a more current version of TLS (e.g., v1.1 and v1.2) is strongly encouraged. The use of TLS by CDMI entities is optional, but should be used to protect sensitive data.

   Although HTTP shall be implemented by all CDMI entities, its use is optional.

The following requirements for implementations and optional use of HTTP over TLS (HTTPS) apply:

   The following cipher suites shall be supported to ensure a minimum level of security and interoperability between implementations:

   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (mandatory for TLS 1.0),

   TLS_RSA_WITH_AES_128_CBC_SHA (mandatory for TLS 1.1/1.2), and

   TLS_RSA_WITH_NULL_SHA (for TLS without encryption).

Note:   Implementors are free to include additional cipher suites, but there is no guarantee of interoperability when they are used.

   For clients and servers to communicate, they need to be using a consistent approach to security. Properly configured clients and servers may fail to communicate, if one is relying on port 80 and the other on port 443. Clients that fail to connect to a CDMI server via HTTP over TLS on TCP port 443 should retry with HTTP on TCP port 80 if their security policy allows it.

   Servers may accelerate discovery that a secure channel is needed by responding to HTTP contacts on TCP port 80 with a HTTP REDIRECT to the appropriate HTTPS: URI (HTTP over TLS on TCP port 443) to avoid the need for clients to timeout the HTTP contact attempt. Clients should honor such redirects in this situation.

   All certificates, including CA Root Certificates used by clients for certificate validation, shall be replaceable.

   The DER-encoded X.509, base 64-encoded X.509, and PKCS#12 certificate formats shall be supported.

   Certificate Revocation Lists shall be supported in the DER-encoded X.509 and base 64-encoded X.509 formats.

Note:   Since there are no absolutes when it comes to security, when specified versions are found to be vulnerable and/or inadequate, CDMI implementations should move to a newer version of TLS and stronger cipher suites as soon as possible.

A.3   Basic HTTP Security

HTTP is the mandatory transport mechanism for this version of CDMI. It is important to note that HTTP, by itself, offers no confidentiality or integrity protections.

CDMI clients may be responsible for initiating user authentication for each CDMI server that a user accesses. The CDMI server functions as the authenticator, and it receives the user credentials from the HTTP authentication operations.

IETF RFC 2616 and IETF RFC 2617 define requirements for HTTP authentication, which generally starts with an HTTP client request, such as <GET Request-URI> (where Request-URI is the resource requested). If the client request does not include an "Authorization" header line and authentication is required, the server responds with a 401 Unauthorized status code, and a WWW-Authenticate header line. The HTTP client shall then respond with the appropriate Authorization header line in a subsequent request. The format of the WWW-Authenticate and Authorization header lines varies depending on the type of authentication required‚ basic authentication, or digest authentication. If the authentication is successful, the HTTP server shall respond with a status code of 200 OK.

Basic authentication involves sending the user name and password in the clear, and it should only be used on a secure network or in conjunction with a mechanism that ensures confidentiality, such as Transport Layer Security (TLS). (See A.4). Digest authentication sends a secure digest of the user name and password (and other information including a nonce value), so that the password is not revealed. 401 Unauthorized responses should not include a choice of authentication.

Client authentication to the CDMI server is based on an authentication service (local and/or external). Differing authentication schemes may be supported, including host-based authentication, Kerberos, PKI, or other; the authentication service is out scope of this international standard.

A.4   HTTP over TLS (HTTPS)

CDMI may also include a mechanism to secure HTTP communications, such that data sent between the clients and servers are encrypted before being sent over the network. This security is achieved by transmitting HTTP over TLS (also known as HTTPS); the URI of a secure connection shall begin with https:// instead of http://. It is also important to note that a CDMI client communicates with a CDMI server via HTTPS on TCP port 443 (TCP port 80 is used for HTTP). A.5 provides important details on TLS.

When TLS is used to secure HTTP, the client and server typically perform some form of entity authentication. However, the specific nature of this entity authentication depends on the cipher suite negotiated; a cipher suite specifies the encryption algorithm and digest algorithm to use on a TLS connection. A very common scenario involves the use of server-side certificates, which the client trusts, as the basis for unidirectional entity authentication. It is possible that no authentication will occur (e.g., anonymous authentication) or on the other extreme, mutual authentication involving both client-side and server-side certificates may be required.

A.5   Transport Layer Security (TLS)

CDMI servers shall implement the TLS protocol; however, its use by clients is optional. TLS 1.0, which shall be implemented, is specified in RFC 2246, and the TLS 1.1 and TLS 1.2 should be implemented as specified in RFC 4346 and RFC 5246, respectively.

The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications. TLS allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. TLS is layered on top of some reliable transport protocol (e.g., TCP) and is used for encapsulating various higher-level protocols (e.g., HTTP).

TLS provides endpoint authentication and communications privacy over the network using cryptography. Typically, only the server is authenticated (i.e., its identity is ensured), while the client remains unauthenticated; this means that the end user (whether an individual or an application) has a measure of assurance with whom they are communicating. Mutual authentication (the identities of both endpoints are verified) requires, with few exceptions, the deployment of digital certificates on the client.

TLS involves three basic phases:

   peer negotiation for algorithm support;

   key exchange and authentication; and

   symmetric cipher encryption and message authentication.

During the first phase, the client and server negotiate cipher suites (see A.5.1), which determine the ciphers to be used, the key exchange, authentication algorithms, and the message authentication codes (MACs). The key exchange and authentication algorithms are typically public key algorithms. The MACs are made up from a keyed-Hash Message Authentication Code, or HMAC.

A.5.1   Cipher Suites

TLS packages one key establishment, confidentiality, signature and hash algorithm into a cipher suite. A registered 16-bit (4 hexadecimal digit) number, called the cipher suite index, is assigned for each defined cipher suite.

EXAMPLE   RSA key agreement, RSA signature, Advanced Encryption Standard (AES) using Cipher Block Chaining (CBC) confidentiality, and the Secure Hash Algorithm (SHA-1) hash are assigned the hexadecimal value {0x000F} for TLS.

The client always initiates the TLS session and starts cipher suite negotiation by transmitting a handshake message that lists the cipher suites (by index value) that it will accept. The server responds with a handshake message indicating which cipher suite it selected from the list or an "abort" as described below. Although the client is required to order its list by increasing "strength" of cipher suite, the server may choose ANY of the cipher suites proposed by the client. Therefore, there is NO guarantee that the negotiation will select the strongest suite. If no cipher suites are mutually supported, the connection is aborted. When the negotiated options, including optional public key certificates and random data for developing keying material to be used by the cryptographic algorithms, are complete, messages are exchanged to place the communications channel in a secure mode.

To ensure a minimum level of security and interoperability between implementations, all CDMI clients and servers shall support:

   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite (hexadecimal value {0x0013}), which is also the mandatory cipher suite for TLS 1.0 (see RFC 2246 Section 9, Mandatory Cipher Suites).

   TLS_RSA_WITH_AES_128_CBC_SHA cipher suite (hexadecimal value {0x002F}) shall be implemented, which is the mandatory cipher suite for TLS 1.2.

   TLS_RSA_WITH_NULL_SHA cipher suite (hexadecimal value {0x0002}) shall be supported by both CDMI clients and servers to implement authenticated, non-encrypted communications. When this cipher suite is used, HTTP basic authentication shall not be used.

   TLS_RSA_WITH_AES_128_CBC_SHA256 cipher suite (hexadecimal value {0x003C}) should be included with all recommended TLS 1.2 implementations to meet the transition to a security strength of 112 bits.

Implementors are free to include additional cipher suites.

A.5.2   Digital Certificates

CDMI clients and servers may be attacked by setting up a false CDMI server to capture userids and passwords or to insert itself as an undetected proxy between a CDMI client and server. The most effective countermeasure for this attack is the controlled use of server certificates with TLS, matched by client controls on certificate acceptance on the assumption that the false server will be unable to obtain an acceptable certificate. Specifically, this may be accomplished by configuring clients to always use TLS underneath HTTP authentication, and only accept certificates from a specific local certificate authority.

When used by CDMI, TLS shall use X.509 version 3 public key certificates that conform to the Certificate and Certificate Extension Profile defined in Section 4 of RFC 3280 (X.509v3 Certificate and CRL). This certificate and certificate revocation list (CRL) profile specifies the mandatory fields that shall be included in the certificate, as well as optional fields and extensions that may be included in the certificate.

Server certificates shall be supported by all CDMI servers, and client certificates may be supported by CDMI clients. The server presents a server certificate to authenticate the server to the client; likewise, the client presents a client certificate to authenticate itself to the server. For public web sites offering secure communications via TLS, server certificate usage is quite common, but client certificates are rarely used, because the client is typically authenticated by other means.

EXAMPLE   An e-commerce site will authenticate a client by a credit card number, user name/password, etc., when a purchase is made. It is much more of a trust issue that the client (purchaser) be assured of the identity of the e-commerce site, and for this reason, server certificates are much more commonly encountered in practice.

These X.509 certificates use a digital signature to bind together a public key with an identity. These signatures will often be issued by a certification authority (CA) that is associated with an internal or external public key infrastructure (PKI); however, an alternate approach uses self-signed certificates (the certificate is digitally signed by the very same key-pair whose public part appears in the certificate data). The trust models associated with these two approaches are very different. In the case of PKI certificates, a hierarchy of trust and a trusted third party may be consulted in the certificate validation process, which enhances security at the expense of increased complexity. The self-signed certificates may be used to form a web of trust (trust decisions are in the hands of individual users/administrators), but is considered less secure, as there is no central authority for trust (e.g., no identity assurance or revocation). This reduction in overall security, which may still offer adequate protections for some environments, is accompanied by an easing of the overall complexity of implementation.

With PKI certificates, it is often necessary to traverse the hierarchy or chain of trust in search of a root of trust or trust anchor (a trusted CA). This trust anchor may be an internal CA, which has a certificate signed by a higher ranking CA, or it may be the end of a certificate chain as the highest ranking CA. This highest ranking CA is the ultimate attestation authority in a particular PKI scheme, and its certificate, known as a root certificate, may only be self-signed. Establishing a trust anchor at the root certificate level, especially for commercial CAs, may have undesirable side effects resulting from the implicit trust afforded all certificates issued by that commercial CA. Ideally the trust anchor should be established with the lowest ranking CA that is practical.

A.5.2.1   Certificate Validation

CDMI clients and servers shall perform basic path validation, extension path validation, and Certificate Revocation List (CRL) validation as specified in Section 6 of RFC 3280 for all presented certificates. These validations include, but are not limited to, the following:

   The certificate is a validly constructed certificate.

   The signature is correct for the certificate.

   The date of its use is within the validity period (i.e., it has not expired).

   The certificate has not been revoked (applies only to PKI certificates).

   The certificate chain is validly constructed (considering the peer certificate plus valid issuer certificates up to the maximum allowed chain depth (applies only to PKI certificates).

When CDMI clients and servers use CRLs, they shall use X.509 version 2 CRLs that conform to the CRL and CRL Extension Profile defined in Section 5 of RFC 3280. (This requirement also only applies to PKI certificates.)

When PKI certificates and self-signed certificates are used together in a single management domain, it is important to recognize that the level of security is lowered to that afforded by self-signed certificates. Self-signed certificates by themselves only offer the keying materials to allow confidentiality and integrity in communications. The only identity assurances for self-signed certificates lie in the processes governing their acceptance as described below.

A.5.2.2   Certificate Formats

All interfaces for certificate configuration (import in particular) shall support the following certificate formats:

   DER-encoded X.509. See ISO/IEC 9594-8:2008 for specification and technical corrigenda.

   Base 64-encoded X.509 (often called PEM). See Section 6.8 of RFC2045.

   PKCS#12. See PKS12 for specification and technical corrigenda.

All certificate validation software shall support local certificate revocation lists and at least one list per CA root certificate. Support is required for both DER-encoded X.509 and base 64-encoded X.509 formats, but this support may be provided by using one format in the software and providing a tool to convert lists from the other format. OCSP and other means of immediate online verification of certificate validity are optional, as connectivity to the issuing Certificate Authority may not be assured.

A.5.2.3   Certificate Management

All certificates and their associated private keys shall be replaceable. CDMI clients and servers shall either have the ability to

   import an externally generated certificate and corresponding private key, or

   generate and install a new self-signed certificate along with its corresponding private key.

When CDMI clients and servers use PKI certificates, the implementations shall include the ability to import, install/store, and remove the CA root certificates; support for multiple trusted issuing CAs shall be included. CA certificates are used to verify that a certificate has been signed by a key from an acceptable certification authority.

All certificate interfaces required above shall support access restrictions that permit access only by suitably privileged administrators. A suitably privileged security administrator shall be able to disable functionality for acceptance of unrecognized certificates described in A.5.2.1 and A.5.2.2.

Support for PKCS#7 certificate format was deliberately omitted from the requirements. This format is primarily used for online interaction with certificate authorities; such functionality is not appropriate to require of all CDMI software, and tools are readily available to convert PKCS#7 certificates to or from other certificate formats.

A.5.2.4   Digital Certificate Guidance for TLS

To facilitate the use of certificates, CDMI implementations should include configurable mechanisms that allow for one of the following mutually exclusive operating modes to be in force at any time for end-entity certificates (i.e., not CA certificates):

   Unverifiable end-entity (self-signed) certificates are automatically installed as trust anchors when they are presented; such certificates shall be determined to not be CA root certificates before being installed as trust anchors and shall not serve as trust anchors to verify any other certificates. If a CA certificate is presented as an end-entity certificate in this mode, it shall be rejected. For CDMI clients, a variant of this option, which consults the user before taking action, should be implemented and used when possible.

Note:   The use of this operating mode should be limited to a learning or enrollment period during which communication is established with all other cloud storage systems with which security communication is desired. Use of a timeout to force automatic exit from this mode is recommended.

   Unverifiable end-entity (self-signed) certificates may be manually imported and installed as trust anchors (in a fashion similar to manually importing and installing a CA root certificate), but they are not automatically added when initially encountered. Administrative privilege may be required to import and install an end-entity certificate as a trust anchor.

   This operating mode is considered normal. All certificate acceptance policies for CDMI clients and servers shall be configurable. The configurable mechanisms determine how the CDMI implementation handles presented certificates. Under normal operating mode, CDMI servers should not accept certificates from unknown trust authorities (i.e., the CA root certificate has not been installed).

Interactive clients should provide a means to query the user about acceptance of a certificate from an unrecognized certificate authority (no corresponding CA root certificate installed in client), and accept responses allowing use of the certificate presented, or all certificates from the issuing CA. Servers should not support acceptance of unrecognized certificates; it is expected that a limited number of CAs will be acceptable for client certificates in any site that uses them.

Pre-configuring root certificates from widely used CAs is optional, but simplifies initial configuration of certificate-based security, as certificates from those CAs will be accepted. These CA root certificates may be exported from widely available web browsers.