|
0
|
1 % appendix B
|
|
|
2
|
|
|
3 \appendix{B}{A Short Exchange}
|
|
|
4
|
|
|
5 The simple nature of the interchange between the user and \MH/
|
|
|
6 in Appendix~A completely hides any interactions between the \TMA/
|
|
|
7 and the \KDS/.
|
|
|
8 Let us briefly examine an exchange that might occur
|
|
|
9 after the destination \TMA/ receives the message shown in Figure~\before.
|
|
|
10
|
|
|
11 To begin,
|
|
|
12 the \TMA/ must ascertain what it knows about the sender of the message,
|
|
|
13 which claims to have a \KDS/ ID of~17.
|
|
|
14 That is,
|
|
|
15 the \TMA/ must first consider what key relationships it has with the sender.
|
|
|
16 For the sake of argument,
|
|
|
17 suppose that this purported subscriber is unknown to the \TMA/.
|
|
|
18 In this case,
|
|
|
19 the first step it must undertake is to ascertain the validity of this
|
|
|
20 subscriber.
|
|
|
21
|
|
|
22 \tagdiagram{B1-1}{Ascertaining the Sender}{rui}
|
|
|
23 As shown in Figure~\rui\ on lines~1--7,
|
|
|
24 the \TMA/ does this by establishing a connection to the \KDS/ and issuing an
|
|
|
25 {\it request identified user} (RUI) MCL.%
|
|
|
26 \nfootnote{In point of fact,
|
|
|
27 the {\it very} first thing that the \TMA/ does after connecting to the \KDS/
|
|
|
28 is verify that the key relationships between the \KDS/ and the \TMA/ are
|
|
|
29 valid (have not expired).
|
|
|
30 If the key relationship between the two has expired,
|
|
|
31 the \TMA/ issues a {\it request service initialization} RSI MCL to
|
|
|
32 establish a new key relationship.
|
|
|
33 This relationship contains a {\it key-encrypting key} (KK)
|
|
|
34 and an {\it authentication key} (KA).
|
|
|
35 Once a valid key relationship exists between the \KDS/ and the \TMA/,
|
|
|
36 transactions concerning other key relationships may take place.}
|
|
|
37 If the response by the \KDS/ is positive,
|
|
|
38 the \TMA/ will use the information returned when generating the
|
|
|
39 \eg{X-KDS-ID:} field for authentication.
|
|
|
40 The response \CSM/ returned by the \KDS/ includes
|
|
|
41 an {\it authentication checksum} (the MAC field on line~15)
|
|
|
42 and a {\it transaction count} (the CTA field on line~12)
|
|
|
43 to prevent spoofing by a process pretending to be the \KDS/.
|
|
|
44 The \TMA/ then acknowledges that the response from the server was acceptable
|
|
|
45 on lines~18--24.
|
|
|
46
|
|
|
47 The next step is to ascertain the actual key relationship used to encrypt the
|
|
|
48 structure $m$, which appears after the identifying string.
|
|
|
49 The \TMA/ consults the IDK field in $m$,
|
|
|
50 and if this relationship is unknown to it,
|
|
|
51 then the \KDS/ is asked to disclose the key relationship.
|
|
|
52
|
|
|
53 \tagdiagram{B1-2}{Ascertaining the Key Relationship}{rsi}
|
|
|
54 As shown in Figure~\rsi\ on lines~1--9,
|
|
|
55 This is done by issuing a {\it request service initialization} (RSI) MCL
|
|
|
56 and specifying the particular key relationship of interest.
|
|
|
57 The \KDS/ consults its database,
|
|
|
58 and if the exact key relationship between the two indicated \TMA/s can be
|
|
|
59 ascertained,
|
|
|
60 it returns this information.
|
|
|
61 The key relationship
|
|
|
62 is encrypted using the key relationship between the \KDS/ and the \TMA/,
|
|
|
63 and the usual count and authentication fields are included.
|
|
|
64
|
|
|
65 Once the \TMA/ knows the key relationship used to encrypt the structure $m$,
|
|
|
66 it can decider the structure and ascertain the KD/IV/KA triple used to
|
|
|
67 encrypt the body of the message.
|
|
|
68
|
|
|
69 % <--- (
|
|
|
70 % <--- MCL/RSI
|
|
|
71 % <--- ORG/3
|
|
|
72 % <--- KDC/TTI
|
|
|
73 % <--- SVR/*KK.KD
|
|
|
74 % <--- EDC/dabfdb4c
|
|
|
75 % <--- )
|
|
|
76 % ---> (
|
|
|
77 % ---> MCL/RTR
|
|
|
78 % ---> ORG/3
|
|
|
79 % ---> *KK/926b876cafce46cd365382c36a40fa80
|
|
|
80 % ---> CTA/1
|
|
|
81 % ---> KD/1eea5394e6ad1b75
|
|
|
82 % ---> KD/6c95c8d2caa75807
|
|
|
83 % ---> EDK/850618075827
|
|
|
84 % ---> KDC/TTI
|
|
|
85 % ---> MAC/501f71b6
|
|
|
86 % ---> EDC/5bd7b2d0
|
|
|
87 % ---> )
|
|
|
88 % <--- (
|
|
|
89 % <--- MCL/ACK
|
|
|
90 % <--- ORG/3
|
|
|
91 % <--- KDC/TTI
|
|
|
92 % <--- EDC/db46ce7e
|
|
|
93 % <--- )
|
