Skip to main content

Considerations for Web Transaction Security

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 2084.
Authors Greg Bossert , Simon P. Cooper , Walt F. Drummond III
Last updated 2013-03-02 (Latest revision 1996-03-13)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 2084 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
INTERNET-DRAFT                                                G. Bossert
Expires in six months                                          S. Cooper
                                                   Silicon Graphics Inc.
                                                             W. Drummond
                                                              IEEE, Inc.
                                                          February, 1996

                 Requirements for Web Transaction Security

   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.  Distribution of
     this memo is unlimited.

     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 (US East Coast), (Europe), (US West Coast), or (Pacific Rim).
     This document specifies the requirements for the provision of security
     services to the HyperText Transport Protocol.  These services include
     confidentiality, integrity, user authentication, and authentication of
     servers/services, including proxied or gatewayed services.  Such
     services may be provided as extensions to HTTP, or as an encapsulating
     security protocol.  Secondary requirements include ease of integration
     and support of multiple mechanisms for providing these services.
   1. Introduction
     The use of the HyperText Transport Protocol [1] to provide
     specialized or commercial services and personal or private data
     necessitates the development of secure versions that include
     privacy and authentication services.  Such services may be
     provided as extensions to HTTP, or as encapsulating security
     protocols; for the purposes of this document, all such
     enhancements will be referred to as WTS.
     In this document, we specify the requirements for WTS, with
     the intent of codifying perceived Internet-wide needs, along with
     existing practice, in a way that aids in the evaluation and
     development of such protocols.
     WTS is an enhancement to an object transport protocol.  As
     such, it does not provide independent certification of documents
     or other data objects outside of the scope of the transfer of
     said objects.  In addition, security at the WTS layer is
     independent of and orthogonal to security services provided at
     underlying network layers.  It is envisioned that WTS may
     coexist in a single transaction with such mechanisms, each
     providing security services at the appropriate level, with at
     worst some redundancy of service.
   1.1 Terminology
     This following terms have specific meaning in the context of this
     document.  The HTTP specification [1] defines additional useful
        A complete HTTP action, consisting of a request from the
        client and a response from the server.

     Gatewayed Service:
        A service accessed, via HTTP or an alternate protocol, by the
        HTTP server on behalf of the client.

        An specific implementation of a protocol or related subset of
        features of a protocol.

   2. General Requirements
     WTS must define the following services.  These services must be
     provided independently of each other and support the needs of proxies
     and intermediaries 
      o Confidentiality of the HTTP request and/or response.
      o Data origin authentication and data integrity of the HTTP request
        and/or response. 
      o Non-repudiability of origin for the request and/or response.
      o Transmission freshness of request and/or response.
      o Ease of integration with other features of HTTP.
      o Support of multiple mechanisms for the above services.

   3. Confidentiality
     WTS must be able to provide confidentiality for both requests and
     responses.  Note: because the identity of the object being requested is
     potentially sensitive, the URI of the request should be
     confidential; this is particularly critical in the common case of form
     data or other user input being passed in the URI.

   4. Service Authentication
     WTS should support the authentication of gatewayed services to the
     WTS should support the authentication of the origin HTTP server or
     gatewayed services regardless of intermediary proxy or caching servers.
     To allow user privacy, WTS must support service authentication with
     user anonymity.
     Because the identity of the object being requested is potentially
     sensitive, service authentication should occur before any part of the
     request, including the URI of the requested object, is passed.  In
     cases where the authentication process depends on the URI (or other
     header data) of the request, such as gatewayed services, the minimum
     necessary information to identify the entity to be authenticated should
     be passed.
   5. User Authentication
     WTS must support the authentication of the client to the server.
     WTS should support the authentication of the client to gatewayed
     WTS should support the authentication of the client to the origin HTTP
     server regardless of intermediary proxy servers.
   6. Integrity
     WTS must provide assurance of the integrity of the HTTP transaction,
     including the HTTP headers and data objects of both client requests and
     server responses.
   7. Integration 
     In order to support integration with current and future versions of
     HTTP, and to provide extendibility and independence of development, the
     secure services provided by WTS must be orthogonal to and independent
     of other services provided by HTTP.
     In accordance with the layered model of network protocols, WTS must be:
      o independent of the content or nature of data objects being
        transported although special attention to reference integrity of
        hyperlinked objects may be appropriate
      o implementable over a variety of connection schemes and
        underlying transport protocols
   8. Multiple Mechanisms
     WTS must be compatible with multiple mechanisms for authentication and
     encryption.  Support for multiple mechanisms is required for a number
     of reasons:
      o Accommodation of variations in site policies, including those
        due to external restrictions on the availability of
        cryptographic technologies.

      o Support for a variety of applications and gatewayed services.

      o Support for parallel implementations within and across
        administrative domains.

      o Accomodation of application-specific performance/security tradeoffs.
     To allow interoperability across domains, and to support the transition
     to new/upgraded mechanisms, WTS should provide negotiation of
     authentication and encryption mechanisms.
     [1] T. Berners-Lee, R. T. Fielding, and H. Frystyk Nielsen.
         "Hypertext Transfer Protocol -- HTTP/1.0" Internet-Draft
         draft-ietf-http-v10-spec-05.txt>, February, 1996

     [2] G. Bossert, S. Cooper, W. Drummond.  "Requirements of Secure
         Object Transfer Protocols"
         draft-rutgers-sotp-requirements-00.txt>, March 1995.

     The revision history of this document can be located at


     This document is a product of the IETF WTS working group.  The working
     group uses the mailing list for discussion.
     The subscription address is

     Eric Rescorla of Terisa <> provided valuable comments on
     an early draft of a document called "Requirements of Secure Object
     Transfer" [2], a principal influence on this document. 
   Security Considerations
     As noted above.

   Author's Addresses

     Greg Bossert  --
     Simon Cooper  --
     Silicon Graphics, Inc. MS 15-7 
     2011 North Shoreline Blvd. 
     Mountain View, CA 94043-1389

     Walt Drummond --
     Institute of Electrical and Electronics Engineers, Inc.
     445 Hoes Lane
     Piscataway, NJ 08855-1331
     PH: 908-562-6545