git.marmaro.de Git - mmh/blob - docs/historical/mh-6.8.5/papers/trusted/appendixC.tex

   1 % appendix C
   2
   3 \appendix{C}{Differences between the ANSI and TTI drafts}
   4
   5 The differences between the \ansi/ draft standard for
   6 financial institution key management,
   7 and the \TTI/ draft's specification for trusted mail handling,
   8 are considered.
   9
  10 The concept of a {\it key distribution center}
  11 (\CKD/ in the \ansi/ draft, \KDC/ in the \TTI/ draft)
  12 environment differs.
  13 In the \ansi/ draft,
  14 only one party talks to the {\it key distribution server} (\KDS/);
  15 in the \TTI/ draft,
  16 both parties talk to the \KDS/.
  17 This leads to a number of differences in the two protocols.
  18 The reason for this shift in the \TTI/ draft is somewhat subtle:
  19 although both parties can talk to the \KDS/,
  20 the {\it mail transfer system} (\MTS/)
  21 environment is such that both {\it user agents} (\UA/s) are unable to
  22 contact each other in real-time.
  23 Hence, a detailed two-way protocol between them is prohibitively expensive.%
  24 \nfootnote{In the words of Einar A.~Stefferud:
  25 ``Every interesting connection has at least two end-points~---~connections
  26 with only one end-point are always uninteresting.''}
  27
  28 Before discussing the differences between the two drafts,
  29 let us consider the differences in the two environments:
  30 in the electronic mail environment,
  31 the two end-to-end peers need not be simultaneously online.
  32 Electronic mail relies on a communication service with potentially large
  33 delays in transit between {\it message transfer agents} (\MTA/s).
  34 A basic concept of ``mail'' is that an originator must release the enveloped
  35 message to a ``transfer agent'' before delivery can be attempted to a
  36 recipient.
  37 In contrast,
  38 in the electronic funds environment,
  39 the two peers make use of a virtual-circuit service.
  40 This means that they can synchronize much easier
  41 and inter-operate in a more direct fashion.
  42
  43 Service protocols are based on the notion of requests and responses.
  44 A client issues a request to a server,
  45 the server processes the request and returns a response.
  46 Depending on the complexity of the protocol,
  47 the client may now respond to the server's message,
  48 or might issue a new request,
  49 or might terminate the connection.
  50
  51 As delays in the network increase,
  52 along with the possibility of loss or corruption or re-ordering of messages,
  53 it becomes more difficult to implement a service protocol.
  54 In the case of a high-level protocol making use of a virtual-circuit service,
  55 most problems can be ignored,
  56 as the virtual-circuit service masks out problems in the network
  57 by using sequences, positive (and/or negative) acknowledgments, windows,
  58 and so on.
  59
  60 Sadly, electronic mail cannot utilize a virtual-circuit throughout the \MTS/
  61 (although individual \MTA/-wise connections are (in theory) virtual-circuit
  62 based).
  63 This means that implementing a real-time or interactive
  64 service protocol between two endpoints (a.k.a.~\UA/s)
  65 in the \MTS/ is very difficult.
  66 As a result,
  67 the complexity of an end-to-end protocol in the \MTS/
  68 (in terms of requests and responses)
  69 is severely constrained.
  70 For all practical purposes,
  71 an \MTA/ can assume datagram service and nothing else:
  72 messages might be re-ordered;
  73 messages might not reach their destination;
  74 messages might be corrupted (though this is unlikely);
  75 in cases of failure, a notice might be generated, or might not.
  76
  77 In terms of the environment in which {\it cryptographic service messages}
  78 (\CSM/s) must flow,
  79 the high degree of delay and uncertainty make the implementation of a complex
  80 end-to-end protocol between \UA/s prohibitively expensive.
  81 Hence, a \KDC/ is needed,
  82 to which each \UA/ can connect using a virtual-circuit service,
  83 at posting and delivery time.
  84 The \TTI/ draft terms such a user agent a {\it trusted mail agent} (\TMA/).
  85 Since both \TMA/s can connect to the \KDS/ at different times using different
  86 media,
  87 the \KDS/ maintains state information about the key relationships between
  88 different \TMA/s and manages those relationships appropriately.
  89 Since connections to the \KDS/ can be expensive in terms of resources,
  90 each \TMA/ caches information received from the \KDS/ appropriately.
  91
  92 That's the gist of the argument as to why the \TTI/ draft differs from the
  93 \ansi/ draft.
  94 It might be possible to include \CSM/s in the messages which \UA/s exchange,
  95 but management of these \CSM/s can not be done reliably or in a straightforward
  96 fashion owing to the datagram nature of the service offered by the \MTS/.
  97 Finally, it should be noted that in the \TTI/ draft,
  98 the \KDS/ never initiates a connection with a \TMA/,
  99 rather it is the \TMA/s which connect to the \KDS/.
 100
 101 In the following,
 102 the differences between the two drafts are highlighted.
 103 Minor differences between the two are not discussed.
 104
 105 In the \ansi/ draft,
 106 $\S 4.2$ (p.~22) discusses the requirements for the automated key
 107 management architecture.
 108 The \TTI/ draft has somewhat more ``depth'',
 109 since the \ansi/ draft does not make use of a {\it master key} (MK)
 110 to fully automate the distribution of {\it key-encrypting keys} (KK).
 111
 112 The \ansi/ draft states that once a KK-relationship is discontinued by either
 113 of that pair,
 114 the relation is not to be re-used for any subsequent activity.
 115 This can't be guaranteed in the prototype implementation.
 116 If one of the \TMA/s wishes to discontinue a key,
 117 not only does it have to inform the \KDS/,
 118 but the other \TMA/ as well.
 119 Since the \TTI/ draft does not permit \CSM/s between \TMA/-peers,
 120 the latter action doesn't seem possible.
 121 However, there is a solution.
 122 Whenever a message is deciphered,
 123 the \TMA/ checks the effective date of the key used to
 124 encrypt a message it has received,
 125 and if the key is newer than the one it currently uses,
 126 it considers the older key to be discontinued.
 127
 128 Furthermore,
 129 although the environment in the \TTI/ draft is that of a key distribution
 130 center,
 131 the notion of an {\it ultimate recipient} is not present,
 132 since all clients connect to the \KDS/ at one time or another.
 133 In addition,
 134 the differences between the environs envisioned by the two drafts
 135 become even more pronounced when one considers that the \KDS/ distributes
 136 key-encrypting keys to \TMA/s,
 137 although the \ansi/ draft specifically prohibits this.
 138
 139 Finally,
 140 there is another important technical difference between the two
 141 drafts:
 142 every request to the \KDS/ by the \TMA/
 143 results in a specifically defined response from the \KDS/ to the \TMA/.
 144 Furthermore,
 145 if the \KDS/ responds in a positive manner,
 146 then the \TMA/ acknowledges this.
 147 This three-way interaction is used to ensure consistency between the states
 148 of the \KDS/ and the \TMA/.
 149 The \ansi/ draft does not require such behavior,
 150 and might profit from some finite-state analysis to ascertain unsafe
 151 (in terms of correctness) states which are reachable.