Np1sec - Revision history

Vmon: /* Session Confirmation */

2016-06-23T10:48:12Z

‎Session Confirmation

Vmon: /* Explaniantion of the handlers */

2016-06-22T20:11:42Z

‎Explaniantion of the handlers

Vmon: /* Explaniantion of the handlers */

2016-06-22T20:09:13Z

‎Explaniantion of the handlers

Vmon: /* Finite State Table */

2016-06-22T20:07:58Z

‎Finite State Table

Vmon: /* VIII.10 (n+1)sec Session Management and Message Handling */

2016-06-22T19:32:10Z

‎VIII.10 (n+1)sec Session Management and Message Handling

Vmon: /* VIII.4 Leave */

2016-06-22T13:40:01Z

‎VIII.4 Leave

Show changes

Vmon: /* VIII.2 Chatroom Setup */

2016-06-22T13:34:25Z

‎VIII.2 Chatroom Setup

Vmon: /* Session transition */

2016-06-22T10:30:40Z

‎Session transition

Vmon: /* Session transmission */

2016-06-22T10:05:41Z

‎Session transmission

Vmon at 09:35, 22 June 2016

2016-06-22T09:35:20Z

@@ Line 1,166: / Line 1,166: @@
      session id (DTHash), session confirmation (DTHash), next session ephemeral key (DTHash)
-"session confirmation" is a hash(Session key|sender nickname), the next session ephemeral key is the 32bit public key that the user is going to use in the next session.
+"session confirmation" is a hash(Session key|sender nickname), the next session ephemeral key is the 32 byte public key that the user is going to use in the next session.
-−
 ===(n+1)sec in session Message Structure===

@@ Line 1,325: / Line 1,325: @@
 * '''authenticate and store share'''
    validate the authentication token and store the sent share. If everybody is authenticated and all shares are received, compute the session key and the session confirmation and send of SESSION_CONFIRMATION message. In that case, the session state will be changed to GROUP_KEY GENERATED. Otherwise stays unchanged.
-  If the received PARTICIPANTS_INFO message does not corresponds to the session, it create a new  session for that list in stale state.
 * '''confirm and may move session'''
-it validate the session confirmation. If all the participant is confirmed the state will change to IN_SESSION. joiner become confirmed participant.
+it validate the session confirmation. If all the participant is confirmed the state will change to IN_SESSION. joiner become confirmed participant. Otherwise it does not change the state of the session.
 * '''init a session with new user'''
-When a confirmed participant receive this message start a new session with the joiner added to it. The state of new session will be RE_SHARED.
+When a confirmed participant receive this message start a new session with the joiner added to it. The state of new session will be RE_SHARED. it does not change the state of the session.
 * '''init a stale session with new user'''
-It creates a new session with the joiner added to it. The state of new session will be STALE.
+It creates a new session with the joiner added to it. The state of new session will be STALE. it does not change the state of the session.
 = '''IX Cryptographic Primitives''' =

@@ Line 1,333: / Line 1,333: @@
 When a confirmed participant receive this message start a new session with the joiner added to it. The state of new session will be RE_SHARED.
-* '''init a session stale session with new user'''
+* '''init a stale session with new user'''
 It creates a new session with the joiner added to it. The state of new session will be STALE.

@@ Line 1,325: / Line 1,325: @@
 * '''authenticate and store share'''
    validate the authentication token and store the sent share. If everybody is authenticated and all shares are received, compute the session key and the session confirmation and send of SESSION_CONFIRMATION message. In that case, the session state will be changed to GROUP_KEY GENERATED. Otherwise stays unchanged.
 * '''confirm and may move session'''
@@ Line 1,331: / Line 1,332: @@
 * '''init a session with new user'''
 When a confirmed participant receive this message start a new session with the joiner added to it. The state of new session will be RE_SHARED.
 = '''IX Cryptographic Primitives''' =

@@ Line 1,230: / Line 1,230: @@
 ==VIII.10 (n+1)sec Session Management and Message Handling==
-This section explains the rule - based on which - (n+1)sec governs the order when multiple participants try to join or leave a session simultaneously. Every participant in a chat room has either the status of a "joiner" or a "participant" of a confirmed session exclusively. Based on the user status and the message received, a specific subprotocol needs to be run by the user which is explained in the following sections.
+However, the process on how a joining and leaving participants trigger a new chat sessions and how participants need to respond to multiple simultanous joins and leaves requests and the process of establishing multiple chat sessions is managed by (n+1)sec Session Management protocol.
-If the message has a session id of a session that the user is part of, then message handling is governed by the finite state machine table described below. Otherwise, the messages should be handled as follows:
+This protocol is work in progress to deal with unresponsive participants and those who denial their response to bar the establishment of a session. This section explains the rules - based on which - (n+1)sec currently governs the order when multiple participants try to join or leave a session simultaneously.
 ===Joiner===
