CS 337 Project 2 Human-To-Host Simulator Instructor: Plaxton Judah - - PDF document

CS 337 Project 2 Human-To-Host Simulator Instructor: Plaxton

Judah De Paula Greg Plaxton Due March 8 (Monday) at 8:00pm

1 Overview

Your task is to simulate a system in which a dynamic collection of humans access a dynamic collection of hosts. Initially, there are no humans or hosts in the system. The simulation processes a sequence of commands, including commands to create and destroy humans and hosts. Two of the commands (create-host and h2h-keygen) involve simulating the creation of an RSA key pair, consisting of a public key and a private key. We assume that the public key is encoded as a human-readable string (i.e., no control characters), followed by a newline. The significance of this assumption is that we can build up a set of public keys in a single file, one per line, by simply appending together various public keys. The simulation should assume that whenever a new RSA key pair is generated, it is different from any previously generated pair. Remark: This assignment is loosely based on ssh and its associated tools such as scp and ssh-agent. However, our h2h protocol attempts to model only a fragment of the capabilities of ssh, and even within this fragment, there are discrepancies between the behavior of ssh and h2h. Accordingly, the student should not rely on ssh documentation to clarify any of the project details.

2 Commands

Before proceeding to define all of the commands to be processed by the simulator, we mention a few notational conventions. First, when we define a command, we indicate required arguments in square brackets and optional arguments in parentheses. Lowercase letters and the the colon and @ symbols simply represent the corresponding characters. An argument of the form “{ foo | bar }” denotes either “foo” or “bar”. Throughout this section, the symbols A through H denote arbitrary nonempty strings of digits and lowercase letters. Such strings are used as labels for some of the simulated entities. Each command has an associated precondition. If this precondition is not satisfied, the com- mand is a no-op. In the case of a command such as h2h-connect that returns success or failure, the command is considered to fail whenever the precondition is not satisfied. The command create-host [A] {forwarding | noforwarding} precondition: host A is undefined 1

creates a new host A with “forwarding” enabled or disabled as indicated by the second argument. We will see the significance of the forwarding attribute later on. When a host is created it is assigned a new RSA key pair. Each host can have an arbitrary number of user accounts. When a host is created, it does not have any accounts. The command create-account [A@B] [C] {forwarding | noforwarding} precondition: host B is defined and account A@B is undefined creates account A@B with password C and with forwarding configured as indicated. The simulation also models a set of humans who access various accounts. Initially, the set of humans is empty. The command create-human [A] precondition: human A is undefined creates human A. Initially, a human does not have any information regarding the passwords of any accounts or the passphrases of any private key files. The command password-belief [A] [B@C] [D] precondition: human A is defined updates human A to believe that if account B@C exists, then it has password D. The command password-prompt [A] [B@C] precondition: human A and account B@C are defined determines whether human A has a correct belief as to the current password for account B@C. If so, the command succeeds. Otherwise, the command fails. Each user account can have an arbitrary number of associated shells. As we will see, each shell runs within a specific account under the control of a specific human. The command login [A] [B@C] [D] precondition: human A and account B@C are defined, and shell D is undefined executes the command “password-prompt A B@C”. If the latter command succeeds, a new shell D is created that is running in account B@C under the control of human A. Since it is a login shell, shell D has no parent shell. Later we will see another way to create a shell, via the h2h-shell command, which creates a new shell as a child of an existing shell. The command password [A] [B] precondition: shell A is defined sets the password of the account C@D in which A is running to B, and then executes the command “password-belief E C@D B”, where E denotes the human controlling shell A. The command passphrase-belief [A] [B@C:D] [E] precondition: shell A is defined 2

updates the human controlling shell A to believe that if private key file B@C:D exists and is encrypted, then it has passphrase E. The command passphrase-prompt [A] [B] precondition: shell A is defined and is running in an account containing an encrypted private key file B is used to determine whether the human C controlling shell A has a correct belief as to the current passphrase for private key file B. If so, the command succeeds. Otherwise, the command fails. The command h2h-keygen [A] (B) precondition: shell A is defined generates an RSA key pair. Letting C@D denote the account in which shell A is running, the public and private keys are stored in files C@D:public and C@D:private, respectively. (The previous content

• f these files, if any, is overwritten.) If the optional parameter B is specified, then the private key

file is encrypted using the passphrase B and the command “passphrase-belief A C@D:private B” is executed. The command h2h-verify [A] [B] precondition: shell A and host B are defined is used to determine whether the human C controlling shell A accepts the public key of host B. In

• rder to simplify our simulation, we assume that such keys are always accepted. This acceptance

is recorded by appending the public key of host B to the file D@E:known hosts, where D@E denotes the account in which shell A is running. (If file D@E:known hosts is undefined, then it is created before appending.) The command append [A] [B] [C] precondition: shell A and file D@E:B are defined, where D@E denotes the account in which shell A is running appends file D@E:B to file D@E:C. (If file D@E:C is undefined, then it is created before appending.) The command h2h-agent [A] precondition: shell A is defined creates/destroys an agent process running in shell A (i.e., this command acts as a toggle). Such an agent has an associated set of private keys. When the agent is created, this set is empty. The command h2h-add [A] [B] precondition: (1) shell A is defined, (2) an agent is running in shell A, and (3) file D@E:B is defined and contains a single private key, where D@E denotes the account associated with shell A 3

