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