5 Design of the TTI Prototype
21 The design of the TTI prototype Trusted Mail Agent (TMA)
23 is discussed. This agent interfaces between two entities: a key
25 distribution center (KDC) and a user agent (UA). The KDC
27 manages keys for the encryption of text messages, which two
29 subscribers to a key distribution service (KDS) may exchange.
31 The TMA is independent of any underlying message transport
36 Subscribers to the KDC are known by unique identifiers,
38 known as IDs. In addition to distributing keys, the KDC also
40 offers a simple directory lookup service, in which the "real-
42 world" name of a subscriber may be mapped to an ID, or the
44 inverse mapping may be performed.
47 This document details three software components: first_, a
49 prototype key distribution service, which has been running
51 in a TCP/IP environment since December, 1984; second____, a
53 prototype trusted mail agent; and, third___, modifications to an
55 existing UA, the Rand MH Message Handling system, which
57 permit interaction with the prototype TMA.
61 ________________________________________
62 y All three authors are with Trusted Technologies, Incorporated, POB 45, Glenwood, MD 21738,
64 USA. Telephone: 301/854-6889. In addition, Professor Farber is with the University of Delaware.
67 Design of the TTI Prototype
75 Initially, a brief model of a user community employing a trusted mail service
77 is introduced. Following this introduction, a prototype system is described which
79 attempts to meet the needs of a user community. Finally, open issues are discussed,
81 which are currently not satisfied by the prototype system or its model of operation.
84 Two or more entities, called users, wish to communicate in a secure
86 environment. Depending on their available resources, different levels of security
88 are possible. At the extreme, two parties with substantial resources may wish to
90 communicate in a fashion which prevents any third parties, known as adversaries,
92 from observing their communication. At this level, not only is an adversary
94 unable to capture the communication for analysis, but in fact, the adversary is
96 unaware that any communication is occurring at all. In most applications, this
98 level of security is prohibitively expensive. A more economic method is to translate
100 messages into a form which is useless to an adversary and then to communicate
102 those messages on an insecure medium.
105 This latter method requires the two users to have some sort of key with which
107 to "lock" the plaintext into ciphertext when transmitting, and then to "unlock"
109 the ciphertext back into useful form when receiving. Hence, there are two central
111 issues to deal with: first_, keys must be generated, distributed, and maintained in
113 a secure fashion; and, second____, the keys must be "intricate" enough so that sense
115 can't be made out of the ciphertext without knowledge of the key. The first part
117 is handled by a key distribution center (KDC), which maintains a list of users
119 and a set of keys for each pair of users. The second part relies on sophisticated
121 encryption and decryption algorithms. It is beyond the scope of this paper to
123 describe cryptographic techniques in detail. For a detailed survey of this area, the
125 reader should consult [VVoyd83].
128 In the context of our discussion (using the terminology of [X.400]), the
130 medium used to transport is supplied by a message transport system (MTS), which
132 is composed of one or more message transport agents (MTAs). Usually, the entire
134 MTS is distributed in nature, and not under a single administrative entity; in
136 contrast, an MTA is usually controlled by a single administration and resides in a
138 particular domain. At every end-point in the medium, a user agent (UA) acts on
140 behalf of a user and interfaces to a local MTA. This model is briefly summarized in
146 Copyright fcl1985, IFIP TC-6 1
147 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 2
148 ______________________________________________________________________________________________________________________
164 MTA MTA : : : : : : MTA
172 _______________________________________________The_MTS_Model__________________________________________________________
176 A message, in our context, consists of two parts: the headers and the body.
178 The headers are rigorously structured; they contain addressing information and
180 other forms useful to a UA. The body is freely formatted and is usually not
185 When a message is sent from one user to another, the following activities
187 occur: The originating user indicates to the UA the address of the recipient; the
189 UA then posts the message through a posting slot to an MTA, which involves
191 a posting protocol in which the validity of the address and the syntax of the
193 message are considered. Upon successful completion of the protocol, the MTA
195 accepts responsibility for delivering the message, or if delivery fails, to inform the
197 originating user of the failure. The MTA then decides if it can deliver the message
199 directly to the recipient; if so, it delivers the message through a delivery slot to
201 the recipient's UA, using a delivery protocol. If not, it contacts an adjacent MTA,
203 closer to the recipient, and negotiates its transfer (using a protocol similar to the
205 posting protocol). This process repeats until an MTA is able to deliver the message,
207 or an MTA determines that the message can't be delivered. In this latter case, a
209 failure notice is sent to the originating user.
212 It is important to note that there are two mappings which occur here. The
214 first, which is performed implicitly by the originating user, maps the name of the
216 recipient into the recipient's address; the second, which is performed explicitly by
218 the MTS, maps the address of the recipient into a route to get from the originator's
220 MTA to the recipient's MTA. These mappings are depicted in Figure 2.
223 Obviously, there is no guarantee that the MTS can be made secure, in any
225 sense of the word. This is particularly true if it is under several administrations.
227 Regardless of the number of administrations in the MTS, this problem quickly
228 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 3
229 ______________________________________________________________________________________________________________________
250 MTA MTA : : : : : : MTA
256 ______________________________________Mappings_in_the_MTS_model_______________________________________________________
260 degenerates to a problem of Byzantine generals[LLamp82]. Further, trying to secure
262 each MTA in the path that a message travels is equally questionable.
265 To support secure communications in this environment, a new entity, the
267 trusted mail agent (TMA) is introduced into our model. A solution is to have the
269 UA interact with this entity both when posting a message and when taking delivery
271 of a message. The UA first contacts a TMA to encrypt the body of the message for
273 the recipient, prior to pushing it through the posting slot. Upon receipt from the
275 destination MTA, the UA examines the message and contacts the TMA to decipher
277 the body of the message from the source. An overview of the relationship between
279 the standard MTS model and the augmentations made for the Trusted Mail1 system
281 is shown in Figure 3.
284 To achieve these tasks, the TMA interacts with a key distribution service
286 (KDS), which manages keys between pairwise users. At this point, a third mapping
288 takes place: the UA must be able to map addresses into the identifier(s) by which
290 the originator and recipient are known by the TMA and KDS. These identifiers
292 are known as KDS IDs, or simply IDs. Usually, a fourth mapping also occurs,
294 ________________________________________
295 1 Trusted Mail is a trademark of Trusted Technologies, Incorporated.
296 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 4
297 ______________________________________________________________________________________________________________________
309 MTA MTA : : : : : : MTA
315 ____________________________________Modifications_to_the_MTS_model____________________________________________________
319 which maps the ID of a user into the name of a user. In our context, there is an
321 exact one-to-one mapping between the name of a user and the ID of that user. In
323 contrast, there may be a one-to-many mapping between the name of a user and
325 that user's address in the MTS. Further, there are usually many different routes
327 which a message may traverse when going from an originating user to a recipient
332 The TMA is said to be trusted because it can be relied on to perform only
334 those actions specifically requested by the user. In the context of this paper,
336 this means, given proper construction and maintenance of the TMA, that the
338 software will communicate with the KDC in some secure fashion to negotiate key
340 relationships and that it will not disclose those key relationships to other parties.
342 Furthermore, the body of mail messages exchanged between users which employ a
344 trusted mail agent will be unintelligible to other parties. Finally, a recipient of a
346 message receives authenticated information from the trusted mail agent as to the
348 identify of the sender.
351 Hence, when each user employs a TMA, end-to-end encryption occurs at the
353 UA level (to avoid any problems with malicious MTAs).2 Any adversary listening
355 in on the MTS, may observe messages, but make no sense out of them (other than
357 rudimentary traffic analysis). Note, however, that since the medium itself is not
359 secure, an adversary may still introduce new messages, corrupt messages, or remove
362 ________________________________________
363 2 Note that in the scope of this system, the end-points are the user agents, not the hosts they reside
365 on. In fact, it may very well be the case that the user agent and the local message transport agent
366 do not reside on the same host.
367 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 5
370 messages, as they traverse the MTS. In the first two cases, however, the recipient
372 would be suspicious because the adversary lacks the encrypting key employed by
374 the source user. In the third case, the source user can retransmit the message after
376 a suitable time. Of course, there is no built-in retransmission policy _ this aspect
378 depends on the user's sending mail and is beyond the scope of the system.
381 It is important to understand the target community for the Trusted Mail
383 system described herein. In particular, the TMA is intended for a commercial
385 and not a military environment. This distinction is important, since it is the
387 fundamental assumption of this paper that the latter community has much stricter
389 requirements than the former. Because of this, the prototype system is able to
391 make certain simplifying assumptions which permit it to operate in a mode which
393 is less secure than military applications would permit. Although these issues are
395 explored in greater detail at the end of the paper, for the moment recall that, like
397 most qualities, trustedness is not absolute: there are varying degrees of trustedness,
399 and as a system becomes more trusted, it becomes more expensive, in some sense,
401 to operate and maintain.
404 It is perhaps instructive at this point to consider why the introduction of a key
406 distribution center is appropriate in this environment, and why the fundamental
408 assumption that trusted mail agents do not directly communicate with each other
410 is necessary. Although a user agent is able to converse with the local message
412 transport agent in real-time, it is frequently not able to communicate with other
414 user agents in real-time. Furthermore, considering the vast problems and overhead
416 of trying to establish secure communications from "scratch" (a problem far beyond
418 the scope of this paper), it is would not be a good idea to try and communicate
420 key relationships with other user agents, even if it were always possible to do so.
422 In addition, by separating the trusted aspects of the message transport system
424 from the system itself, many other advantages can be seen. These are presented in
426 greater detail at the end of the paper.
429 The discussion thus far has considered only a single recipient. In practice, a
431 user might wish to send to several others, using a different key for each. Hence each
433 copy of the message is encrypted differently, depending on the particular recipient
435 in question. Note that this has the effect of un-bundling message transfer in the
437 MTS, as advanced MTAs tend to keep only a single copy of the message for any
439 number of recipients in order to save both cpu, disk, and I/O resources.
442 For example, in some existing mail systems, if a message was sent to n users
444 on a remote system, then the n addresses would be sent from the source MTA to
446 the remote MTA along with one copy of the message. Upon delivery, the remote
448 MTA would deliver a copy to each of the n recipients, but the virtual wire between
450 the source MTA and the recipient MTA was burdened with only one copy of the
452 message. But in a secure environment, since a different key is used by the source
453 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 6
456 user when communicating with each of the n recipients, n different messages will
458 be posted with the local MTA, and the advantages of recipient bundling are lost.
461 Along these lines however, private discussion groups may wish to avoid
463 this problem by establishing access to a single ID for their use. In this case, a
465 subscriber to the KDS may actually have more than one ID, one for "personal"
467 use and one for each discussion group. The appropriate ID is used when posting
469 messages to the discussion group. Naturally the administrative policy for deciding
471 who is allowed to use the KDS ID of a discussion group is left to the moderator
473 of the group. Observant readers will note that this vastly decreases the aspect
475 of secure communications for the discussion group. This method is suggested
477 as a compromise which permits the bundling of messages for multiple recipients
479 to reduce MTS traffic. The price is high however, as a compromise on behalf
481 of any member of the discussion group compromises the entire group. For large
483 discussion groups and a bandwidth limited MTS, this price may be worth paying.
485 The prototype implementation of the TMA supports multiple recipients but not
490 Having described this environment for communication, the designs of a KDS
492 and TMA which form the heart of the TTI Trusted Mail system are discussed.
494 The prototype system was developed on a VAX3 -11/780 running 4.2bsd UNIX4 .
496 The system is based on the ansi draft[FIKM] for financial key management, but
498 diverges somewhat in operation owing to the differences between the electronic mail
500 (CBMS) and electronic funds (EFT) environments. Note however that the ansi
502 data encryption algorithm[DEA, FIPS46] is used in the current implementation. A
504 public-key cipher system was not considered as the basis for the prototype since,
506 to the authors' knowledge, an open standard for a public-key system has yet to be
508 adopted by the commercial community. In contrast, the ansi draft for financial key
510 management appears to be receiving wide support from the commercial community.
513 In the description that follows, a large number of acronyms are employed to
515 denote commonly used terms. In order to aid the reader, these are summarized in
521 The Key Distribution Service
523 The prototype version of the KDS was designed to provide key distribution
525 services for user agents under both the same or different administrations. As a
527 result, the means by which a trusted mail agent connects to a key distribution
529 server is quite flexible. For example, the prototype system supports connections
531 via standard terminal lines, dial-ups (e.g., over a toll-free 800 number), UNIX pipes,
533 and over TCP sockets[IP, TCP]. In the interests of simplicity, for the remainder
535 of this paper, a TCP/IP model of communication is used. Initially, a server on a
537 ________________________________________
538 3 VAX is a trademark of Digital Equipment Corporation.
539 4 UNIX is a trademark of AT&T Bell Laboratories.
540 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 7
541 ______________________________________________________________________________________________________________________
542 ______________________________________________________________________________________________
544 __Abbrev.________________________________Term_____________________________Context_______________
546 _ CBC _ Cipher Block Chaining _ DES _
547 _ CBMS _ Computer Based Message System _ _
548 _ CKD _ Key Distribution Center _ EFT _
549 _ CKS _ Checksumming _ DES _
550 _ CSM _ Cryptographic Service Message _ _
551 _ DEA _ Data Encryption Algorithm _ _
552 _ DES _ Data Encryption Standard _ _
553 _ DSM _ Disconnect Service Message _ MCL _
554 _ ECB _ Electronic Code Book _ DES _
555 _ EFT _ Electronic Funds Transfer _ _
556 _ IDK _ Key Identifier _ CSM _
557 _ ID _ Identifier _ KDS _
558 _ IP _ Internet Protocol _ _
559 _ IV _ Initialization Vector _ CSM _
560 _ KA _ Authentication Key _ CSM _
561 _ KDC _ Key Distribution Center _ CBMS _
562 _ KDS _ Key Distribution Server _ CBMS _
563 _ KD _ Data-encrypting Key _ CSM _
564 _ KK _ Key-encrypting Key _ CSM _
565 _ MAC _ Message Authentication Code _ CSM _
566 _ MCL _ Message Class _ CSM _
567 _ MH _ The Rand Message Handling System _ _
568 _ MIC _ Message Integrity Code _ CSM _
569 _ MK _ Master Key _ CSM _
570 _ MTA _ Message Transport Agent _ CBMS _
571 _ MTS _ Message Transport System _ CBMS _
572 _ ORG _ Message Originator _ CSM _
573 _ RCV _ Message Receiver _ CSM _
574 _ RIU _ Request Identified User _ MCL _
575 _ RSI _ Request Service Initialization _ MCL _
576 _ RUI _ Request User Identification _ MCL _
577 _ TCP _ Transmission Control Protocol _ _
578 _ TMA _ Trusted Mail Agent _ CBMS _
579 _ TTI _ Trusted Technologies, Inc. _ _
580 ______UA___________User_Agent_______________________________________________CBMS____________
585 ____________________________________Abbreviations_used_in_this_paper__________________________________________________
589 well-known service host in the ARPA Internet community listens for connections
591 on a well-known port.5 As each connection is established, it services one or more
593 transactions over the lifetime of the session. When all transactions for a session
595 have been made, the connection is closed. If the necessary locking operations are
597 performed by the server to avoid the usual database problems, then more than one
599 connection may be in progress simultaneously. Of course, a time-out facility should
601 ________________________________________
602 5 The term well known in this context means that the location of the service is known a priori to
605 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 8
608 also be employed to prevent a rogue agent from monopolizing the key distribution
613 Once a session has been started, the client (a.k.a. TMA) initiates transactions
615 with the server (a.k.a. KDS). Each transaction consists of the exchange of two
617 or three cryptographic service messages (CSMs): the client sends a request,
619 the server attempts to honor the request and sends a response, and, if the
621 server responded positively, the client then acknowledges the transaction. By
623 exchanging these cryptographic service messages, the KDS and the TMA are able
625 to communicate key relationships. Obviously, the relationships themselves must
627 be transmitted in encrypted form.6 Hence, not only are key relationships between
629 two TMAs communicated, but key relationships between the KDS and the TMA
631 are communicated as well.
634 This leads us to consider the key relationships that exist between a TMA and
636 the KDS. A client usually has three keys dedicated for use with the server. The
638 first is the master key (denoted MK), which has an infinite cryptoperiod, and is
640 rarely used. This key is distributed manually. The second is the key-encrypting key
642 (denoted KK), which has a shorter cryptoperiod. Whenever a KK is transmitted
644 to the TMA, it is encrypted with the master key. The third is the authentication
646 key (denoted KA), which is used to authenticate transactions that do not contain
648 data keys (a count field is also used to avoid play-back attacks). Whenever a
650 KA is transmitted to the TMA, it is encrypted with the key-encrypting key.
652 When transactions contain keys, an associated count field is included to indicate
654 the number of keys encrypted with the key-encrypting key used. Although not
656 used by the prototype implementation, a production system would employ audit
658 mechanisms to monitor usage histories.
661 Currently four types of requests are honored by the KDS: two key relationship
663 primitives, and two name service primitives. The type is indicated by the message
665 class (MCL) of the first cryptographic service message sent in the transaction.
667 As each message class is discussed, the appropriate datastructures used by the
669 KDS are introduced. Space considerations prevent a detailed description of the
671 information exchanged in each transaction. Appendix B of this paper presents a
673 short example of an interaction between the KDS and a TMA.
676 The first two requests are used to create (or retrieve) key relationships, and
678 to destroy key relationships:
681 The request service initialization (RSI) message class is used to establish
683 a key-encrypting key (KK) relationship between the TMA and another TMA, or
685 between the TMA and the KDS. As implied by the name, a key-encrypting key is
689 ________________________________________
690 6 Otherwise an adversary could simply impersonate a TMA and ask for the desired key relationships.
692 Similarly, this also prevents an adversary from successfully impersonating a key distribution server.
693 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 9
696 used to cipher keys which are used to cipher data exchanged between peers. These
698 other keys are called data keys (KDs).
701 The disconnect service message (DSM) message class is used to discontinue
703 a KK-relationship between the TMA and another TMA, or between the TMA and
705 the KDS. This prevents keys which are felt to have been compromised, or are
707 vulnerable to compromise, from receiving further use in the system. It should
709 be noted that, owing to mail messages (not CSMs) in transit, a discontinued key
711 relationship may be needed to decipher the key used to encipher a mail message.
713 The prototype KDS supports this capability.
716 In addition to maintaining an MK/KK/KA triple for each TMA, the KDS
718 also remembers KK-relationships between TMAs. The reason for this stems from a
720 fundamental difference between the electronic funds transfer and computer-based
722 message system worlds. The KDS assumes that no two arbitrarily chosen TMAs can
724 communicate in real-time, and as a result, TMAs do not exchange cryptographic
726 service messages. (See Appendix C for a more detailed discussion.) This means
728 that when a TMA establishes a KK-relationship with another TMA, the former
730 TMA may start using the KK before the latter TMA knows of the new KK-
732 relationship. In fact, it is quite possible for a KK-relationship to be established,
734 used, and then discontinued, all unilaterally on the part of one TMA. It is up to
736 the KDS to retain old cryptographic material (possibly for an indefinite period
738 of time), and aid the latter TMA in reconstructing KK-relationships as the need
740 arises. Naturally, discontinued KKs are not used to encode any new information,
742 but rather to decode old information. (Again, refer to Appendix C for additional
747 The other two requests are used to query the directory service aspects of the
749 key distribution server:
752 The request user identification (RUI) message class is used to identify a
754 subscriber to the KDS. Both the KDS and TMA are independent of any underlying
756 mail transport system (MTS). As a result, a subscriber to the KDS is known
758 by two unique attributes: a "real-world" name, and a KDS identifier (ID). The
760 user of a mail system, or the UA, is responsible for mapping an MTS-specific
762 address (e.g., MRose@UDEL.ARPA) to the person associated with that maildrop (e.g.,
764 ``Marshall T. Rose'' ). When conversing with the KDS, the TMA uses the KDS
766 ID of another user to reference that person's TMA. Since it is inconvenient to
768 remember the IDs (as opposed to people's names), the KDS provides the RUI
770 message class to permit a TMA to query the mapping between names and IDs.
772 If the KDS cannot return an exact match, it may respond with a list of possible
774 matches (if the identifying information given was ambiguous), or it may respond
776 with a response that there is no matching user.
777 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 10
780 Finally, the request identified user (RIU) message class performs the inverse
782 operation: given a KDS ID, a "real-world" name is returned. This request is useful
784 for disambiguating unsuccessful RUI requests and in boot-strapping a TMA.
787 The KDS maintains two directories: a private directory and a public directory.
789 The private directory contains all information on all clients to the KDS. The public
791 directory is a subset of this, and is used by the KDS when processing RUI and
793 RIU requests.7 As a result, certain clients of the KDS may have unlisted IDs and
799 The Trusted Mail Agent
801 The prototype version of the TMA was designed to interface directly to the
803 user agent in order to maximize transparency to the user. In present form, the
805 TMA is available as a load-time library under 4.2bsd UNIX, although efforts are
807 currently underway to transport the TMA to a PC-based environment.
810 The software modules which compose the TMA contain a rich set of interfaces
812 to the KDS. In addition, the TMA manages a local database, so responses from the
814 KDS may be cached and used at a later time. In all cases, the KDS is consulted
816 only if the information is not present in the TMA database, or if the information
818 in question has expired (e.g., KK-relationships). This caching activity minimizes
820 connections to the KDS. Although connections are relatively cheap in the ARPA
822 Internet, substantial savings are achieved for PCs which contact the KDS over a
824 public phone network (dial-up) connection.
827 The TMA performs mappings between pairs of the following objects: user
829 names, KDS IDs, and MTS addresses. The TMA considers all trusted mail agents,
831 including itself, as a user name, KDS ID, and one or more MTS addresses. Although
833 the TMA does not interpret addresses itself, in order to simplify mail handling,
835 the TMA remembers the relationship between these objects so the user enters this
837 information only once.
840 Initially, when a TMA is booted, the user supplies it with the master key and
842 the user's KDS ID. Both of these quantities are assigned by the personnel at the
844 key distribution center, and subsequently transmitted to the user via an alternate,
846 bonded service.8 The TMA connects with the KDS and verifies its identity. From
848 this point on, the TMA manages its KK-relationships between the KDS and other
850 TMAs without user intervention.
853 The current implementation of the TMA assumes a "general memo framework"
855 in the context of the Standards for ARPA Internet Text Messages[DCroc82]:
859 ________________________________________
860 7 In the prototype implementation, the two directories are, for the moment, identical.
861 8 In this fashion, the problems of boot-strapping over an unsecure medium are avoided.
862 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 11
865 1. A message consists of two parts: the headers and the body. A blank line
867 separates the headers from the body.
870 2. Each (virtual) line in the headers consists of a keyword/value pair,
872 in which the keyword is separated from the value by a colon (:).
874 The headers are rigorously structured in the sense that they contain
876 addressing and other information useful to a user agent.
879 3. The body is freely formatted and must not be meaningful to a user
881 agent. However, as will be seen momentarily, the body of encrypted
883 messages must have an initial fixed format which the TMA enforces.
886 This format is widely called "822" after the number assigned to the defining
891 To support the cipher activities described below, the TMA contains internal
893 routines to perform the following DES functions: electronic code book (ECB)
895 for key encryption, cipher block chaining (CBC) for mail message encryption,
897 checksumming (CKS) for mail message and CSM authentication. Readers interested
899 in these different modes of operation for the DES should consult [FIPS81].
904 To encipher a message, the method used is a straightforward adaptation
906 of the standard encrypting/authentication techniques (though the terminology is
908 tedious). Consider the following notation:
911 ax (s): the checksum of the string s using the key x (DEA checksumming
916 ax+y (s): the checksum of the string s using the exclusive-or of the two keys x
921 ex (y): the encryption of the key y using the key x (DEA electronic code book
926 ex;y (s): the encryption of the string s using the key x and initialization vector
928 y (DEA cipher block chaining encryption)
931 h: the headers of the message
937 b: the body of the message
941 ________________________________________
942 9 Although an 822-style framework is employed by the TMA prototype, the 822 ``Encrypted:''
944 header is not currently present in encrypted messages. This is due to a design decision which
945 assumes that nothing in the headers of a message is sacred to the transport system, and that
946 "helpful" munging might occur at any time. In the real world, such helpfulness is often a problem.
947 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 12
950 For each message to be encrypted, a data key, initialization vector, authentication
952 key (KD/IV/KA) triple is generated by a random process. (It goes without saying
954 that the integrity of the system depends on the process being random). Then, for
956 each user to receive a copy of the encrypted message, the following actions are
961 First, the headers of the message are output in the clear. Then, a banner
963 string, i, is constructed and placed at the beginning of the body of the message:
966 ENCRYPTED MESSAGE: TTI TMA
969 which identifies the message as being encrypted by the TTI TMA. Following
971 the banner string is a structure, m, which takes on the syntax and most of the
973 semantics of a cryptographic service message:
995 After this, the encrypted body is output, ekd;iv (b). In short, the entire output
999 h + i + m + ekd;iv (b):
1003 The purpose of the structure m is many-fold. The MCL field indicates the
1005 structure m's type; currently only the type MAIL is generated and understood.
1007 The RCV and ORG fields identify the intended recipient of the message and the
1009 originator. The IDK field identifies the key-encrypting key, KK, used to encrypt
1011 the next two fields. The first KD field has the encrypted authentication key, KA,
1013 used to calculate the MIC of the plaintext of the body of the message. After
1015 the body of the message is deciphered, aka (b) is calculated and compared to the
1017 value of the MIC field. Hence, the MIC field authenticates the message body. The
1019 second KD field has the encrypted data encrypting key, KD, which along with the
1021 encrypted initialization vector in the IV field was used to generate the ciphertext
1023 of the body. Finally, the MAC field authenticates the m structure itself. The use
1025 of a data key, initialization vector, authentication key (KD/IV/KA) triple permits
1027 us to perform key distribution in a hierarchical fashion and allows the system to
1029 use a KK-relationship over a longer cryptoperiod without fear of compromise.
1030 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 13
1033 The TMA provides three primary interfaces to a UA to send encrypted mail:
1035 the first takes a file-descriptor to a message and returns a structure g (called a
1037 group) describing the ciphertext version of the body (this structure contains a KD,
1039 IV, and KA generated at random, along with a file-descriptor to the plaintext
1041 headers, a file-descriptor to the ciphertext body, and the checksum of the plaintext
1043 body); the second takes a user entry (or MTS address) and g, and returns a
1045 file-descriptor to the encrypted message for that user (or MTS address); the third
1047 takes g and performs clean-up operations. The chief advantage to this scheme of
1049 encryption is that if the message is to be sent to more than one recipient, then the
1051 MIC and the encrypted body need only be calculated once, since the KD, IV, and
1053 KA remain constant (only the KK's change with each recipient, hence for each
1055 copy of the encrypted message, only the structure m need be re-calculated).
1058 There are, however, a few subtleties involved: first_, the MTS usually accepts
1060 only 7-bit characters, so the encrypted text is exploded to consist of only printable
1062 characters;10 second____, since the MTS may impose limits on the length of a line,
1064 each line of output is limited to 64 characters; and, third___, since the body may
1066 require trailing padding, during encryption one last unit of 8 bytes is written
1068 (and encrypted), naming the number of characters (presently, nulls) padded in the
1070 previous 8 bytes (0 : : :7).
1075 To decipher a message, the method is also straightforward: The headers are
1077 output in the clear. The banner string is essentially ignored, and the structure m
1079 is consulted to identify the correct key-encrypting key. The TMA checks to see if
1081 it knows of that KK. If not, it asks the KDS to supply it. From that point, the
1083 KA, KD, and IV are deciphered. The m structure is then authenticated. With the
1085 correct key, the remainder of the body is deciphered, and all except for the last
1087 16 bytes are output. The last 8 bytes indicate how many of the previous 8 bytes
1089 should be output. So, the appropriate number of bytes is output, and the plaintext
1091 body is authenticated and compared to the MIC. Needless to say, as the body is
1093 deciphered, it is imploded back to 8-bit characters and lines are restored to their
1095 previous lengths. To indicate that the message was correctly deciphered, a new
1100 X-KDS-ID: orgid (originator's name)
1103 is appended to the headers of the message. Note that this provides an authentication
1105 mechanism. Note, further, that the UA did not have to know the identity of the
1107 sender of the message.
1111 ________________________________________
1112 10 As a rule, in all CSMs, when encrypted information is transmitted, it is exploded after encryption
1114 by the sender, and imploded prior to decryption by the receiver.
1115 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 14
1120 MH is a public domain UA for UNIX, which is widely used in dealing with
1122 both a large number of electronic mail application and a large number of messages.
1124 Although this document does not intend to describe MH, parts of the system are
1126 described as they relate to the TMA. Readers interested in MH should consult
1128 either the user's manual[MRose85a] for a detailed description, or [MRose85d] for a
1130 higher-level description.
1133 To modify MH in order to make use of a TMA, three programs were changed
1135 (with a high degree of transparency to the user), and two new programs were
1140 In MH, when a user wishes to send a composed draft (which may be an
1142 entirely new message, a re-distribution of a message, a forwarding of messages, or
1144 a reply to a message), the user invokes the send program. This program performs
1146 some minor front-end work for a program called post which actually interacts with
1148 the MTS. A new option to the send and post programs, the `-encrypt' switch, is
1150 introduced. If the user indicates
1156 then post encrypts the messages it sends.
1159 When sending an encrypted message, post first checks that each addressee
1161 has a mapping to a KDS ID during address verification. Then, instead of batching
1163 all addresses for a message in a single posting transaction, for each addressee, post
1165 consults the TMA for the appropriately encrypted text and posts that instead.
1167 (Appendix A discusses the reasons for this more fully.) Hence, assuming the user
1169 has established mappings between MTS addresses and KDS IDs, the TMA does
1171 all the work necessary to encrypt the message, including contacting the KDS as
1176 In MH, when a user is notified that new mail has arrived, the inc program is
1178 run. As each message is incorporated into the user's message handling area, a scan
1180 (one-line) listing of the message is generated.
1183 By default, the inc program upon detecting one or more encrypted messages,
1185 after the scanning process, asks the TMA to decipher the message, and if successful,
1187 scans the deciphered messages. This action can be inhibited with the `-nodecrypt'
1189 switch. Hence, if the user wishes to retain messages in encrypted form, inc can
1191 be told to note the presence of encrypted messages, but otherwise not to process
1193 them. By using the MH user profile mechanism, inc can be easily customized to
1195 ________________________________________
1196 11 Once the TMA establishes a connection to the KDS, it retains that connection until the UA
1198 terminates. This is done to minimize connections to the KDS. In the context of MH, since the
1199 trusted mail agent is active over the lifetime of an invocation of a program such as post, this means
1200 that the connection is terminated just before the program terminates.
1201 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 15
1204 reflect the user's tastes. Again, the actions of the TMA are transparent to the user.
1206 In fact, if encrypted mail is received from users unknown to the TMA, it queries
1208 the KDS as to their identity prior to retrieving the KK-relationship.
1211 If inc fails to decrypt a message for some reason, or if inc was told not to
1213 decrypt a message, the decipher program can be used. This simple program merely
1215 deciphers each message given in its argument list. The decipher program can be
1217 given the `-insitu' switch, which directs it to replace the ciphertext version of
1219 the message with the plaintext version; or, the `-noinsitu' switch can be used
1221 indicating that the ciphertext version of the message should be left untouched and
1223 the plaintext version should be listed on the standard output.
1226 Finally, the tma program is used to manipulate the TMA database, containing
1228 commands to boot the database, add new users to the database, and to establish
1230 mappings between addresses and users in the TMA database. This program can
1232 also be used to disconnect KKs between other TMAs, and the KK/KA between
1237 Appendix A of this paper contains a transcript of an MH session.
1243 We now consider the merit of the system described. After presenting some
1245 of the basic strengths of the system and a few unresolved questions, the discussion
1247 centers on the simplifying assumptions made by the system, and how these can be
1249 defended in a non-military environment.
1254 It can be argued that the prototype system (and the augmented model in
1256 which it finds its basis) present many strengths.
1259 Perhaps the most important is the high-level of independence from the MTS
1261 enjoyed by the system. As a result, since the TMA does not interact directly
1263 with the MTS, it can be made to be completely free from any MTS-specific
1265 attributes, such as naming, addressing, and routing conventions. Furthermore,
1267 when interfacing a Trusted Mail system, no modifications need be made to the MTS
1272 In addition to the systems-level advantage to this scheme, users of the system
1274 profit as well, since many disjoint MTSs can be employed by a user with a single
1276 TMA. This reduces the number of weaknesses in the system and allows a user to
1278 keep a single database of "trusted" correspondents. It should also make analysis
1280 and verification of the TMA easier.
1283 Of course from the user-viewpoint, once the TMA has been initially booted,
1285 all key management is automatic. Not only does this reduce the risk of compromise
1286 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 16
1289 of cryptographic material (given proper construction and maintenance of the
1291 TMA), but it relieves the user of a tedious and error-prone task.
1294 Finally, although the KDS described herein is used to support Trusted Mail,
1296 other applications which require key management, could employ the services offered
1298 by the key distribution center.
1303 At present, there are many restrictions on the prototype implementation
1305 described. Some of these result from that fact that the implementation is a
1307 prototype and not a production system. Others deal with more fundamental
1312 In terms of the TMA, the expiration delay for keys is hard-wired in; it should
1314 be user-settable. In the prototype version, the KK and KA with the KDS are good
1316 for 2 days or 10 uses (whichever comes first), while a KK for use with another
1318 TMA is good for 1 day or 5 uses. In actual practice, keys with long cryptoperiods
1320 might be good for 6 months or 100 uses, while keys with short cryptoperiods might
1322 be good for 1 month or 25 uses. The choice of actual values is an open question
1324 beyond the scope of prototype system.12 In many respects, this issue is a classic
1326 trade-off: with relatively small cryptoperiods, an adversary has less chance of
1328 breaking a key, but with longer cryptoperiods less connections have to be made to
1330 the key distribution server.
1333 A fundamental issue, owing to differences between the EFT and CBMS
1335 environments, is that the KDS implements only a subset of the ansi draft and the
1337 semantics of certain operations have changed somewhat. It would be nice to unify
1339 the CBMS and EFT views of a key distribution center (in the former environment,
1341 the center is called a KDC, while in the latter environment, the center is known
1343 as a CKD). Appendix C of this paper discusses the differences between the two
1345 perspectives in greater detail.
1348 At present, the relationship between errors in the TMA and the posting
1350 process is an open question. For example, if an address doesn't have a mapping in
1352 the TMA database, post treats this as an address verification error. This prevents
1354 the draft from being posted. The philosophy of the UA is unclear at this point,
1356 with respect to how recovery should occur. A second area, also in question, deals
1358 with the way in which plaintext and ciphertext versions of a message are present
1360 in a system. Clearly, it is a bad idea to make both versions available, but since
1362 the TMA doesn't try to concern itself with first party observation, there seems to
1364 be little possibility of preventing this behavior. The best that can be done, at this
1366 stage, is simply to choose a consistent policy that user's should attempt to adhere
1370 ________________________________________
1371 12 The current values were chosen by guess work. Although not necessarily technically sound, the
1373 small numbers were very good for debugging purposes.
1374 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 17
1377 to. The software can help somewhat in implementing this policy, but it certainly
1379 can't circumvent the user.
1382 The prototype is built on the assumption that a single key distribution server
1384 is present. Since the ansi draft[FIKM] makes provisions for key translation centers,
1386 the Trusted Mail prototype should perhaps be made to operate in a more diverse
1388 environment. Until the issues become clearer, this remains open.
1391 Finally, for distribution lists, a large number of people would need to share
1393 the same KDS ID. The current implementation doesn't support this. Each TMA
1395 database is for a particular ID. A user with multiple IDs would need multiple
1397 databases, or the database should be re-organized.
1402 As pointed out earlier, this prototype system situates itself in a commercial,
1404 not military, environment. With respect to this decision, several aspects of
1406 the system are now discussed, which we feel are acceptable in a commercial
1408 environment, but which would be considered weaknesses in a military environment:
1413 The prototype TMA makes no attempt whatsoever to prevent or confuse
1415 traffic analysis by augmenting traffic flow.
1418 2. The Database of KDS Subscribers
1420 Since information returned by the request user identification (RUI) and
1422 request identified user (RIU) MCLs are returned in the clear, this allows
1424 an adversary to ascertain subscribers to the KDS, and perhaps deduce
1426 some information about the system. Without knowledge of the master key
1428 however, an adversary could not impersonate a subscriber though. Still, in
1430 the military sense, this is a weakness. However, all this assumes that the
1432 database maintained by the KDS accurately reflects the real-world.
1435 3. Multiple Recipients
1437 It is possible, though not proven to the authors' knowledge, that the scheme
1439 used to avoid encrypting the body of a message more than once for multiple
1441 recipients might permit one of the recipients who is also an adversary to
1443 compromise the key relationship between the sender and another recipient.
1446 The scenario goes like this: When a message is being prepared for encryption,
1448 a single KD/IV/KA triple is generated to encrypt the body. Since the sender
1450 has a different key relationship with each recipient, each message sent is
1452 different, since the structure m depends not only on the KD/IV/KA triple
1454 but also on the key relation between the sender and a particular recipient.
1456 Now suppose that one of the recipients, r1 , in addition to receiving the copy
1458 of the message meant for him/her also intercepts a copy of the message
1460 destined for another recipient, r2 . At this point, the recipient r1 has both
1461 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 18
1464 the plaintext and ciphertext version of the body, the plaintext version of the
1466 KD/IV/KA triple, and the ciphertext version of the KD/IV/KA triple that
1468 was generated using the key relationship between the sender and the recipient
1470 r2 . The question is: can r1 now deduce the key relationship between the
1475 If so, then the way that the TMA attempts to minimize the use of encryption
1477 resources is a weakness. But, even if this is possible, given relatively short
1479 cryptoperiods for key relationships between TMA peers, this becomes a
1484 4. Discussion Groups
1486 As discussed earlier, the proposed method of associating a single KDS ID with
1488 the membership of a discussion group does introduce a significant weakness
1490 for the security of messages sent to the discussion group. Since the TMA
1492 does not assume a general broadcast facility, it appears that there are no
1494 good solutions to the problem of discussion group traffic. Of course, it is easy
1496 enough to simply send to each member of the group.
1499 For the sake of argument, let's assume that the discussion group has n
1501 members. Now, since a different key relationship would exist between the
1503 sender and each of the n recipients, the structure m would be different for
1505 each recipient and so a different message would have to be sent to each
1507 recipient. To make matters worse, if one rejects the way the TMA handles
1509 multiple recipients, not only does the MTS get burdened with n different
1511 messages, but the sender's TMA gets burdened by having to encrypt the body
1513 of the message n times. For meaningful values of n (say on the order of 500,
1515 or even 25), the amount of resources required for any trusted discussion group
1517 are simply too costly.
1520 Compromises, Compromises
1522 Each of the possible weaknesses discussed above represent a compromise
1524 between the expense of the system and the level of security it can provide.
1527 The first two areas, if addressed by the TMA, could result in much less
1529 background information being available to an adversary. In an application where it
1531 is important that an adversary not know who is talking to whom, or who can talk
1533 at all, this is very important. It is the authors' position that in the commercial
1535 environment, this issue is not paramount. By ignoring the issue of traffic flow, the
1537 TMA has a lot less work to do and the MTS is kept clear of "useless" messages.
1539 By keeping the information returned by the RUI and RIU MCLs in the clear, the
1541 complexity of the TMA is significantly reduced.
1544 The second two areas, if addressed by the TMA, could result in a lesser
1546 probability of traffic being deciphered by an adversary. Regardless of the
1548 application, this is always extremely important. However, the authors' feel
1549 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 19
1552 that the compromise made by the TMA in these two issues is not substantial,
1554 and does not result in an explicit weakness when a message is sent to multiple
1556 recipients (note that when there is only a single recipient of a message, these two
1558 policies can not introduce weaknesses). In return, efficient use can be made of
1560 both the MTS and the TMA when messages are being sent to multiple recipients.
1562 Given scarce resources or large numbers of recipients, this approach may prove to
1567 Of course, much work remains to be done to prove the success of the TMA in
1569 all four of these areas.
1575 The prototype implementation described herein utilizes a public domain
1577 implementation of the DES algorithm[DEA] which was originally implemented by
1579 James J. Gillogly in May, 1977 (who at that time was with the Rand Corporation,
1581 and is now affiliated with Gillogly Software). Interfaces to Dr. Gillogly's
1583 implementation were subsequently coded by Richard W. Outerbridge in September,
1585 1984 (who at that time was with the Computer Systems Research Institute at the
1587 University of Toronto, and is now affiliated with Perle Systems, Incorporated).
1590 The authors would like to acknowledge Dennis Branstad, Elaine Barker,
1592 and David Balensen of the National Bureau of Standards for their comments
1594 on the prototype system and insights on the ANSI draft[FIKM]. In particular,
1596 Dr. Branstad originally suggested the method used for encrypting a single message
1598 for multiple recipients under different keys.
1601 The authors (and all those who have read this paper) would like to thank Willis
1603 H. Ware of the Rand Corporation, and Jonathon B. Postel of the USC/Information
1605 Sciences Institute. Their extensive comments resulted in a much more readable
1607 paper. In addition, the authors would like to thank Dr. Stephen P. Smith and
1609 Major Douglas A. Brothers for their insightful comments.
1610 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 20
1617 [DCroc82] D.H. Crocker. Standard for the Format of ARPA Internet Text
1619 Messages. Request for Comments 822. ARPA Internet Network
1621 Information Center (NIC), SRI International (August, 1982).
1625 [DEA] Data Encryption Algorithm, X3.92-1981, American National
1627 Standards Institute, 1981.
1631 [FIKM] Financial Institution Key Management, X9.17-198_ (draft), American
1633 National Standards Institute, 198_.
1637 [FIPS46] Data Encryption Standard, Federal Information Processing Standards,
1639 Publication 46, 1977.
1643 [FIPS81] DES Modes of Operation, Federal Information Processing Standards,
1645 Publication 81, 1980.
1649 [IP] Internet Protocol. Request for Comments 791 (milstd 1777).
1651 Appearing in Internet Protocol Transition Workbook, ARPA Internet
1653 Network Information Center (NIC), SRI International, 1981.
1657 [LLamp82] L. Lamport, R. Shostak, M. Pease. The Byzantine Generals Problem.
1659 ACM Transactions on Programming Languages and Systems 4 (July,
1665 [MRose85a] M.T. Rose, J.L. Romine. The Rand MH Message Handling System:
1667 User's Manual. UCI Version. Department of Information and Computer
1669 Science, University of California, Irvine (January, 1985).
1673 [MRose85d] M.T. Rose, E.A. Stefferud, J.N. Sweet. MH: A Multifarious User
1675 Agent. Computer Networks (to appear).
1679 [TCP] Transmission Control Protocol. Request for Comments 793 (milstd
1681 1778). Appearing in Internet Protocol Transition Workbook, ARPA
1683 Internet Network Information Center (NIC), SRI International, 1981.
1687 [VVoyd83] V.L. Voydock, S.T. Kent. Security Mechanisms in High-Level
1689 Network Protocols. Computing Surveys 15, 2 (June, 1983), 135-171.
1693 [X.400] Message Handling Systems: System Model-Service Elements,
1695 Recommendation X.400, International Telegraph and Telephone
1697 Consultative Committee (CCITT).
1698 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 21
1699 ______________________________________________________________________________________________________________________
1701 1 % tma -add -user "UCI Portal" uci@udel-dewey
1708 8 Subject: test message
1713 13 What now? send -encrypt
1714 14 -- Address Verification --
1715 15 -- Local Recipients --
1717 17 -- Address Verification Successful --
1718 18 -- Posting for All Recipients --
1719 19 -- Local Recipients --
1721 21 -- Recipient Copies Posted --
1722 22 -- Filing Folder Copies --
1723 23 Fcc outbox: folder ok
1724 24 -- Folder Copies Filed --
1725 25 Message Processed
1730 __________________________________________Sending_Encrypted_Mail______________________________________________________
1734 Appendix A: An MH Session
1736 In the following, the user ``Marshall T. Rose'' logged onto host
1738 ``udel-dewey'' , wishes to send a message to a user known as the ``UCI Portal''
1740 (a system maintenance account). As shown in Figure 4, line 1, the user first estab-
1742 lishes a mapping between the name ``UCI Portal'' and the address uci@udel-
1744 dewey. Once this mapping is performed, it remains in effect until the user indicates
1746 otherwise to the TMA. When the tma program is invoked, it consults the TMA
1748 database to see if that user is known. If not, it contacts the KDS to ask for the
1750 KDS ID associated with the user. If the response is successful (in this case, the
1752 KDS ID is ``3'' ), then the TMA updates its database. The tma program indicates
1754 in its output the KDS ID associated with the user, along with all known addresses
1756 (in this case, only one). So, once the name to address mapping has been described
1758 the user, the user agent, MH, deals only with the address, while the trusted mail
1760 agent deals with the name and KDS ID aspects of the user.
1763 Next, the comp program is invoked to compose a new draft on line 5. The
1765 user addresses the local user ``uci'' in the To: field, and indicates that a plaintext
1767 copy should be kept in the folder ``+outbox'' . After entering the subject and
1769 text of the draft, the user enters What now? level on line 13. At this point, the
1770 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 22
1771 ______________________________________________________________________________________________________________________
1774 2 Incorporating new mail into inbox...
1776 4 1+E02/28 0227-EST mrose test message <<ENCRYPTED MESSAGE: TTI
1778 6 Incorporating encrypted mail into inbox...
1780 8 1+ 02/28 0227-EST mrose test message <<mumble, mumble. >>
1785 ________________________________________Receiving_Encrypted_Mail______________________________________________________
1789 user directs MH to send the draft in encrypted form. The resulting output is
1791 verbose (a default for send for this user) but instructive. Initially, all addresses in
1793 the draft are verified on lines 14 to 17. Two forms of verification occur: first, the
1795 MTS is asked to verify the address as much as possible. For local addresses, the
1797 MTS decides if the name has a maildrop associated with it. For remote addresses,
1799 the MTS decides if the host is known to it. The second type of verification occurs
1801 with the TMA. For all addresses, the TMA is asked if it can find a mapping from
1803 the address to a KDS ID.
1806 The reason MH goes to all this trouble is a philosophical issue. Since the
1808 copy of the encrypted draft is different for each recipient, post tries to verify that
1810 all recipients can be successfully posted prior to actually posting the different
1812 ciphertext versions of the draft. This behavior is not optimal in terms of cycles,
1814 but is perhaps "correct" from a UA perspective.
1817 Finally, the draft is actually posted, and the folder carbon-copy is filed.
1820 Some time later, the UCI portal is informed that new mail has arrived. As
1822 shown in Figure 5, the inc program is run. The ``E'' prior to the date of the
1824 message indicates that inc has detected the message to be encrypted. Since the
1826 user did not inhibit inc from deciphering the message, it proceeds to do so.
1829 Finally, it may be instructive to see what the encrypted message looked
1831 like when it was delivered to the portal's maildrop, and the final message after
1833 deciphering. Figures 6 and 7 show these respectively. In particular, note that the
1835 ``X-KDS-ID:'' field has been introduced in Figure 7 after successfully deciphering
1837 the message. The presence of this field authenticates the sender of the message.
1838 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 23
1839 ______________________________________________________________________________________________________________________
1841 Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a022713
1844 Subject: test message
1845 Date: 28 Feb 85 02:27:16 EST (Thu)
1846 Message-ID: <4057.478423636@udel-dewey>
1847 From: mrose@udel-dewey
1850 ENCRYPTED MESSAGE: TTI TMA
1858 IV/Ef9d283565431b103
1862 a13774f652d844762c4fc03c2f4e201b9d2f57eadb00546c
1867 ______________________________________Message_Prior_to_Decryption_____________________________________________________
1869 ______________________________________________________________________________________________________________________
1870 Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a022713
1873 Subject: test message
1874 Date: 28 Feb 85 02:27:16 EST (Thu)
1875 Message-ID: <4057.478423636@udel-dewey>
1876 From: mrose@udel-dewey
1877 X-KDS-ID: 17 (Marshall T. Rose)
1885 ________________________________________Message_After_Decryption______________________________________________________
1889 Appendix B: A Short Exchange
1891 The simple nature of the interchange between the user and MH in Appendix A
1893 completely hides any interactions between the TMA and the KDS. Let us briefly
1895 examine an exchange that might occur after the destination TMA receives the
1897 message shown in Figure 6.
1900 To begin, the TMA must ascertain what it knows about the sender of the
1902 message, which claims to have a KDS ID of 17. That is, the TMA must first
1904 consider what key relationships it has with the sender. For the sake of argument,
1905 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 24
1906 ______________________________________________________________________________________________________________________
1920 13 ---> USR/"Marshall T. Rose"
1922 15 ---> MAC/2ebde134
1923 16 ---> EDC/96b183de
1930 23 <--- EDC/59a8ddcc
1936 __________________________________________Ascertaining_the_Sender_____________________________________________________
1940 suppose that this purported subscriber is unknown to the TMA. In this case, the
1942 first step it must undertake is to ascertain the validity of this subscriber.
1945 As shown in Figure 8 on lines 1-7, the TMA does this by establishing a
1947 connection to the KDS and issuing an request identified user (RUI) MCL.13 If
1949 the response by the KDS is positive, the TMA will use the information returned
1951 when generating the ``X-KDS-ID:'' field for authentication. The response CSM
1953 returned by the KDS includes an authentication checksum (the MAC field on
1955 line 15) and a transaction count (the CTA field on line 12) to prevent spoofing by a
1957 process pretending to be the KDS. The TMA then acknowledges that the response
1959 from the server was acceptable on lines 18-24.
1962 The next step is to ascertain the actual key relationship used to encrypt the
1964 structure m, which appears after the identifying string. The TMA consults the
1967 ________________________________________
1968 13 In point of fact, the very first thing that the TMA does after connecting to the KDS is verify
1970 that the key relationships between the KDS and the TMA are valid (have not expired). If the
1971 key relationship between the two has expired, the TMA issues a request service initialization RSI
1972 MCL to establish a new key relationship. This relationship contains a key-encrypting key (KK) and
1973 an authentication key (KA). Once a valid key relationship exists between the KDS and the TMA,
1974 transactions concerning other key relationships may take place.
1975 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 25
1976 ______________________________________________________________________________________________________________________
1982 5 <--- IDK/850228072730
1991 14 ---> KK/095f9d6b87f57871
1993 16 ---> KD/527fbb5593efd318
1994 17 ---> KD/1dcab338be1e7a09
1995 18 ---> IV/E02db5e598b2823ae
1996 19 ---> EDK/850618075332
1998 21 ---> MAC/12cbbdf5
1999 22 ---> EDC/8cd0c4a8
2006 29 <--- EDC/59a8ddcc
2012 __________________________________Ascertaining_the_Key_Relationship___________________________________________________
2016 IDK field in m, and if this relationship is unknown to it, then the KDS is asked to
2018 disclose the key relationship.
2021 As shown in Figure 9 on lines 1-9, This is done by issuing a request service
2023 initialization (RSI) MCL and specifying the particular key relationship of interest.
2025 The KDS consults its database, and if the exact key relationship between the
2027 two indicated TMAs can be ascertained, it returns this information. The key
2029 relationship is encrypted using the key relationship between the KDS and the
2031 TMA, and the usual count and authentication fields are included.
2034 Once the TMA knows the key relationship used to encrypt the structure m,
2036 it can decider the structure and ascertain the KD/IV/KA triple used to encrypt
2038 the body of the message.
2039 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 26
2042 Appendix C: Differences between the ANSI and TTI drafts
2044 The differences between the ansi draft standard for financial institution key
2046 management, and the TTI draft's specification for trusted mail handling, are
2051 The concept of a key distribution center (CKD in the ansi draft, KDC in the
2053 TTI draft) environment differs. In the ansi draft, only one party talks to the key
2055 distribution server (KDS); in the TTI draft, both parties talk to the KDS. This
2057 leads to a number of differences in the two protocols. The reason for this shift
2059 in the TTI draft is somewhat subtle: although both parties can talk to the KDS,
2061 the mail transfer system (MTS) environment is such that both user agents (UAs)
2063 are unable to contact each other in real-time. Hence, a detailed two-way protocol
2065 between them is prohibitively expensive.14
2068 Before discussing the differences between the two drafts, let us consider the
2070 differences in the two environments: in the electronic mail environment, the two
2072 end-to-end peers need not be simultaneously online. Electronic mail relies on a
2074 communication service with potentially large delays in transit between message
2076 transfer agents (MTAs). A basic concept of "mail" is that an originator must release
2078 the enveloped message to a "transfer agent" before delivery can be attempted to a
2080 recipient. In contrast, in the electronic funds environment, the two peers make use
2082 of a virtual-circuit service. This means that they can synchronize much easier and
2084 inter-operate in a more direct fashion.
2087 Service protocols are based on the notion of requests and responses. A client
2089 issues a request to a server, the server processes the request and returns a response.
2091 Depending on the complexity of the protocol, the client may now respond to the
2093 server's message, or might issue a new request, or might terminate the connection.
2096 As delays in the network increase, along with the possibility of loss or
2098 corruption or re-ordering of messages, it becomes more difficult to implement a
2100 service protocol. In the case of a high-level protocol making use of a virtual-
2102 circuit service, most problems can be ignored, as the virtual-circuit service masks
2104 out problems in the network by using sequences, positive (and/or negative)
2106 acknowledgments, windows, and so on.
2109 Sadly, electronic mail cannot utilize a virtual-circuit throughout the MTS
2111 (although individual MTA-wise connections are (in theory) virtual-circuit based).
2113 This means that implementing a real-time or interactive service protocol between
2115 two endpoints (a.k.a. UAs) in the MTS is very difficult. As a result, the complexity
2117 of an end-to-end protocol in the MTS (in terms of requests and responses) is
2119 severely constrained. For all practical purposes, an MTA can assume datagram
2121 service and nothing else: messages might be re-ordered; messages might not reach
2123 ________________________________________
2124 14 In the words of Einar A. Stefferud: "Every interesting connection has at least two end-points _
2126 connections with only one end-point are always uninteresting."
2127 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 27
2130 their destination; messages might be corrupted (though this is unlikely); in cases
2132 of failure, a notice might be generated, or might not.
2135 In terms of the environment in which cryptographic service messages (CSMs)
2137 must flow, the high degree of delay and uncertainty make the implementation of a
2139 complex end-to-end protocol between UAs prohibitively expensive. Hence, a KDC
2141 is needed, to which each UA can connect using a virtual-circuit service, at posting
2143 and delivery time. The TTI draft terms such a user agent a trusted mail agent
2145 (TMA). Since both TMAs can connect to the KDS at different times using different
2147 media, the KDS maintains state information about the key relationships between
2149 different TMAs and manages those relationships appropriately. Since connections
2151 to the KDS can be expensive in terms of resources, each TMA caches information
2153 received from the KDS appropriately.
2156 That's the gist of the argument as to why the TTI draft differs from the ansi
2158 draft. It might be possible to include CSMs in the messages which UAs exchange,
2160 but management of these CSMs can not be done reliably or in a straightforward
2162 fashion owing to the datagram nature of the service offered by the MTS. Finally, it
2164 should be noted that in the TTI draft, the KDS never initiates a connection with
2166 a TMA, rather it is the TMAs which connect to the KDS.
2169 In the following, the differences between the two drafts are highlighted. Minor
2171 differences between the two are not discussed.
2174 In the ansi draft, x 4:2 (p. 22) discusses the requirements for the automated
2176 key management architecture. The TTI draft has somewhat more "depth", since
2178 the ansi draft does not make use of a master key (MK) to fully automate the
2180 distribution of key-encrypting keys (KK).
2183 The ansi draft states that once a KK-relationship is discontinued by either
2185 of that pair, the relation is not to be re-used for any subsequent activity. This
2187 can't be guaranteed in the prototype implementation. If one of the TMAs wishes
2189 to discontinue a key, not only does it have to inform the KDS, but the other TMA
2191 as well. Since the TTI draft does not permit CSMs between TMA-peers, the latter
2193 action doesn't seem possible. However, there is a solution. Whenever a message is
2195 deciphered, the TMA checks the effective date of the key used to encrypt a message
2197 it has received, and if the key is newer than the one it currently uses, it considers
2199 the older key to be discontinued.
2202 Furthermore, although the environment in the TTI draft is that of a key
2204 distribution center, the notion of an ultimate recipient is not present, since all clients
2206 connect to the KDS at one time or another. In addition, the differences between
2208 the environs envisioned by the two drafts become even more pronounced when
2210 one considers that the KDS distributes key-encrypting keys to TMAs, although the
2212 ansi draft specifically prohibits this.
2213 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985 28
2216 Finally, there is another important technical difference between the two
2218 drafts: every request to the KDS by the TMA results in a specifically defined
2220 response from the KDS to the TMA. Furthermore, if the KDS responds in a positive
2222 manner, then the TMA acknowledges this. This three-way interaction is used to
2224 ensure consistency between the states of the KDS and the TMA. The ansi draft
2226 does not require such behavior, and might profit from some finite-state analysis to
2228 ascertain unsafe (in terms of correctness) states which are reachable.
2239 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
2242 The Key Distribution Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2244 The Trusted Mail Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2246 Encrypting Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2248 Decrypting Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2250 Modifications to MH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2252 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
2255 Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*
2258 Open Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2260 Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
2263 Compromises, Compromises. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2265 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2267 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
2270 Appendix A: An MH Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2272 Appendix B: A Short Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2274 Appendix C: Differences between the ANSI and TTI drafts . . . . . . . . . . 26
2278 ________________________________________
2279 This document (version #2.60) was TEXset April 12, 1990 with DISS.STY v103.
projects / mmh / blob