Mercurial > hg > Applications > mh
comparison papers/trusted/appendixC.tex @ 0:bce86c4163a3
Initial revision
author | kono |
---|---|
date | Mon, 18 Apr 2005 23:46:02 +0900 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
-1:000000000000 | 0:bce86c4163a3 |
---|---|
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. |