RFC 2660






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||[