diff options
Diffstat (limited to 'doc/rfc/rfc2084.txt')
-rw-r--r-- | doc/rfc/rfc2084.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2084.txt b/doc/rfc/rfc2084.txt new file mode 100644 index 0000000..9fea63f --- /dev/null +++ b/doc/rfc/rfc2084.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group G. Bossert +Request for Comments: 2084 S. Cooper +Category: Informational Silicon Graphics Inc. + W. Drummond + IEEE, Inc. + January 1997 + + + Considerations for Web Transaction Security + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + 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. + + + + + + + + + + +Bossert, et. al. Informational [Page 1] + +RFC 2084 Considerations for Web Transaction Security January 1997 + + + 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 + terms. + + Transaction: + 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. + + Mechanism: + 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. + + + +Bossert, et. al. Informational [Page 2] + +RFC 2084 Considerations for Web Transaction Security January 1997 + + +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 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. + +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. + + + + + + + + + +Bossert, et. al. Informational [Page 3] + +RFC 2084 Considerations for Web Transaction Security January 1997 + + + 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. + + + + + + + + + + + + + + + + + + + + +Bossert, et. al. Informational [Page 4] + +RFC 2084 Considerations for Web Transaction Security January 1997 + + +References + + [1] Berners-Lee, T., Fielding, R., and H. Frystyk Nielsen, + "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, + May 1996. + + [2] G. Bossert, S. Cooper, W. Drummond. "Requirements of Secure + Object Transfer Protocols", Work in Progress + <URL:http://www-ns.rutgers.edu/www-security/draft/ + draft-rutgers-sotp-requirements-00.txt>, March 1995. + + The revision history of this document can be located 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], a principal influence on this document. + +Security Considerations + + As noted above. + + + + + + + + + + + + + + + + + + + + + + + +Bossert, et. al. Informational [Page 5] + +RFC 2084 Considerations for Web Transaction Security January 1997 + + +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 + + + + + + + + + + + + + + + + + + + + + + +Bossert, et. al. Informational [Page 6] + |