![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to appendixC.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / mh / papers / trusted|
Return to appendixC.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / mh / papers / trusted |
1.1 root 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.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.