text.tex

早期freebsd实现

% begin text

\banner

\section{Introduction}
Initially,
a brief model of a user community employing a trusted mail service is
introduced.
Following this introduction,
a prototype system is described which attempts to meet the needs of a user
community.
Finally,
open issues are discussed,
which are currently not satisfied by the prototype system or its model of
operation.

Two or more entities,
called {\it users},
wish to communicate in a {\it secure} environment.
Depending on their available resources,
different levels of security are possible.
At the extreme,
two parties with substantial resources may wish to communicate in a fashion
which prevents any third parties,
known as {\it adversaries},
from observing their communication.
At this level,
not only is an adversary unable to capture the communication for analysis,
but in fact, the adversary is unaware that any communication is occurring at
all.
In most applications,
this level of security is prohibitively expensive.
A more economic method is to translate messages into a form which is useless
to an adversary and then to communicate those messages on an insecure medium.

This latter method requires the two users to have some sort of {\it key}
with which to ``lock'' the plaintext into ciphertext when transmitting,
and then to ``unlock'' the ciphertext back into useful form when receiving.
Hence, there are two central issues to deal with:
\underbar{first},
keys must be generated, distributed, and maintained in a secure fashion;
and,
\underbar{second},
the keys must be ``intricate'' enough so that sense can't be made out of the
ciphertext without knowledge of the key.
The first part is handled by a {\it key distribution center} (\KDC/),
which maintains a list of users and a set of keys for each pair of users.
The second part relies on sophisticated encryption and decryption algorithms.
It is beyond the scope of this paper to describe cryptographic techniques in
detail.
For a detailed survey of this area, the reader should consult \cite{VVoyd83}.

\tagfigure{1}{The \MTS/ Model}{mtsmodel}
In the context of our discussion (using the terminology of \cite{X.400}),
the medium used to transport is supplied
by a {\it message transport system} (\MTS/),
which is composed of one or more {\it message transport agents} (\MTA/s).
Usually,
the entire \MTS/ is distributed in nature,
and not under a single administrative entity;
in contrast, an \MTA/ is usually controlled by a single administration and
resides in a particular domain.
At every end-point in the medium,
a {\it user agent} (\UA/) acts on behalf of a user and interfaces
to a local \MTA/.
This model is briefly summarized in Figure~\mtsmodel.

A message, in our context, consists of two parts:
the {\it headers} and the {\it body}.
The headers are rigorously structured;
they contain addressing information and other forms useful to a \UA/.
The body is freely formatted and is usually not meaningful to a \UA/.

When a message is sent from one user to another,
the following activities occur:
The originating user indicates to the \UA/ the address of the recipient;
the \UA/ then posts the message through a {\it posting slot} to an \MTA/,
which involves a posting protocol in which the validity of the address
and the syntax of the message are considered.
Upon successful completion of the protocol,
the \MTA/ accepts responsibility for delivering the message,
or if delivery fails, to inform the originating user of the failure.
The \MTA/ then decides if it can deliver the message directly to the
recipient;
if so, it delivers the message through a {\it delivery slot} to the
recipient's \UA/,
using a delivery protocol.
If not, it contacts an adjacent \MTA/, closer to the recipient,
and negotiates its transfer (using a protocol similar to the posting protocol).
This process repeats until an \MTA/ is able to deliver the message,
or an \MTA/ determines that the message can't be delivered.
In this latter case,
a failure notice is sent to the originating user.

\tagfigure{2}{Mappings in the \MTS/ model}{mappings}
It is important to note that there are two mappings which occur here.
The first, which is performed implicitly by the originating user,
maps the name of the recipient into the recipient's address;
the second, which is performed explicitly by the \MTS/,
maps the address of the recipient into a route to get from the originator's
\MTA/ to the recipient's \MTA/.
These mappings are depicted in Figure~\mappings.

Obviously, there is no guarantee that the \MTS/ can be made secure,
in {\it any} sense of the word.
This is particularly true if it is under several administrations.
Regardless of the number of administrations in the \MTS/,
this problem quickly degenerates to a problem of
Byzantine generals\cite{LLamp82}.
Further, trying to secure each \MTA/ in the path that a message travels is
equally questionable.

\tagfigure{3}{Modifications to the \MTS/ model}{tmodel}
To support secure communications in this environment,
a new entity,
the {\it trusted mail agent} (\TMA/) is introduced into our model.
A solution is to have the \UA/ interact with this entity
both when posting a message and when taking delivery of a message.
The \UA/ first contacts a \TMA/ to encrypt the body of the message for the
recipient,
prior to pushing it through the posting slot.
Upon receipt from the destination \MTA/,
the \UA/ examines the message and contacts
the \TMA/ to decipher the body of the message from the source.
An overview of the relationship between the standard \MTS/ model
and the augmentations made for the \trustedmail/ system is shown in
Figure~\tmodel.

