RFC 2084

Considerations for Web Transaction Security

📅 published January 1997, from ietf

RFC 2084: Considerations for Web Transaction Security 🎀 This one is an Informational doc (not a standard!), dated January 1997. It's written by Greg (G.) Bossert and Simon (S.) Cooper from Silicon Graphics Inc. 💖, plus Walt (W.) Drummond from IEEE, Inc. 🧚. Its title block lists no "Obsoletes" or "Updates" entries, so it's not replacing or changing anything else ✨

Status of this Memo ✨

This memo provides information for the Internet community 🌸 It does not specify an Internet standard of any kind, so don't go treating it as one 🙈 Distribution of this memo is unlimited 🦋

Abstract 💜

This doc lays out the requirements for giving the HyperText Transport Protocol some security services 🔐 Those are confidentiality, integrity, user authentication, and authentication of servers and services, including proxied or gatewayed ones 👑 These MAY be provided as extensions to HTTP, or as an encapsulating security protocol. The secondary goals are ease of integration and support for multiple mechanisms that provide these services 💅

1. Introduction 🌸

Okay so HTTP is used for specialized or commercial services and for personal or private data, which means it needs secure versions with privacy and authentication built in 🔥 These MAY be extensions to HTTP or encapsulating security protocols. For this doc, all of those enhancements get called WTS 🧚

The goal here is to write down the WTS requirements, collecting the Internet-wide needs along with existing practice, so evaluating and building these protocols gets easier 💅

WTS is an enhancement to an object transport protocol, so it doesn't independently certify documents or other data objects outside the scope of transferring them 🙈 Security at the WTS layer is also independent of, and orthogonal to, the security services at the underlying network layers. It's envisioned that WTS MAY coexist in a single transaction with such mechanisms, each providing security services at the right level, with at worst some redundancy of service 🫶

1.1 Terminology 🎀

The following terms have specific meaning in this document. The HTTP specification [1] defines additional useful terms 💖

  • Transaction: A complete HTTP action, made up 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.
  • Mechanism: A specific implementation of a protocol, or a 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 they support the needs of proxies and intermediaries 💅

  • Confidentiality of the HTTP request and/or response 🔒
  • Data origin authentication and data integrity of the HTTP request and/or response 🫶
  • Non-repudiability of origin for the request and/or response 💜
  • Transmission freshness of request and/or response 🍓
  • Ease of integration with other features of HTTP 🧚
  • 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 especially 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 client 🦋

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 with 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 services 🍓

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. No cap, this is a big one ✨

7. Integration 🧚

So 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 the other services provided by HTTP 💜

In accordance with the layered model of network protocols, WTS MUST be:

  • independent of the content or nature of the data objects being transported, although special attention to reference integrity of hyperlinked objects MAY be appropriate 🦋
  • 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 💅

  • Accommodation of variations in site policies, including those due to external restrictions on the availability of cryptographic technologies 🌍
  • Support for a variety of applications and gatewayed services 🍓
  • Support for parallel implementations within and across administrative domains 🧚
  • Accommodation of application-specific performance/security tradeoffs ⭐

To allow interoperability across domains, and to support the transition to new or upgraded mechanisms, WTS SHOULD provide negotiation of authentication and encryption mechanisms 🫶

References 📚

The revision history of this document can be found at <URL:http://reality.sgi.com/csp/wts-wg/wts-documents.html> 🌷

Acknowledgments 🫶

This document is a product of the IETF WTS working group. The working group uses the wts-wg@postofc.corp.sgi.com mailing list for discussion. The subscription address is wts-wg-request@postofc.corp.sgi.com 💌

Eric Rescorla of Terisa <ekr@terisa.com> provided valuable comments on an early draft of a document called "Requirements of Secure Object Transfer" [2], which was a principal influence on this document 👑

Security Considerations 💀

As noted above. (Yes, that's the whole section. Iconic minimalism 💀)

Authors' Addresses 🦋

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

EMail: bossert@corp.sgi.com


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

EMail: sc@corp.sgi.com


Walt Drummond
Institute of Electrical and Electronics Engineers, Inc.
445 Hoes Lane
Piscataway, NJ 08855-1331
USA

Phone: 908-562-6545
Fax: 908-562-1727
EMail: drummond@ieee.org
📦 where this page comes from