[2] in WWW Security List Archive
[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