An amusing problem has occurred on the NADF exploder list that may have a
deeper message.
For the past five days, private e-mail from a very large organization (who
shall go nameless) has been appearing on the NADF's exploder list. Most has
been rather innocuous, but some has involved departing personnel, their
salaries, etc. -- fairly sensitve stuff.
Most, but not all of the mail has aparently been sent to one particular person,
VK, who is a member of the NADF. but recently other correspondence has been
showing up as well. How all this has come about makes a pretty good mystery. I
think I have my facts straight, but even if I am wrong in the particulars, the
message will still be clear.
Act 1, Scene 1. For reasons that are lost in the prehistoric past, the NADF's
exploder list program deletes the sender's From address, and substitutes the
address of the NADF exploder. However, some people complained that they could
never tell who sent a message, so someone modified the program to add the
sender's name in parentheses after the NADF exploder in the From address.
Act 1, Scene 2. The plot thickens. The organization in question is very
diverse, and has lots of incompatible e-mail systems running on a variety of
platforms, ranging from ccmail to X.400. They therefore installed a program
called Softswitch (with which I am completely unfamiliar), to act as an
internal gateway between these various e-mail systems. Softswitch also acts as
a gateway to the external world, translating incoming and outgoing e-mail into
the appropriate native system.
Act 1, Scene 3. The organization also operates a directory service, which may
or may not be X.500. In order to facilitate sending mail to correspondents who
are encumbered with those nasty X.400 verbose names, the Softswitch program was
configured to auto-register the originator of any e-mail messages it processed,
so that anyone who wanted to send mail to that person would only have to point
and click on the name, and the e-mail address would be inserted in the outgoing
mail.
Act 2, Scene 1. The leading man, VK, sent a very simple test message to the
NADF list, testing the gateway. The NADF list promptly returned his message to
him, appending his name to the NADF exploder list address. The Softswitch
program obligingly autoregistered VK's name with the new address.
Unfortunately, this new listing was higher in the collating sequence than the
previous listing.
Act 2, Scene 2. One or more individuals send VK an email message, but
apparently select the NADF address instead of his internal address from the
point and shoot directory. As a result, their private correspondence is copied
to the entire NADF list! Worse yet, the NADF list obligingly sends their
message back to VK, a member of the list, but with person X's name added after
the NADF list. Softswitch then adds this new name to the directory, so anyone
who sends mail to that person may also have their mail forwarded to the NADF as
well.
Act 2, Scene 3. Consternation reigns. Everyone is sending messages back and
forth to these principals, including copies of all the replicated mail, all of
which is showing up on the NADF list. People like me are beginning to post to
the NADF list as well, so my name is probably added to the organization's
directory.
Intermission.
Act 3. To Be Continued.
-----
The message for us in all of this is that we should be careful in designing
systems that cache user's names, email addresses, etc., and to ensure that the
user really wants to send mail to the person he has selected. Sometimes, too
much user friendliness can be dangerous.
Some of the embarrassment caused by this incident could have been avoided if
the organization had implemented PEM, and routinely encrypted their email. In
that case, even if the mail had been sent to the wrong address, no one else
would have been able to read it.
However, it is not beyond the realm of possibility that someone who knew about
this particular flaw in the organization's e-mail system could have taken
advantage of it by sending someone (anyone) in the organization some unsigned
mail purporting to be from one individual, but including his own certificate.
If the system auto-registered that user's bogus name and also included the
certificate, then mail sent to VK might have been encryted in someone else's
public key.
I think that this rather convincingly illustrates Steve Kent's concerns that
people wo'nt pay much attention to what they see on the screen, they will just
click OK when they think they know what they are doing.
I think this confirms the desirability of including the user's e-mail address
in his certificate, not as part of the distinguished name, but as a signed
extension attribute. Sending mail to someone at a different e-mail address than
is in their certificate should not be prohibited, but a red flag should be
raised to make sure that the user knows what he is doing. Even more to the
point, the common name that is in the certificate should match the common name
of the intended recipient, even at the risk of some additional verbosity.
'Nuff said.
Bob
--------------------------------
Robert R. Jueneman
Mgr., Secure Systems
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820 (rolls over to cellular and/or my house
if no answer -- have patience)