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