Internet Draft W. Krebs Document: draft-krebs-gnuqueue-protocol-02.txt FSF Category: Experimental July 2001 Expires: January 2002 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 Expires January 2002 Table of Contents Status of this Memo...................................................1 Copyright Statement...................................................1 Table of Contents.....................................................2 Abstract..............................................................3 Overview..............................................................4 Transport Layer Protocols.............................................4 Mutual Authentication Protocol........................................4 Job Control File......................................................7 Host Selection Protocol...............................................9 Secure Rlogin-like Protocol Description..............................11 GNU Queue main loop ................................................11 Signal Information from Client to Server ..........................12 Client-side implementation ......................................12 Server-side implementation ......................................12 Signal Information Flow from Server to Client .....................13 Connection Closure .................................................13 Security Considerations..............................................13 References...........................................................15 Author's Address.....................................................15 Full Copyright Statement.............................................16 Protocols Used by GNU Queue Expires January 2002 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://www.gnuqueue.org . Protocols Used by GNU Queue Expires January 2002 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://www.gnuqueue.org . 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. Mutual Authentication Protocol This memo defines two protocols that require GNU Queue clients and servers to mutually authenticate themselves to one another. This authenticate scheme is used in both the job control file transfer protocol and the rlogin-like protocol. Upon connecting establishment, both protocols require the process accepting the inbound socket connection normally to check 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) [7] 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 GNU Queue processes are running with full Protocols Used by GNU Queue Expires January 2002 operating system privileges, they should bind a reserved port before connecting to one another. Following connection establishment in the job control file transfer and rlogin-like protocols, GNU Queue processes authenticate themselves to each using a scheme similar to the HTTP Digest Authentication (RFC2617) [8] scheme. The job control file transfer protocol uses a cluster-wide master password as the shared secret; digest authentication is used, because it ensures that the master password is never transmitted in the clear, even when an insecure transport layer protocol implementation is used. The rlogin-like protocol uses a job-specific, one-time cookie 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. GNU Queue uses SHA1 [9], the modified Secure Hash Algorithm, as the hash function, because at the time of writing it was perceived to be more secure than MD5, which was used as the has function in RFC 2617. The implementation of SHA1 used by GNU Queue (see source code, http://www.gnuqueue.org) converts the 160-bit binary hash into its 40 character ASCII hexadecimal expansion. 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 SHA1 algorithm is a form of known plaintext attack, known to make cryptanalysis much easier [10]. The solution is to have the server (Digest authentication client) send a challenge of its own ("cnounce") which is incorporated into the final hash. In GNU Queue, the nounce and cnounce are ASCII and may not be more than 20 characters. 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 socket originator (digest authentication client): ASCII cnounce string GNU Queue socket acceptor (digest authentication server): ASCII nounce string GNU Queue socket originator: ASCII-SHA1(concat(cookie,nounce,cnounce)) This proves that the two GNU Queue processes both know the shared secret without revealing it to either party or sending it over the network. In the rlogin-like protocol, if the either side fails to send the correct response within a reasonable period of time (10 seconds in a LAN environment is suggested), the client drops the Protocols Used by GNU Queue Expires January 2002 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 in the rlogin-like protocol, 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 socket acceptor can authenticate itself to the GNU Queue socket originator. As above, if the rlogin-like protocol 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 in the rlogin-like protocol. Failed authentication in the job control file transfer protocol is more ominous: the connection is dropped and the error is logged. Like HTTP Digest Authentication the scheme is still vulnerable to man-in- the-middle attacks. The exchange is: GNU Queue socket acceptor (now digest authentication client): ASCII cnounce string GNU Queue socket originator (digest authentication server): ASCII nounce string GNU Queue socket acceptor: ASCII-SHA1(concat(nounce,cookie,cnounce)) originator: [ or if there is an error ] At this point, both GNU Queue processes have successfully proven that know the shared secret. The digest authentication scheme used by GNU Queue is essentially a symmetric cryptographic system. TLS supports asymmetric cryptographic key certificates as a means of authentication using a scheme such as RSA. This scheme has some advantages over the shared secret scheme used by GNU Queue. Rather than having both processes know a single shared secret, each process has a private and a public key. The process signs a "certificate" with its cryptographically strong public key. The nature of the asymmetric cryptographic process is such that the other party can verify that the certificate has been signed by the private key using the published public key, but it is extremely hard to generate the private key corresponding Protocols Used by GNU Queue Expires January 2002 to the published public key. Multiple keys could be used. There could be a published "master key" allowing execution of jobs through an organization, and varying types of "sub-master keys" allowing execution of jobs only within specific departments. Keys could have expiration dates as well, making it possible to gradually phase out older keys. The shared secret scheme used by GNU Queue is much simpler. An identical shared secret master node password must be used on every node in the cluster. However, this scheme is completely adequate for the systems GNU Queue is currently used on. As it relies only a one-way hash, it is unencumbered by legal restrictions attached to public key and even some symmetric key cryptographic algorithms. The protocol has the additional advantage that it still retains some security when used with the insecure but widely available TCP/IP protocol. 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 [11] 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. 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 an ASCII one-time magic cookie, which will subsequently be used for authentication and as a job control file ID. (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 Protocols Used by GNU Queue Expires January 2002 An ASCII job-specific magic cookie, used for authentication 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 An ASCII job-specific magic cookie, used for authentication 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.] 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 Protocols Used by GNU Queue Expires January 2002 Node 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 node to which the job control file is to be sent is determined by the node selection protocol. This memo describes node selection protocol VERSION0. Future revisions of this document may include more sophisticated node selection protocols, including highly scalable hierarchical querying schemes designed for large networks, or protocols that perform capability queries of potential target nodes. In VERSION0 of this protocol, however, the cluster is surveyed by simply querying every node in the cluster once per job submitted. This is done by establishing a TLS [12] socket connection to the server on a predetermined port reserved for this purpose. The format is as follows: "QUERY" "VERSION0" [this is the version specifier string, without quotes.] job control file version string from job control file ASCII queue-name 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. Typically, 1e08 is the magic value returned if the batch queue cannot start new jobs; e.g., it is already running the maximum number of jobs in that batch queue on that node. Protocols Used by GNU Queue Expires January 2002 A GNU Queue client typically proceeds by surveying each node in the cluster with this protocol. Usually, it will elect the node which returns the lowest "load average" in the selected batch queue. At this point, it will send the file to the elected node. 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: "JOBCONTROLFILE" "VERSION0" protocol version specifier string, without quotes. "VERSION1"specifying the first string in the job control file (must be VERSION1 in this memo.) The previously described digest authentication protocol exchange now follows with cluster master password used as cookie. If authentication is successful, the protocol continues: Name of batch queue run is be run in The integer "-1" sent as signed four byte integer, network order Job control file as binary data 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; normally the connection will simply be terminated. 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" 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 node may decide that conditions for running the job are unfavorable. Typically, the node cannot run the job in the specified batch queue because it is already running the maximum number of jobs in that queue, or because the load average has exceeded the maximum load average allowed for starting jobs in this queue. In this case, it may turn itself into a Protocols Used by GNU Queue Expires January 2002 client and follow the above querying protocol to locate a more suitable host. If it finds a more suitable host (one in which a query does not respond return a load of "1e08" for this batch queue), it may act as a client and retransmit the job control file to this new server using the previously described protocol. It is important that the query protocol return "1e08" when it cannot start new jobs in a given batch queue to prevent needless shuttling of jobs between cluster nodes. 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. The initial exchange involves the mutual digest authentication scheme described in the section "Mutual Authentication Protocol." The job receiving process (typically, the "queued" GNU Queue server process") is the socket originator. The shared secret is the job specific one-time cookie from the job control file. (For this reason, the job control file transmission protocol TLS stream should normally be encrypted.) Following successful mutual authentication (as indicated by the final null byte from "queued" to the "queue" client), the job receiving process ("queued" server) opens a second outgoing socket and determines the local port number of this socket. This is sent to the client on the original socket as a null terminated ASCII string. At this point, a connection consisting of two two-way TLS/TCP/IP sockets is established between server and client. 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. Protocols Used by GNU Queue Expires January 2002 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. (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. Current implementation used the system numbering found in the RedHat Linux 6.2 operating system, which shares the important signal numbers -- SIGHUP, SIGTERM, SIGKILL, SIGSTOP, SIGCONT, SIGTSTP, SIGPIPE, etc. -- with other flavors of Unix. If the client is running a different operating system and wishes to send a signal which has a different number than its equivalent under Linux, the signal number is translated to the Linux numbering scheme before being sent to the server. Similarly, if the server is not running Linux, it should either translate non-standard signal numbers from Linux to the equivalent under its operating system, or simply ignore numbers for non-standard signals.) 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 as a "struct winsize" data structure as implemented under RedHat Linux 6.2; the format of this data structure is not likely to change in future implementations of the Linux operating system. 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 Linux "struct winsize" structure from the socket and Protocols Used by GNU Queue Expires January 2002 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. 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 Protocols Used by GNU Queue Expires January 2002 The GNU Queue protocol (as implemented), like rlogin [13] 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 [14]. 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. 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 job-specific one-time ASCII 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, as could insecure communications if the job control file is transmitted in the clear. Protocols Used by GNU Queue Expires January 2002 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-931 StJohns, M., "Authentication Server", RFC 931, January 1985. 8 RFC-2617 Franks, J. et al., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. 9 "SECURE HASH STANDARD", NIST Federal Information Processing Standards Publication 180-1, 1995; ANSI X9.30 (Part 2), "...Part 2: The Secure Hash Algorithm (SHA)", ASC X9 Secretariat - American Bankers Association, 1993; ISO/IEC 10118-3, "Information Technology - Security Techniques - Hash Functions - Part3: Dedicated hash functions", draft, 1996. 10 Kaliski, B.,Robshaw, M., "Message Authentication with MD5", CryptoBytes, Sping 1995, RSA Inc, (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm) 11 RFC-1282, Cantor, B., "BSD Rlogin", RFC 1282, December 1991. 12 RFC-2246 Dierks, T. and C. Allen "The TLS Protocol, Version 1.0", RFC 2246, January 1999. 13 RFC-1282, Cantor, B., "BSD Rlogin", RFC 1282, December 1991. 14 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 Expires January 2002 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.