Internet Engineering Task Force Alain Durand & Jean-Luc Richier INTERNET-DRAFT IMAG November, 1996 A.L.P.E.S. Administration deLocalisee Par Emissions Securisees a TCP/IP protocol 1. Status 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 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This memo defines the ALPES protocol to administrate remote hosts in an authenticated way. It has been assigned TCP port number 463 by IANA. 3. Background ALPES stands for Administration Delocalisee Par Emissions Securisees (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 text files and the execution of a controlled set of remote commands using hashed signatures. The choice of the hash function is implementation dependant ; however, MD5 [1] SHOULD be provided. If IPSec is available, a NULL hash function MAY be used. 5. Limitation of the Scope of ALPES The main point of ALPES is to transfer configuration text files between an information server and its clients and to execute programs on the server. ALPES does not tackle the issue of maintaining large trees of files or transferring binary files. 6. Inspiration The ALPES protocol is largely inspired from SMTP [2], the APOP command in POPv3 [3] and IP authentication using keyed MD5 [4]. ALPES is a unicast TCP/IP protocol built on top of TCP. 7. Protocol overview A client opens a session with a server. The session consists in sequences of one client command followed by one server answers. Each command and each answer is authenticated by a hashed signature. This signature is computed from a shared secret, the text of the message and a one time challenge. Each message provides the challenge to be used by the next message issued by the peer. The server issues an initial greeting message to bootstrap this mechanism. Several clients MAY initiate several sessions simultaneously. The way servers handle those sessions is implementation dependant. It MAY treat them simultaneously or it MAY serialized them. 8. Syntax In the rest of this document, the following syntax is adopted. The symbol <-- indicates client commands. The symbol --> indicates server responses. Strings surrounded by * * are implementation dependant comments. Strings surrounded by < > are arguments. /ch/resp/ will represent an authentication token. //resp/ , /ch// or /// are used in some cases to specify a special case authentication token. ch and resp are ASCII strings. ch is a challenge and resp a response. It MUST contains only characters in the ranges [A-Za-z0-9+@._-]. 9. Protocol Commands Very much like SMTP, ALPES is a text, line oriented protocol. The character set is any of the extended US-ASCII character set. Clients and server MUST share a common character set. It understands 10 commands keywords: EXEC FILES GET HASH HASHLIST HELLO HELP PROGS PUT QUIT All commands MUST be terminated by the sequence , i.e. ASCII code 13 and ASCII code 10. Command keywords are case insensitive. 10. ALPES Server Replies The server replies to any query either with a single line response or with a multi-line response. Each response line MUST begin with a 3 digit xyz reply code and MUST be terminated by the sequence . 10.1 The First Digit 1yz: keep message alive 2yz: positive replies 3yz: positive intermediary replies 4yz: transient negative replies 5yz: permanent negative replies 10.2 The Second Digit x0z: syntax x1z: information x2z: connection x3z: reserved x4z: reserved x5z: status 10.3 The Third Digit The third digit provides a finer gradation of the meaning of the reply code. 10.4 One-line answer A one-line answer consists of the 3 digit reply code followed by a separator (SPACEs or TABs) followed by an implementation dependant comment followed by an authentication field. If the comment is empty, the separator MAY be omited. Example: 553 no such program /122788243/9883958h354/ 10.5 Multi-lines answer A multi-line answer is made of continuation lines followed by a one-line answer. A continuation line consists of a 3 digit reply code followed by DASH ("-") followed by a text string. This string is a meaningful part of the answer. Note: the 3 digit reply codes MAY be different for each line of the multi-line answer. 11. Greeting When the TCP connection is established, the server emits a greeting message: 220 * Ready*/ch// ch is used to bootstrap the authentication mechanism. ch SHOULD be different for each new session. The server SHALL NOT accept any another command than HASHLIST, HELLO, HELP and QUIT until the client is authenticated. The server MAY refuse to start a session with some clients. In such a case, the server MUST reply: 521 *invalid connection*/// and close the connection. 12. Exceptional commands While the HELLO command has not been accepted by the server, a client MAY use three unauthenticated commands. 12.1 HASHLIST Syntax: HASHLIST The server lists the names of the hash functions supported by the server in a 250 multi-line answer. MD5 is mandatory. The last line of the answer MUST provide a new challenge. Example: <-- HASHLIST --> 250-MD4 --> 250-MD5 --> 250-NULL --> 250 OK. /ch// 12.2 HELP Syntax: HELP The server send information about available commands in a 250 multi-line answer. The last line of the answer MUST provide a new challenge. Example: <-- HELP --> 250-Commands: --> 250-EXEC [params] --> 250-FILES --> 250-GET --> 250-HASH --> 250-HASHLIST --> 250-HELLO --> 250-HELP --> 250-PROGS --> 250-PUT --> 250-QUIT --> 250-Contact Alain.Durand@imag.fr for more information. --> 250 OK. /ch// 12.3 QUIT Syntax: QUIT The server MUST reply: 221 * bye */// and then close the TCP connection. 13. HELLO 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. The session class is specified by the client with the HELLO command and is valid for the whole session. The client MUST also specify the hash function to use for authentication purposes. Syntax: HELLO /ch/resp/ If the class is unsupported, the server MUST reply: 550 *Invalid class.*/ch/resp/ If the hash function is unsupported, the server MUST reply: 551 *Invalid hash function.*/ch/resp/ If the authentication failed, the server MUST reply: 552 *Authentication failed.*/ch/resp/ If the command is successful, the server MUST reply: 250 *OK.*/ch/resp/ At this point, the client MAY not issue exceptional commands any more nor reissue the HELLO command. Example: --> 220 ganesha.imag.fr READY /4051// <-- HELLO mail MD5 /dsd34/fc2ea41588b1742a5bd88dc38b39640aj/ --> 552 Authentication failed /234/a0f3485739b76d0/ <-- HELLO mail MD5 /gdfg5/a0fef37ab797ade39b76d0/ --> 250 OK. /5fghh7/a0fef453222ea9b76d0/ 14. Getting information on the ALPES server The ALPES server maintains a list of files and programs. The client may request some information about them. Commands dealing with files or programs do not use the operating system dependant names of the real files. Instead, they use a key to identify unambiguously those files. Each class MUST define its own set of keys. The mapping of the key to the real name of the file (or program) is implementation dependant. Some servers MAY use a simple list of pair key/filename, other MAY use some generic patterns. The HASH, FILES, PUT and GET commands share the same name space for a given class. The PROGS and EXEC commands also share a common name space for a given class. 14.1 FILES With the FILES command, the client requests from the server the list of the keys of the maintained files for the current class. Syntax: FILES /ch/resp/ The server replies with a 250 multi-line answer containing the list of available file keys. Example: <-- FILES /dgdfgdg/dfgxffsf/ --> 250-aliases --> 250-reverses --> 250-hosts_Mail --> 250-sendmail.cf --> 250 OK. /sfsdfj245/dfgdhg567566756/ 14.2 PROGS With the PROGS command, the client requests from the server the list of the program keys of the program which may be executed in the current class. Syntax: PROGS /ch/resp/ The server replies with a 250 multi-line answer containing the list of available program keys. Example: <-- PROGS /sdfsdfsdf/235dsfsdfsf/ --> 250-stop-sendmail --> 250-start-sendmail --> 250-mkaliases --> 250-mkreverses --> 250 OK. /gjdfkgjdkjg536/sdfsdfjk5j76ysdf/ 15. Files Files may be transfered from the client to the server or from the server to the client. Files MUST be in an extended ASCII text format. Only maintained files MAY be transfered. 15.1 HASH With the HASH command, the client requests from the server the hashed checksum of a maintained file. Syntax: HASH /ch/resp/ If the command is successful, the server replies with a 250 multi- line answer containing the textual representation of the hashed checksum. 250- 250 *OK.* /ch/resp/ Otherwise, the server MUST answer one the the following error code: 553 *No such file * /ch/resp/ 554 *Execution problem* /ch/resp/ Example: <-- HASH sendmail.cf /sdsfsf/345345drsfsdxfs/ --> 250-c433bb0b30c0df8b36bedbe2a426e739 --> 250 OK. /hsdjhgjksg/435bec2ab612adb/ <-- HASH foobar /sdfsfsdfsdf234/sdfsfad7dfsdf/ --> 553 No such file foobar /dgdgdfgdgf/345345sdfsdfsfs/ <-- HASH aliases /98233jksdf/36rf/ --> 554 Execution problem /sdfsdf235/sdf546awds/ 15.2 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 /ch/resp/ If the file is not maintained, the server replies: 553 *No such file.* /ch/resp/ 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, each line being terminated by . The client marks the end of file with a single DOT (".") on a line by itself. If the file contains lines starting with a dot, an extra dot is added at the beginning of the line before the transmission. This is known as the dot-dot algorithm. The server MUST remove this extra dot. When the server receives the final dot, the transfer is over. The server MUST check the hashed checksum of the received file to determine whether the transmission is valid or not. If the transmission is successful, the server replies: 250 *OK.* /ch/resp/ if not: 554 *Transaction failed.* /ch/resp/ Example: <-- PUT reverses 24cc0acd9ccc /sfsfds/dsw435sef/ --> 354-Start file input, end with '.' on a line by itself <-- line number1 <-- .. <-- ... <-- line 3 <-- ..dgdfg <-- the end <-- . --> 250 OK. /sdfsfsdfsdf34535/sdfsdfsdfsdfsf34/ Note: for authentication purpose, the 354-.... line is part of the multi-line server answer. The text of transfered file is authenticated by the part of the PUT command. 15.3 GET With the GET command, the client requests from the server the content of a maintained file. Syntax: GET /ch/resp/ If the filekey is not maintained, the server replies: 553 *No such file* /ch/resp/ If the server cannot transfer the requested file, it replies: 554 *Transaction failed* /ch/resp/ If not, the server replies with a 250 multi-line answer. Each line contains exactly one line of the requested file. The last line MAY not be a part of the transfered file. It MAY contain some comments. Example: <-- GET reverses /sdfgsdf4536/sdfdt4225rwser/ --> 250-line number1 --> 250-. --> 250-line 3 --> 250-.. --> 250-the end --> 250 OK. /sdfsfsf/sdfsdtddfd/ 15.4 File representation To compute the hashed checksum of a file (for the HASH and PUT commands), the server MUST use the following file representation: - each line is terminated by the sequence - the dot-dot algorythm is not use - the file is represented in extended ASCII. 16. Remote Execution A client may request from a server the remote execution of programs. Only programs maintained by the server MAY be executed. With the EXEC command, the client requests the execution of a program. Syntax: EXEC [parameters...] /ch/resp/ If the program is not maintained on the server, it replies: 553 *No such program* /ch/resp/ If the program fails, the server replies: 554 *Execution failed* /ch/resp/ If not the server replies: 250 *OK.* /ch/resp/ 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 answer 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 /csddfsetgs/dfgkjdslkgjdlk/ --> 312-stopping sendmail --> 312-rebuilding aliases --> 315-warning: conflicting aliases --> 312-starting sendmail --> 250 OK. /dfgdfgdfg/346drgdfgd/ 17. HELP Syntax: HELP /ch/resp/ The server send information about available commands in a 250 multi-line answer. Example: <-- HELP /sdkfjh56/345sefsd/ --> 250-Commands: --> 250-EXEC [params] --> 250-FILES --> 250-GET --> 250-HASH --> 250-HASHLIST --> 250-HELLO --> 250-HELP --> 250-PROGS --> 250-PUT --> 250-QUIT --> 250-Contact Alain.Durand@imag.fr for more information. --> 250 OK. /hjdhge456h4jhd/dfgdfgdfgsdg/ 18. QUIT Syntax: QUIT /ch/resp/ The server MUST reply: 221 * bye * //resp/ and then close the TCP connection. 19. Syntax Errors If a server receives an invalid command, it replies: 500 *syntax error* /ch/resp/ 20. 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: 555 * timeout, closing connection.* /ch/resp/ The proposed delay is 5 minutes. 21. 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. those message MAY NOT be taken into account in the authentication process. 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. 22. Authentication mechanism Authenticating clients during the opening of the connection may not be enough. Intruders may forge an existing TCP connection. Authenticating every single message may prove a better solution. The authentication mechanism is based on a challenge/response system. The method used to build the response is a key point of the ALPES protocol. 22.1 Challenge The challenge is a text string that must be different each time. To resist replay attack, this challenge SHOULD be unique. A proposed solution is to use a string obtain by the concatenating: a) a textual NTP time stamp b) the process ID (if relevant) c) the IP address of the host 22.2 Response The response is the textual representation of the hashed valued of a computed authentication string. The hash function used is specified in the HELLO command. The authentication string is computed by the concatenation of: a) The shared secret. b) The peer challenge. c) The full text of the peer message from and including the 3 digit codes and up to and including the "/" preceeding the peer response. In the case of multi-line answer, all lines are taken into account (including the separators. d) The shared secret. 22.3 Failed authentication (server) If the server failed to authenticate the client command, the server MUST reply: 552 *authentication failed* /ch/resp/ It SHOULD then close the connection. It SHOULD log the event. 22.4 Failed authentication (client) If the client failed to authenticate the server, the client MAY end the session. To do so it SHOULD try to issue a QUIT command. If this failed again, it SHOULD close the connection. In any case, it SHOULD log the event. 23. Line length Theere is no need for line length limitation inside the ALPES protocol, however implementation MAY define a maximum line length which MUST be greater tham 4096 octets. 24. Port Number The ALPES protocol has been assigned TCP port number 463 by the IANA. 25. Reply Codes List 111 keep alive, I'm working for you... 220 greeting message 221 bye 250 OK 312 execution output message 315 execution error message 354 Start file input 500 syntax error 521 invalid connection 550 Invalid class 551 Invalid hash function 552 authentication failed 553 No such file/program 554 Execution failed 555 timeout 26. Grammar 26.1 Client commands grammar command :: non-auth-keyword CRLF :: keyword AUTH CRLF :: param-keyword SEP param AUTH CRLF :: param2-keyword SEP param SEP param AUTH CRLF :: paramN-keyword SEP param paramlist AUTH CRLF param-list :: :: SEP param param-list AUTH :: AUTHSEP challenge AUTHSEP response AUTHSEP :: SEP AUTHSEP challenge AUTHSEP response AUTHSEP AUTHSEP :: "/" SEP :: " " :: "" :: " " SEP :: "" SEP CRLF :: paramN-keyword :: "EXEC" param2-keyword :: "HELLO" :: "PUT" param-keyword :: "HASH" :: "GET" keyword :: "FILES" :: "PROGS" :: "HELP" :: "QUIT" non-auth-keyword :: "HELP" :: "HASHLIST" :: "QUIT" challenge :: [A-Za-z0-9+@._-]* response :: [A-Za-z0-9+@._-]* param :: [any printable character but SPACE or TAB]+ 26.2 Server responses grammar answer :: one-line-answer :: multi-line-anser one-line-answer :: 3digit SEP string AUTH CRLF :: 3digit AUTH CRLF multi-line-answer :: continuation-line multi-line-answer :: continuation-line one-line-answer continuation-line :: 3digit CONTINUATOR string CRLF 3digit :: [1-5][0-9][0-9] CONTINUATOR :: "-" string :: [printable character]* 27. ALPES State Diagram +------------------<----------+ | +- (error) ---------->| | | _______ | | |-/ HELP /----------->| V | ~~~~~~~ | | ___________ | (begin)--->|-/ HASHLIST /------->+ | ~~~~~~~~~~~ | | | +------------------<-------------+ | | +-- (error) --------------->| | | | ________ | | | |-/ FILES /---------------->| | | | ~~~~~~~~ | | | | ________ | | | |-/ PROGS /---------------->| | | | ~~~~~~~~ | | | | ______________ | | | |-/ HASH /---------->| | V | ~~~~~~~~~~~~~~ | | __________________ | ____________________ | |-/ HELLO /-->(auth)--|-/ PUT /---->| | ~~~~~~~~~~~~~~~~~~ | ~~~~~~~~~~~~~~~~~~~~ | | | _____________ | | |-/ GET /----------->| | | ~~~~~~~~~~~~~ | | | _____________________ | | |-/ EXEC * /--->| | | ~~~~~~~~~~~~~~~~~~~~~ | | | _______ | | |-/ HELP /----------------->+ | | ~~~~~~~ | | _______ | +-/ QUIT /--> (end) | ~~~~~~~ | _______ +-/ QUIT /--> (end) ~~~~~~~ 28. Security Considerations MD5 checksums are today one of the best known ways to assure authentication. However, it might one day be compromized, so the potentiality to change the hash function has been considered. 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. Executing programs with arguments might be dangerous. If the association key/filemane is made with generic patterns, one MUST make sure not to introduce security flaws by allowing access to unauthorized areas. Denial of service attacks are not taken care of. 29. Author address Alain Durand Jean-Luc Richier Institut d'Informatique et de Mathematiques Appliquees de Grenoble IMAG BP 53 38041 Grenoble CEDEX 9 France Phone : +33 4 76 63 57 03 Fax : +33 4 76 44 66 75 E-Mail: Alain.Durand@imag.fr Jean-Luc.Richier@imag.fr 30. Acknowledgements The authors gratefully acknowledge the many helpful suggestions of the following people: - Laurent Amon - Mike Parker - Jean-Claude Giese - ... 31. References [1] R. Rivest. The MD5 Message-Digest Algorithm, Request For Comments 1321 (April 1992) [2] J.B. Postel. Simple Mail Transfer Protocol, Request For Comments 821, STD 10 (August 1982). [3] J. Myers, M. Rose, Post Office Protocol - Version 3 Request For Comments 1725 (November 1994) [4] P. Metzger, W. Simpson. IP Authentication using Keyed MD5 Request For Comments 1828 (August 1995)