diplodocus.org Git - nmh/blob - docs/historical/mh-6.8.5/papers/trusted/appendixB.tex

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