Internet Engineering Task Force Alain Durand INTERNET-DRAFT IMAG March, 1996 A.L.P.E.S. Administration deLocalisee Par Emissions Securisees a TCP/IP protocol 1. Status Distribution of this memo is unlimited. This document is an Internet Draft. 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. Internet Drafts 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 2. Abstract This memo defines the ALPES protocol to administrate remote hosts in an authenticated way. It has been assigned port number 463 by IANA. 3. Background ALPES stands for Administration Delocalisee Par Emissions Securisee (remote administration using secured messages). ALPES is a TCP/IP client server protocol build on top of TCP. Its main goal is to secure the administration of a network of computers. One of the most common and recurrent tasks of a network administrator is to maintain a copy of system files like /etc/passwd, /etc/printcap, /etc/aliases,... on every computer of the network. Mechanisms like NIS, rcp, rsh, rdist are important steps toward remote system administration but all of them have numerous and important security flaws. There is a need for a set of tools to maintain administration system files in a secured way. Those tools must be build on top of a secured protocol. 4. Security overview When dealing with security, one must consider two different issues: integrity and confidentiality. Integrity ensures that you are talking to the right peer and that messages are not corrupted during the data transmission. Confidentiality ensures that nobody but the right peer can read the transfered data. Integrity is the minimum security level to provide for system administration. Confidentiality is a valuable plus but raises several legal issues in certain countries. The ALPES protocol ensures integrity for the transfer and checksum of a controlled set of ASCII files and the execution of a controlled set of remote commands. The ALPES protocol offers two levels of integrity control. An ALPES client can either request authentication to take place only at the beginning of the TCP session or request that every single command and answer be authenticated. The authentication mechanism uses MD5 checksums. 5. Limitation of the Scope of ALPES The main point of ALPES is transfer configuration text files between an information server and its clients and to execute programs on them. ALPES does not tackle the issue of maintaining large trees of files. 6. Inspiration The ALPES protocol is largely inspired from SMTP [1] and from the APOP command in POPv3 [2]. ALPES is a unicast TCP/IP protocol built on top of TCP. 7. Protocol Commands Very much like SMTP, ALPES is a text protocol. It understands 12 commands: HELP HELLO HELO FILES PROGS MD5 PUT GET EXEC AUTH CLASS QUIT All commands MUST be terminated by the sequence , i.e. ASCII code 13 and ASCII code 10. Command keywords are case insensitive. 8. ALPES Server Replies The ALPES server replies to queries with a 3-digit xyz reply code, followed by a separator followed by a text string followed by an optional comment. All replies MUST be terminated by the sequence , i.e. ASCII code 13 and ASCII code 10. 8.1 The First Digit 1yz: keep message alive 2yz: positive replies 3yz: positive intermediary replies 4yz: transient negative replies 5yz: permanent negative replies 8.2 The Second Digit x0z: syntax x1Z: information x2z: connection x3z: reserved x4z: reserved x5z: status 8.3 The Third Digit The third digit gives a finer gradation of the meaning of the reply code. 8.4 One-line Responses If the responses take just one line, the separator MUST be SPACE (" ") or TAB. 8.5 Multi-lines Responses If the responses take more than one line, the separator MUST be DASH ("-") for all lines but the last one, for which it MUST be SPACE (" ") or TAB. 8.6 Text String The ALPES client MUST use only the 3-digit reply code received from the server during the state-change dialog. In one-line responses or in the last line of multi- line responses, text strings are merely given as comments. 8.7 Optional Comments The "#" character indicates a comment in the server reply. Everything on the line after and including this character MUST be discarded by the client. 9. On-line HELP At any time an ALPES client can request help with the HELP command. The ALPES server replies with a multi-line 250 reply code. In the rest of this document, the symbol <-- indicates client commands and the symbol --> indicates server responses. Syntax: HELP HELP Example: <-- HELP --> 250-ganesha.imag.fr ALPES server --> 250-Commands: --> 250- HELO HELLO --> 250- HELP FILES PROGS MD5 --> 250- PUT GET EXEC AUTH --> 250- QUIT --> 250-Contact Alain.Durand@imag.fr for more information. --> 250 OK. 10. Greeting When the TCP connection is established, the ALPES server emits a greeting message: 220 Ready / MUST be the fully qualified hostname of the ALPES server. is an ASCII string which MUST be different for each connection. This challenge MUST only contains characters in the ranges [A-Z], [a-z], [0-9], "." and "+". This session id allows the ALPES clients to be authenticated. The ALPES server SHALL NOT accept any another command than HELO, HELLO, CLASS, AUTH, HELP and QUIT until the client is authenticated. The ALPES server MAY refuse to open the connection to some clients. In such a case, the server MUST reply: 521 invalid connection 11. Classes Classes of services exist so that the ALPES server can be used for different purposes. One can for instance decide to maintain mail-related files and printer-related files in different classes. Class utilization is optional and MUST be declared by the ALPES client prior to authentication. The client MAY use the class option by issuing the command: CLASS If the class is recognized on the ALPES server, it replies: 250 OK If it is not recognized, the server replies: 551 invalid class If two or more classes commands are issued, only the last one will be validated. A class declaration is valid for the complete ALPES session. 12. Authentication The client and the server MUST share a common secret called password. If classes are used, a different password MAY be used for each client/classes couple. The client and the server MUST both do the following to compute a session response: a) concatenate the server's challenge, the common password and the server's challenge again into a string, b) compute the MD5 checksum of this string. Once the client has its response, it MUST send the following command to the ALPES server: HELLO or HELO The server then compares this response to the one it has computed. If they match, the client is authenticated, and the server replies: 250 OK. If the two response don't match, the server replies: 552 authentication failed The server MAY then close the connection. This authentication mechanism is inspired from the APOP mechanism in POP. It makes sure that no password is transmitted in clear over the network and that the transmitted string is never twice the same. Example: --> 220 ganesha.imag.fr READY 4051 <-- HELO fc2ea41588b1742a5bd88dc38b39640a --> 552 Authentication failed <-- HELO a0fef37ab797ad9f456fabc5e39b76d0 --> 250 OK. The client MAY NOT reissue the HELLO/HELO command. 13. Getting information on the ALPES server The ALPES server maintains a list of files and programs. The client MAY request some information about them. 13.1 FILES With the FILES command, the client requests from the server the list of the maintained files. Syntax: FILES The ALPES server replies with a multi-line 250 reply code. Example: <-- FILES --> 250-aliases # /etc/mail/aliases --> 250-reverses # /etc/mail/reverses --> 250-hosts_Mail # /etc/mail/hosts_Mail --> 250-sendmail.cf # /etc/mail/sendmail.cf --> 250 OK. 13.2 PROGS With the PROGS command, the client requests from the server the list of the programs which MAY be executed. Syntax: PROGS The ALPES server replies with a multi-line 250 reply code. Example: <-- PROGS --> 250-stop-sendmail # /etc/mail/programs/stop-sendmail --> 250-start-sendmail # /etc/mail/programs/start-sendmail --> 250-mkaliases # /etc/mail/programs/mkaliases --> 250-mkreverses # /etc/mail/programs/mkreverses --> 250 OK. 13.3 MD5 With the MD5 command, the client requests from the server the MD5 checksum of a maintained file. Syntax: MD5 The ALPES server replies: 250- 250 OK. or 553 No such file or 554 Execution problem Example: <-- MD5 sendmail.cf --> 250 c433bb0b30c0df8b36bedbe2a426e739 # /etc/mail/sendmail.cf <-- MD5 foobar --> 553 No such file foobar <-- MD5 aliases --> 554 Execution problem 14. File Transfer Files MAY be transfered from the client to the server or from the server to the client. Files MUST be in an ASCII text format. Only maintained files MAY be transfered. 14.1 PUT With the PUT command, the client requests that the server get ready for the input of the new content for a maintained file. Syntax: PUT [] If the file is not maintained, the ALPES server replies: 553 No such file. If it is maintained, the server replies: 354 Start input file, end with "." on a line by itself The client now sends the new file, line by line. It marks the end of file with a single DOT (".") on a line by itself. If the file contains lines with just dots, an extra dot is added at the beginning of the line before the transmission. This is known as the dot-dot algorithm. The server will then remove the extra dot. When the server receives the final dot, the transfer is over. The client MAY optionally specify the MD5 checksum of the transfered file. The server MUST then check the MD5 checksum of the received file to determine whether the transmission valid. If the transmission is successful, the server replies: 250 OK. if not: 554 Transaction failed Example: <-- PUT reverses 24cc0a7f492021c76dcf5b1820cd9ccc --> 354 Start file input, end with '.' on a line by itself <-- line number1 <-- .. <-- line 3 <-- ... <-- the end <-- . --> 250 OK. 14.2 GET With the GET command, the client requests from the server the content of a maintained file. Syntax: GET If the file is not maintained, the ALPES server replies: 553 No such file If the server cannot transfer the requested file, it replies: 554 Transaction failed If not, the server replies with a 250 multi-line response. Each line contains exactly one line of the requested file. Example: <-- GET reverses --> 250-line number1 --> 250-. --> 250-line 3 --> 250-.. --> 250-the end --> 250 OK. 15. Remote Execution An ALPES client MAY request from an ALPES server the remote execution of programs. Only programs maintained by the server MAY be executed. With the EXEC command, the client requests that the server execute a program. Syntax: EXEC [parameters] If the program is not maintained on the ALPES server, it replies: 553 No such program If the program failed, the server replies: 554 Execution failed If the execution is OK, the server replies: 250 OK. The parameters are passed as arguments to the program. The server MAY also redirect the output of the program to the client. The server then uses a multi-line reply in which all output lines are preceded by the 312 reply code and all error lines are preceded by the 315 reply code. Example: <-- EXEC mkaliases --> 312-stopping sendmail --> 312-rebuilding aliases --> 315-warning: conflicting aliases --> 312-starting sendmail --> 250 OK. 16. Extra Authentication (Optional) Authenticating clients during the opening of the connection may not be enough. Intruders may forge an existing TCP connection. So authenticating the clients and the server messages for every single command may prove a better solution. With the AUTH command, an ALPES client may request that the ALPES server perform authentication for every single command. Syntax: AUTH If the server is willing to manage this extra authentication, it replies: 250 OK// If not: 510 Command not supported The server's response MUST be computed as followed: a) concatenate , the common password, the full text of the server's reply (including CR/LF in case of multiline replies and the last / preceeding the server's response but excluding the server's response), and again b) compute the MD5 checksum of this string. If the server enters this extra authentication state, it MUST add two extra string for every single-line reply or in the last line of every multi-line reply. The first string holds a new server's challenge that the client MUST use to re-authenticate the next command. The ALPES server MUST use a different string for each of its challenges. A proposed solution is to concatenate a NTP time stamp and the server's IP address. The second string holds a MD5 checksum to authenticate the server's answers. This checksum MUST be computed according to the algorithm described above. A "/" character MUST be used to separate those strings from the text part of the server replies. Examples: 250 OK// 500 syntax error/# optional comment After entering this extra authentication state, the client MUST provide two extra arguments separated by a "/" to every commands but QUIT. A "/" character MUST be used to separate those strings from the text part of the client commands. The first one holds a new client's challenge. This challenge MUST be different for each command. The client MUST also ensure the this challenge is unique in the Internet. A proposed solution is to concatenate a NTP time stamp and the client's IP address. The second one is a new response. The client MUST use the new server's challenge to compute this new response. This client's response MUST be computed as followed: a) concatenate , the common password, the full text of the input command (including the client's challenge and the last "/" preceeding the client's response but excluding the client's response) and again into a string, b) compute the MD5 checksum of this string. Example: PUT []// If the client does not provide a response and a challenge, or if the response is invalid, the server MUST abort the command and reply: 552 authentication failed// The server MUST accept only one AUTH command per client connection. The server CANNOT come back to its original state where authentication was only performed at the beginning of the connection. If the server's response is invalid, the client MAY abort the connection. 17. Closing Session With the QUIT command, the client requests that the server close the TCP connection. Syntax: QUIT The server replies: 221 bye Example: <-- QUIT --> 221 ganesha.imag.fr bye 18. Syntax Errors If a server receives an invalid command, it replies: 500 syntax error 19. Time-out If an ALPES client does not send any request after a reasonable delay, the server MAY close the connection unilaterally. It then sends: 554 timeout, closing connection. The proposed delay is 5 minutes. 20. Application Keep Alive Remote execution of programs can take time. In the meantime, the client has no way of knowing if the connection is still up. In order to prevent this, the server MAY send multi-line 111 messages on a regular basis during the execution of the programs. 111-keep alive, I'm working for you... The client MUST discard those messages. Another advantage of these application keep alive is that servers can intercept a system error if the client breaks its connection during the execution of a time-consuming program. The server MAY then abort the program, saving CPU resources. 21. Port Number The ALPES protocol has been assigned port number 463 by the IANA. 22. Syntax of the Commands HELP [] HELO HELLO FILES PROGS MD5 PUT GET EXEC [parameters] QUIT 23. Reply Codes List 111 keep alive 220 greeting message 221 connection closing 312 program's STDOUT 315 program's STDERR 421 connection aborting 500 syntax error 521 invalid connection 551 invalid class 552 authentication failed 553 no such file/program 554 execution/transaction error 24. ALPES State Diagram +------------------<------+ | +- (error) ------>| | | _______ | | |-/ HELP /------->| V | ~~~~~~~ | | _____________ | (begin)--->|-/ CLASS /->+ | ~~~~~~~~~~~~~ | +------------------<------------+ | | +-- (error) ------------>| | | | ________ | | | |-/ FILES /------------->| | | | ~~~~~~~~ | | | | ________ | | | |-/ PROGS /------------->| | | | ~~~~~~~~ | | | | _____________ | | | |-/ MD5 /-------->| | V | ~~~~~~~~~~~~~ | | _____________ | ___________________ | |-/ HELLO /-> (hello) --|-/ put [MD5] /-->| | ~~~~~~~~~~~~~ | ~~~~~~~~~~~~~~~~~~~ | | | _____________ | | |-/ GET /-------->| | | ~~~~~~~~~~~~~ | | | __________________ | | |-/ EXEC [.] /--->| | | ~~~~~~~~~~~~~~~~~~ | | | _______ | | |-/ HELP /-------------->+ | | ~~~~~~~ | | _______ | |-/ AUTH /-------------->+ | | ~~~~~~~ | | | _______ | | +-/ QUIT /--> (end) | | ~~~~~~~ | | +-------------------<------------+ | | | | | +-------------------<------------------+ | | +-- (error) ------------------>| | | | _______________ | | | |-/ FILES/ /------------>| | | | ~~~~~~~~~~~~~~~ | | | | ________________ | | | |-/ PROGS// /----------->| | | | ~~~~~~~~~~~~~~~~ | | | | _____________________ | | | |-/ MD5 // /------>| | V | ~~~~~~~~~~~~~~~~~~~~~ | | _______ | ___________________________ | |-/ AUTH /-------> (auth) ---|-/ PUT [MD5]// /-| | ~~~~~~~ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | _____________________ | | |-/ GET // /------>| | | ~~~~~~~~~~~~~~~~~~~~~ | | | __________________________ | | |-/ EXEC [.]// /->| | | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | _______ | | |-/ HELP /-------------------->+ | | ~~~~~~~ | | _______ | +-/ QUIT /--> (end) | ~~~~~~~ | _______ +-/ QUIT /--> (end) ~~~~~~~ 25. Security Considerations MD5 checksums are one of the best ways to assure authentication. The ALPES protocol allows the manipulation of system tables in a very restricted environment and thus can be regarded as safer than using rsh commands. 26. Author address Alain Durand Institut de Mathematiques Appliquees de Grenoble (IMAG) BP 53 38041 Grenoble CEDEX 9 France Phone : +33 76 63 57 03 Fax : +33 76 44 66 75 E-Mail: Alain.Durand@imag.fr 27. References [1] J.B. Postel. Simple Mail Transfer Protocol, Request For Comments 821, STD 10 (August 1982). [2] J. Myers, M. Rose, Post Office Protocol - Version 3 Request For Comments 1725 (November 1994) 28. Acknowledgements I would like to thank Laurent Amon for his help in reviewing this paper.