Network Working Group                                            J. Linn

Request for Comments: 1421                    IAB IRTF PSRG, IETF PEM WG

Obsoletes: 1113                                            February 1993

           Privacy Enhancement for Internet Electronic Mail:

        Part I: Message Encryption and Authentication Procedures

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet

   community, and requests discussion and suggestions for improvements.

   Please refer to the current edition of the "IAB Official Protocol

   Standards" for the standardization state and status of this protocol.

   Distribution of this memo is unlimited.

Acknowledgements

   This document is the outgrowth of a series of meetings of the Privacy

   and Security Research Group (PSRG) of the IRTF and the PEM Working

   Group of the IETF.  I would like to thank the members of the PSRG and

   the IETF PEM WG, as well as all participants in discussions on the

   "pem-dev@tis.com" mailing list, for their contributions to this

   document.

1.  Executive Summary

   This document defines message encryption and authentication

   procedures, in order to provide privacy-enhanced mail (PEM) services

   for electronic mail transfer in the Internet.  It is intended to

   become one member of a related set of four RFCs.  The procedures

   defined in the current document are intended to be compatible with a

   wide range of key management approaches, including both symmetric

   (secret-key) and asymmetric (public-key) approaches for encryption of

   data encrypting keys.  Use of symmetric cryptography for message text

   encryption and/or integrity check computation is anticipated. RFC

   1422 specifies supporting key management mechanisms based on the use

   of public-key certificates.  RFC 1423 specifies algorithms, modes,

   and associated identifiers relevant to the current RFC and to RFC

   1422.  RFC 1424 provides details of paper and electronic formats and

   procedures for the key management infrastructure being established in

   support of these services.

   Privacy enhancement services (confidentiality, authentication,

   message integrity assurance, and non-repudiation of origin) are

   offered through the use of end-to-end cryptography between originator

   and recipient processes at or above the User Agent level.  No special

   processing requirements are imposed on the Message Transfer System at

Linn                                                            [Page 1]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   endpoints or at intermediate relay sites.  This approach allows

   privacy enhancement facilities to be incorporated selectively on a

   site-by-site or user-by-user basis without impact on other Internet

   entities.  Interoperability among heterogeneous components and mail

   transport facilities is supported.

   The current specification's scope is confined to PEM processing

   procedures for the RFC-822 textual mail environment, and defines the

   Content-Domain indicator value "RFC822" to signify this usage.

   Follow-on work in integration of PEM capabilities with other

   messaging environments (e.g., MIME) is anticipated and will be

   addressed in separate and/or successor documents, at which point

   additional Content-Domain indicator values will be defined.

2.  Terminology

   For descriptive purposes, this RFC uses some terms defined in the OSI

   X.400 Message Handling System Model per the CCITT Recommendations.

   This section replicates a portion of (1984) 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 or her

   User Agent (UA).  A 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.

Linn                                                            [Page 2]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

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

   originator and recipient processes residing at the UA level or above.

   No privacy enhancements are offered for message fields which are

   added or transformed by intermediate relay points between PEM

   processing components.

   If an originator elects to perform PEM processing on an outbound

   message, all PEM-provided security services are applied to the PEM

   message's body in its entirety; selective application to portions of

   a PEM message is not supported. Authentication, integrity, and (when

   asymmetric key management is employed) non-repudiation of origin

   services are applied to all PEM messages; confidentiality services

   are optionally selectable.

   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 originator to be

            cognizant of whether a message's intended recipient

            implements privacy enhancements, in order that encoding and

            possible encryption will not be performed on a message whose

            destination is not equipped to perform corresponding inverse

            transformations.  (Section 4.6.1.1.3 of this RFC describes a

            PEM message type ("MIC-CLEAR") which represents a signed,

            unencrypted PEM message in a form readable without PEM

            processing capabilities yet validatable by PEM-equipped

            recipients.)

        3.  The defined mechanisms are compatible with a range of mail

            transport facilities (MTAs).  Within the Internet,

Linn                                                            [Page 3]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

            electronic mail transport is effected by a variety of SMTP

            [2] 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 are compatible 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 electronic mail privacy

            enhancements be available to the broadest possible user

            community, selected mechanisms should be usable with the

            widest possible variety of existing UA programs.  For

            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 PEM

            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 PEM with a higher assurance level than a strictly

            UA-integrated approach would allow.

        6.  The defined mechanisms support privacy protection of

            electronic mail addressed to mailing lists (distribution

            lists, in ISO parlance).

        7.  The mechanisms defined within this RFC are compatible with a

            variety of supporting key management approaches, including

            (but not limited to) manual pre-distribution, centralized

            key distribution based on symmetric cryptography, and the

            use of public-key certificates per RFC 1422.  Different

            key management mechanisms may be used for different

            recipients of a multicast message.  For two PEM

            implementations to interoperate, they must share a common

            key management mechanism; support for the mechanism defined

            in RFC 1422 is strongly encouraged.

