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 4. Processing of Messages 4.1 Message Processing Overview This subsection provides a high-level overview of the components and processing steps involved in electronic mail privacy enhancement processing. Subsequent subsections will define the procedures in more detail. A two-level keying hierarchy is used to support privacy-enhanced message transmission: 1. Data Encrypting Keys (DEKs) are used for encryption of message text and (with certain choices among a set of alternative algorithms) for computation of message integrity check quantities (MICs). DEKs are generated individually for each transmitted message; no predistribution of DEKs is needed to support privacy-enhanced message transmission. 2. Interchange Keys (IKs) are used to encrypt DEKs for transmission within messages. An IK may be a single symmetric cryptographic key or, where asymmetric (public-key) cryptography is used to encrypt DEKs, the composition of a public component used by an originator and a secret component used by a recipient. Ordinarily, the same IK will be used for all messages sent between a given originator-recipient pair over a period of time. Each transmitted message includes a representation of the DEK(s) used for message encryption and/or authentication, encrypted under an individual IK per named recipient. This representation is associated with sender and recipient identification header fields, which enable recipients to identify the IKs used. With this information, the recipient can decrypt the transmitted DEK representation, yielding the DEK required for message text decryption and/or MIC verification. When privacy enhancement processing is to be performed on an outgoing message, a DEK is generated [1] for use in message encryption and a variant of the DEK is formed (if the chosen MIC algorithm requires a key) for use in MIC computation. An "X-Sender-ID:" field is included in the header to provide one identification component for the IK(s) used for message processing. An IK is selected for each individually identified recipient; a corresponding "X-Recipient-ID:" field, interpreted in the context of a prior "X-Sender-ID:" field, serves to identify each IK. Each "X-Recipient-ID:" field is followed by an "X-Key-Info:" field, which transfers the DEK and computed MIC. The DEK and MIC are encrypted for transmission under the appropriate IK. Linn [Page 6] RFC 1040 Privacy Enhancement for Electronic Mail January 1988 A four-phase transformation procedure is employed in order to represent encrypted message text in a universally transmissible form and to enable messages encrypted on one type of system to be decrypted on a different type. A plaintext message is accepted in local form, using the host's native character set and line representation. The local form is converted to a canonical message text representation, defined as equivalent to the inter-SMTP representation of message text. This canonical representation forms the input to the encryption and MIC computation processes. For encryption purposes, the canonical representation is padded as required by the encryption algorithm. The padded canonical representation is encrypted (except for any regions explicitly excluded from encryption). The canonically enco