Network Working Group Internet Engineering Task Force
Internet-Draft Common Authentication Technology Working Group
Updates: RFC 959 S. J. Lunt
<draft-ietf-cat-ftpsec-05.txt> Bellcore
April 1994
FTP Security Extensions
Status of this Memo
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 ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list.
1. Abstract
This document defines extensions to the FTP specification RFC 959,
"FILE TRANSFER PROTOCOL (FTP)" (October 1985), which provide strong
authentication, integrity, and confidentiality on both the control
and data channels with the introduction of new optional commands,
replies, and file transfer encodings.
The following new optional commands are introduced in this
specification:
AUTH (Authentication Type),
ADAT (Authentication Data),
MIC (Integrity Protected Command),
ENC (Privacy Protected Command),
PROT (Data Channel Protection Level), and
PBSZ (Protection Buffer Size).
Expires: October 31, 1994 [Page 1]
Internet-Draft FTP Security Extensions April 1994
A new class of reply types (6yz) is also introduced for protected
replies.
None of the above commands are required to be implemented, but each
is dependent on the other (except ENC, which is optional).
Note that this specification is compatible with RFC 959.
2. Motivation
The File Transfer Protocol (FTP) currently defined in RFC 959 and in
place on the Internet uses usernames and passwords passed in
cleartext to authenticate clients to servers (via the USER and PASS
commands). Except for services such as 'anonymous' FTP archives,
this represents a security risk whereby passwords can be stolen
through monitoring of local and wide-area networks. This either aids
potential attackers through password exposure and/or limits
accessibility of files by FTP servers who cannot or will not accept
the inherent security risks.
Aside from the problem of authenticating users in a secure manner,
there is also the problem of protecting sensitive data and/or
verifying its integrity. An attacker may be able to access valuable
or sensitive data merely by monitoring a network, or through active
means may be able to delete or modify the data being transferred so
as to corrupt its integrity. An active attacker may also initiate
spurious file transfers to and from a site of the attacker's choice,
and may invoke other commands on the server. FTP does not currently
have any provision for the encryption or verification of the
authenticity of commands, replies, or transferred data. Note that
these security services have value even to anonymous file access.
Current practice for sending files securely is generally either:
1. via FTP of files pre-encrypted under keys which are manually
distributed,
2. via electronic mail containing an encoding of a file encrypted
under keys which are manually distributed,
3. via a PEM message, or
4. via the rcp command enhanced to use Kerberos.
None of these means could be considered even a de facto standard, and
none are truly interactive. A need exists to securely transfer files
using FTP in a secure manner which is supported within the FTP
Expires: October 31, 1994 [Page 2]
Internet-Draft FTP Security Extensions April 1994
protocol in a consistent manner and which takes advantage of existing
security infrastructure and technology. Extensions are necessary to
the FTP specification if these security services are to be introduced
into the protocol in an interoperable way.
Although the FTP control connection follows the Telnet protocol, and
Telnet has defined an authentication and encryption option [5], RFC
1123 [4] explicitly forbids the use of Telnet option negotiation over
the control connection (other than Synch and IP). Also, the Telnet
authentication and encryption option does not provide for integrity
protection only (without confidentiality), and does not address the
protection of the data channel.
3. New FTP Commands
The following commands are optional, but dependent on each other.
They are extensions to the FTP Access Control Commands.
AUTHENTICATION TYPE (AUTH)
The argument field is a Telnet string identifying a supported
authentication mechanism. The command represents a request to
perform an authentication protocol exchange based on an
authentication mechanism identified by the argument. Currently,
only KERBEROS_V4 and GSSAPI are defined.
If the server accepts an authentication type with reply code 334,
then the client must next initiate an authentication exchange (via
the ADAT command) based on that authentication type. The goal of
the authentication exchange is to strongly authenticate the user
to the server, and to establish a security context [3] under which
protection of the control and data channels may be performed.
If the server replies with a 234 code, then the authentication
type is accepted, and no ADAT commands are required. This is
useful to indicate to the server that the password to be sent in a
subsequent PASS command is to be interpreted differently than
normal, as in the case of smart cards or other non-disclosing
password systems. Challenge information intended for human
interpretation may be contained in the reply. Such information
may also be conveyed in the text of the reply to the USER command.
It should be noted that "smart" clients which obscure from the
user the text of the USER command may hinder incorporation of
one-time password schemes (e.g., S/Key). It is important that the
client display the text of the USER response to the user *prior*
to prompting for a password. These one-time password systems may
be incorporated in servers without need for client modification
since the challenge is one way.
Expires: October 31, 1994 [Page 3]
Internet-Draft FTP Security Extensions April 1994
If the server rejects a type (reply code 504), or any ADAT command
fails, then the client may try another authentication type by
issuing another AUTH command, or may continue by sending USER and
PASS commands. Thus, the client should request authentication
types in decreasing order of preference (i.e., strength). The
server will reject (with a 503 reply code) any AUTH or ADAT
commands sent after an authentication protocol successfully
completes.
The client should not require the server to support the AUTH
command or any particular authentication type. If either the
server does not support the AUTH command (reply code 500), or the
client and server cannot agree on an authentication type, or no
authentication exchange succeeds, then the default USER and PASS
commands must be performed.
The AUTH command will normally be the first command transmitted by
the user after the control connection is made, generally before
the USER command. However, some authentication protocols may
require prior knowledge of the remote user name (e.g., some
challenge/response systems). In this case, the USER command may
be sent in advance of the AUTH command.
Some servers will require that authentication be performed before
certain commands (including USER) will be accepted. In this case,
a 530 reply will be sent in response to these commands indicating
that an authentication exchange is required.
AUTHENTICATION DATA (ADAT)
The argument field is a Telnet string representing base 64 encoded
authentication data (see Section 5, "Base 64 Encoding"). The data
is specific to the authentication protocol specified by the
previous AUTH command. The ADAT command, and the associated
replies, allow the client and server to conduct an arbitrary
authentication protocol. The client will send authentication data
to the server via the ADAT command, and the server will send
authentication data back to the client by including "ADAT=string"
in the reply, where string is also a Telnet string representing
base 64 encoded authentication data. The server will reply 501 if
the string could not be base 64 decoded.
If the server sends a 535 reply, then the authentication data
could not be successfully processed, and the client has not been
authenticated. The client may either try another authentication
type by sending another AUTH command, or may send USER and PASS
commands. The server will reply 503 if no AUTH command was
previously accepted.
Expires: October 31, 1994 [Page 4]
Internet-Draft FTP Security Extensions April 1994
If the server sends a 335 reply, then the authentication data was
successfully processed, but more authentication data is necessary
to complete the authentication process. In this case, the server
must include encoded authentication data in the reply. The client
must process this returned data and then issue another ADAT
command.
If the server sends a 235 reply, optionally including encoded
authentication data, then the server considers the client
authenticated. The client must process any authentication data
present in the reply.
Appendix I defines the actual protocol for KERBEROS_V4. Appendix
II defines the actual protocol for the GSSAPI.
If an authentication exchange succeeds, then the client's identity
has been authenticated but not yet authorized. The client must
next invoke the USER command to identify to the server the account
(file system) for which access is requested. If the USER command
results in a 231 reply, then the client is authorized, and no
password is required. However, the client must then send the PASS
command to actually log the user in (the actual password is
ignored by the server and should be a dummy value). If the USER
command results in a 333 reply, then the user was not authorized
without a password, and a password must be sent with the PASS
command. In this case, it is recommended that the PASS command be
ENC protected. Additional USER or PASS commands may be sent after
success of an ADAT command.
Once the client is successfully authenticated via AUTH and ADAT
commands, the rest of the data over the control channel (commands
and replies) must be protected, either with integrity (by a
cryptographic checksum) via the MIC command, or with
confidentiality (by encryption) via the ENC command. (Also see
Section 4 on protected replies.) These two commands may be
arbitrarily intermixed. It is up to the client to decide which of
MIC and ENC commands to use, and it is up to the server when to
accept either. The server will return a 502 reply to any other
command. The server will return a 500 reply to a MIC or ENC
command if no ADAT command succeeded.
Commands sent via the Telnet out-of-band signal must also be
protected. That is, if the client sends the Telnet "Interrupt
Process" (IP) signal followed by the Telnet "Synch" signal, then
the command sent to the server immediately afterwards must also
protected.
A requirement of all specifications for authentication exchanges
based on new authentication types is that they convey to the
caller whether encryption is supported on the resultant security
Expires: October 31, 1994 [Page 5]
Internet-Draft FTP Security Extensions April 1994
context, since it is not a requirement that the ENC command, 632
protected replies, or the Private protection level be supported.
It is also strongly suggested that the per message protection
services supported by each mechanism perform message replay and
out-of-sequence detection, since no provision for these services
is explicitly made within this specification.
Since no explicit provision is made in this specification for the
negotiation of alternate mechanisms for performing per message
protection services, implementors should instead utilize the token
exchange for this purpose.
INTEGRITY PROTECTED COMMAND (MIC)
The argument field is a Telnet string consisting of a base 64
encoded "safe" message produced by an authentication mechanism
specific message integrity procedure. The server will decode the
received string, verify its integrity via the authentication
mechanism specific message integrity procedure, and upon success,
interpret the resultant string as an FTP command. The user-
process need not include the Telnet end-of-line code within the
encoded command.
The server will return a 501 reply if the argument could not be
properly base 64 decoded.
The server will return a 535 reply to any MIC command which fails
checksum, replay, sequencing, or other applicable security checks.
The server may return a 402 reply to a MIC command if it is not
willing to accept MIC commands and instead will accept ENC
commands only. In this case, the client should retry the enclosed
command under ENC protection.
The three replies defined above must themselves be protected.
There are no other direct replies from MIC or ENC commands; the
resultant FTP command will generate its own replies.
When the client's native character set is not ASCII, the client
must translate the encapsulated command to ASCII before passing it
to the authentication mechanism specific message protection
routine. When the server's native character set is not ASCII, the
server must translate the encapsulated command from ASCII after
passing the token to the authentication mechanism specific message
protection routine.
PRIVACY PROTECTED COMMAND (ENC)
Expires: October 31, 1994 [Page 6]
Internet-Draft FTP Security Extensions April 1994
The argument field is a Telnet string consisting of a base 64
encoded "private" message produced by an authentication mechanism
specific message confidentiality procedure. The server will
decode the received string, verify its integrity and
confidentiality via the authentication mechanism specific message
confidentiality procedure, and upon success, interpret the
resultant string as an FTP command.
It is strongly recommended that PASS commands be sent under ENC
protection, when possible.
The server will return a 501 reply if the argument could not be
properly base 64 decoded.
The server will return a 535 reply to any ENC command which cannot
be properly decrypted, or fails checksum, replay, sequencing, or
other applicable security checks.
The server will return a 402 reply if it does not support the ENC
command. In this case, the client should retry the enclosed
command under MIC protection.
The three replies defined above must themselves be protected.
DATA CHANNEL PROTECTION LEVEL (PROT)
The argument is a single Telnet character code specifying the data
channel protection level. The PROT command will be rejected and
the server will reply 504 if no previous ADAT command succeeded,
or the specified protection level is not supported. Upon success,
a 200 reply will be sent by the server, indicating that the new
protection level is now in effect.
The following codes are assigned for protection levels:
C - Clear
S - Safe
P - Private
The default protection level is Clear. The Safe protection level
is required to be implemented by all authentication types which
exchange ADAT commands, but the Private protection level is
optional.
When using the Safe protection level, all data sent over the data
channel is to be integrity protected by cryptographic checksum.
When using the Private protection level, all data sent over the
data channel is to be privacy protected by encryption.
Expires: October 31, 1994 [Page 7]
Internet-Draft FTP Security Extensions April 1994
The sender will apply protection services after all data
transformations associated with the current representation type,
file structure, and transfer mode have been performed. The data
sent over the data channel is, for the purposes of data
protection, to be treated as a byte stream. An authentication
mechanism specific data protection procedure will be employed by
the sender to protect this byte stream. The procedure should
process a buffer of bytes at a time, and send the result as a
stream of bytes, prepending each transferred ciphertext buffer
with a four byte length field (most significant byte first)
indicating the length of the ciphertext buffer. A maximum buffer
length must be negotiated with the PBSZ command (see the next
section) before the first PROT command will be accepted (there is
no default maximum buffer size). Implementors must ensure that
they encrypt a maximum cleartext buffer somewhat smaller than the
negotiated maximum such that the resultant ciphertext buffer is
assured to be no greater than this maximum. The receiver will
read the four byte length field, and then read that number of
bytes of protected data, passing the buffer to an authentication
mechanism specific data protection procedure. Further buffers
will be similarly read and processed until all bytes are sent.
Any transformations associated with the current representation
type, file structure, and transfer mode would then be performed by
the receiver on the resultant data. When using block transfer
mode, the sender's (cleartext) buffer size is independent of the
block size.
Under the Clear protection level (i.e., as currently defined in
RFC 959), and when in stream mode, the sender indicates end of
file by closing the data connection. This is inherently
unreliable, since the receiver cannot determine whether the
connection was closed prematurely. Transferring files under the
Safe or Private protection level allows the sender to convey a
positive indication of end of file by sending a protected buffer
which contains zero bytes of cleartext data. Upon receipt of such
a zero length cleartext buffer, the recipient should close the
data connection (without further reading from the connection) and
consider the file transfer complete. If the connection is closed
before such a buffer is received, then the file transfer should be
aborted, and the user should be alerted. If the server was the
recipient, then it should send a 535 reply in this case.
The PROT command will be rejected and the server will reply 503 if
no previous PBSZ command was issued.
The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or
APPE command if the current protection level is not at the level
dictated by the server's security requirements for the particular
file transfer.
Expires: October 31, 1994 [Page 8]
Internet-Draft FTP Security Extensions April 1994
If any data protection services fail at any time during data
transfer at the server end (including an attempt to send a buffer
size greater than the negotiated maximum), the server will send a
535 reply to the data transfer command (either STOR, STOU, RETR,
LIST, NLST, or APPE).
PROTECTION BUFFER SIZE (PBSZ)
The argument is a decimal integer representing the maximum number
of bytes to be sent or received in a protected buffer during file
transfer. This number shall be no greater than can be represented
in 32 bits.
This command allows the FTP client and server to negotiate a
maximum protected buffer size for the connection. There is no
default size; the client must issue a PBSZ command before it can
issue the first PROT command. Upon success, a 200 reply will be
sent by the server. The server must convey its maximum buffer
size in the reply by including "PBSZ=number" in the reply, where
number is also a decimal integer. If the server does not include
this number in the reply, or the client cannot parse the response,
then the client should use the maximum buffer size which it had
sent in the PBSZ command. Otherwise, the client and server will
use the minimum of the two values as the true maximum buffer size.
A client may send another PBSZ command at any time.
The PBSZ command will be rejected and the server will reply 503 if
no previous ADAT command succeeded, and will reply 504 if the
specified protection buffer size cannot be represented in 32 bits.
4. New FTP Replies
All replies after a successful ADAT command must be protected. A new
reply type is introduced for this purpose, indicated by a sixth value
for the first digit of the reply code:
6yz Protected reply
The text of this reply is to be decoded and interpreted as an FTP
reply (if such decoding is successful). If the reply code is 631,
then the text of the reply is integrity protected in the same
manner as MIC commands. If the reply code is 632, then the text
of the reply is privacy protected in the same manner as ENC
commands. The server need not include the Telnet end-of-line code
within the encoded reply. All replies must be protected once an
ADAT command succeeds. The server may send a protected reply only
if a previous ADAT command succeeded.
Expires: October 31, 1994 [Page 9]
Internet-Draft FTP Security Extensions April 1994
The security policy of the server will dictate when 631 or 632
replies are to be used. As a general rule, the server should send
a 631 reply to a MIC command, and a 632 reply to an ENC command.
The server must not send 632 replies if the client does not
support encryption (this should be indicated by the security
context). If, upon context establishment, it is not known whether
the client supports encryption, then the server may send a 632
reply only if client support of encryption has been indicated
implicitly by means of the client issuing an ENC command or a PROT
P command.
Multi-line replies are handled as follows. If the server sends a
protected reply in which the decoded reply has a hyphen ("-")
immediately following the reply code, then the server will send
the rest of the lines of text of the multi-line reply each
protected and base 64 encoded as was the first line, and each
followed by the Telnet end-of-line code. The last line of the
multi-line reply will be that line which when decoded by the
receiver begins with the initial reply code followed by a space.
For consistency with RFC 959 replies, each line of a protected
multi-line replies should begin with either a 631 or 632 code
followed by a hyphen or, on the last line, a space. However, note
that it is the format of the decoded reply, and not the enclosing
protected reply, that indicates a multi-line reply.
The following is an example showing the format of a four line
multi-line reply:
631-<base64string>
631-<base64string>
631-<base64string>
631 <base64string>
If the server for some reason cannot encode the reply, then the
unprotected reply will be sent instead. However, the client
should ignore the reply code of any cleartext reply sent after the
success of an ADAT command, and instead simply display the text of
the reply to the user.
5. Base 64 Encoding
Base 64 encoding is the same as the Printable Encoding described in
Section 4.3.2.4 of [2] and is defined as follows.
Proceeding from left to right, the bit string resulting from the
mechanism specific protection routine is encoded into characters
which are universally representable at all sites, though not
necessarily with the same bit patterns (e.g., although the character
"E" is represented in an ASCII-based system as hexadecimal 45 and as
Expires: October 31, 1994 [Page 10]
Internet-Draft FTP Security Extensions April 1994
hexadecimal C5 in an EBCDIC-based system, the local significance of
the two representations is equivalent).
A 64-character subset of International Alphabet IA5 is used, enabling
6 bits to be represented per printable character. (The proposed
subset of characters is represented identically in IA5 and ASCII.)
The character "=" signifies a special processing function used for
padding within the printable encoding procedure.
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right
across a 24-bit input group output from the authentication mechanism
specific message protection procedure, each 6-bit group is used as an
index into an array of 64 printable characters, namely "[A-Z][a-
z][0-9]+/". The character referenced by the index is placed in the
output string. These characters are selected so as to be universally
representable, and the set excludes characters with particular
significance to Telnet (e.g., "<CR>", "<LF>", IAC).
Special processing is performed if fewer than 24 bits are available
in an input group at the end of a message. A full encoding quantum
is always completed at the end of a message. When fewer than 24
input bits are available in an input group, zero bits are added (on
the right) to form an integral number of 6-bit groups. Output
character positions which are not required to represent actual input
data are set to the character "=". Since all canonically encoded
output is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character.
Implementors should keep in mind that the base 64 encodings in ADAT,
MIC, and ENC commands, and in 631 and 632 replies may be arbitrarily
long. Thus, the entire line must be read before it can be processed.
Several successive reads on the control channel may be necessary. It
is not appropriate to for a server to reject a command containing a
base 64 encoding simply because it is too long (assuming that the
decoding is otherwise well formed in the context in which it was
sent).
Case should not be ignored when reading commands and replies
containing base 64 encodings.
6. Command Summary
Expires: October 31, 1994 [Page 11]
Internet-Draft FTP Security Extensions April 1994
The following is a summary of the commands described above:
AUTH <SP> <auth-type> <CRLF>
ADAT <SP> <base64string> <CRLF>
MIC <SP> <base64string> <CRLF>
ENC <SP> <base64string> <CRLF>
PROT <SP> <protection-level> <CRLF>
PBSZ <SP> <decimal-integer> <CRLF>
The syntax of the above argument fields (using BNF notation where
applicable) is:
<auth-type> ::= <string>
<string> ::= <char> | <char><string>
<char> ::= any of the 128 ASCII characters except <CR> and <LF>
<protection-level> ::= C | S | P
<decimal-integer> ::= any decimal integer
<base64string> ::= <quads> | <quads><terminal>
<quads> ::= <quad> | <quad><quads>
<quad> ::= <base64char><base64char><base64char><base64char>
<base64char> ::= ASCII A through Z
| ASCII a through z
| ASCII 0 through 9
| ASCII +
| ASCII /
<terminal> ::= <base64char><terminal1><pad><pad>
| <base64char><base64char><terminal2><pad>
<terminal1> ::= A | Q | g | w
<terminal2> ::= A | E | I | M | Q | U | Y | c |
g | k | o | s | w | 0 | 4 | 8
<pad> ::= ASCII =
The following lists the various reply codes for each new command:
AUTH
234
334
500, 501, 503, 504, 421
ADAT
235
335
500, 501, 503, 535, 421
MIC
402
500, 501, 535, 421
ENC
402
500, 501, 535, 421
PROT
Expires: October 31, 1994 [Page 12]
Internet-Draft FTP Security Extensions April 1994
200
500, 501, 503, 504, 421, 530
PBSZ
200
500, 501, 503, 504, 421
The following are additional reply codes for existing commands (502
is the only reply for all commands except ENC and MIC once an ADAT
command succeeds):
USER
231
333
STOR
534, 535
STOU
534, 535
RETR
534, 535
LIST
534, 535
NLST
534, 535
APPE
534, 535
The following is the syntax for protected replies:
<code> <SP> <base64string> <CRLF>
<code> ::= 631 | 632
Lines of the following form may precede this in the case of a multi-
line protected reply:
<code> <hyphen> <base64string> <CRLF>
<hyphen> ::= ASCII -
7. State Diagram
Here we present state diagrams for the new AUTH and ADAT commands,
similar to the state diagrams in [1]. Only the first digit of the
reply codes is used.
In the state diagrams below we use the symbol B for "begin", and the
symbol W for "wait for reply". The state labeled "U" represents the
begin state of the diagram for the Login sequence from [1].
5 & more AUTH types
Expires: October 31, 1994 [Page 13]
Internet-Draft FTP Security Extensions April 1994
------------------------------------------------
| | 3 |
| | -------------- |
| | | | |
V | V | |
+---+ AUTH +---+ 3 +---+ ADAT +---+
| B |---------->| W |---------->| |---------->| W |
+---+ +---+ +---+ +---+
| |
|-------------------------------
| 2, 5 & no more AUTH types
V
+---+
| U |
+---+
8. References
[1] Reynolds, Joyce, and Postel, Jon, "File Transfer Protocol (FTP)",
RFC 959, ISI, October 1985.
[2] Linn, John, "Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures", RFC
1421, February 1993.
[3] Linn, John, "Generic Security Service Application Program
Interface", RFC 1508, September 1993.
[4] Braden, R., "Requirements for Internet Hosts -- Application and
Support", RFC 1123, October 1989.
[5] Borman, D., "Telnet Authentication and Encryption Option",
Internet Draft, Cray Research, Inc, April 1993.
Security Considerations
Third party file transfers cannot be secured using these extensions,
since a security context cannot be established between two servers
using these facilities (no control connection exists between servers
over which to pass ADAT tokens). Further work in this area is
deferred.
Acknowledgements
I would like to thank the members of the CAT WG, as well as all
participants in discussions on the "cat-ietf@mit.edu" mailing list,
for their contributions to this document. I would especially like to
thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut,
Derrick Brashear, and John Gardiner Myers for their contributions to
this work.
Expires: October 31, 1994 [Page 14]
Internet-Draft FTP Security Extensions April 1994
APPENDIX I: SPECIFICATION UNDER KERBEROS VERSION 4
The authentication type (for the AUTH command) associated with
Kerberos Version 4 is KERBEROS_V4. If the server supports
KERBEROS_V4, it will respond with a 334 reply code indicating that an
ADAT command is expected next.
The client should retrieve a ticket for the Kerberos principal
"ftp.hostname@realm" by calling krb_mk_req(3) with a principal name
of "ftp", an instance equal to the canonical host name of the server
with all letters in lower case (as returned by krb_get_phost(3)), the
server's realm name (as returned by krb_realmofhost(3)), and an
arbitrary checksum. The ticket must then be base 64 encoded and sent
as the argument to an ADAT command.
If the "ftp" principal name is not a registered principal in the
Kerberos database, then the client may fall back on the "rcmd"
principal name (same instance and realm). However, servers must
accept only one or the other of these principal names, and must not
be willing to accept either. Generally, if the server has a key for
the "ftp" principal in its srvtab, then that principal only should be
used, otherwise the "rcmd" principal only should be used.
The server must base 64 decode the argument to the ADAT command and
pass the result to krb_rd_req(3). The server must add one to the
checksum from the authenticator, convert the result to network byte
order (most significant byte first), and sign it using
krb_mk_safe(3), and base 64 encode the result. Upon success, the
server must reply to the client with a 235 code and include
"ADAT=base64string" in the text of the reply. Upon failure, the
server will reply 535.
Upon receipt of the 235 reply from the server, the client must parse
the text of the reply for the base 64 encoded data, decode it,
convert it from network byte order, and pass the result to
krb_rd_safe(3). The client should consider the server authenticated
if the resultant checksum is equal to one plus the value previously
sent.
The procedure associated with integrity protected MIC commands,
replies, and Safe file transfers is:
krb_mk_safe(3) for the sender
krb_rd_safe(3) for the receiver
The procedure associated with privacy protected ENC commands,
replies, and Private file transfers is:
krb_mk_priv(3) for the sender
krb_rd_priv(3) for the receiver
Expires: October 31, 1994 [Page 15]
Internet-Draft FTP Security Extensions April 1994
Note that this specification for KERBEROS_V4 contains no provision
for negotiating alternate means for integrity and confidentiality
routines. Note also that the ADAT exchange does not convey whether
the peer supports confidentiality services.
In order to stay within the allowed PBSZ, implementors should take
note that a cleartext buffer will grow by 31 bytes when processed by
krb_mk_safe(3) and will grow by 26 bytes when processed by
krb_mk_priv(3).
APPENDIX II: SPECIFICATION UNDER THE GSSAPI
The authentication type (for the AUTH command) associated with all
mechanisms employing the GSSAPI is GSSAPI. If the server supports an
authentication mechanism employing the GSSAPI, it will respond with a
334 reply code indicating that an ADAT command is expected next.
The client should begin the authentication exchange by calling
GSS_Init_Sec_Context, passing in 0 for input_context_handle
(initially), and a targ_name equal to output_name from
GSS_Import_Name called with input_name_type of NULL and
input_name_string of "SERVICE:ftp@hostname" where "hostname" is the
fully qualified host name of the server with all letters in lower
case. (Failing this, the client may try again using
input_name_string of "SERVICE:host@hostname".) The output_token must
then be base 64 encoded and sent to the server as the argument to an
ADAT command. If GSS_Init_Sec_Context returns GSS_CONTINUE_NEEDED,
then the client should expect a token to be returned in the reply to
the ADAT command. This token should subsequently be passed to
another call to GSS_Init_Sec_Context. In this case, if
GSS_Init_Sec_Context returns no output_token, then the reply code
from the server for the previous ADAT command should have been 235.
If GSS_Init_Sec_Context returns GSS_COMPLETE, then no further tokens
should be expected from the server, and the client should consider
the server authenticated.
The server must base 64 decode the argument to the ADAT command and
pass the resultant token to GSS_Accept_Sec_Context as input_token,
setting acceptor_cred_handle to NULL (for "use default credentials"),
and 0 for input_context_handle (initially). If an output_token is
returned, it should be base 64 encoded and returned to the client by
including "ADAT=base64string" in the text of the reply. If
GSS_Accept_Sec_Context returns GSS_COMPLETE, the reply code should be
235, and the server should consider the client authenticated. If
GSS_Accept_Sec_Context returns GSS_CONTINUE_NEEDED, the reply code
should be 335. Otherwise, the reply code should be 535, and the text
of the reply should contain a descriptive error message.
The procedure associated with integrity protected MIC commands,
replies, and Safe file transfers is:
Expires: October 31, 1994 [Page 16]
Internet-Draft FTP Security Extensions April 1994
GSS_Seal for the sender, with conf_flag == FALSE
GSS_Unseal for the receiver
The procedure associated with privacy protected ENC commands,
replies, and Private file transfers is:
GSS_Seal for the sender, with conf_flag == TRUE
GSS_Unseal for the receiver
Both the client and server should inspect the value of conf_avail to
determine whether the peer supports confidentiality services.
Author's Address:
Steven J. Lunt
Bellcore
RRC-1L213
444 Hoes Lane
Piscataway, NJ 08854
Phone: (908) 699-4244
E-Mail: lunt@bellcore.com
Mailing List: cat-ietf@mit.edu
Chair's Address:
The working group can be contacted via the current chair:
Sam Sjogren
TGV, Inc.
101 Cooper St.
Santa Cruz, CA 95060-4526
Phone: (408) 457-5380
E-Mail: sjogren@tgv.com
Expires: October 31, 1994 [Page 17]
