diff options
Diffstat (limited to 'doc/rfc/rfc989.txt')
| -rw-r--r-- | doc/rfc/rfc989.txt | 1357 |
1 files changed, 1357 insertions, 0 deletions
diff --git a/doc/rfc/rfc989.txt b/doc/rfc/rfc989.txt new file mode 100644 index 0000000..b5ce2eb --- /dev/null +++ b/doc/rfc/rfc989.txt @@ -0,0 +1,1357 @@ + + + +Network Working Group John Linn (BBNCC) +Request for Comments: 989 IAB Privacy Task Force + February 1987 + + + 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, 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 authentication 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 + components and mail transport facilities is supported. + + + + + +Linn, Privacy Task Force [Page 1] + +RFC 989 February 1987 + + +2 Terminology + + For descriptive purposes, this RFC uses some terms defined in the OSI + X.400 Message Handling System Model. 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's goal is to define 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. Two distinct privacy + enhancement service options are supported: + + 1. an option providing sender authentication and integrity + verification + + 2. an option providing sender authentication and integrity + verification in addition to confidentiality service through + encryption + + No facility for confidentiality service in the absence of + authentication is provided. Encryption and authentication facilities + may be applied selectively to portions of a message's contents; this + allows less sensitive portions of messages (e.g., descriptive fields) + + + +Linn, Privacy Task Force [Page 2] + +RFC 989 February 1987 + + + to be processed by a recipient's delegate in the absence of the + recipient's personal cryptographic keys. + + 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 offer compatibility with non- + enhanced Internet components. Privacy enhancements will be + 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 offer compatibility 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, it is desirable that the selected mechanism + 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 + + + +Linn, Privacy Task Force [Page 3] + +RFC 989 February 1987 + + + 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. + + As a result of these restrictions, the following facilities can be + provided: + + -- disclosure protection, + + + + +Linn, Privacy Task Force [Page 4] + +RFC 989 February 1987 + + + -- sender authenticity, and + + -- message integrity measures, + + but the following privacy-relevant concerns are not addressed: + + -- access control, + + -- traffic flow security, + + -- address list accuracy, + + -- routing control, + + -- issues relating to the serial reuse of PCs by multiple users, + + -- assurance of message receipt and non-deniability of receipt, and + + -- automatic association of acknowledgments with the messages to + which they refer + + 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. This will necessitate + mechanisms by which a sender can 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. + +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 + + + +Linn, Privacy Task Force [Page 5] + +RFC 989 February 1987 + + + text and for computation of message authentication codes + (MACs). 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. An IK may either be a single symmetric + cryptographic key or, where asymmetric (public-key) + cryptography is used for DEK encryption, 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 accompanied by an + identifier (IK ID) to enable the recipient to determine which + IK was used, and so to decrypt the representation yielding the + DEK required for message text decryption and/or MAC + verification. + + An encoding 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. Four phases are involved in this process. 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. The canonical + representation is padded to an integral multiple of eight octets, as + required by the encryption algorithm. MAC computation is performed, + and (if disclosure protection is required), the padded canonical + representation is encrypted. The output of this step is 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. + + The output of the encoding procedure is combined with a set of header + fields (to be defined in Section 4.8) carrying cryptographic control + information. The result is passed to the electronic mail system to + be encapsulated as the text portion of a transmitted message. + + When a privacy-enhanced message is received, the cryptographic + control fields within its text portion provide the information + required for the authorized recipient to perform MAC verification and + decryption on the received message text. First, the printable + encoding is converted to a bitstring. If the transmitted message was + encrypted, it is decrypted into the canonical representation. If the + message was not encrypted, decoding from the printable form produces + the canonical representation directly. The MAC is verified, and the + + + +Linn, Privacy Task Force [Page 6] + +RFC 989 February 1987 + + + canonical representation is converted to the recipient's local form, + which need not be the same as the sender's local form. + +4.2 Encryption Algorithms and Modes + + For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined + in ISO draft international standard DIS 8227 [1] shall be used for + encryption of message text and for computation of authentication + codes on messages. The DEA-1 is equivalent to the Data Encryption + Standard (DES), as defined in FIPS PUB 46 [2]. When used for these + purposes, the DEA-1 shall be used in the Cipher Block Chaining (CBC) + mode, as defined in ISO DIS 8372 [3]. The CBC mode definition in DIS + 8372 is equivalent to that provided in FIPS PUB 81 [4]. A unique + initializing vector (IV) will be generated for and transmitted with + each encrypted electronic mail message. + + An algorithm other than DEA-1 may be employed, provided that it + satisfies the following requirements: + + 1. it must be a 64-bit block cipher, enciphering and deciphering + in 8 octet blocks + + 2. it is usable in the ECB and CBC modes defined in DIS8372 + + 3. it is able to be keyed using the procedures and parameters + defined in this RFC + + 4. it is appropriate for MAC computation + + 5. cryptographic key field lengths are limited to 16 octets + in length + + Certain operations require that one key be encrypted under another + key (interchange key) for purposes of transmission. For purposes of + this RFC, such encryption will be performed using DEA-1 in Electronic + Codebook (ECB) mode. An optional facility is available to an + interchange key provider to indicate that an associated key is to be + used for encryption in another mode (e.g., the Encrypt-Decrypt- + Encrypt (EDE) mode used for key encryption and decryption with pairs + of 64-bit keys, as described [5] by ASC X3T1). + + Future support of public key algorithms for key encryption is under + consideration, and it is intended that the procedures defined in this + RFC be appropriate to allow such usage. Support of key encryption + modes other than ECB is optional for implementations, however. + Therefore, in support of universal interoperability, interchange key + providers should not specify other modes in the absence of a priori + information indicating that recipients are equipped to perform key + encryption in other modes. + + + + + +Linn, Privacy Task Force [Page 7] + +RFC 989 February 1987 + + +4.3 Canonical Encoding + + Any encryption scheme must be compatible with the transparency + constraints of its underlying electronic mail facilities. These + constraints are generally established based on expected user + requirements and on the characteristics of anticipated endpoint + transport facilities. SMTP, designed primarily for interpersonal + messages and anticipating systems and transport media which may be + restricted to a 7-bit character set, can transmit any 7-bit + characters (but not arbitrary 8-bit binary data) in message text. + + SMTP introduces other transparency constraints related to line + lengths and message delimiters. Message text may not contain the + string "<CR><LF>.<CR><LF>" in sequence before the end of a message, + and must contain the string "<CR><LF>" at least every 1000 + characters. Another important SMTP transparency issue must be noted. + Although SMTP specifies a standard representation for line delimiters + (ASCII <CR><LF>), numerous systems use a different native + representation to delimit lines. For example, the <CR><LF> sequences + delimiting lines in mail inbound to UNIX(tm) systems are transformed + to single <LF>s as mail is written into local mailbox files. Lines + in mail incoming to record-oriented systems (such as VAX VMS) may be + converted to appropriate records by the destination SMTP [6] server. + As a result, if the encryption process generated <CR>s or <LF>s, + those characters might not be accessible to a recipient UA program at + a destination using different line delimiting conventions. It is + also possible that conversion between tabs and spaces may be + performed in the course of mapping between inter-SMTP and local + format; this is a matter of local option. If such transformations + changed the form of transmitted ciphertext, decryption would fail to + regenerate the transmitted plaintext, and a transmitted MAC would + fail to compare with that computed at the destination. + + The conversion performed by an SMTP server at a system with EBCDIC as + a native character set has even more severe impact, since the + conversion from EBCDIC into ASCII is an information-losing + transformation. In principle, the transformation function mapping + between inter-SMTP canonical ASCII message representation and local + format could be moved from the SMTP server up to the UA, given a + means to direct that the SMTP server should no longer perform that + transformation. This approach has the disadvantage that it would + imply internal file (e.g., mailbox) formats which would be + incompatible with the systems on which they reside, an untenable + prospect. Further, it would require modification to SMTP servers, as + mail would be passed to SMTP in a different representation than it is + passed at present. + + Our approach to this problem selects a canonical character set, + uniformly representable across privacy-enhanced UAs regardless of + their systems' native character sets, to transport encrypted mail + text (but not electronic mail transport headers!) between endpoints. + + + +Linn, Privacy Task Force [Page 8] + +RFC 989 February 1987 + + + In this approach, an outbound privacy-enhanced message is transformed + between four forms, in sequence: + + + 1. (Local_Form) The message text is created (e.g., via an editor) + in the system's native character set, with lines delimited in + accordance with local convention. + + 2. (Canonicalize) The message text is converted to the universal + canonical form, equivalent to the inter-SMTP representation as + defined in RFC822 [7] (ASCII character set, <CR><LF> line + delimiters). (The processing required to perform this + conversion is relatively small, at least on systems whose + native character set is ASCII.) + + 3. (Encipher/Authenticate) A padded version of the canonical + plaintext representation is created by appending zero-valued + octets to the end of the representation until the length is an + integral multiple of 8 octets, as is required to perform + encryption in the DEA-1 CBC mode. No padding is applied if + the canonical plaintext representation's length is already a + multiple of 8 octets. This padded representation is used as + the input to the encryption function and to the MAC + computation function. + + 4. (Encode to Printable Form) The bits resulting from the + encryption operation are encoded into characters which are + universally representable at all sites, though not necessarily + with the same bit patterns (e.g., although the character "E" + is represented in an ASCII-based system as hexadecimal 45 and + as hexadecimal C5 in an EBCDIC-based system, the local + significance of the two representations is equivalent). Use + of a 64-character subset of International Alphabet IA5 is + proposed, enabling 6 bits to be represented per printable + character. (The proposed subset of characters is represented + identically in IA5 and ASCII.) Two additional characters, "=" + and "*", are used to signify special processing functions. + The encoding function's output is delimited into text lines + (using local conventions), with each line containing 64 + printable characters. The encoding process is performed as + follows, transforming strings of 3 arbitrary (8-bit) + characters to strings of 4 encoded characters: + + 4a. Proceeding from left to right across the input characters + (considered as a contiguous bitstring), each group of 6 + bits is used as an index into an array of 64 printable + characters; the character referenced by the index is + placed in the output string. These characters, + identified in Table 1, are selected so as to be + universally representable, and the set excludes + characters with particular significance to SMTP e.g., + + + +Linn, Privacy Task Force [Page 9] + +RFC 989 February 1987 + + + ".", "<CR>", "<LF>"). + + 4b. If fewer than 3 input characters are available in a final + quantum, zero bits are added (on the right) to form an + integral number of 6-bit groups. Output character + positions which are not required to represent actual + input data are set to a 65th reserved, universally + representable character ("="). Use of a reserved + character for padding allows compensatory processing to + be performed by a recipient, allowing the decoded message + text's length to be precisely the same as the input + message's length. A final 3-octet input quantum will be + represented as a 4 octet encoding with no terminal "=", a + 2-octet input quantum will be represented as 3 octets + followed by one terminal "=", and a 1-octet input quantum + will be represented as 2 octets followed by two + occurrences of "=". + + A sender may exclude one or more portions of a message from + encryption/authentication processing. Explicit action is required to + exclude a portion of a message from such processing; by default, + encryption/authentication is applied to the entirety of message text. + The user-level delimiter which specifies such exclusion is a local + matter, and hence may vary between sender and recipient, but all + systems should provide a means for unambiguous identification of + areas excluded from encryption/authentication processing. An + excluded area is represented in the inter-SMTP transmission form + (universal across communicating systems) by bracketing with the + reserved delimiter "*". Cryptographic state is preserved + transparently across an excluded area and continued after the end of + the excluded area. A printable encoding quantum (per step 4b) is + completed before the delimiter "*" is output to initiate or terminate + the representation of an excluded block. Note that the + canonicalizing transformation (step 2 above) and the encoding to + printable form (step 4 above) are applied to all portions of message + text, even those excluded from encryption and authentication. + + In summary, the outbound message is subjected to the following + composition of transformations: + + Transmit_Form = Encode(Encipher(Canonicalize(Local_Form))) + + The inverse transformations are performed, in reverse order, to + process inbound privacy-enhanced mail: + + Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form))) + + Note that the local form and the functions to transform messages to + and from canonical form may vary between the sender and recipient + systems without loss of information. + + + + +Linn, Privacy Task Force [Page 10] + +RFC 989 February 1987 + + + Value Encoding Value Encoding Value Encoding Value Encoding + 0 A 17 R 34 i 51 z + 1 B 18 S 35 j 52 0 + 2 C 19 T 36 k 53 1 + 3 D 20 U 37 l 54 2 + 4 E 21 V 38 m 55 3 + 5 F 22 W 39 n 56 4 + 6 G 23 X 40 o 57 5 + 7 H 24 Y 41 p 58 6 + 8 I 25 Z 42 q 59 7 + 9 J 26 a 43 r 60 8 + 10 K 27 b 44 s 61 9 + 11 L 28 c 45 t 62 + + 12 M 29 d 46 u 63 / + 13 N 30 e 47 v + 14 O 31 f 48 w (pad) = + 15 P 32 g 49 x + 16 Q 33 h 50 y (1) * + + (1) The character "*" is used to delimit portions of an + encoded message to which encryption/authentication + processing has not been applied. + + Printable Encoding Characters + Table 1 + +4.4 Encapsulation Mechanism + + Encapsulation of privacy-enhanced messages within an enclosing layer + of headers interpreted by the electronic mail transport system offers + a number of advantages in comparison to a flat approach in which + certain fields within a single header are encrypted and/or carry + cryptographic control information. Encapsulation provides generality + and segregates fields with user-to-user significance from those + transformed in transit. As far as the MTS is concerned, information + incorporated into cryptographic authentication or encryption + processing will reside in a message's text portion, not its header + portion. + + The encapsulation mechanism to be used for privacy-enhanced mail is + derived from that described in RFC934 [8] which is, in turn, based on + precedents in the processing of message digests in the Internet + community. To prepare a user message for encrypted or authenticated + transmission, it will be transformed into the representation shown in + Figure 1. Note that, while encryption and/or authentication + processing of transmitted mail may depend on information contained in + the enclosing header (e.g., "To:"), all fields inserted in the course + of encryption/authentication processing are placed in the + encapsulated header. This facilitates compatibility with mail + handling programs which accept only text, not header fields, from + input files or from other programs. Further, privacy enhancement + + + +Linn, Privacy Task Force [Page 11] + +RFC 989 February 1987 + + + processing can be applied recursively. + + Sensitive data should be protected by incorporating the data within + the encapsulated text rather than by applying measures selectively to + fields in the enclosing header. Examples of potentially sensitive + header information may include fields such as "Subject:", with + contents which are significant on an end-to-end, inter-user basis. + The (possibly empty) set of headers to which protection is to be + applied is a user option. If an authenticated version of header + information is desired, that data can be replicated within the + encapsulated text portion in addition to its inclusion in the + enclosing header. If a user wishes disclosure protection for header + fields, they must occur only in the encapsulated text and not in the + enclosing or encapsulated header. If disclosure protection is + desired for the "Subject:" field, it is recommended that the + enclosing header contain a "Subject:" field indicating that + "Encrypted Mail Follows". + + A specific point regarding the integration of privacy-enhanced mail + facilities with the message encapsulation mechanism is worthy of + note. The subset of IA5 selected for transmission encoding + intentionally excludes the character "-", so encapsulated text can be + distinguished unambiguously from a message's closing encapsulation + boundary (Post-EB) without recourse to character stuffing. + +4.5 Processing for Authentication Without Confidentiality + + When a message is to be authenticated without confidentiality + service, a DEK is generated [9] for use in MAC computation, and a MAC + is computed using that DEK. For each individually identified + recipient, an IK is selected and identified with an "X-IK-ID:" field. + Each "X-IK-ID:" field is followed by an "X-Key-Info:" field which + transfers the key under which MAC computation was performed, + encrypted under the IK identified by the preceding "X-IK-ID:" field, + along with a representation of the MAC encrypted under the same IK. + The encapsulated text portion following the encapsulated header is + canonically encoded, and coded into printable characters for + transmission, but not encrypted. + + + + + + + + + + + + + + + + +Linn, Privacy Task Force [Page 12] + +RFC 989 February 1987 + + + Enclosing Header Portion + + (Contains header fields per RFC-822) + + Blank Line + + (Separates Enclosing Header from Encapsulated Message) + + Encapsulated Message + + Pre-Encapsulation Boundary (Pre-EB) + + -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- + + Encapsulated Header Portion + + (Contains encryption control fields inserted in plaintext. + Examples include "X-IV:", "X-IK-ID:", "X-Key-Info:", + and "X-Pad-Count:". Note that, although these control + fields have line-oriented representations similar to + RFC-822 header fields, the set of fields valid in this + context is disjoint from those used in RFC-822 processing.) + + Blank Line + + (Separates Encapsulated Header from subsequent encoded + Encapsulated Text Portion) + + Encapsulated Text Portion + + (Contains message data encoded as specified in Section 4.3; + may incorporate protected copies of "Subject:", etc.) + + Post-Encapsulation Boundary (Post-EB) + + -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- + + Message Encapsulation + Figure 1 + +4.6 Processing for Authentication and Confidentiality + + When a message is to be authenticated with confidentiality service, a + DEK is generated for use in MAC computation and a variant of the DEK + is formed for use in message encryption. For each individually + identified recipient, an IK is selected and identified with an "X- + IK-ID:" field. Each "X-IK-ID:" field is followed by an "X-Key-Info:" + field, which transfers the DEK and computed MAC, each encrypted under + the IK identified in the preceding "X-IK-ID:" field. The + encapsulated text portion following the encapsulated header is + canonically encoded, encrypted, and coded into printable characters + + + +Linn, Privacy Task Force [Page 13] + +RFC 989 February 1987 + + + for transmission. + +4.7 Mail for Mailing Lists + + When mail is addressed to mailing lists, two different methods of + processing can be applicable: the IK-per-list method and the IK-per- + recipient method. The choice depends on the information available to + the sender and on the sender's preference. + + If a message's sender addresses a message to a list name or alias, + use of an IK associated with that name or alias as a entity (IK-per- + list), rather than resolution of the name or alias to its constituent + destinations, is implied. Such an IK must, therefore, be available + to all list members. This alternative will be the normal case for + messages sent via remote exploder sites, as a sender to such lists + may not be cognizant of the set of individual recipients. + Unfortunately, it implies an undesirable level of exposure for the + shared IK, and makes its revocation difficult. Moreover, use of the + IK-per-list method allows any holder of the list's IK to masquerade + as another sender to the list for authentication purposes. + + If, in contrast, a message's sender is equipped to expand the + destination mailing list into its individual constituents and elects + to do so (IK-per-recipient), the message's DEK and MAC will be + encrypted under each per-recipient IK and all such encrypted + representations will be incorporated into the transmitted message. + (Note that per-recipient encryption is required only for the + relatively small DEK and MAC quantities carried in the X-Key-Info + field, not for the message text which is, in general, much larger.) + Although more IKs are involved in processing under the IK-per- + recipient method, the pairwise IKs can be individually revoked and + possession of one IK does not enable a successful masquerade of + another user on the list. + +4.8 Summary of Added Header and Control Fields + + This section summarizes the syntax and semantics of the new header + and control fields to be added to messages in the course of privacy + enhancement processing, indicating whether a particular field occurs + in a message's encapsulated header portion or its encapsulated text + portion. Figure 2 shows the appearance of a small example + encapsulated message using these fields. In all cases, hexadecimal + quantities are represented as contiguous strings of digits, where + each digit is represented by a character from the ranges "0"-"9" or + upper case "A"-"F". Unless otherwise specified, all arguments are to + be processed in a case-sensitive fashion. + + Although the encapsulated header fields resemble RFC-822 header + fields, they are a disjoint set and will not in general be processed + by the same parser which operates on enclosing header fields. The + complexity of lexical analysis needed and appropriate for + + + +Linn, Privacy Task Force [Page 14] + +RFC 989 February 1987 + + + encapsulated header field processing is significantly less than that + appropriate to RFC-822 header processing. For example, many + characters with special significance to RFC-822 at the syntactic + level have no such significance within encapsulated header fields. + + The "X-IK-ID" and "X-Key-Info" fields are the only encapsulated + header fields with lengths which can vary beyond a size conveniently + printable on a line. Whitespace may be used between the subfields of + these fields to fold them in the manner of RFC-822; such whitespace + is not to be interpreted as a part of a subfield. + + -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- + X-Proc-Type: 1,E + X-Pad-Count: 1 + X-IV: F8143EDE5960C597 + X-IK-ID: JL:3:ECB + X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD + X-IK-ID: JL:1:ECB + X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF7 + + LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M + 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk + J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot + dXd/H5LMDWnonNvPCwQUHt== + -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- + + Example Encapsulated Message + Figure 2 + + + X-IK-ID: This field is placed in the encapsulated header + portion of a message to identify the Interchange Key + used for encryption of an associated Data Encrypting + Key or keys (used for message text encryption and/or + MAC computation). This field is used for messages + authenticated without confidentiality service and for + messages authenticated with confidentiality service. + The field contains (in order) an Issuing Authority + subfield and an IK Qualifier subfield, and may also + contain an optional IK Use Indicator subfield. The + subfields are delimited by the colon character (":"), + optionally followed by whitespace. Section 5.1.2, + Interchange Keys, discusses the semantics of these + subfields and specifies the alphabet from which they + are chosen. Note that multiple X-IK-ID fields may + occur within a single encapsulated header. Each X- + IK-ID field is associated with an immediately + subsequent X-Key-Info field. + + X-IV: This field is placed in the encapsulated header + portion of a message to carry the Initializing Vector + + + +Linn, Privacy Task Force [Page 15] + +RFC 989 February 1987 + + + used for message encryption. It is used only for + messages where confidentiality service is applied. + Following the field name, and one or more delimiting + whitespace characters, a 64-bit Initializing Vector + is represented as a contiguous string of 16 + hexadecimal digits. + + X-Key-Info: This field is placed in a message's encapsulated + header portion to transfer two items: a DEK and a + MAC. Both items are encrypted under the IK + identified by a preceding X-IK-ID field; they are + represented as two strings of contiguous hexadecimal + digits, separated by a comma. For DEA-1, the DEK + representation will be 16 hexadecimal digits + (corresponding to a 64-bit key); this subfield can be + extended to 32 hexadecimal digits (corresponding to a + 128-bit key) if required to support other algorithms. + The MAC is a 64-bit quantity, represented as 16 + hexadecimal digits. The MAC is computed under an + unmodified version of the DEK. Message encryption is + performed using a variant of the DEK, formed by + modulo-2 addition of the hexadecimal quantity + F0F0F0F0F0F0F0F0 to the DEK. + + X-Pad-Count: This field is placed in the encapsulated header + portion of a message to indicate the number of zero- + valued octets which were added to pad the input + stream to the encryption function to an integral + multiple of eight octets, as required by the DEA-1 + CBC encryption mode. A decimal number in the range + 0-7 follows the field name, and one or more + delimiting whitespace characters. Inclusion of this + field allows disambiguation between terminal zero- + valued octets in message text (admittedly, a + relatively unlikely prospect) and zero-valued octets + inserted for padding purposes. + + X-Proc-Type: This field is placed in the encapsulated header + portion of a message to identify the type of + processing performed on the transmitted message. The + first subfield is a decimal version number, which + will be used if future developments make it necessary + to redefine the interpretation of encapsulated header + fields. At present, this field may assume only the + value "1". The second subfield, delimited by a + comma, assumes one of two single-character alphabetic + values: "A" and "E", to signify, respectively, (1) + authentication processing only and (2) the + combination of authentication and confidentiality + service through encryption. + + + + +Linn, Privacy Task Force [Page 16] + +RFC 989 February 1987 + + +5 Key Management + +5.1 Types of Keys + +5.1.1 Data Encrypting Keys (DEKs) + + Data Encrypting Keys (DEKs) are used for encryption of message text + and for computation of message authentication codes (MACs). It is + strongly recommended that DEKs be generated and used on a one-time + basis. A transmitted message will incorporate a representation of + the DEK encrypted under an interchange key (IK) known to the + authorized recipient. + + DEK generation can be performed either centrally by key distribution + centers (KDCs) or by endpoint systems. One advantage of centralized + KDC-based generation is that DEKs can be returned to endpoints + already encrypted under the IKs of message recipients. This reduces + IK exposure and simplifies endpoint key management requirements. + Further, dedicated KDC systems may be able to implement better + algorithms for random key generation than can be supported in + endpoint systems. On the other hand, decentralization allows + endpoints to be relatively self-sufficient, reducing the level of + trust which must be placed in components other than a message's + originator and recipient. Moreover, decentralized DEK generation by + endpoints reduces the frequency with which senders must make real- + time queries of (potentially unique) servers in order to send mail, + enhancing communications availability. + +5.1.2 Interchange Keys (IKs) + + Interchange Keys (IKs) are used to encrypt Data Encrypting Keys. In + general, the granularity of IK usage is at the pairwise per-user + level except for mail sent to address lists comprising multiple + users. In order for two principals to engage in a useful exchange of + privacy-enhanced electronic mail using conventional cryptography, + they must first share a common interchange key. When asymmetric + cryptography is used, an originator and recipient must possess + appropriate public and secret components which, in composition, + constitute an interchange key. + + The means by which interchange keys are provided to appropriate + parties are outside the scope of this RFC, but may be centralized + (e.g., via key management servers) or decentralized (e.g., via direct + distribution among users). In any case, a given IK is associated + with a responsible Issuing Authority (IA). When an IA generates and + distributes an IK, associated control information must be provided to + direct how that IK is to be used. In order to select the appropriate + IK to use in message encryption, a sender must retain a + correspondence between IKs and the recipients with which they are + associated. Expiration date information must also be retained, in + order that cached entries may be invalidated and replaced as + + + +Linn, Privacy Task Force [Page 17] + +RFC 989 February 1987 + + + appropriate. + + When a privacy-enhanced message is transmitted, an indication of the + IK (or IKs, in the case of a message sent to multiple recipients) + used for DEK encryption must be included. To this end, the IK ID + construct is defined to provide the following data: + + 1. Identification of the relevant Issuing Authority (IA + subfield) + + 2. Qualifier string to distinguish the particular IK within + the set of IKs distributed by the IA (IK qualifier + subfield) + + 3. (Optional) Indicator of IK usage mode (IK use indicator + subfield) + + + The subfields of an IK ID are delimited with the colon character + (":"). The IA and IK qualifier subfields are generated from a + restricted character set, as prescribed by the following BNF (using + notation as defined in RFC-822, sections 2 and 3.3): + + IAorIKQual := 1*ia-char + + ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" / + "," / "." / "/" / "=" / "?" / "-" / "@" / + "%" / "!" / '"' / "_" / "<" / ">" + + The IK use indicator subfield assumes a value from a small set of + reserved strings, described later in this section. + + IA identifiers must be assigned in a manner which assures uniqueness. + This can be done on a centralized or hierarchic basis. + + The IK qualifier string format may vary among different IAs, but must + satisfy certain functional constraints. An IA's IK qualifiers must + be sufficient to distinguish among the set of IKs issued by that IA. + Since a message may be sent with multiple IK IDs, corresponding to + multiple intended recipients, each recipient must be able to + determine which IK is intended for it. Moreover, if no corresponding + IK is available in the recipient's database when a message arrives, + the recipient must be able to determine which IK to request and to + identify that IK's associated IA. Note that different IKs may be + used for different messages between a pair of communicants. + Consider, for example, one message sent from A to B and another + message sent (using the IK-per-list method) from A to a mailing list + of which B is a member. The first message would use an IK shared + between A and B, but the second would use an IK shared among list + members. + + + + +Linn, Privacy Task Force [Page 18] + +RFC 989 February 1987 + + + While use of a monotonically increasing number as an IK qualifier is + sufficient to distinguish among the set of IKs distributed by an IA, + it offers no facility for a recipient lacking a matching IK to + determine the appropriate IK to request. This suggests that sender + and recipient name information should be incorporated into an IK + qualifier, along with a number to distinguish among multiple IKs used + between a sender/recipient pair. In order to support universal + interoperability, it is necessary to assume a universal form for the + naming information. General definition of such a form requires + further study; issues and possible approaches will be noted in + Section 6. As an interim measure, the following IK qualifier format + is suggested: + + <sender-name>/<recipient-name>/<numid> + + where <sender-name> and <recipient-name> are in the following form: + + <user>@<domain-qualified-host> + + For the case of installations which transform local host names before + transmission into the broader Internet, it is strongly recommended + that the host name as presented to the Internet be employed. The + <numid> is a contiguous string of decimal digits. + + The IK use indicator subfield is an optional facility, provided to + identify the encryption mode in which the IK is to be used. + Currently, this subfield may assume the following reserved string + values: "ECB" and "EDE"; the default value is ECB. + + An example IK ID adhering to this recommendation is as follows: + + ptf-kmc:linn@CCY.BBN.COM/privacy-tf@C.ISI.EDU/2:ECB + + This IK ID would indicate that IA "ptf-kmc" has issued an IK for use + on messages sent from "linn@CCY.BBN.COM" to "privacy-tf@C.ISI.EDU", + that the IA has associated number 2 with that IK, and that the IK is + to be used in ECB mode. + + IKs will remain valid for a period which will be longer than a single + message and will be identified by an expiration time distributed + along with the IK; IK cryptoperiod is dictated in part by a tradeoff + between key management overhead and revocation responsiveness. It + would be undesirable to delete an IK permanently before receipt of a + message encrypted using that IK, as this would render the message + permanently undecipherable. Access to an expired IK would be needed, + for example, to process mail received by a user (or system) which had + been inactive for an extended period of time. In order to enable + very old IKs to be deleted, a message's recipient desiring encrypted + local long term storage should transform the DEK used for message + text encryption via re-encryption under a locally maintained IK, + rather than relying on IA maintenance of old IKs for indefinite + + + +Linn, Privacy Task Force [Page 19] + +RFC 989 February 1987 + + + periods. + +6 User Naming + + Unique naming of electronic mail users, as is needed in order to + select corresponding keys correctly, is an important topic and one + requiring significant study. A logical association exists between + key distribution and name/directory server functions; their + relationship is a topic deserving further consideration. These + issues have not been fully resolved at this writing. The interim + architecture relies on association of IKs with user names represented + in a universal form, which has the following properties: + + 1. The universal form must be specifiable by an IA as it + distributes IKs and known to a UA as it processes + received IKs and IK IDs. If a UA or IA uses addresses in + a local form which is different from the universal form, + it must be able to perform an unambiguous mapping from + the universal form into the local representation. + + 2. The universal form, when processed by a sender UA, must + have a recognizable correspondence with the form of a + recipient address as specified by a user (perhaps + following local transformation from an alias into a + universal form) + + It is difficult to ensure these properties throughout the Internet. + For example, an MTS which transforms address representations between + the local form used within an organization and the global form used + for Internet mail transmission may cause property 2 to be violated. + + The use of flat (non-hierarchic) electronic mail user identifiers, + which are unrelated to the hosts on which the users reside, appears + useful. Personal characteristics, like social security numbers, + might be considered. Individually-selected identifiers could be + registered with a central authority, but a means to resolve name + conflicts would be necessary. + + A point of particular note is the desire to accommodate multiple + names for a single individual, in order to represent and allow + delegation of various roles in which that individual may act. A + naming mechanism that binds user roles to keys is needed. Bindings + cannot be immutable since roles sometimes change (e.g., the + comptroller of a corporation is fired). + + It may be appropriate to examine the prospect of extending the Domain + Name System and its associated name servers to resolve user names to + unique user IDs. An additional issue arises with regard to mailing + list support: name servers do not currently perform (potentially + recursive) expansion of lists into users. ISO and CSNet are working + on user-level directory service mechanisms, which may also bear + + + +Linn, Privacy Task Force [Page 20] + +RFC 989 February 1987 + + + consideration. + +7 Example User Interface and Implementation + + In order to place the mechanisms and approaches discussed in this RFC + into context, this section presents an overview of a prototype + implementation. This implementation is a standalone program [10] + which is invoked by a user, and lies above the existing UA sublayer. + This form of integration offers the advantage that the program can be + used in conjunction with a range of UA programs, rather than being + compatible only with a particular UA. When a user wishes to apply + privacy enhancements to an outgoing message, the user prepares the + message's text and invokes the standalone program (interacting with + the program in order to provide address information and other data + required to perform privacy enhancement processing), which in turn + generates output suitable for transmission via the UA. When a user + receives a privacy-enhanced message, the UA delivers the message in + encrypted form, suitable for decryption and associated processing by + the standalone program. + + In this prototype implementation, a cache of IKs is maintained in a + local file, with entries managed manually based on pairwise + agreements between originators and recipients. This cache is, + effectively, a simple database. IKs are selected for transmitted + messages based on recipient names, and corresponding IK IDs are + placed into the message's encapsulated header. When a message is + received, the IK ID is used as a basis for a lookup in the database, + yielding the appropriate IK entry. DEKs and IVs are generated + dynamically within the program. + + Options (e.g., authentication only vs. authentication with + confidentiality service) are selected by command line arguments to + the standalone program. Destination addresses are specified in the + same fashion. The function of specifying destination addresses to + the privacy enhancement program is logically distinct from the + function of specifying the corresponding addresses to the UA for use + by the MTS. This separation results from the fact that, in many + cases, the local form of an address as specified to a UA differs from + the Internet global form as used for IK ID fields. + +8 Areas For Further Study + + The procedures defined in this RFC are sufficient to support pilot + implementation of privacy-enhanced electronic mail transmission among + cooperating parties in the Internet. Further effort will be needed, + however, to enhance robustness, generality, and interoperability. In + particular, further work is needed in the following areas: + + + 1. User naming techniques, and their relationship to the domain + system, name servers, directory services, and key management + + + +Linn, Privacy Task Force [Page 21] + +RFC 989 February 1987 + + + functions + + 2. Standardization of Issuing Authority functions, including + protocols for communications among IAs and between User Agents + and IAs + + 3. Use of public key encryption algorithms to encrypt data + encrypting keys + + 4. Interoperability with X.400 mail + + We anticipate generation of subsequent RFCs which will address these + topics. + + +9 References + + This section identifies background references which may be useful to + those contemplating use of the mechanisms defined in this RFC. + + + ISO 7498/Part 2 - Security Architecture, prepared by ISO.TC97/SC + 21/WG 1 Ad hoc group on Security, extends the OSI Basic + Reference Model to cover security aspects which are general + architectural elements of communications protocols, and + provides an annex with tutorial and background information. + + US Federal Information Processing Standards Publication (FIPS PUB) + 46, Data Encryption Standard, 15 January 1977, defines the + encipherment algorithm used for message text encryption and + MAC computation. + + FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines + specific modes in which the Data Encryption Standard algorithm + is to be used to perform encryption and MAC computation. + +NOTES: + + + [1] Information Processing Systems: Data Encipherment: Block + Cipher Algorithm DEA 1. + + [2] Federal Information Processing Standards Publication 46, Data + Encryption Standard, 15 January 1977. + + [3] Information Processing Systems: Data Encipherment: Modes of + Operation of a 64-bit Block Cipher + + [4] Federal Information Processing Standards Publication 81, DES + Modes of Operation, 2 December 1980. + + + + +Linn, Privacy Task Force [Page 22] + +RFC 989 February 1987 + + + [5] Addendum to the Transport Layer Protocol Definition for + Providing Connection Oriented End to End Cryptographic Data + Protection Using a 64-Bit Block Cipher, X3T1-85-50.3, draft of + 19 December 1985, Gaithersburg, MD, p. 15. + + [6] This transformation should occur only at an SMTP endpoint, not + at an intervening relay, but may take place at a gateway + system linking the SMTP realm with other environments. + + [7] Crocker, D. Standard for the Format of ARPA Internet Text + Messages (RFC822), August 1982. + + [8] Rose, M. T., and Stefferud, E. A., Proposed Standard for + Message Encapsulation, January 1985. + + [9] Key generation for authentication and message text encryption + may either be performed by the sending host or by a + centralized server. This RFC does not constrain this design + alternative. Section 5.1.1 identifies possible advantages of + a centralized server approach. + + [10] Note that in the UNIX(tm) system, and possibly in other + environments as well, such a program can be invoked as a + "filter" within an electronic mail UA or a text editor, + simplifying the sequence of operations which must be performed + by the user. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Linn, Privacy Task Force [Page 23] + |