DataMuseum.dk

top - metrics - download

    Length: 3392 (0xd40)
    Types: TextFile
    Names: »appendixB.tex«

└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
    └─⟦3658e588a⟧ »EurOpenD3/mail/mh/mh-6.7.tar.Z« 
        └─⟦c75e36ecb⟧ 
            └─⟦this⟧ »mh-6.7/papers/trusted/appendixB.tex« 

TextFile

% 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
%	<--- )