SOFTWARE USER'S MANUAL FOR THE SECURE FILE TRANSFER PROGRAM (SFTP) CONTRACT NO. N60921-87-C-0283 CDRL SEQUENCE NO. A008 28 March 1988 Prepared For: White Oak Laboratory Naval Surface Warfare Center 10901 New Hampshire Avenue Silver Springs, MD 20903 Prepared By: THE BDM CORPORATION 1801 Randolph RD SE Albuquerque, NM 87106 SFTP USER'S MANUAL March 28, 1988 i Foreword The Secure File Transfer Program (SFTP) User's Manual is prepared by The BDM Corporation, 1801 Randolph RD SE, Albuquerque NM 87106 for the Naval Surface Warfare Center, 10901 New Hampshire Avenue, Silver Springs MD 20903, CDRL number A008, contract number N60921-87-C-0283. The Naval Surface Weapons Center contract officer is Mr. Phil Hwang. The primary contributors to this manual from BDM are Dr. David Peercy, SFTP program manager, Mr. Paul Sands, SFTP technical leader, Mr. Fred Magee, and Mr. Dan McKay. SFTP USER'S MANUAL March 28, 1988 ii Change Log Page DATE CHANGE CHANGE SCN PAGES DESCRIPTION ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- | | ----------------|-----------------------------------------------|-------- SFTP USER'S MANUAL March 28, 1988 iii Table of Contents SECURE FILE TRANSFER PROGRAM USER'S MANUAL Section Page 1.0 SCOPE 1 1.1 Identification 1 1.2 Purpose 1 1.3 Organization of Manual 1 2.0 REFERENCED DOCUMENTS 1 3.0 COMPUTER PROGRAM SYSTEM CAPABILITIES 2 3.1 General Description 2 3.2 Functions Performed 6 3.3 Dependencies 6 4.0 FUNCTIONAL DESCRIPTION 8 4.1 Major Functions 8 4.1.1 Command Interpretation Function 8 4.1.2 Send File Function 8 4.1.3 Receive File Function 8 4.1.4 Delete/Refuse File Function 8 4.1.5 Inquire Function 9 4.1.6 Authorization Function 9 4.1.7 Audit Function 10 4.1.8 Status Notification Function 10 4.1.9 Incoming File Spooling Function 10 4.1.10 Outgoing File Spooling Function 10 4.1.11 File Transfer Function 11 4.2 Major Components 11 4.2.1 User Interface Task 11 4.2.2 Command Execution Task 15 4.2.3 TCP/IP Interface Task 15 4.2.4 Get Security Attributes Functions 15 5.0 USER INTERFACE INSTRUCTIONS 16 5.1 User Command Description: SFTP 16 5.2 Security Administrator Command Description 17 SFTP USER'S MANUAL March 28, 1988 iv Section Page 6.0 OPERATING INSTRUCTIONS 17 6.1 Generic Operational Environment 17 6.2 VAX/DEC Operational Environment 21 6.2.1 Description 21 6.2.2 Dependencies 21 6.2.3 Security Provisions 22 6.2.4 Installation Procedure 22 6.2.5 Results of Program Execution 25 6.3 COMPAQ/ALSYS Operational Environment 25 6.3.1 Description 25 6.3.2 Dependencies 27 6.3.3 Security Provisions 27 6.3.4 Installation Procedure 28 6.3.5 Results of Program Execution 29 6.4 Other Computer System Operational Environment 29 6.4.1 Description 29 6.4.2 Dependencies 30 6.4.3 Security Provisions 30 6.4.4 Installation Procedure 31 6.4.5 Results of Program Execution 32 APPENDICES Section Page APPENDIX 10. Glossary of Terms 33 APPENDIX 20. Summary of User Messages 41 APPENDIX 30. Security Administrator Interface 45 Illustrations Figure Page 3-1 SFTP Architecture 3 3-2 DoD Internet Model Protocol Layers 4 3-3 Secure Network Elements 5 4-1 Mapping of Functions to Modules 12 4-2 Top Level SFTP Components 13 4-3 Data Flow Through SFTP Components 14 6-1 General SFTP Operational Environment 18 6-2 VAX-VAX Homogeneous Environment 19 6-3 VAX-COMPAQ Heterogeneous Environment 20 6-4 SFTP Directory System 24 6-5 Example SFTP Inquire Function Screen Output 26 30-1 Security Administrator Interface 48 30-2 Security Administrator Startup Messages 55 30-3 Security Administrator Audit File Messages 56 SFTP USER'S MANUAL March 28, 1988 1.0 SCOPE 1.1 Identification This Software User's Manual (SUM) provides the procedures for executing the Secure File Transfer Program (SFTP). The SFTP provides the user the capability to transfer a file of sensitive information from one computer system to another computer system as long as the transfer satisfies a security policy implemented through a set of security attribute tables specified by a designated security administrator. 1.2 Purpose The purpose of this SUM is to describe the user interface and functional capabilities of the SFTP. The security administrator interface is described in Appendix 30. 1.3 Organization of Manual This SUM is organized to enable the user to determine the necessary procedural steps for using the SFTP. This includes environment installation considerations, preparation of data inputs, explanation of the normal results of the SFTP process, and description of the fault recognition capabilities of the SFTP. The documents referenced in this SUM are listed in section 2. The SFTP system capabilities are described in section 3. A functional description of the SFTP top level components is contained in section 4. The SFTP user instructions are presented in section 5. The SFTP operating procedures in the various operational environments are described in section 6. A glossary of common terms is given in Appendix 10. A summary of User Messages is in Appendix 20. The security administrator interface is described in Appendix 30. 2.0 REFERENCED DOCUMENTS [TCSEC] DoD 5200.28-STD, "Department of Defense Trusted Computer System Evaluation Criteria," Supersedes CSC-STD-001-83, December 1985. [TNI] NCSC-TG-005, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria," National Computer Security Center, Version-1, 31 July 1987. [ISO7498] ISO-STD-7498, "Basic Reference Model for Open Systems Interconnection - Part 2: Security Architecture," DRAFT, 18 June 1987. [MIL1777] MIL-STD-1777, "Internet Protocol Standard," 12 August 1983. [MIL1778] MIL-STD-1778, "Transmission Control Protocol Standards," 12 August 1983. [DOD2167A] DoD-STD-2167A, "Defense System Software Development," DRAFT, 1 April 1987. [SUM] DI-MCCR-800019, "Software User's Manual, Defense System Software Development," DRAFT, 15 August 1986. [MIL1815A] ANSI/MIL-STD-1815A, "Reference Manual for the Ada Programming Language," January 1983. SFTP USER'S MANUAL March 28, 1988 3.0 COMPUTER PROGRAM SYSTEM CAPABILITIES 3.1 General Description The SFTP architecture satisfies the capability to securely send and receive files across a multilevel secure network. On the send side, the SFTP architecture satisfies the capability to obtain file information and routing instructions from a user, check appropriate security provisions of the file and the file routing, and push the file onto the attached network using a standard TCP/IP interface, the Naval Ocean Systems Center (NOSC) TCP/IP Ada Foundations tool, and an appropriate lower layer subnet interface. On the receive side, the SFTP architecture must satisfy the capability to properly log receipt of the file, check security provisions of the file and its recipient, and notify the recipient (or system security administrator) of the file's arrival. The general framework for the architecture is illustrated in figure 3-1. The SFTP implements the transfer protocol to accomplish the necessary interfaces between the user application protocol layer, the TCP/IP protocol layer, and the peer-to-peer SFTP protocol. The SFTP thus executes in the Utility protocol layer of the DoD Internet Model. The general architecture structure of the protocol layers is shown in figure 3-2. The SFTP is designed to execute within a domain controlled by a secure operating system (OS), and to complete the secure transfer of files without degrading the OS security. The SFTP does not make an operating system more secure than its original design. The following minimal system features, corresponding to Class B1 (see references [TCSEC] and [TIN]), are required for secure operation: (1) Sensitivity labels associated with each subject and storage object under the control of the OS must be maintained by the OS. A system call must be provided for SFTP to obtain these labels. (2) Files owned by SFTP must not be accessible to other users without SFTP permission. (Discretionary access controls must be implemented) (3) Untrusted users must not be allowed access to the network, TCP/IP, or the communication lines. The environment of the SFTP executing within the control of a secure operating system while providing the secure transfer of files through the protocol layers is illustrated in figure 3-3. SFTP USER'S MANUAL March 28, 1988 Figure 3-1. SFTP Architecture SFTP USER'S MANUAL March 28, 1988 Figure 3-2. DoD Internet Model Protocol layers SFTP USER'S MANUAL March 28, 1988 Figure 3-3. Secure Network Elements SFTP USER'S MANUAL March 28, 1988 3.2 Functions Performed The SFTP provides a "push" type file transfer capability. Like a mail system, a push file transfer system requires that all transfers be initiated at the sending computer. This limitation is a requirement for a SFTP. The SFTP consists of the following functions: (1) command interpretation (2) send file (3) receive file (4) delete/refuse file (5) inquire (6) authorization (7) audit (8) status (including error) notification (9) incoming file spooling (10) outgoing file spooling (11) file transfer (TCP/IP interface). The network of SFTP users must establish the appropriate access control and routing tables controlled by each node security administrator. The user enters a command "SFTP" along with appropriate parameters according to the function to be performed: send file, receive file, delete/refuse file, or inquire about the status of files being sent/received. The command parameters are parsed for processing. If a file is being sent, then security provisions are checked to determine whether the send can be accomplished. If so, then the file is pushed onto the specified computer system through a TCP/IP/Subnet communications interface to the specified user. The receiving system TCP/IP passes the file to the receiving SFTP which determines whether the receipt of such a file by the receiving (system,user) pair is authorized. If so, the user is notified that a file has been received. When the user inquires about the presence of files, then the file may either be received or refused/deleted. The lower layers Transport/Internet Protocol (TCP/IP) and the subnet protocol layers provide for proper port to port routing through the network, including necessary packetization of the file information and any bulk encipherment. The SFTP could, but does not provide with this version, interfaces for extended security functions of encipherment (data confidentiality), digital signature (non-repudiation), message authentication codes (data integrity), and so forth. 3.3 Dependencies. The SFTP has dependencies in specific interfaces due to the nature of the security provisions being provided, and the specific use of the NOSC TCP/IP prototype tools and Ethernet for the lower layer communication protocols. The nature of these dependencies are: (1) Operating System. SFTP will only provide for a level of secure file transfer supported by the operating system. If the operating system is not secure, then the SFTP file transfer will not be secure. The SFTP depends upon the security protection of the operating system to protect the SFTP execution domain and external files from unauthorized access. The security administrator must be a privileged user. The access control and routing tables input by the security administrator and used by the SFTP for file acceptance/delivery access control must be protected by the operating system. The operating system provides the protected "mailbox" mechanism through which the files can be sent and received. SFTP USER'S MANUAL March 28, 1988 (2) Lower Level Protocols. Although the SFTP design is essentially free from lower level protocol dependencies (i.e., the lower level protocol interface is hidden within a small number of modules), the prototype SFTP implementation is dependent upon the NOSC TCP/IP Ada implementation. In particular, it would be necessary to make minor modifications to the SFTP lower level protocol interface in order for the SFTP to execute in a full packet switch network which has implemented standard TCP/IP. (3) Ada Implementations. SFTP is written to be as portable as possible. However, the current prototype SFTP is written using two validated Ada environments: DEC Ada on the VAX computer family, and ALSYS Ada on the COMPAQ PC computer family. These two SFTP variations use operating system interfaces which represent particular Ada implementation dependencies. These dependencies are isolated in one package: OS_DEPEND. (4) Security. SFTP is designed to satisfy the criteria of reference [TNI] for multilevel security trust for a secure file transfer service which does not degrade the overall trusted security level (e.g., A1) of the network. However, since this version is only a prototype, there are many steps which would need to be completed prior to the certification of SFTP as a trusted software component product/service. In particular, the current informal security model would need to be formally specified and the trusted software part of the SFTP would need to be formally verified. Appropriate security documentation other than this user's manual would also need to be written from the current internal design information. (5) NOSC TCP/IP Software. There are two parts of this software that have been used as part of the SFTP demonstration environment: TCP/IP DEC Ada version, and TCP/IP Telesoft (WICAT/PC) Ada version. Both software packages were developed during the time when mature Ada compilers were not available and were not developed to be commercial products. The DEC Ada version is much superior to the Telesoft-WICAT version in terms of usability. Neither version is of production quality, and should be used only for demonstration purposes. There are many dependencies in the NOSC TCP/IP software including hard coded addresses, lack of a clear "black box" interface (it is required for the Upper Level Protocol to "know" something of the TCP/IP data structures), and inadequate implementation of the internet addressing scheme (four octet of addresses). The WICAT version has never been successfully used, and many changes were necessary so that it would compile in the DEC Ada or ALSYS Ada environments. The NOSC TCP/IP software was not designed to be very portable, so any use of the software on other than a VAX computer with the VMS operating system and the DEC Ada environment will be a significant challenge. SFTP USER'S MANUAL March 28, 1988 4.0 FUNCTIONAL DESCRIPTION 4.1 Major Functions. 4.1.1 Command Interpretation Function. This function provides the interface between a subject and the SFTP. The term subject may be either a person or a process (e. g. an application). Where the application is simply an interactive entry of the "SFTP" command from the user, the command is passed to the SFTP and the application may be viewed as a user. However, the SFTP is sufficiently general to allow an arbitrary application to make requests to the SFTP. The requests to be supported by the Command Interpretation Function include the following: (1) inquire about files which can be received or which have been sent; (2) send a file to another user/system; (3) receive a file which has been sent to the requester. (4) delete/refuse file A complete description of the user "SFTP" command through which the user invokes the above functions is given in Section 5. 4.1.2 Send File Function. This function provides a subject with the capability to send a file to a specified user on a specified system. If the request is permitted by the authorization function, this function creates a mailbox/queue unique to the requesting user for the file to be transferred to the specified user and system. The actual transfer is not a part of this function. The subject must have send privileges (based on the security level and category of the file, the intended recipient, and the remote computer), and must have discretionary and mandatory read permission to the file to be sent. 4.1.3 Receive File Function. This function provides a subject with the capability to access a file which has already been received by the system from another subject. If the request is permitted by the authorization function, then this function will write the received file into the specified output file. The subject must be the owner of the received file, must have receive privileges (based on the security level and category of the received file, the sending subject, and the remote computer), must have mandatory read permission to the received file, and must have discretionary and mandatory write permission to the output file. 4.1.4 Delete/Refuse File Function. This function provides a subject with the capability to delete a file which has been received for that subject. This function will typically be used by a subject to refuse a file, or to delete a file from the "mailbox" after it has been copied to another file by the Receive File Function. The only authorization requirement is that the subject must be the owner (addressee) of the file. SFTP USER'S MANUAL March 28, 1988 4.1.5 Inquire Function. This function informs a subject of the files which have been received for the subject and the status of files which have been sent by the subject. Options of the authorization function will determine whether the user is notified of all files which he owns or only those which he could receive at his present security level, and whether files sent are to be acknowledged as received by the receiving system. The information reported on received files includes: (1) file descriptor (name given it by sender), (2) sender name, (3) sending computer, (4) file security level, (5) file security category, and (6) date and time received. 4.1.6 Authorization Function. This function, based on data provided by the SFTP Security Administrator, allows or denies each request received from a subject. In addition this function accepts or rejects each file which is sent to the SFTP from a remote computer. Generation, editing, and protection of the authorization data base are external functions to the SFTP. This software effort will assume use of existing text editors to maintain the authorization data. Authorization data is informally described in the following subparagraphs. A more formal description of all the authorization files is contained in Appendix 30. 4.1.6.1 Authorization to Send Files. Determined by a list of permissions for each subject. Associated with each possible security level and category of files to be sent a subject may have any of the following send permissions: (1) no permission, (2) permission to send to all users on all computer systems, (3) permission to send to all users at one or more specified computers, (4) permission to send to one or more specified users at one or more specified computers. 4.1.6.2 Authorization to Receive Files. Determined by a list of permissions for each subject. Associated with each possible security level and category of files to be received a subject may have any of the following receive permissions: (1) no permission, (2) permission to receive from all users on all computer systems, (3) permission to receive from all users at one or more specified computers, (4) permission to receive from one or more specified users at one or more specified computers. SFTP USER'S MANUAL March 28, 1988 Permission to receive a file is only permission to be the owner of a file in the file mailbox. The subject still must satisfy the rules of mandatory read permission, which means that the subject (unless privileged) cannot read a file at a higher security level or in a different category than the subject. 4.1.6.3 Authorization to Delete a File from the SpoolIn Directory. Is granted to the owner of every file, regardless of the current security level or category of the owner. 4.1.7 Audit Function. This function creates an entry in an audit file whenever an event occurs for which auditing is enabled. Auditing will be enabled or disabled by the SFTP Security Administrator. The following events will be capable of being audited: (1) receiving a request from a subject, (2) rejecting a request from a subject, (3) completing a request from a subject, (4) receiving a transfer request from another computer, (5) rejecting a transfer request from another computer, (6) completing a transfer request from another computer. 4.1.8 Status Notification Function. This function notifies the requesting subject of the status of requests. Status will include the following: (1) request rejected, (2) request completed without errors, (3) error detected. 4.1.9 Incoming File Spooling Function. This function interacts with the file transfer function to accept or reject incoming files. Accepted files are placed in a unique directory based upon the file's security level until deleted by the owner or deleted by this function due to aging. A file will be accepted if (and only if) all of the following conditions are met: (1) the file does not have a higher security level than the highest level of the receiving system; (2) the file does not have any security category which is not allowed on the receiving system; (3) the intended recipient is authorized to receive the file (4) no unrecoverable errors (including lack of disk space) occur while attempting to accept the file. SFTP USER'S MANUAL March 28, 1988 4.1.10 Outgoing File Spooling Function. This function interacts with the file transfer function to transfer files to other systems. A file is transferred to another system from the user's directory to an SFTP controlled directory, and then onto the designated (system,recipient) pair if and only if all of the following conditions are met: (1) the file does not have a higher security level than the highest level permitted to be transferred to the remote system; (2) the file does not have any security category which is not permitted to be transferred to the remote system; and (3) the sending subject is authorized to send the file to the specified user/system. If the file cannot be sent due to transmission errors, it will remain in the SFTP controlled directory for later retransmission. Files which cannot be transmitted within a specified time will be deleted from the directory. 4.1.11 File Transfer Function. This function interfaces between the Incoming and Outgoing File Spooling Functions and the lower level protocol layers (TCP/IP) to physically coordinate the transfer of a file. 4.2 Major Components. The SFTP functions are accomplished by four major components. These components are: (1) User Interface Task (2) Command Execution Task (3) TCP/IP Interface Task (4) Get Security Attributes Function The SFTP major functions are mapped to the four major components as shown in Figure 4-1. The top level design of the data flow through the major components is shown in Figure 4-2. A more detailed user view of the data flow through the major components is shown in Figure 4-3. A brief description of the major components is contained in the following subsections. 4.2.1 User Interface Task. The User Interface Task (UIT) forms the interface between the use and the Command Execution Task. The user enters the command SFTP with a "command line" of parameters. These parameters include: (1) operation (send, receive, inquire, list) (2) computer system to receive a file (3) user name to receive a file (4) local file name for a send/receive operation The UIT parses the command line and responds as appropriate with a Command Execution Task request. SFTP USER'S MANUAL March 28, 1988 Function Component Module 4.1.1 Command Interpretation UIT Parse_Arguments UIT Do_Request 4.1.2 Send File UIT Do_Send CET Receive_File TCP_Out Outlist_Handler 4.1.3 Receive File UIT Do_Receive CET Send_File TCP_In Inlist_Handler.Receive 4.1.4 Delete/Refuse File UIT Do_Delete TCP_In Inlist_Handler.Delete 4.1.5 Inquire UIT Do_Inquire TCP_In Inlist_Handler.Inquire 4.1.6 Authorization GSA Valid_Send CET Valid_Send GSA Valid_Receive TCP_In Valid_Receive 4.1.7 Audit CET Audit_File_Handler.Enter TCP_In Audit_File_Handler.Enter TCP_Out Audit_File_Handler.Enter 4.1.8 Status Notification UIT Do_Inquire TCP_In Inlist_Handler.Inquire TCP_Out Inlist_Handler.Inquire 4.1.9 Incoming File Spool TCP_In all 4.1.10 Outgoing File Spool TCP_Out all 4.1.11 File Transfer TCP_In Lower_Level_Protocol_Interface TCP_Out Lower_Level_Protocol_Interface UIT - User_Interface_Task CET- Command_Execution_Task GSA - Get_Security_Attributes Figure 4-1. Mapping of Functions to Modules SFTP USER'S MANUAL March 28, 1988 Figure 4-2. Top Level SFTP Data Flow SFTP USER'S MANUAL March 28, 1988 Figure 4-3. Data Flow Through SFTP Major Components SFTP USER'S MANUAL March 28, 1988 4.2.2 Command Execution Task. The Command Execution Task (CET) provides the principle trusted control for the file transfer function. It talks to the various user's UITs, validates and authorizes requests, and logs results. No SFTP transfers are possible without this task running. The SFTP is started by the Security Administrator on multitasking systems. During initialization, the CET reads in the authorization tables, routing tables, and other security related information. Whenever there are files to be sent, the CET starts a TCP_OUT task to handle the request. In addition, the CET controls directories of the files sent and received, and coordinates the transfer of the received files to the proper users when so requested by the user. 4.2.3 TCP/IP Interface Task. The TCP/IP Interface Task provides the direct interface between the SFTP and the lower level TCP/IP protocol function. The TCP/IP Interface Task is composed of two functions: TCP_OUT Task Function and TCP_IN Task Function. The TCP_OUT Task provides the interface for files being sent between the Command Execution Task (CET) and the network. This task interfaces directly to the Naval Oceans System Center (NOSC) TCP/IP Ada Foundation software. This task does not directly perform security functions. Such functions have already been performed by CET. This task provides the following functions: (1) Maintains the OUTLIST directory (files waiting to be sent) (2) Physically sends a file to the TCP/IP protocol (3) Tell user (through CET) about the status of send requests The TCP_IN Task provides the interface between the Command Execution Task (CET) and the network for files to be received. This task interfaces directly to the Naval Oceans System Center (NOSC) TCP/IP Ada Foundation software. This task provides the following functions: (1) Maintains an open request to receive network files (2) Requests security validation on incoming files from the security function (3) Physically accepts/rejects a file from the TCP/IP protocol (4) Maintains the INLIST directory (files received) (5) Tells user (through CET) about available files 4.2.4 Get Security Attributes Function. The Get Security Attributes Function is not a separate task, but consists of procedures in the package OS_DEPEND. This organization is the most logical since the security features available on a computer are largely machine and Operating System dependent. This function is performed primarily by the CET with incoming files being checked through services requested by the TCP_IN Task. This function supports the SFTP security model through the following procedures: (1) VALID_SEND: validate send request; used by CET (2) VALID_RECEIVE: validate receive request; used by CET (3) VALID_SECURITY: validate security policy for security levels; used by TCP_IN SFTP USER'S MANUAL March 28, 1988 5.0 USER INTERFACE INSTRUCTIONS 5.1 User Command Description: SFTP. The user runs the SFTP program by entering a command "SFTP", and a command line of parameters. On most systems this will look like SFTP On Operating Systems which support the "command line" concept, the user types the arguments to the SFTP following the command word which starts the user's copy of the UIT. For example: SFTP -s -cAFWL -uJONES somefile.ext. The operating system provides a call to obtain this information. On systems which do not support commands of this form, the user will be prompted for the command line, which will be read from the screen. The command line specifies the function to be performed, the remote computer and user involved, and the name of the remote and local files. The form is ::= | | ::= ::= | ::= | | | | ::= -q | -i | -l | -r | -s ::= -c | -c ::= -u | -u ::= -f | -f ::= -n | -n ::= ::= ::= ::= -- system dependent ::= ::= | ::= a..z | A..Z | 0..9 | ::= The command has the following meaning: -q inquire Do I have any files to receive? -i inquire Same, plus status of files sent previously. -l list List files available to receive. -r receive Receive a file (must specify -u, -c, -f, -n) -s send Send a file. (must specify -u, -c, -n) The user_name is the name by which the addressee (for a send) or the sender (for a receive) is known on the remote computer. SFTP USER'S MANUAL March 28, 1988 The comp_name is the string by which the remote computer is known. This string corresponds to an entry in the routing table and authorization tables maintained by the system administrator. It is intended that these names be mnemonic rather than TCP addresses. For example, the user might specify NSWCWO (rather than 26.1.0.102) for the NSWC White Oaks computer. The remote name is the identifier, sent by the sending computer, which describes the file. On pathname oriented machines, this will be the last part of the file name (less directories). The user obtains this name by requesting a list (-l). The pathname, which is the location of a file (for a send) or the place to put a file (for a receive) is a pathname on the local system. This specification is system dependent. 5.2 Security Administrator Command Description. The Security Administrator (or an automatic system startup file) initiates execution of the SFTP Command Execution Task by entering a privileged command SASFTP. The command must be installed on the system so that only the Security Administrator (or the system) has the privilege to execute the command. The command syntax is SASFTP where is the pathname of the file SFTP>CONFIG>STRTUP. A detailed description of the Security Administrator interface is contained in Appendix 30. 6.0 OPERATING INSTRUCTIONS 6.1 Generic Operational Environment. The general operational environment for the SFTP is illustrated in the Figure 6-1. The requirements are that each node in the network have an SFTP socket, a lower level TCP/IP protocol interface with SFTP, and a subnet interface with TCP/IP and the carrier network (Local Area Network or Wide Area Network). The network should have a Network Security Administrator to provide coordination across the network concerning security levels, categories, and routing restrictions. Each node should have a Local Security Administrator to coordinate the mapping of Network Security Data to the Local Security Attribute Tables. The SFTP interface at each node with the particular secure operating system must be developed and inserted into the SFTP Security Attribute Modules (VALID_SEND, VALID_RECEIVE, VALID_SECURITY). The security level of the network will depend upon the security level of each component node and its interconnection with other nodes. A homogeneous environment for VAX to VAX file transfers is illustrated in Figure 6-2. A heterogeneous environment for a VAX to COMPAQ file transfer is illustrated in Figure 6-3. The rest of this section describes the general user interface to any SFTP network through the SFTP command input, and the specific operational procedures for the two prototype environments: VAX with DEC Ada environment, and COMPAQ Microcomputer with ALSYS Ada environment. SFTP USER'S MANUAL March 28, 1988 Figure 6-1. General SFTP Operational Environment SFTP USER'S MANUAL March 28, 1988 Figure 6-2. VAX-VAX Homogeneous Environment SFTP USER'S MANUAL March 28, 1988 Figure 6-3. VAX - COMPAQ Heterogeneous Environment SFTP USER'S MANUAL March 28, 1988 6.2 VAX/DEC Ada Environment. 6.2.1 Description. The VAX/DEC Ada environment consists of the following hardware/software components: (1) VAX computer system with VMS operating system (Version 4.4/later) (e.g., VAX 11/780, Microvax, VAX 8250) (2) VAX DEUNA Ethernet board (3) Communication interface from Ethernet board to external nodes: (e.g., Ethernet cable, MICOM communication multiplexor) (4) DEC Ada Compiler and Library System -- Version 1.5 -- Only required for development/modification of software (5) SFTP DEC Ada Library -- Source -- Load Library The only VAX restriction on running the SFTP is to have an interface to a TCP/IP lower level protocol. The SFTP interface to the TCP/IP is contained in one module (Lower_Level_Protocol_Interface) which might need to be changed slightly to work with commercial TCP/IP software other than the NOSC TCP/IP for which it is currently implemented. 6.2.2 Dependencies. The dependencies of the prototype SFTP as implemented to interface with the NOSC TCP/IP DEC Ada version are as follows: (1) DEC Ada Packages (Required for SFTP) -- CALENDAR -- *CONDITION_HANDLING -- DIRECT_IO -- IO_EXCEPTIONS -- *RMS_ASYNCH_OPERATIONS -- *STARLET -- SYSTEM -- *TASKING_SERVICES -- TEXT_IO -- UNCHECKED_CONVERSIONS -- UNCHECKED_DEALLOCATION * - DEC Ada specific (2) DEC Ada Packages (Required for TCP/IP) -- CALENDAR -- *CONDITION_HANDLING -- IO_EXCEPTIONS -- *RMS_ASYNCH_OPERATIONS -- *STARLET -- SYSTEM -- *TASKING_SERVICES -- TEXT_IO -- UNCHECKED_CONVERSIONS * - DEC Provided Packages SFTP USER'S MANUAL March 28, 1988 (3) Subnet Ethernet Board -- DEC DEUNA Board The NOSC TCP/IP DEC Ada version has been modified to provide a better "black box" interface with SFTP. There are also several internal machine dependencies (e.g., hard coded addresses, hard coded buffer pointer use, unique use of overflow for address manipulation) that make the NOSC TCP/IP very machine and Ada environment dependent. 6.2.3 Security Provisions. The VAX VMS operating system (e.g., Version 4.4) is rated at the C2 security level, which only provides discretionary access controlled protection (see reference [TCSEC]). Thus, the level of security protection provided by the SFTP can be no higher than C2. Furthermore, the operating system dependent security attribute functions provided by the SFTP require an interface to the operating system to determine user's security level and object file sensitivity level. This generally requires the operating system to provide mandatory access control capabilities (e.g., at least a level B1). Consequently, the implementation of the SFTP for the VAX VMS only provides security attribute interface functions which are "hooks" for an actual interface to a specific secure operating system such as the Honeywell Secure Communications Processor (SCOMP) operating system. The overall implication for running an SFTP network with node VAX computer systems is that the network would have to be run in a "system high" mode. 6.2.4 Installation Procedure. The necessary software for execution of the SFTP in the VAX DEC Ada environment is delivered on two tapes (SFTP and TCP/IP)in DEC backup format. There are three file types on the SFTP tape: (1) [SFTP_Source] - all files named .ADA (2) [SFTP_Command]- all files named .COM (3) [SFTP_SecAdm] - all files named .TXT The SFTP Users Manual (this document) is supplied on a 5 1/4 floppy diskette in WORDSTAR 4.0 format. The SFTP_Command files include: (1) Compile_SFTP_UIT_VAX (2) Compile_SFTP_CET_VAX (3) Link_SFTP_UIT_VAX (4) Link_SFTP_CET_VAX There are three file types on the TCP/IP tape: (1) [TCPIP_Source] - all files named .ADA (2) [TCPIP_Command]- all files named .COM (3) [TCPIP_Users_Manual] - TCPUSERS.MAN The TCPIP_Command files include: (1) Compile_TCPIP_VAX (2) Link_TCPIP_VAX SFTP USER'S MANUAL March 28, 1988 The following installation sequence illustrates what is required to make the prototype SFTP operational on a VAX with the DEC Ada environment. The illustrated directories and various names could be appropriately modified by experienced personnel. (1) Create an SFTP directory as illustrated in Figure 6-4. (2) Load SFTP source, command, and text files from the SFTP tape into the SFTP root directory. (Text files are only for examples.) (3) Load TCP/IP source and command files from the TCPIP tape into the SFTP root directory. (4) Create an Ada program library in the SFTP root directory (note that multiple program libraries could be established, one for SFTP_UIT, SFTP_CET, TCPIP. (5) Compile SFTP_UIT and SFTP_CET source modules into the Ada program library using the SFTP commands COMPILE_SFTP_UIT_VAX.COM and COMPILE_SFTP_CET_VAX.COM, respectively. Link the UIT and CET processes using LINK_SFTP_UIT_VAX.COM and LINK_SFTP_CET_VAX.COM, respectively. (6) Modify TCP/IP source as follows: -- SUBNET_CALLS: set position dependent addresses for all hosts on the planned network in the ADDRESS_TABLE array. Note that this array must be identical for all hosts on the network. -- SUBNET_CALLS: set DEVNAME variable to the name of the VAX Ethernet board. -- IP_GLOBALS: set WHOAMI constant to indicate position in ADDRESS_TABLE for local host. (7) Compile TCP/IP source modules into the Ada program library using the TCP/IP command COMPILE_TCPIP_VAX.COM. Link TCP/IP process using the command LINK_TCPIP_VAX.COM. (8) Create appropriate Security Administrator text files. (See SFTP .txt files for examples from the SFTP demonstration.) The security attribute table files are formatted according to Appendix 30. (9) Set system privileges for the secure SFTP directory account manager (e.g., Security Administrator) to include minimally: -- PRMMBX, can establish permanent mailbox -- SYSNAM, can put permanent mailbox name into system logical table (10) Put SFTP command in System Startup File for general use by the "PUBLIC" with associated privileges. (11) Put SASFTP command in the protected SFTP directory, or in the System Startup File for automatic activation when the system is brought up (cold/warm start). (12) Include TCP/IP initiation in the system startup, or at least start the TCP/IP/Ethernet board processes. (13) If the SASFTP command is not executed as part of the system startup, then the Security Administrator should enter the "SASFTP" command to instantiate the CET process. (14) Users can now execute the "SFTP" command to send/receive/ inquire/list files. SFTP USER'S MANUAL March 28, 1988 Figure 6-4. SFTP Directory System SFTP USER'S MANUAL March 28, 1988 6.2.5 Results of Program Execution The results of executing SFTP depend upon the function - send, receive, refuse/delete, or inquire - that the user executes. The general format for the output response is: := SFTP := := SFTP: The is only shown for an "inquire" function. See figure 6-5 for an example of the table format. The is a one-line message which indicates the end result of the command function processed. The possible messages and user responses are shown in Appendix 20. Any messages that are not prefaced by the "SFTP:" are sent by the system, and users should take the appropriate action based upon the message. 6.3 COMPAQ/ALSYS Ada Environment. 6.3.1 Description. The COMPAQ/ALSYS Ada environment consists of the following hardware/software components: (1) COMPAQ Microcomputer with MSDOS operating system (Version 3.0) (e.g., COMPAQ Portable III, or any Microcomputer that has the other required capabilities) (2) 3-COM Ethernet board (any micro Ethernet board should work but the NOSC TCP/IP interface would need to be modified) (3) Communication interface to external nodes: (e.g., Ethernet cable, MODEM and asynchronous software interface between port and NOSC TCP/IP to bypass Ethernet board) (4) ALSYS Ada Compiler and Library System -- Version 3.2 -- Only required for development/modification of software (5) SFTP ALSYS Ada Library -- Source -- Library Load The only PC restriction on running the SFTP is to have an interface to a TCP/IP lower level protocol. The SFTP interface to the TCP/IP is contained in one module (Lower_Level_Protocol_Interface) which would need to be changed slightly to work with commercial TCP/IP software other than the NOSC TCP/IP. The TCP/IP protocol would need an interface with some PC subnet capability, for example, an Ethernet subnet or an RS-232 asynchronous port interface. The MSDOS operating system is not secure. The microcomputer must be operated in a dedicated security mode while on the network. SFTP USER'S MANUAL March 28, 1988 Figure 6-5. Example SFTP Inquire Function Screen Output SFTP USER'S MANUAL March 28, 1988 6.3.2 Dependencies. The dependencies of the prototype SFTP as implemented to interface with the NOSC TCP/IP PC (WICAT) Ada version are as follows: (1) ALSYS Ada Packages (Required for SFTP) -- CALENDAR -- +CONDITION_HANDLING -- DIRECT_IO -- *DOS -- IO_EXCEPTIONS -- +RMS_ASYNCH_OPERATIONS -- +STARLET -- SYSTEM -- +TASKING_SERVICES -- TEXT_IO -- UNCHECKED_CONVERSIONS -- UNCHECKED_DEALLOCATION -- *UNSIGNED + - Contain ALSYS Ada specific interfaces to DOS system functions to emulate the DEC packages * - ALSYS Provided Package (2) ALSYS Ada Packages (Required for TCP/IP) -- CALENDAR -- *DOS -- IO_EXCEPTIONS -- SYSTEM -- TEXT_IO -- UNCHECKED_CONVERSIONS -- *UNSIGNED * - ALSYS Provided Package (3) Subnet Ethernet Board -- 3-COM Board -- Ethernet Local Area Network The NOSC TCP/IP Microcomputer (WICAT) version has been modified to provide a better "black box" interface with SFTP. There are also several internal machine dependencies (e.g., hard coded addresses, hard coded buffer pointer use). Invalid Ada software has been changed in an attempt to make the NOSC TCP/IP (WICAT) workable to test the prototype SFTP in a microcomputer environment. The NOSC TCP/IP (WICAT) version is very machine and Ada environment dependent, and has not been completely implemented and tested. SFTP USER'S MANUAL March 28, 1988 6.3.3 Security Provisions. The MSDOS microcomputer operating system (e.g., Version 3.0) is rated at the D security level, which provides very little security protection (see reference [TCSEC]). Thus, the level of security protection provided by the SFTP can be no higher than D, except as the microcomputer is run as a dedicated network node and other protection procedures are in effect. The operating system dependent security attribute functions provided by the SFTP require an interface to the operating system to determine user's security level and object file sensitivity level. This generally requires the operating system to provide mandatory access control capabilities (e.g., at least a level B1). Consequently, the implementation of the SFTP for the microcomputer only provides security attribute interface functions which are "hooks" for the actual interface to a specific secure operating system such as a dual processor microcomputer implementation with a secure operating system shell, for example the Honeywell Secure Communications Processor (SCOMP) operating system, around the MSDOS. The overall implication for running an SFTP network with node microcomputer computer systems is that the network would have to be run in a such a manner to assure through procedures that the microcomputer is run in "dedicated" mode while on the network. 6.3.4 Installation Procedure. The installation procedure for the COMPAQ PC with the ALSYS Ada environment is similar to the procedure for the VAX environment. The primary differences are that the SFTP/TCP/IP acts as a single bound process on the COMPAQ PC, and there are no special security features on the COMPAQ PC similar to the VAX system privileges. The necessary software for execution of the SFTP in the COMPAQ PC Ada environment is delivered on two sets of 360K floppy (5 1/4) diskettes (SFTP and TCP/IP) in MSDOS format. There are four file types on the SFTP diskettes: (1) [SFTP_Source] - all files named .ADA (2) [SFTP_Command]- all files named .BAT (3) [SFTP_SecAdm] - all files named .TXT (4) [SFTP_Users_Manual] - SFTPUSER.MAN, no figures, WORDSTAR 4.0 The SFTP_Command files include: (1) Compile_SFTP_UIT_PC (2) Compile_SFTP_CET_PC (3) Link_SFTP_TCP_IP_PC There are three file types on the TCP/IP diskettes: (1) [TCPIP_Source] - all files named .ADA (2) [TCPIP_Command]- all files named .BAT (3) [TCPIP_Users_Manual] - USERS.MAN SFTP USER'S MANUAL March 28, 1988 The TCPIP_Command files include: (1) Compile_TCPIP_PC The following installation sequence illustrates what is required to make the prototype SFTP operational on a PC with the ALSYS Ada environment. The illustrated directories and various names could be appropriately modified by experienced personnel. (1) Create an SFTP directory as illustrated in Figure 6-2. (2) Load SFTP source, command, and text files from the SFTP diskette into the SFTP root directory. (Text files are only for examples.) (3) Load TCP/IP source and command files from the TCPIP diskettes into the SFTP root directory. (4) Create an Ada program library in the SFTP root directory (note that multiple program libraries could be established, one for SFTP_UIT, SFTP_CET, TCPIP. (5) Compile SFTP_UIT and SFTP_CET source modules into the Ada program library using the SFTP commands COMPILE_SFTP_UIT_PC.BAT and COMPILE_SFTP_CET_PC.BAT, respectively. (6) Modify TCP/IP source as follows: -- SUBNET_CALLS: set position dependent addresses for all hosts on the planned network in the ADDRESS_TABLE array. Note that this array must be identical for all hosts on the network. -- SUBNET_CALLS: set DEVNAME variable to the name of the VAX Ethernet board. -- IP_GLOBALS: set WHOAMI constant to indicate position in ADDRESS_TABLE for local host. -- there are many other possible changes that may be required do to the TCP/IP (WICAT) version being used: use of a standard TCP/IP package on the PC with modifications of the SFTP software may be preferable. (7) Compile TCP/IP source modules into the Ada program library using the TCP/IP command COMPILE_TCPIP_PC.BAT. Link SFTP/TCP/IP process using the command LINK_SFTP_TCP_IP.BAT. (8) Create appropriate Security Administrator text files. (See SFTP .txt files for examples from the SFTP demonstration.) The security attribute table files are formatted according to Appendix 30. (10) Put SFTP command in MSDOS System Startup File for general use by the dedicated "PUBLIC". The SFTP command will start execution of both the UIT and CET tasks as necessary. (11) Users can now execute the "SFTP" command to send/receive/ inquire/list files. SFTP USER'S MANUAL March 28, 1988 6.3.5 Results of Program Execution The results of executing SFTP in the COMPAQ environment are the same as in the VAX environment, with the exception that the Security Administrator messages will be sent to the user as well. On a single tasking operating system like MSDOS which has no security, the PC is considered to be a dedicated system and the user cleared for all information (e.g., can also act as the Security Administrator). See Section 6.2.5 for Inquire function screen output. 6.4 Other Computer System Environment. 6.4.1 Description. If SFTP were to be taken to an environment different from the VAX with DEC Ada or the COMPAQ with ALSYS Ada, there are several dependencies that would need to be addressed in order to have an operational product. These dependencies are related to the general operational environment described in the Section 6.1. In general the required hardware/software components would include: (1) Network of computer systems each with a secure operating system and a set of components for network communication equivalent to TCP/IP and a lower level subnet (E.g., Ethernet or X.25). (2) Ada Environment on at least one of the computer systems in order to complete the necessary modifications to SFTP. The changes to SFTP are somewhat machine/operating system dependent and Ada implementation dependent, so it will be necessary to make the modifications so as to be able to test the product on the target system. (3) SFTP Source (e.g., DEC Ada Version) - DEC Ada Version for multitasking operating systems - ALSYS Ada Version for singletasking operating systems SFTP USER'S MANUAL March 28, 1988 6.4.2 Dependencies. The dependencies of the prototype SFTP as implemented on a general computer system are as follows: (1) Ada Packages (Required for SFTP) -- CALENDAR -- *CONDITION_HANDLING -- DIRECT_IO -- *INTERTASK_COMMUNICATION_SERVICE_CALLS -- IO_EXCEPTIONS -- *OPERATING_SYSTEM_SERVICE_CALLS -- SYSTEM -- TEXT_IO -- UNCHECKED_CONVERSIONS -- UNCHECKED_DEALLOCATION * - These are typically Ada implementation packages that provide the capability to create a MAILBOX controlled by the operating system, control exceptions raised by such services, and interact with the specific operating system tasking services. (2) Operating System Interfaces -- Creation and control of the MAILBOX mechanism -- Security attribute information necessary for the VALID_SEND, VALID_RECEIVE, VALID_SECURITY modules. (3) Security Administrator Interfaces -- The security administrator files (see Appendix 30) must be created. 6.4.3 Security Provisions. The level of security protection provided by the SFTP can be no higher than the security provided by the operating system itself. The operating system dependent security attribute functions provided by the SFTP require an interface to the operating system to determine user's security level and object file sensitivity level. This generally requires the operating system to provide mandatory access control capabilities (e.g., at least a level B1). Consequently, the implementation of the SFTP for a general computer system provides security attribute interface functions which are "hooks" for the actual interface to a specific secure operating system. These "hooks" are the modules: VALID_SEND, VALID_RECEIVE, and VALID_SECURITY. These modules are specified as part of the package OS_DEPEND. SFTP USER'S MANUAL March 28, 1988 6.4.4 Installation Procedure. The installation procedure for SFTP on a general computer system is similar to the procedure for the VAX environment. The primary differences are that the SFTP interface dependencies will need to be modified so that the SFTP executes in the target environment. The SFTP for a general computer system environment is delivered on either a VAX tape or 360K floppy diskettes depending upon the target system. There are four file types that are supplied: (1) [SFTP_Source] - all files named .ADA (2) [SFTP_Command]- all files named .COM (3) [SFTP_SecAdm] - all files named .TXT (4) [SFTP_Users_Manual] - SFTPUSER.MAN, no figures, WORDSTAR 4.0 The SFTP_Command files include: (1) Compile_SFTP_UIT_PC (compile order for UIT) (2) Compile_SFTP_CET_PC (compile order for CET) The following installation sequence illustrates what is required to make the prototype SFTP operational on a general computer system. The illustrated directories and various names could be appropriately modified by experienced personnel. (1) Create an SFTP directory as illustrated in Figure 6-2. (2) Load SFTP source, command, and text files from the SFTP medium into the SFTP root directory. (Text files are only for examples.) For a multitasking operating system, use the DEC Ada version of SFTP. For a singletasking operating system, use the ALSYS Ada version of SFTP (modules for UIT and CET are bound together and do not require operating system interface for the mailbox). (3) Create an Ada program library in the SFTP root directory using the available Ada environment (note that multiple program libraries could be established, one for SFTP_UIT, SFTP_CET,TCPIP. (4) Modify modules for operating system mailbox dependencies in the package OS_DEPEND (required only to take advantage of the multitasking capabilities of the operating system - used to provide separation of the UIT and the trusted CET tasks to satisfy security requirements). (5) Modify modules for operating system security interface dependencies in OS_DEPEND (level of modification will depend upon the security services supplied by the operating system). (6) Modify module Lower_Level_Protocol_Interface to properly communicate with the computer system/network specific lower layer protocols (e.g. TCP/IP, RS232-C). This module is in the TCP_In and TCP_Out packages. SFTP USER'S MANUAL March 28, 1988 (7) Compile SFTP_UIT and SFTP_CET source modules into the Ada program library using the SFTP commands COMPILE_SFTP_UIT_PC.COM and COMPILE_SFTP_CET_PC.COM, respectively, as guidance for the compile order. (8) Link the UIT and CET packages separately for the multitasking version, or together for the singletasking version. (9) Create appropriate Security Administrator text files. (See SFTP .txt files for examples from the SFTP demonstration.) The security attribute table files are formatted according to Appendix 30. (10) Put SFTP command in the appropriate computer system startup file or at least the user's "PUBLIC" command file. The SFTP command must start execution of the UIT process. On a multitasking system, the SASFTP command must be available to the Security Administrator (or automatically executed on system startup). The SASFTP command starts execution of the CET process, including the input processing of the Security Administrator files (see Appendix 30). (11) Users can now execute the "SFTP" command to send/receive/ inquire/list files. 6.4.5 Results of Program Execution The results of executing SFTP in the general computer system environment are the same as in the VAX environment or the COMPAQ environment depending upon the particular implementation. SFTP USER'S MANUAL March 28, 1988 APPENDIX 10. GLOSSARY OF TERMS See references [TCSEC] and [TNI] for a complete glossary of security specific terms. Many of the following terms are taken from [TNI]. -A- Access control list - (1) A list of subjects authorized for specific access to an object. (2) A list of entities, together with their access rights, which are authorized to have access to a resource. Audit trail - (1) A set of records that collectively provide documentary evidence of processing used to aid in tracing from original transactions forward to related records and reports, and/or backwards from records and reports to their component source transactions. (2) Information collected or used to facilitate a Security Audit. Authentication - (1) To establish the validity of a claimed identity. (2) To provide protection against fraudulent transactions by establishing the validity of message, station, individual, or originator. -C- Category - A grouping of objects to which a non-hierarchical restrictive label is applied (e.g., proprietary, compartmented information). Subjects must be privileged to access a category. Command Execution Task (CET) - The major component of the Secure File Transfer Program that provides the trusted transfer of a file between the user's directory and the INLIST or OUTLIST directories that interface with the lower level network protocols. Communication channel - The physical media and devices which provide the means for transmitting information from one component of a network to (one or more) other components. Compartment - A designation applied to a type of sensitive information, indicating the special handling procedures to be used for the information and the general class of people who may have access to the information. It can refer to the designation of information belonging to one or more categories. Confidentiality - The property that information is not made available or disclosed to unauthorized individuals, entities, or processes. SFTP USER'S MANUAL March 28, 1988 Connection - a liaison, in the sense of a network interrelationship, between two hosts for a period of time. The liaison is established (by an initiating host) for the purpose of information transfer (with the associated host); the period of time is the time required to carry out the intent of the liaison (e.g., transfer of a file, a chatter session, delivery of mail)/. In many cases, a connection ( in the sense of this glossary) will coincide with a host-host connection (in a special technical sense) established via TCP or equivalent protocol. However, a connection (liaison) can also exist when only a protocol such as IP is in use (IP has no concept of a connection that persists for a period of time). Hence, the notion of connection as used here is independent of the particular protocols in user during a liaison of two hosts. Covert channel - A communications channel that allows a process to transfer information in a manner that violates the system's security policy. A covert channel typically communicates by exploiting a mechanism not intended to be used for communication. -D- Data confidentiality - The state that exists when data is held in confidence and is protected from unauthorized disclosure. Data integrity - (1) The state that exists when computerized data is the same as that in the source documents and has not been exposed to accidental or malicious alteration or destruction. (2) The property that data has not been exposed to accidental or malicious alteration or destruction. Dedicated Security Mode - The mode of operation in which the system is specifically and exclusively dedicated to and controlled for the processing of one particular type or classification of information, either for full- time operation or for a specific period of time. Compare Multilevel Security Mode, System High Security Mode. SFTP USER'S MANUAL March 28, 1988 DoD Internet Protocol Model - The DoD uses a network protocol model based upon seven layers. The layers are loosely related to the International Standards Organization (ISO) Open System Interconnection (OSI) Reference Model. The seven layers are: 1. Physical Layer: includes the functions to activate, maintain, and deactivate the physical connection. It defines the functional and procedural characteristics of the interface to the physical circuit: the electrical and mechanical specifications are considered to be part of the medium itself. Typical interfaces include: RS-232C, MIL-STD- 188C, EIA RS-449, CCITT V.24/V.35, Ethernet/IEEE 802(physical). 2. Data Link Layer: Formats the message. Covers synchronization and error control for the information transmitted over the physical link, regardless of content. "Point-to-point error checking" is one way to describe this layer. Typical interface standards include: High-level Data Link Control (HDLC), Binary Synchronous Link(BSC), Ethernet/IEEE 802(data link). 3. Network Layer: Selects the appropriate facilities. Includes routing communications through network resources to the system where the communicating application is: segmentation and reassembly of data units (packets), and some error correction. Typical interface standards include: X.25, Ethernet/IEEE 802(network). 4. Internet Layer: Network services are unified and viewed as an internet datagram service. Global internet addressing, internet routing, and error handling are defined as part of the service. The principal protocol standards at this layer are Internet Protocol (IP), see reference [MIL1777], and Internet Control Message Protocol (ICMP). The Internet Layer corresponds to a Global Network part of the ISO OSI Reference Model Network Layer. 5. Transport Layer: Includes such functions as multiplexing several independent message streams over a single connection, and segmenting data into appropriately sized packets for processing by the Internet Layer. Provides end-to-end control of data reliability. There are three primary host support protocols at this level: Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Stream Protocol (ST). 6. Utility Layer: Includes several protocols more specifically related to providing end user functionality. SOme of these protocols include: TELNET, Simple Mail Transfer Protocol (SMTP), and File Transport Protocol (FTP). This layer is where the Secure File Transfer Protocol (SFTP) is implemented. 7. Application Layer: Supports distributed applications by manipulating information. Provides resource management for file transfer, virtual file and virtual terminal emulation, distributed processes and other applications. SFTP USER'S MANUAL March 28, 1988 Discretionary Access Control (DAC) - A means of restricting access to objects based on the identity of subjects and/or group to which they belong. The controls are discretionary in the sense that: (a) A subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject; (b) DAC is often employed to enforce need-to-know; (c) Access control may be changed by an authorized individual. Compare to Mandatory Access Control. Domain - The set of objects that a subject has the ability to access. -F- Formal security policy model - A mathematically precise statement of security policy. To be adequately precise, such a model must represent the initial state of a system, the way in which the system progresses from one state to another, and a definition of a "secure" state of the system. To be acceptable as a basis for a TCB, the model must be supported by a formal proof that if the initial state of the system satisfies the definition of a s"secure" state and if all assumptions required by the model hold, then all future states of the system will be secure. Some formal modeling techniques include: state transition models, temporal logic models, denotational semantics models, algebraic specification models. Formal top-level specification (FTLS) - A Top-Level Specification that is written in a formal mathematical language to allow theorems showing the correspondence of the system specification to its formal requirements to be hypothesized and formally proven. -H- Host - Any computer-based system connected to the network and containing the necessary protocol interpreter software to initiate network access and carry out information exchange across the communications network. -I- Internet Protocol (IP) - IP is a protocol that coordinates host/internet interactions including routing advice from gateways to hosts (e.g., redirection of traffic to alternate gateways) and warning messages related to congestion or unrecoverable failures. IP is implemented in the fourth layer (Internet) of the DoD Internet Protocol Model. -M- Mandatory access control - A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity. SFTP USER'S MANUAL March 28, 1988 Multilevel device - A device that is used in a manner that permits it to simultaneously process data of two or more security levels without risk of compromise. To accomplish this, sensitivity labels are normally stored on the same physical medium and in the same form (i.e., machine-readable or human-readable) as the data being processed. Multilevel secure - A class of system containing information with different sensitivities that simultaneously permits access by users with different security clearances and needs-to-know, but prevents users from obtaining access to information for which the lack authorization. Multilevel Security Mode - The mode of operation that allows two or more classification levels of information to be processed simultaneously within the same system when some users are not cleared for all levels of information present. Compare Dedicated Security Mode, System High Security Mode. -N- Network Reference Monitor - An access control concept that refers to an abstract machine that mediates all access to objects within the network by subjects within the network. Network security - The protection of networks and their services from unauthorized modification, destruction, or disclosure. Providing an assurance that the network performs its critical functions correctly and there are no harmful side-effects. Includes providing for information accuracy. Network Trusted Computer Base (NTCB) - The totality of protection mechanisms within a network system -- including hardware, firmware, and software -- the combination of which is responsible for enforcing a security policy. (See also Trusted Computing Base.) -O- Object - A passive entity that contains or receives information. Access to an object potentially implies access to the information it contains. Examples of objects are: records, blocks, pages, segments, files, directories, directory trees, and programs, as well as bits, bytes, words, fields, processors, video displays, keyboards, clocks, printers, etc. SFTP USER'S MANUAL March 28, 1988 OSI Reference Model - The International Organization for Standardization (ISO) provides a framework for defining the communications process between systems. This framework includes a network architecture, consisting of seven layers. The architecture is referred to as the Open Systems Interconnection (OSI) model or Reference Model. Services and the protocols to implement them for the different layers of the model are defined by international standards (see reference [ISO7498]. This OSI Reference Model is similar to the DoD Internet Protocol Model. The seven layers are: 1. Physical Layer: includes the functions to activate, maintain, and deactivate the physical connection. It defines the functional and procedural characteristics of the interface to the physical circuit: the electrical and mechanical specifications are considered to be part of the medium itself. Typical interfaces include: RS-232C, MIL-STD- 188C, EIA RS-449, CCITT V.24/V.35, Ethernet/IEEE 802(physical). 2. Data Link Layer: Formats the message. Covers synchronization and error control for the information transmitted over the physical link, regardless of content. "Point-to-point error checking" is one way to describe this layer. Typical interface standards include: High-level Data Link Control (HDLC), Binary Synchronous Link(BSC), Ethernet/IEEE 802(data link). 3. Network Layer: Selects the appropriate facilities. Includes routing communications through network resources to the system where the communicating application is: segmentation and reassembly of data units (packets), and some error correction. Typical interface standards include: X.25, Ethernet/IEEE 802(network). The Global Network functionality of the OSI Network Layer compares to the DoD Internet Protocol Model Internet Layer functionality. 4. Transport Layer: Includes such functions as multiplexing several independent message streams over a single connection, and segmenting data into appropriately sized packets for processing by the Internet Layer. Provides end-to-end control of data reliability. There are several host support protocols at this level, the best known one is a close variation of TCP called TP-4. 5. Session Layer: Selects the type of service. Manages and synchronizes conversations between two application processes. Two main types of dialogue are provided: two-way simultaneous (full-duplex), or two-way alternating (half-duplex). Provides control functions similar to the control language in computer system. Corresponds to part of DoD Internet Protocol Model Utility Layer functionality. SFTP USER'S MANUAL March 28, 1988 6. Presentation Layer: Ensures that information is delivered in a form that the receiving system can understand and use. Communicating parties determine the format and language (syntax) of messages: translates if required, preserving the meaning (semantics). Corresponds to part of DoD Internet Protocol Model Utility Layer functionality. 7. Application Layer: Supports distributed applications by manipulating information. Provides resource management for file transfer, virtual file and virtual terminal emulation, distributed processes and other applications. -P Penetration testing - The portion of security testing in which the penetrators attempt to circumvent the security features of a system. The penetrators may be assumed to use all system design and implementation documentation, which may include listings of system source code, manuals, and circuit diagrams. The penetrators work under no constraints other than those that would be applied to ordinary users or implementors of untrusted portions of the component. -R- Read access - Permission to conduct a fundamental operation that results only in the flow of information from an object to a subject. -S- Secure File Transfer Program (SFTP) - The program that executes in an upper level protocol (E.g., Utility layer of the DoD Internet Reference Model, or the Presentation layer of the OSI Reference Model) and securely transfers a file from the initiating host to the receiving host without compromising the overall security of the network. Security Administrator - See System Security Officer Security Kernel - The hardware, firmware, and software elements of a Trusted Computing Base (or Network Trusted Computing Base partition) that implement the reference monitor concept. It must mediate all accesses, be protected form modification, and be verifiable as correct. Security level - The combination of hierarchical classification and a set of non-hierarchical categories that represents the sensitivity of information. Security policy - The set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive information. Security policy model - An informal presentation of a formal security policy model. SFTP USER'S MANUAL March 28, 1988 Sensitivity label - A piece of information that represents the security level of an object and that describes the sensitivity (e.g., classification) of the data in the object. Sensitivity labels are used by the NTCB as the basis for mandatory access control decisions. Single-level device - A device that is used to process data of a single security level at any one time. Since the device need not be trusted to separate data of different security levels, sensitivity labels do not have to be stored with the data being processed. Subject - An active 3entity, generally in the form of a person,m process, or device that causes information to flow among objects or changes the system state. Technically, a process/domain pair. System High Security Mode - The mode of operation in which system hardware and software is only trusted to provide discretionary access protection between users. In this mode, the entire system, to include all components electrically and/or physically connected, must operate with security measures commensurate with the highest classification and sensitivity of the information being processed and/or stored. All system users in this environment must possess clearances and authorization for all information contained in the system. All system output must be clearly marked with the highest classification and all system caveats until the information has been reviewed manually by an authorized individual to ensure appropriate classifications and that caveats have been affixed. Compare Dedicated Security Mode, Multilevel Security Mode. System Security Officer (SSO) - The person responsible for the security of a system. The SSO is authorized to act in the "security administrator" role. Functions that the SSO is expected to perform include: auditing and changing security characteristics of a user. Transmission Control Protocol (TCP) - TCP is a highly reliable, end-to- end, sequenced byte stream protocol which uses retransmission and positive acknowledgment to assure data delivery. An end-to-end, window-based flow control strategy is used. This protocol provides "virtual circuit" service to higher level protocols and applications. It is implemented in the fifth layer (Transport) of the DoD Internet Protocol Model. Trusted Computing Base (TCB) - The totality of protection mechanisms within a computer system -- including hardware, firmware, and software -- the combination of which is responsible for enforcing a security policy. It creates a basic protection environment and provides additional user services required for a trusted computer system. The ability of a trusted computing base to correctly enforce a security policy depends solely on the mechanisms within the TCB and on the correct input by system administrative personnel of parameters (e.g., a user's clearance) related to the security policy. Trusted subject - A subject that is part of the TCB. It has the ability to violate the security policy, but is trusted not to actually do so. SFTP USER'S MANUAL March 28, 1988 User - Any person who interacts directly with a network system. This includes both those persons who are authorized to interact with the system and those people who interact without authorization (e.g., active or passive wiretappers). Note that "users" does not include "operators," "system programmers," "technical control officers," "system security officers," and other system support personnel. They are distinct from users. Such individuals may change the system parameters of the network system, for example by defining membership of a group. These individuals may also have the separate role of users. User Interface task (UIT) - The major component of the Secure File Transfer Program that provides the interface with the user to send, receive, and inquire about files transferred between the user and some other component on the network. Write access - Permission to conduct a fundamental operation that results only in the flow of information from a subject to an object. SFTP USER'S MANUAL March 28, 1988 APPENDIX 20. SUMMARY OF USER MESSAGES Each message to the user is described along with the module issuing the message and the suggested user action. The generic action of "Check with system programmer" means that there is a fault in the SFTP program. The generic action of "Check with the Security Administrator" means some aspect of the security authorization needs to be updated for the user to be able to complete the desired SFTP request. All SFTP user messages are prefaced with the string "SFTP:". Any other message will be from system components not controlled by SFTP. The user should take the appropriate action if known, otherwise consult with the system programmer or Security Administrator. 20.1 Messages From: package OS_DEPEND: procedure GET_USER_INFO Message 1: "SFTP: ENTER DESIRED SECURITY LEVEL" User Action: Enter security level for the session. This action may vary with the particular implementation. With a secure operating system, the desired level may already be known to the system through user login procedures Message 2: "SFTP: ENTER EACH SECURITY CATEGORY NUMBER" "SFTP: ENTER 0 TO FINISH" "SFTP: ENTER A SECURITY CATEGORY NUMBER" "SFTP: THANK YOU" User Action: Enter security category number (positive integer) followed by a for each category that applies. A "0" entry terminates the entries. See Security Administrator for meaning of category numbers. Message 3: "SFTP: NEGATIVE NUMBERS NOT ALLOWED - NUMBER IGNORED" "SFTP: MAXIMUM SECURITY CATEGORY IS" & User Action: These messages are shown to the user if the input category number is out of range. NOTE: These messages and user entries are simply for prototype use. Normally the user will log on with certain security level and category privileges, which are verified by the operating system. This information would then be passed to SFTP through the normal security authorization modules. 20.2 Messages From: package OS_DEPEND: procedure GET_USER_ARGUMENTS Message 1: "SFTP: Could not get command_line" User Action: Check command line for proper syntax, and reenter SFTP USER'S MANUAL March 28, 1988 20.3 Messages From: procedure USER_TASK_MAIN Message 1: "SFTP: No Response from SFTP Command Task" User Action: Check with Security Administrator Message 2: "SFTP: Request not processed due to missing, inconsistent, or invalid Arguments" User Action: Check command line for proper syntax, and reenter Message 3: "SFTP: Permission denied." User Action: User is not authorized for requested action. Check command line for proper syntax and/or check with the Security Administrator to obtain proper authorization. 20.4 Messages From: package USER_PKG: procedure PARSE_ARGUMENTS Message 1: "SFTP: More than one action requested" User Action: Check command line for proper syntax, and reenter Message 2: "SFTP: Unsupported argument: " & User Action: Check command line for proper syntax, and reenter Message 3: "SFTP: Argument not preceded by '-' must be last." User Action: Check command line for proper syntax, and reenter. Remember that an argument that is not preceded by a "minus" must appear as the last argument on the command line. 20.5 Messages From: package USER_PKG: procedure DO_INQUIRE_SHORT Message 1: "SFTP: You have" & & " files to receive" User Action: none Message 1: "SFTP: You have no files to receive" User Action: none SFTP USER'S MANUAL March 28, 1988 20.6 Messages From: package USER_PKG: procedure DO_INQUIRE_LIST Message 1: "SFTP: You have no files to receive" User Action: none Message 2: " Filename Sender Computer " & " When received Security" User Action: none, this is the header for the list of files associated with the user INQUIRE request Message 3: & & &