% 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 occurafter 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 thissubscriber.\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/ arevalid (have not expired).If the key relationship between the two has expired,the \TMA/ issues a {\it request service initialization} RSI MCL toestablish 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/ includesan {\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 acceptableon lines~18--24.The next step is to ascertain the actual key relationship used to encrypt thestructure $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) MCLand 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 beascertained,it returns this information.The key relationshipis 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 toencrypt 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%	<--- )