E. Rescorla, A. Schiffman INTERNET-DRAFT Enterprise Integration Technologies Feb 1996 (Expires August-96) The Secure HyperText Transfer Protocol Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This document describes S-HTTP version 1.2. The original draft of this specification, defining S-HTTP version 1.0, was distributed by the CommerceNet Consortium in June 1994; in December 1994 a revised specification describing S-HTTP version 1.1 was published as an Internet Draft (draft-rescorla-shttp-00.txt). In July 1995, an updated version of that draft was published as an Internet Draft. That document deprecated some unimplemented facilities, provides additional clarifying material, and made minor corrections to the 12/94 version. This document implements a decision reached at the December 1995 IETF WTS meeting to break up the single S-HTTP document into two docu- ments, one describing the S-HTTP messaging protocol and negotiation syntax and one describing extensions to HTML to facilitate the use of S-HTTP. The companion document is draft-ietf-wts-shtml-00.txt [23]. Abstract This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. Secure HTTP (S-HTTP) is an extension of HTTP, provid- ing independently applicable security services for transaction confi- dentiality, authenticity/integrity and non-repudiability of origin. Rescorla, Schiffman [Page 1] Internet-Draft Secure HTTP The protocol emphasizes maximum flexibility in choice of key manage- ment mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction. Rescorla, Schiffman [Page 2] Internet-Draft Secure HTTP 1. Introduction The World Wide Web (WWW) is a distributed hypermedia system which has gained widespread acceptance among Internet users. Although WWW browsers support other, preexisting Internet application protocols, the native and primary protocol used between WWW clients and servers is the HyperText Transfer Protocol (HTTP) [18]. The ease of use of the Web has prompted widespread interest in its employment as a client/server architecture for many applications. Many such applica- tions require the client and server to be able to authenticate each other and exchange sensitive information confidentially. The original HTTP specification had only modest support for the cryptographic mechanisms appropriate for such transactions. Secure HTTP (S-HTTP) provides secure communication mechanisms between an HTTP client-server pair in order to enable spontaneous commercial transactions for a wide range of applications. Our design intent is to provide a flexible protocol that supports multiple orthogonal operation modes, key management mechanisms, trust models, crypto- graphic algorithms and encapsulation formats through option negotia- tion between parties for each transaction. 1.1. Summary of Features Secure HTTP supports a variety of security mechanisms to HTTP clients and servers, providing the security service options appropriate to the wide range of potential end uses possible for the World-Wide Web. The protocol provides symmetric capabilities to both client and server (in that equal treatment is given to both requests and replies, as well as for the preferences of both parties) while preserving the transaction model and implementation characteristics of HTTP. Several cryptographic message format standards may be incorporated into S-HTTP clients and servers, particularly, but in principle not limited to, PKCS-7 and PEM. S-HTTP supports interoperation among a variety of implementations, and is compatible with HTTP. S-HTTP aware clients can communicate with S-HTTP oblivious servers and vice-versa, although such transactions obviously would not use S-HTTP security features. S-HTTP does not require client-side public key certificates (or pub- lic keys), supporting symmetric session key operation modes. This is significant because it means that spontaneous private transactions can occur without requiring individual users to have an established public key. While S-HTTP is able to take advantage of ubiquitous certification infrastructures, its deployment does not require it. Rescorla, Schiffman [Page 3] Internet-Draft Secure HTTP S-HTTP supports end-to-end secure transactions, in contrast with the original HTTP authorization mechanisms which require the client to attempt access and be denied before the security mechanism is employed. Clients may be "primed" to initiate a secure transaction (typically using information supplied in an HTML anchor); this may be used to support encryption of fill-out forms, for example. With S- HTTP, no sensitive data need ever be sent over the network in the clear. S-HTTP provides full flexibility of cryptographic algorithms, modes and parameters. Option negotiation is used to allow clients and servers to agree on transaction modes (should the request be signed? encrypted? both? what about the reply?); cryptographic algorithms (RSA vs. DSA for signing, DES vs. RC2 for encrypting, etc.); and cer- tificate selection (please sign with your "Mastercard certificate"). S-HTTP attempts to avoid presuming a particular trust model, although its designers admit to a conscious effort to facilitate multiply- rooted hierarchical trust, and anticipate that principals may have many public key certificates. 1.2. Changes This document describes S-HTTP/1.2. The prior draft described S- HTTP/1.1. This version adds a number of minor changes, including a new hash construction and a new way of binding cryptographic parame- ters to HTML anchors. S-HTTP/1.2 messages will be readable by S- HTTP/1.1 agents and vice versa, provided that compatible algorithms are used. 1.3. Processing Model 1.3.1. Message Preparation The creation of an S-HTTP message can be thought of as a a function with three inputs: 1. The cleartext message. This is either an HTTP message or some data object. 2. The receiver's cryptographic preferences and keying material. This is either explicitly specified by the receiver or subject to some default set of preferences. 3. The sender's cryptographic preferences and keying material. This input to the function can be thought of as implicit since it exists only in the memory of the sender. In order to create an S-HTTP message, then, the sender merges the Rescorla, Schiffman [Page 4] Internet-Draft Secure HTTP sender's preferences with the receiver's preferences. The result of this is a list of cryptographic enhancements to be applied and keying material to be used to apply them. This may require some user inter- vention. For instance, there might be multiple keys available to sign the message. (See Section 7 for more on this topic.) Using this data, the sender applies the enhancements to the message cleartext to create the S-HTTP message. The processing steps required to transform the cleartext message into the S-HTTP message are described in Sections 2 and 3. The processing steps required to merge the sender's and receiver's preferences are described in Sections 4 and 5. 1.3.2. Message Recovery The recovery of an S-HTTP message can be thought of as a function of four distinct inputs: 1. The S-HTTP message. 2. The receiver's stated cryptographic preferences and keying material. The receiver has the opportunity to remember what cryptographic preferences it provided in order for this document to be dereferenced. 3. The receiver's current cryptographic preferences and keying material. 4. The sender's previously stated cryptographic options. The sender may have stated that he would perform certain cryptographic operations in this message. (Again, see sections 4 and 5 for details on how to do this.) In order to recover an S-HTTP message, the receiver needs to read the headers and discover what sorts of cryptographic transformations were performed on the message, then remove them using some combination of the sender's and receiver's keying material, in the process while taking note of what enhancements were applied. The receiver may also choose to verify that the applied enhancements match both the enhancements that the sender said he would apply (input 4 above) and that the receiver requested (input 2 above) as well as the current preferences to see if the S-HTTP message was appropriately transformed. This process may require interaction with the user to verify that the enhancements are acceptable to the user. (See Section 7 for more on this topic.) 1.4. Modes of Operation Message protection may be provided on three orthogonal axes: Rescorla, Schiffman [Page 5] Internet-Draft Secure HTTP signature, authentication, and encryption. Any message may be signed, authenticated, encrypted, or any combination of these (including no protection). Multiple key management mechanisms are provided, including password- style manually shared secrets, public-key key exchange and Kerberos [19] ticket distribution. In particular, provision has been made for prearranged (in an earlier transaction) symmetric session keys in order to send confidential messages to those who have no key pair. Additionally, a challenge-response (``nonce'') mechanism is provided to allow parties to assure themselves of transaction freshness. 1.4.1. Signature If the digital signature enhancement is applied, an appropriate cer- tificate may either be attached to the message (possibly along with a certificate chain) or the sender may expect the recipient to obtain the required certificate (chain) independently. 1.4.2. Key Exchange and Encryption In support of bulk encryption, S-HTTP defines two key transfer mechanisms, one using public-key enveloped key exchange and another with externally arranged keys. In the former case, the symmetric-key cryptosystem parameter is passed encrypted under the receiver's public key. In the latter mode, we encrypt the content using a prearranged ses- sion key, with key identification information specified on one of the header lines. Keys may also be extracted from Kerberos tickets. 1.4.3. Message Integrity and Sender Authentication Secure HTTP provides a means to verify message integrity and sender authenticity for a HTTP message via the computation of a Message Authentication Code (MAC), computed as a keyed hash over the document using a shared secret -- which could potentially have been arranged in a number of ways, e.g.: manual arrangement or Kerberos. This technique requires neither the use of public key cryptography nor encryption. This mechanism is also useful for cases where it is appropriate to allow parties to identify each other reliably in a transaction without providing (third-party) non-repudiability for the transac- tions themselves. The provision of this mechanism is motivated by our bias that the action of "signing" a transaction should be explicit Rescorla, Schiffman [Page 6] Internet-Draft Secure HTTP and conscious for the user, whereas many authentication needs (i.e., access control) can be met with a lighter-weight mechanism that retains the scalability advantages of public-key cryptography for key exchange. 1.4.4. Freshness The protocol provides a simple challenge-response mechanism, allowing both parties to insure the freshness of transmissions. Additionally, the integrity protection provided to HTTP headers permits implementa- tions to consider the Date: header allowable in HTTP messages as a freshness indicator, where appropriate (although this requires imple- mentations to make allowances for maximum clock skew between parties, which we choose not to specify). 1.5. Implementation Options In order to encourage widespread adoption of cryptographic facilities for the World-Wide Web, Secure HTTP deliberately caters to a variety of implementation options despite the fact that the resulting varia- bility makes interoperation potentially problematic. We anticipate that some implementors will choose to integrate an out- board PEM program with a WWW client or server; such implementations will not be able to use all operation modes or features of S-HTTP, but will be able to interoperate with most other implementations. Other implementors will choose to create a full-fledged PKCS-7 imple- mentation (allowing for all the features of S-HTTP); in which case PEM support will be only a modest additional effort. Without com- pletely prescribing a minimum implementation profile (although see section 8) then, we recommend that all S-HTTP implementations support the PEM message format. 2. HTTP Encapsulation A Secure HTTP message consists of a request or status line (as in HTTP) followed by a series of RFC-822 style headers followed by an encapsulated content. Once the content has been decoded, it should either be another Secure HTTP message, an HTTP message, or simple data. For the purposes of compatibility with existing HTTP implementations, we distinguish S-HTTP transaction requests and replies with a dis- tinct protocol designator ('Secure-HTTP/1.2'). However, if a future version of HTTP (i.e., 'HTTP/2.0') subsumes this document use of a new protocol HTTP designator would provide the same backwards compa- tibility function and a distinction between such a future version of HTTP and Secure-HTTP would be unnecessary. Rescorla, Schiffman [Page 7] Internet-Draft Secure HTTP 2.1. The Request Line For HTTP requests, we define a new HTTP protocol method, 'Secure'. All secure requests (using this version of the protocol) should read: Secure * Secure-HTTP/1.2 All case variations should be accepted. The asterisk shown here is a placeholder and should be ignored by servers; proxy-aware clients should substitute the URL (and must provide at least the host+port portion) of the request when communicating via proxy, as is the current HTTP convention; (e.g. http://www.terisa.com/*) proxies should remove the appropriate amount of this information to minimize the threat of traffic analysis. See Section 8.2.2.1 for a situation where providing more information is appropriate. 2.2. The Status Line For server responses, the first line should be: Secure-HTTP/1.2 200 OK whether the request succeeded or failed. This prevents analysis of success or failure for any request. All case variations should be accepted. 2.3. Secure HTTP Header Lines We define a series of new header lines to go in the header of the Secure HTTP message. All except 'Content-Type' and 'Content-Privacy- Domain' are optional. The message body shall be separated from the header block by two successive CRLFs. All data and fields in header lines should be treated as case insen- sitive unless otherwise specified. Linear whitespace [6] should be used only as a token separator unless otherwise quoted. Long header lines may be line folded in the style of RFC822 [6]. This document refers to the header block following the S-HTTP request/response line and preceding the successive CRLFs collectively as "S-HTTP headers". 2.3.1. Content-Privacy-Domain This header line exists to provide compatibility with PEM-based Secure HTTP systems. The two values defined by this document are 'PEM' and 'PKCS-7'. PKCS-7 [2] refers to the privacy enhancement specified in section 3. PEM refers to standard PEM message format as Rescorla, Schiffman [Page 8] Internet-Draft Secure HTTP defined in RFC1421 [1]. Note that MOSS[25] could be accomodated sim- ply by adding a Content-Privacy-Domain: MOSS. 2.3.2. Content-Transfer-Encoding The PKCS-7 message format is designed for an 8-bit clear channel, but may be passed over other channels using base-64 encoding (see RFC1421 [1] for a description of base-64). For 'Content-Privacy-Domain: PKCS-7', acceptable acceptable values for this field are 'BASE64','8BIT', or 'BINARY'. Unless such a line is included, the rest of the message is assumed to be 'BINARY'. (Note that the difference between 'BINARY' and '8BIT' has to do with line length.) For 'Content-Privacy-Domain: PEM', the only acceptable value for this field is '7BIT', since PEM messages are already encoded for RFC-822 (and hence 7-bit) transport. 2.3.3. Content-Type Under normal conditions, the terminal encapsulated content (after all privacy enhancements have been removed) shall be considered to be an HTTP/1.0 message. In this case, there shall be a Content-Type line reading: Content-Type: application/http It is intended that this type be registered with IANA as a MIME con- tent type. For backwards compatibility, 'application/x-http' is also acceptable. However, the terminal content may be of some other type provided that that type is properly indicated by the use of an appropriate Content-Type header line. In this case, the header fields for the last (most deeply encapsulated) HTTP or S-HTTP message should be applied to the terminal content. It should be noted that unless the (S-)HTTP message from which the headers are taken is itself enveloped, then some possibly sensitive information has been passed in the clear. This is a useful mechanism for passing pre-enhanced data (especially presigned data) without requiring that the HTTP headers themselves be pre-enhanced. 2.3.4. Prearranged-Key-Info This header line is intended to convey information about a key which Rescorla, Schiffman [Page 9] Internet-Draft Secure HTTP has been arranged outside of the internal cryptographic format. One use of this is to permit in-band communication of session keys for return encryption in the case where one of the parties does not have a key pair. However, this should also be useful in the event that the parties choose to use some other mechanism, for instance, a one-time key list. This specification defines three methods for exchanging named keys, Inband, Kerberos and Outband. Inband and Kerberos indicates that the session key was exchanged previously, using a Key-Assign header of the corresponding method. Outband arrangements imply that agents have external access to key materials corresponding to a given name, presumably via database access or perhaps supplied immediately by a user from keyboard input. The syntax for the header line is: Prearranged-Key-Info: ','',' := ':' := := 'inband' | 'krb-' | 'outband' := '4' | '5' While chaining ciphers require an Initialization Vector (IV) [16] to start off the chaining, that information is not carried by this field. Rather, it should be passed internal to the cryptographic for- mat being used. Likewise, the bulk cipher used is specified in this fashion. should be the name of the block cipher used to encrypt the session key (see section 4.4.7). is the protected Data Exchange Key (a.k.a. transaction key) under which the encapsulated message was encrypted. It should be appropriately (randomly) generated by the sending agent, then encrypted under the cover of the negotiated key (a.k.a. session key) using the indicated header cipher, and then converted into hex. In order to avoid name collisions, cover key namespaces must be main- tained separately by host and port. 2.3.5. MAC-Info This header is used to supply a Message Authenticity Check, providing both message authentication and integrity, computed from the message text, the time (optional -- to prevent replay attack), and a shared secret between client and server. The MAC should be computed over the encapsulated content of the S-HTTP message. S-HTTP/1.1 defined that MACs should be computed using the following algorithm ('||' means Rescorla, Schiffman [Page 10] Internet-Draft Secure HTTP concatenation): MAC = hex(H(Message||[