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 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 implementations to consider the Date: header allowable in HTTP messages as a freshness indicator, where appropriate (although this requires implementations 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 secure documents for the World-Wide Web in the face of the broad scope of application requirements, variability of user sophistication, and disparate implementation constraints, Secure HTTP deliberately caters to a variety of implementation options. See Section 8 for implementation recommendations and requirements. 2. Message Format Syntactically, Secure HTTP messages are the same as HTTP, consisting of a request or status line followed by headers and a body. However, the range of headers is different and the bodies are typically Rescorla & Schiffman Experimental [Page 7] RFC 2660 The Secure HyperText Transfer Protocol August 1999 cryptographically enhanced. 2.1. Notational Conventions This document uses the augmented BNF from HTTP [RFC-2616]. You should refer to that document for a description of the syntax. 2.2. Request Line In order to differentiate S-HTTP messages from HTTP messages and allow for special processing, the request line should use the special Secure" method and use the protocol designator "Secure-HTTP/1.4". Consequently, Secure-HTTP and HTTP processing can be intermixed on the same TCP port, e.g. port 80. In order to prevent leakage of potentially sensitive information Request-URI should be "*". For example: Secure * Secure-HTTP/1.4 When communicating via a proxy, the Request-URI should be consist of the AbsoluteURI. Typically, the rel path section should be replaced by "*" to minimize the information passed to in the clear. (e.g. http://www.terisa.com/*); proxies should remove the appropriate amount of this information to minimize the threat of traffic analysis. See Section 7.2.2.1 for a situation where providing more information is appropriate. 2.3. The Status Line S-HTTP responses should use the protocol designator "Secure- HTTP/1.4". For example: Secure-HTTP/1.4 200 OK Note that the status in the Secure HTTP response line does not indicate anything about the success or failure of the unwrapped HTTP request. Servers should always use 200 OK provided that the Secure HTTP processing is successful. This prevents analysis of success or failure for any request, which the correct recipient can determine from the encapsulated data. All case variations should be accepted. 2.4. Secure HTTP Header Lines The header lines described in this section go in the header of a 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. Rescorla & Schiffman Experimental [Page 8] RFC 2660 The Secure HyperText Transfer Protocol August 1999 All data and fields in header lines should be treated as case insensitive unless otherwise specified. Linear whitespace [RFC-822] should be used only as a token separator unless otherwise quoted. Long header lines may be line folded in the style of [RFC-822]. 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.4.1. Content-Privacy-Domain The two values defined by this document are 'MOSS' and 'CMS'. CMS refers to the privacy enhancement specified in section 2.6.1. MOSS refers to the format defined in [RFC-1847] and [RFC-1848]. 2.4.2. Content-Type for CMS Under normal conditions, the terminal encapsulated content (after all privacy enhancements have been removed) would be an HTTP message. In this case, there shall be a Content-Type line reading: Content-Type: message/http The message/http content type is defined in RFC-2616. If the inner message is an S-HTTP message, then the content type shall be 'application/s-http'. (See Appendix for the definition of this.) It is intended that these types be registered with IANA as MIME content types. The terminal content may be of some other type provided that the type is properly indicated by the use of an appropriate Content-Type header line. In this case, the header fields for the encapsulation of the terminal content apply to the terminal content (the 'final headers'). But in any case, final headers should themselves always be S-HTTP encapsulated, so that the applicable S-HTTP/HTTP headers are never passed unenhanced. S-HTTP encapsulation of non-HTTP data is a useful mechanism for passing pre-enhanced data (especially presigned data) without requiring that the HTTP headers themselves be pre-enhanced. Rescorla & Schiffman Experimental [Page 9] RFC 2660 The Secure HyperText Transfer Protocol August 1999 2.4.3. Content-Type for MOSS The Content-Type for MOSS shall be an acceptable MIME content type describing the cryptographic processing applied. (e.g. multipart/signed). The content type of the inner content is described in the content type line corresponding to that inner content, and for HTTP messages shall be 'message/http'. 2.4.4. Prearranged-Key-Info This header line is intended to convey information about a key which 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 two methods for exchanging named keys, Inband, Outband. Inband 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 = "Prearranged-Key-Info" ":" Hdr-Cipher "," CoveredDEK "," CoverKey-ID CoverKey-ID = method ":" key-name CoveredDEK = *HEX method = "inband" | "outband" While chaining ciphers require an Initialization Vector (IV) [FIPS- 81] to start off the chaining, that information is not carried by this field. Rather, it should be passed internal to the cryptographic format 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 3.2.4.7) is the protected Data Encryption 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. Rescorla & Schiffman Experimental [Page 10] RFC 2660 The Secure HyperText Transfer Protocol August 1999 In order to avoid name collisions, cover key namespaces must be maintained separately by host and port. Note that some Content-Privacy-Domains, notably likely future revisions of MOSS and CMS may have support for symmetric key management. The Prearranged-Key-Info field need not be used in such circumstances. Rather, the native syntax is preferred. Keys exchanged with Key-Assign, however, may be used in this situation. 2.4.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 concatenation): MAC = hex(H(Message||[