INTERNET-DRAFT Donald E. Eastlake 3rd CyberCash Expires: November 1997 May 1996 Mail Ubiquitous Security Extensions (MUSE) ---- ---------- -------- ---------- ------ Status of This Document This draft is file name draft-eastlake-muse-02.txt. Distribution of this document is unlimited. Comments should be sent to the ietf- muse@imc.org mailing list or to the author. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). Donald E. Eastlake 3rd [Page 1] INTERNET-DRAFT MUSE May 1997 Abstract Secure electronic mail can provide authentication of the source of mail and confidentiality for its contents. These features are becoming increasingly important as the Internet grows exponentially and email is increasingly used for critical, sensitive, and confidential communications. In addition, authentication can make mail filtering more effective and ubiquitous encryption indirectly makes all mail more secure be defeating traffic analysis based on distinctions between encrypted and non-encrypted mail and defeating bulk searching through insecure mail. However, use of secure mail is not widespread due to the problems of key distribution and lack of migration to secure mail enabled user agents. This draft proposes partial solutions to these two problems by using coarser grained identity to permit some authentication and confidentiality without user agent change, and secure DNS for key distribution. These changes also support limited host and domain level mail security policies. Acknowledgments The contributions of the following person to this draft are gratefully acknowledged: Ned Freed (Spam is the trademark name of a meat product by Hormel.) Donald E. Eastlake 3rd [Page 2] INTERNET-DRAFT MUSE May 1997 Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgments............................................2 Table of Contents..........................................3 1. Introduction............................................4 1.1 Benefits of Secure Mail................................4 1.2 Secure Mail Systems....................................4 1.3 So Why Isn't Secure Mail Used?.........................4 1.4 Overview Of The MUSE Solution..........................5 1.5 So Why Might MUSE Succeed?.............................5 1.6 But What About the End to End Argument?................6 2. Bypassing the Requirement for User Agent Migration......7 2.1 Host Level Mail Security...............................8 2.1.1 MUSE Policies........................................8 2.1.2 Detailed MUSE Processing............................10 2.1.2.1 Outgoing Mail Processing..........................11 2.1.2.2 Incoming Mail Processing..........................13 2.1.2.3 Local Mail........................................14 2.1.2.4 Transit Mail......................................15 2.2 Domain Gateway Level Mail Security....................15 2.3 Summary of MUSE Headers...............................16 3. Using DNS Security for Key Distribution................18 4. Processing Load Considerations.........................19 5. Security Considerations................................20 References................................................21 Author's Address..........................................22 Expiration and File Name..................................22 Appendix A: MUSE Policy Syntax............................22 Donald E. Eastlake 3rd [Page 3] INTERNET-DRAFT MUSE May 1997 1. Introduction 1.1 Benefits of Secure Mail Secure electronic mail can provide authentication of the source of mail and confidentiality for its contents. These features are becoming more important as the Internet expands. Increasingly critical, sensitive, and confidential mail is being passed over the network. Protection of the mail contents and verification of its origin are becoming ever more important. In addition, increasing amounts of email "spam" (unsolicited bulk messages, frequently with fraudulent headers) and forged mail are plaguing the network. Critical and sensitive email could be better protected and spam could be more reliably filtered if the use of secure mail were ubiquitous. Finally, a requirement by recipients that a substantial portion of all or at least of unanticipated mail to them be encrypted would improve security and decrease spam as follows: For the attacker, encrypting most or all mail makes traffic analysis based on which messages are encrypted and which unencryted much harder and perhaps insurmountably increases the work factor in attempting to scan all messages for "interesting" content. And encrypting a message with current mail security formats and algorithms entails substantial per recipient computation which would make massive "spam" impractical with current technology. 1.2 Secure Mail Systems Two generations of Internet standard secure mail have been developed. The Privacy Enhanced Mail (PEM) is defined in RFCs 1421, 1422, 1423, and 1424. Recently, the MIME [RFC 2045] security multiparts have been defined in RFC 1847 and secure mail derived by the generalization of PEM and use of MIME multiparts (MOSS) has been specified in RFC 1848. In the mean time, the most widely adopted secure mail on the Internet has been become PGP (Pretty Good Privacy, by Phil Zimmerman) [RFC 1991, 2015] and numerous other secure mail systems have been proposed. 1.3 So Why Isn't Secure Mail Used? Why has secure mail been so slow to be adopted? Donald E. Eastlake 3rd [Page 4] INTERNET-DRAFT MUSE May 1997 There are probably many reasons but one of the strongest is the problem of user agent migration. All of the systems mentioned above were initially designed with the idea that the end users who sent and received secure mail would use specially adapted mail programs and, in fact, they usually assumed the same special adaptations at each end. But many users are attached by circumstance or habit to a mail user agent that is not capable of producing or properly validating and/or decrypting secure mail. Even if their mail user agent is security capable, many users are not sufficiently motivated to make use of its security features. A second problem is that of key distribution. Most of these systems assume public key technology which requires each party to securely determine the public key of the other. (In some cases, secret key technology can be used. This requires each party to securely learn the secret key to be used and is thus no better from the point of view of key distribution.) Methods to obtain keys on line, such as the PGP key servers and inclusion of certificates from a hierarchy or web, have been limited and do not provide much assurance that the keying material obtained can be authenticated by the user's mail agent. 1.4 Overview Of The MUSE Solution MUSE partially solves the user agent migration problem by making significant optional security at the host and mail gateway levels, as well as at the user level, as described in section 2 below. MUSE partially solves the key distribution problem by supplementing existing techniques with secure key distribution via secure DNS as described in section 3 below. (Note: Throughout this document, hosts are assumed to be identified by domain name and users are assumed to be identified by email address of the form user-name followed by an "@" followed by a domain name. These are the normal identifiers that are actually in use in the Internet.) 1.5 So Why Might MUSE Succeed? Implementation of MUSE does not depend on end user action. It can be deployed by host, mail gateway, and DNS server administrators. These are the people who have to deal with security breakdowns, complaints about spam, etc., and are thus motivated to improve security. In addition, MUSE gives organizations a limited ability to enforce policies that require or prohibit the transmission or reception by Donald E. Eastlake 3rd [Page 5] INTERNET-DRAFT MUSE May 1997 that organization of encrypted and/or authenticated mail. Many organizations will choose not to impose such policies but any that wish to will be motivated to install MUSE. 1.6 But What About the End to End Argument? It is an architectural principle of the Internet that "end-to-end functions can best be realised by end-to-end protocols". See RFC 1958, Section 2.3. For example, the maximum assurance of confidential and authenticated email between two users requires encryption/decryption and digital signature/verification mechanisms as close as possible to each user, preferably on a laptop or other piece of hardware under their physical control. Why then does MUSE advocate mechanisms which can be viewed as being in the interior of the net and thus not end-to-end? There are two reasons as follows: One, MUSE can provide security in depth. Dependence on end users, or even host administrators in this age of ubiquitous personal computers, to properly configure, maintain, an utilize security is problematic and email security might depend on correct and error free action at both ends. MUSE can provide significant security over much of the path email follows even if only one or neither of the end parties is willing to make any effort in this matter or makes an incorrect effort. Even where both ends properly configure and use security, any additional confidentially and authentication provided by MUSE would not negate but further enhance the security of the email in question. Two, MUSE supports host and domain gateway level email security policies. Such policies are not end-user to end-user. For such policies, the "end" is the host or domain. For inherently host or domain level policies, such as requirement that all email exiting the whitehouse.gov domain be signed by "whitehouse.gov" or a requirement that all mail accepted by paranoid-host.foo.xx be encrypted, the MUSE host and domain level mechanisms are "end-to-end". Donald E. Eastlake 3rd [Page 6] INTERNET-DRAFT MUSE May 1997 2. Bypassing the Requirement for User Agent Migration Current implementations of email security use special mail user agents (MUAs), although in some cases this can be accomplished with a security "plug-in" or, with enough user effort, by a separate application. This can be good because you want the security operations of signing and/or encrypting at the origin of the message and authenticating and/or decrypting at the destination to be as close to the user as possible. This minimizes the extent of the transmission path during which the mail is unprotected. In fact, you would really want the MUA in some single-user hardware (perhaps a laptop computer) which the user keeps under their physical control for maximum security. However, there are a tremendous number of mail user agents (MUAs) and many of them do not support secure mail. In some cases, users are very attached to their MUA or do not have another easily available and do not want to or will not change. Even when a user has an MUA that supports security, many users just find it to be too much trouble to use. In such cases, they can still be provided significant security, through MUSE, by using coarser grained identity for authentication and encryption as explained below. Note that some users run their MUA to send and receive mail on multi-user computer systems which places them at the mercy of the computer operating system and ultimately gives them little more host level security in any case. Furthermore, there are some cases where an organization or host wishes to enforce, so far as possible, an email security policy such as requiring outgoing mail to be signed. MUSE can, within limits, assist such policies. The structure of the Internet for user to user mail between organizations, say X and Y, is now typically as shown below: +-------->The Internet<-------+ | | v v Firewall/Gateway X Firewall/Gateway Y | | | | | | | | user 1 System.A user 4 System.B laptop | \ laptop | \ | \ | \ user 2 user 3 user 5 user 6 laptop laptop MAIL STRUCTURE DIAGRAM [need to add some references back to this diagram in the text below...] Donald E. Eastlake 3rd [Page 7] INTERNET-DRAFT MUSE May 1997 Of course there are many variation on the above including multiple levels of firewall and directly connected systems with no firewall. 2.1 Host Level Mail Security Simple mail security can be provided at the host level of granularity. How to do this is generally described below in this introduction to section 2.1. Subsequent sections describe how to specify MUSE policy and give the details of the processing. Basically, hosts can provide mail security as follows: Authentication: Outgoing mail can be signed by the host by signing the mail as a message/rfc822 object with the key for the host. A key for "system.organization.tld" for example if mail is being send by user@system.organization.tld. Confidentiality: For encryption, if an authenticated mail confidentiality key is accessible for the remote user or host, the message can be encrypted directly to them by the host level mail transport software. On receipt: Mail would be checked to see if it is encrypted to that host. If so, it would be decrypted before being delivered. In addition, if it is signed by the source host or user, that signature could be validated. The mail could be bounced or flagged if the validation fails or flagged if validation succeeds. All such verification processing is security policy dependent. 2.1.1 MUSE Policies The above description is highly simplified. It does not describe any means for the user or host administrator to control the host level mail security processing or for the user of an mail user agent to be made aware that mail received has been authenticated. Different hosts will have different policies. In addition, different users will have different policies (although sometimes such policies will be subordinated to their host's policy). There are four possible sources for MUSE policy: (1) the global MUSE default policy defined in this document, (2) the host's MUSE policy, (3) the sender's static MUSE policy, and (4) the sender's per message policy as indicated by the "muse-policy: " header in an outgoing message. Policies 2 and 3 would normally be defined by a per host and per user file. This file contains simple text each line of which is interpreted as if it appeared in a "muse-policy:" header. The Donald E. Eastlake 3rd [Page 8] INTERNET-DRAFT MUSE May 1997 location and name of this file is system dependent. [Probably ".muse-policy" on UNIX like systems.] Each policy component consists, as described in Appendix A, of a policy category followed by a verb and possibly additional modifiers. The categories are: "encrypt", "sign", "verify", and "strip". The "sign" and "encrypt" categories control host level authentication and host executed encryption of outgoing messages. The "verify" and "strip" categories control the handling of incoming signed messages. Incoming messages encrypted to a host must always be decrypted because only the host will have access to its private key. Delivering such an encrypted-to-host message to a user without decrypting it would be useless. The verbs available in each category are: "always", "once", and "never". Possible modifiers are "mandatory", "requested", "host", and "user". In the absence of modifiers, policies are treated as if the defaults "requested" and "user" appeared in each case. If a category appears more than once in a single policy file or in the headers of a single messages, the policy specification last appearing for that category prevails. Multiple policies can appear in a "muse-policy:" header or line in a policy file if separated by commas. Policy files lines may include parenthesized comments and be wrapped as in RFC 822 headers. [do we need to add "filters" such that policy could be different for different senders/destinations? could be per policy line and of the form to restrict be sender and to restrict by destination. this would requiring adding an optional number or the like to muse-policy header lines to specify ordering or policy application or making the effect dependent on the order of entries.] [do we need to add hooks in the policy syntax to invoke external programs at various steps during the MUSE processing so you could, for example, easily specify to run a virus checker on incoming mail... ?] The following definitions are used in explaining the effect of MUSE policies verbs and modifiers: Signed: For the purposes of this draft, mail is signed if the outer MIME type is a proper multipart/signed. This means that the body interior to the first part of the multipart/signed has been signed. (MUSE implementations MAY also recognize as signed PEM, classic PGP, or other non-MIME formatted types of signed but not encrypted messages messages.) Encrypted: For the purposes of this draft, mail is encrypted if the Donald E. Eastlake 3rd [Page 9] INTERNET-DRAFT MUSE May 1997 outer MIME type, ignoring any number of completely enwrapping multipart/signed structures, is a proper multipart/encrypted. This means that the part of the message interior to the second part of the multipart/encrypted has been encrypted. (MUSE implementations MAY recognize PEM, classic PGP, or other non-MIME formatted types of encrypted messages and enwrapping signed structures.) The host level policy is the MUSE global default except as overridden by a host policy file. If the host policy has the modifier "host" for any category, the host policy prevails and any user specified policy for that category is ignored. If the host policy file includes the modifier "user" for any category or has neither the "user" or "host" modifiers, then the host policy is overridden by the user's policy if there is one. The user's policy is as specified in the user's policy file except that for outgoing messages sent by the user, a "muse-policy:" header or headers in the message override the user's policy file. "user" or "host" modifiers are ignored in user MUSE policy. The global policy defaults for MUSE are as follows: encrypt never requested user sign once requested user verify always requested user strip never requested user These MUSE standard defaults are biased against encryption and in favor of authentication. Authentication only implementations of MUSE, without confidentiality, are permitted. 2.1.2 Detailed MUSE Processing The following definitions are useful in describing MUSE mail processing in detail: Origination MUSE Header Processing: Find and parse any "muse- policy:" headers at the top level of the message and remove them. Determine and remember the MUSE policy based on any host, user, and message header MUSE policy declarations. Suppress any "muse- authenticated:", "muse-confidentiality:", "muse-not-authentic:", and "muse-sender:" headers by prefixing them with "muse-bogus: by /host/ at /dt/ " where /host/ is the fully qualified domain name of the host doing the processing and /dt/ is the date and time of processing in RFC 822 format. Donald E. Eastlake 3rd [Page 10] INTERNET-DRAFT MUSE May 1997 Destination MUSE Header Processing: Suppress any "muse- confidentiality:", "muse-authenticated:", "muse-not-authentic:", "muse-policy:", and "muse-sender:" headers by prefixing them with "muse-bogus: by /host/ at /dt/ " as above. Signature Processing: Add a "muse-sender: /rfc822-address/ at /dt/" header and then sign the resulting message/rfc822 MIME object. (SMTP/RFC822 permits an arbitrary "from:" address to be specified in a message. MUSE does not interfere with that feature but authenticates what will be the SMTP envelope sender address by including it within the signed portion of the message. As a local mater, the local user name that is sending the message must be securely communicated to the MUSE equipped MTA. This name is then extended with the hosts fully qualified domain name.) Copy all headers from the signed object to the new outer message header except "muse-" and "content-" headers. There should be no "muse-" headers in the outer message and its "content-" header should be appropriate for the multipart/signed type it carries. Encryption Processing: Encrypt mail as a message/rfc822 MIME object under the destination key. Add a cc to musemaster@host, where "host" is the host where encryption is being done, and encrypt to that as another recipient. (This is necessary so that the copy of the message in any bounces that are received can be decrypted.) Only required mail routing headers are copied to the new outer message and supplemented by a new "date:" header and by "content-" headers appropriate for the multipart/encrypted type. Destination Key: This key is determined by looking for a key for the destination user (see section 3). If none is available, then looking for a key for the destination user's email address domain name part. The first applicable key found above is the destination key. If none is found, there is no destination key. If the implementation of MUSE does not include confidentiality, proceed as if there were no destination key. If key access attempts time out or otherwise fail in a transient fashion, the mail SHOULD be queued in a manner similar to transient delivery failure queuing. 2.1.2.1 Outgoing Mail Processing The following steps describe the MUSE processing of outgoing mail. This processing may be organized or performed in any order provided the result is the same as the following organization and order: (1) Do Origination MUSE header processing. Donald E. Eastlake 3rd [Page 11] INTERNET-DRAFT MUSE May 1997 (2) Confidentiality (Encryption) Processing: (2a) If the policy is "encrypt never requested" go to step 3. (2b) Determine the Destination Key as described above. (2c) Perform actions as per policy below: encrypt always requested: Perform encryption processing under the destination key (this may result in superencryption) or pass on mail unencrypted if there is no destination key. encrypt always mandatory: Perform encryption processing under the destination key (this may result in superencryption) or bounce it back to the originator if there is no destination key. encrypt once requested: If the mail is encrypted, do nothing. If the mail is not encrypted, perform encryption processing under the destination key or pass on mail unencrypted if there is no destination key. encrypt once mandatory: If the mail is encrypted, do nothing. If the mail is not encrypted perform encryption processing under the destination key or bounce it back to the originator if there is no destination key. encrypt never mandatory: Pass the mail on if it is unencrypted or bounce it back to the originator if it is encrypted. (3) Authentication Processing. Perform actions as per policy below: sign always: Perform signature processing with the local host key. (The "mandatory"/"requested" modifier is ignored. This may result in nested signatures.) sign once: Perform signature processing with the local host key unless the message is already signed. (The "mandatory"/"requested" modifier is ignored.) sign never requested: Pass on the mail without signature processing. sign never mandatory: Strip off and discard any completely enwrapping signatures, saving any "received:" lines and adding them back after removing the surrounding multipart/signed, and then pass on the resulting message. (4) Perform remainder of standard non-MUSE mail processing, including addition of a "received:" header. Donald E. Eastlake 3rd [Page 12] INTERNET-DRAFT MUSE May 1997 2.1.2.2 Incoming Mail Processing (1) Do Destination MUSE Header Processing. (2) Determine if message is encrypted to host. If not, go to step 3. In making this determination, after checking to see if the entire message is encrypted, if it is not recursively examine all visible MIME parts to see if any is encrypted. (This is necessary, for example, to find and decrypt any bounced messages copies that were encrypted by this host.) If an interior encrypted MIME part is found, decrypt it as below. If the message is encrypted to the host, see if there are any signatures enwrapping the encrypted message (or enwrapping at any higher level the interior encrypted MIME part). If there are and verify policy is anything other than "never", verify as many as possible, remember their signers, and strip them off. If there are signatures and verify policy is "never", just strip these signatures. (Note: the signatures will no longer verify after the encrypted mail they enclose has been decrypted so they will be useless.) When stripping signatures or the headers associated with a multipart/encrypted, also remember any "received:" lines in the stripped headers. Then decrypt the message or interior MIME part(s), remember that you have done so, and go to step 1 or step 2 depending on whether the resulting decrypted part is at the top level or an interior body, respectively. (A message may have been encrypted and then superencrypted to a host.) (3) Verification Processing. Perform actions as per policy below: verify never: Do nothing. (The "mandatory"/"requested" modifier is ignored.) verify once requested: Try to verify the outermost fully enclosing signature if there is one and remember the results. If the message is not signed, got to step 5. verify once mandatory: Try to verify the outermost enclosing signature and remember the results if there is one. If verification is not possible, bounce back to originator or discard as per local policy. verify always requested: Try to verify all fully enclosing signatures and remember the results for each. If the message is not signed, go to step 5. verify always mandatory: Try to verify all fully enclosing signatures and remember the results for each. If verification is Donald E. Eastlake 3rd [Page 13] INTERNET-DRAFT MUSE May 1997 not possible, bounce back to originator or discard as per local policy. (4) Strip Processing. Perform actions as per policy below. (The "mandatory"/"requested" modifier is ignored in all cases.) strip never: Do nothing. strip once: Strip the outermost enwrapping signature and perform destination MUSE header processing on the result, if there is such a signature. Remember any "received:" headers that are removed. strip always: Strip all enwrapping signatures and perform destination MUSE header processing on the result, if there were any such signatures. Remember any "received:" headers that are removed. (5) Header Injection. Add a muse-authenticated: from /sender/ by /checker/ at /dt/ or muse-not-authentic: claimed from /sender/ by /checker/ at /dt/ header for each enwrapping signature found in steps 2 and 3 that was verified or which could not be verified, respectively. [Should header distinguish between a verification that could not complete and one that found the signature to definitely be bad?] /checker/ is the domain name of the host that performed the authentication. /sender/ is the email address from the "muse-sender:" header protected by the authenticated signature. /dt/ is the RFC 822 format date and time that the verification was performed. Add a muse-confidential: to /decryptor/ at /dt/ header for encryption removed in step 2. /decryptor/ is the domain name of the host to which the message had been encrypted and which performed the decryption. /dt/ is the RFC822 format date and time at which the decryption was performed. Restore any "received:" header removed in steps 2 and 4. (6) Perform remainder of standard non-MUSE mail processing including addition of a "received:" header. 2.1.2.3 Local Mail Mail that that is sent locally on a MUSE equipped host should be processed as if it went through the outgoing mail processing and then Donald E. Eastlake 3rd [Page 14] INTERNET-DRAFT MUSE May 1997 the incoming mail processing. However, enormous efficiencies in processor time can be achieved by making a few special test as follows: (1) If the MUSE policy and Destination Key situation would call for encrypting the mail to the current host, then don't bother. It will take a lot of computation and you'll just have to decrypt it again. In this case, the "muse-confidential:" header that would have resulted from the encryption and then decryption SHOULD be added. (If the policy and Destination Key are such that the mail would be encrypted to the destination user, then this encryption SHOULD be performed. Mail in the user's "in box" will be less vulnerable if encrypted.) (2) If the MUSE policy is such that the message would be authenticated and then that signature verified and stripped off, then don't bother. It will take a lot of computation for no good purpose. If the policy is such that a signature would be added and not stripped, then it MUST be added, even if the mail is local. In either case, a "muse-authenticated:" header that would have resulted from the signing and verification MUST be added if verification policy calls for it. 2.1.2.4 Transit Mail Transit mail is mail that neither originates nor terminates at the host in question unless that host is acting as a mail gateway as described in section 2.2. Ordinary non-MUSE mail processing is performed on transit mail, including addition of a "received:" header. No special MUSE processing is done. 2.2 Domain Gateway Level Mail Security A number of steps must be taken to properly handle MUSE mail at a gateway. (A mail gateway is also a host and performs the processing specified in 2.1 above for locally originated and locally terminating mail.) For gateway mail policy, a gateway mail host has two additional policy files [.muse-gateway-out, .muse-gateway-in ?]. The gateway can not access the remote user policy file but does take into account any "muse-policy:" header it finds at the top level of an outgoing message (and removes them to the extent it can do so without breaking retained signatures). For outgoing gateway mail, the situation is somewhat simpler. Hosts Donald E. Eastlake 3rd [Page 15] INTERNET-DRAFT MUSE May 1997 that send mail out through the gateway are normally manually configured to do so. A local gateway policy, not specified by MUSE, must be adopted as to what evidence MUSE will accept at the gateway to trust that it knows the host that the mail is originating from. This could be IP address but the recommended technique is to have all hosts forwarding to the gateway have a "sign always" policy and use these signatures to verify that the outgoing mail is coming from within the domain. Gateways MUST NOT sign mail whose sender they can not authenticate according to their local policy. The verify and strip parts of the outgoing gateway policy are first applied, then the sign and encrypt parts. For incoming gateway mail, the situation is somewhat more complex. If the incoming gateway is implemented invisibly, by rewriting the addresses of outgoing messages to encourage replies to go directly to the gateway, etc., the it is a matter of local knowledge at the incoming gateway that it is a gateway and when it should apply host MUSE policy or incoming gateway MUSE policy. In this case, to senders, it appears to be the destination host. However, in the case where an incoming gateway is implemented by MX records, MUSE processing can not be done to it. The verify and strip parts of the incoming gateway policy are first applied then the sign and encrypt parts. Hosts receiving incoming mail that they trust is from a gateway modify their destination MUSE header processing to retain any "must-authenticated:", "muse- confidential:", and "must-not-authentic:" headers from the gateway that they would otherwise declare bogus. It is recommended that such hosts use the gateway signature to confirm that mail is from the gateway and that gateway incoming policy include "sign always". 2.3 Summary of MUSE Headers All header lines beginning with "muse-" are reserved for use by MUSE or future extensions thereof. The six such headers defined in this draft are briefly explained below in alphabetic order: muse-authenticated: from /sender/ by /checker/ at /dt/ Indicates that an incoming message has been confirmed as from the RFC 822 address /sender/ with the verification done by host /checked/. /dt/ is the RFC 822 formatted date and time of this verification. muse-bogus: by /host/ at /dt/ /bogus-muse-header/ This header is used to prefix other apparent muse headers (the /bogus-muse-header/) when received from an untrusted or inappropriate source. This stops the /bogus-muse-header/ from being recognized or trusted. /host/ is the fully qualified domain Donald E. Eastlake 3rd [Page 16] INTERNET-DRAFT MUSE May 1997 name of the host adding the muse-bogus prefix and /dt/ is the RFC 822 formatted date and time of prefixing. muse-confidential: to /decryptor/ at /dt/ This header indicates that an incoming message was successfully decrypted at the host whose fully qualified domain name is /decryptor/. /dt/ is the RFC 822 formatted time the decryption occurred. muse-not-authentic: claimed from /sender/, bad by /checker/ at /dt/ This header indicates that an incoming signature and signed "muse-sender:" could not be verified. /sender/ was the claimed sender in the unverified "muse-sender:" header. /checker/ is the domain name of the host that performed the failing verification and /dt/ is the RFC 822 formatted date and time of the check. muse-policy: // This header is used by a user to state its requested MUSE policy to their local host (and outgoing gateway if the local host is configured not to strip out "muse-policy:" headers). /policies/ are the policy statements as per Appendix A. muse-sender: /rfc822-address/ at /dt/ This header is added to mail by a MUSE host or gateway before signing the message. It causes the authentic local or trusted SMTP envelope sender address to be incorporated into the authenticated message/rfc822 body part. /dt/ is the RFC 822 formatted date and time that the muse-sender header is added. Donald E. Eastlake 3rd [Page 17] INTERNET-DRAFT MUSE May 1997 3. Using DNS Security for Key Distribution Section 2 above does not address the second problem holding back ubiquitous secure mail, the problem of key distribution. The private keys for signing/decrypting at a host or gateway are normally configured on line at that host or gateway and thus available. But how do you find the public key, or determine the lack of such a key, for a remote user, host, or gateway for encrypting/verifying? The answer is DNS Security as described in RFC 2065. (See also RFC 1034 and 1035 for DNS background.) You can find a key for a user or host by looking for authenticated KEY RRs whose owner name is that host's domain name or user's email address mapped into a domain name. If the retrieval fails hard, then there is no KEY in the DNS for that user. If the retrieval times out, you do not know. If one or more KEY RRs are returned, MUSE software must examine them to see that at least one has the appropriate flag bits to indicate that it is a user KEY authorized for use in mail. If an appropriate KEY is found for a destination user or host, it can be used to encrypt mail being sent to that destination. If a signed message has been received and an appropriate key is found for the signer, then the signature can be authenticated. Authentication of retrieved KEY RRs is provided automatically by security aware DNS resolvers which must be used on MUSE equipped hosts that perform encryption or signature verification. A MUSE implementation that only signs and/or decrypts messages does not need to access remote keys. Donald E. Eastlake 3rd [Page 18] INTERNET-DRAFT MUSE May 1997 4. Processing Load Considerations The cryptographic calculations involved in signing, verifying, encrypting, and/or decrypting messages can impose substantial processing loads. Installing MUSE software on an existing host with high mail traffic or a busy mail gateway may produce congestion and make it impossible to keep up with the mail flow. The largest part of this load will normally be public key computations which are per message. This additional processing time will be affected by message length only as a second order effect. There are only 86,400 seconds in a day. Assuming a gateway or host took an average of 2 seconds per message to sign/encrypt/verify/decrypt, the maximum it could possibly hand would be 43,200 per day. In fact, due to variations from hour to hour and from day to day, substantial congestion at certain times could begin at around an average of 6,000 messages a day for such a gateway (assuming the monthly volume to be around 100 time the busy hour). Because this is primarily a computational load due to multi-precision arithmetic, processors that are faster and/or have wider arithmetic are the best solution. For example, a 150 megahertz 32 bit processor would, for this application, have roughly a quarter the capacity of a 300 megahertz 64 bit processor. Donald E. Eastlake 3rd [Page 19] INTERNET-DRAFT MUSE May 1997 5. Security Considerations The use of coarser grained identification and partial path encryption for email security provides a lower level of security to the end user than direct user to user authentication and encryption. In the case of host level mail security, the difference may not be large if the user was dependent on host security in any case. But domain gateway level mail security, while better than nothing, is noticeable less security than user level security. In addition, there might be circumstances under which such gateway or host level security would decrease the incentive for superior user level security. MUSE provides policy options which can attempt to filter out encryption, block encrypted mail, strip off authentication, require signing, etc. These policies only work to the extent that such encryption or authentication is based on the MIME security multiparts or other syntax recognized by the MUSE implementation. Encryption or authentication could by marked as a MIME application type or other non-RFC1827 formatting and encrypted messages can be hidden by stegeographic techniques. Such techniques would not be recognized by MUSE. In addition, MUSE could easily be fooled by weak algorithm or key selection, including deliberate use of a compromised key. The use of headers without any inherent security, such as "muse- authenticated:", to control or flag the results of mail security is a potential weakness. Great care must be taken in configuration, user interface implementation, and user education to avoid insecure configurations and excessive user confidence in spoofable MUSE headers. While security can be improved by the use of the techniques described in this draft, failure to secure other parts of the mail process can negate such improvements. For example, using MUSE to add host level authentication and verification may do little good if the user receives and transmits mail via an insecure link between a personal computer client and the MUSE enhanced software on their mail server host. Donald E. Eastlake 3rd [Page 20] INTERNET-DRAFT MUSE May 1997 References RFC 822 - D. Crocker, "Standard for the format of ARPA Internet text messages", 08/13/1982. RFC 1034 - P. Mockapetris, "Domain names - concepts and facilities", 11/01/1987. RFC 1035 - P. Mockapetris, "Domain names - implementation and specification", 11/01/1987. RFC 1421 - J. Linn, "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", 02/10/1993. RFC 1422 - S. Kent, "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", 02/10/1993. (Pages=32) RFC 1423 - D. Balenson, "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", 02/10/1993. RFC 1424 - B. Kaliski, "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", 02/10/1993. RFC 1847 - J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 10/03/1995. RFC 1958 - B. Carpenter, "Architectural Principles of the Internet", 06/06/1996. RFC 1991 - D. Atkins, W. Stallings, P. Zimmermann, "PGP Message Exchange Formats", 08/16/1996. RFC 2015 - M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", 10/14/1996. RFC 2045 - N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", 12/02/1996. RFC 2065 - Domain Name System Security Extensions, D. Eastlake, C. Kaufman, January 1997. Donald E. Eastlake 3rd [Page 21] INTERNET-DRAFT MUSE May 1997 Author's Address Donald E. Eastlake, 3rd CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 USA Telephone: +1 508-287-4877 +1 508-371-7148 (fax) +1 703-620-4200 (main office, Reston, Virginia, USA) email: dee@cybercash.com Expiration and File Name This draft expires November 1997. Its file name is draft-eastlake-muse-02.txt. Appendix A: MUSE Policy Syntax ::= encrypt | sign | verify | strip ::= always | never | once ::= mandatory | requested | user | host ::= *( ) ::= *(,) Comments are parenthesized and lines may be wrapped as in RFC 822 headers. Donald E. Eastlake 3rd [Page 22]