@@ Line 1,241: / Line 1,246: @@
      user_in_room_state == JOINING
-* Messages without session id (including JOIN_REQUEST):The Joiner, user in "JOINIG" state will ignores all messages without session id.
+* Messages without session id (including JOIN_REQUEST): The Joiner, user in "JOINIG" state will ignores all messages without session id.
-* If the message has a session id which the joiner has not constructed - the joiner will react as follows:
+* If the message has a session id which the joiner has not constructed a session - the joiner will react as follows based on the typ of the message:
-** ''Participant Info'':
+** '''Participant Info''':
-*** If the joiner is mentioned in the participant list, the joiner construct a session with that list.
+*** If the joiner is mentioned in the participant list, the joiner construct a session with that list. The session will be at the state of JOIN_REQUESTED.
-*** If the joiner is not mentioned in the plist,  the joiner ignore the message (*** Should the joiner begins a session by appending itself to the list?).
+*** If the joiner is not mentioned in the plist,  the joiner ignores the message (Suggestion: Should the joiner begins a session by appending itself to the list?).
-** ''Session Confirmation'': The joiner will mark all sessions as DEAD and wait for the new participant list (*** should joiner send a new join request?).
+** '''Session Confirmation''': The joiner will mark all its sessions as DEAD and wait for the new participant list (*** should joiner send a new join request?).
 If the message has session id corresponding to a session that the joiner already constructed (and is in process of joining, i.e. is not DEAD), then the session FSM will deal with the message, as stated above.
@@ Line 1,258: / Line 1,263: @@
      user_in_room_state == CURRENT_USER
 * If the received message has a session id and the participant has constructed a session corresponding to that message. Then the FSM treats the message.
@@ Line 1,263: / Line 1,270: @@
 * If the received message has a session id, but the confirmed participant does not have a session is not part of the session then the participant will ignore the message, unless the message is of PARTICIPANT_INFO.
-* If the received message is of PARTICIPANT_INFO for which, the user doesn't have corresponding session then the FSM of next_in_activation_line will treat the session. For the definition of next_in_activation_line see Session Transmission section.
+* If the received message is of PARTICIPANT_INFO for which, the user doesn't have corresponding session then the FSM of next_in_activation_line session will treat the session. For the definition of next_in_activation_line.
-* If the received message does not have a session id, then it is a JOIN_REQUEST then the FSM of next_in_activation_line will treat the session. For the definition of next_in_activation_line see Session Transmission section.
+* If the received message does not have a session id, then it is a JOIN_REQUEST (otherwise marked as invalid). The FSM of next_in_activation_line will treat the session.
 ===Session transition===
@@ Line 1,281: / Line 1,288: @@
 next_in_activation_line is the session which receives requests for new session (join/leave). When new session is activated it also become next_in_activation_line. When a new priority session is constructed it takes the next_in_activation_line pointer. If there is no priority session, then the first session which gets it share key generated becomes the next in activtion.
-When a user leaves while another user trys to join, the leave protocol will take priority and a new participant info message is sent to the joining user after all leaving users have left. When multiple users are joining, when the confirmed participant receives the first joiner auth, it will halt the protocol for other joining users. When the session is confirmed, the new participant info list will be sent to the remaining joining users.
+When a user leaves while another user trys to join, the leave protocol will take priority and a new participant info message is sent to the joining user after all leaving users have left. In this case, the session with leaving participant removed becomes the '''next_in_activation_line''' and all live sessions (not DEAD) (beside the active_session) will be marked as stale.
 Joining user (user_in_room_state == JOINING) does not keep any indicator.

@@ Line 545: / Line 545: @@
 |}
