Internet Draft W. Krebs Document: draft-krebs-gnuqueue-protocol-00.txt FSF Category: Experimental July 2000 Description of Load-Balancing and Communication Protocols Used by GNU Queue Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited." Comments on this document should be directed to the author at wkrebs@gnu.org. Copyright Statement This document is Copyright (C) W. G. Krebs (2000). All Rights Reserved. However, distribution of this memo in its original form is unlimited. Protocols Used by GNU Queue July 2000 Table of Contents Status of this Memo...................................................1 Copyright Statement...................................................1 Table of Contents.....................................................2 Abstract..............................................................3 Overview..............................................................4 Transport Layer Protocols.............................................4 Job Control File......................................................4 Host Selection Protocol...............................................6 Secure Rlogin-like Protocol Description...............................8 Mutual Authentication and Connection Establishment ..................8 Option Negotiation by Telnet-style Will-Wont Mechanism .............10 GNU Queue main loop ................................................11 Signal Information from Client to Server ..........................11 Client-side implementation ......................................11 Server-side implementation ......................................12 Signal Information Flow from Server to Client .....................12 Connection Closure .................................................13 Security Considerations..............................................13 References...........................................................15 Author's Address.....................................................15 Full Copyright Statement.............................................16 Protocols Used by GNU Queue July 2000 Abstract This document describes the protocols used by GNU Queue to communicate between GNU Queue processes. This includes protocols used to facilitate network load-balancing (including reporting to GNU Queue processes of host load averages, 'virtual load averages', and/or other information used to determine job routing), process input-output, and process control information (two-way signal and termination code reporting). GNU Queue is a load-balancing system that lets users control their remote jobs in an intuitive, transparent and nearly seamless way. This is done with local shell job control and signaling through Queue's proxy daemon mechanism. Queue can be used as a local replacement for rsh and ssh to hosts within a cluster under single administrative control. Queue also supports the more traditional email-based load-balancing and distributed batch-processing facilities using a number of criteria to decide where to send jobs. The homepage for GNU Queue is http://queue.sourceforge.net . Protocols Used by GNU Queue July 2000 Overview GNU Queue is a load-balancing system and local replacement for rsh and ssh for hosts in a cluster under single administrative control. Queue lets users control their remote jobs in an intuitive, transparent and nearly seamless way. This is done with local shell job control and signaling through Queue's proxy daemon mechanism. Queue also supports the more traditional email-based load-balancing and distributed batch-processing facilities using a number of criteria to decide where to send jobs. The homepage for GNU Queue is http://queue.sourceforge.net . This document describes the protocols used by GNU Queue to facilitate communicate between GNU Queue processes, including protocols used to facilitate network load-balancing (including reporting to GNU Queue processes of host load averages, 'virtual load averages', and/or other information used to determine job routing), process input-output, and process control information (two-way signal and termination code reporting). Transport Layer Protocols By popular demand, implementations of the GNU Queue protocols complaint with this memo wrap their socket communications as application data under RFC-2246 Transport Layer Security (TLS) Protocol [2] socket connections; these, in turn, are based on TCP sockets [3]. This document makes no specification as to the TLS ciphers that should be used, although a combination of 3DES [4], MD5 [5], and no compression is suggested when permitted by law. Compliant implementations may elect to use the less secure RC4 cipher protocol [6] or simple plaintext in order to make the code more exportable and less encumbered by legal restrictions, where necessary. The insecure TCP/IP protocol may be substituted for TLS/TCP/IP in experimental implementations of the protocol for testing purposes. Job Control File In the initial negotiation, the submitting host writes a "job control file." This contains a superset of UNIX environment information about the remote command to be executed, current directory, remote user id, remote group id, additional remote group ids, UNIX environment variables, UNIX nice value, and UNIX resource limits (if supported). (An NT implementation of a GNU Queue client would simply supply reasonable values for the UNIX variables. A user's typical UNIX environment variables might be supplied to the NT client initially by a UNIX program, or might simply be generated synthetically in the manner of the UNIX login program.) It also specifies GNU Queue options, such as whether or not to establish an rlogin-like [7] connection between the running job and the user (see below), whether to allocate a virtual tty for the job, or whether to run the job in batch mode and, if so, whether to mail the output of the batch process to the user. Protocols Used by GNU Queue July 2000 The exact details of the job control file are important, except that the first null-terminated string in the job control file contains the file's version string, which the job receiving process must support. Also, the file must somewhere contain a 128-bit binary one- time-pad cookie, which will subsequently be used in as encryption key. (Care should be taken to ensure that this cookie is as random as reasonably possible, although the means to do this are not discussed in this protocol.) The file assumes an eight-bit format. The version strings "VERSION0" and "VERSION1" modes of the job control file must be at least partially supported by all versions of GNU Queue compliant with this memo, and is suitable for creating interoperable versions of GNU Queue clients. These have the following format: "VERSION0" file version specifier (no quotes) ASCII UNIX Username ASCII optional UNIX password or simply A 128-bit binary one-time-pad-cryptographic cookie UNIX current directory Null-terminated ASCII UNIX environmental variable key=value pairs, terminated by two consecutive s null-terminated strings giving the UNIX arguments of the command to be run "VERSION1" file version specifier (no quotes) 4-byte UNIX User ID (UID) integer in network ordering ASCII Username ASCII email address ASCII job name ASCII space or ASCII destination hostname Binary variable, 0=rlogin-like mode, 1=batch mode A 128-bit binary one-time-pad cryptographic cookie 4-byte IP address of host with queue process in network ordering 2-byte IP address of port on which queue process is listening (in the rlogin like mode; otherwise this is undefined.) List of optional null-terminated UNIX environmental variables, terminated by two nulls. 4-byte UNIX audit ID (same as UID except on HP) in network ordering 4-byte UNIX effective user ID (normally same as UID) in network ordering 4-byte UNIX effective group ID (normally same as group ID) 4-byte UNIX group ID (integer in network byte ordering) 4-byte number of group ids integer in network byte ordering, followed by this number of group id integers in network byte ordering. 4-byte integer in network ordering which is 1 if standard input is a tty, 0 otherwise [this is also set to zero if the user has forcibly disabled tty options, or if the client is running on an OS which does not support ttys.] Protocols Used by GNU Queue July 2000 4-byte integer in network ordering which is 1 if standard output is a tty, 0 otherwise. 4-byte integer in network ordering which is 1 if standard error is a tty, 0 otherwise. 4-byte integer in networking byte order giving size of terminal data structure, if any, followed by a terminal data structure of this size [0 on non-UNIX flavor systems]. A list of null-terminated strings giving the arguments of the command to be run remotely, terminated by two consecutive nulls. A 4-byte integer in network byte ordering giving the umask value of the client's environment (clients on non-UNIX systems should set this to hexadecimal 022). A 4-byte integer in network byte order setting the nice value of the process (non-UNIX clients set this to decimal 20). A 4-byte integer in network byte order giving the size of an optional UNIX resource limit data structure. If non-zero, eight resource limit data structures of this size Host Selection Protocol Once a valid job control file exists, a GNU Queue server (typically, "queued") or GNU Queue client (typically, "queue") must determine whether to run the job locally or export the job control file to another machine. (The client, "queue" always decides to export the job, if only to the local "queued" server process.) The host to which the job control file is to be sent is determined by the host selection protocol. This memo describes host selection protocol VERSION0. Future revisions of this document may include more sophisticated host selection protocols, including highly scalable hierarchical querying schemes designed for large networks, or protocols that perform capability queries of potential target hosts. In VERSION0 of this protocol, however, the cluster is surveyed by simply querying every host in the cluster once per job submitted. This is done by establishing a TLS [8] socket connection to the server on a predetermined port reserved for this purpose. The format is as follows: "QUERY" "VERSION0" version specifier string, without quotes. job control file version string from job control file queue-name or queue-name; the octal 001 specifies that the job is already running and is to be process-migrated. Process migration is not described in this memo; consequently, Protocols Used by GNU Queue July 2000 memo-compliant implementations can reject jobs by returning 1e08 as the load average. If the client's IP address is in the server's ACL (Access Control List), the server responds to this stream with a network-ordered (big endian) 4-byte float value in the standard IEEE 754 single precision floating-point format, usually equivalent to the local C "float" type in either forward or reverse byte ordering. If the job is rejected (e.g., the socket stream does not begin with "VERSION0", the job control file version is not understood, or the job queue has too many jobs) it may be rejected by returning the magic value 1e08 as the load average. If the client's IP address is not in the server's ACL, it may immediately close the connection. Note that the load average returned is considered a "virtual load average" calculated specifically for the particular job queue and the protocol version string. It may take any of a number of factors into account, including the traditional operating system load average. A GNU Queue client typically proceeds by surveying each host in the cluster with this protocol. Usually, it will elect the host which returns the lowest load average. At this point, it will send the file to the elected host. This is again done by establishing a TLS/TCP/IP socket connection to the serving process (typically "queued") on the elected host. The following information is sent: "JOB CONTROL FILE" "VERSION0" protocol version specifier string, without quotes. Job control file The server responds with a null if all is well; otherwise it responds with a non-null byte. The behavior of the client upon receiving a non-null byte is unspecified. (Typically, it may try another host before giving up with an error to the user.) Also, the behavior of the server in receiving a file from a machine whose IP address is not in the server's access control list is also undefined. Note that the first string in the job control file establishes the version number of the file. The host that receives the job control file may choose to run the job if conditions are favorable. In this case, it becomes the job receiving process, or server, described in our next section, and, depending on the contents of the job control file, may attempt to connect with the original job submitting process listed in the job control file (referred to somewhat confusingly as the "client" Protocols Used by GNU Queue July 2000 process in the next section) via the rlogin-like protocol described immediately below. If this connection is attempted, and the connection fails, the job and job control file may be discarded. Likewise, if the job is run, the job control file is discarded. Alternatively, after a suitable delay, the host may decide that conditions for running the job are unfavorable. In this case, it may turn itself into a client and follow the above querying protocol to locate a more suitable host. If it finds a more suitable host (e.g., lower load average), it may act as a client and retransmit the job control file to this new server using the previously described protocol. Secure Rlogin-like Protocol Description The GNU Queue protocol can optionally provide a remote-echoed, locally flow-controlled virtual terminal based on TLS/TCP/IP between job submitting process (GNU Queue client and TLS socket server) and job receiving process (GNU Queue server and TLS socket client). This option is controlled by the job control file, which might defeat this feature and instead require that process output be sent back to the user as email, for example. The contact port is configured at compile time, but may be assigned in a future draft of this document. An eight-bit transparent stream is assumed. Mutual Authentication and Connection Establishment The GNU Queue server (job receiving process) opens a TLS connection (in TLS client mode) to the previously specified client (job submitting process in TLS server mode) host and port using TLS/TCP/IP. The client, upon connecting establishment, normally checks the IP address of the server host to see if it is in an ACL (Access Control List) of hosts allowed to connect to the client. The ACL typically also specifies a unique user ID common to all the hosts in the cluster under which the server process is expected to run. Consequently, the client may optionally attempt to use the identd service (RFC931) [9] to determine the user id of the connecting GNU Queue server process, or, if the server process normally runs as root, check that the originating TLS socket has bound a reserved port. For this reason, if the server process is running with root privileges, it should bind a reserved port before connecting to the client. Following connection establishment, the server and client authenticate themselves to each using a scheme similar to the HTTP Digest Authentication (RFC2617) [10] scheme. The one-time cookie, included in the job control file (which has been transmitted using secure TLS connections) is used as the shared secret. Following RFC 2617, The client (server in the digest authentication sense) sends a challenge ("nounce") which is combined with the cookie (shared secret) to generate a hash using a secure hash function, MD5 [11]. MD5 generates hashes of ASCII text in the form of 32-byte ASCII strings. Protocols Used by GNU Queue July 2000 A known potential weakness in this approach is that a malicious (or false) client (server in the HTTP Digest sense) could choose which challenge ("nounce") to send to the server and observe the replies. This ability to choose the plaintexts encrypted with the MD5 algorithm is a form of known plaintext attack, known to make cryptanalysis much easier [12]. The solution is to have the server (Digest authentication client) send a challenge of its own ("cnounce") which is incorporated into the final hash. This gives the client (server in the Digest authentication sense) much less control over the hash to be encrypted. Thus the exchange is: GNU Queue server (digest authentication client): ASCII cnounce string GNU Queue client (digest authentication server): ASCII nounce string GNU Queue server: MD5(concat(cookie,":",nounce,":",cnounce)) This proves to the GNU Queue client that the GNU Queue client knows the shared secret (cookie) without revealing the actual cookie. If the server fails to send the correct response within a reasonable period of time (10 seconds in a LAN environment is suggested), the client drops the connection and returns to the top of the waiting loop under the assumption that the server is trying to run a leftover job for an old GNU Queue client that has since died. A GNU Queue server, sensing a lost connection, deletes the job control file under this same assumption. If the connection still exists at this point, the roles are reversed, so that the GNU Queue client can authenticate itself to the GNU Queue server. As above, if client does not produce a valid response to the server's challenge within some reasonable period of time (10 seconds in a LAN environment is suggested), the server assumes that this is a different GNU Queue client. It drops the connection and deletes the job control file associated with the cookie. The client, sensing the dropped connection, returns to the top of the waiting loop. Like both HTTP Digest Authentication and the Secure HTTP Protocol (RFC2660) [13], the scheme is still vulnerable to man-in-the-middle attacks. Otherwise, the server (job receiving process) opens a second TLS/TCP/IP socket, and sends the port number as a null-terminated ASCII string to the client (job submitting process) via the already- open TLS/TCP/IP connection. Again, a reasonable time-out is allowed for this exchange, otherwise the procedure is aborted. The client Protocols Used by GNU Queue July 2000 then listens on this port number for the incoming connection with the server. Normally, the client also performs a sanity check on the IP address of this second incoming socket connection to make sure it matches the IP address of the server host. If everything is OK, the client sends a null byte back to the server. At this point, client and server are authenticated and have established two socket TLS connections. The client's behavior changes, in that subsequent protocol failures will cause the client to terminate rather than return to the top of a loop waiting for incoming connections. In summary, the exchange is: GNU Queue client (now digest authentication client): ASCII cnounce string GNU Queue server (digest authentication server): ASCII nounce string GNU Queue client: MD5(concat(cookie,":",nounce,":",cnounce)) server: secondary-port-number-ascii client: At this point, a connection consisting of two two-way TLS/TCP/IP sockets is established between server and client. Option Negotiation by Telnet-style Will-Wont Mechanism Compliant implementations of the GNU Queue protocol include a telnet-style (RFC 854) WILL-WONT mechanism [14,15] for negotiating between client and server in a non-homogeneous environment. As in telnet, WILL XXX is sent, by either party, to indicate that party's offer to begin performing option XXX, DO XXX and DONT XXX being its positive and negative acknowledgments, respectively; similarly, DO XXX is sent to request that the other party (i.e., the recipient of the DO) begin performing option XXX, and WILL XXX and WONT XXX are the positive and negative acknowledgments, respectively. The DONT and WONT responses are guaranteed to leave the connection in some sort of minimalist state which both ends can handle (i.e., no virtual tty support, no SIGWINCH support, no signal passing support). Thus, all hosts may implement their GNU Queue processes to be totally unaware of options Protocols Used by GNU Queue July 2000 that are not supported, simply returning a rejection to (i.e., refusing) any option request that cannot be understood. Currently, only two options are defined by this memo, "SIGWINCH" and "SIGNAL". Each option is followed by a string identifying the flavor of the operating system. For example, "WILL SIGWINCH SOLARIS" by the client followed by a "DO SIGWINCH SOLARIS" from the server negotiates a Solaris-style virtual tty window-size data structure. Similarly, a "WILL/DO SIGNAL SOLARIS" negotiates Solaris- style signal number mapping between client and server. Failure to negotiate SIGWINCH causes the client to ignore SIGWINCH events and disables window size information from being sent from client to server. Similarly, failure to negotiate a signal mapping between client and server means that only SIGSTOP, SIGCONT, SIGTERM, SIGKILL, and SIGHUP signals are supported in the exchange between client and server. Other signals must be either mapped to one of these signals, guaranteed to be supported, or must be ignored. WILL/DO negotiations are concluded by the client's sending of the empty string terminated by a byte. The server responds with a byte. This throws both client and server into the main loop, described in the next session. GNU Queue main loop For the duration of the connection, the client sends its standard input stream to the server by transparently copying it to the first TLS/TCP/IP socket. The client also copies incoming data on this socket transparently to its standard output. Similarly, the server redirects incoming data on this first socket to the standard input of the running process being remotely controlled by transparently copying it to either the processes' controlling virtual tty or a UNIX pipe to the processes' standard in. Standard output from the process (either directly from the processes' standard output into a UNIX pipe, or via the master end of a controlling virtual tty) is similarly redirected into this socket by verbatim copying. If a virtual tty is not being used to control the running process, the server is sometimes able to distinguish the running processes' standard output from its standard error. In this case, standard error output is read from a UNIX pipe connected to the running processes' standard error output. This is then send to the client by copying this data verbatim into the second socket. Signal Information from Client to Server Client-side implementation If the client receives a signal from the operating system that supports signals (e.g., the client process receives a UNIX SIGSTOP signal to suspend) it sends this to the server as a simple byte containing the number of the signal sent. (This assumes that client Protocols Used by GNU Queue July 2000 and server have negotiated a homogenous network mode, where signal numbers are the same on both client and host. Future implementations may negotiate a signal-translation map between client and server, whereby the client may learn how to translate a signal number into that used by the server. In this case, the signal number is translated to the server's number before being sent.) If the client is running on an operating system that does not support signals (e.g., Windows NT), some other means of allowing the user to send signals to the running process is normally provided, such as a graphical user interface listing sensible signals to send to the process being controlled by the server. If the client receives SIGWINCH (the UNIX terminal window size change signal) and client and server have previously negotiated a window size structure as well as use of a virtual tty, the SIGWINCH number is followed by the client's new window size structure. Typically, client and server have negotiated homogeneous cluster mode, so this structure is the same on both client and server, and the client can simply send the data structure verbatim to the server. Clients running on non-UNIX operating systems, such as Windows NT, are unlikely to have a useful equivalent of a terminal window size change, and therefore should not send SIGWINCH to the server. Server-side implementation If the server receives a byte on the second socket, it should send this signal to the process (typically via a signal() system call under UNIX.) If the signal number matches SIGWINCH and it has negotiated a window size structure (by, e.g., negotiating homogeneous cluster mode) as well as use of a virtual tty, it should first read the "struct winsize" structure from the socket and adjust the virtual tty for the process it is controlling to match the information in the "struct winsize" structure. Signal Information Flow from Server to Client The server monitors the process it is controlling (e.g., using the wait() system call) for normal termination and/or termination or suspension by a signal. The process allocates a signed char. If the process terminated or was suspended by a signal, the signal number is recorded as a negative value (under most flavors of UNIX, there are no more than 64 signals). Otherwise, the exit value (under UNIX) is noted; if the exit is less than zero or greater than 127, the signed char is set to 127. Otherwise, the signed char is set to the exit value code. This signed char (positive or zero for normal exit, negative for termination or suspension by signal) is sent to the client by setting the OOB (Out of Bounds) data marker in the application data stream on the second TLS socket (standard error socket) to the current position and transmitting the byte. Protocols Used by GNU Queue July 2000 The client is able to distinguish this termination/suspension byte from normal standard error information by monitoring the OOB marker. When it points to a byte in the stream, the sign of the byte is tested. If it is negative, the process controlled by server has received a signal, and the client takes appropriate action (Under GNU Queue for UNIX, the client sends itself the signal, first performing any appropriate signal number mapping in a non- homogeneous environment). If the number is positive, the process controlled by the server has terminated normally, and the client takes appropriate action (GNU Queue clients for UNIX terminate with this value.) Connection Closure Normally, the death of the process running under the server's control will trigger the client to terminate via the OOB mechanism just described. The client should ensure all pending socket input and output has been processed before terminating or sending itself a potentially terminal signal. Similarly, the server should ensure there is no more incoming data from the client before sending signals to the process under control. If the TLS/TCP/IP connection closes abnormally in either direction, the client or server process that notices the close should perform an orderly shutdown, restoring terminal modes (on the client side) and/or killing the running process in an orderly fashion (on the server side by, e.g., a SIGTERM followed a few seconds later by a SIGKILL). Security Considerations The GNU Queue protocol (as implemented), like rlogin [16] and rsh, allows a user to set up a class of trusted users and/or hosts which will be allowed to execute jobs as him- or herself without the entry of a password. Also like rlogin and rsh, compromise of one of the trusted hosts opens ALL the systems so configured [17]. Unlike rlogin and rsh however, the GNU Queue protocol (as commonly implemented) requires each the IP address(es) of each trusted host to be explicitly listed in the global Access Control List (wildcards are not supported), which is only supposed to list hosts in the user's immediate cluster. Hosts in a GNU Queue cluster already share certain security-related attributes (such as mounting a common networked filesystem or use shared passwords for ease of use) so this security caveat is less likely to be a major issue for GNU Queue than it is for other protocols, such as rlogin and rsh. While GNU Queue may allow compromise of the entire GNU Queue cluster from a single cluster node, unlike rlogin and rsh this will not, in general, allow compromise of other GNU Queue clusters under separate administrative control. Protocols Used by GNU Queue July 2000 GNU Queue was originally written with small, local clusters in mind, which can be assumed to have relatively secure networks. In the past, widespread use of plaintext passwords mean that compromise of these networks resulted in compromise of the entire cluster through no fault of GNU Queue. Today, however, widespread use of network switches and secure authentication and communication protocols such as ssh and kerberos means that the GNU Queue protocol could be the weak link in the chain were it not to rely on a secure protocol such as TLS for reasonably secure communications.. Other potential areas of concern include denial-of-service attacks. While already somewhat reduced by the use of IP Access Control Lists in the standard implementation, situating the GNU Queue cluster behind a firewall can further mitigate these risks. A final concern might include attempts at client or server process spoofing. These spoofing attacks in general require that the malicious party already has shell access to one or both machines --- the malicious party is merely attempting to gain additional privileges. Properly configured, these risks have been addressed by the standard implementation of the protocol. When processes have root privileges available (installed by an administrator) secure ports are required. Otherwise, a facility for identd (RFC931) checking is available, but an identd server must be properly installed in the cluster. A further security precaution involves the use of a 128-bit one-time-pad, shared between client and server by means of the secure TLS protocol, to mutually authenticate client and server via a cryptographic digest algorithm. A poor, non-random generation of the one-time pad could compromise this approach. Protocols Used by GNU Queue July 2000 References 1 RFC-2026 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 RFC-2246 Dierks, T. and C. Allen "The TLS Protocol, Version 1.0", RFC 2246, January 1999. 3 Stevens, W., "UNIX Network Programming", ISBN 0-13-949876-1. 4 Federal Information Processing Standards Publication (FIPS PUB) 81, DES Modes of Operation, 1980 December 2. 5 RFC-1321 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. 6 RC4 Thayer, R. and K. Kaukonen, A Stream Cipher Encryption Algorithm, Work in Progress. 7 RFC-1282, Cantor, B., "BSD Rlogin", RFC 1282, December 1991. 8 RFC-2246 Dierks, T. and C. Allen "The TLS Protocol, Version 1.0", RFC 2246, January 1999. 9 RFC-931 StJohns, M., "Authentication Server", RFC 931, January 1985. 10 RFC-2617 Franks, J. et al., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. 11 RFC-1321 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. 12 Kaliski, B.,Robshaw, M., "Message Authentication with MD5", CryptoBytes, Sping 1995, RSA Inc, (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm) 13 RFC-2660 Rescorla, E. et al., "The Secure HyperText Transfer Protocol", RFC 2660, August 1999. 14 RFC-854 Postel, J. and Reynolds, J., "Telnet Protocol Specification", RFC 854, May 1983. 15 RFC-1143 Berstein, D., "The Q Method of Implementing TELNET Option Negotiation", RFC 1143, February 1990. 16 RFC-1282, Cantor, B., "BSD Rlogin", RFC 1282, December 1991. 17 Garfinkel & Spafford, "Practical Unix Security", ISBN 0-937175-72-2. Author's Address W. G. Krebs Free Software Foundation, Inc. Phone: 1-203-432-9380 59 Temple Place - Suite 330 Email: wkrebs@gnu.org Boston, MA 02111, USA Protocols Used by GNU Queue July 2000 Full Copyright Statement Copyright (C) W. G. Krebs (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. ** This document and the information contained herein is provided on an "AS IS" basis and THE AUTHORS AND THE FREE SOFTWARE FOUNDATION DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT Protocols Used by GNU Queue July 2000 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL THE AUTHORS OR THE FREE SOFTWARE FOUNDATION BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY MANNER RELATING TO THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.