E. Rescorla, A. Schiffman INTERNET-DRAFT Enterprise Integration Technologies December 1994 (Expires 5/95) The Secure HyperText Transfer Protocol Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This document describes S-HTTP version 1.1. A prior draft of this document, defining S-HTTP version 1.0, was distributed by the Commer- ceNet Consortium in June 1994, is known as ``draft 24''. This docu- ment is draft 35; it provides additional clarifying material, and specifies additional facilities relative to draft 24. 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) is an extension of HTTP, provid- ing independently applicable security services for transaction confi- dentiality, authenticity/integrity and non-repudiability of origin. The protocol emphasizes maximum flexibility in choice of key manage- ment mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction. Rescorla, Schiffman
[Page 1] Internet-Draft Secure HTTP
1. Introduction The World Wide Web (WWW) is a distributed hypermedia system which is rapidly gaining acceptance among Internet users. Although many 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) [18]. The ease of use of the Web has prompted widespread interest in its employment as a client/server architecture for many applications. Many such applica- tions require the client and server to be able to authenticate each other and exchange sensitive information confidentially. Current HTTP implementations have 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, crypto- graphic algorithms and encapsulation formats through option negotia- tion between parties for each transaction.
1.1. Summary of Features Secure HTTP supports 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 the current HTTP. Several cryptographic message format standards may be incorporated into S-HTTP clients and servers, including, but not limited to, PKCS-7, PEM, and PGP. S-HTTP supports interoperation among a variety of implementations, and is compatible with HTTP. S-HTTP aware clients can talk to 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 pub- lic keys), supporting symmetric session key 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 will be able to take advantage of ubiqui- tous certification infrastructures, its deployment does not require it. Rescorla, Schiffman [Page 2] Internet-Draft Secure HTTP S-HTTP supports end-to-end secure transactions, in contrast with the existing de-facto 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 transac- tion (typically using information supplied in an HTML anchor); 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 (should the request be signed? encrypted? both? what about the reply?); cryptographic algorithms (RSA vs. DSA for signing, DES vs. RC2 for encrypting, etc.); and cer- tificate selection (please sign with your "Mastercard 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.
1.2. Modes of Operation Message protection may be provided on three orthogonal axes: signa- ture, authentication, and encryption. Any message may be signed, authenticated, encrypted, or any combination of these (including no protection). Multiple key management mechanisms are provided, including password- style manually shared secrets, public-key key exchange and Kerberos [19] ticket distribution. In particular, provision has been made for prearranged (in an earlier transaction) symmetric session keys in order to send confidential messages to those who have no key pair. Additionally, a challenge-response (``nonce'') mechanism is provided to allow parties to assure themselves of transaction freshness.
1.2.1. Signature If the digital signature enhancement is applied, an appropriate cer- tificate 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.2.2. Encryption In support of bulk encryption, S-HTTP defines two key transfer mechanisms, one using public key in-band key exchange and another Rescorla, Schiffman [Page 3] Internet-Draft Secure HTTP 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 ses- sion key, with key identification information specified on one of the header lines. Keys may also be extracted from Kerberos tickets.
1.2.3. (Message Integrity and Sender) Authentication Secure HTTP provides a means to verify message integrity and sender authenticity for a HTTP 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 Kerberos. 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 transac- tions 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.
1.2.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 implementa- tions to consider the Date: header allowable in HTTP messages as a freshness indicator, where appropriate (although this requires imple- mentations to make allowances for maximum clock skew between parties, which we choose not to specify).
1.3. Implementation Options In order to encourage widespread adoption of cryptographic facilities for the World-Wide Web, Secure HTTP deliberately caters to a variety of implementation options despite the fact that the resulting varia- bility makes interoperation potentially problematic. We anticipate that some implementors will choose to integrate an out- board PEM program with a WWW client or server; such implementations will not be able to use all operation modes or features of S-HTTP, Rescorla, Schiffman [Page 4] Internet-Draft Secure HTTP but will be able to interoperate with most other implementations. Other implementors will choose to create a full-fledged PKCS-7 imple- mentation (allowing for all the features of S-HTTP); in which case PEM support will be only a modest additional effort. Without com- pletely prescribing a minimum implementation profile (although see section 8) then, we recommend that all S-HTTP implementations support the PEM message format.
2. HTTP Encapsulation A Secure HTTP message consists of a request or status line (as in HTTP) followed by a series of RFC-822 style headers followed by an encapsulated content. Once the content has been decoded, it should either be another Secure HTTP message, an HTTP message, or simple data. For the purposes of compatibility with existing HTTP implementations, we distinguish S-HTTP transaction requests and replies with a dis- tinct protocol designator ('Secure-HTTP/1.1'). However, if a future version of HTTP (i.e., 'HTTP/2.0') subsumes this RFC, use of a new protocol HTTP designator would provide the same backwards compatibil- ity function and a distinction between such a future version of HTTP and Secure-HTTP would be unnecessary.
2.1. The Request Line For HTTP requests, we define a new HTTP protocol method, 'Secure'. All secure requests (using this version of the protocol) should read: Secure * Secure-HTTP/1.1 All case variations should be accepted. The asterisk shown here is to be considered non-coding; proxy-aware clients should substitute the URL (at least the host+port portion) of the request when communicat- ing via proxy, as is the current HTTP convention; proxies should remove the appropriate amount of this information to minimize the threat of traffic analysis.
2.2. The Status Line For server responses, the first line should be: Secure-HTTP/1.1 200 OK whether the request succeeded or failed. This prevents analysis of success or failure for any request. All case variations should be accepted. Rescorla, Schiffman [Page 5] Internet-Draft Secure HTTP
2.3. Secure HTTP Header Lines We define a series of new header lines to go in the header of the 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. All data and fields in header lines should be treated as case insen- sitive unless otherwise specified. Linear whitespace [6] should be used only as a token separator unless otherwise quoted. Long header lines may be line folded in the style of RFC822 [6].
2.3.1. Content-Privacy-Domain This header line exists to provide compatibility with PEM-based Secure HTTP systems. The three values defined by this document are 'PEM', 'PKCS-7' and 'PGP'. PKCS-7 [2] refers to the privacy enhance- ment specified in section 3. PEM refers to standard PEM message for- mat as defined in RFC1421 [1]. PGP refers to the message format com- patible with PGP 2.6 [14].
2.3.2. Content-Transfer-Encoding The PKCS-7 protocol is designed for an 8-bit clear channel, but may be passed over other channels using base-64 encoding (see RFC1421 [1] for a description of base-64). For 'Content-Privacy-Domain: PKCS-7', the only acceptable values for this field are 'BASE64' or '8BIT'. Unless such a line is included, the rest of the message is assumed to be 8-bit. For 'Content-Privacy-Domain: PEM', the only acceptable value for this field is '7BIT', since PEM messages are already encoded for RFC-822 (and hence 7-bit) transport. For 'Content-Privacy-Domain: PGP', '8BIT', '7BIT', and 'BASE64' are acceptable to refer to respectively binary, ASCII-armored, and base- 64 recoded PGP messages (the last seems unlikely to be useful).
2.3.3. Content-Type Under normal conditions, the terminal encapsulated content (after all privacy enhancements have been removed) shall be considered to be an HTTP/1.0 message. In this case, there shall be a Content-Type line reading: Content-Type: application/http Rescorla, Schiffman [Page 6] Internet-Draft Secure HTTP It is intended that this type be registered with IANA as a MIME con- tent type. For backwards compatibility, 'application/x-http' is also acceptable. However, the terminal content may be of some other type provided that that type is properly indicated by the use of an appropriate Content-Type header line. In this case, the header fields for the last (most deeply encapsulated) HTTP message should be applied to the terminal content. It should be noted that unless the HTTP message from which the headers are taken is itself enveloped, then some pos- sibly sensitive information has been passed in the clear. This is a useful mechanism for passing pre-enhanced data (especially presigned data) without requiring that the HTTP headers themselves be pre-enhanced.
2.3.4. Prearranged-Key-Info This header line is intended to convey information about a key which has been arranged in some way 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 document defines three methods for exchanging named keys, Inband, Kerberos and Outband. Inband and Kerberos 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:= '4' | '5' While chaining ciphers require an Initialization Vector (IV) [16] to start off the chaining, that information is not carried by this field. Rather, it should be passed internal to the cryptographic for- mat being used. Likewise, the bulk cipher used is specified in this fashion. should be the name of the block cipher used to encrypt Rescorla, Schiffman [Page 7] Internet-Draft Secure HTTP the session key (see section 4.4.7). should be to the protected Data Exchange Key (a.k.a. transaction key) under which the (following) message was encrypted. It should be 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. In order to avoid name collisions, cover key namespaces must be main- tained separately by host and port.
2.3.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 SHTTP message. Given a hash algorithm H, the MAC should be computed with ('||' means concatenation): MAC = hex(H(Message||||)) The time should be represented as an unsigned 32 bit quantity representing seconds since the UNIX epoch, in network byte order. The shared key format is a purely local matter. The format of the MAC-Info line is: MAC-Info: [hex(),], hex(), := "unsigned seconds since Unix epoch" := "hash algorithms from section 4.4.5" := "computation as described above" := 'null' | 'dek' | Key-Ids can refer either to keys bound using the Key-Assign header line or those bound in the same fashion as the Outband method described later. The use of a 'Null' key-spec implies that a zero length key was used, and therefore that the MAC merely represents a hash of the message text and (optionally) the time. The special key-spec 'DEK' refers to the Data Exchange Key used to encrypt the following message body (it is an error to use this key-spec in situa- tions where the following message body is unencrypted). Note that this header line can be used to provide a more advanced version of the original HTTP Basic authentication mode in that the user can be made to provide a username and password. However, the Rescorla, Schiffman [Page 8] Internet-Draft Secure HTTP password remains private and message integrity can be assured. More- over, this can be accomplished without encryption of any kind. In addition, MAC-Info permits fast message integrity verification (at the loss of non-repudiability) for messages, provided that the parti- cipants share a key (possibly passed using Key-Assign). The MAC-Info mechanism was not described in draft 24, but was sup- ported in the author's implementation of S-HTTP/1.0.
2.4. Content The content of the message is largely dependent upon the values of the Content-Privacy-Domain and Content-Transfer-Encoding fields. For a PKCS-7 message, with '8BIT' Content-Transfer-Encoding, the con- tent should simply be the message itself. The same should be true for 8-bit or 7-bit encoded PGP messages (i.e., just the message as pro- duced by PGP). If the Content-Transfer-Encoding is 'BASE64', the content should be preceded by a line that reads: -----BEGIN PRIVACY-ENHANCED MESSAGE----- and followed by a line that reads -----END PRIVACY-ENHANCED MESSAGE----- (see RFC1421) with the content simply being the base-64 representa- tion of original content. If the inner (protected) content is itself a PKCS-7 message, than the ContentType of the outer content should be set appropriately. Else, the ContentType should be represented as 'Data'. If the Content-Privacy-Domain is PEM, the content should consist of a normal encapsulated message, beginning with: -----BEGIN PRIVACY-ENHANCED MESSAGE----- and ending with -----END PRIVACY-ENHANCED MESSAGE----- as defined in RFC1421. It is expected that once the privacy enhancements have been removed, the resulting (possibly protected) contents will be a normal HTTP Rescorla, Schiffman [Page 9] Internet-Draft Secure HTTP request. Alternately, the content may be another Secure-HTTP request, in which case privacy enhancements should be unwrapped until clear content is obtained or privacy enhancements can no longer be removed. (This permits embedding of enhancements, as in, for instance, sequen- tial Signed and Enveloped enhancements.) Provided that all enhance- ments can be removed, the final de-enhanced content should be a valid HTTP request/response unless otherwise specified by the Content-Type line. 3. Message Format Options
3.1. Content-Privacy-Domain: PKCS-7 Content-Privacy-Domain 'PKCS-7' follows the form of the PKCS-7 stan- dard (see Appendix). Message protection may proceed on two orthogonal axes: signature and encryption. Any message may be either signed, encrypted, both, or neither. In addition, provision has been made for prearranged keys in order to send to those who have no key pair.
3.1.1. Signature If the digital signature enhancement is applied, an appropriate cer- tificate may either be attached to the message (possibly along with a certificate chain) as specified in PKCS-7 or the sender may expect the recipient to obtain its certificate (and/or chain) independently. Note that an explicitly allowed instance of this is a certificate signed with the private component corresponding to the public com- ponent being attested to. This shall be referred to as a self-signed certificate. What, if any, weight to give to such a certificate is a purely local matter. In either case, a purely signed message is pre- cisely PKCS-7 compliant.
3.1.2. Encryption
3.1.2.1. Encryption -- normal, public key This enhancement is performed precisely as enveloping under PKCS-7. A message encrypted in this fashion, signed or otherwise, is PKCS-7 compliant.
3.1.2.2. Encryption -- prearranged key This uses the "EncryptedData" type of PKCS-7. In this mode, we encrypt the content using a DEK encrypted under cover of a prear- ranged session key (how this key may be exchanged is discussed later), with key identification information specified on one of the Rescorla, Schiffman [Page 10] Internet-Draft Secure HTTP header lines. The IV is in the EncryptedContentInfo type of the EncryptedData element. To generate signed, encrypted data, it is necessary to generate the SignedData production and then encrypt it.
3.2. Content-Privacy-Domain: PEM/PGP These Content-Privacy-Domains simply refer to using straight PEM or PGP messages as per section 2.3.1. Note that clients and servers which implement the original HTTP access authorization protocols (as proposed by Tony Sanders and originally implemented by Rob McCool) can be converted to use S-HTTP (using these Content-Privacy-Domains) simply by changing the request/results lines to match S-HTTP and by adding the following three lines to the header: Content-Privacy-Domain: PEM (or PGP) Content-Type: application/http Content-Transfer-Encoding: 7BIT It would be helpful (but not necessary) to remove the 'authorization' line. No cryptographic transformations are necessary.
4. Negotiation
4.1. Negotiation Overview Both parties should be able to express their requirements and prefer- ences regarding what cryptographic enhancements they will permit/require the other party to provide. The appropriate option choices will depend on implementation capabilities and the require- ments of particular applications. A negotiation block is a sequence of specifications each conforming to a four-part schema detailing: Property -- the option being negotiated, such as bulk encryption algorithm. Value -- the value being discussed for the property, such as DES-CBC Direction -- the direction which is to be affected, namely: during reception or origination (with respect to the nego- tiator). Strength -- strength of preference, namely: required, optional, refused Rescorla, Schiffman [Page 11] Internet-Draft Secure HTTP As an example, the negotiation header: SHTTP-Symmetric-Content-Algorithms: recv-optional=DES-CBC,RC4 could be thought to say: ``You are free to use DES-CBC or RC4 for bulk encryption.'' We define new header lines lines (to be used in the encapsulated HTTP header, not in the S-HTTP header) to permit negotiation of these matters.
4.2. Negotiation Header Format The general format for negotiation header lines is: value indicates whether this refers to what the agent's actions are upon sending privacy enhanced messages as opposed to upon receiving them. For any given mode-action pair, the interpre- tation to be placed on the enhancements (s) listed is: 'recv-optional:' The agent will process the enhancement if the other party uses it, but will also gladly process mes- sages without the enhancement. 'recv-required:' The agent will not process messages without this enhancement. 'recv-refused:' The agent will not process messages with this enhancement. 'orig-optional:' When encountering an agent which refuses this enhancement, the agent will not provide it, and when encountering an agent which requires it, this agent will provide it. 'orig-required:' The agent will always generate the enhancement. 'orig-refused:' The agent will never generate the enhance- ment. The behavior of agents which discover that they are communicating Rescorla, Schiffman [Page 12] Internet-Draft Secure HTTP with an incompatible agent is at the discretion of the agents. It is inappropriate to blindly persist in a behavior that is known to be unacceptable to the other party. Plausible responses include simply terminating the connection, or, in the case of a server response, returning 'Not implemented 501'. Optional values are considered to be listed in decreasing order of preference. Agents are free to choose any member of the intersection of the optional lists (or none) however. .
4.4. Negotiation Headers
4.4.1. SHTTP-Privacy-Domains This header line refers to the Content-Privacy-Domain type of section 2.3.1. Acceptable values are as listed there. For instance, Rescorla, Schiffman [Page 13] Internet-Draft Secure HTTP SHTTP-Privacy-Domains: orig-required=pkcs-7; recv-optional=pkcs-7,pem would indicate that the agent always generates PKCS-7 compliant mes- sages, but can read PKCS-7 or PEM (or, unenhanced messages). All the negotiation headers described below can be considered to apply to all privacy domains (message formats) or to a particular one. To specify negotiation parameters which apply to all privacy domains, those header line(s) should be provided before any privacy- domain specifier. Negotiation headers which follow a privacy-domain header are considered to apply only to that domain. Multiple privacy-domain headers specifying the same privacy domain are permit- ted, in order to support multiple parameter combinations. 4.4.2. SHTTP-Certificate-Types This indicates what sort of Public Key certificates the agent will accept. This is somewhat (but not completely) orthogonal to SHTTP- Privacy-Domains. It seems strange but not unbelievable to accept PKCS-6 Extended Certificates for a PEM formatted message. Defined values include 'X.509', and 'PKCS-6' to refer respectively to X.509 [3] certificates and the extended format of PKCS-6 [5].
4.4.3. SHTTP-Key-Exchange-Algorithms This line indicates which
algorithms may be used for key exchange. Defined values are 'RSA',
'Outband', 'Inband', and 'Krb-'
4.4.4. SHTTP-Signature-Algorithms This indicates what Digital
Signature algorithms may be used. Defined values are 'RSA' and
'NIST-DSS' [17]. Since NIST-DSS and RSA use variable length moduli
the parametrization syntax of section 4.3 Rescorla, Schiffman
[Page 14] Internet-Draft Secure HTTP should be used. Note that
a key length specification may interact with the acceptability
of a given certificate, since keys (and their lengths) are specified
in public-key certificates.
4.4.5. SHTTP-Message-Digest-Algorithms This indicates what message
digest algorithms may be used. Defined values are 'RSA-MD2' [7],
'RSA-MD5' [8], and 'NIST-SHS' [9]. 4.4.6. SHTTP-Symmetric-Content-Algorithms
This header specifies the symmetric-key bulk cipher used to encrypt
message content. Defined values are: DES-CBC -- DES in Cipher
Block Chaining (CBC) mode (FIPS 81 [11]) DES-EDE-CBC -- 2 Key
3DES using Encrypt-Decrypt-Encrypt in CBC mode DES-EDE3-CBC --
3 Key 3DES using Encrypt-Decrypt-Encrypt in CBC mode DESX-CBC
-- RSA's DESX in CBC mode IDEA-CFB -- IDEA in Cipher Feedback
Mode [12] RC2-CBC -- RSA's RC2 in CBC mode RC4 -- RSA's RC4 CDMF-CBC
-- IBM's CDMF (weakened key DES) [20] in CBC mode Since RC2 and
RC4 keys are variable length, the syntax of section 4.3 should
be used.
4.4.7. SHTTP-Symmetric-Header-Algorithms This header specifies
the symmetric-key cipher used to encrypt mes- sage headers. DES-ECB
-- DES in Electronic Codebook (ECB) mode (FIPS 81 [11]) DES-EDE-ECB
-- 2 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode DES-EDE3-ECB
-- 3 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode DESX-ECB
-- RSA's DESX in ECB mode IDEA-ECB -- IDEA RC2-ECB -- RSA's RC2
in ECB mode CDMF-ECB -- IBM's CDMF in ECB mode Since RC2 is variable
length, the syntax of section 4.3 should be used.
4.4.8. SHTTP-Privacy-Enhancements This header indicates security
enhancements to apply. Possible values are 'sign', 'encrypt' and
'auth' indicating whether messages are signed, encrypted, or authenticated
(i.e., provided with a MAC), Rescorla, Schiffman [Page 15] Internet-Draft
Secure HTTP respectively.
4.4.9. Your-Key-Pattern This is a generalized pattern match syntax
for a large number of types of keying material. The general syntax
is: Your-Key-Pattern :
4.4.9.1. Cover Key Patterns This parameter specifies desired values
for key names used for encryption of transaction keys using the
Prearranged-Key-Info syntax of section 2.3.4. The pattern-info
syntax consists of a series of comma separated regular expressions.
Commas should be escaped with backslashes if they appear in the
regexps. The first pattern should be assumed to be the most preferred.
4.4.9.2. Auth key patterns Auth-key patterns specify name forms
desired for use for MAC authen- ticators. The pattern-info syntax
consists of a series of comma separated regular expressions. Commas
should be escaped with backslashes if they appear in the regexps.
The first pattern should be assumed to be the most preferred.
4.4.9.3. Signing Key Pattern This parameter describes a pattern
or patterns for what keys are acceptable for signing for the digital
signature enhancement. The pattern-info syntax for signing-key
is:
4.4.9.4. Kerberos ID Pattern This specifies acceptable Kerberos
realms for the sender of the mes- sage being referred to by the
negotiation headers. in the form of the name of a Kerberos entity;
i.e.,
4.4.10. Example A representative header block for a server follows.
SHTTP-Privacy-Domains: recv-optional=PEM, PKCS-7; orig-required=PKCS-7
SHTTP-Certificate-Types: recv-optional=X.509, PKCS-6; orig-required=X.509
SHTTP-Key-Exchange-Algorithms: recv-required=RSA; orig-optional=Inband,RSA
SHTTP-Signature-Algorithms: orig-required=RSA; recv-required=RSA
SHTTP-Privacy-Enhancements: orig-required=sign; orig-optional=encrypt
Rescorla, Schiffman [Page 17] Internet-Draft Secure HTTP
4.4.11. Defaults Explicit negotiation parameters take precedence
over default values. For a given negotiation header line type,
defaults for a given mode- action pair (such as 'orig-required')
are implicitly merged unless explicitly overridden. The default
values (these may be negotiated downward or upward) are: SHTTP-Privacy-Domains:
orig-optional=PKCS-7, PEM; recv-optional=PKCS-7, PEM SHTTP-Certificate-Types:
orig-optional=PKCS-6,X.509; recv-optional=PKCS-6,X.509 SHTTP-Key-Exchange-Algorithms:
orig-optional=RSA,Inband; recv-optional=RSA,Inband SHTTP-Signature-Algorithms:
orig-optional=RSA; recv-optional=RSA; SHTTP-Message-Digest-Algorithms:
orig-optional=MD5; recv-optional=MD5 SHTTP-Symmetric-Content-Algorithms:
orig-optional=DES-CBC; recv-optional=DES-CBC SHTTP-Symmetric-Header-Algorithms:
orig-optional=DES-ECB; recv-optional=DES-ECB SHTTP-Privacy-Enhancements:
orig-optional=sign,encrypt, auth; recv-required=encrypt; recv-optional=sign,
auth
5. New HTTP Header Lines We define a series of new header lines
which go in the HTTP header block (i.e., in the encapsulated content)
so that they may be crypto- graphically protected.
5.1. Security-Scheme This mandatory header line specifies the
version of the protocol (although it may be used by othe security
protocols). This header, with a value of 'S-HTTP/1.1' must be
generated by every agent to be compatible with this specification.
Security-Scheme is new to S- HTTP/1.1.
5.2. Encryption-Identity This header line identifies a potential
entity for whom the message described by these options could be
encrypted; this permits return encryption under (say) public key
without the other agent signing first (or under a different key
than that of the signature). Or, in the Kerberos case, provides
information as the agent's Kerberos Rescorla, Schiffman [Page
18] Internet-Draft Secure HTTP identity. The syntax of the Encryption-Identity
line is: Encryption-Identity:
5.2.1. DN-1485 Name Class The argument is an RFC-1485 encoded
DN. This mechanism corresponds to the Encryption-DN header of
S-HTTP/1.0. 5.2.2. KRB-* Name Class The argument is the name of
a Kerberos entity. i.e.
5.4.1. Inband Key Assignment This refers to the direct assignment
of an uncovered key to a sym- bolic name. Method-args should be
just the desired session key encoded in hexidecimal. E.g.: Key-Assign:
inband,akey,reply,DES-ECB;0123456789abcdef Short keys should be
derived from long keys by reading bits from left to right. Note
that inband key assignment is especially important in order to
permit confidential spontaneous communication between agents where
one (but not both) of the agents have key pairs. However, this
mechanism is also useful to permit key changes without public
key computations. The key information is carried in this header
line must be in the inner secured HTTP request, therefore use
in unencrypted messages is not permitted. Use of the Key-Assign
header with the inband method corresponds to the 'Inband-Key-Info:'
header of S-HTTP/1.0. 5.4.2. Kerberos Key Assignment This permits
the binding of the shared secret derived from a Kerberos ticket/authenticator
pair to a symbolic keyname. In this case, method-args should be
the ticket/authenticator pair (each base64- encoded), comma separated.
E.g.: Key-Assign: krb-4,akerbkey,reply,DES-ECB;
5.5. Nonces Nonces are opaque, transient, session-oriented identifiers
which may be used to provide demonstrations of freshness. Nonce
values are a local matter, although they are might well be simply
random numbers generated by the originator. The value is supplied
simply to be returned by the recipient. 5.5.1. Nonce This header
is used by an originator to specify what value is to be returned
in the reply. The field may be any value. Multiple nonce header
lines may be used, each to be echoed independently. Rescorla,
Schiffman [Page 21] Internet-Draft Secure HTTP An equivalent mechanism
for use in HTML anchors is described in sec- tion 7.2.2.
5.5.2. Nonce-Echo The header is used to return the value provided
in a previously received Nonce: field or HTML anchor attribute.
6. (Retriable) Server Status Error Reports We describe here the
special processing appropriate for client retries in the face
of servers returning an error status. This behavior was not defined
in S-HTTP/1.0.
6.1. Retry for Option (Re)Negotiation A server may respond to
a client request with an error code that indicates that the request
has not completely failed but rather that the client may possibly
achieve satisfaction through another request. HTTP already has
this concept with the 3XX redirection codes. In the case of SHTTP,
it is conceivable (and indeed likely) that the server expects
the client to retry his request using another set of cryptographic
options. E.g., the document which contains the anchor that the
client is dereferencing is old and did not require digital signature
for the request in question, but the server now has a pol- icy
requiring signature for dereferencing this URL. These options
should be carried in the header of the encapsulated HTTP message,
precisely as client options are carried. The general idea here
is that the client will perform the retry in the manner indicated
by the combination of the original request and the precise nature
of the error and the cryptographic enhancements depending on the
options carried in the server response. The guiding principle
in client response to these errors should be to provide the user
with the same sort of informed choice with regard to dereference
of these anchors as with normal anchor dereference. For instance,
in the case above, it would be inappropriate for the client to
sign the request without requesting permission for the action.
6.2. Specific Retry Behavior
6.2.1. Unauthorized 401, PaymentRequired 402 The HTTP errors 'Unauthorized
401', 'PaymentRequired 402' represent failures of HTTP style authentication
and payment schemes. While S- HTTP has no explicit support for
these mechanisms, they can be Rescorla, Schiffman [Page 22] Internet-Draft
Secure HTTP performed under S-HTTP while taking advantage of the
privacy services offered by S-HTTP. [There are other errors for
S-HTTP specific authentication errors.]
6.2.2. SecurityRetry 420 This server status reply is provided
so that the server may inform the client that although the current
request is rejected, a retried request with different cryptographic
enhancements is worth attempt- ing.
6.2.2.1. SecurityRetries for S-HTTP Requests In the case of a
request that was made as an SHTTP request, it indi- cates that
for some reason the cryptographic enhancements applied to the
request were unsatisfactory and that the request should be repeated
with the options found in the response header. Note that this
can be used as a way to force a new public key negotiation if
the session key in use has expired or to supply a unique nonce
for the purposes of ensuring request freshness.
6.2.2.2. SecurityRetries for HTTP Requests If this header is made
in response to an HTTP request, it indicates that the request
should be retried using S-HTTP and the cryptographic options indicated
in the response header.
6.2.3. BogusHeader 421 This error code indicates that something
about the S-HTTP request was bad. The error code is to be followed
by an appropriate explanation, e.g.: BogusHeader 421 Content-Privacy-Domain
must be specified
6.2.4. Redirection 3XX These headers are again internal to HTTP,
but may contain S-HTTP negotiation options of significance to
S-HTTP. The request should be redirected in the sense of HTTP,
with appropriate cryptographic pre- cautions being observed.
6.3. Limitations On Automatic Retries Permitting automatic client
retry in response to this sort of server response permits several
forms of attack. Consider for the moment the simple credit card
case: Rescorla, Schiffman [Page 23] Internet-Draft Secure HTTP
The user views a document which requires his credit card. The
user verifies that the DN of the intended recipient is acceptable
and that the request will be encrypted and dereferences the anchor.
The attacker intercepts the server's reply and responds with a
message encrypted under the client's public key containing the
Moved 301 header. If the client were to automatically perform
this redirect it would allow compromise of the user's credit card.
6.3.1. Automatic Encryption Retry This shows one possible danger
of automatic retries -- potential compromise of encrypted information.
While it is impossible to con- sider all possible cases, clients
should never automatically reen- crypt data unless the server
requesting the retry proves that he already has the data. So,
situations in which it would be acceptable to reencrypt would
be if: 1. The retry response was returned encrypted under an inband
key freshly generated for the original request. 2. The retry response
was signed by the intended recipient of the original request.
3. The original request used an outband key and the response is
encrypted under that key. This is not an exhaustive list, however
the browser author would be well advised to consider carefully
before implementing automatic reencryption in other cases. Note
that an appropriate behavior in cases where automatic reencryption
is not appropriate is to query the user for permission.
6.3.2. Automatic Signature Retry Since we discourage automatic
(without user confirmation) signing in even the usual case, and
given the dangers described above, it is prohibited to automatically
retry signature enchancement. 6.3.3. Automatic MAC Authentication
Retry Assuming that all the other conditions are followed, it
is permiss- able to automatically retry MAC authentication.
7. Other Issues
7.1. Compatibility of Servers with Old Clients Servers which receive
requests in the clear which should be secured Rescorla, Schiffman
[Page 24] Internet-Draft Secure HTTP should return 'Unauthorized
401' with header lines set to indicate the required privacy enhancements.
7.2. HTML and URL Format Extensions Although this document describes
extensions to the HTTP protocol, we include here extensions to
the HyperText Markup Language [15] (the native document format
of the WWW) and Universal Resource Locators [16] which is needed
to support secure dereferencing of anchors (hyperlinks).
7.2.1. URL Protocol Type We define a new URL protocol designator,
'shttp'. Use of this desig- nator as part of an anchor URL implies
that the target server is S- HTTP capable, and that a dereference
of this URL should be enveloped (e.g., the request is to be encrypted).
Use of these secure URLs permit the additional anchor attributes
described in the following section. Note that S-HTTP oblivious
agents will not be willing to dereference a URL with an unknown
protocol specifier, and hence sensitive data will not be accidentally
sent in the clear by users of non-secure clients.
7.2.2. AncHor Attributes We define the following new anchor (and
form submission) attributes: DN -- The distinguished name of the
principal who will sign the reply to the dereferenced URL. This
need not be speci- fied, but failure to do so runs the risk that
the client will be unable to determine the DN and therefore will
be unable to encrypt. (See section 7.3.1 for another way for clients
to get DNs/certificates). This should be specified in the form
of RFC1485, using SGML quoting conventions as needed. NONCE --
A free-format string (appropriately SGML quoted) which is to be
included in a SHTTP-Nonce: header (after SGML quoting is removed)
when the anchor is dereferenced (see section 4.5). CRYPTOPTS --
The cryptographic option information from sec- tion 4. If multiline,
this must be quoted to protect the line break information. Rescorla,
Schiffman [Page 25] Internet-Draft Secure HTTP
7.2.3. CERTS Element A new CERTS HTML element is defined, which
carries a (not necessarily related) group of certificates provided
as advisory data. The element contents are not intended to be
displayed to the user. Certificate groups may be provided appropriate
for either PEM or PKCS-7 implemen- tations. Such certificates
are supplied in the HTML document for the convenience of the recipient,
who might otherwise be unable to retrieve the certificate (chain)
corresponding to a DN specified in an anchor. The format should
be the same as that of the 'Certificate-Info' header line, (see
section 5.3) except that the
7.2.5. HTML Example An example of cryptographic data embedded
in an anchor, proceeded by a certificate group is provided below.
Note the SGML quoting syntax used to supply embedded quotation
marks. Rescorla, Schiffman [Page 26] Internet-Draft Secure HTTP
7.3. Server Conventions
7.3.1. Certificate Requests We define the convention that issuing
a normal HTTP request: GET /SERVER-CERTIFICATE[-
7.3.2. Policy Requests Servers should (but not must) store the
policies of the Policy Cer- tification Authorities, if available,
corresponding to their various certificates. The convention for
retrieving such policies via HTTP is the request: GET /POLICY-
7.3.3. CRL Requests Servers should (but not must) store the CRLs
of the PCAs correspond- ing to their various certificates. The
convention for retrieving such CRLs is: GET /CRL-
7.4. Browser Presentation
7.4.1. Transaction Security Status While preparing a secure message,
the browser should provide a visual indication of the security
of the transaction, as well as an indica- tion of the party who
will be able to read the message. While reading a signed and/or
enveloped message, the browser should indicate this and (if applicable)
the identity of the signer. Self-signed certifi- cates should
be clearly differentiated from those validated by a cer- tification
hierarchy.
7.4.2. Failure Reporting Failure to authenticate or decrypt an
S-HTTP message should be presented differently from a failure
to retrieve the document. Com- pliant clients may at their option
display unverifiable documents but must clearly indicate that
they were unverifiable in a way clearly distinct from the manner
in which they display documents which pos- sessed no digital signatures
or documents with verifiable signatures. Rescorla, Schiffman [Page
28] Internet-Draft Secure HTTP
7.4.3. Certificate Management Clients shall provide a method
for determining that HTTP requests are to be signed and for determining
which (assuming there are many) cer- tificate is to be used for
signature. It is suggested that users be presented with some sort
of selection list from which they may choose a default. No signing
should be performed without some sort of expli- cit user interface
action, though such action may take the form of a persistent setting
via a user preferences mechanism (although this is not recommended).
7.4.4. Anchor Dereference Clients shall provide a method to display
the DN and certificate chain associated with a given anchor to
be dereferenced so that users may determine for whom their data
is being encrypted. This should be distinct from the method for
displaying who has signed the document containing the anchor since
these are orthogonal pieces of encryption information.
8. ImpLementation Recommendations and Requirements All S-HTTP
agents must support the MD5 message digest and MAC auten- tication.
All S-HTTP agents must support one of the following external key
exchange methods: RSA enveloping, Outband and Kerberos. Support
for encryption is recommended; agents which implement encryp-
tion must support the in-band key exchange method and one of the
fol- lowing three cryptosystems (in ECB and CBC modes): DES, RC2[40]
and CDMF. Agents are recommended to support signature verification;
server sup- port of signature generation is additionally recommended.
Note that conformant implementations of the protocol (although
not recommended ones) can avoid the use of public key cryptography
entirely.
9. Protocol Syntax Summary We present below a summary of the main
syntactic features of S- HTTP/1.1, excluding message encapsulation
proper. Facilities new or significantly changed for version 1.1
of the protocol are prefixed with a plus ('+') symbol. Rescorla,
Schiffman [Page 29] Internet-Draft Secure HTTP
9.1. S-HTTP (Unencapsulated) Headers Content-Privacy-Domain: ('PKCS-7'
| 'PEM' | 'PGP') Content-Transfer-Encoding: ('8BIT' | '7BIT' |
'BASE64') Prearranged-Key-Info: :
9.3. Encapsulated Negotiation Headers SHTTP-Privacy-Domains: ('PKCS-7'
| 'PEM' | 'PGP') SHTTP-Certificate-Types: ('PKCS-6' | 'X.509')
SHTTP-Key-Exchange-Algorithms: ('RSA' | 'KRB-'
9.4. HTTP Methods Secure * Secure-HTTP/1.1
9.5. Server Status Reports Secure-HTTP/1.1 200 OK + SecurityRetry
420 + BogusHeader 421
9.6. HTML Anchor Attributes DN=<1485-string> NONCE=
9.7. HTML Elements CERTS FMT= ('PKCS-7' | 'PEM') + CRYPTOPTS NAME=#
9.8. Server Conventions GET SERVER-CERTIFICATE-
10. Future Work
10.1. Interaction with Other Standards
10.1.1. Cryptosystems Aficionados may note the conspicuous absence
of support for Diffie- Hellman key agreement. We believe it has
a role in the protocol, but will plan to defer inclusion of D-H
until there are appropriate stan- dards for D-H certificates.
10.1.2. Encapsulation Formats This version of the protocol explicitly
accomodates PEM as defined by RFC-1421. It is expected that a
new version of PEM which integrates well with MIME will be standardized
soon. We plan to make the modest revisions necessary in the protocol
to accomodate the new standard.
10.2. Interaction with Future Versions of HTTP Secure HTTP interacts
with some recent advances in HTTP (both pro- posed and accomplished)
in a number of ways that could be improved. Current implementations
of caching proxies become useless in the face of message encryption.
Also, since message integrity is computed on the entire message,
performance boosting schemes based on packetizing messages and
multiplexing them over a single message stream is prob- lematic.
Finally, the S-HTTP negotiation headers aggravate the ver- bose
nature of HTTP. These issues are discussed below.
10.2.1. Interaction with Caching HTTP Proxies It is straightforward
to support caching with S-HTTP if the proxy server is trusted,
but open issues remain. Imagine that the proxy has already performed
a fetch which was Rescorla, Schiffman [Page 31] Internet-Draft
Secure HTTP enveloped for a client using said client's public
key. Provided that the encrypted document is still in the proxy's
cache, all the server needs to provide when a new client asks
for the same document is the original DEK encrypted under the
new client's public key. The proxy can then assemble a new message
for the client himself. We plan for the next version of S-HTTP
to provide syntax for proxies to request this shortcut response
and servers to provide it, along the line of CERN's Shen proposal.
10.2.2. Accomodating New Transport Facilities A common HTTP client-server
interaction consists of a large number of HTTP request replies
between the same client server pair in close succession. In an
attempt to take advantage of this, it has been sug- gested that
requests be packetized and that multiple data streams be multiplexed
on the same TCP stream. However, since S-HTTP's message integrity
verification is message based, one can only determine that a message
was correctly received when all packets in the stream have been
received (though then you can be certain). Given a future ver-
sion of HTTP which provides for these transport enhancements,
a future version of S-HTTP should support packetization of encrypted
data and incremental integrity checking.
10.2.3. Compression of Negotiation Headers The S-HTTP negotiation
syntax provides extensive control over privacy enhancement options,
is straightforward to implement, and aids debug- ging by being
human-readable. Still, we believe that in practice only a small
portion of the avail- able option space, corresponding to a few
common implementation pro- files and application needs, will typically
be used. We intend to provide a highly compressed negotiation
syntax that allows the common options to be represented while
saving bandwidth (and thus modestly increase performance). Rescorla,
Schiffman [Page 32] Internet-Draft Secure HTTP Appendix: A Review
of PKCS-7 PKCS-7 ("Cryptographic Message Syntax Standard")
is a cryptographic message encapsulation format, similar to PEM,
which was defined by RSA Laboratories as part of a family of related
standards. They state: "The PKCS standards are offered by
RSA Laboratories to developers of computer systems employing public
key cryptography. It is RSA Laboratories' intention to improve
and refine the standards in conjunction with computer system developers,
with the goal of produc- ing standards that most if not all developers
adopt." PKCS-7 is only one of three encapsulation formats
supported by S- HTTP, but it is to be preferred since it permits
the least restricted set of negotiable options, and permits binary
encoding. In the interest of making this specification more self-contained,
we summar- ize PKCS-7 here. PKCS-7 is a superset of PEM, in that
PEM messages can be converted to PKCS-7 messages without any cryptographic
operations, and vice-versa (given PKCS-7 messages which are restricted
to PEM facilities). Additionally, PEM key management materials
such as certificates and certificate revocation lists are compatible
with PKCS-7's. PKCS-7 is defined in terms of OSI's Abstract Syntax
Notation (ASN.1, defined in X.208), and is concretely represented
using ASN.1's Basic Encoding Rules (BER, defined in X.209). A
PKCS-7 message is a sequence of typed content parts. There are
six content types, recur- sively composable: Data -- Some bytes,
with no enhancement. SignedData -- A content part, with zero or
more signature blocks, and associated keying materials. Keying
materials can be transported via the degenerate case of no signature
blocks and no data. EnvelopedData -- One or more (per recipent)
key exchange blocks and an encrypted content part. SignedAndEnvelopedData
-- The obvious combination of SignedData and EnvelopedData for
a single content part. DigestedData -- A content part with a single
digest block. EncryptedData -- An encrypted content part, with
key materials externally provided. Here we will dispense with
convention for the sake of ASN.1-impaired Rescorla, Schiffman
[Page 33] Internet-Draft Secure HTTP readers, and present a syntax
for PKCS-7 in informal BNF (with much gloss). In the actual encoding,
most productions have explicit tag and length fields. Rescorla,
Schiffman [Page 34] Internet-Draft Secure HTTP References [1]
Linn J. "Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures",
RFC1421, Feb 1993. [2] RSA Data Security, Inc. "Cryptographic
Message Syntax Standard", PKCS-7, Nov 1, 1993. [3] CCITT
Recommendation X.509 (1988), "The Directory - Authentication
Framework". [4] Kent, S. "Privacy Enhancement for Internet
Electronic Mail: Part II: Certificate-Based Key Management",
RFC1422, Feb 1993. [5] RSA Data Security, Inc. "Extended
Certificate Syntax Standard", PKCS-6, Nov 1, 1993. [6] Crocker,
D. "Standard For The Format Of ARPA Internet Text Messages",
RFC822, August 1982. [7] Kaliski, B. "The MD2 Message-Digest
Algorithm", RFC1319, April 1992 [8] Rivest, R. "The
MD5 Message-Digest Algorithm", RFC1321, April 1992 [9] Federal
Information Processing Standards Publication (FIPS PUB) 180, "Secure
Hash Standard", 1993 May 11. [10] Federal Information Processing
Standards Publication (FIPS PUB) 46-1, Data Encryption Standard,
Reaffirmed 1988 January 22 (supersedes FIPS PUB 46, 1977 January
15). [11] Federal Information Processing Standards Publication
(FIPS PUB) 81, DES Modes of Operation, 1980 December 2. [12] Lai,
X. "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz: Hartung-Gorre
Verlag, 1992. [13] Hardcastle-Kille, S. "A String Representation
of Distinguished Names", RFC1485, July 1993. [14] pgformat.doc
(v 2.6). This can be obtained from net-dist.mit.edu/pub/PGP. [15]
Berners-Lee, T. "Hypertext Markup Language (HTML)",
draft-ieft-iiir-html-01, June 1993. (expired working draft) [16]
Berners-Lee, T. "Uniform Resource Locators (URLs)",
Rescorla, Schiffman [Page 35] Internet-Draft Secure HTTP draft-ieftf-uri-url-03,
Mar 1994. (expired working draft) [17] Federal Information Processing
Standards Publication (FIPS PUB) 186, Digital Sigature Standard,
1994 May 19. [18] Berners-Lee, T., Fielding, R. T., Nielsen, H.,
"Hypertext Transfer Protocol -- HTTP/1.0", draft-fielding-http-spec-0.0,
1994 Nov 28. (working draft) [19] Kohl, J., and Neuman, C., "The
Kerberos Authentication Service (V5)", RFC1510, September
1993. [20] Johnson, D.B., Matyas, S.M., Le, A.V., Wilkins, J.D.,
"Design of the Commercial Data Masking Facility Data Privacy
Algorithm," Proceedings 1st ACM Conference on Computer &
Communications Security, November 1993, Fairfax, VA., pp. 93-96.
Security Considerations This entire document is about security.
Acknowledgements The authors wish to thank our colleagues at RSA
Data Security, TIS, HP Labs Bristol, NCSA, Spyglass, CERN, EIT
and elsewhere for their review of earlier drafts. This work was
funded in part by the ARPA MADE (Manufacturing Automa- tion and
Design Engineering) program, under contract management by the
USAF Wright Laboratory. In addition to the funding support, we
appreciate the administrative and intellectual resources of the
spon- sors and the research community they maintain. Authors'
Address Eric Rescorla