--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/papers/trusted/appendixB.tex	Mon Apr 18 23:46:02 2005 +0900
@@ -0,0 +1,93 @@
+% appendix B
+
+\appendix{B}{A Short Exchange}
+
+The simple nature of the interchange between the user and \MH/
+in Appendix~A completely hides any interactions between the \TMA/
+and the \KDS/.
+Let us briefly examine an exchange that might occur
+after the destination \TMA/ receives the message shown in Figure~\before.
+
+To begin,
+the \TMA/ must ascertain what it knows about the sender of the message,
+which claims to have a \KDS/ ID of~17.
+That is,
+the \TMA/ must first consider what key relationships it has with the sender.
+For the sake of argument,
+suppose that this purported subscriber is unknown to the \TMA/.
+In this case,
+the first step it must undertake is to ascertain the validity of this
+subscriber.
+
+\tagdiagram{B1-1}{Ascertaining the Sender}{rui}
+As shown in Figure~\rui\ on lines~1--7,
+the \TMA/ does this by establishing a connection to the \KDS/ and issuing an
+{\it request identified user} (RUI) MCL.%
+\nfootnote{In point of fact,
+the {\it very} first thing that the \TMA/ does after connecting to the \KDS/
+is verify that the key relationships between the \KDS/ and the \TMA/ are
+valid (have not expired).
+If the key relationship between the two has expired,
+the \TMA/ issues a {\it request service initialization} RSI MCL to
+establish a new key relationship.
+This relationship contains a {\it key-encrypting key} (KK)
+and an {\it authentication key} (KA).
+Once a valid key relationship exists between the \KDS/ and the \TMA/,
+transactions concerning other key relationships may take place.}
+If the response by the \KDS/ is positive,
+the \TMA/ will use the information returned when generating the
+\eg{X-KDS-ID:} field for authentication.
+The response \CSM/ returned by the \KDS/ includes
+an {\it authentication checksum} (the MAC field on line~15)
+and a {\it transaction count} (the CTA field on line~12)
+to prevent spoofing by a process pretending to be the \KDS/.
+The \TMA/ then acknowledges that the response from the server was acceptable
+on lines~18--24.
+
+The next step is to ascertain the actual key relationship used to encrypt the
+structure $m$, which appears after the identifying string.
+The \TMA/ consults the IDK field in $m$,
+and if this relationship is unknown to it,
+then the \KDS/ is asked to disclose the key relationship.
+
+\tagdiagram{B1-2}{Ascertaining the Key Relationship}{rsi}
+As shown in Figure~\rsi\ on lines~1--9,
+This is done by issuing a {\it request service initialization} (RSI) MCL
+and specifying the particular key relationship of interest.
+The \KDS/ consults its database,
+and if the exact key relationship between the two indicated \TMA/s can be
+ascertained,
+it returns this information.
+The key relationship
+is encrypted using the key relationship between the \KDS/ and the \TMA/,
+and the usual count and authentication fields are included.
+
+Once the \TMA/ knows the key relationship used to encrypt the structure $m$,
+it can decider the structure and ascertain the KD/IV/KA triple used to
+encrypt the body of the message.
+
+%	<--- (
+%	<--- MCL/RSI
+%	<--- ORG/3
+%	<--- KDC/TTI
+%	<--- SVR/*KK.KD
+%	<--- EDC/dabfdb4c
+%	<--- )
+%	---> (
+%	---> MCL/RTR
+%	---> ORG/3
+%	---> *KK/926b876cafce46cd365382c36a40fa80
+%	---> CTA/1
+%	---> KD/1eea5394e6ad1b75
+%	---> KD/6c95c8d2caa75807
+%	---> EDK/850618075827
+%	---> KDC/TTI
+%	---> MAC/501f71b6
+%	---> EDC/5bd7b2d0
+%	---> )
+%	<--- (
+%	<--- MCL/ACK
+%	<--- ORG/3
+%	<--- KDC/TTI
+%	<--- EDC/db46ce7e
+%	<--- )