Usage Scenario

This section provides a real case scenario involving two users and real life friends, called generically Alice and Bob, who follow the Gazebo F2F protocol steps in order to reach the point where both are authenticated one to the other and can chat in a secure manner over the insecure network.

(!!!) We will see these steps through Alice's eyes, Bob just doing similar things (when he is not mentioned). In figures where 2 pictures are placed side by side, the left one is Alice's and the right one is Bob's.

When Alice starts Gazebo F2F, she should see a frame similar to the one presented in Figure 1. Before she logs in, she has to create an account, which she does, by clicking on the left most icon from the group of 3, that are at the bottom of the frame. A wizard should pop up, wizard that she has to follow in order to create a new account.
The information required can be split in three : personal information – name, location, e-mail, other comments; network related information – network connection type, IP address, workspace and download directory; security related information – username, password, private and session key size. Because the account resides on the local disk, a strong password should be chosen. The session key size should be picked, based on the level of insecurity of the network : if we use the protocol only in a secure local network then a smaller key size can be picked to speed up the transfer process, whereas if we use it over the Internet, even if packets can get delayed a bit, we can choose a larger key size. In the end, Alice's account will be an archive called "alice.gzb" (is she pickes her username to be alice) that resides in path-to-Gazebo/profiles/alice .

Later on, if Alice wants to access her account on a different machine than the one she made her account on, she has to have the ".gzb" file with her. On a different computer, she has to click on the middle icon from the group of 3 on the bottom of the frame. A dialog box, like the one in Figure 2 should appear. There, she has to introduce the path to her archive and the password of her account. On the local machine she can just fill up the username and password fields that are on the login frame, and click on the "Sign In" button. The right most icon (from the group of 3), exits the application.

After she logged in, she should see Gazebo F2F's main frame, and in the bottom left corner, a message stating that the user alice has logged in (Figure 3 - (a) ).

Alice would like now to connect to Bob. After Bob created an account of his own, the two users should exchange their public keys (that are found in path-to-Gazebo/profiles/username), which are unique identifiers.
In the main frame, Alice clicks on the Profiles tab (Figure 3 – (b)) which pops up the Profile Manager. She then clicks on the Add button (Figure 3 – (c)) and a form, like the one the red arrow points to, pops up. She fills in the required fields, the last of them being Bob's identifier ( the public key we took from him) (Figure 3 – (e)). Bob does the same, and fills in a form like the one shown in Figure 4, providing Alice's public key as the unique identifier.

After this step, each user will have a certificate (that resulted from filling up the form) that must be exchanged with the other one. The exchange is mandatory to be made in an out-of-band manner (like face-to-face) and not over e-mail or any other network communication means. Anyway, other secrets have to be shared also (how to answer the questions) and although the certificates are encrypted, they could be intercepted and possibly get broken, if sending them over the network.
After the physical exchange, those certificates have to be loaded in both users' accounts. This is done by selecting from Profiles, the item on top of which we want to load the certificate, and press the Load Certificate button (Figure 3 – (d)). The left part of Figure 5 shows the dialog box that appears when Alice tries to load the certificate she received from Bob (the right part is when Bob loads the certificate received from Alice). She also has to answer a question (this is for security reasons), the answer being provided by Bob in their face-to-face meating.

Figure 5 : Loading certificates

After the certificates have been loaded, Alice and Bob are called penders, and a new Pendings entry is
added in the main frame's tree (Figure 6).

Figure 6 : Pendings entries

At some point, when both users are online, the protocol that "transforms" penders to friends, takes place. A dialog box on each side pops up, and each user is asked if accepts the friendship offer. There is also presented each pender's question and answer (Figure 7). If a malicious user would intercept the protocol communication and would want to forge someone's identity, he would not know how to answer these questions, because they are personal secrets and are shared only between friends.

Figure 7 : Friendship offer

The Pendings entry of each is removed, and a Friends entry is added to each main frame's tree. Now, both users are authenticated to each other, and each of them is called a friend. If they are still online or when they both get online, they automatically connect one to the other (Figure 8).

Figure 8 : Users online

Gazebo F2F users can now chat in a secure manner (Figure 9).

Figure 9 : A chat service session

---

Copyright © 2009 Stefan Silvestru All Rights Reserved.