home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2084.txt < prev    next >
Text File  |  1997-01-20  |  9KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         G. Bossert
  8. Request for Comments: 2084                                     S. Cooper
  9. Category: Informational                            Silicon Graphics Inc.
  10.                                                              W. Drummond
  11.                                                               IEEE, Inc.
  12.                                                             January 1997
  13.  
  14.  
  15.               Considerations for Web Transaction Security
  16.  
  17. Status of this Memo
  18.  
  19.    This memo provides information for the Internet community.  This memo
  20.    does not specify an Internet standard of any kind.  Distribution of
  21.    this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    This document specifies the requirements for the provision of
  26.    security services to the HyperText Transport Protocol.  These
  27.    services include confidentiality, integrity, user authentication, and
  28.    authentication of servers/services, including proxied or gatewayed
  29.    services.  Such services may be provided as extensions to HTTP, or as
  30.    an encapsulating security protocol.  Secondary requirements include
  31.    ease of integration and support of multiple mechanisms for providing
  32.    these services.
  33.  
  34. 1. Introduction
  35.  
  36.    The use of the HyperText Transport Protocol [1] to provide
  37.    specialized or commercial services and personal or private data
  38.    necessitates the development of secure versions that include privacy
  39.    and authentication services.  Such services may be provided as
  40.    extensions to HTTP, or as encapsulating security protocols; for the
  41.    purposes of this document, all such enhancements will be referred to
  42.    as WTS.
  43.  
  44.    In this document, we specify the requirements for WTS, with the
  45.    intent of codifying perceived Internet-wide needs, along with
  46.    existing practice, in a way that aids in the evaluation and
  47.    development of such protocols.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Bossert, et. al.             Informational                      [Page 1]
  59.  
  60. RFC 2084      Considerations for Web Transaction Security   January 1997
  61.  
  62.  
  63.    WTS is an enhancement to an object transport protocol.  As such, it
  64.    does not provide independent certification of documents or other data
  65.    objects outside of the scope of the transfer of said objects.  In
  66.    addition, security at the WTS layer is independent of and orthogonal
  67.    to security services provided at underlying network layers.  It is
  68.    envisioned that WTS may coexist in a single transaction with such
  69.    mechanisms, each providing security services at the appropriate
  70.    level, with at worst some redundancy of service.
  71.  
  72. 1.1 Terminology
  73.  
  74.    This following terms have specific meaning in the context of this
  75.    document.  The HTTP specification [1] defines additional useful
  76.    terms.
  77.  
  78.    Transaction:
  79.       A complete HTTP action, consisting of a request from the
  80.       client and a response from the server.
  81.  
  82.    Gatewayed Service:
  83.       A service accessed, via HTTP or an alternate protocol, by the
  84.       HTTP server on behalf of the client.
  85.  
  86.    Mechanism:
  87.       An specific implementation of a protocol or related subset of
  88.       features of a protocol.
  89.  
  90. 2. General Requirements
  91.  
  92.    WTS must define the following services.  These services must be
  93.    provided independently of each other and support the needs of proxies
  94.    and intermediaries
  95.  
  96.     o Confidentiality of the HTTP request and/or response.
  97.     o Data origin authentication and data integrity of the HTTP request
  98.       and/or response.
  99.     o Non-repudiability of origin for the request and/or response.
  100.     o Transmission freshness of request and/or response.
  101.     o Ease of integration with other features of HTTP.
  102.     o Support of multiple mechanisms for the above services.
  103.  
  104. 3. Confidentiality
  105.  
  106.    WTS must be able to provide confidentiality for both requests and
  107.    responses.  Note: because the identity of the object being requested
  108.    is potentially sensitive, the URI of the request should be
  109.    confidential; this is particularly critical in the common case of
  110.    form data or other user input being passed in the URI.
  111.  
  112.  
  113.  
  114. Bossert, et. al.             Informational                      [Page 2]
  115.  
  116. RFC 2084      Considerations for Web Transaction Security   January 1997
  117.  
  118.  
  119. 4. Service Authentication
  120.  
  121.    WTS should support the authentication of gatewayed services to the
  122.    client.
  123.  
  124.    WTS should support the authentication of the origin HTTP server or
  125.    gatewayed services regardless of intermediary proxy or caching
  126.    servers.
  127.  
  128.    To allow user privacy, WTS must support service authentication with
  129.    user anonymity.
  130.  
  131.    Because the identity of the object being requested is potentially
  132.    sensitive, service authentication should occur before any part of the
  133.    request, including the URI of the requested object, is passed.  In
  134.    cases where the authentication process depends on the URI (or other
  135.    header data) of the request, such as gatewayed services, the minimum
  136.    necessary information to identify the entity to be authenticated
  137.    should be passed.
  138.  
  139. 5. User Authentication
  140.  
  141.    WTS must support the authentication of the client to the server.
  142.  
  143.    WTS should support the authentication of the client to gatewayed
  144.    services.
  145.  
  146.    WTS should support the authentication of the client to the origin
  147.    HTTP server regardless of intermediary proxy servers.
  148.  
  149. 6. Integrity
  150.  
  151.    WTS must provide assurance of the integrity of the HTTP transaction,
  152.    including the HTTP headers and data objects of both client requests
  153.    and server responses.
  154.  
  155. 7. Integration
  156.  
  157.    In order to support integration with current and future versions of
  158.    HTTP, and to provide extendibility and independence of development,
  159.    the secure services provided by WTS must be orthogonal to and
  160.    independent of other services provided by HTTP.
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Bossert, et. al.             Informational                      [Page 3]
  171.  
  172. RFC 2084      Considerations for Web Transaction Security   January 1997
  173.  
  174.  
  175.    In accordance with the layered model of network protocols, WTS must
  176.    be:
  177.  
  178.     o independent of the content or nature of data objects being
  179.       transported although special attention to reference integrity of
  180.       hyperlinked objects may be appropriate
  181.  
  182.     o implementable over a variety of connection schemes and
  183.       underlying transport protocols
  184.  
  185. 8. Multiple Mechanisms
  186.  
  187.    WTS must be compatible with multiple mechanisms for authentication
  188.    and encryption.  Support for multiple mechanisms is required for a
  189.    number of reasons:
  190.  
  191.     o Accommodation of variations in site policies, including those
  192.       due to external restrictions on the availability of
  193.       cryptographic technologies.
  194.  
  195.     o Support for a variety of applications and gatewayed services.
  196.  
  197.     o Support for parallel implementations within and across
  198.       administrative domains.
  199.  
  200.     o Accomodation of application-specific performance/security
  201.       tradeoffs.
  202.  
  203.    To allow interoperability across domains, and to support the
  204.    transition to new/upgraded mechanisms, WTS should provide negotiation
  205.    of authentication and encryption mechanisms.
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Bossert, et. al.             Informational                      [Page 4]
  227.  
  228. RFC 2084      Considerations for Web Transaction Security   January 1997
  229.  
  230.  
  231. References
  232.  
  233.    [1] Berners-Lee, T., Fielding, R., and H. Frystyk Nielsen,
  234.        "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
  235.        May 1996.
  236.  
  237.    [2] G. Bossert, S. Cooper, W. Drummond.  "Requirements of Secure
  238.        Object Transfer Protocols", Work in Progress
  239.        <URL:http://www-ns.rutgers.edu/www-security/draft/
  240.        draft-rutgers-sotp-requirements-00.txt>, March 1995.
  241.  
  242.    The revision history of this document can be located at
  243.    <URL:http://reality.sgi.com/csp/wts-wg/wts-documents.html>
  244.  
  245. Acknowledgments
  246.  
  247.    This document is a product of the IETF WTS working group.  The
  248.    working group uses the wts-wg@postofc.corp.sgi.com mailing list for
  249.    discussion.  The subscription address is wts-wg-
  250.    request@postofc.corp.sgi.com.
  251.  
  252.    Eric Rescorla of Terisa <ekr@terisa.com> provided valuable comments
  253.    on an early draft of a document called "Requirements of Secure Object
  254.    Transfer" [2], a principal influence on this document.
  255.  
  256. Security Considerations
  257.  
  258.    As noted above.
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Bossert, et. al.             Informational                      [Page 5]
  283.  
  284. RFC 2084      Considerations for Web Transaction Security   January 1997
  285.  
  286.  
  287. Authors' Addresses
  288.  
  289.    Greg Bossert
  290.    Silicon Graphics, Inc. MS 15-7
  291.    2011 North Shoreline Blvd.
  292.    Mountain View, CA 94043-1389
  293.    USA
  294.  
  295.    EMail: bossert@corp.sgi.com
  296.  
  297.  
  298.    Simon Cooper
  299.    Silicon Graphics, Inc. MS 15-7
  300.    2011 North Shoreline Blvd.
  301.    Mountain View, CA 94043-1389
  302.    USA
  303.  
  304.    EMail: sc@corp.sgi.com
  305.  
  306.  
  307.    Walt Drummond
  308.    Institute of Electrical and Electronics Engineers, Inc.
  309.    445 Hoes Lane
  310.    Piscataway, NJ 08855-1331
  311.    USA
  312.  
  313.    Phone: 908-562-6545
  314.    Fax: 908-562-1727
  315.    EMail: drummond@ieee.org
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Bossert, et. al.             Informational                      [Page 6]
  339.  
  340.