Return to appendixC.tex CVS log

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

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

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.