Skip to content

Long term Unidirectional Messaging Session Protocol

Dusty Wilson edited this page May 30, 2016 · 1 revision

= Overview =

This protocol establishes a messaging session that operates as a unidirectional pipe. Bidirectional communication pipes can be formed by establishing two sessions and operating them simultaneously.

Asymmetric cryptography is used to exchange a symmetric session key initially, but the receiver does not have to retain the session key once it has been established. Instead, the receiver encrypts the session key within a session ticket and furnishes the ticket to the sender. A long-term symmetric key known only to the receiver is used to encrypt the session ticket. The sender submits the session ticket along with each message destined for the receiver, which enables the receiver to both validate the session and to decrypt the message.

A feature of the protocol is that sessions do not have to be short-lived; it is up to the two parties to determine an appropriate maximum duration of a session, which could be minutes, days or even years.

It is the sender's responsibility to retain the session key and the ticket. If the sender forgets either, or if the session expires due to policies established by either the sender or receiver, then a new session must be negotiated.

The protocol is extremely well-suited to servers under heavy load with many clients. The use of a long-term symmetric key makes validation and decryption of the session ticket extremely fast. Receivers that do not require a bidirectional pipe will have no memory overhead per session.

= Unidirectional Session Example =

Alice (A) wants to negotiate a session with Bob (B) so that she can send messages to him. It is assumed that Alice has access to a validated public key for Bob (KPB) that matches Bob's private key, and that Bob has access to a validated public key for Alice (KPA) that matches Alice's private key. Bob also is in possession of a long term symmetric key (KLB).

The session is established as follows:

A → B : { N,,A,,, A } ,,KPB,,\\

Alice invents N,,A,, and sends it and her identity to Bob encrypted with Bob's public key.\\

B → A : { N,,A,,, N,,B,,, B } ,,KPA,,, { N,,A,,, N,,B,,, A, T } ,,KLB,,\\

Bob decrypts N,,A,, with his private key, invents N,,B,, and sends N,,A,,, N,,B,, and B to Alice encrypted with Alice's public key.\\ Bob also forms a session ticket by encrypting NA, NB, Alice's identity and a current Time-stamp with his long term symmetric key, and sends that to Alice as well.\\

A → B : { N,,A,,, N,,B,,, A, T } ,,KLB,,, { M } ,,NAB,,\\

Alice verifies that N,,A,, matches what she sent, decrypts N,,B,, with her private key and derives the symmetric session key by concatenating N,,A,, and N,,B,,.\\ Alice subsequently can send any number of messages to Bob by including Bob's session ticket followed by the message content encrypted by NAB.\\ Bob is able to read messages from Alice by decrypting the ticket with his long-term symmetric key, verifying that it is well-formed and unexpired, constructing the session key from N,,A,, and N,,B,, and then decrypting the message with it.