has the following behavior. If the private key file D@E:B is unencrypted, or if it is encrypted and the command “passphrase-prompt A B” succeeds, an unencrypted copy of this private key is added to the set of private keys associated with the agent running in shell A. The command h2h-connect [A] [B@C] precondition: shell A and account B@C are defined determines whether the human D controlling shell A is authorized to connect to account B@C. Before making this determination, we first execute the command “h2h-verify A C”. We then try up to three different approaches to gain access to account B@C: agent-based, key-based (if necessary), and password-based (if necessary). Agent-based: We define the agent serving shell A, if any, as follows. First, if there is an agent running in shell A, then it is the agent serving shell A. Otherwise, we check whether all of the following conditions hold: (1) shell A has a parent shell E running on host F; (2) the account associated with shell E has forwarding enabled; (3) host F has forwarding enabled. If all of these conditions hold, then the agent serving shell A is inductively defined as the agent, if any, serving shell E; otherwise, there is no agent serving shell A. If there is an agent serving shell A, the agent-based approach succeeds if and only if the following two conditions hold: (1) file B@C:authorized keys exists and its contents are the concatenation of some sequence of public keys; (2) the private key corresponding to at least

• ne of the public keys in this sequence is contained in the set of private keys associated with

the agent serving shell A. If there is no agent serving shell A, or if either of the above two conditions is not met, then the agent-based approach fails and we move on to the key-based approach described next. Key-based: Let E@F denote the account associated with shell A. The key-based approach fails immediately unless file E@F:private is defined and contains a (possibly encrypted) private key. If the key-based approach does not fail immediately, we check whether the file E@F:private is

• encrypted. If it is encrypted, we execute the command “passphrase-prompt [A] [private]”; if

the latter command fails, the key-based approach fails. If it succeeds, or if the file E@F:private is unencrypted, the agent-based approach succeeds if and only if the following two conditions hold: (1) file B@C:authorized keys exists and its contents are the concatenation of some sequence of public keys; (2) at least one of the public keys in this sequence corresponds to the private key stored in file E@F:private. If either of these two conditions is not met, the key-based approach fails. If the key-based approach fails, we move on to the password-based approach described next. Password-based: In this approach, we execute the command “password-prompt A B@C”; the password-based approach succeeds if and only if this command succeeds. The command h2h-shell [A] [B@C] [D] precondition: shell A and account B@C are defined, and shell D is undefined provides a second method for creating a shell. First, the command “h2h-connect A B@C” is exe-

• cuted. If the latter command succeeds, a child shell D of shell A is created. The shell D is running

in account B@C under the control of the human controlling shell A. The command 4

h2h-copy [A] (B@C:)[D] (E@F:)[G] precondition: shell A is defined is used for copying files. If the optional string (B@C:) is provided, we execute the command “h2h- connect A B@C”; if this command fails, the h2h-copy command terminates. If the optional string (B@C:) is not provided, we let B@C denote the account associated with shell A in what follows. We now check whether file B@C:D is defined. If not, the copy command terminates. If the optional string (E@F:) is provided, we execute the command “h2h-connect A E@F”; if this command fails, the h2h-copy command terminates. If the optional string (E@F:) is not provided, we let E@F denote the account associated with shell A in what follows. We then copy file B@C:D to file E@F:G, creating the latter file if necessary. In addition, if the human associated with shell A believes that the passphrase associated with file B@C:D is H, we execute the command “passphrase-belief A E@F:G H”. The command destroy-shell [A] precondition: shell A is defined destroys shell A and all of its descendant shells. Any agents associated with these shells are also destroyed. The command destroy-account [A@B] precondition: account A@B is defined destroys all shells associated with account A@B (via the destroy-shell command, so all of their descendant shells are destroyed as well), and then destroys account A@B. The command destroy-host [A] precondition: host A is defined destroys all accounts associated with host A (via the destroy-account command, so all of the descendant shells of these accounts are destroyed as well), and then destroys host A. The command destroy-human [A] precondition: human A is defined destroys all shells controlled by human A, and then destroys human A. Bonus: The command h2h-reachable [A] precondition: human A is defined determines the set of all accounts B@C accessible to human A. Execution of this command does not change the state of the simulation. Remark: Up to 25% additional credit will be given for a simulator that processes this bonus command. 5

3 Input and Output

A command file will list a series of h2h commands. Your simulator will read in this file and process each command sequentially. After each command is executed, a specified output line will need to be printed to a separate file. The input and output classes will be posted on the project web page once they are available. These classes must be used in an unmodified form to preserve compatibility with the grading

• process. The input file is a case-insensitive text file with each line containing either a blank line or

a single command. Each input command has a corresponding output line that echos the input command, followed by an output string. You must use the provided interface class, without modifications, to generate the program output. Example input/output files will be posted on the project web page once they are available.

4 Turnin

Projects will be turned in using the Linux turnin software. Only one submission per group is

• required. The command is:

turnin --submit judah Project 2 [Project Files] See the project protocol document in the projects section of the course website for additional information, including special instructions for submitting late assignments.

5 Questions and Project Clarifications

Questions regarding this project should be posted to the utexas.class.cs337 newsgroup. If certain questions arise repeatedly, a FAQ will be create on the project web page. Any corrections to the project description will be announced on the newsgroup and posted to the project web page. 6