|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T t
Length: 83736 (0x14718)
Types: TextFile
Names: »trusted.tty«
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
└─⟦1c9ac1d5e⟧ »EurOpenD3/mail/mh/papers-tty.tar.Z«
└─⟦ecde7fae8⟧
└─⟦this⟧ »trusted.tty«
Design of the TTI Prototype
Trusted Mail Agent
Marshall T. Rosey
David J. Farber
Stephen T. Walker
Abstract
The design of the TTI prototype Trusted Mail Agent (TMA)
is discussed. This agent interfaces between two entities: a key
distribution center (KDC) and a user agent (UA). The KDC
manages keys for the encryption of text messages, which two
subscribers to a key distribution service (KDS) may exchange.
The TMA is independent of any underlying message transport
system.
Subscribers to the KDC are known by unique identifiers,
known as IDs. In addition to distributing keys, the KDC also
offers a simple directory lookup service, in which the "real-
world" name of a subscriber may be mapped to an ID, or the
inverse mapping may be performed.
This document details three software components: first_, a
prototype key distribution service, which has been running
in a TCP/IP environment since December, 1984; second____, a
prototype trusted mail agent; and, third___, modifications to an
existing UA, the Rand MH Message Handling system, which
permit interaction with the prototype TMA.
________________________________________
y All three authors are with Trusted Technologies, Incorporated, POB 45, Glenwood, MD 21738,
USA. Telephone: 301/854-6889. In addition, Professor Farber is with the University of Delaware.
\f
Design of the TTI Prototype
Trusted Mail Agent
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 users, wish to communicate in a 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 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 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: first_, keys must be generated, distributed, and maintained in
a secure fashion; and, 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 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 [VVoyd83].
In the context of our discussion (using the terminology of [X.400]), the
medium used to transport is supplied by a message transport system (MTS), which
is composed of one or more message transport agents (MTAs). 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 user agent (UA) acts on
behalf of a user and interfaces to a local MTA. This model is briefly summarized in
Figure 1.
Copyright fcl1985, IFIP TC-6 1
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 2
______________________________________________________________________________________________________________________
UA UA
POSTING RECEIPT
MTS
MTA MTA : : : : : : MTA
RELAYING
Figure 1
_______________________________________________The_MTS_Model__________________________________________________________
A message, in our context, consists of two parts: the headers and the 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 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 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.
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 2.
Obviously, there is no guarantee that the MTS can be made secure, in 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
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 3
______________________________________________________________________________________________________________________
user user
name ! address
UA UA
MTS
address ! route
MTA MTA : : : : : : MTA
Figure 2
______________________________________Mappings_in_the_MTS_model_______________________________________________________
degenerates to a problem of Byzantine generals[LLamp82]. Further, trying to secure
each MTA in the path that a message travels is equally questionable.
To support secure communications in this environment, a new entity, the
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 Trusted Mail1 system
is shown in Figure 3.
To achieve these tasks, the TMA interacts with a 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,
________________________________________
1 Trusted Mail is a trademark of Trusted Technologies, Incorporated.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 4
______________________________________________________________________________________________________________________
UA TMA KDS TMA UA
MTS
MTA MTA : : : : : : MTA
Figure 3
____________________________________Modifications_to_the_MTS_model____________________________________________________
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 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 MTAs).2 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
________________________________________
2 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.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 5
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 Trusted Mail
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
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 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 un-bundling message transfer in the
MTS, as advanced MTAs 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
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 6
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 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 not
multiple KDS IDs.
Having described this environment for communication, the designs of a KDS
and TMA which form the heart of the TTI Trusted Mail system are discussed.
The prototype system was developed on a VAX3 -11/780 running 4.2bsd UNIX4 .
The system is based on the ansi draft[FIKM] for financial key management, but
diverges somewhat in operation owing to the differences between the electronic mail
(CBMS) and electronic funds (EFT) environments. Note however that the ansi
data encryption algorithm[DEA, FIPS46] is used in the current implementation. A
public-key cipher system was not considered as the basis for the prototype since,
to the authors' knowledge, an open standard for a public-key system has yet to be
adopted by the commercial community. In contrast, the ansi draft for financial key
management appears to be receiving wide support from the commercial community.
In the description that follows, a large number of acronyms are employed to
denote commonly used terms. In order to aid the reader, these are summarized in
Table 1.
The Key Distribution Service
The prototype version of the KDS was designed to provide key distribution
services for user agents under both the same or different administrations. As a
result, the means by which a trusted mail agent connects to a key distribution
server is quite flexible. For example, the prototype system supports connections
via standard terminal lines, dial-ups (e.g., over a toll-free 800 number), UNIX pipes,
and over TCP sockets[IP, TCP]. In the interests of simplicity, for the remainder
of this paper, a TCP/IP model of communication is used. Initially, a server on a
________________________________________
3 VAX is a trademark of Digital Equipment Corporation.
4 UNIX is a trademark of AT&T Bell Laboratories.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 7
______________________________________________________________________________________________________________________
______________________________________________________________________________________________
__Abbrev.________________________________Term_____________________________Context_______________
_ CBC _ Cipher Block Chaining _ DES _
_ CBMS _ Computer Based Message System _ _
_ CKD _ Key Distribution Center _ EFT _
_ CKS _ Checksumming _ DES _
_ CSM _ Cryptographic Service Message _ _
_ DEA _ Data Encryption Algorithm _ _
_ DES _ Data Encryption Standard _ _
_ DSM _ Disconnect Service Message _ MCL _
_ ECB _ Electronic Code Book _ DES _
_ EFT _ Electronic Funds Transfer _ _
_ IDK _ Key Identifier _ CSM _
_ ID _ Identifier _ KDS _
_ IP _ Internet Protocol _ _
_ IV _ Initialization Vector _ CSM _
_ KA _ Authentication Key _ CSM _
_ KDC _ Key Distribution Center _ CBMS _
_ KDS _ Key Distribution Server _ CBMS _
_ KD _ Data-encrypting Key _ CSM _
_ KK _ Key-encrypting Key _ CSM _
_ MAC _ Message Authentication Code _ CSM _
_ MCL _ Message Class _ CSM _
_ MH _ The Rand Message Handling System _ _
_ MIC _ Message Integrity Code _ CSM _
_ MK _ Master Key _ CSM _
_ MTA _ Message Transport Agent _ CBMS _
_ MTS _ Message Transport System _ CBMS _
_ ORG _ Message Originator _ CSM _
_ RCV _ Message Receiver _ CSM _
_ RIU _ Request Identified User _ MCL _
_ RSI _ Request Service Initialization _ MCL _
_ RUI _ Request User Identification _ MCL _
_ TCP _ Transmission Control Protocol _ _
_ TMA _ Trusted Mail Agent _ CBMS _
_ TTI _ Trusted Technologies, Inc. _ _
______UA___________User_Agent_______________________________________________CBMS____________
Table 1
____________________________________Abbreviations_used_in_this_paper__________________________________________________
well-known service host in the ARPA Internet community listens for connections
on a well-known port.5 As each connection is established, it services one or more
transactions over the lifetime of the session. When all transactions for a session
have been made, the connection is closed. If the necessary locking operations are
performed by the server to avoid the usual database problems, then more than one
connection may be in progress simultaneously. Of course, a time-out facility should
________________________________________
5 The term well known in this context means that the location of the service is known a priori to
the clients.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 8
also be employed to prevent a rogue agent from monopolizing the key distribution
server.
Once a session has been started, the client (a.k.a. TMA) initiates transactions
with the server (a.k.a. KDS). Each transaction consists of the exchange of two
or three cryptographic service messages (CSMs): the client sends a request,
the server attempts to honor the request and sends a response, and, if the
server responded positively, the client then acknowledges the transaction. By
exchanging these cryptographic service messages, the KDS and the TMA are able
to communicate key relationships. Obviously, the relationships themselves must
be transmitted in encrypted form.6 Hence, not only are key relationships between
two TMAs communicated, but key relationships between the KDS and the TMA
are communicated as well.
This leads us to consider the key relationships that exist between a TMA and
the KDS. A client usually has three keys dedicated for use with the server. The
first is the master key (denoted MK), which has an infinite cryptoperiod, and is
rarely used. This key is distributed manually. The second is the key-encrypting key
(denoted KK), which has a shorter cryptoperiod. Whenever a KK is transmitted
to the TMA, it is encrypted with the master key. The third is the authentication
key (denoted KA), which is used to authenticate transactions that do not contain
data keys (a count field is also used to avoid play-back attacks). Whenever a
KA is transmitted to the TMA, it is encrypted with the key-encrypting key.
When transactions contain keys, an associated count field is included to indicate
the number of keys encrypted with the key-encrypting key used. Although not
used by the prototype implementation, a production system would employ audit
mechanisms to monitor usage histories.
Currently four types of requests are honored by the KDS: two key relationship
primitives, and two name service primitives. The type is indicated by the message
class (MCL) of the first cryptographic service message sent in the transaction.
As each message class is discussed, the appropriate datastructures used by the
KDS are introduced. Space considerations prevent a detailed description of the
information exchanged in each transaction. Appendix B of this paper presents a
short example of an interaction between the KDS and a TMA.
The first two requests are used to create (or retrieve) key relationships, and
to destroy key relationships:
The request service initialization (RSI) message class is used to establish
a key-encrypting key (KK) relationship between the TMA and another TMA, or
between the TMA and the KDS. As implied by the name, a key-encrypting key is
________________________________________
6 Otherwise an adversary could simply impersonate a TMA and ask for the desired key relationships.
Similarly, this also prevents an adversary from successfully impersonating a key distribution server.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 9
used to cipher keys which are used to cipher data exchanged between peers. These
other keys are called data keys (KDs).
The disconnect service message (DSM) message class is used to discontinue
a KK-relationship between the TMA and another TMA, or between the TMA and
the KDS. This prevents keys which are felt to have been compromised, or are
vulnerable to compromise, from receiving further use in the system. It should
be noted that, owing to mail messages (not CSMs) in transit, a discontinued key
relationship may be needed to decipher the key used to encipher a mail message.
The prototype KDS supports this capability.
In addition to maintaining an MK/KK/KA triple for each TMA, the KDS
also remembers KK-relationships between TMAs. The reason for this stems from a
fundamental difference between the electronic funds transfer and computer-based
message system worlds. The KDS assumes that no two arbitrarily chosen TMAs can
communicate in real-time, and as a result, TMAs do not exchange cryptographic
service messages. (See Appendix C for a more detailed discussion.) This means
that when a TMA establishes a KK-relationship with another TMA, the former
TMA may start using the KK before the latter TMA knows of the new KK-
relationship. In fact, it is quite possible for a KK-relationship to be established,
used, and then discontinued, all unilaterally on the part of one TMA. It is up to
the KDS to retain old cryptographic material (possibly for an indefinite period
of time), and aid the latter TMA in reconstructing KK-relationships as the need
arises. Naturally, discontinued KKs are not used to encode any new information,
but rather to decode old information. (Again, refer to Appendix C for additional
details.)
The other two requests are used to query the directory service aspects of the
key distribution server:
The request user identification (RUI) message class is used to identify a
subscriber to the KDS. Both the KDS and TMA are independent of any underlying
mail transport system (MTS). As a result, a subscriber to the KDS is known
by two unique attributes: a "real-world" name, and a KDS identifier (ID). The
user of a mail system, or the UA, is responsible for mapping an MTS-specific
address (e.g., MRose@UDEL.ARPA) to the person associated with that maildrop (e.g.,
``Marshall T. Rose'' ). When conversing with the KDS, the TMA uses the KDS
ID of another user to reference that person's TMA. Since it is inconvenient to
remember the IDs (as opposed to people's names), the KDS provides the RUI
message class to permit a TMA to query the mapping between names and IDs.
If the KDS cannot return an exact match, it may respond with a list of possible
matches (if the identifying information given was ambiguous), or it may respond
with a response that there is no matching user.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 10
Finally, the request identified user (RIU) message class performs the inverse
operation: given a KDS ID, a "real-world" name is returned. This request is useful
for disambiguating unsuccessful RUI requests and in boot-strapping a TMA.
The KDS maintains two directories: a private directory and a public directory.
The private directory contains all information on all clients to the KDS. The public
directory is a subset of this, and is used by the KDS when processing RUI and
RIU requests.7 As a result, certain clients of the KDS may have unlisted IDs and
names.
The Trusted Mail Agent
The prototype version of the TMA was designed to interface directly to the
user agent in order to maximize transparency to the user. In present form, the
TMA is available as a load-time library under 4.2bsd UNIX, although efforts are
currently underway to transport the TMA to a PC-based environment.
The software modules which compose the TMA contain a rich set of interfaces
to the KDS. In addition, the TMA manages a local database, so responses from the
KDS may be cached and used at a later time. In all cases, the KDS is consulted
only if the information is not present in the TMA database, or if the information
in question has expired (e.g., KK-relationships). This caching activity minimizes
connections to the KDS. Although connections are relatively cheap in the ARPA
Internet, substantial savings are achieved for PCs which contact the KDS over a
public phone network (dial-up) connection.
The TMA performs mappings between pairs of the following objects: user
names, KDS IDs, and MTS addresses. The TMA considers all trusted mail agents,
including itself, as a user name, KDS ID, and one or more MTS addresses. Although
the TMA does not interpret addresses itself, in order to simplify mail handling,
the TMA remembers the relationship between these objects so the user enters this
information only once.
Initially, when a TMA is booted, the user supplies it with the master key and
the user's KDS ID. Both of these quantities are assigned by the personnel at the
key distribution center, and subsequently transmitted to the user via an alternate,
bonded service.8 The TMA connects with the KDS and verifies its identity. From
this point on, the TMA manages its KK-relationships between the KDS and other
TMAs without user intervention.
The current implementation of the TMA assumes a "general memo framework"
in the context of the Standards for ARPA Internet Text Messages[DCroc82]:
________________________________________
7 In the prototype implementation, the two directories are, for the moment, identical.
8 In this fashion, the problems of boot-strapping over an unsecure medium are avoided.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 11
1. A message consists of two parts: the headers and the body. A blank line
separates the headers from the body.
2. Each (virtual) line in the headers consists of a keyword/value pair,
in which the keyword is separated from the value by a colon (:).
The headers are rigorously structured in the sense that they contain
addressing and other information useful to a user agent.
3. The body is freely formatted and must not be meaningful to a user
agent. However, as will be seen momentarily, the body of encrypted
messages must have an initial fixed format which the TMA enforces.
This format is widely called "822" after the number assigned to the defining
report[DCroc82].9
To support the cipher activities described below, the TMA contains internal
routines to perform the following DES functions: electronic code book (ECB)
for key encryption, cipher block chaining (CBC) for mail message encryption,
checksumming (CKS) for mail message and CSM authentication. Readers interested
in these different modes of operation for the DES should consult [FIPS81].
Encrypting Mail
To encipher a message, the method used is a straightforward adaptation
of the standard encrypting/authentication techniques (though the terminology is
tedious). Consider the following notation:
ax (s): the checksum of the string s using the key x (DEA checksumming
authentication)
ax+y (s): the checksum of the string s using the exclusive-or of the two keys x
and y
ex (y): the encryption of the key y using the key x (DEA electronic code book
encryption)
ex;y (s): the encryption of the string s using the key x and initialization vector
y (DEA cipher block chaining encryption)
h: the headers of the message
and,
b: the body of the message
________________________________________
9 Although an 822-style framework is employed by the TMA prototype, the 822 ``Encrypted:''
header is not currently present in encrypted messages. This is due to a design decision which
assumes that nothing in the headers of a message is sacred to the transport system, and that
"helpful" munging might occur at any time. In the real world, such helpfulness is often a problem.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 12
For each message to be encrypted, a data key, initialization vector, authentication
key (KD/IV/KA) triple is generated by a random process. (It goes without saying
that the integrity of the system depends on the process being random). Then, for
each user to receive a copy of the encrypted message, the following actions are
taken:
First, the headers of the message are output in the clear. Then, a banner
string, i, is constructed and placed at the beginning of the body of the message:
ENCRYPTED MESSAGE: TTI TMA
which identifies the message as being encrypted by the TTI TMA. Following
the banner string is a structure, m, which takes on the syntax and most of the
semantics of a cryptographic service message:
MCL/ MAIL
RCV/ rcvid
ORG/ orgid
IDK/ kkid
KD/ ekk (ka)
KD/ ekk (kd)
IV/ ekd (iv)
MIC/ aka (b)
MAC/ akd+ka (m)
After this, the encrypted body is output, ekd;iv (b). In short, the entire output
consists of
h + i + m + ekd;iv (b):
The purpose of the structure m is many-fold. The MCL field indicates the
structure m's type; currently only the type MAIL is generated and understood.
The RCV and ORG fields identify the intended recipient of the message and the
originator. The IDK field identifies the key-encrypting key, KK, used to encrypt
the next two fields. The first KD field has the encrypted authentication key, KA,
used to calculate the MIC of the plaintext of the body of the message. After
the body of the message is deciphered, aka (b) is calculated and compared to the
value of the MIC field. Hence, the MIC field authenticates the message body. The
second KD field has the encrypted data encrypting key, KD, which along with the
encrypted initialization vector in the IV field was used to generate the ciphertext
of the body. Finally, the MAC field authenticates the m structure itself. The use
of a data key, initialization vector, authentication key (KD/IV/KA) triple permits
us to perform key distribution in a hierarchical fashion and allows the system to
use a KK-relationship over a longer cryptoperiod without fear of compromise.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 13
The TMA provides three primary interfaces to a UA to send encrypted mail:
the first takes a file-descriptor to a message and returns a structure g (called a
group) describing the ciphertext version of the body (this structure contains a KD,
IV, and KA generated at random, along with a file-descriptor to the plaintext
headers, a file-descriptor to the ciphertext body, and the checksum of the plaintext
body); the second takes a user entry (or MTS address) and g, and returns a
file-descriptor to the encrypted message for that user (or MTS address); the third
takes g and performs clean-up operations. The chief advantage to this scheme of
encryption is that if the message is to be sent to more than one recipient, then the
MIC and the encrypted body need only be calculated once, since the KD, IV, and
KA remain constant (only the KK's change with each recipient, hence for each
copy of the encrypted message, only the structure m need be re-calculated).
There are, however, a few subtleties involved: first_, the MTS usually accepts
only 7-bit characters, so the encrypted text is exploded to consist of only printable
characters;10 second____, since the MTS may impose limits on the length of a line,
each line of output is limited to 64 characters; and, third___, since the body may
require trailing padding, during encryption one last unit of 8 bytes is written
(and encrypted), naming the number of characters (presently, nulls) padded in the
previous 8 bytes (0 : : :7).
Decrypting Mail
To decipher a message, the method is also straightforward: The headers are
output in the clear. The banner string is essentially ignored, and the structure m
is consulted to identify the correct key-encrypting key. The TMA checks to see if
it knows of that KK. If not, it asks the KDS to supply it. From that point, the
KA, KD, and IV are deciphered. The m structure is then authenticated. With the
correct key, the remainder of the body is deciphered, and all except for the last
16 bytes are output. The last 8 bytes indicate how many of the previous 8 bytes
should be output. So, the appropriate number of bytes is output, and the plaintext
body is authenticated and compared to the MIC. Needless to say, as the body is
deciphered, it is imploded back to 8-bit characters and lines are restored to their
previous lengths. To indicate that the message was correctly deciphered, a new
header of the form
X-KDS-ID: orgid (originator's name)
is appended to the headers of the message. Note that this provides an authentication
mechanism. Note, further, that the UA did not have to know the identity of the
sender of the message.
________________________________________
10 As a rule, in all CSMs, when encrypted information is transmitted, it is exploded after encryption
by the sender, and imploded prior to decryption by the receiver.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 14
Modifications to MH
MH is a public domain UA for UNIX, which is widely used in dealing with
both a large number of electronic mail application and a large number of messages.
Although this document does not intend to describe MH, parts of the system are
described as they relate to the TMA. Readers interested in MH should consult
either the user's manual[MRose85a] for a detailed description, or [MRose85d] for a
higher-level description.
To modify MH in order to make use of a TMA, three programs were changed
(with a high degree of transparency to the user), and two new programs were
introduced.
In MH, when a user wishes to send a composed draft (which may be an
entirely new message, a re-distribution of a message, a forwarding of messages, or
a reply to a message), the user invokes the send program. This program performs
some minor front-end work for a program called post which actually interacts with
the MTS. A new option to the send and post programs, the `-encrypt' switch, is
introduced. If the user indicates
send -encrypt
then post encrypts the messages it sends.
When sending an encrypted message, post first checks that each addressee
has a mapping to a KDS ID during address verification. Then, instead of batching
all addresses for a message in a single posting transaction, for each addressee, post
consults the TMA for the appropriately encrypted text and posts that instead.
(Appendix A discusses the reasons for this more fully.) Hence, assuming the user
has established mappings between MTS addresses and KDS IDs, the TMA does
all the work necessary to encrypt the message, including contacting the KDS as
necessary.11
In MH, when a user is notified that new mail has arrived, the inc program is
run. As each message is incorporated into the user's message handling area, a scan
(one-line) listing of the message is generated.
By default, the inc program upon detecting one or more encrypted messages,
after the scanning process, asks the TMA to decipher the message, and if successful,
scans the deciphered messages. This action can be inhibited with the `-nodecrypt'
switch. Hence, if the user wishes to retain messages in encrypted form, inc can
be told to note the presence of encrypted messages, but otherwise not to process
them. By using the MH user profile mechanism, inc can be easily customized to
________________________________________
11 Once the TMA establishes a connection to the KDS, it retains that connection until the UA
terminates. This is done to minimize connections to the KDS. In the context of MH, since the
trusted mail agent is active over the lifetime of an invocation of a program such as post, this means
that the connection is terminated just before the program terminates.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 15
reflect the user's tastes. Again, the actions of the TMA are transparent to the user.
In fact, if encrypted mail is received from users unknown to the TMA, it queries
the KDS as to their identity prior to retrieving the KK-relationship.
If inc fails to decrypt a message for some reason, or if inc was told not to
decrypt a message, the decipher program can be used. This simple program merely
deciphers each message given in its argument list. The decipher program can be
given the `-insitu' switch, which directs it to replace the ciphertext version of
the message with the plaintext version; or, the `-noinsitu' switch can be used
indicating that the ciphertext version of the message should be left untouched and
the plaintext version should be listed on the standard output.
Finally, the tma program is used to manipulate the TMA database, containing
commands to boot the database, add new users to the database, and to establish
mappings between addresses and users in the TMA database. This program can
also be used to disconnect KKs between other TMAs, and the KK/KA between
itself and the KDS.
Appendix A of this paper contains a transcript of an MH session.
Remarks
We now consider the merit of the system described. After presenting some
of the basic strengths of the system and a few unresolved questions, the discussion
centers on the simplifying assumptions made by the system, and how these can be
defended in a non-military environment.
Strengths
It can be argued that the prototype system (and the augmented model in
which it finds its basis) present many strengths.
Perhaps the most important is the high-level of independence from the MTS
enjoyed by the system. As a result, since the TMA does not interact directly
with the MTS, it can be made to be completely free from any MTS-specific
attributes, such as naming, addressing, and routing conventions. Furthermore,
when interfacing a Trusted Mail system, no modifications need be made to the MTS
or local MTA.
In addition to the systems-level advantage to this scheme, users of the system
profit as well, since many disjoint MTSs can be employed by a user with a single
TMA. This reduces the number of weaknesses in the system and allows a user to
keep a single database of "trusted" correspondents. It should also make analysis
and verification of the TMA easier.
Of course from the user-viewpoint, once the TMA has been initially booted,
all key management is automatic. Not only does this reduce the risk of compromise
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 16
of cryptographic material (given proper construction and maintenance of the
TMA), but it relieves the user of a tedious and error-prone task.
Finally, although the KDS described herein is used to support Trusted Mail,
other applications which require key management, could employ the services offered
by the key distribution center.
Open Questions
At present, there are many restrictions on the prototype implementation
described. Some of these result from that fact that the implementation is a
prototype and not a production system. Others deal with more fundamental
issues.
In terms of the TMA, the expiration delay for keys is hard-wired in; it should
be user-settable. In the prototype version, the KK and KA with the KDS are good
for 2 days or 10 uses (whichever comes first), while a KK for use with another
TMA is good for 1 day or 5 uses. In actual practice, keys with long cryptoperiods
might be good for 6 months or 100 uses, while keys with short cryptoperiods might
be good for 1 month or 25 uses. The choice of actual values is an open question
beyond the scope of prototype system.12 In many respects, this issue is a classic
trade-off: with relatively small cryptoperiods, an adversary has less chance of
breaking a key, but with longer cryptoperiods less connections have to be made to
the key distribution server.
A fundamental issue, owing to differences between the EFT and CBMS
environments, is that the KDS implements only a subset of the ansi draft and the
semantics of certain operations have changed somewhat. It would be nice to unify
the CBMS and EFT views of a key distribution center (in the former environment,
the center is called a KDC, while in the latter environment, the center is known
as a CKD). Appendix C of this paper discusses the differences between the two
perspectives in greater detail.
At present, the relationship between errors in the TMA and the posting
process is an open question. For example, if an address doesn't have a mapping in
the TMA database, post treats this as an address verification error. This prevents
the draft from being posted. The philosophy of the UA is unclear at this point,
with respect to how recovery should occur. A second area, also in question, deals
with the way in which plaintext and ciphertext versions of a message are present
in a system. Clearly, it is a bad idea to make both versions available, but since
the TMA doesn't try to concern itself with first party observation, there seems to
be little possibility of preventing this behavior. The best that can be done, at this
stage, is simply to choose a consistent policy that user's should attempt to adhere
________________________________________
12 The current values were chosen by guess work. Although not necessarily technically sound, the
small numbers were very good for debugging purposes.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 17
to. The software can help somewhat in implementing this policy, but it certainly
can't circumvent the user.
The prototype is built on the assumption that a single key distribution server
is present. Since the ansi draft[FIKM] makes provisions for key translation centers,
the Trusted Mail prototype should perhaps be made to operate in a more diverse
environment. Until the issues become clearer, this remains open.
Finally, for distribution lists, a large number of people would need to share
the same KDS ID. The current implementation doesn't support this. Each TMA
database is for a particular ID. A user with multiple IDs would need multiple
databases, or the database should be re-organized.
Weaknesses
As pointed out earlier, this prototype system situates itself in a commercial,
not military, environment. With respect to this decision, several aspects of
the system are now discussed, which we feel are acceptable in a commercial
environment, but which would be considered weaknesses in a military environment:
1. Traffic Flow
The prototype TMA makes no attempt whatsoever to prevent or confuse
traffic analysis by augmenting traffic flow.
2. The Database of KDS Subscribers
Since information returned by the request user identification (RUI) and
request identified user (RIU) MCLs are returned in the clear, this allows
an adversary to ascertain subscribers to the KDS, and perhaps deduce
some information about the system. Without knowledge of the master key
however, an adversary could not impersonate a subscriber though. Still, in
the military sense, this is a weakness. However, all this assumes that the
database maintained by the KDS accurately reflects the real-world.
3. Multiple Recipients
It is possible, though not proven to the authors' knowledge, that the scheme
used to avoid encrypting the body of a message more than once for multiple
recipients might permit one of the recipients who is also an adversary to
compromise the key relationship between the sender and another recipient.
The scenario goes like this: When a message is being prepared for encryption,
a single KD/IV/KA triple is generated to encrypt the body. Since the sender
has a different key relationship with each recipient, each message sent is
different, since the structure m depends not only on the KD/IV/KA triple
but also on the key relation between the sender and a particular recipient.
Now suppose that one of the recipients, r1 , in addition to receiving the copy
of the message meant for him/her also intercepts a copy of the message
destined for another recipient, r2 . At this point, the recipient r1 has both
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 18
the plaintext and ciphertext version of the body, the plaintext version of the
KD/IV/KA triple, and the ciphertext version of the KD/IV/KA triple that
was generated using the key relationship between the sender and the recipient
r2 . The question is: can r1 now deduce the key relationship between the
sender and r2 ?
If so, then the way that the TMA attempts to minimize the use of encryption
resources is a weakness. But, even if this is possible, given relatively short
cryptoperiods for key relationships between TMA peers, this becomes a
non-problem.
4. Discussion Groups
As discussed earlier, the proposed method of associating a single KDS ID with
the membership of a discussion group does introduce a significant weakness
for the security of messages sent to the discussion group. Since the TMA
does not assume a general broadcast facility, it appears that there are no
good solutions to the problem of discussion group traffic. Of course, it is easy
enough to simply send to each member of the group.
For the sake of argument, let's assume that the discussion group has n
members. Now, since a different key relationship would exist between the
sender and each of the n recipients, the structure m would be different for
each recipient and so a different message would have to be sent to each
recipient. To make matters worse, if one rejects the way the TMA handles
multiple recipients, not only does the MTS get burdened with n different
messages, but the sender's TMA gets burdened by having to encrypt the body
of the message n times. For meaningful values of n (say on the order of 500,
or even 25), the amount of resources required for any trusted discussion group
are simply too costly.
Compromises, Compromises
Each of the possible weaknesses discussed above represent a compromise
between the expense of the system and the level of security it can provide.
The first two areas, if addressed by the TMA, could result in much less
background information being available to an adversary. In an application where it
is important that an adversary not know who is talking to whom, or who can talk
at all, this is very important. It is the authors' position that in the commercial
environment, this issue is not paramount. By ignoring the issue of traffic flow, the
TMA has a lot less work to do and the MTS is kept clear of "useless" messages.
By keeping the information returned by the RUI and RIU MCLs in the clear, the
complexity of the TMA is significantly reduced.
The second two areas, if addressed by the TMA, could result in a lesser
probability of traffic being deciphered by an adversary. Regardless of the
application, this is always extremely important. However, the authors' feel
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 19
that the compromise made by the TMA in these two issues is not substantial,
and does not result in an explicit weakness when a message is sent to multiple
recipients (note that when there is only a single recipient of a message, these two
policies can not introduce weaknesses). In return, efficient use can be made of
both the MTS and the TMA when messages are being sent to multiple recipients.
Given scarce resources or large numbers of recipients, this approach may prove to
be quite winning.
Of course, much work remains to be done to prove the success of the TMA in
all four of these areas.
Acknowledgements
The prototype implementation described herein utilizes a public domain
implementation of the DES algorithm[DEA] which was originally implemented by
James J. Gillogly in May, 1977 (who at that time was with the Rand Corporation,
and is now affiliated with Gillogly Software). Interfaces to Dr. Gillogly's
implementation were subsequently coded by Richard W. Outerbridge in September,
1984 (who at that time was with the Computer Systems Research Institute at the
University of Toronto, and is now affiliated with Perle Systems, Incorporated).
The authors would like to acknowledge Dennis Branstad, Elaine Barker,
and David Balensen of the National Bureau of Standards for their comments
on the prototype system and insights on the ANSI draft[FIKM]. In particular,
Dr. Branstad originally suggested the method used for encrypting a single message
for multiple recipients under different keys.
The authors (and all those who have read this paper) would like to thank Willis
H. Ware of the Rand Corporation, and Jonathon B. Postel of the USC/Information
Sciences Institute. Their extensive comments resulted in a much more readable
paper. In addition, the authors would like to thank Dr. Stephen P. Smith and
Major Douglas A. Brothers for their insightful comments.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 20
References
[DCroc82] D.H. Crocker. Standard for the Format of ARPA Internet Text
Messages. Request for Comments 822. ARPA Internet Network
Information Center (NIC), SRI International (August, 1982).
[DEA] Data Encryption Algorithm, X3.92-1981, American National
Standards Institute, 1981.
[FIKM] Financial Institution Key Management, X9.17-198_ (draft), American
National Standards Institute, 198_.
[FIPS46] Data Encryption Standard, Federal Information Processing Standards,
Publication 46, 1977.
[FIPS81] DES Modes of Operation, Federal Information Processing Standards,
Publication 81, 1980.
[IP] Internet Protocol. Request for Comments 791 (milstd 1777).
Appearing in Internet Protocol Transition Workbook, ARPA Internet
Network Information Center (NIC), SRI International, 1981.
[LLamp82] L. Lamport, R. Shostak, M. Pease. The Byzantine Generals Problem.
ACM Transactions on Programming Languages and Systems 4 (July,
1982), 382-401.
[MRose85a] M.T. Rose, J.L. Romine. The Rand MH Message Handling System:
User's Manual. UCI Version. Department of Information and Computer
Science, University of California, Irvine (January, 1985).
[MRose85d] M.T. Rose, E.A. Stefferud, J.N. Sweet. MH: A Multifarious User
Agent. Computer Networks (to appear).
[TCP] Transmission Control Protocol. Request for Comments 793 (milstd
1778). Appearing in Internet Protocol Transition Workbook, ARPA
Internet Network Information Center (NIC), SRI International, 1981.
[VVoyd83] V.L. Voydock, S.T. Kent. Security Mechanisms in High-Level
Network Protocols. Computing Surveys 15, 2 (June, 1983), 135-171.
[X.400] Message Handling Systems: System Model-Service Elements,
Recommendation X.400, International Telegraph and Telephone
Consultative Committee (CCITT).
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 21
______________________________________________________________________________________________________________________
1 % tma -add -user "UCI Portal" uci@udel-dewey
2 3: "UCI Portal"
3 uci@udel-dewey
4
5 % comp
6 To: uci
7 Fcc: +outbox
8 Subject: test message
9 --------
10 mumble, mumble.
11 ^D
12
13 What now? send -encrypt
14 -- Address Verification --
15 -- Local Recipients --
16 uci: address ok
17 -- Address Verification Successful --
18 -- Posting for All Recipients --
19 -- Local Recipients --
20 uci: address ok
21 -- Recipient Copies Posted --
22 -- Filing Folder Copies --
23 Fcc outbox: folder ok
24 -- Folder Copies Filed --
25 Message Processed
Figure 4
__________________________________________Sending_Encrypted_Mail______________________________________________________
Appendix A: An MH Session
In the following, the user ``Marshall T. Rose'' logged onto host
``udel-dewey'' , wishes to send a message to a user known as the ``UCI Portal''
(a system maintenance account). As shown in Figure 4, line 1, the user first estab-
lishes a mapping between the name ``UCI Portal'' and the address uci@udel-
dewey. Once this mapping is performed, it remains in effect until the user indicates
otherwise to the TMA. When the tma program is invoked, it consults the TMA
database to see if that user is known. If not, it contacts the KDS to ask for the
KDS ID associated with the user. If the response is successful (in this case, the
KDS ID is ``3'' ), then the TMA updates its database. The tma program indicates
in its output the KDS ID associated with the user, along with all known addresses
(in this case, only one). So, once the name to address mapping has been described
the user, the user agent, MH, deals only with the address, while the trusted mail
agent deals with the name and KDS ID aspects of the user.
Next, the comp program is invoked to compose a new draft on line 5. The
user addresses the local user ``uci'' in the To: field, and indicates that a plaintext
copy should be kept in the folder ``+outbox'' . After entering the subject and
text of the draft, the user enters What now? level on line 13. At this point, the
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 22
______________________________________________________________________________________________________________________
1 % inc
2 Incorporating new mail into inbox...
3
4 1+E02/28 0227-EST mrose test message <<ENCRYPTED MESSAGE: TTI
5
6 Incorporating encrypted mail into inbox...
7
8 1+ 02/28 0227-EST mrose test message <<mumble, mumble. >>
Figure 5
________________________________________Receiving_Encrypted_Mail______________________________________________________
user directs MH to send the draft in encrypted form. The resulting output is
verbose (a default for send for this user) but instructive. Initially, all addresses in
the draft are verified on lines 14 to 17. Two forms of verification occur: first, the
MTS is asked to verify the address as much as possible. For local addresses, the
MTS decides if the name has a maildrop associated with it. For remote addresses,
the MTS decides if the host is known to it. The second type of verification occurs
with the TMA. For all addresses, the TMA is asked if it can find a mapping from
the address to a KDS ID.
The reason MH goes to all this trouble is a philosophical issue. Since the
copy of the encrypted draft is different for each recipient, post tries to verify that
all recipients can be successfully posted prior to actually posting the different
ciphertext versions of the draft. This behavior is not optimal in terms of cycles,
but is perhaps "correct" from a UA perspective.
Finally, the draft is actually posted, and the folder carbon-copy is filed.
Some time later, the UCI portal is informed that new mail has arrived. As
shown in Figure 5, the inc program is run. The ``E'' prior to the date of the
message indicates that inc has detected the message to be encrypted. Since the
user did not inhibit inc from deciphering the message, it proceeds to do so.
Finally, it may be instructive to see what the encrypted message looked
like when it was delivered to the portal's maildrop, and the final message after
deciphering. Figures 6 and 7 show these respectively. In particular, note that the
``X-KDS-ID:'' field has been introduced in Figure 7 after successfully deciphering
the message. The presence of this field authenticates the sender of the message.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 23
______________________________________________________________________________________________________________________
Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a022713
;28 Feb 85 2:27 EST
To: uci@udel-dewey
Subject: test message
Date: 28 Feb 85 02:27:16 EST (Thu)
Message-ID: <4057.478423636@udel-dewey>
From: mrose@udel-dewey
ENCRYPTED MESSAGE: TTI TMA
(
MCL/MAIL
RCV/3
ORG/17
IDK/850228072730
KD/e36813a3882eebd1
KD/fa8b8ac657476669
IV/Ef9d283565431b103
MIC/fdb927fb
MAC/50e9de30
)
a13774f652d844762c4fc03c2f4e201b9d2f57eadb00546c
Figure 6
______________________________________Message_Prior_to_Decryption_____________________________________________________
______________________________________________________________________________________________________________________
Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a022713
;28 Feb 85 2:27 EST
To: uci@udel-dewey
Subject: test message
Date: 28 Feb 85 02:27:16 EST (Thu)
Message-ID: <4057.478423636@udel-dewey>
From: mrose@udel-dewey
X-KDS-ID: 17 (Marshall T. Rose)
mumble, mumble.
Figure 7
________________________________________Message_After_Decryption______________________________________________________
Appendix B: A Short Exchange
The simple nature of the interchange between the user and MH in Appendix A
completely hides any interactions between the TMA and the KDS. Let us briefly
examine an exchange that might occur after the destination TMA receives the
message shown in Figure 6.
To begin, the TMA must ascertain what it knows about the sender of the
message, which claims to have a KDS ID of 17. That is, the TMA must first
consider what key relationships it has with the sender. For the sake of argument,
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 24
______________________________________________________________________________________________________________________
1 <--- (
2 <--- MCL/RIU
3 <--- RCV/17
4 <--- ORG/3
5 <--- KDC/TTI
6 <--- EDC/1a1fbbba
7 <--- )
8 ---> (
9 ---> MCL/RTR
10 ---> RCV/17
11 ---> ORG/3
12 ---> CTA/1
13 ---> USR/"Marshall T. Rose"
14 ---> KDC/TTI
15 ---> MAC/2ebde134
16 ---> EDC/96b183de
17 ---> )
18 <--- (
19 <--- MCL/ACK
20 <--- RCV/17
21 <--- ORG/3
22 <--- KDC/TTI
23 <--- EDC/59a8ddcc
24 <--- )
Figure 8
__________________________________________Ascertaining_the_Sender_____________________________________________________
suppose that this purported subscriber is unknown to the TMA. In this case, the
first step it must undertake is to ascertain the validity of this subscriber.
As shown in Figure 8 on lines 1-7, the TMA does this by establishing a
connection to the KDS and issuing an request identified user (RUI) MCL.13 If
the response by the KDS is positive, the TMA will use the information returned
when generating the ``X-KDS-ID:'' field for authentication. The response CSM
returned by the KDS includes an authentication checksum (the MAC field on
line 15) and a transaction count (the CTA field on line 12) to prevent spoofing by a
process pretending to be the KDS. The TMA then acknowledges that the response
from the server was acceptable on lines 18-24.
The next step is to ascertain the actual key relationship used to encrypt the
structure m, which appears after the identifying string. The TMA consults the
________________________________________
13 In point of fact, the very first thing that the TMA does after connecting to the KDS is verify
that the key relationships between the KDS and the TMA are valid (have not expired). If the
key relationship between the two has expired, the TMA issues a request service initialization RSI
MCL to establish a new key relationship. This relationship contains a key-encrypting key (KK) and
an authentication key (KA). Once a valid key relationship exists between the KDS and the TMA,
transactions concerning other key relationships may take place.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 25
______________________________________________________________________________________________________________________
1 <--- (
2 <--- MCL/RSI
3 <--- RCV/17
4 <--- ORG/3
5 <--- IDK/850228072730
6 <--- KDC/TTI
7 <--- SVR/KD.IV.KK
8 <--- EDC/83679e14
9 <--- )
10 ---> (
11 ---> MCL/RTR
12 ---> RCV/17
13 ---> ORG/3
14 ---> KK/095f9d6b87f57871
15 ---> CTA/2
16 ---> KD/527fbb5593efd318
17 ---> KD/1dcab338be1e7a09
18 ---> IV/E02db5e598b2823ae
19 ---> EDK/850618075332
20 ---> KDC/TTI
21 ---> MAC/12cbbdf5
22 ---> EDC/8cd0c4a8
23 ---> )
24 <--- (
25 <--- MCL/ACK
26 <--- RCV/17
27 <--- ORG/3
28 <--- KDC/TTI
29 <--- EDC/59a8ddcc
30 <--- )
Figure 9
__________________________________Ascertaining_the_Key_Relationship___________________________________________________
IDK field in m, and if this relationship is unknown to it, then the KDS is asked to
disclose the key relationship.
As shown in Figure 9 on lines 1-9, This is done by issuing a request service
initialization (RSI) MCL and specifying the particular key relationship of interest.
The KDS consults its database, and if the exact key relationship between the
two indicated TMAs can be ascertained, it returns this information. The key
relationship is encrypted using the key relationship between the KDS and the
TMA, and the usual count and authentication fields are included.
Once the TMA knows the key relationship used to encrypt the structure m,
it can decider the structure and ascertain the KD/IV/KA triple used to encrypt
the body of the message.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 26
Appendix C: Differences between the ANSI and TTI drafts
The differences between the ansi draft standard for financial institution key
management, and the TTI draft's specification for trusted mail handling, are
considered.
The concept of a key distribution center (CKD in the ansi draft, KDC in the
TTI draft) environment differs. In the ansi draft, only one party talks to the key
distribution server (KDS); in the TTI draft, both parties talk to the KDS. This
leads to a number of differences in the two protocols. The reason for this shift
in the TTI draft is somewhat subtle: although both parties can talk to the KDS,
the mail transfer system (MTS) environment is such that both user agents (UAs)
are unable to contact each other in real-time. Hence, a detailed two-way protocol
between them is prohibitively expensive.14
Before discussing the differences between the two drafts, let us consider the
differences in the two environments: in the electronic mail environment, the two
end-to-end peers need not be simultaneously online. Electronic mail relies on a
communication service with potentially large delays in transit between message
transfer agents (MTAs). A basic concept of "mail" is that an originator must release
the enveloped message to a "transfer agent" before delivery can be attempted to a
recipient. In contrast, in the electronic funds environment, the two peers make use
of a virtual-circuit service. This means that they can synchronize much easier and
inter-operate in a more direct fashion.
Service protocols are based on the notion of requests and responses. A client
issues a request to a server, the server processes the request and returns a response.
Depending on the complexity of the protocol, the client may now respond to the
server's message, or might issue a new request, or might terminate the connection.
As delays in the network increase, along with the possibility of loss or
corruption or re-ordering of messages, it becomes more difficult to implement a
service protocol. In the case of a high-level protocol making use of a virtual-
circuit service, most problems can be ignored, as the virtual-circuit service masks
out problems in the network by using sequences, positive (and/or negative)
acknowledgments, windows, and so on.
Sadly, electronic mail cannot utilize a virtual-circuit throughout the MTS
(although individual MTA-wise connections are (in theory) virtual-circuit based).
This means that implementing a real-time or interactive service protocol between
two endpoints (a.k.a. UAs) in the MTS is very difficult. As a result, the complexity
of an end-to-end protocol in the MTS (in terms of requests and responses) is
severely constrained. For all practical purposes, an MTA can assume datagram
service and nothing else: messages might be re-ordered; messages might not reach
________________________________________
14 In the words of Einar A. Stefferud: "Every interesting connection has at least two end-points _
connections with only one end-point are always uninteresting."
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 27
their destination; messages might be corrupted (though this is unlikely); in cases
of failure, a notice might be generated, or might not.
In terms of the environment in which cryptographic service messages (CSMs)
must flow, the high degree of delay and uncertainty make the implementation of a
complex end-to-end protocol between UAs prohibitively expensive. Hence, a KDC
is needed, to which each UA can connect using a virtual-circuit service, at posting
and delivery time. The TTI draft terms such a user agent a trusted mail agent
(TMA). Since both TMAs can connect to the KDS at different times using different
media, the KDS maintains state information about the key relationships between
different TMAs and manages those relationships appropriately. Since connections
to the KDS can be expensive in terms of resources, each TMA caches information
received from the KDS appropriately.
That's the gist of the argument as to why the TTI draft differs from the ansi
draft. It might be possible to include CSMs in the messages which UAs exchange,
but management of these CSMs can not be done reliably or in a straightforward
fashion owing to the datagram nature of the service offered by the MTS. Finally, it
should be noted that in the TTI draft, the KDS never initiates a connection with
a TMA, rather it is the TMAs which connect to the KDS.
In the following, the differences between the two drafts are highlighted. Minor
differences between the two are not discussed.
In the ansi draft, x 4:2 (p. 22) discusses the requirements for the automated
key management architecture. The TTI draft has somewhat more "depth", since
the ansi draft does not make use of a master key (MK) to fully automate the
distribution of key-encrypting keys (KK).
The ansi draft states that once a KK-relationship is discontinued by either
of that pair, the relation is not to be re-used for any subsequent activity. This
can't be guaranteed in the prototype implementation. If one of the TMAs wishes
to discontinue a key, not only does it have to inform the KDS, but the other TMA
as well. Since the TTI draft does not permit CSMs between TMA-peers, the latter
action doesn't seem possible. However, there is a solution. Whenever a message is
deciphered, the TMA checks the effective date of the key used to encrypt a message
it has received, and if the key is newer than the one it currently uses, it considers
the older key to be discontinued.
Furthermore, although the environment in the TTI draft is that of a key
distribution center, the notion of an ultimate recipient is not present, since all clients
connect to the KDS at one time or another. In addition, the differences between
the environs envisioned by the two drafts become even more pronounced when
one considers that the KDS distributes key-encrypting keys to TMAs, although the
ansi draft specifically prohibits this.
\f
Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 28
Finally, there is another important technical difference between the two
drafts: every request to the KDS by the TMA results in a specifically defined
response from the KDS to the TMA. Furthermore, if the KDS responds in a positive
manner, then the TMA acknowledges this. This three-way interaction is used to
ensure consistency between the states of the KDS and the TMA. The ansi draft
does not require such behavior, and might profit from some finite-state analysis to
ascertain unsafe (in terms of correctness) states which are reachable.
\f
Contents
Page
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
*. 1
The Key Distribution Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
The Trusted Mail Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Encrypting Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Decrypting Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Modifications to MH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
* . 15
Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*
* 15
Open Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
* 17
Compromises, Compromises. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
* . 20
Appendix A: An MH Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B: A Short Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix C: Differences between the ANSI and TTI drafts . . . . . . . . . . 26
________________________________________
This document (version #2.60) was TEXset April 12, 1990 with DISS.STY v103.
i