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.
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.
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.)
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.
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.
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
session key, with key identification information specified on one of
the header lines.
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.
