In 1997 I proposed something along these lines. Appended at the end is
the last rev I did of the Internet Draft...
Donald
===================================================================
Donald E. Eastlake 3rd +1 914-276-2668 [EMAIL PROTECTED]
65 Shindegan Hill Rd, RR#1 +1 914-784-7913(w) [EMAIL PROTECTED]
Carmel, NY 10512 USA
From: Bill Stewart <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
Date: Mon, 13 Sep 1999 18:00:49 -0700
To: Russell Nelson <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
>>On Sat, Aug 21, 1999 at 10:09:31PM -0400, Russell Nelson wrote:
>>> I've been thinking about cryptographic signing of messages at the mail
>>> transfer agent level. I can think of how to do it, but I'm not sure
>>> what problem it solves. :) Anyone have any ideas?
>>
>At 12:01 PM 8/22/99 -0700, Eric Murray wrote:
>>I wrote a similar system for Sun 4 or 5 years ago. However its purpose
>>was to encrypt the email for secrecy. It used sendmail and PGP, would
>>automagically encrypt messages sent to hosts/domains registered in a
>>config file, and would use the same config file to attempt to decrypt
>>incoming PGP'd messages.
>
>PGP/NAI developed an SMTP forwarder system that does rule-based processing
>with capabilities like
> - Encrypt outgoing mail when possible
> - Block unencrypted outgoing mail to some/all sites
> - Block encrypted outgoing mail to some/all sites
> - copy+encrypt in/outgoing mail to Corporate Email Escrow
> - Block outgoing mail not also encrypted to Corporate Escrow
> - Sign&date incoming or outgoing mail
>This was during their Corporate Escrow period, so we all taunted them about
>it,
>rather than doing much thought about what things might be useful.
>
>Cryptographic signing of the messages can be useful in some
>business environments, though I'd prefer encryption+signing for many of them.
>If you always sign outgoing mail, and somebody asserts that
>an unsigned message is from your company, you've got some ability to
>argue that it's forged. More importantly, if someone knows you
>always sign your mail, and they receive unsigned mail claiming to be from you,
>you and they can be suspicious.
>
>One of the fun things about just doing signatures is that you can
>distribute the software for free if you want, without US export laws.
>
>A big problem with this, though, is making very sure that the software
>doesn't sign things it's not supposed to sign. This is hard, because
>it depends on the user's configuration of their mailserver and firewalls,
>which is mostly out of your control - having software with your name on it
>that gets abused this way would be Really Bad.
>
> Thanks!
> Bill
>Bill Stewart, [EMAIL PROTECTED]
>PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
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-
[EMAIL PROTECTED] 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]
Next page...
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 [EMAIL PROTECTED]
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 <s:pattern> to restrict be sender and <d:pattern> 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: /<policies>/
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: [EMAIL PROTECTED]
Expiration and File Name
This draft expires November 1997.
Its file name is draft-eastlake-muse-02.txt.
Appendix A: MUSE Policy Syntax
<category> ::= encrypt | sign | verify | strip
<control> ::= always | never | once
<options> ::= mandatory | requested | user | host
<policy> ::= <category> <control> *( <options>)
<policies> ::= <policy> *(,<policy>)
Comments are parenthesized and lines may be wrapped as in RFC 822
headers.
Donald E. Eastlake 3rd [Page 22]
