4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`INTERNET—DRAFT
`
`Enterprise Integration Technologies
`
`<draft—ietf—wts—shttp—O1.txt>
`
`Feb 1996 (Expires August—96)
`
`E. Rescorla, A. Schiffman
`
`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
`
`(Europe),
`Directories on ftp.is.co.za (Africa), nic.nordu.net
`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.2. The original draft of
`
`this specification, defining S—HTTP version 1.0, was distributed by
`the CommerceNet Consortium in June 1994;
`in December 1994 a revised
`
`specification describing S—HTTP version 1.1 was published as an
`
`Internet Draft
`
`(draft—rescorla—shttp—OO.txt).
`
`In July 1995, an
`
`updated version of that draft was published as an Internet Draft.
`
`That document deprecated some unimplemented facilities, provides
`
`additional clarifying material, and made minor corrections to the
`12/94 version.
`
`This document
`
`implements a decision reached at the December 1995 IETF
`
`WTS meeting to break up the single S—HTTP document into two docu-
`
`ments, one describing the S—HTTP messaging protocol and negotiation
`
`syntax and one describing extensions to HTML to facilitate the use of
`
`S—HTTP. The companion document is draft—ietf—wts—shtml—OO.txt
`
`[23].
`
`Abstract
`
`This memo describes a syntax for securing messages sent using the
`
`(HTTP), which forms the basis for the
`Hypertext Transfer Protocol
`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.
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`1/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 1]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`2/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Internet—Draft
`
`Secure HTTP
`
`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.
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`3/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 2]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`4/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Int
`
`ernet—Draft
`
`Secure HTTP
`
`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)
`
`[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. 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, 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 HTTP.
`
`Several cryptographic message format standards may be incorporated
`
`into S-HTTP clients and servers, particularly, but in principle not
`
`limited to, PKCS—7 and PEM. S-HTTP supports interoperation among a
`
`S-HTTP
`variety of implementations, and is compatible with 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 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 is able to take advantage of ubiquitous
`
`certification infrastructures, its deployment does not require it.
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`5/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 3]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`6/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Int
`
`ernet—Draft
`
`Secure HTTP
`
`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 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.
`
`Changes
`
`This document describes S—HTTP/1.2. The prior draft described S-
`
`HTTP/l.l. This version adds a number of minor changes,
`
`including a
`
`new hash construction and a new way of binding cryptographic parame-
`
`ters to HTML anchors. S—HTTP/1.2 messages will be readable by S-
`
`HTTP/l.l agents and vice versa, provided that compatible algorithms
`are used.
`
`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
`
`data object.
`
`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 merges the
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`7/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 4]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`8/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Internet—Draft
`
`Secure HTTP
`
`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 inter-
`
`vention. For instance,
`
`there might be multiple keys available to sign
`
`the message.
`
`(See Section 7 for more on this topic.) Using this data,
`
`the sender applies the enhancements to the message cleartext 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 4 and 5.
`
`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.
`4 and 5 for details on how to do this.)
`
`(Again, see sections
`
`In order to recover an S—HTTP message,
`
`the receiver needs to read the
`
`headers and discover what sorts of cryptographic transformations were
`performed on the message,
`then remove them using some combination of
`
`the sender's and receiver's keying material,
`
`in the process while
`
`taking note of what 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 7 for more on this topic.)
`
`1.4. Modes of Operation
`
`Message protection may be provided on three orthogonal axes:
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`9/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 5]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`10/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Internet—Draft
`
`Secure HTTP
`
`signature, 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
`
`[l9]
`
`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.4.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.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.
`
`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.4.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
`b ias that the action of "signing" a transaction should be explicit
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`11/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 6]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`12/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Int
`
`ernet—Draft
`
`Secure HTTP
`
`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 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.5.
`
`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,
`
`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.
`
`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-
`
`('Secure-HTTP/1.2'). However, if a future
`tinct protocol designator
`version of HTTP (i.e.,
`'HTTP/2.0‘)
`subsumes this document use of a
`
`new protocol HTTP designator would provide the same backwards compa-
`
`tibility function and a distinction between such a future version of
`
`HTTP and Secure—HTTP would be unnecessary.
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`13/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 7]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`14/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Internet—Draft
`
`Secure HTTP
`
`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.2
`
`All case variations should be accepted. The asterisk shown here is a
`
`placeholder and should be ignored by servers; proxy—aware clients
`
`should substitute the URL (and must provide at least the host+port
`
`portion) of the request when communicating via proxy, as is the
`
`current HTTP convention;
`
`(e.g. http://www.terisa.com/*) proxies
`
`should remove the appropriate amount of this information to minimize
`
`the threat of traffic analysis.
`
`See Section 8.2.2.1 for a situation
`
`where providing more information is appropriate.
`
`2.2.
`
`The Status Line
`
`For server responses,
`
`the first line should be:
`
`Secure—HTTP/1.2 200 OK
`
`whether the request succeeded or failed. This prevents analysis of
`
`success or failure for any request. All case variations should be
`accepted.
`
`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.
`
`A_l 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].
`
`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.3.1. Content—Privacy—Domain
`
`This header line exists to provide compatibility with PEM—based
`
`Secure HTTP systems. The two values defined by this document are
`
`'PEM' and ‘PKCS—7’.
`
`PKCS—7
`
`[2] refers to the privacy enhancement
`
`specified in section 3. PEM refers to standard PEM message format as
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`15/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 8]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`16/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Internet—Draft
`
`Secure HTTP
`
`defined in RFCl42l
`
`[1]. Note that MOSS[25] could be accomodated sim-
`
`ply by adding a Content—Privacy—Domain: MOSS.
`
`2.3.2. Content—Transfer—Encoding
`
`The PKCS-7 message format is designed for an 8-bit clear channel, but
`
`may be passed over other channels using base—64 encoding (see RFCl42l
`
`[l] for a description of base—64).
`
`'Content—Privacy—Domain: PKCS—7', acceptable acceptable values
`For
`for this field are 'BASE64','8BIT', or ‘BINARY’. Unless such a line
`
`(Note
`the rest of the message is assumed to be ‘BINARY’.
`is included,
`that the difference between ‘BINARY’ and '8BIT' has to do with line
`
`length.)
`
`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.
`
`2.3.3. Content—Type
`
`the terminal encapsulated content (after all
`Under normal conditions,
`privacy enhancements have been removed) shall be considered to be an
`
`HTTP/1.0 message.
`reading:
`
`In this case,
`
`there shall be a Content—Type line
`
`Content—Type: application/http
`
`It is intended that this type be registered with IANA as a MIME con-
`
`tent type. For backwards compatibility,
`acceptable.
`
`‘application/x—http'
`
`is also
`
`the terminal content may be of some other type provided that
`However,
`that type is properly indicated by the use of an appropriate
`
`the header fields for the
`In this case,
`Content—Type header line.
`last
`(most deeply encapsulated) HTTP or S-HTTP message should be
`
`applied to the terminal content.
`
`It should be noted that unless the
`
`(S—)HTTP message from which the headers are taken is itself
`
`then some possibly sensitive information has been passed
`enveloped,
`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
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`17/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 9]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`18/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Internet—Draft
`
`Secure HTTP
`
`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 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: <Hdr—Cipher>‘,‘<CoveredDEK>’,‘<CoverKey-ID>
`<CoverKey-ID> := <method>‘:'<key-name>
`
`<CoveredDEK> := <hex—digits>
`<method> := 'inband'
`I
`'krb—'<kv> |
`<kv> := '4'
`I
`'5'
`
`'outband'
`
`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,
`fashion.
`
`the bulk cipher used is specified in this
`
`<Hdr—Cipher> should be the name of the block cipher used to encrypt
`
`the session key (see section 4.4.7).
`
`<CoveredDEK> is the protected Data Exchange 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.
`
`In order to avoid name collisions, cover key namespaces must be main-
`
`tained separately by host and port.
`
`2.3.5. MmC—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
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`19/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 10]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`20/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Internet—Draft
`
`Secure HTTP
`
`concatenation):
`
`MAC = hex(H(Message||[<time>]||<shared key>))
`
`The time should be represented as an unsigned 32 bit quantity
`
`representing seconds since 00:00:00 GMT January 1, 1970 (the UNIX
`
`epoch),
`matter.
`
`in network byte order. The shared key format is a local
`
`Recent research [2l] has demonstrated some insecurities in this
`
`approach, and this draft introduces a new construction.
`
`In the name
`
`of backwards compatibility, we retain the previous constructions with
`the same names as before. However, we also introduce a new series of
`
`names
`
`(See Section 2.3.5 for the names)
`
`that obey a different
`
`(hope-
`
`fully stronger) construction.
`
`MAC = hex(H(K'
`
`II pad2 || H(K'
`
`II padl
`
`||[<time>] || Message)))
`
`padl = the byte 0x36 repeated enough times to fill out a
`
`hash input block.
`SHA)
`
`(I.e. 48 times for MD5, 44 for
`
`pad2 = the byte 0x5c repeated enough times to fill out a
`
`hash input block.
`K‘ = H(<shared key>)
`
`The original HMAC construction is for the use of a key with length
`
`equal to the length of the hash output. Although it is considered
`
`safe to use a key of a different length (Note that security cannot be
`
`increased past the length of the hash function itself, but can be
`
`reduced by using a shorter key.)
`
`[22] we hash the original key to
`
`permit the use of shared keys
`
`(e.g. passphrases)
`
`longer than the
`
`length of the hash. It is noteworthy (though obvious)
`nique does not increase the security of short keys.
`
`that this tech-
`
`The format of the MAC—Info line is:
`
`MAC—Info:
`
`[hex(<time>)],<hash—alg>, hex(<hash—data>),<key—spec>
`
`<time> := "unsigned seconds since Unix epoch"
`
`<hash—alg> := "hash algorithms from section 4.4.5"
`
`<hash—data> := "computation as described above"
`<Key-Spec> := ‘null’
`I
`'dek'
`| <Key—ID>
`
`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
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`21/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 11]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`22/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Internet—Draft
`
`Secure HTTP
`
`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).
`
`If the time is omitted from the MAC—Info line, it should simply not
`be included in the hash.
`
`Note that this header line can be used to provide a more advanced
`
`version of the original HTTP Basic authentication mode in that the
`
`the
`user can be made to provide a username and password. However,
`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).
`
`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 PKCS—7 message itself.
`
`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 RFCl42l) 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,
`‘Data’.
`
`the ContentType should be represented as
`
`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
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`23/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 12]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`24/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Internet—Draft
`
`Secure HTTP
`
`—————END PRIVZ-\CY—ENHANCED MESSAGE—————
`
`as defined in RFCl42l.
`
`It is expected that once the privacy enhancements have been removed,
`
`the resulting (possibly protected) contents will be a normal HTTP
`
`request. Alternately,
`
`the content may be another Secure—HTTP message,
`
`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
`
`(or response) unless otherwise specified by the
`
`Content—Type line.
`
`Note that this recursive encapsulation of messages potentially per-
`
`mits security enhancements to be applied (or removed)
`
`for the benefit
`
`of intermediaries who may be a party to the transaction between a
`
`client and server (e.g., a proxy requiring client authentication).
`
`How such intermediaries should indicate such processing is described
`in Section 6.2.4.
`
`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. Note that the 'auth' protection mode of S—HTTP is provided
`independently of PKCS—7 coding via the MAC—Info header of section
`
`2.3.5 since PKCS—7 does not support a 'KeyDigestedData'
`
`type,
`
`although it does support a 'DigestedData'
`
`type.
`
`3.1.1. Signature
`
`This enhancement uses the 'SignedData'
`
`(or
`
`'SignedAndEnvelopedData')
`
`type of PKCS—7. When digital signatures are used, an appropriate
`
`certificate 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 component being attested to. This shall be referred to as a
`
`self—signed certificate. What, if any, weight to give to such a
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`25/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Rescorla, Schiffman
`
`[Page 13]
`
`http://tools.ietf.org/html/draft-ietf-wts-shttp-01
`
`MANGROVE 1004
`
`26/99
`
`MANGROVE 1004
`
`

`
`4/7/2014
`
`draft-ietf-wts-shttp-01 - The Secure HyperText Transfer Protocol
`
`Internet—Draft
`
`Secure HTTP
`
`certificate is a purely local matter.
`
`In either case, a purely
`
`signed message is precisely PKCS-7 compliant.
`
`3.1.2. Encryption
`
`3.1.2.1. Encryption -- normal, public key
`
`This enhancement is performed precisely as enveloping (using either
`
`'EnvelopedData' or 'SignedAndEnvelopedData'
`
`types) 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
`
`header lines. The IV is in the Encryptedcontentlnfo type of the
`
`EncryptedData element.
`
`To generate signed, encrypted data, it is
`
`necessary to generate the 'SignedData' production and then encrypt it
`
`(since PKCS-7 does not support a 'SignedAndEncryptedData'
`
`type).
`
`3.2. Content—Privacy—Domain: PEM
`
`This Content—Privacy—Domain simply refers to using straight PEM mes-
`
`sages as per section 2.3.1. Note that clients and servers which
`
`implement the original HTTP access authorization protocols (as pro-
`
`posed by Tony Sanders and originally implemented by Rob