20-CS-6053 Network Security Spring 2017
Lab 1

Secret Key, Public Key, Hash Algorithms, IPSec, Kerberos, Authentication, more

Monitor Communication Protocol

Communication Modes:
    The protocol has two modes of communication: Directive and Command modes. Your application must support both of these modes for a variety of cases, which are described herein.
Communication Styles:
There are two styles of communication that can occur:
  • Participant to Monitor (Participant makes active connection to Monitor's server)
  • Monitor to Participant (Monitor makes active connection to Participant's server)

In all cases, regardless of the direction of the connection, the Monitor always operates in Directive mode, and the participant in question is required to operate in Command mode.

Server and Clients:
Each participant must have one server process (which may "spin off" many passive client processes), and at least one active client process.

The server process listens as a ServerSocket() on a particular port, awaiting connections. For extra credit, the server may be capable of handling more than one connection at a time. This case may happen since the Monitor is designed to be able to make frequent (and sometimes simultaneous!) connections to the server process. In this case, each connection should generate a passive client process to handle that connection. (Note: Java Threads will come in handy here)

Each participant also must have at least one active client process, but can have as many as the programmer desires. Active client processes are used to make proactive connections to the server ports of the Monitor. At startup, the very first task of the first active client process will be to make a connection to the Monitor's server and go through a Registration Transaction.

Note that active client processes should not interfere with (although they may need to internally communicate with) the participant's own server process. They should be almost completely independent of each other. Clearly, some communication of internal state will be required, but on the whole, they should operate independently.

Active client processes differ from passive client processes in one key area. The passive client process is started only when the Monitor makes a connection to the Participant's server port and makes some requests. The active client process is that which goes out and makes connections to the Monitor's server port.

The server process for the Monitor will always be on the machine helios.ececs.uc.edu on port 8180. In addition, all active client processes from the Monitor will generate from helios.ececs.uc.edu.

Directive Mode
Directive mode is the mode that the Monitor is always in. When communicating with a Paticipant, the Participant is in the Command mode.
In Directive mode, the Monitor will send a series of Message Groups across the socket. Each message group consists of one or more Directives. Each Directive is on a separate line. After each Message Group, the Monitor waits for the Participant to issue a single Command. (More information about Commands is below).
The Directives:
(Note that all interactions are case insensitive). All Directives are in the form:
ARG1 through ARGN and/or STRING are optional or not depending on each particular Directive. A given ARGI will be guaranteed to contain no whitespace. Sometimes, a given ARGI will be guaranteed to always be the exact same token. In these cases, that literal token will be listed in the tables below.

STRING is usually a free-form string, which can contain whitespace.

Directives are always terminated by a newline.

Directive Description
WAITING: Indicates that the current Message Group is complete, and the Monitor awaits a Command from the Participant.
REQUIRE: ARG1 Indicates that the Monitor is demanding that the next Command from the Participant be ARG1. If the Participant sends some Command besides ARG1, the most likely result will be a COMMAND_ERROR: Directive, and another REQUIRE: ARG1 Directive in the next Message Group.
COMMAND_ERROR: STRING Indicates that an error occurred during the processing of the last Command. This could be because of invalid arguments, incorrect number of arguments, an unexpected Command (e.g., if a different Command is currently REQUIREd), or because a Command is not yet implemented. The STRING will be a diagnostic error message. COMMAND_ERROR only appears in a Message Group if there was an error with the last command.
COMMENT: STRING This Directive is used to give verbose output on the operation of various Commands, and to give general feedback about a variety of things. STRING is completely free-form, and more than likely will only be useful to human eyes for debugging. Not every Message Group is guaranteed to have a COMMENT directive.
RESULT: ARG1 STRING This Directive is used to return results from the last Command issued by the Participant. ARG1 will be the Command for which these are results. STRING, in this case, will not be free-form. Rather, it will be in the format as described by the result format for the Command, ARG1. In many cases, particularly with those commands that generate no results, STRING will be the empty string. Note that the RESULT: Directive does not appear when there is an error executing a given command. See the COMMAND_ERROR Directive.
PARTICIPANT_PASSWORD_CHECKSUM: ARG1 This Directive is sent by the Monitor to authenticate itself to the participant. ARG1 is a SHA-1 digest of the participant's password, represented in hexadecimal. This directive is most useful when the participant receives a connection on its server port. The Monitor will always have this Directive in the first Message Group that it sends during an active client connection. However, it is up to the participant to verify that ARG1 does, in fact, authenticate the Monitor properly. Note that some participants may be attempting to impersonate the Monitor!
Message Groups:
A Message Group is defined as a sequence of N Directives, one per line. A Message Group also has the following properties:
  • N >= 1
  • Each line contains one and only one Directive, each terminated by a newline character
  • The last Directive is WAITING:, unless the Monitor is terminating the connection, in which case the Message Group will not end with WAITING:, but instead will end with the an end of file marker.

Command Mode
The Commands:
(Note that all interactions are case insensitive).

All Commands are in the form:
ARG1 through ARGN are optional or not, depending on each particular Command. A given ARGI will be guaranteed to contain no whitespace. Sometimes, a given ARGI will be guaranteed to always be the exact same token. In these cases, that literal token will be listed in the tables below.

Commands are always terminated by a newline.

The following table of commands are used in all transactions:

Command Description Result
IDENT ARG1 ARG2 This command is used to send the Participant's identity to the Monitor. A participant's identity is not a secret---like a username, it is the method by which others (including the Monitor) identify the participant. ARG1 is the identity of the username. ARG2 is optional. If ARG2 is sent, it should be the Participant's portion that is needed to do shared-secret discovery (that is, the participant's Diffie-Hellman public key - see the Cryptography section below for details). The result is
ARG1 is optional, and only appears if cryptography was requested. If it was requested, then ARG1 will be the Monitor's Diffie-Hellman public key that the participant needs to compute the shared secret (see the Cryptography section below for details).
QUIT This command terminates the current connection. The result is
In addition, note that the Message Group that follows this Command will not contain the WAITING: Directive, as the connection will be closed.
PASSWORD ARG1 This command is used to transmit the Participant's password to the Monitor. ARG1 is the Participant's password. The Monitor sometimes sends REQUIRE: PASSWORD after a successful IDENT command. Note that this command is a bootstrap for secure communications with the Monitor later, so the participant should use other means to verify that the request definitely came from the Monitor. The result is
which is sent in the Message Group following the Command invocation. STRING is an alphanumeric string with no whitespace that is the Participant-specific Monitor password (sometimes called a "cookie"). This password ("cookie") is different from the Participant's own password. This password ("cookie") should be used with the ALIVE command to identify the Participant to the Monitor.
CHANGE_PASSWORD ARG1 ARG2 This command is used to request a change in the Participant password and the Participant-specific Monitor password. ARG1 is the Participant's old password (the one currently in use). ARG2 is the new password that the Participant would like to use from this time forward. Note that the Password is only changed if the command successfully returns a RESULT: Directive in the next Message Group. The result is
which is sent in the Message Group following the Command invocation. STRING is an alphanumeric string with no whitespace that is the Participant-specific Monitor password (sometimes called a "cookie"). This new Participant-specific Monitor password will be different from before. The CHANGE_PASSWORD command not only allows the participant to change the participant password, but also automatically changes the participant-specific monitor password ("cookie"). Note that Participants should be careful with this command. It is recommended that it be sent first in any set of transactions. Participants may abuse the fact that the Monitor gives 180 seconds for a connection, however, connections should never last that long. If the CHANGE_PASSWORD command is sent at the end of one of these "marathon" connections, participants may be cut off before they can receive the new Monitor password, and may be locked out.
HOST_PORT ARG1 ARG2 This Command is always sent by an active client process of a Participant to the Monitor. It is used by the Participant to inform the Monitor of the hostname and port the Participant currently lives on. ARG1 should be the fully qualified DNS name of the host where the server process of the Participant is running. ARG2 should be the integer port number (between 2048 and 65000, inclusive) where the server Socket for the Participant is running on. Note: This Command will only be successful if there is currently a server process for the Participant running on the given hostname and port. The result is
HOST_NAME is the fully qualified DNS hostname that the Monitor was able to identify you as, and PORT is the port where you live.
SIGN_OFF This command is used to tell the Monitor to "forget about the Participant". The Monitor "forgets about the Participant" in two ways. First, it forgets what host and port the Participant's server is on. This means that the HOST_PORT will be REQUIRE: the next time the Participant connects to the Monitor with an active client connection. In addition, the Monitor will "forget about the Participant" by invalidating the current Participant-specific Monitor password for the Participant. This means that the Participant will get a PASSWORD command REQUIRE: the next time that the Participant connects to the Monitor with an active client connection. Note that if you execute this command, the Monitor will consider that you are not alive, until you again send the HOST_PORT command. The result is
in the Message Group following the Command invocation.
ALIVE ARG1 This Command is sent to indicate to the Monitor that the Participant is alive. ARG1 should be the Participant-specific Monitor password ("cookie") that was given to the Participant by the Monitor as a RESULT: of the PASSWORD Command. If ARG1 is not the write password ("cookie"), a COMMAND_ERROR: will and the Participant will not be counted as alive. The result is
RESULT: ALIVE Identity has been verified
GET_GAME_IDENTS This command is used to get a list of identities of Participants who are communicating with the Monitor. This is useful, for example, if you want to know who you can attack. The result is
There will be N arguments in the response. Each argument will be the identity of another Participant who is currently communicating with the monitor.
RANDOM_PARTICIPANT_HOST_PORT This command is used to ask the Monitor for a host port of some random identity. This is useful when a Participant wishes to attack another Participant. A COMMAND_ERROR occurs if you have already asked for a random Participant host and port recently. The result is
ARG1 will be the identity of the Participant, ARG2 will be the most recent host on which that Participant has been seen, and ARG3 will be the port on which that Participant lives and/or the host and port where that Participant was most recently seen.
PARTICIPANT_HOST_PORT ARG1 This command is used to ask the Monitor for a host port of some given Participant's identity. The command costs some points (to be determined). A COMMAND_ERROR occurs if the Participant issuing the command does not have enough points to issue the command. A COMMAND_ERROR also occurs if the identity is not known and/or the requested Participant is not currently alive. Note that the points are deducted even if the identity is not known or the Participant is not alive. The result is
ARG1 will be the identity of the Participant, ARG2 will be the most recent host on which that Participant has been seen, and ARG3 will be the port on which that Participant lives and/or the host and port where that Participant was most recently seen.

Participants may communicate securely (maybe) with the Monitor. The Monitor implements Diffie-Hellman shared-secret exchange to exchange a key with the Participants. This key is then used as the key for Karn symmetric encryption. For Diffie-Hellman to work, Participants will need the proper P and G values. We have created a class, called DHKey that holds these values. See PlantDHKey.java for class information needed to read this key from file. To get the DH values for this assignment, participants need to read the DHKey object from the file called DHKey. Reading this file and using its contents is illustrated in file DiffieHellmanExchange.java where the class DHKey is implemented in PlantDHKey.java. After computing a secret shared with the monitor, the participant uses that secret to create an object which can encrypt plaintext and decrypt ciphertext. We illustrate with the file Karn.java. The constructor of this class takes a secret (in the form of a BigInteger) as argument, sets up the Karn key arrays, and creates the Message Digest (Hash) which is used for encryption/decryption. The class offers two methods: one which encrypts plaintext, given as a String object, and one which decrypts ciphertext, given as a String object. We have only partially implemented all these functions in the above file: it is left to the student to complete the implementation. The files KarnTestServer.java, and KarnTestClient.java may be used to illustrate and test the function of the Diffie-Hellman and Karn classes as required for communication with the Monitor. Usage in Unix is as follows:
    java KarnTestServer &
    java KarnTestClient "The quick brown fox jumped over the lazy dog's back"
You may use the file Karn.class which contains a complete implementation of the Karn class until you build your own complete version.

Note that when using these routines, each line from the Monitor is encrypted as a separate block of ciphertext that must be decrypted.


A sequence such as: Message_Group_0 Command_0 Message_Group_1 Command_1 ... Message_Group_N QUIT
can be categorized as a transaction.

Frequently, the Monitor will use a series of REQUIRE: Directives to force a transaction to play out in a particular way. Thus, transactions tend to "emerge" in particular formats. These transactions are not a formalized portion of the protocol, but considering the transaction examples given here may help you consider useful designs for your Participant.

Below are some common transactions that you will probably encounter. You may find that looking at these interactions will help to figure out how the protocol plays out. However, note that these are only a few of the types of transactions that you will encounter, and they are presented for pedagogical purposes only. Do not assume that all transactions will work out like this!

In the transaction examples below, text that is sent by the Monitor is in red. Text that is sent by the Participant (you) is in green. Finally, comments (things that do not appear at all but are added to explain what is going on) appear in black.

Registration Transaction:
This transaction is initiated when the active client of the Participant connects to the Monitor for the first time, or after having restarted on a new hostname and/or port. The transaction goes as follows.

COMMENT: Monitor Version 2.2
Ident WHO_I_AM

Note here the RESULT:. This means that NRMVEXUHFELPNN is our Monitor password ("cookie"). We will need that later on.

Now, suppose that you ignored this REQUIRE: and sent a different command?
COMMAND_ERROR: Command, PARTICIPANT_STATUS, was not expected in this context, please send HOST_PORT

Since you ignored the directive and did not send the command that was being REQUIRE:'d, a COMMAND_ERROR: was generated, and a new REQUIRE: of the same command has been given.

Now, you answer properly:
HOST_PORT myhost.occ.uc.edu 7891

At this point, before responding to you, the Monitor will attempt to contact the machine myhost.occ.uc.edu on port 7891. The transaction that takes place on that connection will be an Are-You-Alive? transaction, described below. Once that transaction is completed successfully on the other port. The result you see back on this connection is:

At this point, you can send any valid command, since there is no RESULT: Directive in the Message Group.

Are-You-Alive Transaction:
The Monitor initiates an Are-You-Alive Transaction frequently. It is done on demand when the HOST_PORT command is sent on a client connection to the monitor. In addition, the Monitor uses the Are-You-Alive connection to verify you are online and to determine if you have met the requisite uptime for receiving your daily allotment of resources.

The Are-You-Alive Transaction is initiated by a Monitor client to Participant A's server port. Here is what the Transaction looks like:
COMMENT: Monitor Version 2.2
Ident WHO_I_AM
PARTICIPANT_PASSWORD_CHECKSUM: 36c00161466dc725834a9787fc0f18497361f0a6
RESULT: ALIVE Identity has been verified.

Operation Transaction:
This transaction is almost the same as the Registration Transaction. However, note that the HOST_PORT command is not required, since the Monitor was able to verify that you still "live" on the same port as when you last registered.
COMMENT: Monitor Version 2.2
Ident WHO_I_AM
RESULT: ALIVE Identity has been verified.

Note that the Operation Transaction is frequently used when you need to get to a point where you need to send free-form commands to the Monitor (e.g., PARTICIPANT_STATUS). You should expect that most active connections you make the monitor to start out with something like the Operation Transaction, and then leave you in a mode where you can send any command you choose to the Monitor, as you see above.

Operation Transaction with changed HOST_PORT:
This transaction is a variant of the Operation Transaction discussed above. If your host and/or port have changed, the Monitor will need to require the HOST_PORT command again to get a the new host and/or port.
COMMENT: Monitor Version 2.2
Ident WHO_I_AM
RESULT: ALIVE Identity has been verified.
COMMENT: unable to connect to host MYHOST.OCC.UC.EDU on port 7891
HOST_PORT myhost.occ.uc.edu 9971

At this point, the Monitor will have to carry out an Are-You-Alive transaction on the new host and port.



In general, participants are permitted to do anything that is not in violation of state, federal, local law, and not in violation University of Cincinnati, or College of Engineering rules, regulations, and computer usage policies.

For example, impersonation of the Monitor is completely permitted. In addition, impersonation of another Participant to the Monitor.

The following things are explicitly prohibited, and are considered poor conduct:

  • Running a so-called Denial of Service attack on the Monitor server, any Participant's server, or on any machine on the University of Cincinnati network or the Internet. (This includes sending multiple, rapid requests over and over to tie up a machine or server to stop it from getting any work done, or attempting to "crash" someone's machine or server.)

Copyright (©) 1998 and 1999 by Bradley M. Kuhn and John Franco.

Permission is granted to make and distribute verbatim copies of this document materials provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copying, provided also that they are marked clearly as modified versions, that the authors' names and title are unchanged (though subtitles and additional authors' names may be added), and that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.