Customized generic SPECS/build-nmh-cygwin for nmh.
[mmh] / docs / historical / trusted.txt
1
2
3
4
5                                  Design  of  the  TTI  Prototype
6
7                                          Trusted  Mail  Agent
8
9
10                                              Marshall T. Rosey
11
12                                                David J. Farber
13
14                                             Stephen T. Walker
15
16
17
18                                                   Abstract
19
20
21                The design of the TTI  prototype Trusted Mail Agent (TMA)
22
23                is discussed.  This agent interfaces between two entities:  a key
24
25                distribution  center  (KDC)  and  a  user  agent  (UA).  The  KDC
26
27                manages keys for the encryption of text messages, which two
28
29                subscribers to a key distribution service (KDS) may exchange.
30
31                The TMA is independent of any underlying message transport
32
33                system.
34
35
36                Subscribers  to  the  KDC  are  known  by  unique  identifiers,
37
38                known as IDs.  In addition to distributing keys, the KDC also
39
40                offers  a  simple  directory  lookup  service,  in  which  the  "real-
41
42                world" name of a subscriber may be mapped to an ID, or the
43
44                inverse mapping may be performed.
45
46
47                This  document  details  three  software  components:   first_,  a
48
49                prototype  key  distribution  service,  which  has  been  running
50
51                in  a  TCP/IP  environment  since  December,  1984;  second____,  a
52
53                prototype trusted mail agent; and, third___, modifications to an
54
55                existing UA, the Rand MH Message Handling system, which
56
57                permit interaction with the prototype TMA.
58
59
60
61 ________________________________________
62 y All three authors are with Trusted Technologies, Incorporated, POB 45, Glenwood, MD 21738,
63
64 USA. Telephone: 301/854-6889. In addition, Professor Farber is with the University of Delaware.
65 \f
66
67                                  Design  of  the  TTI  Prototype
68
69                                          Trusted  Mail  Agent
70
71
72
73 Introduction
74
75        Initially, a brief model of a user community employing a trusted mail service
76
77 is introduced.  Following this introduction, a prototype system is described which
78
79 attempts to meet the needs of a user community.  Finally, open issues are discussed,
80
81 which are currently not satisfied by the prototype system or its model of operation.
82
83
84        Two  or  more  entities,  called  users,  wish  to  communicate  in  a  secure
85
86 environment.  Depending  on  their  available  resources,  different  levels  of  security
87
88 are possible.  At the extreme, two parties with substantial resources may wish to
89
90 communicate in a fashion which prevents any third parties, known as adversaries,
91
92 from  observing  their  communication.   At  this  level,  not  only  is  an  adversary
93
94 unable  to  capture  the  communication  for  analysis,  but  in  fact,  the  adversary  is
95
96 unaware  that  any  communication  is  occurring  at  all.  In  most  applications,  this
97
98 level of security is prohibitively expensive.  A more economic method is to translate
99
100 messages into a form which is useless to an adversary and then to communicate
101
102 those messages on an insecure medium.
103
104
105        This latter method requires the two users to have some sort of key with which
106
107 to "lock" the plaintext into ciphertext when transmitting,  and then to "unlock"
108
109 the ciphertext back into useful form when receiving.  Hence, there are two central
110
111 issues to deal with:  first_, keys must be generated, distributed, and maintained in
112
113 a secure fashion;  and, second____, the keys must be "intricate" enough so that sense
114
115 can't be made out of the ciphertext without knowledge of the key.  The first part
116
117 is  handled  by  a  key  distribution  center  (KDC),  which  maintains  a  list  of  users
118
119 and a set of keys for each pair of users.  The second part relies on sophisticated
120
121 encryption  and  decryption  algorithms.  It  is  beyond  the  scope  of  this  paper  to
122
123 describe cryptographic techniques in detail.  For a detailed survey of this area, the
124
125 reader should consult [VVoyd83].
126
127
128        In  the  context  of  our  discussion  (using  the  terminology  of  [X.400]),  the
129
130 medium used to transport is supplied by a message transport system (MTS), which
131
132 is composed of one or more message transport agents (MTAs).  Usually, the entire
133
134 MTS  is  distributed  in  nature,  and  not  under  a  single  administrative  entity;  in
135
136 contrast, an MTA is usually controlled by a single administration and resides in a
137
138 particular domain.  At every end-point in the medium, a user agent (UA) acts on
139
140 behalf of a user and interfaces to a local MTA. This model is briefly summarized in
141
142 Figure 1.
143
144
145
146  Copyright fcl1985, IFIP TC-6                                                                                       1
147 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985                2
148 ______________________________________________________________________________________________________________________
149
150
151
152                 UA                                                                                UA
153
154
155
156    POSTING                                                                                            RECEIPT
157
158
159
160                                                         MTS
161
162
163
164                MTA                  MTA                  : : :                : : :              MTA
165
166                                                               RELAYING
167
168
169
170                                                     Figure 1
171
172 _______________________________________________The_MTS_Model__________________________________________________________
173
174
175
176        A message, in our context, consists of two parts:  the headers and the body.
177
178 The  headers  are  rigorously  structured;  they  contain  addressing  information  and
179
180 other  forms  useful  to  a  UA.  The  body  is  freely  formatted  and  is  usually  not
181
182 meaningful to a UA.
183
184
185        When  a  message  is  sent  from  one  user  to  another,  the  following  activities
186
187 occur:  The originating user indicates to the UA the address of the recipient;  the
188
189 UA  then  posts  the  message  through  a  posting  slot  to  an  MTA,  which  involves
190
191 a  posting  protocol  in  which  the  validity  of  the  address  and  the  syntax  of  the
192
193 message  are  considered.  Upon  successful  completion  of  the  protocol,  the  MTA
194
195 accepts responsibility for delivering the message, or if delivery fails, to inform the
196
197 originating user of the failure.  The MTA then decides if it can deliver the message
198
199 directly  to  the  recipient;  if  so,  it  delivers  the  message  through  a  delivery  slot  to
200
201 the recipient's UA, using a delivery protocol.  If not, it contacts an adjacent MTA,
202
203 closer to the recipient, and negotiates its transfer (using a protocol similar to the
204
205 posting protocol).  This process repeats until an MTA is able to deliver the message,
206
207 or an MTA determines that the message can't be delivered.  In this latter case, a
208
209 failure notice is sent to the originating user.
210
211
212        It is important to note that there are two mappings which occur here.  The
213
214 first, which is performed implicitly by the originating user, maps the name of the
215
216 recipient into the recipient's address; the second, which is performed explicitly by
217
218 the MTS, maps the address of the recipient into a route to get from the originator's
219
220 MTA to the recipient's MTA. These mappings are depicted in Figure 2.
221
222
223        Obviously, there is no guarantee that the MTS can be made secure, in any
224
225 sense of the word.  This is particularly true if it is under several administrations.
226
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 ______________________________________________________________________________________________________________________
230
231
232
233          user                                                                                           user
234
235
236
237             name   ! address
238
239
240
241           UA                                                                                            UA
242
243
244
245                                                         MTS
246             address   ! route
247
248
249
250          MTA                    MTA                      : : :                   : : :                 MTA
251
252
253
254                                                     Figure 2
255
256 ______________________________________Mappings_in_the_MTS_model_______________________________________________________
257
258
259
260 degenerates to a problem of Byzantine generals[LLamp82].  Further, trying to secure
261
262 each MTA in the path that a message travels is equally questionable.
263
264
265        To  support  secure  communications  in  this  environment,  a  new  entity,  the
266
267 trusted mail agent (TMA) is introduced into our model.  A solution is to have the
268
269 UA interact with this entity both when posting a message and when taking delivery
270
271 of a message.  The UA first contacts a TMA to encrypt the body of the message for
272
273 the recipient, prior to pushing it through the posting slot.  Upon receipt from the
274
275 destination MTA, the UA examines the message and contacts the TMA to decipher
276
277 the body of the message from the source.  An overview of the relationship between
278
279 the standard MTS model and the augmentations made for the Trusted Mail1  system
280
281 is shown in Figure 3.
282
283
284        To  achieve  these  tasks,  the  TMA  interacts  with  a  key  distribution  service
285
286 (KDS), which manages keys between pairwise users.  At this point, a third mapping
287
288 takes place:  the UA must be able to map addresses into the identifier(s) by which
289
290 the  originator  and  recipient  are  known  by  the  TMA  and  KDS.  These  identifiers
291
292 are  known  as  KDS  IDs,  or  simply  IDs.  Usually,  a  fourth  mapping  also  occurs,
293
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 ______________________________________________________________________________________________________________________
298
299
300
301           UA                    TMA                     KDS                     TMA                     UA
302
303
304
305                                                         MTS
306
307
308
309          MTA                    MTA                      : : :                   : : :                 MTA
310
311
312
313                                                     Figure 3
314
315 ____________________________________Modifications_to_the_MTS_model____________________________________________________
316
317
318
319 which maps the ID of a user into the name of a user.  In our context, there is an
320
321 exact one-to-one mapping between the name of a user and the ID of that user.  In
322
323 contrast,  there may be a one-to-many mapping between the name of a user and
324
325 that user's address in the MTS. Further, there are usually many different routes
326
327 which a message may traverse when going from an originating user to a recipient
328
329 user.
330
331
332        The TMA is said to be trusted because it can be relied on to perform only
333
334 those  actions  specifically  requested  by  the  user.   In  the  context  of  this  paper,
335
336 this  means,  given  proper  construction  and  maintenance  of  the  TMA,  that  the
337
338 software will communicate with the KDC in some secure fashion to negotiate key
339
340 relationships and that it will not disclose those key relationships to other parties.
341
342 Furthermore, the body of mail messages exchanged between users which employ a
343
344 trusted mail agent will be unintelligible to other parties.  Finally, a recipient of a
345
346 message receives authenticated information from the trusted mail agent as to the
347
348 identify of the sender.
349
350
351        Hence, when each user employs a TMA, end-to-end encryption occurs at the
352
353 UA level (to avoid any problems with malicious MTAs).2  Any adversary listening
354
355 in on the MTS, may observe messages, but make no sense out of them (other than
356
357 rudimentary traffic analysis).  Note, however, that since the medium itself is not
358
359 secure, an adversary may still introduce new messages, corrupt messages, or remove
360
361
362 ________________________________________
363 2  Note that in the scope of this system, the end-points are the user agents, not the hosts they reside
364
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
368
369
370 messages, as they traverse the MTS. In the first two cases, however, the recipient
371
372 would be suspicious because the adversary lacks the encrypting key employed by
373
374 the source user.  In the third case, the source user can retransmit the message after
375
376 a suitable time.  Of course, there is no built-in retransmission policy _ this aspect
377
378 depends on the user's sending mail and is beyond the scope of the system.
379
380
381        It  is  important  to  understand  the  target  community  for  the  Trusted  Mail
382
383 system  described  herein.  In  particular,  the  TMA  is  intended  for  a  commercial
384
385 and  not  a  military  environment.   This  distinction  is  important,  since  it  is  the
386
387 fundamental assumption of this paper that the latter community has much stricter
388
389 requirements  than  the  former.  Because  of  this,  the  prototype  system  is  able  to
390
391 make certain simplifying assumptions which permit it to operate in a mode which
392
393 is less secure than military applications would permit.  Although these issues are
394
395 explored in greater detail at the end of the paper, for the moment recall that, like
396
397 most qualities, trustedness is not absolute:  there are varying degrees of trustedness,
398
399 and as a system becomes more trusted, it becomes more expensive, in some sense,
400
401 to operate and maintain.
402
403
404        It is perhaps instructive at this point to consider why the introduction of a key
405
406 distribution center is appropriate in this environment,  and why the fundamental
407
408 assumption that trusted mail agents do not directly communicate with each other
409
410 is  necessary.  Although  a  user  agent  is  able  to  converse  with  the  local  message
411
412 transport agent in real-time, it is frequently not able to communicate with other
413
414 user agents in real-time.  Furthermore, considering the vast problems and overhead
415
416 of trying to establish secure communications from "scratch" (a problem far beyond
417
418 the scope of this paper), it is would not be a good idea to try and communicate
419
420 key relationships with other user agents, even if it were always possible to do so.
421
422 In  addition,  by  separating  the  trusted  aspects  of  the  message  transport  system
423
424 from the system itself, many other advantages can be seen.  These are presented in
425
426 greater detail at the end of the paper.
427
428
429        The discussion thus far has considered only a single recipient.  In practice, a
430
431 user might wish to send to several others, using a different key for each.  Hence each
432
433 copy of the message is encrypted differently, depending on the particular recipient
434
435 in question.  Note that this has the effect of un-bundling message transfer in the
436
437 MTS, as advanced MTAs tend to keep only a single copy of the message for any
438
439 number of recipients in order to save both cpu, disk, and I/O resources.
440
441
442        For example, in some existing mail systems, if a message was sent to n users
443
444 on a remote system, then the n addresses would be sent from the source MTA to
445
446 the remote MTA along with one copy of the message.  Upon delivery, the remote
447
448 MTA would deliver a copy to each of the n recipients, but the virtual wire between
449
450 the source MTA and the recipient MTA was burdened with only one copy of the
451
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
454
455
456 user when communicating with each of the n recipients, n different messages will
457
458 be posted with the local MTA, and the advantages of recipient bundling are lost.
459
460
461        Along  these  lines  however,  private  discussion  groups  may  wish  to  avoid
462
463 this  problem  by  establishing  access  to  a  single  ID  for  their  use.  In  this  case,  a
464
465 subscriber  to  the  KDS  may  actually  have  more  than  one  ID,  one  for  "personal"
466
467 use and one for each discussion group.  The appropriate ID is used when posting
468
469 messages to the discussion group.  Naturally the administrative policy for deciding
470
471 who is allowed to use the KDS ID of a discussion group is left to the moderator
472
473 of  the  group.  Observant  readers  will  note  that  this  vastly  decreases  the  aspect
474
475 of  secure  communications  for  the  discussion  group.   This  method  is  suggested
476
477 as a compromise which permits the bundling of messages for multiple recipients
478
479 to  reduce  MTS  traffic.   The  price  is  high  however,  as  a  compromise  on  behalf
480
481 of any member of the discussion group compromises the entire group.  For large
482
483 discussion groups and a bandwidth limited MTS, this price may be worth paying.
484
485 The prototype implementation of the TMA supports multiple recipients but not
486
487 multiple KDS IDs.
488
489
490        Having described this environment for communication, the designs of a KDS
491
492 and  TMA  which  form  the  heart  of  the  TTI  Trusted  Mail  system  are  discussed.
493
494 The  prototype  system  was  developed  on  a  VAX3 -11/780  running  4.2bsd  UNIX4 .
495
496 The system is based on the ansi draft[FIKM] for financial key management,  but
497
498 diverges somewhat in operation owing to the differences between the electronic mail
499
500 (CBMS) and electronic funds (EFT) environments.  Note however that the ansi
501
502 data encryption algorithm[DEA, FIPS46] is used in the current implementation.  A
503
504 public-key cipher system was not considered as the basis for the prototype since,
505
506 to the authors' knowledge, an open standard for a public-key system has yet to be
507
508 adopted by the commercial community.  In contrast, the ansi draft for financial key
509
510 management appears to be receiving wide support from the commercial community.
511
512
513        In the description that follows, a large number of acronyms are employed to
514
515 denote commonly used terms.  In order to aid the reader, these are summarized in
516
517 Table 1.
518
519
520
521 The Key Distribution Service
522
523        The prototype version of the KDS was designed to provide key distribution
524
525 services  for  user  agents  under  both  the  same  or  different  administrations.  As  a
526
527 result,  the  means  by  which  a  trusted  mail  agent  connects  to  a  key  distribution
528
529 server is quite flexible.  For example,  the prototype system supports connections
530
531 via standard terminal lines, dial-ups (e.g., over a toll-free 800 number), UNIX pipes,
532
533 and  over  TCP  sockets[IP, TCP].  In  the  interests  of  simplicity,  for  the  remainder
534
535 of this paper, a TCP/IP model of communication is used.  Initially, a server on a
536
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               ______________________________________________________________________________________________
543
544               __Abbrev.________________________________Term_____________________________Context_______________
545
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____________
581
582
583                                                      Table 1
584
585 ____________________________________Abbreviations_used_in_this_paper__________________________________________________
586
587
588
589 well-known service host in the ARPA Internet community listens for connections
590
591 on a well-known port.5  As each connection is established, it services one or more
592
593 transactions over the lifetime of the session.  When all transactions for a session
594
595 have been made, the connection is closed.  If the necessary locking operations are
596
597 performed by the server to avoid the usual database problems, then more than one
598
599 connection may be in progress simultaneously.  Of course, a time-out facility should
600
601 ________________________________________
602 5  The term well known in this context means that the location of the service is known a priori to
603
604 the clients.
605 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985                8
606
607
608 also be employed to prevent a rogue agent from monopolizing the key distribution
609
610 server.
611
612
613        Once a session has been started, the client (a.k.a. TMA) initiates transactions
614
615 with  the  server  (a.k.a.  KDS).  Each  transaction  consists  of  the  exchange  of  two
616
617 or  three  cryptographic  service  messages  (CSMs):   the  client  sends  a  request,
618
619 the  server  attempts  to  honor  the  request  and  sends  a  response,  and,  if  the
620
621 server  responded  positively,  the  client  then  acknowledges  the  transaction.   By
622
623 exchanging these cryptographic service messages, the KDS and the TMA are able
624
625 to communicate key relationships.  Obviously,  the relationships themselves must
626
627 be transmitted in encrypted form.6  Hence, not only are key relationships between
628
629 two TMAs communicated,  but key relationships between the KDS and the TMA
630
631 are communicated as well.
632
633
634        This leads us to consider the key relationships that exist between a TMA and
635
636 the KDS. A client usually has three keys dedicated for use with the server.  The
637
638 first is the master  key (denoted MK), which has an infinite cryptoperiod,  and is
639
640 rarely used.  This key is distributed manually.  The second is the key-encrypting key
641
642 (denoted KK), which has a shorter cryptoperiod.  Whenever a KK is transmitted
643
644 to the TMA, it is encrypted with the master key.  The third is the authentication
645
646 key (denoted KA), which is used to authenticate transactions that do not contain
647
648 data  keys  (a  count  field  is  also  used  to  avoid  play-back  attacks).   Whenever  a
649
650 KA  is  transmitted  to  the  TMA,  it  is  encrypted  with  the  key-encrypting  key.
651
652 When transactions contain keys, an associated count field is included to indicate
653
654 the  number  of  keys  encrypted  with  the  key-encrypting  key  used.  Although  not
655
656 used by the prototype implementation, a production system would employ audit
657
658 mechanisms to monitor usage histories.
659
660
661        Currently four types of requests are honored by the KDS: two key relationship
662
663 primitives, and two name service primitives.  The type is indicated by the message
664
665 class  (MCL)  of  the  first  cryptographic  service  message  sent  in  the  transaction.
666
667 As  each  message  class  is  discussed,  the  appropriate  datastructures  used  by  the
668
669 KDS  are  introduced.  Space  considerations  prevent  a  detailed  description  of  the
670
671 information exchanged in each transaction.  Appendix B of this paper presents a
672
673 short example of an interaction between the KDS and a TMA.
674
675
676        The first two requests are used to create (or retrieve) key relationships, and
677
678 to destroy key relationships:
679
680
681        The  request  service  initialization  (RSI)  message  class  is  used  to  establish
682
683 a  key-encrypting  key  (KK)  relationship  between  the  TMA  and  another  TMA,  or
684
685 between the TMA and the KDS. As implied by the name, a key-encrypting key is
686
687
688
689 ________________________________________
690 6  Otherwise an adversary could simply impersonate a TMA and ask for the desired key relationships.
691
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
694
695
696 used to cipher keys which are used to cipher data exchanged between peers.  These
697
698 other keys are called data keys (KDs).
699
700
701        The disconnect  service  message (DSM) message class is used to discontinue
702
703 a KK-relationship between the TMA and another TMA, or between the TMA and
704
705 the  KDS.  This  prevents  keys  which  are  felt  to  have  been  compromised,  or  are
706
707 vulnerable  to  compromise,  from  receiving  further  use  in  the  system.  It  should
708
709 be noted that, owing to mail messages (not CSMs) in transit, a discontinued key
710
711 relationship may be needed to decipher the key used to encipher a mail message.
712
713 The prototype KDS supports this capability.
714
715
716        In  addition  to  maintaining  an  MK/KK/KA  triple  for  each  TMA,  the  KDS
717
718 also remembers KK-relationships between TMAs.  The reason for this stems from a
719
720 fundamental difference between the electronic funds transfer and computer-based
721
722 message system worlds.  The KDS assumes that no two arbitrarily chosen TMAs can
723
724 communicate in real-time, and as a result, TMAs do not exchange cryptographic
725
726 service messages.  (See Appendix C for a more detailed discussion.)  This means
727
728 that  when  a  TMA  establishes  a  KK-relationship  with  another  TMA,  the  former
729
730 TMA  may  start  using  the  KK  before  the  latter  TMA  knows  of  the  new  KK-
731
732 relationship.  In fact, it is quite possible for a KK-relationship to be established,
733
734 used, and then discontinued, all unilaterally on the part of one TMA. It is up to
735
736 the  KDS  to  retain  old  cryptographic  material  (possibly  for  an  indefinite  period
737
738 of time), and aid the latter TMA in reconstructing KK-relationships as the need
739
740 arises.  Naturally, discontinued KKs are not used to encode any new information,
741
742 but rather to decode old information.  (Again, refer to Appendix C for additional
743
744 details.)
745
746
747        The other two requests are used to query the directory service aspects of the
748
749 key distribution server:
750
751
752        The  request  user  identification  (RUI)  message  class  is  used  to  identify  a
753
754 subscriber to the KDS. Both the KDS and TMA are independent of any underlying
755
756 mail  transport  system  (MTS).  As  a  result,  a  subscriber  to  the  KDS  is  known
757
758 by  two  unique  attributes:  a  "real-world"  name,  and  a  KDS  identifier  (ID).  The
759
760 user  of  a  mail  system,  or  the  UA,  is  responsible  for  mapping  an  MTS-specific
761
762 address (e.g., MRose@UDEL.ARPA) to the person associated with that maildrop (e.g.,
763
764 ``Marshall T. Rose''              ).  When conversing with the KDS, the TMA uses the KDS
765
766 ID  of  another  user  to  reference  that  person's  TMA.  Since  it  is  inconvenient  to
767
768 remember  the  IDs  (as  opposed  to  people's  names),  the  KDS  provides  the  RUI
769
770 message  class  to  permit  a  TMA  to  query  the  mapping  between  names  and  IDs.
771
772 If the KDS cannot return an exact match, it may respond with a list of possible
773
774 matches (if the identifying information given was ambiguous), or it may respond
775
776 with a response that there is no matching user.
777 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              10
778
779
780        Finally, the request identified user (RIU) message class performs the inverse
781
782 operation:  given a KDS ID, a "real-world" name is returned.  This request is useful
783
784 for disambiguating unsuccessful RUI requests and in boot-strapping a TMA.
785
786
787        The KDS maintains two directories:  a private directory and a public directory.
788
789 The private directory contains all information on all clients to the KDS. The public
790
791 directory  is  a  subset  of  this,  and  is  used  by  the  KDS  when  processing  RUI  and
792
793 RIU requests.7  As a result, certain clients of the KDS may have unlisted IDs and
794
795 names.
796
797
798
799 The Trusted Mail Agent
800
801        The prototype version of the TMA was designed to interface directly to the
802
803 user  agent  in  order  to  maximize  transparency  to  the  user.  In  present  form,  the
804
805 TMA is available as a load-time library under 4.2bsd UNIX, although efforts are
806
807 currently underway to transport the TMA to a PC-based environment.
808
809
810        The software modules which compose the TMA contain a rich set of interfaces
811
812 to the KDS. In addition, the TMA manages a local database, so responses from the
813
814 KDS may be cached and used at a later time.  In all cases, the KDS is consulted
815
816 only if the information is not present in the TMA database, or if the information
817
818 in question has expired (e.g., KK-relationships).  This caching activity minimizes
819
820 connections to the KDS. Although connections are relatively cheap in the ARPA
821
822 Internet, substantial savings are achieved for PCs which contact the KDS over a
823
824 public phone network (dial-up) connection.
825
826
827        The  TMA  performs  mappings  between  pairs  of  the  following  objects:  user
828
829 names, KDS IDs, and MTS addresses.  The TMA considers all trusted mail agents,
830
831 including itself, as a user name, KDS ID, and one or more MTS addresses.  Although
832
833 the  TMA  does  not  interpret  addresses  itself,  in  order  to  simplify  mail  handling,
834
835 the TMA remembers the relationship between these objects so the user enters this
836
837 information only once.
838
839
840        Initially, when a TMA is booted, the user supplies it with the master key and
841
842 the user's KDS ID. Both of these quantities are assigned by the personnel at the
843
844 key distribution center, and subsequently transmitted to the user via an alternate,
845
846 bonded service.8  The TMA connects with the KDS and verifies its identity.  From
847
848 this point on, the TMA manages its KK-relationships between the KDS and other
849
850 TMAs without user intervention.
851
852
853        The current implementation of the TMA assumes a "general memo framework"
854
855 in the context of the Standards for ARPA Internet Text Messages[DCroc82]:
856
857
858
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
863
864
865            1.  A message consists of two parts:  the headers and the body.  A blank line
866
867                separates the headers from the body.
868
869
870            2.  Each  (virtual)  line  in  the  headers  consists  of  a  keyword/value  pair,
871
872                in  which  the  keyword  is  separated  from  the  value  by  a  colon  (:).
873
874                The  headers  are  rigorously  structured  in  the  sense  that  they  contain
875
876                addressing and other information useful to a user agent.
877
878
879            3.  The  body  is  freely  formatted  and  must  not  be  meaningful  to  a  user
880
881                agent.  However,  as  will  be  seen  momentarily,  the  body  of  encrypted
882
883                messages must have an initial fixed format which the TMA enforces.
884
885
886 This  format  is  widely  called  "822"  after  the  number  assigned  to  the  defining
887
888 report[DCroc82].9
889
890
891        To support the cipher activities described below, the TMA contains internal
892
893 routines  to  perform  the  following  DES  functions:  electronic  code  book  (ECB)
894
895 for  key  encryption,  cipher  block  chaining  (CBC)  for  mail  message  encryption,
896
897 checksumming (CKS) for mail message and CSM authentication.  Readers interested
898
899 in these different modes of operation for the DES should consult [FIPS81].
900
901
902 Encrypting Mail
903
904        To  encipher  a  message,  the  method  used  is  a  straightforward  adaptation
905
906 of the standard encrypting/authentication techniques (though the terminology is
907
908 tedious).  Consider the following notation:
909
910
911      ax (s):   the  checksum  of  the  string  s  using  the  key  x  (DEA  checksumming
912
913                authentication)
914
915
916   ax+y  (s):   the  checksum  of  the  string  s  using  the  exclusive-or  of  the  two  keys  x
917
918                and y
919
920
921      ex (y):   the encryption of the key y  using the key x (DEA electronic code book
922
923                encryption)
924
925
926    ex;y (s):   the encryption of the string s using the key x and initialization vector
927
928                y (DEA cipher block chaining encryption)
929
930
931            h:  the headers of the message
932
933
934        and,
935
936
937            b:  the body of the message
938
939
940
941 ________________________________________
942 9  Although an 822-style framework is employed by the TMA prototype, the 822 ``Encrypted:''
943
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
948
949
950 For each message to be encrypted, a data key, initialization vector, authentication
951
952 key (KD/IV/KA) triple is generated by a random process.  (It goes without saying
953
954 that the integrity of the system depends on the process being random).  Then, for
955
956 each  user  to  receive  a  copy  of  the  encrypted  message,  the  following  actions  are
957
958 taken:
959
960
961        First,  the  headers  of  the  message  are  output  in  the  clear.  Then,  a  banner
962
963 string, i, is constructed and placed at the beginning of the body of the message:
964
965
966            ENCRYPTED  MESSAGE:  TTI  TMA
967
968
969 which  identifies  the  message  as  being  encrypted  by  the  TTI  TMA.  Following
970
971 the  banner  string  is  a  structure,  m,  which  takes  on  the  syntax  and  most  of  the
972
973 semantics of a cryptographic service message:
974
975
976             MCL/      MAIL
977
978             RCV/      rcvid
979
980             ORG/      orgid
981
982              IDK/     kkid
983
984               KD/     ekk (ka)
985
986               KD/     ekk (kd)
987
988                IV/    ekd (iv)
989
990             MIC/      aka (b)
991
992            MAC/       akd+ka   (m)
993
994
995 After  this,  the  encrypted  body  is  output,  ekd;iv (b).  In  short,  the  entire  output
996
997 consists of
998
999                                            h + i + m + ekd;iv (b):
1000
1001
1002
1003        The purpose of the structure m is many-fold.  The MCL field indicates the
1004
1005 structure  m's  type;  currently  only  the  type  MAIL  is  generated  and  understood.
1006
1007 The RCV and ORG fields identify the intended recipient of the message and the
1008
1009 originator.  The IDK field identifies the key-encrypting key, KK, used to encrypt
1010
1011 the next two fields.  The first KD field has the encrypted authentication key, KA,
1012
1013 used  to  calculate  the  MIC  of  the  plaintext  of  the  body  of  the  message.   After
1014
1015 the body of the message is deciphered, aka (b) is calculated and compared to the
1016
1017 value of the MIC field.  Hence, the MIC field authenticates the message body.  The
1018
1019 second KD field has the encrypted data encrypting key, KD, which along with the
1020
1021 encrypted initialization vector in the IV field was used to generate the ciphertext
1022
1023 of the body.  Finally, the MAC field authenticates the m structure itself.  The use
1024
1025 of a data key, initialization vector, authentication key (KD/IV/KA) triple permits
1026
1027 us to perform key distribution in a hierarchical fashion and allows the system to
1028
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
1031
1032
1033         The TMA provides three primary interfaces to a UA to send encrypted mail:
1034
1035  the  first  takes  a  file-descriptor  to  a  message  and  returns  a  structure  g  (called  a
1036
1037  group) describing the ciphertext version of the body (this structure contains a KD,
1038
1039  IV,  and  KA  generated  at  random,  along  with  a  file-descriptor  to  the  plaintext
1040
1041  headers, a file-descriptor to the ciphertext body, and the checksum of the plaintext
1042
1043  body);  the  second  takes  a  user  entry  (or  MTS  address)  and  g,  and  returns  a
1044
1045  file-descriptor to the encrypted message for that user (or MTS address); the third
1046
1047  takes g  and performs clean-up operations.  The chief advantage to this scheme of
1048
1049  encryption is that if the message is to be sent to more than one recipient, then the
1050
1051  MIC and the encrypted body need only be calculated once, since the KD, IV, and
1052
1053  KA  remain  constant  (only  the  KK's  change  with  each  recipient,  hence  for  each
1054
1055  copy of the encrypted message, only the structure m need be re-calculated).
1056
1057
1058         There are, however, a few subtleties involved:  first_, the MTS usually accepts
1059
1060  only 7-bit characters, so the encrypted text is exploded to consist of only printable
1061
1062  characters;10  second____,  since  the  MTS  may  impose  limits  on  the  length  of  a  line,
1063
1064  each  line  of  output  is  limited  to  64  characters;  and,  third___,  since  the  body  may
1065
1066  require  trailing  padding,  during  encryption  one  last  unit  of  8  bytes  is  written
1067
1068  (and encrypted), naming the number of characters (presently, nulls) padded in the
1069
1070  previous 8 bytes (0 : : :7).
1071
1072
1073  Decrypting Mail
1074
1075         To decipher a message, the method is also straightforward:  The headers are
1076
1077  output in the clear.  The banner string is essentially ignored, and the structure m
1078
1079  is consulted to identify the correct key-encrypting key.  The TMA checks to see if
1080
1081  it knows of that KK. If not,  it asks the KDS to supply it.  From that point,  the
1082
1083  KA, KD, and IV are deciphered.  The m structure is then authenticated.  With the
1084
1085  correct key,  the remainder of the body is deciphered,  and all except for the last
1086
1087  16 bytes are output.  The last 8 bytes indicate how many of the previous 8 bytes
1088
1089  should be output.  So, the appropriate number of bytes is output, and the plaintext
1090
1091  body is authenticated and compared to the MIC. Needless to say, as the body is
1092
1093  deciphered, it is imploded back to 8-bit characters and lines are restored to their
1094
1095  previous  lengths.  To  indicate  that  the  message  was  correctly  deciphered,  a  new
1096
1097  header of the form
1098
1099
1100             X-KDS-ID:  orgid  (originator's  name)
1101
1102
1103  is appended to the headers of the message.  Note that this provides an authentication
1104
1105  mechanism.  Note, further, that the UA did not have to know the identity of the
1106
1107  sender of the message.
1108
1109
1110
1111  ________________________________________
1112 10  As a rule, in all CSMs, when encrypted information is transmitted, it is exploded after encryption
1113
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
1116
1117
1118  Modifications to MH
1119
1120         MH  is  a  public  domain  UA  for  UNIX,  which  is  widely  used  in  dealing  with
1121
1122  both a large number of electronic mail application and a large number of messages.
1123
1124  Although this document does not intend to describe MH, parts of the system are
1125
1126  described  as  they  relate  to  the  TMA.  Readers  interested  in  MH  should  consult
1127
1128  either the user's manual[MRose85a] for a detailed description, or [MRose85d] for a
1129
1130  higher-level description.
1131
1132
1133         To modify MH in order to make use of a TMA, three programs were changed
1134
1135  (with  a  high  degree  of  transparency  to  the  user),  and  two  new  programs  were
1136
1137  introduced.
1138
1139
1140         In  MH,  when  a  user  wishes  to  send  a  composed  draft  (which  may  be  an
1141
1142  entirely new message, a re-distribution of a message, a forwarding of messages, or
1143
1144  a reply to a message), the user invokes the send program.  This program performs
1145
1146  some minor front-end work for a program called post which actually interacts with
1147
1148  the MTS. A new option to the send and post programs, the `-encrypt'        switch, is
1149
1150  introduced.  If the user indicates
1151
1152
1153             send -encrypt
1154
1155
1156  then post encrypts the messages it sends.
1157
1158
1159         When  sending  an  encrypted  message,  post  first  checks  that  each  addressee
1160
1161  has a mapping to a KDS ID during address verification.  Then, instead of batching
1162
1163  all addresses for a message in a single posting transaction, for each addressee, post
1164
1165  consults  the  TMA  for  the  appropriately  encrypted  text  and  posts  that  instead.
1166
1167  (Appendix A discusses the reasons for this more fully.)  Hence, assuming the user
1168
1169  has  established  mappings  between  MTS  addresses  and  KDS  IDs,  the  TMA  does
1170
1171  all the work necessary to encrypt the message,  including contacting the KDS as
1172
1173  necessary.11
1174
1175
1176         In MH, when a user is notified that new mail has arrived, the inc program is
1177
1178  run.  As each message is incorporated into the user's message handling area, a scan
1179
1180  (one-line) listing of the message is generated.
1181
1182
1183         By default, the inc program upon detecting one or more encrypted messages,
1184
1185  after the scanning process, asks the TMA to decipher the message, and if successful,
1186
1187  scans the deciphered messages.  This action can be inhibited with the `-nodecrypt'
1188
1189  switch.  Hence,  if  the  user  wishes  to  retain  messages  in  encrypted  form,  inc  can
1190
1191  be told to note the presence of encrypted messages, but otherwise not to process
1192
1193  them.  By using the MH user profile mechanism, inc can be easily customized to
1194
1195  ________________________________________
1196 11  Once  the  TMA  establishes  a  connection  to  the  KDS,  it  retains  that  connection  until  the  UA
1197
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
1202
1203
1204 reflect the user's tastes.  Again, the actions of the TMA are transparent to the user.
1205
1206 In fact, if encrypted mail is received from users unknown to the TMA, it queries
1207
1208 the KDS as to their identity prior to retrieving the KK-relationship.
1209
1210
1211        If  inc  fails  to  decrypt  a  message  for  some  reason,  or  if  inc  was  told  not  to
1212
1213 decrypt a message, the decipher program can be used.  This simple program merely
1214
1215 deciphers each message given in its argument list.  The decipher program can be
1216
1217 given the `-insitu'        switch, which directs it to replace the ciphertext version of
1218
1219 the message with the plaintext version;  or, the `-noinsitu'         switch can be used
1220
1221 indicating that the ciphertext version of the message should be left untouched and
1222
1223 the plaintext version should be listed on the standard output.
1224
1225
1226        Finally, the tma program is used to manipulate the TMA database, containing
1227
1228 commands to boot the database, add new users to the database, and to establish
1229
1230 mappings between addresses and users in the TMA database.  This program can
1231
1232 also be used to disconnect KKs between other TMAs,  and the KK/KA between
1233
1234 itself and the KDS.
1235
1236
1237        Appendix A of this paper contains a transcript of an MH session.
1238
1239
1240
1241 Remarks
1242
1243        We now consider the merit of the system described.  After presenting some
1244
1245 of the basic strengths of the system and a few unresolved questions, the discussion
1246
1247 centers on the simplifying assumptions made by the system, and how these can be
1248
1249 defended in a non-military environment.
1250
1251
1252 Strengths
1253
1254        It  can  be  argued  that  the  prototype  system  (and  the  augmented  model  in
1255
1256 which it finds its basis) present many strengths.
1257
1258
1259        Perhaps the most important is the high-level of independence from the MTS
1260
1261 enjoyed  by  the  system.   As  a  result,  since  the  TMA  does  not  interact  directly
1262
1263 with  the  MTS,  it  can  be  made  to  be  completely  free  from  any  MTS-specific
1264
1265 attributes,  such  as  naming,  addressing,  and  routing  conventions.  Furthermore,
1266
1267 when interfacing a Trusted Mail system, no modifications need be made to the MTS
1268
1269 or local MTA.
1270
1271
1272        In addition to the systems-level advantage to this scheme, users of the system
1273
1274 profit as well, since many disjoint MTSs can be employed by a user with a single
1275
1276 TMA. This reduces the number of weaknesses in the system and allows a user to
1277
1278 keep a single database of "trusted" correspondents.  It should also make analysis
1279
1280 and verification of the TMA easier.
1281
1282
1283        Of course from the user-viewpoint, once the TMA has been initially booted,
1284
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
1287
1288
1289  of  cryptographic  material  (given  proper  construction  and  maintenance  of  the
1290
1291  TMA), but it relieves the user of a tedious and error-prone task.
1292
1293
1294         Finally, although the KDS described herein is used to support Trusted Mail,
1295
1296  other applications which require key management, could employ the services offered
1297
1298  by the key distribution center.
1299
1300
1301  Open Questions
1302
1303         At  present,  there  are  many  restrictions  on  the  prototype  implementation
1304
1305  described.   Some  of  these  result  from  that  fact  that  the  implementation  is  a
1306
1307  prototype  and  not  a  production  system.   Others  deal  with  more  fundamental
1308
1309  issues.
1310
1311
1312         In terms of the TMA, the expiration delay for keys is hard-wired in; it should
1313
1314  be user-settable.  In the prototype version, the KK and KA with the KDS are good
1315
1316  for  2  days  or  10  uses  (whichever  comes  first),  while  a  KK  for  use  with  another
1317
1318  TMA is good for 1 day or 5 uses.  In actual practice, keys with long cryptoperiods
1319
1320  might be good for 6 months or 100 uses, while keys with short cryptoperiods might
1321
1322  be good for 1 month or 25 uses.  The choice of actual values is an open question
1323
1324  beyond the scope of prototype system.12   In many respects, this issue is a classic
1325
1326  trade-off:  with  relatively  small  cryptoperiods,  an  adversary  has  less  chance  of
1327
1328  breaking a key, but with longer cryptoperiods less connections have to be made to
1329
1330  the key distribution server.
1331
1332
1333         A  fundamental  issue,  owing  to  differences  between  the  EFT  and  CBMS
1334
1335  environments, is that the KDS implements only a subset of the ansi draft and the
1336
1337  semantics of certain operations have changed somewhat.  It would be nice to unify
1338
1339  the CBMS and EFT views of a key distribution center (in the former environment,
1340
1341  the center is called a KDC, while in the latter environment,  the center is known
1342
1343  as  a  CKD).  Appendix  C  of  this  paper  discusses  the  differences  between  the  two
1344
1345  perspectives in greater detail.
1346
1347
1348         At  present,  the  relationship  between  errors  in  the  TMA  and  the  posting
1349
1350  process is an open question.  For example, if an address doesn't have a mapping in
1351
1352  the TMA database, post treats this as an address verification error.  This prevents
1353
1354  the draft from being posted.  The philosophy of the UA is unclear at this point,
1355
1356  with respect to how recovery should occur.  A second area, also in question, deals
1357
1358  with the way in which plaintext and ciphertext versions of a message are present
1359
1360  in a system.  Clearly,  it is a bad idea to make both versions available,  but since
1361
1362  the TMA doesn't try to concern itself with first party observation, there seems to
1363
1364  be little possibility of preventing this behavior.  The best that can be done, at this
1365
1366  stage, is simply to choose a consistent policy that user's should attempt to adhere
1367
1368
1369
1370  ________________________________________
1371 12  The current values were chosen by guess work.  Although not necessarily technically sound, the
1372
1373  small numbers were very good for debugging purposes.
1374 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              17
1375
1376
1377 to.  The software can help somewhat in implementing this policy, but it certainly
1378
1379 can't circumvent the user.
1380
1381
1382        The prototype is built on the assumption that a single key distribution server
1383
1384 is present.  Since the ansi draft[FIKM] makes provisions for key translation centers,
1385
1386 the Trusted Mail prototype should perhaps be made to operate in a more diverse
1387
1388 environment.  Until the issues become clearer, this remains open.
1389
1390
1391        Finally, for distribution lists, a large number of people would need to share
1392
1393 the same KDS ID. The current implementation doesn't support this.  Each TMA
1394
1395 database  is  for  a  particular  ID.  A  user  with  multiple  IDs  would  need  multiple
1396
1397 databases, or the database should be re-organized.
1398
1399
1400 Weaknesses
1401
1402        As pointed out earlier, this prototype system situates itself in a commercial,
1403
1404 not  military,  environment.   With  respect  to  this  decision,  several  aspects  of
1405
1406 the  system  are  now  discussed,  which  we  feel  are  acceptable  in  a  commercial
1407
1408 environment, but which would be considered weaknesses in a military environment:
1409
1410
1411    1.  Traffic Flow
1412
1413        The  prototype  TMA  makes  no  attempt  whatsoever  to  prevent  or  confuse
1414
1415        traffic analysis by augmenting traffic flow.
1416
1417
1418    2.  The Database of KDS Subscribers
1419
1420        Since  information  returned  by  the  request  user  identification  (RUI)  and
1421
1422        request  identified  user  (RIU)  MCLs  are  returned  in  the  clear,  this  allows
1423
1424        an  adversary  to  ascertain  subscribers  to  the  KDS,  and  perhaps  deduce
1425
1426        some information about the system.  Without knowledge of the master key
1427
1428        however, an adversary could not impersonate a subscriber though.  Still, in
1429
1430        the  military  sense,  this  is  a  weakness.  However,  all  this  assumes  that  the
1431
1432        database maintained by the KDS accurately reflects the real-world.
1433
1434
1435    3.  Multiple Recipients
1436
1437        It is possible, though not proven to the authors' knowledge, that the scheme
1438
1439        used to avoid encrypting the body of a message more than once for multiple
1440
1441        recipients  might  permit  one  of  the  recipients  who  is  also  an  adversary  to
1442
1443        compromise the key relationship between the sender and another recipient.
1444
1445
1446        The scenario goes like this:  When a message is being prepared for encryption,
1447
1448        a single KD/IV/KA triple is generated to encrypt the body.  Since the sender
1449
1450        has  a  different  key  relationship  with  each  recipient,  each  message  sent  is
1451
1452        different,  since the structure m depends not only on the KD/IV/KA triple
1453
1454        but also on the key relation between the sender and a particular recipient.
1455
1456        Now suppose that one of the recipients, r1 , in addition to receiving the copy
1457
1458        of  the  message  meant  for  him/her  also  intercepts  a  copy  of  the  message
1459
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
1462
1463
1464        the plaintext and ciphertext version of the body, the plaintext version of the
1465
1466        KD/IV/KA triple, and the ciphertext version of the KD/IV/KA triple that
1467
1468        was generated using the key relationship between the sender and the recipient
1469
1470        r2 .  The  question  is:  can  r1  now  deduce  the  key  relationship  between  the
1471
1472        sender and r2 ?
1473
1474
1475        If so, then the way that the TMA attempts to minimize the use of encryption
1476
1477        resources is a weakness.  But,  even if this is possible,  given relatively short
1478
1479        cryptoperiods  for  key  relationships  between  TMA  peers,  this  becomes  a
1480
1481        non-problem.
1482
1483
1484    4.  Discussion Groups
1485
1486        As discussed earlier, the proposed method of associating a single KDS ID with
1487
1488        the membership of a discussion group does introduce a significant weakness
1489
1490        for  the  security  of  messages  sent  to  the  discussion  group.  Since  the  TMA
1491
1492        does  not  assume  a  general  broadcast  facility,  it  appears  that  there  are  no
1493
1494        good solutions to the problem of discussion group traffic.  Of course, it is easy
1495
1496        enough to simply send to each member of the group.
1497
1498
1499        For  the  sake  of  argument,  let's  assume  that  the  discussion  group  has  n
1500
1501        members.  Now,  since  a  different  key  relationship  would  exist  between  the
1502
1503        sender and each of the n recipients,  the structure m would be different for
1504
1505        each  recipient  and  so  a  different  message  would  have  to  be  sent  to  each
1506
1507        recipient.  To make matters worse,  if one rejects the way the TMA handles
1508
1509        multiple  recipients,  not  only  does  the  MTS  get  burdened  with  n  different
1510
1511        messages, but the sender's TMA gets burdened by having to encrypt the body
1512
1513        of the message n times.  For meaningful values of n (say on the order of 500,
1514
1515        or even 25), the amount of resources required for any trusted discussion group
1516
1517        are simply too costly.
1518
1519
1520 Compromises, Compromises
1521
1522        Each  of  the  possible  weaknesses  discussed  above  represent  a  compromise
1523
1524 between the expense of the system and the level of security it can provide.
1525
1526
1527        The  first  two  areas,  if  addressed  by  the  TMA,  could  result  in  much  less
1528
1529 background information being available to an adversary.  In an application where it
1530
1531 is important that an adversary not know who is talking to whom, or who can talk
1532
1533 at all,  this is very important.  It is the authors' position that in the commercial
1534
1535 environment, this issue is not paramount.  By ignoring the issue of traffic flow, the
1536
1537 TMA has a lot less work to do and the MTS is kept clear of "useless" messages.
1538
1539 By keeping the information returned by the RUI and RIU MCLs in the clear, the
1540
1541 complexity of the TMA is significantly reduced.
1542
1543
1544        The  second  two  areas,  if  addressed  by  the  TMA,  could  result  in  a  lesser
1545
1546 probability  of  traffic  being  deciphered  by  an  adversary.   Regardless  of  the
1547
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
1550
1551
1552 that  the  compromise  made  by  the  TMA  in  these  two  issues  is  not  substantial,
1553
1554 and  does  not  result  in  an  explicit  weakness  when  a  message  is  sent  to  multiple
1555
1556 recipients (note that when there is only a single recipient of a message, these two
1557
1558 policies  can  not  introduce  weaknesses).  In  return,  efficient  use  can  be  made  of
1559
1560 both the MTS and the TMA when messages are being sent to multiple recipients.
1561
1562 Given scarce resources or large numbers of recipients, this approach may prove to
1563
1564 be quite winning.
1565
1566
1567        Of course, much work remains to be done to prove the success of the TMA in
1568
1569 all four of these areas.
1570
1571
1572
1573 Acknowledgements
1574
1575        The  prototype  implementation  described  herein  utilizes  a  public  domain
1576
1577 implementation of the DES algorithm[DEA] which was originally implemented by
1578
1579 James J. Gillogly in May, 1977 (who at that time was with the Rand Corporation,
1580
1581 and  is  now  affiliated  with  Gillogly  Software).   Interfaces  to  Dr.  Gillogly's
1582
1583 implementation were subsequently coded by Richard W. Outerbridge in September,
1584
1585 1984 (who at that time was with the Computer Systems Research Institute at the
1586
1587 University of Toronto, and is now affiliated with Perle Systems, Incorporated).
1588
1589
1590        The  authors  would  like  to  acknowledge  Dennis  Branstad,  Elaine  Barker,
1591
1592 and  David  Balensen  of  the  National  Bureau  of  Standards  for  their  comments
1593
1594 on  the  prototype  system  and  insights  on  the  ANSI  draft[FIKM].  In  particular,
1595
1596 Dr. Branstad originally suggested the method used for encrypting a single message
1597
1598 for multiple recipients under different keys.
1599
1600
1601        The authors (and all those who have read this paper) would like to thank Willis
1602
1603 H. Ware of the Rand Corporation, and Jonathon B. Postel of the USC/Information
1604
1605 Sciences  Institute.  Their  extensive  comments  resulted  in  a  much  more  readable
1606
1607 paper.  In  addition,  the  authors  would  like  to  thank  Dr.  Stephen  P.  Smith  and
1608
1609 Major Douglas A. Brothers for their insightful comments.
1610 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              20
1611
1612
1613                                                  References
1614
1615
1616
1617 [DCroc82]        D.H.  Crocker.   Standard  for  the  Format  of  ARPA  Internet  Text
1618
1619                  Messages.  Request  for  Comments  822.  ARPA  Internet  Network
1620
1621                  Information Center (NIC), SRI International (August, 1982).
1622
1623
1624
1625 [DEA]            Data  Encryption  Algorithm,  X3.92-1981,  American  National
1626
1627                  Standards Institute, 1981.
1628
1629
1630
1631 [FIKM]           Financial Institution Key Management, X9.17-198_  (draft), American
1632
1633                  National Standards Institute, 198_.
1634
1635
1636
1637 [FIPS46]         Data Encryption Standard, Federal Information Processing Standards,
1638
1639                  Publication 46, 1977.
1640
1641
1642
1643 [FIPS81]         DES Modes of Operation, Federal Information Processing Standards,
1644
1645                  Publication 81, 1980.
1646
1647
1648
1649 [IP]             Internet  Protocol.  Request  for  Comments  791  (milstd  1777).
1650
1651                  Appearing in Internet Protocol Transition Workbook, ARPA Internet
1652
1653                  Network Information Center (NIC), SRI International, 1981.
1654
1655
1656
1657 [LLamp82]        L. Lamport, R. Shostak, M. Pease.  The Byzantine Generals Problem.
1658
1659                  ACM Transactions on Programming Languages and Systems 4  (July,
1660
1661                  1982), 382-401.
1662
1663
1664
1665 [MRose85a]       M.T. Rose,  J.L. Romine.  The Rand MH Message Handling System:
1666
1667                  User's Manual. UCI Version. Department of Information and Computer
1668
1669                  Science, University of California, Irvine (January, 1985).
1670
1671
1672
1673 [MRose85d]       M.T. Rose, E.A. Stefferud, J.N. Sweet.  MH: A Multifarious User
1674
1675                  Agent. Computer Networks (to appear).
1676
1677
1678
1679 [TCP]            Transmission Control Protocol. Request for Comments 793 (milstd
1680
1681                  1778).  Appearing  in  Internet  Protocol  Transition  Workbook,  ARPA
1682
1683                  Internet Network Information Center (NIC), SRI International, 1981.
1684
1685
1686
1687 [VVoyd83]        V.L.  Voydock,  S.T.  Kent.   Security  Mechanisms  in  High-Level
1688
1689                  Network Protocols. Computing Surveys 15, 2 (June, 1983), 135-171.
1690
1691
1692
1693 [X.400]          Message  Handling  Systems:   System  Model-Service  Elements,
1694
1695                  Recommendation  X.400,  International  Telegraph  and  Telephone
1696
1697                  Consultative Committee (CCITT).
1698 \f  Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              21
1699  ______________________________________________________________________________________________________________________
1700
1701   1    %  tma  -add  -user  "UCI  Portal"  uci@udel-dewey
1702   2    3:  "UCI  Portal"
1703   3         uci@udel-dewey
1704   4
1705   5    %  comp
1706   6    To:  uci
1707   7    Fcc:  +outbox
1708   8    Subject:  test  message
1709   9    --------
1710 10     mumble,  mumble.
1711 11     ^D
1712 12
1713 13     What  now?  send  -encrypt
1714 14      --  Address  Verification  --
1715 15        --  Local  Recipients  --
1716 16        uci:  address  ok
1717 17      --  Address  Verification  Successful  --
1718 18      --  Posting  for  All  Recipients  --
1719 19        --  Local  Recipients  --
1720 20        uci:  address  ok
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
1726
1727
1728                                                      Figure 4
1729
1730  __________________________________________Sending_Encrypted_Mail______________________________________________________
1731
1732
1733
1734  Appendix A: An MH Session
1735
1736         In  the  following,  the  user  ``Marshall T. Rose''                logged  onto  host
1737
1738  ``udel-dewey''          , wishes to send a message to a user known as the ``UCI Portal''
1739
1740  (a system maintenance account).  As shown in Figure 4, line 1, the user first estab-
1741
1742  lishes a mapping between the name ``UCI Portal''           and the address uci@udel-
1743
1744  dewey.  Once this mapping is performed, it remains in effect until the user indicates
1745
1746  otherwise  to  the  TMA.  When  the  tma  program  is  invoked,  it  consults  the  TMA
1747
1748  database to see if that user is known.  If not,  it contacts the KDS to ask for the
1749
1750  KDS ID associated with the user.  If the response is successful (in this case,  the
1751
1752  KDS ID is ``3''    ), then the TMA updates its database.  The tma program indicates
1753
1754  in its output the KDS ID associated with the user, along with all known addresses
1755
1756  (in this case, only one).  So, once the name to address mapping has been described
1757
1758  the user, the user agent, MH, deals only with the address, while the trusted mail
1759
1760  agent deals with the name and KDS ID aspects of the user.
1761
1762
1763         Next, the comp program is invoked to compose a new draft on line 5.  The
1764
1765  user addresses the local user ``uci''      in the To:  field, and indicates that a plaintext
1766
1767  copy  should  be  kept  in  the  folder  ``+outbox''       .  After  entering  the  subject  and
1768
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 ______________________________________________________________________________________________________________________
1772
1773  1    %  inc
1774  2    Incorporating  new  mail  into  inbox...
1775  3
1776  4        1+E02/28  0227-EST  mrose                   test  message   <<ENCRYPTED  MESSAGE:  TTI
1777  5
1778  6    Incorporating  encrypted  mail  into  inbox...
1779  7
1780  8        1+  02/28  0227-EST  mrose                   test  message   <<mumble,  mumble.  >>
1781
1782
1783                                                     Figure 5
1784
1785 ________________________________________Receiving_Encrypted_Mail______________________________________________________
1786
1787
1788
1789 user  directs  MH  to  send  the  draft  in  encrypted  form.   The  resulting  output  is
1790
1791 verbose (a default for send for this user) but instructive.  Initially, all addresses in
1792
1793 the draft are verified on lines 14 to 17.  Two forms of verification occur:  first, the
1794
1795 MTS is asked to verify the address as much as possible.  For local addresses, the
1796
1797 MTS decides if the name has a maildrop associated with it.  For remote addresses,
1798
1799 the MTS decides if the host is known to it.  The second type of verification occurs
1800
1801 with the TMA. For all addresses, the TMA is asked if it can find a mapping from
1802
1803 the address to a KDS ID.
1804
1805
1806        The  reason  MH  goes  to  all  this  trouble  is  a  philosophical  issue.  Since  the
1807
1808 copy of the encrypted draft is different for each recipient, post tries to verify that
1809
1810 all  recipients  can  be  successfully  posted  prior  to  actually  posting  the  different
1811
1812 ciphertext versions of the draft.  This behavior is not optimal in terms of cycles,
1813
1814 but is perhaps "correct" from a UA perspective.
1815
1816
1817        Finally, the draft is actually posted, and the folder carbon-copy is filed.
1818
1819
1820        Some time later, the UCI portal is informed that new mail has arrived.  As
1821
1822 shown  in  Figure  5,  the  inc  program  is  run.  The  ``E''    prior  to  the  date  of  the
1823
1824 message indicates that inc has detected the message to be encrypted.  Since the
1825
1826 user did not inhibit inc from deciphering the message, it proceeds to do so.
1827
1828
1829        Finally,  it  may  be  instructive  to  see  what  the  encrypted  message  looked
1830
1831 like  when  it  was  delivered  to  the  portal's  maildrop,  and  the  final  message  after
1832
1833 deciphering.  Figures 6 and 7 show these respectively.  In particular, note that the
1834
1835 ``X-KDS-ID:''          field has been introduced in Figure 7 after successfully deciphering
1836
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 ______________________________________________________________________________________________________________________
1840
1841 Received:  From  localhost.DELAWARE  by  udel-dewey.DELAWARE  id  a022713
1842               ;28  Feb  85  2:27  EST
1843 To:  uci@udel-dewey
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
1848
1849
1850 ENCRYPTED  MESSAGE:  TTI  TMA
1851 (
1852 MCL/MAIL
1853 RCV/3
1854 ORG/17
1855 IDK/850228072730
1856 KD/e36813a3882eebd1
1857 KD/fa8b8ac657476669
1858 IV/Ef9d283565431b103
1859 MIC/fdb927fb
1860 MAC/50e9de30
1861 )
1862 a13774f652d844762c4fc03c2f4e201b9d2f57eadb00546c
1863
1864
1865                                                     Figure 6
1866
1867 ______________________________________Message_Prior_to_Decryption_____________________________________________________
1868
1869 ______________________________________________________________________________________________________________________
1870 Received:  From  localhost.DELAWARE  by  udel-dewey.DELAWARE  id  a022713
1871               ;28  Feb  85  2:27  EST
1872 To:  uci@udel-dewey
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)
1878
1879
1880 mumble,  mumble.
1881
1882
1883                                                     Figure 7
1884
1885 ________________________________________Message_After_Decryption______________________________________________________
1886
1887
1888
1889 Appendix B: A Short Exchange
1890
1891        The simple nature of the interchange between the user and MH in Appendix A
1892
1893 completely hides any interactions between the TMA and the KDS. Let us briefly
1894
1895 examine  an  exchange  that  might  occur  after  the  destination  TMA  receives  the
1896
1897 message shown in Figure 6.
1898
1899
1900        To  begin,  the  TMA  must  ascertain  what  it  knows  about  the  sender  of  the
1901
1902 message,  which  claims  to  have  a  KDS  ID  of  17.   That  is,  the  TMA  must  first
1903
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  ______________________________________________________________________________________________________________________
1907
1908   1    <---  (
1909   2    <---  MCL/RIU
1910   3    <---  RCV/17
1911   4    <---  ORG/3
1912   5    <---  KDC/TTI
1913   6    <---  EDC/1a1fbbba
1914   7    <---  )
1915   8    --->  (
1916   9    --->  MCL/RTR
1917 10     --->  RCV/17
1918 11     --->  ORG/3
1919 12     --->  CTA/1
1920 13     --->  USR/"Marshall  T.  Rose"
1921 14     --->  KDC/TTI
1922 15     --->  MAC/2ebde134
1923 16     --->  EDC/96b183de
1924 17     --->  )
1925 18     <---  (
1926 19     <---  MCL/ACK
1927 20     <---  RCV/17
1928 21     <---  ORG/3
1929 22     <---  KDC/TTI
1930 23     <---  EDC/59a8ddcc
1931 24     <---  )
1932
1933
1934                                                      Figure 8
1935
1936  __________________________________________Ascertaining_the_Sender_____________________________________________________
1937
1938
1939
1940  suppose that this purported subscriber is unknown to the TMA. In this case, the
1941
1942  first step it must undertake is to ascertain the validity of this subscriber.
1943
1944
1945         As  shown  in  Figure  8  on  lines  1-7,  the  TMA  does  this  by  establishing  a
1946
1947  connection  to  the  KDS  and  issuing  an  request  identified  user  (RUI)  MCL.13  If
1948
1949  the response by the KDS is positive,  the TMA will use the information returned
1950
1951  when generating the ``X-KDS-ID:''           field for authentication.  The response CSM
1952
1953  returned  by  the  KDS  includes  an  authentication  checksum  (the  MAC  field  on
1954
1955  line 15) and a transaction count (the CTA field on line 12) to prevent spoofing by a
1956
1957  process pretending to be the KDS. The TMA then acknowledges that the response
1958
1959  from the server was acceptable on lines 18-24.
1960
1961
1962         The next step is to ascertain the actual key relationship used to encrypt the
1963
1964  structure  m,  which  appears  after  the  identifying  string.  The  TMA  consults  the
1965
1966
1967  ________________________________________
1968 13  In point of fact, the very first thing that the TMA does after connecting to the KDS is verify
1969
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  ______________________________________________________________________________________________________________________
1977
1978   1    <---  (
1979   2    <---  MCL/RSI
1980   3    <---  RCV/17
1981   4    <---  ORG/3
1982   5    <---  IDK/850228072730
1983   6    <---  KDC/TTI
1984   7    <---  SVR/KD.IV.KK
1985   8    <---  EDC/83679e14
1986   9    <---  )
1987 10     --->  (
1988 11     --->  MCL/RTR
1989 12     --->  RCV/17
1990 13     --->  ORG/3
1991 14     --->  KK/095f9d6b87f57871
1992 15     --->  CTA/2
1993 16     --->  KD/527fbb5593efd318
1994 17     --->  KD/1dcab338be1e7a09
1995 18     --->  IV/E02db5e598b2823ae
1996 19     --->  EDK/850618075332
1997 20     --->  KDC/TTI
1998 21     --->  MAC/12cbbdf5
1999 22     --->  EDC/8cd0c4a8
2000 23     --->  )
2001 24     <---  (
2002 25     <---  MCL/ACK
2003 26     <---  RCV/17
2004 27     <---  ORG/3
2005 28     <---  KDC/TTI
2006 29     <---  EDC/59a8ddcc
2007 30     <---  )
2008
2009
2010                                                      Figure 9
2011
2012  __________________________________Ascertaining_the_Key_Relationship___________________________________________________
2013
2014
2015
2016  IDK field in m, and if this relationship is unknown to it, then the KDS is asked to
2017
2018  disclose the key relationship.
2019
2020
2021         As shown in Figure 9 on lines 1-9, This is done by issuing a request service
2022
2023  initialization (RSI) MCL and specifying the particular key relationship of interest.
2024
2025  The  KDS  consults  its  database,  and  if  the  exact  key  relationship  between  the
2026
2027  two  indicated  TMAs  can  be  ascertained,  it  returns  this  information.   The  key
2028
2029  relationship  is  encrypted  using  the  key  relationship  between  the  KDS  and  the
2030
2031  TMA, and the usual count and authentication fields are included.
2032
2033
2034         Once the TMA knows the key relationship used to encrypt the structure m,
2035
2036  it can decider the structure and ascertain the KD/IV/KA triple used to encrypt
2037
2038  the body of the message.
2039 \f  Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              26
2040
2041
2042  Appendix C: Differences between the ANSI and TTI drafts
2043
2044         The differences between the ansi draft standard for financial institution key
2045
2046  management,  and  the  TTI  draft's  specification  for  trusted  mail  handling,  are
2047
2048  considered.
2049
2050
2051         The concept of a key distribution center (CKD in the ansi draft, KDC in the
2052
2053  TTI  draft) environment differs.  In the ansi draft, only one party talks to the key
2054
2055  distribution  server  (KDS);  in  the  TTI  draft,  both  parties  talk  to  the  KDS.  This
2056
2057  leads  to  a  number  of  differences  in  the  two  protocols.  The  reason  for  this  shift
2058
2059  in the TTI  draft is somewhat subtle:  although both parties can talk to the KDS,
2060
2061  the mail transfer system (MTS) environment is such that both user agents (UAs)
2062
2063  are unable to contact each other in real-time.  Hence, a detailed two-way protocol
2064
2065  between them is prohibitively expensive.14
2066
2067
2068         Before discussing the differences between the two drafts, let us consider the
2069
2070  differences in the two environments:  in the electronic mail environment, the two
2071
2072  end-to-end  peers  need  not  be  simultaneously  online.  Electronic  mail  relies  on  a
2073
2074  communication  service  with  potentially  large  delays  in  transit  between  message
2075
2076  transfer agents (MTAs).  A basic concept of "mail" is that an originator must release
2077
2078  the enveloped message to a "transfer agent" before delivery can be attempted to a
2079
2080  recipient.  In contrast, in the electronic funds environment, the two peers make use
2081
2082  of a virtual-circuit service.  This means that they can synchronize much easier and
2083
2084  inter-operate in a more direct fashion.
2085
2086
2087         Service protocols are based on the notion of requests and responses.  A client
2088
2089  issues a request to a server, the server processes the request and returns a response.
2090
2091  Depending on the complexity of the protocol, the client may now respond to the
2092
2093  server's message, or might issue a new request, or might terminate the connection.
2094
2095
2096         As  delays  in  the  network  increase,  along  with  the  possibility  of  loss  or
2097
2098  corruption  or  re-ordering  of  messages,  it  becomes  more  difficult  to  implement  a
2099
2100  service  protocol.   In  the  case  of  a  high-level  protocol  making  use  of  a  virtual-
2101
2102  circuit service, most problems can be ignored, as the virtual-circuit service masks
2103
2104  out  problems  in  the  network  by  using  sequences,  positive  (and/or  negative)
2105
2106  acknowledgments, windows, and so on.
2107
2108
2109         Sadly,  electronic  mail  cannot  utilize  a  virtual-circuit  throughout  the  MTS
2110
2111  (although individual MTA-wise connections are (in theory) virtual-circuit based).
2112
2113  This means that implementing a real-time or interactive service protocol between
2114
2115  two endpoints (a.k.a. UAs) in the MTS is very difficult.  As a result, the complexity
2116
2117  of  an  end-to-end  protocol  in  the  MTS  (in  terms  of  requests  and  responses)  is
2118
2119  severely  constrained.  For  all  practical  purposes,  an  MTA  can  assume  datagram
2120
2121  service and nothing else:  messages might be re-ordered; messages might not reach
2122
2123  ________________________________________
2124 14  In the words of Einar A. Stefferud:  "Every interesting connection has at least two end-points _
2125
2126  connections with only one end-point are always uninteresting."
2127 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              27
2128
2129
2130 their destination; messages might be corrupted (though this is unlikely); in cases
2131
2132 of failure, a notice might be generated, or might not.
2133
2134
2135        In terms of the environment in which cryptographic service messages (CSMs)
2136
2137 must flow, the high degree of delay and uncertainty make the implementation of a
2138
2139 complex end-to-end protocol between UAs prohibitively expensive.  Hence, a KDC
2140
2141 is needed, to which each UA can connect using a virtual-circuit service, at posting
2142
2143 and  delivery  time.  The  TTI  draft  terms  such  a  user  agent  a  trusted  mail  agent
2144
2145 (TMA). Since both TMAs can connect to the KDS at different times using different
2146
2147 media, the KDS maintains state information about the key relationships between
2148
2149 different TMAs and manages those relationships appropriately.  Since connections
2150
2151 to the KDS can be expensive in terms of resources, each TMA caches information
2152
2153 received from the KDS appropriately.
2154
2155
2156        That's the gist of the argument as to why the TTI  draft differs from the ansi
2157
2158 draft.  It might be possible to include CSMs in the messages which UAs exchange,
2159
2160 but management of these CSMs can not be done reliably or in a straightforward
2161
2162 fashion owing to the datagram nature of the service offered by the MTS. Finally, it
2163
2164 should be noted that in the TTI  draft, the KDS never initiates a connection with
2165
2166 a TMA, rather it is the TMAs which connect to the KDS.
2167
2168
2169        In the following, the differences between the two drafts are highlighted.  Minor
2170
2171 differences between the two are not discussed.
2172
2173
2174        In the ansi draft, x 4:2 (p. 22) discusses the requirements for the automated
2175
2176 key management architecture.  The TTI  draft has somewhat more "depth", since
2177
2178 the  ansi  draft  does  not  make  use  of  a  master  key  (MK)  to  fully  automate  the
2179
2180 distribution of key-encrypting keys (KK).
2181
2182
2183        The ansi draft states that once a KK-relationship is discontinued by either
2184
2185 of  that  pair,  the  relation  is  not  to  be  re-used  for  any  subsequent  activity.  This
2186
2187 can't be guaranteed in the prototype implementation.  If one of the TMAs wishes
2188
2189 to discontinue a key, not only does it have to inform the KDS, but the other TMA
2190
2191 as well.  Since the TTI  draft does not permit CSMs between TMA-peers, the latter
2192
2193 action doesn't seem possible.  However, there is a solution.  Whenever a message is
2194
2195 deciphered, the TMA checks the effective date of the key used to encrypt a message
2196
2197 it has received, and if the key is newer than the one it currently uses, it considers
2198
2199 the older key to be discontinued.
2200
2201
2202        Furthermore,  although  the  environment  in  the  TTI  draft  is  that  of  a  key
2203
2204 distribution center, the notion of an ultimate recipient is not present, since all clients
2205
2206 connect to the KDS at one time or another.  In addition, the differences between
2207
2208 the  environs  envisioned  by  the  two  drafts  become  even  more  pronounced  when
2209
2210 one considers that the KDS distributes key-encrypting keys to TMAs, although the
2211
2212 ansi draft specifically prohibits this.
2213 \f Reprinted from Proceedings, Second International Symposium on Computer Message Systems, 1985              28
2214
2215
2216        Finally,  there  is  another  important  technical  difference  between  the  two
2217
2218 drafts:  every  request  to  the  KDS  by  the  TMA  results  in  a  specifically  defined
2219
2220 response from the KDS to the TMA. Furthermore, if the KDS responds in a positive
2221
2222 manner, then the TMA acknowledges this.  This three-way interaction is used to
2223
2224 ensure consistency between the states of the KDS and the TMA. The ansi draft
2225
2226 does not require such behavior, and might profit from some finite-state analysis to
2227
2228 ascertain unsafe (in terms of correctness) states which are reachable.
2229 \f
2230
2231
2232
2233                                                    Contents
2234
2235
2236
2237                                                                                                                Page
2238
2239  Introduction .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  *
2240  *.        1
2241
2242  The Key Distribution Service  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        6
2243
2244  The Trusted Mail Agent  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      10
2245
2246         Encrypting Mail .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      11
2247
2248         Decrypting Mail .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      13
2249
2250  Modifications to MH  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      14
2251
2252  Remarks .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . *
2253  * .      15
2254
2255         Strengths  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .*
2256  *      15
2257
2258         Open Questions  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      16
2259
2260         Weaknesses .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .   *
2261  *   17
2262
2263         Compromises, Compromises.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      18
2264
2265  Acknowledgements .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      19
2266
2267  References .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . *
2268  * .      20
2269
2270  Appendix A: An MH Session  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      21
2271
2272  Appendix B: A Short Exchange .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      23
2273
2274  Appendix C: Differences between the ANSI and TTI drafts  .  .  .  .  .  .  .  .  .  .      26
2275
2276
2277
2278  ________________________________________
2279 This document (version #2.60) was TEXset April 12, 1990 with DISS.STY v103.
2280
2281
2282
2283                                                                                                                      i