Mercurial > hg > Applications > mh

comparison papers/trusted/appendixB.tex @ 0:bce86c4163a3

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Initial revision
author kono
date Mon, 18 Apr 2005 23:46:02 +0900
parents
children
comparison
equal deleted inserted replaced
-1:000000000000 0:bce86c4163a3
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 % <--- )