-=== VIII.3 Join ===
+== VIII.3 Join ==
 Joining a chat involves two different procedures: the Join procedure, described in Algorithm [[''(n+1)sec''#Join|2]], which runs on the new participant’s instance, and an Accept New Participant Procedure, described in Algorithm [[''(n+1)sec''#Protocol_for_other_participants_already_in_the_chat_to_accept_the_newcomer|3]], which runs on the clients of participants that are already in the chat.
@@ Line 553: / Line 553: @@
 The new participant needs to authenticate everybody already in the room and hand them their ephemeral key. All the parties already in the room only need to authenticate the new participant and need to send to them their ephemeral DH key. These procedures are described in Algorithm 3 and 4. After initial authentication step, all parties follow the same procedure to initiate a new session following Algorithm 5.
-====  Authentication Step for new Joining party====
+===  Authentication Step for new Joining party===
 '''Algorithm 3'''
@@ Line 589: / Line 589: @@
 After this step joining user will proceed to "initiate new session" by Algorithm 5.
-====Authentication Step for parties in the room====
+===Authentication Step for parties in the room===
 For other participants to a accept a new participant only, the authentication step is different. After current participants authenticate the new user, they proceed to update session.
@@ Line 618: / Line 618: @@
 After this step users will proceed to "initiate new session" using Algorithm 5.
-==== Initiate new session ====
+=== Initiate new session ===
 '''Algorithm 5'''
@@ Line 696: / Line 696: @@
 |}
-==== Sending and receiving messages while joining is in progress ====
+=== Sending and receiving messages while joining is in progress ===
 In situations where a prolonged joining process (due to connection problems or malicious activities) has an adverse effect on the user experience, it might be desirable to enable that joining users can communicate with the parties in the room, while maintaining minimum assurances of authenticity, confidentiality, forward secrecy, as well as consistency only among participants.
@@ Line 708: / Line 708: @@
 This is less secure model in which a room is a forwardly secure authenticated communication channel while a session is a subset of the room, which additionally offers a consistent view of the room and consistent messages among participants. The detail of the process is depicted in Secthoin VIII.5
-===VIII.4 Leave===
+==VIII.4 Leave==
 Leaving a chatroom involves a message from a leaving party indicating its intention to leave which, as with all other messages, contains the hash of TranscriptChain and one procedure for those who are staying in the chatroom (Procedure Farewell) which is described in Table [[''(n+1)sec''#Leave]].

@@ Line 1,308: / Line 1,308: @@
 Each confirmed participant (user_in_room_state == CURRENT_USER) keeps to indicators:
-* active_session
+* '''active_session'''
 The active_session is the only session which is in IN_SESSION state. A session state moves to IN_SESSION when the user receives session confirmation from all participants. In that case the previously active session state will be DEAD.
@@ Line 1,314: / Line 1,314: @@
 When a new session get activated, all STALE sessions gets refreshed. That is, all sessions which were requested to be created (due to join or leave) during the creation of the newly active session, will be recreated according to the new participant list. Further more, the next_in_activation_line also points to the newly activated session.
-* next_in_activation_line
+* '''next_in_activation_line'''
- When a user leaves while another user trys to join, the leave protocol will take priority and a new participant info message is sent to the joining user after all leaving users have left. When multiple users are joining, when the confirmed participant receives the first joiner auth, it will halt the protocol for other joining users. When the session is confirmed, the new participant info list will be sent to the remaining joining users.
+next_in_activation_line is the session which receives requests for new session (join/leave). When new session is activated it also become next_in_activation_line. When a new priority session is constructed it takes the next_in_activation_line pointer. If there is no priority session, then the first session which gets it share key generated becomes the next in activtion.
 Joining user (user_in_room_state == JOINING) does not keep any indicator.

@@ Line 1,304: / Line 1,304: @@
-=====Session transmission=====
+=====Session transition=====
-The session changes when all users have confirmed a session. When a user leaves while another user trys to join, the leave protocol will take priority and a new participant info message is sent to the joining user after all leaving users have left. When multiple users are joining, when the confirmed participant receives the first joiner auth, it will halt the protocol for other joining users. When the session is confirmed, the new participant info list will be sent to the remaining joining users.
+Each confirmed participant (user_in_room_state == CURRENT_USER) keeps to indicators:
 = '''IX Cryptographic Primitives''' =

@@ Line 1,263: / Line 1,263: @@
 * If the received message has a session id, but the confirmed participant does not have a session is not part of the session then the participant will ignore the message, unless the message is of PARTICIPANT_INFO.
-* If the received message is of PARTICIPANT_INFO for which user doesn't have corresponding session or then the FSM of next_in_activation_line will treat the session.
+* If the received message is of PARTICIPANT_INFO for which, the user doesn't have corresponding session then the FSM of next_in_activation_line will treat the session. For the definition of next_in_activation_line see Session Transmission section.
-* If the received message does not have a session id, then it is a JOIN_REQUEST then the FSM of next_in_activation_line will treat the session.
+* If the received message does not have a session id, then it is a JOIN_REQUEST then the FSM of next_in_activation_line will treat the session. For the definition of next_in_activation_line see Session Transmission section.
 =====Finite State Table=====
@@ Line 1,289: / Line 1,289: @@
 If a message is received when there is no handler it will be ignored.
 * '''authenticate and send share''' called by the joiner, computes authentication token with each of the participants and the user share of the session key and send a JOINER_AUTH Message. Beside generating share it acts like '''authenticate and store share'''.
@@ Line 1,301: / Line 1,303: @@
 When a confirmed participant receive this message start a new session with the joiner added to it. The state of new session will be RE_SHARED.
 =====Session transmission=====