One document matched: draft-durand-alpes-00.txt
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
<draft-durand-alpes-00.txt>
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 <CR-LF>, 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 <CR-LF>, 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 <command>
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 <hostname> Ready /<server's challenge>
<hostname> MUST be the fully qualified hostname of the ALPES server.
<server's challenge> 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 <class-name>
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 <response>
or
HELO <response>
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 <file>
The ALPES server replies:
250-<MD5-checksum>
250 OK.
or
553 No such file <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 <file> [<MD5-checksum>]
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 <file>
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 <program> [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 <client's challenge>
If the server is willing to manage this extra authentication,
it replies:
250 OK/<new server's challenge>/<server's response>
If not:
510 Command not supported
The server's response MUST be computed as followed:
a) concatenate <client's challenge>, 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 <client's challenge>
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/<server's challenge>/<server's response>
500 syntax error/<server's challenge># 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 <new server's challenge>, 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 <new session id>
into a string,
b) compute the MD5 checksum of this string.
Example:
PUT <file> [<MD5 checksum>]/<client's challenge>/<response>
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/<server's challenge>/<server's response>
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 <hostname> 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 <hostname> 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 [<command>]
HELO <session-response>
HELLO <session-response>
FILES
PROGS
MD5 <file>
PUT <file>
GET <file>
EXEC <file> [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 <id> /->+
| ~~~~~~~~~~~~~
| +------------------<------------+
| | +-- (error) ------------>|
| | | ________ |
| | |-/ FILES /------------->|
| | | ~~~~~~~~ |
| | | ________ |
| | |-/ PROGS /------------->|
| | | ~~~~~~~~ |
| | | _____________ |
| | |-/ MD5 <file> /-------->|
| V | ~~~~~~~~~~~~~ |
| _____________ | ___________________ |
|-/ HELLO <id> /-> (hello) --|-/ put <FILE> [MD5] /-->|
| ~~~~~~~~~~~~~ | ~~~~~~~~~~~~~~~~~~~ |
| | _____________ |
| |-/ GET <file> /-------->|
| | ~~~~~~~~~~~~~ |
| | __________________ |
| |-/ EXEC <prog> [.] /--->|
| | ~~~~~~~~~~~~~~~~~~ |
| | _______ |
| |-/ HELP /-------------->+
| | ~~~~~~~
| | _______
| |-/ AUTH /-------------->+
| | ~~~~~~~ |
| | _______ |
| +-/ QUIT /--> (end) |
| ~~~~~~~ |
| +-------------------<------------+
| |
| |
| +-------------------<------------------+
| | +-- (error) ------------------>|
| | | _______________ |
| | |-/ FILES/<c/<k> /------------>|
| | | ~~~~~~~~~~~~~~~ |
| | | ________________ |
| | |-/ PROGS/<c>/<k> /----------->|
| | | ~~~~~~~~~~~~~~~~ |
| | | _____________________ |
| | |-/ MD5 <file>/<c>/<k> /------>|
| V | ~~~~~~~~~~~~~~~~~~~~~ |
| _______ | ___________________________ |
|-/ AUTH /-------> (auth) ---|-/ PUT <file> [MD5]/<c>/<k> /-|
| ~~~~~~~ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| | _____________________ |
| |-/ GET <file>/<c>/<k> /------>|
| | ~~~~~~~~~~~~~~~~~~~~~ |
| | __________________________ |
| |-/ EXEC <prog> [.]/<c>/<k> /->|
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| | _______ |
| |-/ 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.
| PAFTECH AB 2003-2026 | 2026-04-24 01:29:33 |