rfc1040.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                    J. Linn (BBNCC)
Request for Comments: 1040                        IAB Privacy Task Force
Obsoletes RFCs: 989                                         January 1988


           Privacy Enhancement for Internet Electronic Mail:
       Part I: Message Encipherment and Authentication Procedures


STATUS OF THIS MEMO

   This RFC suggests a proposed protocol for the Internet community, and
   requests discussion and suggestions for improvements.  Distribution
   of this memo is unlimited.

ACKNOWLEDGMENT

   This RFC is the outgrowth of a series of IAB Privacy Task Force
   meetings and of internal working papers distributed for those
   meetings.  I would like to thank the following Privacy Task Force
   members and meeting guests for their comments and contributions at
   the meetings which led to the preparation of this RFC:  David
   Balenson, Curt Barker, Matt Bishop, Danny Cohen, Tom Daniel, Charles
   Fox, Morrie Gasser, Steve Kent (chairman), John Laws, Steve Lipner,
   Dan Nessett, Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker,
   and Steve Wilbur.

1.  Executive Summary

   This RFC defines message encipherment and authentication procedures,
   as the initial phase of an effort to provide privacy enhancement
   services for electronic mail transfer in the Internet.  Detailed key
   management mechanisms to support these procedures will be defined in
   a subsequent RFC.  As a goal of this initial phase, it is intended
   that the procedures defined here be compatible with a wide range of
   key management approaches, including both conventional (symmetric)
   and public-key (asymmetric) approaches for encryption of data
   encrypting keys.  Use of conventional cryptography for message text
   encryption and/or integrity check computation is anticipated.

   Privacy enhancement services (confidentiality, authentication, and
   message integrity assurance) are offered through the use of
   end-to-end cryptography between originator and recipient User Agent
   processes, with no special processing requirements imposed on the
   Message Transfer System at endpoints or at intermediate relay
   sites.  This approach allows privacy enhancement facilities to be
   incorporated on a site-by-site or user-by-user basis without impact
   on other Internet entities.  Interoperability among heterogeneous



Linn                                                            [Page 1]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   components and mail transport facilities is supported.

2.  Terminology

   For descriptive purposes, this RFC uses some terms defined in the OSI
   X.400 Message Handling System Model per the 1984 CCITT
   Recommendations.  This section replicates a portion of X.400's
   Section 2.2.1, "Description of the MHS Model: Overview" in order to
   make the terminology clear to readers who may not be familiar with
   the OSI MHS Model.

   In the [MHS] model, a user is a person or a computer application.  A
   user is referred to as either an originator (when sending a message)
   or a recipient (when receiving one).  MH Service elements define the
   set of message types and the capabilities that enable an originator
   to transfer messages of those types to one or more recipients.

   An originator prepares messages with the assistance of his User
   Agent.  A User Agent (UA) is an application process that interacts
   with the Message Transfer System (MTS) to submit messages.  The MTS
   delivers to one or more recipient UAs the messages submitted to it.
   Functions performed solely by the UA and not standardized as part of
   the MH Service elements are called local UA functions.

   The MTS is composed of a number of Message Transfer Agents (MTAs).
   Operating together, the MTAs relay messages and deliver them to the
   intended recipient UAs, which then make the messages available to the
   intended recipients.

   The collection of UAs and MTAs is called the Message Handling System
   (MHS).  The MHS and all of its users are collectively referred to as
   the Message Handling Environment.

3.  Services, Constraints, and Implications

   This RFC defines mechanisms to enhance privacy for electronic mail
   transferred in the Internet.  The facilities discussed in this RFC
   provide privacy enhancement services on an end-to-end basis between
   sender and recipient UAs.  No privacy enhancements are offered for
   message fields which are added or transformed by intermediate relay
   points.

   Authentication and integrity facilities are always applied to the
   entirety of a message's text.  No facility for confidentiality
   service without authentication is provided.  Encryption facilities
   may be applied selectively to portions of a message's contents; this
   allows less sensitive portions of messages (e.g., descriptive fields)
   to be processed by a recipient's delegate in the absence of the