Linn                                                            [Page 4]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   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 and pervasive

   modifications throughout the Internet, the following design

   principles were applied in selecting the set of features specified in

   this RFC:

        1.  This RFC's measures are restricted to implementation at

            endpoints and are amenable to integration with existing

            Internet mail protocols at the user agent (UA) level or

            above, rather than necessitating modifications to existing

            mail protocols or 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.  No mechanisms

            are assumed to prevent users from sending, at their

            discretion, messages to which no PEM processing has been

            applied. 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.

   Based on these principles, the following facilities are provided:

        1.  disclosure protection,

        2.  originator authenticity,

        3.  message integrity measures, and

        4.  (if asymmetric key management is used) non-repudiation of

            origin,

   but the following privacy-relevant concerns are not addressed:

        1.  access control,

Linn                                                            [Page 5]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

        2.  traffic flow confidentiality,

        3.  address list accuracy,

        4.  routing control,

        5.  issues relating to the casual 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

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.

4.1.1  Types of Keys

   A two-level keying hierarchy is used to support PEM 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 (MIC) quantities.  In the asymmetric key management

            environment, DEKs are also used to encrypt the signed

            representations of MICs in PEM messages to which

            confidentiality has been applied. DEKs are generated

            individually for each transmitted message; no

            predistribution of DEKs is needed to support PEM

            transmission.

        2.  Interchange Keys (IKs) are used to encrypt DEKs for

            transmission within messages.  Ordinarily, the same IK will

            be used for all messages sent from a given originator to a

            given recipient over a period of time.  Each transmitted

            message includes a representation of the DEK(s) used for

            message encryption and/or MIC computation, encrypted under

            an individual IK per named recipient.  The representation is

Linn                                                            [Page 6]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

            associated with Originator-ID and Recipient-ID fields

            (defined in different forms so as to distinguish symmetric

            from asymmetric cases), which allow each individual

            recipient to identify the IK used to encrypt DEKs and/or

            MICs for that recipient's use.  Given an appropriate IK, a

            recipient can decrypt the corresponding transmitted DEK

            representation, yielding the DEK required for message text

            decryption and/or MIC validation.  The definition of an IK

            differs depending on whether symmetric or asymmetric

            cryptography is used for DEK encryption:

                 2a. When symmetric cryptography is used for DEK

                     encryption, an IK is a single symmetric key shared

                     between an originator and a recipient.  In this

                     case, the same IK is used to encrypt MICs as well

                     as DEKs for transmission.  Version/expiration

                     information and IA identification associated with

                     the originator and with the recipient must be

                     concatenated in order to fully qualify a symmetric

                     IK.

                 2b. When asymmetric cryptography is used, the IK

                     component used for DEK encryption is the public

                     component [8] of the recipient.  The IK component

                     used for MIC encryption is the private component of

                     the originator, and therefore only one encrypted

                     MIC representation need be included per message,

                     rather than one per recipient.  Each of these IK

                     components can be fully qualified in a Recipient-ID

                     or Originator-ID field, respectively.

                     Alternatively, an originator's IK component may be

                     determined from a certificate carried in an

                     "Originator-Certificate:" field.

4.1.2  Processing Procedures

   When PEM processing is to be performed on an outgoing message, a DEK

   is generated [1] for use in message encryption and (if a chosen MIC

   algorithm requires a key) a variant of the DEK is formed for use in

   MIC computation.  DEK generation can be omitted for the case of a

   message where confidentiality is not to be applied, unless a chosen

   MIC computation algorithm requires a DEK.  Other parameters (e.g.,

   Initialization Vectors (IVs)) as required by selected encryption

   algorithms are also generated.

   One or more Originator-ID and/or "Originator-Certificate:" fields are

   included in a PEM message's encapsulated header to provide recipients

   with an identification component for the IK(s) used for message

