Network Working Group E. Rescorla Request for Comments: 2660 RTFM, Inc. Category: Experimental A. Schiffman Terisa Systems, Inc. August 1999 The Secure HyperText Transfer Protocol Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 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) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin. The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction. Table of Contents 1. Introduction .................................................. 3 1.1. Summary of Features ......................................... 3 1.2. Changes ..................................................... 4 1.3. Processing Model ............................................ 5 1.4. Modes of Operation .......................................... 6 1.5. Implementation Options ...................................... 7 2. Message Format ................................................ 7 2.1. Notational Conventions ...................................... 8 2.2. The Request Line ............................................ 8 2.3. The Status Line ............................................. 8 2.4. Secure HTTP Header Lines .................................... 8 2.5. Content .....................................................12 2.6. Encapsulation Format Options ................................13 Rescorla & Schiffman Experimental [Page 1] RFC 2660 The Secure HyperText Transfer Protocol August 1999 2.6.1. Content-Privacy-Domain: CMS ...............................13 2.6.2. Content-Privacy-Domain: MOSS ..............................14 2.6.3. Permitted HTTP headers ....................................14 2.6.3.2. Host ....................................................15 2.6.3.3. Connection ..............................................15 3. Cryptographic Parameters ......................................15 3.1. Options Headers .............................................15 3.2. Negotiation Options .........................................16 3.2.1. Negotiation Overview ......................................16 3.2.2. Negotiation Option Format .................................16 3.2.3. Parametrization for Variable-length Key Ciphers ...........18 3.2.4. Negotiation Syntax ........................................18 3.3. Non-Negotiation Headers .....................................23 3.3.1. Encryption-Identity .......................................23 3.3.2. Certificate-Info ..........................................23 3.3.3. Key-Assign ................................................24 3.3.4. Nonces ....................................................25 3.4. Grouping Headers With SHTTP-Cryptopts .......................26 3.4.1. SHTTP-Cryptopts ...........................................26 4. New Header Lines for HTTP .....................................26 4.1. Security-Scheme .............................................26 5. (Retriable) Server Status Error Reports .......................27 5.1. Retry for Option (Re)Negotiation ............................27 5.2. Specific Retry Behavior .....................................28 5.3. Limitations On Automatic Retries ............................29 6. Other Issues ..................................................30 6.1. Compatibility of Servers with Old Clients ...................30 6.2. URL Protocol Type ...........................................30 6.3. Browser Presentation ........................................31 7. Implementation Notes ..........................................32 7.1. Preenhanced Data ............................................32 7.2. Note:Proxy Interaction ......................................34 7.2.1. Client-Proxy Authentication ...............................34 8. Implementation Recommendations and Requirements ...............34 9. Protocol Syntax Summary .......................................35 10. An Extended Example ..........................................36 Appendix: A Review of CMS ........................................40 Bibliography and References ......................................41 Security Considerations ..........................................43 Authors' Addresses ...............................................44 Full Copyright Statement..........................................45 Rescorla & Schiffman Experimental [Page 2] RFC 2660 The Secure HyperText Transfer Protocol August 1999 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) [RFC-2616]. The ease of use of the Web has prompted its widespread employment as a client/server architecture for many applications. Many such applications 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, cryptographic algorithms and encapsulation formats through option negotiation between parties for each transaction. 1.1. Summary of Features Secure HTTP is a secure message-oriented communications protocol designed for use in conjunction with HTTP. It is designed to coexist with HTTP's messaging model and to be easily integrated with HTTP applications. Secure HTTP provides 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, [CMS] and [MOSS]. 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 public keys), as it supports symmetric key-only operation modes. Rescorla & Schiffman Experimental [Page 3] RFC 2660 The Secure HyperText Transfer Protocol August 1999 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. 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 message headers); 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 (e.g., should the request be signed or encrypted or both -- similarly for the reply?); cryptographic algorithms (RSA vs. DSA for signing, DES vs. RC2 for encrypting, etc.); and certificate selection (please sign with your "Block-buster Video 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. S-HTTP differs from Digest-Authentication, described in [RFC-2617] in that it provides support for public key cryptography and consequently digital signature capability, as well as providing confidentiality. 1.2. Changes This document describes S-HTTP/1.4. It differs from the previous memo in that it differs from the previous memo in its support of the Cryptographic Message Syntax (CMS) [CMS], a successor to PKCS-7; and hence now supports the Diffie-Hellman and the (NIST) Digital Signature Standard cryptosystems. CMS used in RSA mode is bits on the wire compatible with PKCS-7. Rescorla & Schiffman Experimental [Page 4] RFC 2660 The Secure HyperText Transfer Protocol August 1999 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 other data object. Note that since the cleartext message is carried transparently, headers and all, any version of HTTP can be carried within an S-HTTP wrapper. 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 integrates the 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 intervention. For instance, there might be multiple keys available to sign the message. (See Section 3.2.4.9.3 for more on this topic.) Using this data, the sender applies the enhancements to the message clear-text 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 3.2. 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.) Rescorla & Schiffman Experimental [Page 5] RFC 2660 The Secure HyperText Transfer Protocol August 1999 In order to recover an S-HTTP message, the receiver needs to read the headers to discover which cryptographic transformations were performed on the message, then remove the transformations using some combination of the sender's and receiver's keying material, while taking note of which 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 6.4 for more on this topic.) 1.4. Modes of Operation Message protection may be provided on three orthogonal axes: signature, authentication, and encryption. Any message may be signed, authenticated, encrypted, or any combination of these (including no protection). Multiple key management mechanisms are supported, including password-style manually shared secrets and public-key key exchange. In particular, provision has been made for prearranged (in an earlier transaction or out of band) symmetric session keys in order to send confidential messages to those who have no public 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 certificate 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. Rescorla & Schiffman Experimental [Page 6] RFC 2660 The Secure HyperText Transfer Protocol August 1999 In the latter mode, we encrypt the content using a prearranged session key, with key identification information specified on one of the header lines. 1.4.3. Message Integrity and Sender Authentication Secure HTTP provides a means to verify message integrity and sender authenticity for a 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 'inband' key management. 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 transactions themselves. The provision of this mechanism is motivated by our bias that the action of "signing" a transaction should be explicit and conscious for the user, whereas many authentication needs (i.e., access control) can be met with a lighter-weight mechanism th