Return to text.tex CVS log

Up to [CSRG BSD Unix] / 43BSD / contrib / mh / papers / trusted

Annotation of 43BSD/contrib/mh/papers/trusted/text.tex, revision 1.1

1.1     ! root        1: % begin text
        !             2: 
        !             3: \banner
        !             4: 
        !             5: \section{Introduction}
        !             6: Initially,
        !             7: a brief model of a user community employing a trusted mail service is
        !             8: introduced.
        !             9: Following this introduction,
        !            10: a prototype system is described which attempts to meet the needs of a user
        !            11: community.
        !            12: Finally,
        !            13: open issues are discussed,
        !            14: which are currently not satisfied by the prototype system or its model of
        !            15: operation.
        !            16: 
        !            17: Two or more entities,
        !            18: called {\it users},
        !            19: wish to communicate in a {\it secure} environment.
        !            20: Depending on their available resources,
        !            21: different levels of security are possible.
        !            22: At the extreme,
        !            23: two parties with substantial resources may wish to communicate in a fashion
        !            24: which prevents any third parties,
        !            25: known as {\it adversaries},
        !            26: from observing their communication.
        !            27: At this level,
        !            28: not only is an adversary unable to capture the communication for analysis,
        !            29: but in fact, the adversary is unaware that any communication is occurring at
        !            30: all.
        !            31: In most applications,
        !            32: this level of security is prohibitively expensive.
        !            33: A more economic method is to translate messages into a form which is useless
        !            34: to an adversary and then to communicate those messages on an insecure medium.
        !            35: 
        !            36: This latter method requires the two users to have some sort of {\it key}
        !            37: with which to ``lock'' the plaintext into ciphertext when transmitting,
        !            38: and then to ``unlock'' the ciphertext back into useful form when receiving.
        !            39: Hence, there are two central issues to deal with:
        !            40: \underbar{first},
        !            41: keys must be generated, distributed, and maintained in a secure fashion;
        !            42: and,
        !            43: \underbar{second},
        !            44: the keys must be ``intricate'' enough so that sense can't be made out of the
        !            45: ciphertext without knowledge of the key.
        !            46: The first part is handled by a {\it key distribution center} (\KDC/),
        !            47: which maintains a list of users and a set of keys for each pair of users.
        !            48: The second part relies on sophisticated encryption and decryption algorithms.
        !            49: It is beyond the scope of this paper to describe cryptographic techniques in
        !            50: detail.
        !            51: For a detailed survey of this area, the reader should consult \cite{VVoyd83}.
        !            52: 
        !            53: \tagfigure{1}{The \MTS/ Model}{mtsmodel}
        !            54: In the context of our discussion (using the terminology of \cite{X.400}),
        !            55: the medium used to transport is supplied
        !            56: by a {\it message transport system} (\MTS/),
        !            57: which is composed of one or more {\it message transport agents} (\MTA/s).
        !            58: Usually,
        !            59: the entire \MTS/ is distributed in nature,
        !            60: and not under a single administrative entity;
        !            61: in contrast, an \MTA/ is usually controlled by a single administration and
        !            62: resides in a particular domain.
        !            63: At every end-point in the medium,
        !            64: a {\it user agent} (\UA/) acts on behalf of a user and interfaces
        !            65: to a local \MTA/.
        !            66: This model is briefly summarized in Figure~\mtsmodel.
        !            67: 
        !            68: A message, in our context, consists of two parts:
        !            69: the {\it headers} and the {\it body}.
        !            70: The headers are rigorously structured;
        !            71: they contain addressing information and other forms useful to a \UA/.
        !            72: The body is freely formatted and is usually not meaningful to a \UA/.
        !            73: 
        !            74: When a message is sent from one user to another,
        !            75: the following activities occur:
        !            76: The originating user indicates to the \UA/ the address of the recipient;
        !            77: the \UA/ then posts the message through a {\it posting slot} to an \MTA/,
        !            78: which involves a posting protocol in which the validity of the address
        !            79: and the syntax of the message are considered.
        !            80: Upon successful completion of the protocol,
        !            81: the \MTA/ accepts responsibility for delivering the message,
        !            82: or if delivery fails, to inform the originating user of the failure.
        !            83: The \MTA/ then decides if it can deliver the message directly to the
        !            84: recipient;
        !            85: if so, it delivers the message through a {\it delivery slot} to the
        !            86: recipient's \UA/,
        !            87: using a delivery protocol.
        !            88: If not, it contacts an adjacent \MTA/, closer to the recipient,
        !            89: and negotiates its transfer (using a protocol similar to the posting protocol).
        !            90: This process repeats until an \MTA/ is able to deliver the message,
        !            91: or an \MTA/ determines that the message can't be delivered.
        !            92: In this latter case,
        !            93: a failure notice is sent to the originating user.
        !            94: 
        !            95: \tagfigure{2}{Mappings in the \MTS/ model}{mappings}
        !            96: It is important to note that there are two mappings which occur here.
        !            97: The first, which is performed implicitly by the originating user,
        !            98: maps the name of the recipient into the recipient's address;
        !            99: the second, which is performed explicitly by the \MTS/,
        !           100: maps the address of the recipient into a route to get from the originator's
        !           101: \MTA/ to the recipient's \MTA/.
        !           102: These mappings are depicted in Figure~\mappings.
        !           103: 
        !           104: Obviously, there is no guarantee that the \MTS/ can be made secure,
        !           105: in {\it any} sense of the word.
        !           106: This is particularly true if it is under several administrations.
        !           107: Regardless of the number of administrations in the \MTS/,
        !           108: this problem quickly degenerates to a problem of
        !           109: Byzantine generals\cite{LLamp82}.
        !           110: Further, trying to secure each \MTA/ in the path that a message travels is
        !           111: equally questionable.
        !           112: 
        !           113: \tagfigure{3}{Modifications to the \MTS/ model}{tmodel}
        !           114: To support secure communications in this environment,
        !           115: a new entity,
        !           116: the {\it trusted mail agent} (\TMA/) is introduced into our model.
        !           117: A solution is to have the \UA/ interact with this entity
        !           118: both when posting a message and when taking delivery of a message.
        !           119: The \UA/ first contacts a \TMA/ to encrypt the body of the message for the
        !           120: recipient,
        !           121: prior to pushing it through the posting slot.
        !           122: Upon receipt from the destination \MTA/,
        !           123: the \UA/ examines the message and contacts
        !           124: the \TMA/ to decipher the body of the message from the source.
        !           125: An overview of the relationship between the standard \MTS/ model
        !           126: and the augmentations made for the \trustedmail/ system is shown in
        !           127: Figure~\tmodel.
        !           128: 
        !           129: To achieve these tasks,
        !           130: the \TMA/ interacts with a {\it key distribution service} (\KDS/),
        !           131: which manages keys between pairwise users.
        !           132: At this point, a third mapping takes place:
        !           133: the \UA/ must be able to map addresses into the identifier(s)
        !           134: by which the originator and recipient are known by the \TMA/ and \KDS/.
        !           135: These identifiers are known as \KDS/ IDs, or simply IDs.
        !           136: Usually, a fourth mapping also occurs,
        !           137: which maps the ID of a user into the name of a user.
        !           138: In our context,
        !           139: there is an exact one-to-one mapping between the name of a user and the ID
        !           140: of that user.
        !           141: In contrast,
        !           142: there may be a one-to-many mapping between the name of a user and
        !           143: that user's address in the \MTS/.
        !           144: Further, there are usually many different routes which a message may traverse
        !           145: when going from an originating user to a recipient user.
        !           146: 
        !           147: The \TMA/ is said to be {\it trusted} because it can be relied on to perform
        !           148: only those actions specifically requested by the user.
        !           149: In the context of this paper,
        !           150: this means, given proper construction and maintenance of the \TMA/,
        !           151: that the software will communicate with the \KDC/ in some secure fashion to
        !           152: negotiate key relationships and that it will not disclose those key
        !           153: relationships to other parties.
        !           154: Furthermore,
        !           155: the body of mail messages exchanged between users which employ
        !           156: a trusted mail agent will be unintelligible to other parties.
        !           157: Finally,
        !           158: a recipient of a message receives authenticated information from the
        !           159: trusted mail agent as to the identify of the sender.
        !           160: 
        !           161: Hence,
        !           162: when each user employs a \TMA/,
        !           163: end-to-end encryption occurs at the \UA/ level
        !           164: (to avoid any problems with malicious \MTA/s).%
        !           165: \nfootnote{Note that in the scope of this system,
        !           166: the end-points are the user agents, not the hosts they reside on.
        !           167: In fact,
        !           168: it may very well be the case that the user agent and the local message
        !           169: transport agent do not reside on the same host.}
        !           170: Any adversary listening in on the \MTS/,
        !           171: may observe messages,
        !           172: but make no sense out of them
        !           173: (other than rudimentary traffic analysis).
        !           174: Note, however,
        !           175: that since the medium itself is not secure,
        !           176: an adversary may still introduce new messages,
        !           177: corrupt messages,
        !           178: or remove messages,
        !           179: as they traverse the \MTS/.
        !           180: In the first two cases, however,
        !           181: the recipient would be suspicious
        !           182: because the adversary lacks the encrypting key employed by the source user.
        !           183: In the third case,
        !           184: the source user can retransmit the message after a suitable time.
        !           185: Of course,
        !           186: there is no built-in retransmission policy~---~this aspect depends on the
        !           187: user's sending mail and is beyond the scope of the system.
        !           188: 
        !           189: It is important to understand the target community for the \trustedmail/ system
        !           190: described herein.
        !           191: In particular,
        !           192: the \TMA/ is intended for a commercial and not a military environment.
        !           193: This distinction is important,
        !           194: since it is the {\it fundamental} assumption of this paper that
        !           195: the latter community has much stricter requirements than the former.
        !           196: Because of this,
        !           197: the prototype system is able to make certain simplifying assumptions which
        !           198: permit it to operate in a mode which is less secure than military
        !           199: applications would permit.
        !           200: Although these issues are explored in greater detail at the end of the paper,
        !           201: for the moment recall that, like most qualities, trustedness is not absolute:
        !           202: there are varying degrees of trustedness,
        !           203: and as a system becomes more trusted,
        !           204: it becomes more expensive, in some sense, to operate and maintain.
        !           205: 
        !           206: It is perhaps instructive at this point to consider why the introduction of a
        !           207: key distribution center is appropriate in this environment,
        !           208: and why the {\it fundamental} assumption that trusted mail agents do not
        !           209: directly communicate with each other is necessary.
        !           210: Although a user agent is able to converse with the local message transport
        !           211: agent in real-time,
        !           212: it is frequently not able to communicate with other user agents in real-time.
        !           213: Furthermore,
        !           214: considering the vast problems and overhead
        !           215: of trying to establish secure communications from ``scratch''
        !           216: (a problem far beyond the scope of this paper),
        !           217: it is would not be a good idea to try and communicate key relationships with
        !           218: other user agents,
        !           219: even if it were always possible to do so.
        !           220: In addition,
        !           221: by separating the trusted aspects of the message transport system from the
        !           222: system itself,
        !           223: many other advantages can be seen.
        !           224: These are presented in greater detail at the end of the paper.
        !           225: 
        !           226: The discussion thus far has considered only a single recipient.
        !           227: In practice, a user might wish to send to several others,
        !           228: using a different key for each.
        !           229: Hence each copy of the message is encrypted differently,
        !           230: depending on the particular recipient in question.
        !           231: Note that this has the effect of {\it un-bundling} message transfer in the
        !           232: \MTS/,
        !           233: as advanced \MTA/s tend to keep only a single copy of the message for any
        !           234: number of recipients in order to save both cpu, disk, and I/O resources.
        !           235: 
        !           236: For example,
        !           237: in some existing mail systems,
        !           238: if a message was sent to $n$ users on a remote system,
        !           239: then the $n$ addresses would be sent from the source \MTA/ to the remote \MTA/
        !           240: along with one copy of the message.
        !           241: Upon delivery,
        !           242: the remote \MTA/ would deliver a copy to each of the $n$ recipients,
        !           243: but the virtual wire between the source \MTA/ and the recipient \MTA/ was
        !           244: burdened with only one copy of the message.
        !           245: But in a secure environment,
        !           246: since a different key is used by the source user when communicating with each
        !           247: of the $n$ recipients,
        !           248: $n$ different messages will be posted with the local \MTA/,
        !           249: and the advantages of recipient bundling are lost.
        !           250: 
        !           251: Along these lines however,
        !           252: private discussion groups may wish to avoid this problem by establishing
        !           253: access to a single ID for their use.
        !           254: In this case,
        !           255: a subscriber to the \KDS/ may actually have more than one ID,
        !           256: one for ``personal'' use and one for each discussion group.
        !           257: The appropriate ID is used when posting messages to the discussion group.
        !           258: Naturally the administrative policy for deciding who is allowed to use the
        !           259: \KDS/ ID of a discussion group is left to the moderator of the group.
        !           260: Observant readers will note that this vastly decreases the aspect of
        !           261: secure communications for the discussion group.
        !           262: This method is suggested as a compromise
        !           263: which permits the bundling of messages for multiple recipients
        !           264: to reduce \MTS/ traffic.
        !           265: The price is high however,
        !           266: as a compromise on behalf of {\it any} member of the discussion group
        !           267: compromises the entire group.
        !           268: For large discussion groups and a bandwidth limited \MTS/,
        !           269: this price may be worth paying.
        !           270: The prototype implementation of the \TMA/ supports multiple recipients but
        !           271: not multiple \KDS/ IDs.
        !           272: 
        !           273: Having described this environment for communication,
        !           274: the designs of a \KDS/ and \TMA/ which form the heart of the \TTI/
        !           275: \trustedmail/ system are discussed.
        !           276: The prototype system was developed on a \vax/-11/780 running 4.2\bsd/ \unix/.
        !           277: The system is based on the \ansi/ draft\cite{FIKM}
        !           278: for financial key management,
        !           279: but diverges somewhat in operation
        !           280: owing to the differences between the electronic mail (CBMS)
        !           281: and electronic funds (EFT) environments.
        !           282: Note however that the \ansi/ data encryption algorithm\cite{DEA,FIPS46} is
        !           283: used in the current implementation.
        !           284: A public-key cipher system was not considered as the basis for the prototype
        !           285: since, to the authors' knowledge,
        !           286: an open standard for a public-key system has yet to be adopted by the
        !           287: commercial community.
        !           288: In contrast,
        !           289: the \ansi/ draft for financial key management appears to be receiving
        !           290: wide support from the commercial community.
        !           291: 
        !           292: \tagtable{4}{Abbreviations used in this paper}{terms}
        !           293: In the description that follows,
        !           294: a large number of acronyms are employed to denote commonly used terms.
        !           295: In order to aid the reader,
        !           296: these are summarized in Table~\terms.
        !           297: 
        !           298: \section{The Key Distribution Service}
        !           299: The prototype version of the \KDS/
        !           300: was designed to provide key distribution services for
        !           301: user agents under both the same or different administrations.
        !           302: As a result,
        !           303: the means by which a trusted mail agent connects to a key distribution server
        !           304: is quite flexible.
        !           305: For example,
        !           306: the prototype system supports connections via
        !           307: standard terminal lines,
        !           308: dial-ups (e.g., over a toll-free 800 number),
        !           309: \unix/ pipes,
        !           310: and over TCP sockets\cite{IP,TCP}.
        !           311: In the interests of simplicity,
        !           312: for the remainder of this paper,
        !           313: a TCP/IP model of communication is used.
        !           314: Initially,
        !           315: a server on a well-known service host in the ARPA Internet community
        !           316: listens for connections on a well-known port.%
        !           317: \nfootnote{The term {\it well known} in this context means that the 
        !           318: location of the service is known {\it a priori} to the clients.}
        !           319: As each connection is established,
        !           320: it services one or more transactions over the lifetime of the session.
        !           321: When all transactions for a session have been made,
        !           322: the connection is closed.
        !           323: If the necessary locking operations are performed by the server
        !           324: to avoid the usual database problems,
        !           325: then more than one connection may be in progress simultaneously.
        !           326: Of course,
        !           327: a time-out facility should also be employed to prevent a rogue agent from
        !           328: monopolizing the key distribution server.
        !           329: 
        !           330: Once a session has been started,
        !           331: the client (a.k.a.~\TMA/) initiates transactions with the server
        !           332: (a.k.a.~\KDS/).
        !           333: Each transaction consists of the exchange of two or three
        !           334: {\it cryptographic service messages} (\CSM/s):
        !           335: the client sends a request,
        !           336: the server attempts to honor the request and sends a response,
        !           337: and,
        !           338: if the server responded positively,
        !           339: the client then acknowledges the transaction.
        !           340: By exchanging these cryptographic service messages,
        !           341: the \KDS/ and the \TMA/ are able to communicate key relationships.
        !           342: Obviously, the relationships themselves must be transmitted in encrypted
        !           343: form.%
        !           344: \nfootnote{Otherwise an adversary could simply impersonate a \TMA/ and ask
        !           345: for the desired key relationships.
        !           346: Similarly, this also prevents an adversary from successfully impersonating a
        !           347: key distribution server.}
        !           348: Hence, not only are key relationships between two \TMA/s communicated,
        !           349: but key relationships between the \KDS/ and the \TMA/ are communicated as well.
        !           350: 
        !           351: This leads us to consider the key relationships that exist
        !           352: between a \TMA/ and the \KDS/.
        !           353: A client usually has three keys dedicated for use with the server.
        !           354: The first is the {\it master key} (denoted MK),
        !           355: which has an infinite cryptoperiod, and is rarely used.
        !           356: This key is distributed manually.
        !           357: The second is the {\it key-encrypting key} (denoted KK),
        !           358: which has a shorter cryptoperiod.
        !           359: Whenever a KK is transmitted to the \TMA/,
        !           360: it is encrypted with the master key.
        !           361: The third is the {\it authentication key} (denoted KA),
        !           362: which is used to authenticate transactions that do not contain data keys
        !           363: (a count field is also used to avoid play-back attacks).
        !           364: Whenever a KA is transmitted to the \TMA/,
        !           365: it is encrypted with the key-encrypting key.
        !           366: When transactions contain keys,
        !           367: an associated count field is included to indicate the number of
        !           368: keys encrypted with the key-encrypting key used.
        !           369: Although not used by the prototype implementation,
        !           370: a production system would employ audit mechanisms to monitor usage histories.
        !           371: 
        !           372: Currently four types of requests are honored by the \KDS/:
        !           373: two key relationship primitives, and two name service primitives.
        !           374: The type is indicated by the {\it message class} (MCL) of the first
        !           375: cryptographic service message sent in the transaction.
        !           376: As each message class  is discussed,
        !           377: the appropriate datastructures used by the \KDS/ are introduced.
        !           378: Space considerations prevent a detailed description of the information
        !           379: exchanged in each transaction.
        !           380: Appendix~B of this paper presents a short example of an interaction between
        !           381: the \KDS/ and a \TMA/.
        !           382: 
        !           383: The first two requests are used to create (or retrieve) key relationships,
        !           384: and to destroy key relationships:
        !           385: 
        !           386: The {\it request service initialization} (RSI) message class
        !           387: is used to establish a {\it key-encrypting key} (KK) relationship
        !           388: between the \TMA/ and another \TMA/,
        !           389: or between the \TMA/ and the \KDS/.
        !           390: As implied by the name,
        !           391: a key-encrypting key is used to cipher keys which are used to cipher data
        !           392: exchanged between peers.
        !           393: These other keys are called {\it data keys} (KDs).
        !           394: 
        !           395: The {\it disconnect service message} (DSM) message class
        !           396: is used to discontinue a KK-relationship
        !           397: between the \TMA/ and another \TMA/,
        !           398: or between the \TMA/ and the \KDS/.
        !           399: This prevents keys which are felt to have been compromised,
        !           400: or are vulnerable to compromise,
        !           401: from receiving further use in the system.
        !           402: It should be noted that,
        !           403: owing to mail messages (not \CSM/s) in transit,
        !           404: a discontinued key relationship
        !           405: may be needed to decipher the key used to encipher a mail message.
        !           406: The prototype \KDS/ supports this capability.
        !           407: 
        !           408: In addition to maintaining an MK/KK/KA triple for each \TMA/,
        !           409: the \KDS/ also remembers KK-relationships between \TMA/s.
        !           410: The reason for this stems from a fundamental difference between the
        !           411: electronic funds transfer and computer-based message system worlds.
        !           412: The \KDS/ assumes that no two arbitrarily chosen \TMA/s can communicate in
        !           413: real-time,
        !           414: and as a result,
        !           415: \TMA/s do not exchange cryptographic service messages.
        !           416: (See Appendix~C for a more detailed discussion.)
        !           417: This means that when a \TMA/ establishes a KK-relationship with another \TMA/,
        !           418: the former \TMA/ may start using the KK before the latter \TMA/ knows of the
        !           419: new KK-relationship.
        !           420: In fact,
        !           421: it is quite possible for a KK-relationship to be established,
        !           422: used,
        !           423: and then discontinued,
        !           424: all unilaterally on the part of one \TMA/.
        !           425: It is up to the \KDS/ to retain old cryptographic material
        !           426: (possibly for an indefinite period of time),
        !           427: and aid the latter \TMA/ in reconstructing KK-relationships as the need arises.
        !           428: Naturally,
        !           429: discontinued KKs are not used to encode any new information,
        !           430: but rather to decode old information.
        !           431: (Again, refer to Appendix~C for additional details.)
        !           432: 
        !           433: The other two requests are used to query the directory service aspects of the
        !           434: key distribution server:
        !           435: 
        !           436: The {\it request user identification} (RUI) message class
        !           437: is used to identify a subscriber to the \KDS/.
        !           438: Both  the \KDS/ and \TMA/ are independent of any underlying mail transport
        !           439: system (\MTS/).
        !           440: As a result,
        !           441: a subscriber to the \KDS/ is known by two unique attributes:
        !           442: a ``real-world'' name,
        !           443: and a \KDS/ identifier (ID).
        !           444: The user of a mail system,
        !           445: or the \UA/,
        !           446: is responsible for mapping an \MTS/-specific address
        !           447: (e.g., {\tx [email protected]})
        !           448: to the person associated with that maildrop
        !           449: (e.g., \eg{Marshall\ T.\ Rose}).
        !           450: When conversing with the \KDS/,
        !           451: the \TMA/ uses the \KDS/ ID of another user to reference that person's \TMA/.
        !           452: Since it is inconvenient to remember the IDs (as opposed to people's names),
        !           453: the \KDS/ provides the RUI message class to permit a \TMA/ to query the
        !           454: mapping between names and IDs.
        !           455: If the \KDS/ cannot return an exact match,
        !           456: it may respond with a list of possible matches
        !           457: (if the identifying information given was ambiguous),
        !           458: or it may respond with a response that there is no matching user.
        !           459: 
        !           460: Finally,
        !           461: the {\it request identified user} (RIU) message class
        !           462: performs the inverse operation:
        !           463: given a \KDS/ ID, a ``real-world'' name is returned.
        !           464: This request is useful for disambiguating unsuccessful RUI requests
        !           465: and in boot-strapping a \TMA/.
        !           466: 
        !           467: The \KDS/ maintains two directories:
        !           468: a private directory and a public directory.
        !           469: The private directory contains all information on all clients to the \KDS/.
        !           470: The public directory is a subset of this,
        !           471: and is used by the \KDS/ when processing RUI and RIU requests.%
        !           472: \nfootnote{In the prototype implementation,
        !           473: the two directories are, for the moment, identical.}
        !           474: As a result,
        !           475: certain clients of the \KDS/ may have unlisted IDs and names.
        !           476: 
        !           477: \section{The Trusted Mail Agent}
        !           478: The prototype version of the \TMA/
        !           479: was designed to interface directly to the user agent in order to maximize
        !           480: transparency to the user.
        !           481: In present form,
        !           482: the \TMA/ is available as a load-time library under 4.2\bsd/ \unix/,
        !           483: although efforts are currently underway to transport the \TMA/ to a PC-based
        !           484: environment.
        !           485: 
        !           486: The software modules which compose the \TMA/ contain a rich set of interfaces
        !           487: to the \KDS/.
        !           488: In addition,
        !           489: the \TMA/ manages a local database,
        !           490: so responses from the \KDS/ may be cached and used at a later time.
        !           491: In all cases,
        !           492: the \KDS/ is consulted only if the information is not present
        !           493: in the \TMA/ database,
        !           494: or if the information in question has expired (e.g., KK-relationships).
        !           495: This caching activity minimizes connections to the \KDS/.
        !           496: Although connections are relatively cheap in the ARPA Internet,
        !           497: substantial savings are achieved for PCs which contact the \KDS/ over a
        !           498: public phone network (dial-up) connection.
        !           499: 
        !           500: The \TMA/ performs mappings between pairs of the following objects:
        !           501: user names, \KDS/ IDs, and \MTS/ addresses.
        !           502: The \TMA/ considers all trusted mail agents, including itself,
        !           503: as a user name, \KDS/ ID, and one or more \MTS/ addresses.
        !           504: Although the \TMA/ does not interpret addresses itself,
        !           505: in order to simplify mail handling,
        !           506: the \TMA/ remembers the relationship between these objects so the user enters
        !           507: this information only once.
        !           508: 
        !           509: Initially,
        !           510: when a \TMA/ is booted,
        !           511: the user supplies it with the master key and the user's \KDS/ ID.
        !           512: Both of these quantities are assigned by the personnel at the key
        !           513: distribution center,
        !           514: and subsequently transmitted to the user via an alternate, bonded service.%
        !           515: \nfootnote{In this fashion,
        !           516: the problems of boot-strapping over an unsecure medium are avoided.}
        !           517: The \TMA/ connects with the \KDS/ and verifies its identity.
        !           518: From this point on,
        !           519: the \TMA/ manages its KK-relationships between the \KDS/ and other \TMA/s
        !           520: without user intervention.
        !           521: 
        !           522: The current implementation of the \TMA/ assumes a ``general memo framework''
        !           523: in the context of the Standards for ARPA Internet Text Messages\cite{DCroc82}:
        !           524: \smallskip
        !           525: {\advance\leftskip by\parindent
        !           526: \item{1.} A message consists of two parts:
        !           527: the {\it headers} and the {\it body}.
        !           528: A blank line separates the headers from the body.
        !           529: 
        !           530: \item{2.} Each (virtual) line in the headers consists of a keyword/value
        !           531: pair, in which the keyword is separated from the value by a colon (:).
        !           532: The headers are rigorously structured in the sense that they contain
        !           533: addressing and other information useful to a user agent.
        !           534: 
        !           535: \item{3.} The body is freely formatted and must not be meaningful to a
        !           536: user agent.
        !           537: However, as will be seen momentarily,
        !           538: the body of encrypted messages must have an initial fixed format which the
        !           539: \TMA/ enforces.
        !           540: \smallskip}
        !           541: \noindent
        !           542: This format is widely called ``822'' after the number assigned to the
        !           543: defining report\cite{DCroc82}.%
        !           544: \nfootnote{Although an 822--style framework is employed by the \TMA/ prototype,
        !           545: the 822 \eg{Encrypted:} header is not currently present in encrypted messages.
        !           546: This is due to a design decision which assumes that nothing in the headers of
        !           547: a message is sacred to the transport system,
        !           548: and that ``helpful'' munging might occur at any time.
        !           549: In the real world, such helpfulness is often a problem.}
        !           550: 
        !           551: To support the cipher activities described below,
        !           552: the \TMA/ contains internal routines to perform the following DES functions:
        !           553: electronic code book (ECB) for key encryption,
        !           554: cipher block chaining (CBC) for mail message encryption,
        !           555: checksumming (CKS) for mail message and \CSM/ authentication.
        !           556: Readers interested in these different modes of operation for the DES should
        !           557: consult \cite{FIPS81}.
        !           558: 
        !           559: \subsection{Encrypting Mail}
        !           560: To encipher a message, the method used is a straightforward adaptation
        !           561: of the standard encrypting/authentication techniques
        !           562: (though the terminology is tedious).
        !           563: Consider the following notation:
        !           564: \smallskip
        !           565: {\advance\leftskip by\parindent
        !           566: \itemm $a_x(s)$ the checksum of the string $s$ using the key $x$
        !           567: (DEA~{\it checksumming} authentication)
        !           568: 
        !           569: \itemm $a_{x+y}(s)$ the checksum of the string $s$ using the exclusive-or
        !           570: of the two keys $x$ and $y$
        !           571: 
        !           572: \itemm $e_x(y)$ the encryption of the key $y$ using the key $x$
        !           573: (DEA~{\it electronic code book} encryption)
        !           574: 
        !           575: \itemm $e_{x,y}(s)$ the encryption of the string $s$ using the key $x$
        !           576: and initialization vector $y$
        !           577: (DEA~{\it cipher block chaining} encryption)
        !           578: 
        !           579: \itemm $h$ the headers of the message
        !           580: 
        !           581: \noindent and,
        !           582: 
        !           583: \itemm $b$ the body of the message
        !           584: \smallskip}
        !           585: \noindent
        !           586: For each message to be encrypted,
        !           587: a data key, initialization vector, authentication key (KD/IV/KA)
        !           588: triple is generated by a random process.
        !           589: (It goes without saying that the integrity of the system depends on the
        !           590: process being {\it random\/}).
        !           591: Then, for each user to receive a copy of the encrypted message,
        !           592: the following actions are taken:
        !           593: 
        !           594: First, the headers of the message are output in the clear.
        !           595: Then, a {\it banner} string, $i$, is constructed and placed at the beginning
        !           596: of the body of the message:
        !           597: \example ENCRYPTED MESSAGE: TTI TMA\endexample
        !           598: which identifies the message as being encrypted by the \TTI/ \TMA/.
        !           599: Following the banner string is a structure, $m$,
        !           600: which takes on the syntax and most of the semantics of a cryptographic
        !           601: service message:
        !           602: $$\displayindent=\leftskip     \advance\displayindent by1.5\parindent
        !           603:     \halign{\hfil#/&   \enspace#\hfil\cr
        !           604:        MCL&    MAIL\cr
        !           605:        RCV&    rcvid\cr
        !           606:        ORG&    orgid\cr
        !           607:        IDK&    kkid\cr
        !           608:        KD&     $e_{kk}(ka)$\cr
        !           609:        KD&     $e_{kk}(kd)$\cr
        !           610:        IV&     $e_{kd}(iv)$\cr
        !           611:        MIC&    $a_{ka}(b)$\cr
        !           612:        MAC&    $a_{kd+ka}(m)$\cr
        !           613: }$$
        !           614: After this, the encrypted body is output, $e_{kd,iv}(b)$.
        !           615: In short, the entire output consists of
        !           616: $$h+i+m+e_{kd,iv}(b).$$
        !           617: 
        !           618: The purpose of the structure $m$ is many-fold.
        !           619: The MCL field indicates the structure $m$'s type;
        !           620: currently only the type MAIL is generated and understood.
        !           621: The RCV and ORG fields identify the intended recipient of the message
        !           622: and the originator.
        !           623: The IDK field identifies the key-encrypting key, KK,
        !           624: used to encrypt the next two fields.
        !           625: The first KD field has the encrypted authentication key, KA,
        !           626: used to calculate the MIC of the plaintext of the body of the message.
        !           627: After the body of the message is deciphered, $a_{ka}(b)$ is calculated and
        !           628: compared to the value of the MIC field.
        !           629: Hence, the MIC field authenticates the message body.
        !           630: The second KD field has the encrypted data encrypting key, KD,
        !           631: which along with the encrypted initialization vector in the IV field
        !           632: was used to generate the ciphertext of the body.
        !           633: Finally, the MAC field authenticates the $m$ structure itself.
        !           634: The use of a data key, initialization vector, authentication key (KD/IV/KA)
        !           635: triple permits us to perform key distribution in a hierarchical fashion and
        !           636: allows the system to use a KK-relationship over a longer cryptoperiod
        !           637: without fear of compromise.
        !           638: 
        !           639: The \TMA/ provides three primary interfaces to a \UA/ to send encrypted mail:
        !           640: the first takes a file-descriptor to a message
        !           641: and returns a structure $g$ (called a {\it group})
        !           642: describing the ciphertext version of the body
        !           643: (this structure contains a KD, IV, and KA generated at random,
        !           644: along with a file-descriptor to the plaintext headers,
        !           645: a file-descriptor to the ciphertext body,
        !           646: and the checksum of the plaintext body);
        !           647: the second takes a user entry (or \MTS/ address) and $g$,
        !           648: and returns a file-descriptor to the encrypted message
        !           649: for that user (or \MTS/ address);
        !           650: the third takes $g$ and performs clean-up operations.
        !           651: The chief advantage to this scheme of encryption
        !           652: is that if the message is to be sent to more than one recipient,
        !           653: then the MIC and the encrypted body need only be calculated once,
        !           654: since the KD, IV, and KA remain constant
        !           655: (only the KK's change with each recipient,
        !           656: hence for each copy of the encrypted message,
        !           657: only the structure $m$ need be re-calculated).
        !           658: 
        !           659: There are, however, a few subtleties involved:
        !           660: \underbar{first},
        !           661: the \MTS/ usually accepts only 7--bit characters,
        !           662: so the encrypted text is exploded to consist of only printable characters;%
        !           663: \nfootnote{%
        !           664: As a rule, in all \CSM/s,
        !           665: when encrypted information is transmitted,
        !           666: it is exploded after encryption by the sender,
        !           667: and imploded prior to decryption by the receiver.}
        !           668: \underbar{second},
        !           669: since the \MTS/ may impose limits on the length of a line,
        !           670: each line of output is limited to 64~characters;
        !           671: and,
        !           672: \underbar{third},
        !           673: since the body may require trailing padding,
        !           674: during encryption
        !           675: one last unit of 8~bytes is written (and encrypted),
        !           676: naming the number of characters (presently, nulls) padded in the
        !           677: previous 8~bytes ($0\tdots7$).
        !           678: 
        !           679: \subsection{Decrypting Mail}
        !           680: To decipher a message, the method is also straightforward:
        !           681: The headers are output in the clear.
        !           682: The banner string is essentially ignored,
        !           683: and the structure $m$ is consulted to identify the correct key-encrypting key.
        !           684: The \TMA/ checks to see if it knows of that KK.
        !           685: If not, it asks the \KDS/ to supply it.
        !           686: From that point,
        !           687: the KA, KD, and IV are deciphered.
        !           688: The $m$ structure is then authenticated.
        !           689: With the correct key,
        !           690: the remainder of the body is deciphered,
        !           691: and all except for the last 16~bytes are output.
        !           692: The last 8~bytes indicate how many of the previous 8~bytes should be output.
        !           693: So,
        !           694: the appropriate number of bytes is output,
        !           695: and the plaintext body is authenticated and compared to the MIC.
        !           696: Needless to say,
        !           697: as the body is deciphered,
        !           698: it is imploded back to 8--bit characters and lines are restored to their
        !           699: previous lengths.
        !           700: To indicate that the message was correctly deciphered,
        !           701: a new header of the form
        !           702: \example X-KDS-ID: orgid (originator's name)\endexample
        !           703: is appended to the headers of the message.
        !           704: Note that this provides an authentication mechanism.
        !           705: Note, further,
        !           706: that the \UA/ did not have to know the identity of the sender of the message.
        !           707: 
        !           708: \section{Modifications to MH}
        !           709: \MH/ is a public domain \UA/ for \unix/,
        !           710: which is widely used in dealing with both a large number of electronic mail
        !           711: application and a large number of messages.
        !           712: Although this document does not intend to describe \MH/,
        !           713: parts of the system are described as they relate to the \TMA/.
        !           714: Readers interested in \MH/ should consult either the user's
        !           715: manual\cite{MRose85a} for a detailed description,
        !           716: or \cite{MRose85d} for a higher-level description.
        !           717: 
        !           718: To modify \MH/ in order to make use of a \TMA/,
        !           719: three programs were changed (with a high degree of transparency to the user),
        !           720: and two new programs were introduced.
        !           721: 
        !           722: In \MH/,
        !           723: when a user wishes to send a composed draft
        !           724: (which may be an entirely new message,
        !           725: a re-distribution of a message,
        !           726: a forwarding of messages,
        !           727: or a reply to a message),
        !           728: the user invokes the \pgm{send} program.
        !           729: This program performs some minor front-end work for a program called
        !           730: \pgm{post} which actually interacts with the \MTS/.
        !           731: A new option to the \pgm{send} and \pgm{post} programs,
        !           732: the \switch{encrypt} switch,
        !           733: is introduced.
        !           734: If the user indicates
        !           735: \example send\ -encrypt\endexample
        !           736: then \pgm{post} encrypts the messages it sends.
        !           737: 
        !           738: When sending an encrypted message,
        !           739: \pgm{post} first checks that each addressee has a mapping to a \KDS/ ID
        !           740: during address verification.
        !           741: Then, instead of batching all addresses for a message in a single posting
        !           742: transaction,
        !           743: for each addressee,
        !           744: \pgm{post} consults the \TMA/ for the appropriately encrypted text and
        !           745: posts that instead.
        !           746: (Appendix~A discusses the reasons for this more fully.)
        !           747: Hence,
        !           748: assuming the user has established mappings between \MTS/ addresses
        !           749: and \KDS/ IDs,
        !           750: the \TMA/ does all the work necessary to encrypt the message,
        !           751: including contacting the \KDS/ as necessary.%
        !           752: \nfootnote{Once the \TMA/ establishes a connection to the \KDS/,
        !           753: it retains that connection until the \UA/ terminates.
        !           754: This is done to minimize connections to the \KDS/.
        !           755: In the context of \MH/,
        !           756: since the trusted mail agent is active over the lifetime of an invocation of
        !           757: a program such as \pgm{post},
        !           758: this means that the connection is terminated just before the program
        !           759: terminates.}
        !           760: 
        !           761: In \MH/,
        !           762: when a user is notified that new mail has arrived,
        !           763: the \pgm{inc} program is run.
        !           764: As each message is incorporated into the user's message handling area,
        !           765: a scan (one-line) listing of the message is generated.
        !           766: 
        !           767: By default,
        !           768: the \pgm{inc} program upon detecting one or more encrypted messages,
        !           769: after the scanning process,
        !           770: asks the \TMA/ to decipher the message,
        !           771: and if successful,
        !           772: scans the deciphered messages.
        !           773: This action can be inhibited with the \switch{nodecrypt} switch.
        !           774: Hence, if the user wishes to retain messages in encrypted form,
        !           775: \pgm{inc} can be told to note the presence of encrypted messages,
        !           776: but otherwise not to process them.
        !           777: By using the \MH/ user profile mechanism,
        !           778: \pgm{inc} can be easily customized to reflect the user's tastes.
        !           779: Again,
        !           780: the actions of the \TMA/ are transparent to the user.
        !           781: In fact,
        !           782: if encrypted mail is received from users unknown to the \TMA/,
        !           783: it queries the \KDS/ as to their identity prior to retrieving the
        !           784: KK-relationship.
        !           785: 
        !           786: If \pgm{inc} fails to decrypt a message for some reason,
        !           787: or if \pgm{inc} was told not to decrypt a message,
        !           788: the \pgm{decipher} program can be used.
        !           789: This simple program merely deciphers each message given in its argument
        !           790: list.
        !           791: The \pgm{decipher} program can be given the \switch{insitu} switch,
        !           792: which directs it to replace the ciphertext version of the message with the
        !           793: plaintext version;
        !           794: or,
        !           795: the \switch{noinsitu} switch can be used indicating that the ciphertext
        !           796: version of the message should be left untouched and the plaintext version
        !           797: should be listed on the standard output.
        !           798: 
        !           799: Finally,
        !           800: the \pgm{tma} program is used to manipulate the \TMA/ database,
        !           801: containing commands to boot the database,
        !           802: add new users to the database,
        !           803: and to establish mappings between addresses and users in the \TMA/ database.
        !           804: This program can also be used to disconnect KKs between other \TMA/s,
        !           805: and the KK/KA between itself and the \KDS/.
        !           806: 
        !           807: Appendix~A of this paper contains a transcript of an \MH/ session.
        !           808: 
        !           809: \section{Remarks}
        !           810: We now consider the merit of the system described.
        !           811: After presenting some of the basic strengths of the system
        !           812: and a few unresolved questions,
        !           813: the discussion centers on the simplifying assumptions made by the system,
        !           814: and how these can be defended in a non-military environment.
        !           815: 
        !           816: \subsection{Strengths}
        !           817: It can be argued that the prototype system
        !           818: (and the augmented model in which it finds its basis)
        !           819: present many strengths.
        !           820: 
        !           821: Perhaps the most important is the high-level of independence from the \MTS/
        !           822: enjoyed by the system.
        !           823: As a result,
        !           824: since the \TMA/ does not interact directly with the \MTS/,
        !           825: it can be made to be completely free from any \MTS/-specific attributes,
        !           826: such as naming, addressing, and routing conventions.
        !           827: Furthermore,
        !           828: when interfacing a \trustedmail/ system,
        !           829: no modifications need be made to the \MTS/ or local \MTA/.
        !           830: 
        !           831: In addition to the systems-level advantage to this scheme,
        !           832: users of the system profit as well,
        !           833: since many disjoint \MTS/s can be employed by a user with a single \TMA/.
        !           834: This reduces the number of weaknesses in the system and allows a user to keep
        !           835: a single database of ``trusted'' correspondents.
        !           836: It should also make analysis and verification of the \TMA/ easier.
        !           837: 
        !           838: Of course from the user-viewpoint,
        !           839: once the \TMA/ has been initially booted,
        !           840: all key management is automatic.
        !           841: Not only does this reduce the risk of compromise of cryptographic material
        !           842: (given proper construction and maintenance of the \TMA/),
        !           843: but it relieves the user of a tedious and error-prone task.
        !           844: 
        !           845: Finally,
        !           846: although the \KDS/ described herein is used to support \trustedmail/,
        !           847: other applications which require key management,
        !           848: could employ the services offered by the key distribution center.
        !           849: 
        !           850: \subsection{Open Questions}
        !           851: At present, there are many restrictions on the prototype implementation
        !           852: described.
        !           853: Some of these result from that fact that the implementation is a prototype
        !           854: and not a production system.
        !           855: Others deal with more fundamental issues.
        !           856: 
        !           857: In terms of the \TMA/,
        !           858: the expiration delay for keys is hard-wired in;
        !           859: it should be user-settable.
        !           860: In the prototype version,
        !           861: the KK and KA with the \KDS/ are good for 2~days or 10~uses
        !           862: (whichever comes first),
        !           863: while a KK for use with another \TMA/ is good for 1~day or 5~uses.
        !           864: In actual practice,
        !           865: keys with long cryptoperiods might be good for 6~months or 100~uses,
        !           866: while keys with short cryptoperiods might be good for 1~month or 25~uses.
        !           867: The choice of actual values is an open question
        !           868: beyond the scope of prototype system.%
        !           869: \nfootnote{The current values were chosen by guess work.
        !           870: Although not necessarily technically sound,
        !           871: the small numbers were very good for debugging purposes.}
        !           872: In many respects, this issue is a classic trade-off:
        !           873: with relatively small cryptoperiods,
        !           874: an adversary has less chance of breaking a key,
        !           875: but with longer cryptoperiods less connections have to be made to the key
        !           876: distribution server.
        !           877: 
        !           878: A fundamental issue,
        !           879: owing to differences between the EFT and CBMS environments,
        !           880: is that the \KDS/ implements only a subset of the \ansi/ draft
        !           881: and the semantics of certain operations have changed somewhat.
        !           882: It would be nice to unify the CBMS and EFT views
        !           883: of a {\it key distribution center}
        !           884: (in the former environment, the center is called a \KDC/,
        !           885: while in the latter environment, the center is known as a \CKD/).
        !           886: Appendix~C of this paper discusses the differences between the two
        !           887: perspectives in greater detail.
        !           888: 
        !           889: At present,
        !           890: the relationship between errors in the \TMA/ and the posting process is an
        !           891: open question.
        !           892: For example,
        !           893: if an address doesn't have a mapping in the \TMA/ database,
        !           894: \pgm{post} treats this as an address verification error.
        !           895: This prevents the draft from being posted.
        !           896: The philosophy of the \UA/ is unclear at this point,
        !           897: with respect to how recovery should occur.
        !           898: A second area, also in question, deals with the way in which plaintext and
        !           899: ciphertext versions of a message are present in a system.
        !           900: Clearly, it is a bad idea to make both versions available,
        !           901: but since the \TMA/ doesn't try to concern itself with first party
        !           902: observation,
        !           903: there seems to be little possibility of preventing this behavior.
        !           904: The best that can be done,
        !           905: at this stage,
        !           906: is simply to choose a consistent policy that user's should attempt to adhere
        !           907: to.
        !           908: The software can help somewhat in implementing this policy,
        !           909: but it certainly can't circumvent the user.
        !           910: 
        !           911: The prototype is built on the assumption that a single key
        !           912: distribution server is present.
        !           913: Since the \ansi/ draft\cite{FIKM} makes provisions for
        !           914: {\it key translation centers},
        !           915: the \trustedmail/ prototype should perhaps be made to operate in a more diverse
        !           916: environment.
        !           917: Until the issues become clearer,
        !           918: this remains open.
        !           919: 
        !           920: Finally,
        !           921: for distribution lists,
        !           922: a large number of people would need to share the same \KDS/ ID.
        !           923: The current implementation doesn't support this.
        !           924: Each \TMA/ database is for a particular ID.
        !           925: A user with multiple IDs would need multiple databases,
        !           926: or the database should be re-organized.
        !           927: 
        !           928: \subsection{Weaknesses}
        !           929: As pointed out earlier,
        !           930: this prototype system situates itself in a commercial, not military,
        !           931: environment.
        !           932: With respect to this decision,
        !           933: several aspects of the system are now discussed,
        !           934: which we feel are acceptable in a commercial environment,
        !           935: but which would be considered weaknesses in a military environment:
        !           936: 
        !           937: \item{1.} Traffic Flow\hbreak
        !           938: The prototype \TMA/ makes no attempt whatsoever to prevent or confuse traffic
        !           939: analysis by augmenting traffic flow.
        !           940: 
        !           941: \item{2.} The Database of \KDS/ Subscribers\hbreak
        !           942: Since information returned by the request user identification (RUI)
        !           943: and request identified user (RIU) MCLs are returned in the clear,
        !           944: this allows an adversary to ascertain subscribers to the \KDS/,
        !           945: and perhaps deduce some information about the system.
        !           946: Without knowledge of the master key however,
        !           947: an adversary could not impersonate a subscriber though.
        !           948: Still, in the military sense, this is a weakness.
        !           949: However,
        !           950: all this assumes that the database maintained by the \KDS/ accurately
        !           951: reflects the real-world.
        !           952: 
        !           953: \item{3.} Multiple Recipients\hbreak
        !           954: It is possible, though not proven to the authors' knowledge,
        !           955: that the scheme used to avoid encrypting the body of a message more than once
        !           956: for multiple recipients might permit one of the recipients who is also an
        !           957: adversary to compromise the key relationship between the sender and another
        !           958: recipient.
        !           959: 
        !           960: \item{} The scenario goes like this:
        !           961: When a message is being prepared for encryption,
        !           962: a single KD/IV/KA triple is generated to encrypt the body.
        !           963: Since the sender has a different key relationship with each recipient,
        !           964: each message sent is different, since the structure $m$ depends not only on
        !           965: the KD/IV/KA triple but also on the key relation between the sender and a
        !           966: particular recipient.
        !           967: Now suppose that one of the recipients, $r_1$,
        !           968: in addition to receiving the copy of the message meant for him/her also
        !           969: intercepts a copy of the message destined for another recipient, $r_2$.
        !           970: At this point,
        !           971: the recipient $r_1$ has both the plaintext and ciphertext version of the body,
        !           972: the plaintext version of the KD/IV/KA triple,
        !           973: and the ciphertext version of the KD/IV/KA triple that was generated using
        !           974: the key relationship between the sender and the recipient $r_2$.
        !           975: The question is:
        !           976: can $r_1$ now deduce the key relationship between the sender and $r_2$?
        !           977: 
        !           978: \item{} If so, then the way that the \TMA/ attempts to minimize the use of
        !           979: encryption resources is a weakness.
        !           980: But, even if this is possible,
        !           981: given relatively short cryptoperiods for key relationships between \TMA/
        !           982: peers,
        !           983: this becomes a non-problem.
        !           984: 
        !           985: \item{4.} Discussion Groups\hbreak
        !           986: As discussed earlier,
        !           987: the proposed method of associating a single \KDS/ ID with the membership of a
        !           988: discussion group does introduce a significant weakness for the security of
        !           989: messages sent to the discussion group.
        !           990: Since the \TMA/ does not assume a general broadcast facility,
        !           991: it appears that there are no good solutions to the problem of discussion
        !           992: group traffic.
        !           993: Of course,
        !           994: it is easy enough to simply send to each member of the group.
        !           995: 
        !           996: \item{} For the sake of argument,
        !           997: let's assume that the discussion group has $n$ members.
        !           998: Now,
        !           999: since a different key relationship would exist between the sender and
        !          1000: each of the $n$ recipients,
        !          1001: the structure $m$ would be different for each recipient
        !          1002: and so a different message would have to be sent to each recipient.
        !          1003: To make matters worse,
        !          1004: if one rejects the way the \TMA/ handles multiple recipients,
        !          1005: not only does the \MTS/ get burdened with $n$ different messages,
        !          1006: but the sender's \TMA/ gets burdened by having to encrypt
        !          1007: the body of the message $n$ times.
        !          1008: For meaningful values of $n$ (say on the order of~500, or even~25),
        !          1009: the amount of resources required for any trusted discussion group are simply
        !          1010: too costly.
        !          1011: 
        !          1012: \subsection{Compromises, Compromises}
        !          1013: Each of the possible weaknesses discussed above represent a compromise
        !          1014: between the expense of the system and the level of security it can provide.
        !          1015: 
        !          1016: The first two areas, if addressed by the \TMA/,
        !          1017: could result in much less background information being available to an
        !          1018: adversary.
        !          1019: In an application where it is important that an adversary not know who is
        !          1020: talking to whom,
        !          1021: or who can talk at all,
        !          1022: this is very important.
        !          1023: It is the authors' position that in the commercial environment,
        !          1024: this issue is not paramount.
        !          1025: By ignoring the issue of traffic flow,
        !          1026: the \TMA/ has a lot less work to do and the \MTS/ is kept clear of
        !          1027: ``useless'' messages.
        !          1028: By keeping the information returned by the RUI and RIU MCLs in the clear,
        !          1029: the complexity of the \TMA/ is significantly reduced.
        !          1030: 
        !          1031: The second two areas, if addressed by the \TMA/,
        !          1032: could result in a lesser probability of traffic being deciphered by an
        !          1033: adversary.
        !          1034: Regardless of the application,
        !          1035: this is always extremely important.
        !          1036: However,
        !          1037: the authors' feel that the compromise made by the \TMA/ in these two issues
        !          1038: is not substantial,
        !          1039: and does not result in an explicit weakness when a message is sent to
        !          1040: multiple recipients
        !          1041: (note that when there is only a single recipient of a message,
        !          1042: these two policies can not introduce weaknesses).
        !          1043: In return, efficient use can be made of both the \MTS/ and the \TMA/ when
        !          1044: messages are being sent to multiple recipients.
        !          1045: Given scarce resources or large numbers of recipients,
        !          1046: this approach may prove to be quite winning.
        !          1047: 
        !          1048: Of course, much work remains to be done to prove the success of the \TMA/ in
        !          1049: all four of these areas.
        !          1050: 
        !          1051: \section{Acknowledgements}
        !          1052: The prototype implementation described herein utilizes a public domain
        !          1053: implementation of the DES algorithm\cite{DEA}
        !          1054: which was originally implemented by James J.~Gillogly in May, 1977
        !          1055: (who at that time was with the Rand Corporation,
        !          1056: and is now affiliated with Gillogly Software).
        !          1057: Interfaces to Dr.~Gillogly's implementation were subsequently coded by
        !          1058: Richard W.~Outerbridge in September, 1984
        !          1059: (who at that time was with the Computer Systems Research Institute
        !          1060: at the University of Toronto,
        !          1061: and is now affiliated with Perle Systems, Incorporated).
        !          1062: 
        !          1063: The authors would like to acknowledge Dennis Branstad,
        !          1064: Elaine Barker, and David Balensen of the National Bureau of Standards
        !          1065: for their comments on the prototype system
        !          1066: and insights on the ANSI draft\cite{FIKM}.
        !          1067: In particular, Dr.~Branstad originally suggested the method used for
        !          1068: encrypting a single message for multiple recipients under different keys.
        !          1069: 
        !          1070: The authors (and all those who have read this paper) would like to thank
        !          1071: Willis H.~Ware of the Rand Corporation,
        !          1072: and Jonathon B.~Postel of the USC/Information Sciences Institute.
        !          1073: Their extensive comments resulted in a much more readable paper.
        !          1074: In addition,
        !          1075: the authors would like to thank
        !          1076: Dr. Stephen P.~Smith and Major Douglas A.~Brothers
        !          1077: for their insightful comments.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.