As per Relevance of the word extensions, we have this rfc below:
Network Working Group M.
Request for Comments: 2228 Cygnus
Updates: 959 S.
Category: Standards Track
October 1997
FTP Security
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This document defines extensions to the FTP specification STD 9,
959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These
provide strong authentication, integrity, and confidentiality on
the control and data channels with the introduction of new
commands, replies, and file transfer encodings
The following new optional commands are introduced in
specification
AUTH (Authentication/Security Mechanism),
ADAT (Authentication/Security Data),
PROT (Data Channel Protection Level),
PBSZ (Protection Buffer Size),
CCC (Clear Command Channel),
MIC (Integrity Protected Command),
CONF (Confidentiality Protected Command),
ENC (Privacy Protected Command).
A new class of reply types (6yz) is also introduced for
replies
None of the above commands are required to be implemented,
interdependencies exist. These dependencies are documented with
commands
Note that this specification is compatible with STD 9, RFC 959.
Horowitz & Lunt Standards Track [Page 1]
RFC 2228 FTP Security Extensions October 1997
1.
The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959
and in place on the Internet uses usernames and passwords passed
cleartext to authenticate clients to servers (via the USER and
commands). Except for services such as "anonymous" FTP archives
this represents a security risk whereby passwords can be
through monitoring of local and wide-area networks. This either
potential attackers through password exposure and/or
accessibility of files by FTP servers who cannot or will not
the inherent security risks
Aside from the problem of authenticating users in a secure manner
there is also the problem of authenticating servers,
sensitive data and/or verifying its integrity. An attacker may
able to access valuable or sensitive data merely by monitoring
network, or through active means may be able to delete or modify
data being transferred so as to corrupt its integrity. An
attacker may also initiate spurious file transfers to and from a
of the attacker's choice, and may invoke other commands on
server. FTP does not currently have any provision for the
or verification of the authenticity of commands, replies,
transferred data. Note that these security services have value
to anonymous file access
Current practice for sending files securely is generally either
1. via FTP of files pre-encrypted under keys which are
distributed
2. via electronic mail containing an encoding of a file
under keys which are manually distributed
3. via a PEM message,
4. via the rcp command enhanced to use Kerberos
None of these means could be considered even a de facto standard,
none are truly interactive. A need exists to securely transfer
using FTP in a secure manner which is supported within the
protocol in a consistent manner and which takes advantage of
security infrastructure and technology. Extensions are necessary
the FTP specification if these security services are to be
into the protocol in an interoperable way
Horowitz & Lunt Standards Track [Page 2]
RFC 2228 FTP Security Extensions October 1997
Although the FTP control connection follows the Telnet protocol,
Telnet has defined an authentication and encryption option [TELNET
SEC], [RFC-1123] explicitly forbids the use of Telnet
negotiation over the control connection (other than Synch and IP).
Also, the Telnet authentication and encryption option does
provide for integrity protection only (without confidentiality),
does not address the protection of the data channel
2. FTP Security
At the highest level, the FTP security extensions seek to provide
abstract mechanism for authenticating and/or authorizing connections
and integrity and/or confidentiality protecting commands, replies
and data transfers
In the context of FTP security, authentication is the
of a client's identity and/or a server's identity in a secure way
usually using cryptographic techniques. The basic FTP protocol
not have a concept of authentication
Authorization is the process of validating a user for login.
basic authorization process involves the USER, PASS, and
commands. With the FTP security extensions,
established using a security mechanism may also be used to make
authorization decision
Without the security extensions, authentication of the client,
this term is usually understood, never happens. FTP authorization
accomplished with a password, passed on the network in the clear
the argument to the PASS command. The possessor of this password
assumed to be authorized to transfer files as the user named in
USER command, but the identity of the client is never
established
An FTP security interaction begins with a client telling the
what security mechanism it wants to use with the AUTH command.
server will either accept this mechanism, reject this mechanism, or
in the case of a server which does not implement the
extensions, reject the command completely. The client may
multiple security mechanisms until it requests one which the
accepts. This allows a rudimentary form of negotiation to
place. (If more complex negotiation is desired, this may
implemented as a security mechanism.) The server's reply
indicate if the client must respond with additional data for
Horowitz & Lunt Standards Track [Page 3]
RFC 2228 FTP Security Extensions October 1997
security mechanism to interpret. If none is needed, this
usually mean that the mechanism is one where the password (
by the PASS command) is to be interpreted differently, such as with
token or one-time password system
If the server requires additional security information, then
client and server will enter into a security data exchange.
client will send an ADAT command containing the first block
security data. The server's reply will indicate if the data
is complete, if there was an error, or if more data is needed.
server's reply can optionally contain security data for the client
interpret. If more data is needed, the client will send another
command containing the next block of data, and await the server'
reply. This exchange can continue as many times as necessary.
this exchange completes, the client and server have established
security association. This security association may
authentication (client, server, or mutual) and keying information
integrity and/or confidentiality, depending on the mechanism in use
The term "security data" here is carefully chosen. The purpose
the security data exchange is to establish a security association
which might not actually include any authentication at all,
the client and the server as described above. For instance,
Diffie-Hellman exchange establishes a secret key, but
authentication takes place. If an FTP server has an RSA key pair
the client does not, then the client can authenticate the server,
the server cannot authenticate the client
Once a security association is established, authentication which is
part of this association may be used instead of or in addition to
standard username/password exchange for authorizing a user to
to the server. A username specified by the USER command is
required to specify the identity to be used on the server
In order to prevent an attacker from inserting or deleting
on the control stream, if the security association
integrity, then the server and client must use integrity
on the control stream, unless it first transmits a CCC command
turn off this requirement. Integrity protection is performed
the MIC and ENC commands, and the 63z reply codes. The CCC
and its reply must be transmitted with integrity protection
Commands and replies may be transmitted without integrity (that is
in the clear or with confidentiality only) only if no
association is established, the negotiated security association
not support integrity, or the CCC command has succeeded
Horowitz & Lunt Standards Track [Page 4]
RFC 2228 FTP Security Extensions October 1997
Once the client and server have negotiated with the PBSZ command
acceptable buffer size for encapsulating protected data over the
channel, the security mechanism may also be used to protect
channel transfers
Policy is not specified by this document. In particular, client
server implementations may choose to implement restrictions on
operations can be performed depending on the security
which exists. For example, a server may require that a
authorize via a security mechanism rather than using a password
require that the client provide a one-time password from a token
require at least integrity protection on the command channel,
require that certain files only be transmitted encrypted.
anonymous ftp client might refuse to do file transfers
integrity protection in order to insure the validity of
downloaded
No particular set of functionality is required, except
dependencies described in the next section. This means that none
authentication, integrity, or confidentiality are required of
implementation, although a mechanism which does none of these is
of much use. For example, it is acceptable for a mechanism
implement only integrity protection, one-way authentication and/
encryption, encryption without any authentication or
protection, or any other subset of functionality if policy
technical considerations make this desirable. Of course, one
might require as a matter of policy stronger protection than
other is able to provide, preventing perfect interoperability
3. New FTP
The following commands are optional, but dependent on each other
They are extensions to the FTP Access Control Commands
The reply codes documented here are generally described
recommended, rather than required. The intent is that reply
describing the full range of success and failure modes exist,
that servers be allowed to limit information presented to the client
For example, a server might implement a particular
mechanism, but have a policy restriction against using it.
server should respond with a 534 reply code in this case, but
respond with a 504 reply code if it does not wish to divulge that
disallowed mechanism is supported. If the server does choose to
a different reply code than the recommended one, it should try to
a reply code which only differs in the last digit. In all cases,
server must use a reply code which is documented as returnable
the command received, and this reply code must begin with the
digit as the recommended reply code for the situation
Horowitz & Lunt Standards Track [Page 5]
RFC 2228 FTP Security Extensions October 1997
AUTHENTICATION/SECURITY MECHANISM (AUTH
The argument field is a Telnet string identifying a
mechanism. This string is case-insensitive. Values must
registered with the IANA, except that values beginning with "X-"
are reserved for local use
If the server does not recognize the AUTH command, it must
with reply code 500. This is intended to encompass the
deployed base of non-security-aware ftp servers, which
respond with reply code 500 to any unrecognized command. If
server does recognize the AUTH command but does not implement
security extensions, it should respond with reply code 502.
If the server does not understand the named security mechanism,
should respond with reply code 504.
If the server is not willing to accept the named
mechanism, it should respond with reply code 534.
If the server is not able to accept the named security mechanism
such as if a required resource is unavailable, it should
with reply code 431.
If the server is willing to accept the named security mechanism
but requires security data, it must respond with reply code 334.
If the server is willing to accept the named security mechanism
and does not require any security data, it must respond with
code 234.
If the server is responding with a 334 reply code, it may
security data as described in the next section
Some servers will allow the AUTH command to be reissued in
to establish new authentication. The AUTH command, if accepted
removes any state associated with prior FTP Security commands
The server must also require that the user reauthorize (that is
reissue some or all of the USER, PASS, and ACCT commands) in
case (see section 4 for an explanation of "authorize" in
context).
Horowitz & Lunt Standards Track [Page 6]
RFC 2228 FTP Security Extensions October 1997
AUTHENTICATION/SECURITY DATA (ADAT
The argument field is a Telnet string representing base 64
security data (see Section 9, "Base 64 Encoding"). If a
code indicating success is returned, the server may also use
string of the form "ADAT=base64data" as the text part of the
if it wishes to convey security data back to the client
The data in both cases is specific to the security
specified by the previous AUTH command. The ADAT command, and
associated replies, allow the client and server to conduct
arbitrary security protocol. The security data exchange
include enough information for both peers to be aware of
optional features are available. For example, if the client
not support data encryption, the server must be made aware
this, so it will know not to send encrypted command
replies. It is strongly recommended that the security
provide sequencing on the command channel, to insure that
are not deleted, reordered, or replayed
The ADAT command must be preceded by a successful AUTH command
and cannot be issued once a security data exchange
(successfully or unsuccessfully), unless it is preceded by an
command to reset the security state
If the server has not yet received an AUTH command, or if a
security data exchange completed, but the security state has
been reset with an AUTH command, it should respond with reply
503.
If the server cannot base 64 decode the argument, it
respond with reply code 501.
If the server rejects the security data (if a checksum fails,
instance), it should respond with reply code 535.
If the server accepts the security data, and requires
data, it should respond with reply code 335.
If the server accepts the security data, but does not require
additional data (i.e., the security data exchange has
successfully), it must respond with reply code 235.
If the server is responding with a 235 or 335 reply code, then
may include security data in the text part of the reply
specified above
Horowitz & Lunt Standards Track [Page 7]
RFC 2228 FTP Security Extensions October 1997
If the ADAT command returns an error, the security data
will fail, and the client must reset its internal security state
If the client becomes unsynchronized with the server (for example
the server sends a 234 reply code to an AUTH command, but
client has more data to transmit), then the client must reset
server's security state
PROTECTION BUFFER SIZE (PBSZ
The argument is a decimal integer representing the maximum size
in bytes, of the encoded data blocks to be sent or received
file transfer. This number shall be no greater than can
represented in a 32-bit unsigned integer
This command allows the FTP client and server to negotiate
maximum protected buffer size for the connection. There is
default size; the client must issue a PBSZ command before it
issue the first PROT command
The PBSZ command must be preceded by a successful security
exchange
If the server cannot parse the argument, or if it will not fit
32 bits, it should respond with a 501 reply code
If the server has not completed a security data exchange with
client, it should respond with a 503 reply code
Otherwise, the server must reply with a 200 reply code. If
size provided by the client is too large for the server, it
use a string of the form "PBSZ=number" in the text part of
reply to indicate a smaller buffer size. The client and
server must use the smaller of the two buffer sizes if both
sizes are specified
DATA CHANNEL PROTECTION LEVEL (PROT
The argument is a single Telnet character code specifying the
channel protection level
This command indicates to the server what type of data
protection the client and server will be using. The
codes are assigned
C -
S -
E -
P -
Horowitz & Lunt Standards Track [Page 8]
RFC 2228 FTP Security Extensions October 1997
The default protection level if no other level is specified
Clear. The Clear protection level indicates that the data
will carry the raw data of the file transfer, with no
applied. The Safe protection level indicates that the data
be integrity protected. The Confidential protection
indicates that the data will be confidentiality protected.
Private protection level indicates that the data will be
and confidentiality protected
It is reasonable for a security mechanism not to provide all
channel protection levels. It is also reasonable for a
to provide more protection at a level than is required (
instance, a mechanism might provide Confidential protection,
include integrity-protection in that encoding, due to API or
considerations).
The PROT command must be preceded by a successful
buffer size negotiation
If the server does not understand the specified protection level
it should respond with reply code 504.
If the current security mechanism does not support the
protection level, the server should respond with reply code 536.
If the server has not completed a protection buffer
negotiation with the client, it should respond with a 503
code
The PROT command will be rejected and the server should reply 503
if no previous PBSZ command was issued
If the server is not willing to accept the specified
level, it should respond with reply code 534.
If the server is not able to accept the specified
level, such as if a required resource is unavailable, it
respond with reply code 431.
Otherwise, the server must reply with a 200 reply code to
that the specified protection level is accepted
CLEAR COMMAND CHANNEL (CCC
This command does not take an argument
Horowitz & Lunt Standards Track [Page 9]
RFC 2228 FTP Security Extensions October 1997
It is desirable in some environments to use a security
to authenticate and/or authorize the client and server, but not
perform any integrity checking on the subsequent commands.
might be used in an environment where IP security is in place
insuring that the hosts are authenticated and that TCP
cannot be tampered, but where user authentication is desired
If unprotected commands are allowed on any connection, then
attacker could insert a command on the control stream, and
server would have no way to know that it was invalid. In order
prevent such attacks, once a security data exchange
successfully, if the security mechanism supports integrity,
integrity (via the MIC or ENC command, and 631 or 632 reply)
be used, until the CCC command is issued to enable non-
protected control channel messages. The CCC command itself
be integrity protected
Once the CCC command completes successfully, if a command is
protected, then the reply to that command must also not
protected. This is to support interoperability with clients
do not support protection once the CCC command has been issued
This command must be preceded by a successful security
exchange
If the command is not integrity-protected, the server must
with a 533 reply code
If the server is not willing to turn off the
requirement, it should respond with a 534 reply code
Otherwise, the server must reply with a 200 reply code to
that unprotected commands and replies may now be used on
command channel
INTEGRITY PROTECTED COMMAND (MIC)
CONFIDENTIALITY PROTECTED COMMAND (CONF)
PRIVACY PROTECTED COMMAND (ENC
The argument field of MIC is a Telnet string consisting of a
64 encoded "safe" message produced by a security
specific message integrity procedure. The argument field of
is a Telnet string consisting of a base 64 encoded "confidential
message produced by a security mechanism specific
procedure. The argument field of ENC is a Telnet
consisting of a base 64 encoded "private" message produced by
security mechanism specific message integrity and
procedure
Horowitz & Lunt Standards Track [Page 10]
RFC 2228 FTP Security Extensions October 1997
The server will decode and/or verify the encoded message
This command must be preceded by a successful security
exchange
A server may require that the first command after a
security data exchange be CCC, and not implement the
commands at all. In this case, the server should respond with
502 reply code
If the server cannot base 64 decode the argument, it
respond with a 501 reply code
If the server has not completed a security data exchange with
client, it should respond with a 503 reply code
If the server has completed a security data exchange with
client using a mechanism which supports integrity, and requires
CCC command due to policy or implementation limitations, it
respond with a 503 reply code
If the server rejects the command because it is not supported
the current security mechanism, the server should respond
reply code 537.
If the server rejects the command (if a checksum fails,
instance), it should respond with reply code 535.
If the server is not willing to accept the command (if privacy
required by policy, for instance, or if a CONF command is
before a CCC command), it should respond with reply code 533.
Otherwise, the command will be interpreted as an FTP command.
end-of-line code need not be included, but if one is included,
must be a Telnet end-of-line code, not a local end-of-line code
The server may require that, under some or all circumstances,
commands be protected. In this case, it should make a 533
to commands other than MIC, CONF, and ENC
4. Login
The security data exchange may, among other things, establish
identity of the client in a secure way to the server. This
may be used as one input to the login authorization process
Horowitz & Lunt Standards Track [Page 11]
RFC 2228 FTP Security Extensions October 1997
In response to the FTP login commands (AUTH, PASS, ACCT), the
may choose to change the sequence of commands and replies
by RFC 959 as follows. There are also some new replies available
If the server is willing to allow the user named by the USER
to log in based on the identity established by the security
exchange, it should respond with reply code 232.
If the security mechanism requires a challenge/response password,
should respond to the USER command with reply code 336. The
part of the reply should contain the challenge. The client
display the challenge to the user before prompting for the
in this case. This is particularly relevant to more
clients or graphical user interfaces which provide dialog boxes
other modal input. These clients should be careful not to prompt
the password before the username has been sent to the server, in
the user needs the challenge in the 336 reply to construct a
password
5. New FTP
The new reply codes are divided into two classes. The first class
new replies made necessary by the new FTP Security commands.
second class is a new reply type to indicate protected replies
5.1. New individual reply
232 User logged in, authorized by security data exchange
234 Security data exchange complete
235 [ADAT=base64data
; This reply indicates that the security data
; completed successfully. The square brackets are
; to be included in the reply, but indicate
; security data in the reply is optional
334 [ADAT=base64data
; This reply indicates that the requested security
; is ok, and includes security data to be used by the
; to construct the next command. The square brackets are
; to be included in the reply, but indicate
; security data in the reply is optional
335 [ADAT=base64data
; This reply indicates that the security data
; acceptable, and more is required to complete
; security data exchange. The square
; are not to be included in the reply, but
; that security data in the reply is optional
Horowitz & Lunt Standards Track [Page 12]
RFC 2228 FTP Security Extensions October 1997
336 Username okay, need password. Challenge is "...."
; The exact representation of the challenge should be
; by the mechanism to be sensible to the human user of
; system
431 Need some unavailable resource to process security
533 Command protection level denied for policy reasons
534 Request denied for policy reasons
535 Failed security check (hash, sequence, etc).
536 Requested PROT level not supported by mechanism
537 Command protection level not supported by security mechanism
5.2. Protected replies
One new reply type is introduced
6yz Protected
There are three reply codes of this type. The first,
code 631 indicates an integrity protected reply.
second, reply code 632, indicates a confidentiality
integrity protected reply. the third, reply code 633,
indicates a confidentiality protected reply
The text part of a 631 reply is a Telnet string
of a base 64 encoded "safe" message produced by a
mechanism specific message integrity procedure. The
part of a 632 reply is a Telnet string consisting of a
64 encoded "private" message produced by a
mechanism specific message confidentiality and
procedure. The text part of a 633 reply is a Telnet
consisting of a base 64 encoded "confidential"
produced by a security mechanism specific
confidentiality procedure
The client will decode and verify the encoded reply.
failures decoding or verifying replies are handled
implementation-specific. An end-of-line code need not
included, but if one is included, it must be a Telnet end
of-line code, not a local end-of-line code
A protected reply may only be sent if a security
exchange has succeeded
The 63z reply may be a multiline reply. In this case,
plaintext reply must be broken up into a number
fragments. Each fragment must be protected, then base 64
Horowitz & Lunt Standards Track [Page 13]
RFC 2228 FTP Security Extensions October 1997
encoded in order into a separate line of the
reply. There need not be any correspondence between
line breaks in the plaintext reply and the encoded reply
Telnet end-of-line codes must appear in the plaintext of
encoded reply, except for the final end-of-line code,
is optional
The multiline reply must be formatted more strictly than
continuation specification in RFC 959. In particular,
line before the last must be formed by the reply code
followed immediately by a hyphen, followed by a base 64
encoded fragment of the reply
For example, if the plaintext reply
123-First
Second
234 A line beginning with
123 The last
then the resulting protected reply could be any of
following (the first example has a line break only to
within the margins):
631 base64(protect("123-First line\r\nSecond line\r\n 234 A
631-base64(protect("123-First line\r\n"))
631-base64(protect("Second line\r\n"))
631-base64(protect(" 234 A line beginning with numbers\r\n"))
631 base64(protect("123 The last line"))
631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b"))
631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))
6. Data Channel
When data transfers are protected between the client and server (
either direction), certain transformations and encapsulations must
performed so that the recipient can properly decode the
file
The sender must apply all protection services after
associated with the representation type, file structure, and
mode have been performed. The data sent over the data channel is
for the purposes of protection, to be treated as a byte stream
When performing a data transfer in an authenticated manner,
authentication checks are performed on individual blocks of the file
rather than on the file as a whole. Consequently, it is possible
Horowitz & Lunt Standards Track [Page 14]
RFC 2228 FTP Security Extensions October 1997
insertion attacks to insert blocks into the data stream (i.e.,
replays) that authenticate correctly, but result in a corrupted
being undetected by the receiver. To guard against such attacks,
specific security mechanism employed should include mechanisms
protect against such attacks. Many GSS-API mechanisms usable
the specification in Appendix I, and the Kerberos mechanism
Appendix II do so
The sender must take the input byte stream, and break it up
blocks such that each block, when encoded using a security
specific procedure, will be no larger than the buffer size
by the client with the PBSZ command. Each block must be encoded
then transmitted with the length of the encoded block prepended as
four byte unsigned integer, most significant byte first
When the end of the file is reached, the sender must encode a
of zero bytes, and send this final block to the recipient
closing the data connection
The recipient will read the four byte length, read a block of
that many bytes long, then decode and verify this block with
security mechanism specific procedure. This must be repeated until
block encoding a buffer of zero bytes is received. This
the end of the encoded byte stream
Any transformations associated with the representation type,
structure, and transfer mode are to be performed by the recipient
the byte stream resulting from the above process
When using block transfer mode, the sender's (cleartext) buffer
is independent of the block size
The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or
command if the current protection level is not at the level
by the server's security requirements for the particular
transfer
If any data protection services fail at any time during data
at the server end (including an attempt to send a buffer size
than the negotiated maximum), the server will send a 535 reply to
data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE).
Horowitz & Lunt Standards Track [Page 15]
RFC 2228 FTP Security Extensions October 1997
7. Potential policy
While there are no restrictions on client and server policy,
are a few recommendations which an implementation should implement
- Once a security data exchange takes place, a server should
all commands be protected (with integrity and/or confidentiality),
and it should protect all replies. Replies should use the
level of protection as the command which produced them.
includes replies which indicate failure of the MIC, CONF, and
commands. In particular, it is not meaningful to require
AUTH and ADAT be protected; it is meaningful and useful to
that PROT and PBSZ be protected. In particular, the use of CCC
not recommended, but is defined in the interest
interoperability between implementations which might desire
functionality
- A client should encrypt the PASS command whenever possible. It
reasonable for the server to refuse to accept a non-encrypted
command if the server knows encryption is available
- Although no security commands are required to be implemented,
is recommended that an implementation provide all commands
can be implemented, given the mechanisms supported and the
considerations of the site (export controls, for instance).
8. Declarative
These sections are modelled after sections 5.3 and 5.4 of RFC 959,
which describe the same information, except for the standard
commands and replies
8.1. FTP Security commands and
AUTH <mechanism-name>
ADAT
PROT
PBSZ
MIC
CONF
ENC
<mechanism-name> ::=
::=
; must be formatted as described in section 9
::= C | S | E |
::= any decimal integer from 1 to (2^32)-1
Horowitz & Lunt Standards Track [Page 16]
RFC 2228 FTP Security Extensions October 1997
8.2. Command-Reply
Security Association
234
334
502, 504, 534, 431
500, 501, 421
235
335
503, 501, 535
500, 501, 421
Data protection negotiation
200
503
500, 501, 421, 530
200
504, 536, 503, 534, 431
500, 501, 421, 530
Command channel protection
535, 533
500, 501, 421
535, 533
500, 501, 421
535, 533
500, 501, 421
Security-Enhanced login commands (only new replies listed
232
336
Data channel commands (only new replies listed
534, 535
534, 535
534, 535
Horowitz & Lunt Standards Track [Page 17]
RFC 2228 FTP Security Extensions October 1997
534, 535
534, 535
534, 535
In addition to these reply codes, any security command can
500, 501, 502, 533, or 421. Any ftp command can return a
code encapsulated in a 631, 632, or 633 reply once a security
exchange has completed successfully
Horowitz & Lunt Standards Track [Page 18]
RFC 2228 FTP Security Extensions October 1997
9. State
This section includes a state diagram which demonstrates the flow
authentication and authorization in a security enhanced
implementation. The rectangular blocks show states where the
must issue a command, and the diamond blocks show states where
server must issue a response
,------------------,
__\| Unauthenticated |_________\
| /| (new connection) | /|
| `------------------' |
| | |
| | AUTH |
| V |
| / \ |
| 4yz,5yz / \ 234 |
|<--------< >------------->. |
| \ / | |
| \_/ | |
| | | |
| | 334 | |
| V | |
| ,--------------------, | |
| | Need Security Data |<--. | |
| `--------------------' | | |
| | | | |
| | ADAT | | |
| V | | |
| / \ | | |
| 4yz,5yz / \ 335 | | |
`<--------< >-----------' | |
\ / | |
\_/ | |
| | |
| 235 | |
V | |
,---------------. | |
,--->| Authenticated |<--------' | After the client and
| `---------------' | have completed authenti
| | | cation, command must
| | USER | integrity-protected
| | | integrity is available.
| |<-------------------' CCC command may be issued
| V relax this restriction
Horowitz & Lunt Standards Track [Page 19]
RFC 2228 FTP Security Extensions October 1997
| / \
| 4yz,5yz / \ 2
|<--------< >------------->.
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,---------------. |
| | Need Password | |
| `---------------' |
| | |
| | PASS |
| V |
| / \ |
| 4yz,5yz / \ 2yz |
|<--------< >------------->|
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,--------------. |
| | Need Account | |
| `--------------' |
| | |
| | ACCT |
| V |
| / \ |
| 4yz,5yz / \ 2yz |
`<--------< >------------->|
\ / |
\_/ |
| |
| 3yz |
V |
,-------------. |
| Authorized |/________|
| (Logged in) |\
`-------------'
Horowitz & Lunt Standards Track [Page 20]
RFC 2228 FTP Security Extensions October 1997
10. Base 64
Base 64 encoding is the same as the Printable Encoding described
Section 4.3.2.4 of [RFC-1421], except that line breaks must not
included. This encoding is defined as follows
Proceeding from left to right, the bit string resulting from
mechanism specific protection routine is encoded into
which are universally representable at all sites, though
necessarily with the same bit patterns (e.g., although the
"E" is represented in an ASCII-based system as hexadecimal 45 and
hexadecimal C5 in an EBCDIC-based system, the local significance
the two representations is equivalent).
A 64-character subset of International Alphabet IA5 is used,
6 bits to be represented per printable character. (The
subset of characters is represented identically in IA5 and ASCII.)
The character "=" signifies a special processing function used
padding within the printable encoding procedure
The encoding process represents 24-bit groups of input bits as
strings of 4 encoded characters. Proceeding from left to
across a 24-bit input group output from the security
specific message protection procedure, each 6-bit group is used as
index into an array of 64 printable characters, namely "[A-Z][a
z][0-9]+/". The character referenced by the index is placed in
output string. These characters are selected so as to be
representable, and the set excludes characters with
significance to Telnet (e.g., "", "", IAC).
Special processing is performed if fewer than 24 bits are
in an input group at the end of a message. A full encoding
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 (
the right) to form an integral number of 6-bit groups.
character positions which are not required to represent actual
data are set to the character "=". Since all canonically
output is an integral number of octets, only the following cases
arise: (1) the final quantum of encoding input is an
multiple of 24 bits; here, the final unit of encoded output will
an integral multiple of 4 characters with no "=" padding, (2)
final quantum of encoding input is exactly 8 bits; here, the
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input
exactly 16 bits; here, the final unit of encoded output will be
characters followed by one "=" padding character
Horowitz & Lunt Standards Track [Page 21]
RFC 2228 FTP Security Extensions October 1997
Implementors must keep in mind that the base 64 encodings in ADAT
MIC, CONF, and ENC commands, and in 63z replies may be
long. Thus, the entire line must be read before it can be processed
Several successive reads on the control channel may be necessary.
is not appropriate to for a server to reject a command containing
base 64 encoding simply because it is too long (assuming that
decoding is otherwise well formed in the context in which it
sent).
Case must not be ignored when reading commands and replies
base 64 encodings
11. Security
This entire document deals with security considerations related
the File Transfer Protocol
Third party file transfers cannot be secured using these extensions
since a security context cannot be established between two
using these facilities (no control connection exists between
over which to pass ADAT tokens). Further work in this area
deferred
12.
I would like to thank the members of the CAT WG, as well as
participants in discussions on the "cat-ietf@mit.edu" mailing list
for their contributions to this document. I would especially like
thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut
Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Karri
for their contributions to this work. Of course, without Steve Lunt
the author of the first six revisions of this document, it would
exist at all
13.
[TELNET-SEC] Borman, D., "Telnet Authentication and
Option", Work in Progress
[RFC-1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC-1421] Linn, J., "Privacy Enhancement for Internet
Mail: Part I: Message Encryption and Authentication Procedures",
RFC 1421, February 1993.
Horowitz & Lunt Standards Track [Page 22]
RFC 2228 FTP Security Extensions October 1997
14. Author's
Marc
Cygnus
955 Massachusetts
Cambridge, MA 02139
Phone: +1 617 354 7688
EMail: marc@cygnus.
Horowitz & Lunt Standards Track [Page 23]
RFC 2228 FTP Security Extensions October 1997
Appendix I: Specification under the
In order to maximise the utility of new security mechanisms, it
desirable that new mechanisms be implemented as GSSAPI
rather than as FTP security mechanisms. This will enable
ftp implementations to support the new mechanisms more easily,
little or no code will need to be changed. In addition,
mechanism will be usable by other protocols, such as IMAP, which
built on top of the GSSAPI, with no additional specification
implementation work needed by the mechanism designers
The security mechanism name (for the AUTH command) associated
all mechanisms employing the GSSAPI is GSSAPI. If the
supports a security mechanism employing the GSSAPI, it must
with a 334 reply code indicating that an ADAT command is
next
The client must begin the authentication exchange by
GSS_Init_Sec_Context, passing in 0 for input_context_
(initially), and a targ_name equal to output_name
GSS_Import_Name called with input_name_type of Host-Based Service
input_name_string of "ftp@hostname" where "hostname" is the
qualified host name of the server with all letters in lower case
(Failing this, the client may try again using input_name_string
"host@hostname".) The output_token must then be base 64 encoded
sent to the server as the argument to an ADAT command.
GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the
must expect a token to be returned in the reply to the ADAT command
This token must subsequently be passed to another call
GSS_Init_Sec_Context. In this case, if GSS_Init_Sec_Context
no output_token, then the reply code from the server for the
ADAT command must have been 235. If GSS_Init_Sec_Context
GSS_S_COMPLETE, then no further tokens are expected from the server
and the client must consider the server authenticated
The server must base 64 decode the argument to the ADAT command
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
returned, it must be base 64 encoded and returned to the client
including "ADAT=base64string" in the text of the reply.
GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must
235, and the server must consider the client authenticated.
GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply
must be 335. Otherwise, the reply code should be 535, and the
of the reply should contain a descriptive error message
Horowitz & Lunt Standards Track [Page 24]
RFC 2228 FTP Security Extensions October 1997
The chan_bindings input to GSS_Init_Sec_Context
GSS_Accept_Sec_Context should use the client internet address
server internet address as the initiator and acceptor addresses
respectively. The address type for both should be GSS_C_AF_INET.
application data should be specified
Since GSSAPI supports anonymous peers to security contexts, it
possible that the client's authentication of the server does
actually establish an identity
The procedure associated with MIC commands, 631 replies, and
file transfers is
GSS_Wrap for the sender, with conf_flag ==
GSS_Unwrap for the
The procedure associated with ENC commands, 632 replies, and
file transfers is
GSS_Wrap for the sender, with conf_flag ==
GSS_Unwrap for the
CONF commands and 633 replies are not supported
Both the client and server should inspect the value of conf_avail
determine whether the peer supports confidentiality services
When the security state is reset (when AUTH is received a
time, or when REIN is received), this should be done by calling
GSS_Delete_sec_context function
Appendix II: Specification under Kerberos version 4
The security mechanism name (for the AUTH command) associated
Kerberos Version 4 is KERBEROS_V4. If the server
KERBEROS_V4, it must respond with a 334 reply code indicating that
ADAT command is expected next
The client must retrieve a ticket for the Kerberos
"ftp.hostname@realm" by calling krb_mk_req(3) with a principal
of "ftp", an instance equal to the first part of the canonical
name of the server with all letters in lower case (as returned
krb_get_phost(3)), the server's realm name (as returned
krb_realmofhost(3)), and an arbitrary checksum. The ticket must
be base 64 encoded and sent as the argument to an ADAT command
Horowitz & Lunt Standards Track [Page 25]
RFC 2228 FTP Security Extensions October 1997
If the "ftp" principal name is not a registered principal in
Kerberos database, then the client may fall back on the "rcmd
principal name (same instance and realm). However, servers
accept only one or the other of these principal names, and must
be willing to accept either. Generally, if the server has a key
the "ftp" principal in its srvtab, then that principal only must
used, otherwise the "rcmd" principal only must be used
The server must base 64 decode the argument to the ADAT command
pass the result to krb_rd_req(3). The server must add one to
checksum from the authenticator, convert the result to network
order (most significant byte first), and sign it
krb_mk_safe(3), and base 64 encode the result. Upon success,
server must reply to the client with a 235 code and
"ADAT=base64string" in the text of the reply. Upon failure,
server should reply 535.
Upon receipt of the 235 reply from the server, the client must
the text of the reply for the base 64 encoded data, decode it
convert it from network byte order, and pass the result
krb_rd_safe(3). The client must consider the server authenticated
the resultant checksum is equal to one plus the value
sent
The procedure associated with MIC commands, 631 replies, and
file transfers is
krb_mk_safe(3) for the
krb_rd_safe(3) for the
The procedure associated with ENC commands, 632 replies, and
file transfers is
krb_mk_priv(3) for the
krb_rd_priv(3) for the
CONF commands and 633 replies are not supported
Note that this specification for KERBEROS_V4 contains no
for negotiating alternate means for integrity and
routines. Note also that the ADAT exchange does not convey
the peer supports confidentiality services
In order to stay within the allowed PBSZ, implementors must take
that a cleartext buffer will grow by 31 bytes when processed
krb_mk_safe(3) and will grow by 26 bytes when processed
krb_mk_priv(3).
Horowitz & Lunt Standards Track [Page 26]
RFC 2228 FTP Security Extensions October 1997
Full Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implmentation may be prepared, copied,
andand distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Horowitz & Lunt Standards Track [Page 27]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
