From: "Dr. D.C. Williams" <dcwill@ee.unr.edu>
Date: Wed, 28 Sep 94 06:34:03 PDT
To: dps@kafka.atinc.com (Doug Shapter)
Subject: Re: Mandatory email verification
In-Reply-To: <9409280832.ZM12030@kafka.atinc.com>
Message-ID: <199409281332.GAA11124@python>
MIME-Version: 1.0
Content-Type: text/plain


> 
> automagically, using an environment variable (yuch, just a touch
> insecure?) or some other method (a root-owned and executed shell
> script).

I'm now working on a system (internal to each machine) which checks
any mail to be sent for a signature (affixed by a mail front-end or
by the user if he prefers to use the raw mail interface). This sig
is produced by a key created my the system administrator solely for
the purpose of verifying mail authenticity - any user who wants more
security is still free to generate a separate key pair for encryption
purposes. All that would be required is to sign the cyphertext with the
"mail key" after encryption with whatever other key(s) the user wished
to use. The mail sig has to be the last signature affixed to the message
if it's to be stripped before sending (see below).

The problem of key pass phrases is one I hadn't thought of yet. 
Remember that the "mail key" pair is not intended for any purpose
beyond mail authentication. What if the private keys are stored in
separate directories with rwx permissions for the individual user
only? The keyring could be accessed by a mail program run by that user
but not by anyone else (except uid 0), which is as secure as any UNIX
system can hope for. Remember that uid 0 made the keys in the first place!
The script which adds the sig wouldn't need a unique passphrase to sign with
the "mail key". Of course, users' own private keys used for encryption
would be protected in whatever manner they see fit, although (as beaten
to death in another thread) keeping private keys on public machines is
often a risky proposition.

Once the system has verified that the mail submitted for transmittal does
indeed have a valid sig, the sig could be stripped before sending. This
would have absolutely no impact on other systems' mail, because all of
the "sig, verify, strip" processes are confined to the user's machine. In
fact, the mail recipient wouldn't even know this had occurred, ensuring
proper use with remailers.

All this system does is provide some reasonable protection for users against
mail forgery originating from their own machine. My experiments with
port 25 show that a telnet connection from a remote machine to port 25
causes the remote machine's address to appear in the ESMTP headers. However,
mail sent from a local connection to port 25 can't be readily distinguished
from mail sent via "normal" mail programs (mail, elm, pine, etc.). On the
systems I've examined, I can enter a user's login through port 25 and sendmail
will affix his real identity from /etc/passwd just as though that user had
sent the mail. For instance, a user can forge mail from root on their own
machine. I don't know about you, but that's something that concerns me.
It's entirely possible that someone impersonating root could send email to
a user to change his password as a "system test", giving the bad guy access
to someone else's account. Admittedly, this is a pretty benign example, but
the potential for real damage is there.

It might well be that I'm overly concerned with something that really isn't
a problem. However, the more I think about possible acts of "e-terrorism"
which can be caused by convincingly forged email, the more concerned I 
become. If everybody knew how insecure mail really is and afforded it the
proper amount of suspicion and distrust, this wouldn't be much of a problem
(I don't know anybody who believes that "for a good time, call 555-XXXX"
messages written in bathroom stalls were put there by the person who belongs
to that phone number). However, I sense that many well meaning but largely
uninformed people seem to think that email is secure, private, and inviolable.
Given that level of trust, the possible consequences which might flow from
convincingly forged email are significant. It's probably easier to fix the
mail than attempt to educate the public, although I might well be wrong in
that assessment.
 

=D.C. Williams	<dcwill@ee.unr.edu>