Linn                                                            [Page 2]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   recipient's personal cryptographic keys.  In the limiting case, where
   the entirety of message text is excluded from encryption, this
   feature can be used to yield the effective combination of
   authentication and integrity services without confidentiality.

   In keeping with the Internet's heterogeneous constituencies and usage
   modes, the measures defined here are applicable to a broad range of
   Internet hosts and usage paradigms.  In particular, it is worth
   noting the following attributes:

       1.  The mechanisms defined in this RFC are not restricted to a
           particular host or operating system, but rather allow
           interoperability among a broad range of systems.  All
           privacy enhancements are implemented at the application
           layer, and are not dependent on any privacy features at
           lower protocol layers.

       2.  The defined mechanisms are compatible with non-enhanced
           Internet components.  Privacy enhancements are implemented
           in an end-to-end fashion which does not impact mail
           processing by intermediate relay hosts which do not
           incorporate privacy enhancement facilities.  It is
           necessary, however, for a message's sender to be cognizant
           of whether a message's intended recipient implements privacy
           enhancements, in order that encoding and possible
           encipherment will not be performed on a message whose
           destination is not equipped to perform corresponding inverse
           transformations.

       3.  The defined mechanisms are compatible with a range of mail
           transport facilities (MTAs).  Within the Internet,
           electronic mail transport is effected by a variety of SMTP
           implementations.  Certain sites, accessible via SMTP,
           forward mail into other mail processing environments (e.g.,
           USENET, CSNET, BITNET).  The privacy enhancements must be
           able to operate across the SMTP realm; it is desirable that
           they also be compatible with protection of electronic mail
           sent between the SMTP environment and other connected
           environments.

       4.  The defined mechanisms offer compatibility with a broad
           range of electronic mail user agents (UAs).  A large variety
           of electronic mail user agent programs, with a corresponding
           broad range of user interface paradigms, is used in the
           Internet.  In order that an electronic mail privacy
           enhancement be available to the broadest possible user
           community, the selected mechanism should be usable with the
           widest possible variety of existing UA programs.  For



Linn                                                            [Page 3]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


           purposes of pilot implementation, it is desirable that
           privacy enhancement processing be incorporable into a
           separate program, applicable to a range of UAs, rather than
           requiring internal modifications to each UA with which
           enhanced privacy services are to be provided.

       5.  The defined mechanisms allow electronic mail privacy
           enhancement processing to be performed on personal computers
           (PCs) separate from the systems on which UA functions are
           implemented.  Given the expanding use of PCs and the limited
           degree of trust which can be placed in UA implementations on
           many multi-user systems, this attribute can allow many users
           to process privacy-enhanced mail with a higher assurance
           level than a strictly UA-based approach would allow.

       6.  The defined mechanisms support privacy protection of
           electronic mail addressed to mailing lists.

   In order to achieve applicability to the broadest possible range of
   Internet hosts and mail systems, and to facilitate pilot
   implementation and testing without the need for prior modifications
   throughout the Internet, three basic restrictions are imposed on the
   set of measures to be considered in this RFC:

       1.  Measures will be restricted to implementation at endpoints
           and will be amenable to integration at the user agent (UA)
           level or above, rather than necessitating integration into
           the message transport system (e.g., SMTP servers).

       2.  The set of supported measures enhances rather than restricts
           user capabilities.  Trusted implementations, incorporating
           integrity features protecting software from subversion by
           local users, cannot be assumed in general.  In the absence
           of such features, it appears more feasible to provide
           facilities which enhance user services (e.g., by protecting
           and authenticating inter-user traffic) than to enforce
           restrictions (e.g., inter-user access control) on user
           actions.

       3.  The set of supported measures focuses on a set of functional
           capabilities selected to provide significant and tangible
           benefits to a broad user community.  By concentrating on the
           most critical set of services, we aim to maximize the added
           privacy value that can be provided with a modest level of
           implementation effort.






Linn                                                            [Page 4]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   As a result of these restrictions, the following facilities can be
   provided:

           1.  disclosure protection,

           2.  sender authenticity, and

           3.  message integrity measures,

   but the following privacy-relevant concerns are not addressed:

           1.  access control,

           2.  traffic flow confidentiality,

           3.  address list accuracy,

           4.  routing control,

           5.  issues relating to the serial reuse of PCs by multiple
               users,

           6.  assurance of message receipt and non-deniability of
               receipt,

           7.  automatic association of acknowledgments with the
               messages to which they refer, and

           8.  message duplicate detection, replay prevention, or other
               stream-oriented services.

   An important goal is that privacy enhancement mechanisms impose a
   minimum of burden on the users they serve.  In particular, this goal
   suggests eventual automation of the key management mechanisms
   supporting message encryption and authentication.  In order to
   facilitate deployment and testing of pilot privacy enhancement
   implementations in the near term, however, compatibility with
   out-of-band (e.g., manual) key distribution must also be supported.

   A message's sender will determine whether privacy enhancements are to
   be performed on a particular message.  Therefore, a sender must be
   able to determine whether particular recipients are equipped to
   process privacy-enhanced mail.  In a general architecture, these
   mechanisms will be based on server queries; thus, the query function
   could be integrated into a UA to avoid imposing burdens or
   inconvenience on electronic mail users.





Linn                                                            [Page 5]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988