|
|
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.