Mandatory email verification

Greetings:

Is anyone aware of a way to modify sendmail to require a verified digital
signature for all mail sent? This subject came up after a discussion
of the possible repercussions of forged email through port 25.
Even a good PGP user can't use manual encryption on a message-by-
message basis as a defense for false mail attribution. For example,
someone forges a defamatory message and signs your name to it. The
recipient brings it to public attention and you try to claim "it doesn't
have my PGP sig, therefore I didn't send it". The obvious counter is that
you purposely failed to sign it to preserve your plausible deniability.
The only way this would work is if the system you're on won't accept
mail unless accompanied by a digital signature, which would allow the
user to claim innocence if it wasn't his sig. The mailer would also have
to check the sig to ensure that it belongs to an authorized user on the
system to prevent people from creating one-time keys just to appease the
mailer and prevent their real sig from being used. Running this version
of "SIGmail" (<-- note flashy new marketing name) on your system would
seem to be a reasonable defense against claims of false attribution.

Has anyone done any work along these lines? Is there an obvious fault
with a system which would operate in this manner?

Please don't misconstrue this as an attack on anon mail, which obviously
needs to be preserved. What I'm interested in avoiding is mail forged
with another user's name. All that's required to do a convincing job now
is an account on the user's home system and some knowledge of ESMTP. Seems
to me like this is a potential disaster waiting to happen.

Maybe the H.E.A.T. crew can solve this one . . . Fabio, we need you!


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

D. C. Williams writes:
 > Is anyone aware of a way to modify sendmail to require a verified
 > digital signature for all mail sent?...

 > Has anyone done any work along these lines? Is there an obvious
 > fault with a system which would operate in this manner?

I think that changing "sendmail" to do this would have lots of
repercussions.  Many services send mail automatically, and most of
them aren't equipped to do digital signatures.

| GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5@tivoli.com>       |
| TAKE TWA TO CAIRO.          ||| Tivoli Systems, Austin, TX:        |
|     (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |

DC Williams writes:

| Is anyone aware of a way to modify sendmail to require a verified digital
| signature for all mail sent? This subject came up after a discussion
| of the possible repercussions of forged email through port 25.
| Even a good PGP user can't use manual encryption on a message-by-
| message basis as a defense for false mail attribution. For example,
| someone forges a defamatory message and signs your name to it. The
| recipient brings it to public attention and you try to claim "it doesn't
| have my PGP sig, therefore I didn't send it". The obvious counter is that
| you purposely failed to sign it to preserve your plausible deniability.
| The only way this would work is if the system you're on won't accept
| mail unless accompanied by a digital signature, which would allow the
| user to claim innocence if it wasn't his sig. The mailer would also have
| to check the sig to ensure that it belongs to an authorized user on the
| system to prevent people from creating one-time keys just to appease the
| mailer and prevent their real sig from being used. Running this version
| of "SIGmail" (<-- note flashy new marketing name) on your system would
| seem to be a reasonable defense against claims of false attribution.
| 
| Has anyone done any work along these lines? Is there an obvious fault
| with a system which would operate in this manner?

	Design areas to be worked out:
	Will the system drop such mail silently, or return it to the
sender?  Will the messages returned to sender be signed by the mail
system?  If so, will they contain any reference to the message sent?
How will you protect the keys used for signing?  If the 'bounce'
messages aren't signed, a great way to generate flamage would be to
send messages to the user claiming that his recent mail was not
properly signed, causing him to send another copy, annoying the hell
out of all the recipeints.

	I'd like to close this message by saying that mandatory
signing is not a good idea.  People will generate a low security key,
and leave it totally unsecured.  The way most folks with a clue deal
with forged mail is they see the writing style is different, the
person is advocating a new & different position, or the mail is just
random flammage.  Most folks regularly disregard this sort of thing as
children playing with a new toy.  Requiring the use of signatures for
all mail is silly.

Adam

> From: "Dr. D.C. Williams" <dcwill@ee.unr.edu>
> 
> Is anyone aware of a way to modify sendmail to require a verified digital
> signature for all mail sent?

This would be very difficult to do in the short-term because of the
current problems of few PKCAs and the relatively poor intergration of
signatures into current mail user agents.

But, rather than providing user-keyed authentication, it should be
possible for you to set up your sendmail so that you could prove that
an _outgoing_ message did or did not originate at your site (e.g.
rather than verify userx sent it you can say with reasonable certainty
that userx@my.domain sent that message.)  Create a public key pair for
the mail system.  Messages being sent out are given a signature based
upon the user who sent the message (the person who invoked
sendmail...), so if someone tried to forge mail that had the 
appearance of coming from your site you would be able to at least show
that it was not actually sent from the @foo.bar mail system.  It is
not too difficult to push the system a little further and be able to
show that if the message does have such a signature then either the
user did send the message or the originating system was hacked.  A
few more quick hacks would let someone send a mail message to the site
given on the From line and have it check the signature and report back
on whether or not the message was obviously forged or if it has the
right sending signatures.  

Such a system would only take a few hours of hacking to get
operational, and users would not be significantly inconvenienced by
it's operation and would only need to query it if they wanted to check
the validity of a message...

jim

Its my understanding that to be truly useful on multi-user
systems, digital signatures require some user input (eg, PGP
requires entering a pass phrase). Sendmail could be hacked
easily
enough to append signatures and to even ask the user for the
requisite pass phrase-- or sendmail can append the signature
automagically, using an environment variable (yuch, just a touch
insecure?) or some other method (a root-owned and executed shell
script).

The first method, having sendmail ask the user for the pass
phrase, is most secure, but also the most inconvienent. For
instance, at our site, we have several distributed
workstations. We send numerous mail messages to each other every
day, and signing each one would be a real pain. To prevent this
sendmail could be hacked to only require signatures on mail
messages addressed outside the domain. This still leaves us back
at the original problem-- one of us could flame the boss and
then
deny the authenticity of the message because it lacked our
signature.

The automagic method is frightfully insecure. Creating an
environment variable transparently requires that the pass phrase
be physically located on the system, instead of the user's
mind. (I wouldn't want to ask users to slip in their "pass
phrase" disk every morning when they log on). There is also a
question of trust-- a dishonest sysadm could easily break this
method. The dishonest sysadm could also easily break a shell
script method, as could anyone who got the root password.

Jim McCoy pointed out aptly that the hack could be done quickly,
but, laying technical issues aside, do we really want our
computers signing our mail for us (what about messages to
anonymous remailers-- a digital signature defeats that in short
order)? That's the real question.



-- 
Doug Shapter                
dps@kafka.atinc.com         
finger dps@kryten.atinc.com for PGP public key

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

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


	The last time I hacked a mailer (elm 2.4 to be specific) I
seem to remember that it invoced sendmail as a process rather than
connecting to it via port 25 to send mail. 

	It would seem that one could hack sendmail so as not to accept
non sendmail connections to port 25 from the local machine (it clearly
knows from the socket info structures who is connected on the other end
of the socket) or perhaps to refuse to accept user id from a port 25
connection on the local machine (instead indicating the origen of the
mail as user "sendmail25" or something similar).  The later approach
could be refined by adding a header line to the mail indicating it came
from port 25 rather than rejecting it - then all you would have to do is
make sure that the legitimate mailers were configured to invoke sendmail
as a process rather than via port 25, and the appearence of the warning
header line would be a red flag that something irregular happened in the
creation of the mail. 

	It might be necessary to hack the permanent sendmail process
listening on port 25 to accept mail from other spawned sendmail
processes via a memory to memory transfer (most unixes support this
these days) or via some other port than 25, or with an additional step
of passing the process id so it could check the UID of the process
sending it the mail to authenticate the sender.   [I am writing this
in a typically airheaded manner this afternoon without looking at
the sendmail source I have on the machine so I am a little vague about
how sendmail spawned talks to sendmail permanent to send mail, but whatever
technique is used here ought to be subject to a pass the process ID
or pass a magic cookie (hash of process ID and sendmail version perhaps?)
and the process id approach].

	Thus one need not bother with message signing at all, or if one wanted
to use it, could use it only to authenticate one sendmail process on your
local machine to another.

> From: dps@kafka.atinc.com (Doug Shapter)
> 
> Its my understanding that to be truly useful on multi-user
> systems, digital signatures require some user input (eg, PGP
> requires entering a pass phrase).

Not really.  The system I was sketching out would not require the user
to enter any information at all, the sendmail daemon would handle
everything and have the key for that mail server held internally.  The
purpose would not be to say that "User X" did or did not sign a
message, but to say _with reasonable assurance_ that the message
either came from someone logged in as userx@foo.com (there are other
alternatives, like the mail server being hacked, etc.)  The purpose of
such a system would not be to link mail messages to any real person or
identity, but to link it to an account on the sending host (and mostly
to link it to the sending host.)  Thus someone who just did a telnet
to port 25 and forged off a mail message would not be able to generate
the necessary site signature to pull off the charade unless they
managed to actually hack _into_ the mail server.  Bouncing messages
off a smtp port would no longer be enough to work.

In actual practice the keys would not need to be monstrously huge and
one could probably get by with a public key small enough to fit into a
TXT record in the DNS system.  It would be easier to break in to the
system than crack a 512 bit key...

The mail system would not be signing the messages for you, it would
just do a hash of a few choice lines from the header and sign those
with the mail system key.  It would not try to say that any particular
person sent a mail message but would instead say "to the best of my
knowledge this message came from my system and was sent by someone
accessing account userx" and no more.  This would probably be enough
to cut mail forgery through smtp by 90% among sites using the system.

jim