Linn                                                            [Page 7]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   processing.  All of a message's Originator-ID and/or "Originator-

   Certificate:" fields are assumed to correspond to the same principal;

   the facility for inclusion of multiple such fields accomodates the

   prospect that different keys, algorithms, and/or certification paths

   may be required for processing by different recipients.  When a

   message includes recipients for which asymmetric key management is

   employed as well as recipients for which symmetric key management is

   employed, a separate Originator-ID or "Originator-Certificate:" field

   precedes each set of recipients.

   In the symmetric case, per-recipient IK components are applied for

   each individually named recipient in preparation of ENCRYPTED, MIC-

   ONLY, and MIC-CLEAR messages. A corresponding "Recipient-ID-

   Symmetric:" field, interpreted in the context of the most recent

   preceding "Originator-ID-Symmetric:" field, serves to identify each

   IK.  In the asymmetric case, per-recipient IK components are applied

   only for ENCRYPTED messages, are independent of originator-oriented

   header elements, and are identified by "Recipient-ID-Asymmetric:"

   fields.  Each Recipient-ID field is followed by a "Key-Info:" field,

   which transfers the message's DEK encrypted under the IK appropriate

   for the specified recipient.

   When symmetric key management is used for a given recipient, the

   "Key-Info:" field following the corresponding "Recipient-ID-

   Symmetric:" field also transfers the message's computed MIC,

   encrypted under the recipient's IK. When asymmetric key management is

   used, a "MIC-Info:" field associated with an "Originator-ID-

   Asymmetric:" or "Originator-Certificate:" field carries the message's

   MIC, asymmetrically signed using the private component of the

   originator.  If the PEM message is of type ENCRYPTED (as defined in

   Section 4.6.1.1.1 of this RFC), the asymmetrically signed MIC is

   symmetrically encrypted using the same DEK, algorithm, encryption

   mode and other cryptographic parameters as used to encrypt the

   message text, prior to inclusion in the "MIC-Info:" field.

4.1.2.1  Processing Steps

   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 host computer to be

   decrypted on a different type of host computer.  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 MIC computation step (applicable to ENCRYPTED, MIC-

   ONLY, and MIC-CLEAR messages) and the encryption process (applicable

   to ENCRYPTED messages only).

Linn                                                            [Page 8]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   For ENCRYPTED PEM messages, the canonical representation is padded as

   required by the encryption algorithm, and this padded canonical

   representation is encrypted. The encrypted text (for an ENCRYPTED

   message) or the unpadded canonical form (for a MIC-ONLY message) is

   then encoded into a printable form.  The printable form is composed

   of a restricted character set which is chosen to be universally

   representable across sites, and which will not be disrupted by

   processing within and between MTS entities. MIC-CLEAR PEM messages

   omit the printable encoding step.

   The output of the previous processing steps is combined with a set of

   header fields carrying cryptographic control information.  The

   resulting PEM message is passed to the electronic mail system to be

   included within the text portion of a transmitted message. There is

   no requirement that a PEM message comprise the entirety of an MTS

   message's text portion; this allows PEM-protected information to be

   accompanied by (unprotected) annotations.  It is also permissible for

   multiple PEM messages (and associated unprotected text, outside the

   PEM message boundaries) to be represented within the encapsulated

   text of a higher-level PEM message. PEM message signatures are

   forwardable when asymmetric key management is employed; an authorized

   recipient of a PEM message with confidentiality applied can reduce

   that message to a signed but unencrypted form for forwarding purposes

   or can re-encrypt that message for subsequent transmission.

   When a PEM message is received, the cryptographic control fields

   within its encapsulated header provide the information required for

   each authorized recipient to perform MIC validation and decryption of

   the received message text.  For ENCRYPTED and MIC-ONLY messages, the

   printable encoding is converted to a bitstring.  Encrypted portions

   of the transmitted message are decrypted.  The MIC is validated.

   Then, the recipient PEM process converts the canonical representation

   to its appropriate local form.

4.1.2.2  Error Cases

   A variety of error cases may occur and be detected in the course of

   processing a received PEM message. The specific actions to be taken

   in response to such conditions are local matters, varying as

   functions of user preferences and the type of user interface provided

   by a particular PEM implementation, but certain general

   recommendations are appropriate. Syntactically invalid PEM messages

   should be flagged as such, preferably with collection of diagnostic

   information to support debugging of incompatibilities or other

   failures.  RFC 1422 defines specific error processing requirements

   relevant to the certificate-based key management mechanisms defined

   therein.

Linn                                                            [Page 9]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   Syntactically valid PEM messages which yield MIC failures raise

   special concern, as they may result from attempted attacks or forged

   messages.  As such, it is unsuitable to display their contents to

   recipient users without first indicating the fact that the contents'

   authenticity and integrity cannot be guaranteed and then receiving

   positive user confirmation of such a warning.  MIC-CLEAR messages

   (discussed in Section 4.6.1.1.3 of this RFC) raise special concerns,

   as MIC failures on such messages may occur for a broader range of

   benign causes than are applicable to other PEM message types.

4.2  Encryption Algorithms, Modes, and Parameters

   For use in conjunction with this RFC, RFC 1423 defines the

   appropriate algorithms, modes, and associated identifiers to be used

   for encryption of message text with DEKs.

   The mechanisms defined in this RFC incorporate facilities for

   transmission of cryptographic parameters (e.g., pseudorandom

   Initializing Vectors (IVs)) with PEM messages to which the