Return to appendixB.tex CVS log

Up to [CSRG BSD Unix] / 43BSD / contrib / mh / papers / trusted

Annotation of 43BSD/contrib/mh/papers/trusted/appendixB.tex, revision 1.1.1.1

1.1       root        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: %      <--- )

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.