Changes
Np1sec
,/* Session Confirmation */
|}
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.
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.
'''Algorithm 3'''
After this step joining user will proceed to "initiate new session" by Algorithm 5.
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.
After this step users will proceed to "initiate new session" using Algorithm 5.
'''Algorithm 5'''
|}
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.
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
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]].
Run by exiting user.
|}
When the remaining participants receive the farewell message they need to reply with the Hash of TranscriptChain of the last message seen by the leaving user. They also need to re-run the one round key update algorithm. However, they only need a notice from the server that the user is leaving to initiate a subsession excluding the leaving user.
On Receive, the protocol updates who has seen which pieces of the key shares. The protocol also generates a new group key if the new key shares have been received from all participants. Those who have not updated their key shares eventually time out via their heartbeat interval.
'''Algorithm 8'''
|}
The protocol provisions two procedures to reach consistency in different cases: (a) reaching consistency for arbitrary messages during the course of a conversation, and (b) reaching consistency when an instance <math>\Pi^S_i</math> leaves. Case (b) may be viewed as a special instance of case (a) plus the additional premise that <math>\Pi^S_i</math> must reach consistency as soon as possible (because they want to leave), and that they don't care about reaching consistency for any subsequent messages that they might receive after their final "farewell" message.
** <math>\Pi^S_i</math> won't have a chance to reach consistency for the messages receives after ''p''
To ensure forward secrecy in long living chat sessions, ''(n+1)sec'' provides a session key update throughout the session. Each message sent to the session by each participant contains meta data described in [[#VIII.5.1 (n+1)sec Message Structure]]. Prior to sending any message, ''(n+1)sec'' determines the content of meta data, and piggy backs to that message according to the following algorithm:
|}
Heartbeat is an empty message which contains only meta data. The meta data consists of information used to compute a new key and the most updated hash of transcript chain.
* BROADCAST_LATENCY: Modelling the amount of time which a message takes to reach the server and broadcast to the other clients. It should be based on the transport considered.
Whenever, a message ''m'' is received a timer of (2*BROADCAST_LATENCY)+ACK_GRACE_INTERVAL) period is set. If the <math>H(Transcript_j[m'])</math> for a <math>m' \ge m</math> is received from all participants, the timer is cancelled. Otherwise at the time out, the protocol issues a local UI warning and cancel the warning if/when such a hash is received and is consistence among participants.
When a new session key is computed as well as when <math>\Pi^S_i</math> receives new ephemeral DH values from all users, a timer of (2*BROADCAST_LATENCY)+REKEY_GRACE_INTERVAL period is set. It is cancelled when all user contributions are received (ephemeral keys or session key secrets). Otherwise, the <math>\Pi^S_i</math> excludes users who failed to contribute from the <math>plist</math> exclude those users from the plist and call '''initiate new session'''. This measure is taken to ensure that users do not block in-session forward secrecy due to loss of connection or being under attack.
''(n+1)sec'' by design assumes the participants are trusted in being commited to the goal fo creating a secure chatroom. In this sense, ''(n+1)sec'' provide little defens against party which trying to sabotage a room by mounting various denial of service approaches. However, there are situation where a party is genuinely affected (by external adversary) or by connection problem. Under such assumption, situations we expect that all other parties, reach a consensus, that a participant has connectivity problem and agree on leave them out of the room.
Timeout sub protocol is designed to deal with such a situation. When a new session is requested (for join, leave, etc) each participant wait for (2*BROADCAST_LATENCY)+INTERACTION_GRACE_INTERVAL, they omit non-participating participants from the plist, and wait for PLIST_UPDATE_GRACE_INTERVAL. so other participants also reach to the same conclusion and updates their plists, then they initiate a new session.
'''Algorithm 10.XX'''
When a participant receives a request for initiating new session, it checks their most current view of participant list (the one with eliminated timed out users) and if it matched then they go ahead with initiating the session, otherwise decline halt the request.
All (n+1)sec messages have the following format
The following sections will describe the type-specific part for each type of messagee information about the joiner.
participant id, ephemeral publick key (DTHash)
are representing the joiner's information. the authenticated (DTByte) is kept only for compatibility with participant_info sub message structure and has no information value. It should be 1 as it represents the state of authentication of the joiner to itself. However, its value will be ignored by the current participants. =====Participant Info=====
session id (DTHash), session view (DTOpaque), key_confirmation(DTOpaque), sender's share(DTHash)
the sender's share is computed as described in the algorithm.
session id (DTHash), key_confirmation (DTOpeque), signature
session id (DTHash), sender share (DTHash), signature (DTHash)
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 32 byte public key that the user is going to use in the next session. =====(n+1)sec in session Message Structure=====
Every (n+1)sec message sent after establishment of a session has the following format:
If there is no message load, then the message is just an ack, acknowledging receipt of other messages.
Every p2p (n+1)sec message sent after exchange of the ephemeral public keys has the following format.
User message is the plain text typed by user and handled to (n+1)sec by the chat client.
'''FSM message handling''': The Joiner will ignores all messages without basic rule is that if the message has a session idof 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, for users of joiner or confirmed participant status:
===Joiner===
The sesseion finte state machine react based on the following table. A joiner will start a new session with JOIN_REQUESTED after it sends its join request.
{| class="wikitable"
|-
! State/Message !! JOIN_REQUEST !! PARTICIPANTS_INFO !! JOINER_AUTH !! GROUP_SHARE !! SESSION_CONFIRMATION !! IN_SESSION_MESSAGE !!
|-
| JOIN_REQUESTED || || authenticate and send share || || || || ||
|-
| RE_SHARED || init a stale session with new user || authenticate and store share || authenticate and store share || authenticate and store share || || ||
|-
| GROUP_KEY_GENERATED || init a stale session with new user || || || || mark confirmed and may move session || ||
|-
| IN_SESSION || init a session with new user || || || || || receive ||
|-
| DEAD STALE || || || || || || receive |-|DEAD || || || || || || receive
|}
If a message is received when there is no handler it will be ignored.
====Explaniantion of the handlers====
* '''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'''.
* '''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. In that case, the state of the receiving session stays unchanged.
* '''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. 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. =======Explaniantion it does not change the state of the handlers======authenticate and reshare =====Session transmission=====session.
= '''IX Cryptographic Primitives''' =