[2] in WWW Security List Archive

home help back first fref pref prev next nref lref last post

[bossert@maurolycus.rutgers.edu: Requirements for Secure Document Transfer Protocols]

daemon@ATHENA.MIT.EDU (yandros@MIT.EDU)
Fri Aug 12 14:42:38 1994

From: yandros@MIT.EDU
Date: Fri, 12 Aug 1994 14:42:35 +0500
To: www-security.discuss@charon.LOCAL


  Date: Fri, 12 Aug 94 0:06:23 EDT
  From: Greg Bossert <bossert@maurolycus.rutgers.edu>
  To: www-security@ns1.rutgers.edu
  Subject: Requirements for Secure Document Transfer Protocols
  
  The following is a rough draft of the requirements for secure document
  transfer protocols (SDTPs) for use in the World Wide Web.  We hope
  that this document will "kickstart" discussion on this list, and that
  this draft will be developed into a requirements specification that
  can be used to evaluate proposed security extensions to HTTP and
  similar document transport protocols, and aid in the development of
  Internet standards for such protocols.  Debate, dialog, deliberation,
  diatribes, and general discussion of this document is thus invited
  (and expected ;).
  
  It is vital that WWW security efforts take into account the ongoing
  work on related security and document transport issues.  Pertinent
  efforts include:
  
     o GSS-API (RFC1508/RFC1509 IETF CAT Working Group)
     o ASN.1 encoding (X.208/X.209)
     o "Fast HTTP" mechanisms (WWW-speed mailing list, etc.)
     o Caching/proxy servers (CERN HTTPD, etc.)
     o HTML 2/3/4 (W3 Organization and the proposed IETF HTML Working Group)
     o Shen from CERN
     o SHTTP from EIT/CommerceNet
  
  The latest version of this document is available via the Web:
  
  http://www-ns.rutgers.edu/www-security/sdtp-req/draft-sdtp-requirements-00.txt
  
  The www-security Web page has links to many related documents:
  
  http://www-ns.rutgers.edu/www-security/index.html
  
  ----------------------------------------------------------------------
  
                                            $Date: 1994/08/10 20:45:51 $
                                    www-security-team@www-ns.rutgers.edu
                                                            Greg Bossert
                                                            Simon Cooper
                                                           Walt Drummond
                                     Rutgers University Network Services
  
  	 Requirements for a Secure Document Transfer Protocol
  
     1. Introduction
     
     This document specifies the requirements for Secure Document
     Transfer Protocols (SDTPs).  SDTPs are used to request and supply
     data and documents within the World Wide Web paradigm, while
     providing privacy and authentication services.
     
     We use the term/acronym SDTP below to avoid identification with any
     current or proposed secure Web protocols.  We do not intend in this
     document to propose a new protocol or to rule out any existing
     schemes; instead we hope to codify existing practice and perceived
     Internet-wide needs in a way that aids in the evaluation and
     development of such protocols.
     
     Modular security packages, such as the GSS-API, may provide
     negotiation, encryption, certification, integrity, and other
     services, as well as security context management.  An SDTP that
     relies on an underlying security package/protocol may encapsulate
     or disregard these features.
     
     Security services provided at the document transport level should
     be independent of such measures provided at the document level.  An
     SDTP should thus not require changes to document description
     languages or require the parsing of documents or other data.
     
     2. Overview
     
     An SDTP must provide the following:
     
        o Server Certification, to authenticate the SDTP server software
          and host to the client/user.
     
        o Encryption of client requests; this includes, URLs and any
          additional data such as Forms/ISINDEX replies and arguments to
          service gateways.  This data should be encoded to avoid
          "traffic analysis".
     
        o Service Certification, to manage the authentication of
          gatewayed services via the SDTP server.
     
        o Immunity to malicious "person in the middle" attacks.  
     
        o User Authentication, before retrieving or submitting a
          response to a document.  See Section 4 for important
          qualifications of authentication.
     
        o Preservation of security state information, or context, over
          the length of a "user session", and support of a token to
          identify the session.  See Section 8 for important
          qualifications of sessions and session tokens.
     
        o Data Certification (digital signatures), to guarantee
          authenticity and integrity of documents.
     
        o Compatibility with document caching mechanisms.
     
     An SDTP should support the following:
          
        o Multiple methods of strong encryption and authentication for
          international interoperability
     
        o Negotiation of encryption and authentication methods.
     
     3. Privacy and Encryption
     
     An SDTP must ensure the privacy of client requests, including data
     from HTML forms and ISINDEX fields and arguments to gatewayed
     services, and documents and error/status messages from the server,
     via encryption of the protocol messages.
     
     The need for encryption when retrieving private documents, such as
     financial or medical records, is obvious.  The protection of data
     sent to the server, for example, data in an order form, is
     particularly critical to the implementation of secure services via
     the Web.  Encryption and padding of requests and responses
     (error/status messages) prevents traffic analysis attacks, such as
     comparisons of message sizes.
     
     Encryption using a mutually agreed shared session key combined with
     server certification protects against intrusion on an SDTP session
     by third parties.
     
     Multiple encryption mechanisms should be supportable by an SDTP,
     though a particular implementation may support only one mechanism.
     The encryption method for a particular session should be negotiated
     as described in section 9.  If neither the server nor the client
     have requested encryption for document retrieval it is allowable to
     transfer the document using a plaintext mechanism.
     
     4. User Authentication
     
     An SDTP must support user authentication.  Multiple authentication
     mechanisms should be supportable by an SDTP, though a particular
     implementation may support only one mechanism.  Example mechanisms
     are username/password with challenge/response, authentication
     ticket (e.g. kerberos) and public/private key schemes.  In order to
     preserve privacy, user authentication is never automatic; a user
     always has the option to refuse to authenticate.  This may result
     in denied access to documents.  Denial can take two forms, a
     (re)request for the user to authenticate or the appearance that the
     document doesn't exist.  This can be used to constrain users into
     following a specified document access path.
     
     User authentication is independent from server/service
     certification (i.e.  mutual authentication is not required).
     
     Authentication status of a session should be saved, to avoid
     repetitive authentication; this will be essential to user
     acceptance of the system.  See Section 8 for more on sessions.  In
     a particular implementation, reauthentication can be forced after a
     timeout period, for particular documents or classes of documents,
     or at the request of a gatewayed service.
     
     The authentication method for a particular session should be
     negotiated as described in section 9.
     
     5. Server Certification
     
     An SDTP must support certification of the SDTP server.  This
     certification occurs at the start of a session.  When combined with
     a mutually-agreed session key, this provides protection against
     "spoofing" or "in-the-middle" servers.  In a particular
     implementation, re-certification can be forced after a timeout
     period, for particular documents or classes of documents, or at the
     user's request.
     
     Certification status of the server/session should be saved; see
     Section 8 for more on session data.
     
     Multiple certification mechanisms should be supportable by an SDTP,
     though a particular implementation may support only one mechanism.
     The certification method for a particular session should be
     negotiated as described in section 9.
     
     6. Service Certification
     
     An SDTP should provide certification management for gatewayed
     services, allowing clients/users to authenticate a gatewayed
     service independently of the SDTP server.
     
     Certification status of a session should be saved, to avoid
     repetitive certification; this will be essential to user acceptance
     of the system.  See Section 8 for more on sessions.  In a
     particular implementation, re-certification can be forced after a
     timeout period, for particular documents or classes of documents,
     or at the request of a gatewayed service.
     
     The certification method for a particular session should be
     negotiated as described in section 9.  However, the SDTP should
     support the ability of the client and gatewayed service to
     negotiate directly.
     
     7. Document Certification and Integrity
     
     An SDTP should support certification of authenticity and integrity
     of data in requests and responses.  Digital signatures should be
     included in the document header and/or be available independently
     from the server.
     
     8. Sessions and Session Tokens.
     
     SDTPs should support the concept of a session or security context.
     This is used to avoid repeated authentication or certification, or
     renegotiation of encryption and authentication mechanisms.  State
     information is maintained in parallel on client and server.  A
     uniquely-generated session token is used to identify sessions.
     NOTE: A session token must not provide information about
     authentication or the encryption key.  It must be possible to
     transmit this token "in the clear", to allow the server/client
     software to identify the context of the associated message.
     
     Examples of session data are: encryption mechanism, encryption
     key(s), server certification status/data, user authentication
     status/data.
     
     Sessions can be terminated by errors, authentication failures,
     timeouts, security failures in underlying protocols, or by user
     request.
     
     9. Negotiation
     
     An SDTP should be able to negotiate:
     
        o Encryption mechanisms
        o User Authentication mechanisms
        o Service/server Certification mechanisms
     
     Supported mechanisms should be strong, with the exception of
     trivial mechanisms (e.g. plaintext encryption).  Negotiation is
     thus based on the mutual support of mechanisms, efficiency, etc.
     
     Negotiation may be handled by an underlying security protocol.
  
  ----------------------------------------------------------------------
                                    www-security-team@www-ns.rutgers.edu
                                     Rutgers University Network Services

home help back first fref pref prev next nref lref last post