/*============================================================*/ ** MESSAGE DEFINITIONS FOR THE INTERFACE BETWEEN PARTICIPANTS ** /*============================================================*/ /*------------------------------------------------------------*/ Join Request - after connecting the bootstrap server, the participant checks if it is the Group Mgr. If not, is sends a join request to the GM. +---------+--------+ | type(1) | key(8) | +---------+--------+ 0:type - msg type = 0x10 for join request. 1:key - participant's secret key. /*------------------------------------------------------------*/ Key Version Change - when a participant is forced out of the active chat, the versions of all the KEKs and the TEK that were known by that member are replaced in order to provide perfect forward security. +---------+----------+-------------+-----------+============+==========+=====+-----------+============+==========+ | type(1) | lmem(15) | num_keys(1) | desc_0(3) | kdesc_0(3) | key_0(8) | ... | desc_N(3) | kdesc_N(3) | key_N(8) | +---------+----------+-------------+-----------+============+==========+=====+-----------+============+==========+ 0:type - msg type = 0x01 for key version change. 1:lmem - IP address of member whose departure is causing the version change. 2:num_keys - the number of pairs are contained in the message. 3:desc_n - descriptor of key used to encrypt the subsequent pair 4:kdesc_n - descriptor of subsequent key being delivered. 5:key_n - new key being distributed. note: encrypted fields are shown with '=' boundaries, unencrypted with '-' boundaries. /*------------------------------------------------------------*/ Key Revision Change - when a new participant joins, the revisions of all the KEKs and the TEK are passed through a one way hash function to provide perfect backward secrecy. +---------+---------+==========+ | type(1) | desc(3) | jmem(15) | +---------+---------+==========+ 0:type - msg type = 0x02 for key revision change. 1:desc - descriptor of key used to encrypt the rest of the message (kid|ver|rev). 2:jmem - IP address of member whose join is causing the revision change. note: encrypted fields are shown with '=' boundaries, unencrypted with '-' boundaries. /*------------------------------------------------------------*/ Chat Data - chat data message. Note the data field had to be a multiple of 64 due to the DES block re- quirements. +---------+---------+===========+ | type(1) | desc(3) | data(980) | +---------+---------+===========+ 0:type - msg type = 0x03 for key revision change. 1:desc - descriptor of key used to encrypt the rest of the message (kid|ver|rev). 2:data - actual data payload. note: encrypted fields are shown with '=' boundaries, unencrypted with '-' boundaries. /*------------------------------------------------------------*/ Join Response, Keys - when a new participant sends a Join Request to the GM, the GM responds with this message to inform the new participant of the KEKs it needs to know and the TEK. +---------+--------+=============+===========+==========+=====+===========+==========+ | type(1) | kid(1) | num_keys(1) | desc_0(3) | key_0(8) | ... | desc_N(3) | key_N(8) | +---------+--------+=============+===========+==========+=====+===========+==========+ 0:type - msg type = 0x04 for the join response, keys msg. 1:kid - key id given to the new user's secret key by the GM. 2:num_keys - the number of pairs are contained in the message. note 1: encrypted fields are shown with '=' boundaries, unencrypted with '-' boundaries. note 2: a descriptor isn't needed here since at this point the joiner only knows one key. note 3: TEK is the first key in the list; DEPTH keys are returned. /*------------------------------------------------------------*/ Join Response, Members - when a new participant sends a Join Request to the GM, the GM responds with this message to inform the new participant of the other active members. +---------+------------+==============+=============+==============+=====+==============+ | type(1) | entries(1) | num_users(1) | num_msgs(1) | member_0(15) | ... | member_N(15) | +---------+------------+==============+=============+==============+=====+==============+ 0:type - msg type = 0x05 for join response, members msg. 1:entries - is the number of members listed in this message. 2:num_users - is the total number of active users in the group. 3:num_msgs - is the numbers of msgs that will be necessary to deliver all the members. 4:member_n - IP address of active members maintained by the GM. note 1: encrypted fields are shown with '=' boundaries, unencrypted with '-' boundaries. note 2: entries can range from 0 (if joiner is first member) to 67. /*------------------------------------------------------------*/ Complaint - this message allows active members to vote to force another member to leave. How to act on these votes is policy-specific. In this implementation, one active members that is not the GM must vote to kick out a certain member before any action occurs. It is this force-out that necessitates a Key Version Change. It is notable that the GM cannot be forced out. +---------+---------+=========+ | type(1) | desc(3) | mem(15) | +---------+---------+=========+ 0:type - msg type = 0x06 for Complaint message. 1:desc - descriptor of key used to encrypt the rest of the message (kid|ver|rev). Note that this is the descriptor of the user sending the complaint and not the TEK. This is done for privacy. 2:mem - the active member the sender is voting to kick out. note 1: encrypted fields are shown with '=' boundaries, unencrypted with '-' boundaries. /*------------------------------------------------------------*/ Leave - this message allows an active member to volutarily leave the group. In this case, no keys need to be changed since the keys are not viewed to be comp- romised. GM removes member from the key hierarchy and the remaining members remove him from their distribution list. Note that if multicast is sup- ported, no action is necessary by non-GM members in the case of a voluntary leave. +---------+ | type(1) | +---------+ 0:type - msg type = 0x07 for the Leave message. /*------------------------------------------------------------*/ Destroy - this message can only be sent by the GM. It is sent when the GM wishes to disband the group. Upon receipt of this message, non-GMs should erase any keying material they have stored, free any alloc'd memory, and then exit. +---------+ | type(1) | +---------+ 0:type - msg type = 0x08 for the Destroy message. /*------------------------------------------------------------*/ /*============================================================*/ ** MESSAGE DEFINITIONS FOR THE INTERFACE TO THE ADMINISTRATOR ** /*============================================================*/ /*------------------------------------------------------------*/ Group Query - this is the bootstrap message sent by every chat node when the application is started. The node asks who is the GM of the group they wish to join. Nodes are preconfigured (out-of-band) with the IP address of the Admin node. Prompts the Admin node to send back a Group Response message (below). +---------+--------+ | type(1) | grp(3) | +---------+--------+ 0:type - msg type = 0x01 for the Group Query message. 1:grp - group number the node would like to join. /*------------------------------------------------------------*/ Group Reply - if the initiator of a Group Query is registered in the group about which it has asked, the Admin sends back the IP address of the GM. In the event that the requestor is the first to ask, they become the GM of that group and subsequent queries by other nodes wishing to join will be pointed to this first node. If the requestor is not registered, the request is ignored. +---------+--------+----------+ | type(1) | grp(3) | addr(15) | +---------+--------+----------+ 0:type - msg type = 0x02 for the Group Response message 1:grp - the group number about which the initiator of the Request asked. 2:addr - the IP address of the Group Manager of the group in question. /*------------------------------------------------------------*/ Registration Query - this message is sent by the GM of a group when it receives a request to join from a prospective chat node. The GM asks the Admin node of the Joiner is a registered member. +---------+--------+----------+ | type(1) | grp(3) | addr(15) | +---------+--------+----------+ 0:type - msg type = 0x03 for the Registration Query message 1:grp - the group number for which the Joiner has contacted the GM. 2:addr - the IP address of Joiner. /*------------------------------------------------------------*/ Registration Reply - this message is sent by the Admin node in response to a Registration Query message, but only if the sender of the Query is the GM of the group about which it is asking. The reply contains a flag whose value is the response to the query. +---------+---------+--------+----------+ | type(1) | flag(1) | grp(3) | addr(15) | +---------+---------+--------+----------+ 0:type - msg type = 0x04 for the Registration Reply message 1:flag - this field contains 1 or 0 depending on whether the 'addr' is registered 2:grp - the group number about which the GM has inquired. 3:addr - the IP address of Joiner. /*------------------------------------------------------------*/ GM Resignation - this message is sent by the GM as part of the group destroy process. If the sender of the message is the GM of the group in question, the Admin de-registers the sender as the GM of the group. After this action is taken, the next registered user to send a Group Query to the Admin concerning this group will become the GM. +---------+--------+ | type(1) | grp(3) | +---------+--------+ 0:type - msg type = 0x05 for the GM Resignation message. 1:grp - group number whose GM-ship the sender is resigning. /*------------------------------------------------------------*/