Process Management and Monitoring Notebook - page 42 of 74

First PagePrevious PageNext PageLast PageTable of ContentsSearch

Date and Author(s)

Security Plan and Wire Protocol

Proposal for a Security Plan and Secure Wire Protocol

The Scalable Systems Software project is now defining standard interfaces between components of the systems software of large computing clusters and Massively Parallel Processors (MPPs). The component suite is primarily designed to run within a supercomputer center, but access to these components by system administrators and users may come from "remote" locations. This requires a security plan and a means for components to securely exchange data over the wire. The following is a proposal for a security plan and secure wire protocol based on discussions with security personel at Sandia. It is expressed in terms of CPlant, but can be applied to any components with access to high performance resources.

We propose defining the following modules with corresponding interfaces, any or all of which may be accessible under this security plan: accounting, user database, usage reports, resource allocation and management, scheduler, queue manager, system monitor, job manager & monitor, node configuration and build manager, data migration.

Security Plan

  1. We are seeking to give access to the Cplant "heads" that are on the SON only. No classified or restricted information will be involved. Cplant on the SON includes user authentication mechanisms, which will not be circumvented.
  2. We will have a server that has network connections to both the Internet and the SON. This server will run only one program, which we are writing. This program will listen for connections on port 443 (SSL) and accept either HTTP or XML commands (as described below) after passing suitable security checks.
  3. The SSL protocol will be set up to use 128 bit encryption. Before completing a connection, it will require "client authentication" from a list of clients that will be set up manually. Thus, incoming connections will only be accepted from computers having an SSL "private key" for which the corresponding "public key" has been entered into the server at Sandia. As currently envisioned, this mechanism will permit connections from any IP address on the Internet.
  4. The entry of a private key into the list of authorized clients is anticipated to be an infrequent, manual process. This process will require the external party to sign a letter acknowledging acceptance of the Sandia "no expectation of privacy" notice. This letter will be kept on file with the project's principal investigator at Sandia. With this letter on file, a splash screen with the notice will not be applicable, since no user will be able to connect without the private key.
  5. The new and innovative purpose of this project is to accept parallel supercomputer commands in XML format. The server program will relay these commands to the appropriate Cplant computer on the SON and relay the result to the originating client computer via the return channel of SSL. This mode of operation is expected to be used by non-interactive systems software components at other national labs and other authorized locations.
  6. The security measures described above will also allow input from a properly-configured Web browser. Specifically, connections from a browser with 128 bit encryption and equipped with an authorized client certificate will be accepted. For ease of use, the server program will also accept HTML access and will respond and process human-readable HTML forms.

Enhancements to Cplant

These capabilities are present in Cplant now, although in a very inconvenient form. Specifically, Cplant on the Sandia Open Network (SON) has a user authentication mechanism that permits a user to log in from any location on the Internet through Secure SHell (SSH) and submit, run, and monitor jobs through a ASCII command line interface. This project intends to provide conduits and automation so that suitably authorized jobs may be submitted and controlled by software agents located at authorized locations on the Internet.

Sandia Cplant XML Interface

Each server listens on a designated port for connections via SSL protocol, such as server:12345.

An incoming request is deemed to be XML if the first two characters are " If the request is XML, the connection is assumed to be an XML command stream, with the socket open for responses in the other direction. The server will parse each top-level XML element as soon as it is complete (this is a controversial provision).

If the request is HTTP GET or POST to file /XML, the command is expected to be a form submission with one argument of the form xml=data (such as https://server:12345/XML?xml=data). Data is then interpreted as a single SciDAC SSS XML command. The XML response will be returned as a

block in an HTML page.

If the request is HTTP to any other file, the server will implement a small Web site with the following content:

  1. forms for starting, stopping, and otherwise controlling the server,
  2. one or more forms to assist a human in producing XML for testing purposes. These forms would have a TEXTAREA filled-in with the XML markup with blanks where parameters should appear.

Usage scenarios

  1. Human connects a browser to https://server:12345 and receives an HTML form containing the XML framework already filled-in. The human adds parameters in the appropriate places and hits "submit." They get a HTML page with the returned XML.
  2. A computer opens an SSL connection and sends a stream of XML commands, receiving a stream of responses back.
  3. An adminstrator connects a browser to https://server:12345 and accesses a series of Web pages that allow them to review server performance and change parameters.

Addendum: Al Geist Date: Sat Feb 9 15:36:55 2002 (GMT)
I edited the title and first paragraph a little to make this a "proposal" for a security plan rather than appearing like something that had already been voted on. Overall, seems like a reasonable plan for the Scalable Systems Software Suite. Does not impose undue hardship on the the component writers and doesn't preclude the suite being run on clusters with only internal access and no security.

Addendum: Narayan Desai Date: Wed Feb 13 19:04:22 2002 (GMT)
This is fairly similar to what we have been discussing the build/config
group in the context of the security component. So far, we have
been talking about accomodating security inside of the wire protocol.
This would allow the already existing service directory to support
arbitrary security systems without having too much more infrastructure
overhead. This also allows, as Al says above, the cluster
administrator to choose which protocols are employed in the system.
The wire protocols that have been discussed so far are the basic protocol
that Rusty proposed at the last face to face, and in BCM we have been
talking about a challenge response protocol that looks a lot like the
basic protocol with the addition of a challenge/response preamble to communication.

Addendum:   Rusty Lusk   Date: Thu Feb 14 16:46:21 2002 (GMT)
We were planning to suggest at the meeting a simple extension to the basic wire protocol we adopted at the last meeting to provide authentication when connections are made with the basic protocol. It is the challenge-response authentication described on p 602 of Tanenbaum's "Computer Networks" book. It's main virtue is that it relies only on the existence of Unix crypt, and requires no other libraries or protocols. I would like to propose that we add it to the basic protocol as a basic authentication mechanism. We use this in mpd (C) and have a python implementation as well, for our prototype components in this project. We would like to distribute it as a library to accelerate the actual communication between separate components.