To achieve these tasks,
the \TMA/ interacts with a {\it key distribution service} (\KDS/),
which manages keys between pairwise users.
At this point, a third mapping takes place:
the \UA/ must be able to map addresses into the identifier(s)
by which the originator and recipient are known by the \TMA/ and \KDS/.
These identifiers are known as \KDS/ IDs, or simply IDs.
Usually, a fourth mapping also occurs,
which maps the ID of a user into the name of a user.
In our context,
there is an exact one-to-one mapping between the name of a user and the ID
of that user.
In contrast,
there may be a one-to-many mapping between the name of a user and
that user's address in the \MTS/.
Further, there are usually many different routes which a message may traverse
when going from an originating user to a recipient user.

The \TMA/ is said to be {\it trusted} because it can be relied on to perform
only those actions specifically requested by the user.
In the context of this paper,
this means, given proper construction and maintenance of the \TMA/,
that the software will communicate with the \KDC/ in some secure fashion to
negotiate key relationships and that it will not disclose those key
relationships to other parties.
Furthermore,
the body of mail messages exchanged between users which employ
a trusted mail agent will be unintelligible to other parties.
Finally,
a recipient of a message receives authenticated information from the
trusted mail agent as to the identify of the sender.

Hence,
when each user employs a \TMA/,
end-to-end encryption occurs at the \UA/ level
(to avoid any problems with malicious \MTA/s).%
\nfootnote{Note that in the scope of this system,
the end-points are the user agents, not the hosts they reside on.
In fact,
it may very well be the case that the user agent and the local message
transport agent do not reside on the same host.}
Any adversary listening in on the \MTS/,
may observe messages,
but make no sense out of them
(other than rudimentary traffic analysis).
Note, however,
that since the medium itself is not secure,
an adversary may still introduce new messages,
corrupt messages,
or remove messages,
as they traverse the \MTS/.
In the first two cases, however,
the recipient would be suspicious
because the adversary lacks the encrypting key employed by the source user.
In the third case,
the source user can retransmit the message after a suitable time.
Of course,
there is no built-in retransmission policy~---~this aspect depends on the
user's sending mail and is beyond the scope of the system.

It is important to understand the target community for the \trustedmail/ system
described herein.
In particular,
the \TMA/ is intended for a commercial and not a military environment.
This distinction is important,
since it is the {\it fundamental} assumption of this paper that
the latter community has much stricter requirements than the former.
Because of this,
the prototype system is able to make certain simplifying assumptions which
permit it to operate in a mode which is less secure than military
applications would permit.
Although these issues are explored in greater detail at the end of the paper,
for the moment recall that, like most qualities, trustedness is not absolute:
there are varying degrees of trustedness,
and as a system becomes more trusted,
it becomes more expensive, in some sense, to operate and maintain.

It is perhaps instructive at this point to consider why the introduction of a
key distribution center is appropriate in this environment,
and why the {\it fundamental} assumption that trusted mail agents do not
directly communicate with each other is necessary.
Although a user agent is able to converse with the local message transport
agent in real-time,
it is frequently not able to communicate with other user agents in real-time.
Furthermore,
considering the vast problems and overhead
of trying to establish secure communications from ``scratch''
(a problem far beyond the scope of this paper),
it is would not be a good idea to try and communicate key relationships with
other user agents,
even if it were always possible to do so.
In addition,
by separating the trusted aspects of the message transport system from the
system itself,
many other advantages can be seen.
These are presented in greater detail at the end of the paper.

The discussion thus far has considered only a single recipient.
In practice, a user might wish to send to several others,
using a different key for each.
Hence each copy of the message is encrypted differently,
depending on the particular recipient in question.
Note that this has the effect of {\it un-bundling} message transfer in the
\MTS/,
as advanced \MTA/s tend to keep only a single copy of the message for any
number of recipients in order to save both cpu, disk, and I/O resources.

For example,
in some existing mail systems,
if a message was sent to $n$ users on a remote system,
then the $n$ addresses would be sent from the source \MTA/ to the remote \MTA/
along with one copy of the message.
Upon delivery,
the remote \MTA/ would deliver a copy to each of the $n$ recipients,
but the virtual wire between the source \MTA/ and the recipient \MTA/ was
burdened with only one copy of the message.
But in a secure environment,
since a different key is used by the source user when communicating with each
of the $n$ recipients,
$n$ different messages will be posted with the local \MTA/,
and the advantages of recipient bundling are lost.

Along these lines however,
private discussion groups may wish to avoid this problem by establishing
access to a single ID for their use.
In this case,
a subscriber to the \KDS/ may actually have more than one ID,
one for ``personal'' use and one for each discussion group.
The appropriate ID is used when posting messages to the discussion group.
Naturally the administrative policy for deciding who is allowed to use the
\KDS/ ID of a discussion group is left to the moderator of the group.
Observant readers will note that this vastly decreases the aspect of
secure communications for the discussion group.
This method is suggested as a compromise
which permits the bundling of messages for multiple recipients
to reduce \MTS/ traffic.
The price is high however,
as a compromise on behalf of {\it any} member of the discussion group
compromises the entire group.
For large discussion groups and a bandwidth limited \MTS/,
this price may be worth paying.
The prototype implementation of the \TMA/ supports multiple recipients but