One document matched: draft-ietf-cat-ftpsec-06.txt
Differences from draft-ietf-cat-ftpsec-05.txt
Network Working Group M. Horowitz
<draft-ietf-cat-ftpsec-06.txt> Openvision Technologies
Updates: RFC 959 S. J. Lunt
Internet-Draft Bellcore
March, 1995
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.
Abstract
This document defines extensions to the FTP specification RFC 959,
"FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions
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 Mechanism),
ADAT (Authentication Data),
PROT (Data Channel Protection Level),
PBSZ (Protection Buffer Size),
MIC (Integrity Protected Command),
CONF (Confidentiality Protected Command), and
ENC (Privacy Protected Command).
Expires: September 30, 1995 [Page 1]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
A new class of reply types (6yz) is also introduced for protected
replies.
None of the above commands are required to be implemented, but
interdependencies exist.
Note that this specification is compatible with RFC 959.
1. Introduction
The File Transfer Protocol (FTP) currently defined in RFC 959 and in
place on the Internet uses usernames and passwords passed in clear-
text to authenticate clients to servers (via the USER and PASS com-
mands). 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 poten-
tial 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 verify-
ing 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 authen-
ticity 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 proto-
col in a consistent manner and which takes advantage of existing
Expires: September 30, 1995 [Page 2]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
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 [TELNET-
SEC], [RFC-1123] explicitly forbids the use of Telnet option negotia-
tion 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.
2. FTP Security Overview
At the highest level, the FTP security extensions seek to provide an
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 establishment
of a client's identity in a secure way, usually using cryptographic
techniques. The basic FTP protocol does not have a concept of
authentication.
Authorization is the process of validating a user for login. The
basic authorization process involves the USER, PASS, and ACCT com-
mands. With the FTP security extensions, authentication established
using the authentication mechanism may also be used to make the
authorization decision.
Without the security extensions, FTP authentication is established by
assertion (with the USER command), and authorization is validated by
a password on the network in the clear.
An FTP security interaction begins with a client telling the server
what authentication mechanism it wants to use with the AUTH command.
The server will either accept this mechanism, reject this mechanism,
or, in the case of a server which does not implement the security
extensions, reject the command completely. The client may try multi-
ple authentication mechanisms until it requests one which the server
accepts. This allows a rudimentary form of negotiation to take
place. The server's reply will will indicate if the client should
respond with additional data for the authentication mechanism to
interpret. If none is needed, this will usually mean that the
mechanism is one where the password (specified by the PASS command)
is to be interpreted differently, such as with a token or one-time
password system.
Expires: September 30, 1995 [Page 3]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
If the server requires additional authentication information, then
the client and server will enter into an authorization data exchange.
The client will send an ADAT command containing the first block of
authentication data. The server's reply will indicate if the data
exchange is complete, if there was an error, or if more data is
needed. The server's reply can optionally contain authentication
data for the client to interpret. If more data is needed, the client
will send another ADAT command containing the next block of data, and
await the server's reply. This exchange can continue as many times
as necessary. Once this exchange completes, the client and server
have established authentication, which may be one-way or mutual,
depending on the mechanism in use.
Once authentication is established, this authentication may be used
instead of or in addition to the standard username/password exchange
for authorizing a user to connect to the server. In addition, the
client and server may begin integrity and/or confidentiality protect-
ing commands with the MIC, CONF, and ENC commands, and replies with
the 63z reply codes.
Once the client and server have negotiated with the PBSZ command an
acceptable buffer size for encapsulating protected data over the data
channel, the authentication mechanism may also be used to protect
data channel transfers.
Policy is not specified by this document. In particular, client and
server implementations may choose to implement restrictions on what
operations can be performed depending on the authentication which
exists. For example, a server might require that a client authorize
via an authentication mechanism rather than using a password, require
at least integrity protection on the command channel, or require that
certain files only be transmitted encrypted. An anonymous ftp client
might refuse to do file transfers without integrity protection in
order to insure the validity of files downloaded.
No particular set of functionality is required, except as dependen-
cies described in the next section. This means that none of authori-
zation, integrity, or confidentiality are required of an implementa-
tion, although a mechanism which does none is not of much use. For
example, it is acceptable for a mechanism to implement only integrity
protection, one-way authentication and/or encryption, encryption
without any authentication or integrity protection, or any other sub-
set of functionality if policy or technical considerations make this
desirable. Of course, a peer might require stronger protection as a
matter of policy, preventing perfect interoperability.
Expires: September 30, 1995 [Page 4]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
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
mechanism. This string is case-insensitive. Values must be
registered with the IANA, except that values beginning with "X-"
are reserved for local use.
If the server does not implement the security extensions, it
should respond with reply code 500.
If the server does not understand the named authentication mechan-
ism, it should respond with reply code 504.
If the server is not willing to accept the named authentication
mechanism, it should respond with reply code 534.
If the server is not able to accept the named authentication
mechanism, such as if a required resource is unavailable, it
should respond with reply code 431.
If the server is willing to accept the named authentication
mechanism, but requires authentication data, it should respond
with reply code 334.
If the server is willing to accept the named authentication
mechanism, and does not require any authentication data, it should
respond with reply code 234.
Some servers will allow the AUTH command to be reissued in order
to establish new authentication. The AUTH command, if accepted,
removes any state associated with prior FTP Security commands.
The server may also choose to require that the user reauthorize in
this case (see section 2).
AUTHENTICATION DATA (ADAT)
The argument field is a Telnet string representing base 64 encoded
authentication data (see Section xx, "Base 64 Encoding"). If a
reply code indicating success is returned, the server may also use
a string of the form "ADAT=base64data" as the text part of the
reply if it wishes to convey authentication data back to the
client.
Expires: September 30, 1995 [Page 5]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
The data in both cases is specific to the authentication mechanism
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 authentication data
exchange should include enough information for both peers to be
aware of which optional features are available. For example, if
the client does not support authentication, the server should be
aware of this, so it will know not to send encrypted command chan-
nel replies. The authentication mechanism should provide sequenc-
ing on the command channel, to insure that commands are not
deleted, reordered, or replayed.
The ADAT command must be preceded by a successful AUTH command,
and cannot be issued once an authentication data exchange com-
pletes (successfully or unsuccessfully), unless it is preceded by
an AUTH command to reset the authentication state.
If the server has not yet received an AUTH command, or if a prior
authentication data exchange completed, but the authentication
state has not been reset with an AUTH command, it should reply
with reply code 503.
If the server cannot base 64 decode the argument, it should
respond with reply code 501.
If the server rejects the authentication data (if a checksum
fails, for instance), it should respond with reply code 535.
If the server accepts the authentication data, and requires addi-
tional data, it should respond with reply code 336.
If the server accepts the authentication data, but does not
require any additional data (i.e., the authentication data
exchange has completed successfully), it should respond with reply
code 235.
If the server is responding with a 234 or 334 reply code, then it
may include authentication data in the text part of the reply as
specified above.
If the authentication mechanism exchange returns an error, the
authentication state of the client is reset. If the client
becomes unsynchronized with the server (for example, the server
sends a 234 reply code to an AUTH command, but the client has more
data to transmit), then the client should reset the server's
authentication state.
PROTECTION BUFFER SIZE (PBSZ)
Expires: September 30, 1995 [Page 6]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
The argument is a decimal integer representing the maximum size,
in bytes, of the encoded data blocks to be sent or received during
file transfer. This number shall be no greater than can be
represented in a 32-bit unsigned integer.
This command allows the FTP client and server to negotiate a max-
imum 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.
The PBSZ command must be preceded by a successful authentication
data exchange.
If the server cannot parse the argument, or if it will not fit in
32 bits, it should respond with a 501 reply code.
If the server has not completed an authentication data exchange
with the client, it should respond with a 503 reply code.
Otherwise, the server should reply with a 200 reply code. If the
size provided by the client is too large for the server, it should
use a string of the form "PBSZ=number" in the text part of the
reply to indicate a smaller buffer size. The client and the
server should use the smaller of the two buffer sizes if both
buffer sizes are specified.
DATA CHANNEL PROTECTION LEVEL (PROT)
The argument is a single Telnet character code specifying the data
channel protection level.
This command indicates to the server what type of data channel
protection the client and server will be using. The following
codes are assigned:
C - Clear
S - Safe
E - Confidential
P - Private
The default protection level if no other level is specified is
Clear. The Clear protection level indicates that the data channel
will carry the raw data of the file transfer, with no security
applied. The Safe protection level indicates that the data will
be integrity protected. The Confidential protection level indi-
cates that the data will be confidentiality protected. The
Private protection level indicates that the data will be integrity
and confidentiality protected.
Expires: September 30, 1995 [Page 7]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
It is reasonable for an authentication mechanism not to provide
all data channel protection levels. It is also reasonable for a
mechanism to provide more protection at a level than is required
(for instance, a mechanism might provide Confidential protection,
but include integrity-protection in that encoding, due to API or
other considerations).
The PROT command must be preceded by a successful protection
buffer size negotiation.
If the server does not understand the specified protection level,
it should respond with reply code 504.
If the current authentication mechanism does not support the
specified protection level, the server should respond with reply
code 536.
If the server has not completed a protection buffer size negotia-
tion with the client, it should respond with a 503 reply code.
The PROT command will be rejected and the server will reply 503 if
no previous PBSZ command was issued.
If the server is not willing to accept the specified protection
level, it should respond with reply code 534.
If the server is not able to accept the specified protection
level, such as if a required resource is unavailable, it should
respond with reply code 431.
INTEGRITY PROTECTED COMMAND (MIC) and
CONFIDENTIALITY PROTECTED COMMAND (CONF) and
PRIVACY PROTECTED COMMAND (ENC) and
The argument field of MIC is a Telnet string consisting of a base
64 encoded "safe" message produced by an authentication mechanism
specific message integrity procedure. The argument field of CONF
is a Telnet string consisting of a base 64 encoded "confidential"
message produced by an authentication mechanism specific confiden-
tiality procedure. The argument field of ENC is a Telnet string
consisting of a base 64 encoded "private" message produced by an
authentication mechanism specific message integrity and confiden-
tiality procedure.
The server will decode and/or verify the encoded message.
This command must be preceded by a successful authentication data
exchange.
Expires: September 30, 1995 [Page 8]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
If the server cannot base 64 decode the argument, it should
respond with a 501 reply code.
If the server has not completed an authentication data exchange
with the client, it should respond with a 503 reply code.
If the server rejects the command (if a checksum fails, for
instance), it should respond with reply code 535.
If the server is not willing to accept the command (if privacy is
required by policy, for instance), it should respond with reply
code 533.
Otherwise, the command will be interpreted as an FTP command. An
end-of-line code need not be included, but if one is included, it
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, all
commands be protected. In this case, it should make a 533 reply
to commands other than MIC, CONF, and ENC.
4. New FTP Replies
The new reply codes are divided into two classes. The first class is
new replies made necessary by the new FTP Security commands. The
second class is a new reply type to indicate protected replies.
4.1. New individual reply codes
232 User logged in, authorized by authentication data exchange.
234 Authentication data exchange complete.
235 [ADAT=base64data]
; This reply indicates that the authentication exchange
; completed successfully. The square brackets are not
; to be included in the reply, but indicate that
; authentication data in the reply is optional.
334 Need more authentication data.
335 [ADAT=base64data]
; This reply indicates that the authentication data is
; acceptable, and more is required to complete the
; authentication data exchange. The square brackets
; are not to be included in the reply, but indicate
; that authentication data in the reply is optional.
; Authentication data ok, need more authentication
; data.
Expires: September 30, 1995 [Page 9]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
336 Username okay, need password. Challenge is "...."
; The exact representation of the challenge should be chosen
; by the mechanism to be sensible to the human user of the
; system.
431 Need some unavailable resource to handle authentication.
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.
4.2. Protected replies.
One new reply type is introduced:
6yz Protected reply
There are three reply codes of this type. The first, reply
code 631 indicates an integrity protected reply. The
second, reply code 632, indicates a confidentiality and
integrity protected reply. the third, reply code 633, indi-
cates a confidentiality protected reply.
The text part of a 631 reply is a Telnet string consisting
of a base 64 encoded "safe" message produced by an authenti-
cation mechanism specific message integrity procedure. The
text part of a 632 reply is a Telnet string consisting of a
base 64 encoded "private" message produced by an authentica-
tion mechanism specific message confidentiality and
integrity procedure. The text part of a 633 reply is a Tel-
net string consisting of a base 64 encoded "confidential"
message produced by an authentication mechanism specific
message confidentiality procedure.
The client will decode and verify the encoded reply. How
failures decoding or verifying replies are handled is
implementation-specific. An end-of-line code need not be
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 an authentication data
exchange has succeeded.
The 63z reply may be a multiline reply. In this case, the
plaintext reply must be broken up into a number of frag-
ments. Each fragment must be protected, then base 64
Expires: September 30, 1995 [Page 10]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
encoded in order into a separate line of the multiline
reply. There need not be any correspondence between the
line breaks in the plaintext reply and the encoded reply.
Telnet end-of-line codes must appear in the plaintext of the
encoded reply, except for the final end-of-line code, which
is optional.
The multiline reply must be formatted more strictly than the
continuation specification in RFC 959. In particular, each
line before the last must be formed by the reply code, fol-
lowed immediately by a hyphen, followed by a base 64 encoded
fragment of the reply.
For example, if the plaintext reply is
123-First line
Second line
234 A line beginning with numbers
123 The last line
then the resulting protected reply could be any of the fol-
lowing (the first example has a line break only to fit
within the margins):
631 base64(protect("123-First line\r\nSecond line\r\n 234 A line
beginning with numbers\r\n123 The last line\r\n"))
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"))
5. Login Authorization
The authentication data exchange may, among other things, establish
the identity of the client in a secure way to the server. This iden-
tity may be used as one input to the login authorization process.
In response to the FTP login commands (AUTH, PASS, ACCT), the server
may choose not to follow the sequence of commands and replies speci-
fied by RFC 959. There are also some new replies available.
If the server is willing to allow the user named by the USER command
to log in based on the identity established by the authentication
Expires: September 30, 1995 [Page 11]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
data exchange, it should respond with reply code 232.
If the authentication mechanism requires a challenge/response pass-
word, it should respond to the USER command with reply code 335. The
text part of the reply should contain the challenge. The client
should be sure to display the challenge to the user before prompting
for the password in this case.
6. Data Channel Encapsulation
When data transfers are protected between the client and server (in
either direction), certain transformations and encapsulations must be
performed so that the recipient can properly decode the transmitted
file.
The sender should apply all protection services after transformations
associated with the representation type, file structure, and transfer
mode have been performed. The data sent over the data channel is,
for the purposes of protection, to be treated as a byte stream.
The sender should take the input byte stream, and break it up into
blocks such that each block, when encoded using an authentication
mechanism specific procedure, will be no larger than the buffer size
negotiated by the client with the PBSZ command. Each block should be
encoded, then transmitted with the length of the encoded block
prepended as a four byte unsigned integer, most significant byte
first.
When the end of the file is reached, the sender should encode a block
of zero bytes, and send this final block to the recipient before
closing the data connection.
The recipient will read the four byte length, read a block of data
that many bytes long, then decode and verify this block with an
authentication mechanism specific procedure. This should be repeated
until a block encoding a buffer of zero bytes is received. This
indicates the end of the encoded byte stream.
Any transformations associated with the representation type, file
structure, and transfer mode are to be performed by the recipient on
the byte stream resulting from the above process.
When using block transfer mode, the sender's (cleartext) buffer size
is independent of the block size.
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
Expires: September 30, 1995 [Page 12]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
by the server's security requirements for the particular file
transfer.
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).
7. Potential policy considerations
While there are no restrictions on client and server policy, there
are a few recommendations which an implementation should implement.
- Once an authentication data exchange takes place, a server should
require all commands be protected (with integrity and/or confiden-
tiality), and it should protect all replies. Replies should use
the same level of protection as the command which produced them.
This includes replies which indicate failure of the MIC, CONF, and
ENC commands. In particular, it is not meaningful to require that
AUTH and ADAT be protected; it is meaningful and useful to require
that PROT and PBSZ be protected.
- A client should encrypt the PASS command whenever possible. It is
reasonable for the server to refuse to accept a non-encrypted PASS
command if the server knows encryption is available.
- Although no commands are required, it is recommended that an imple-
mentation provide all commands which can be implemented, given the
mechanisms supported and the policy considerations of the site
(export controls, for instance).
8. Declarative specifications
These sections are modelled after sections 5.3 and 5.4 of RFC 959, which
describe the same information, except for the standard FTP commands and
replies.
8.1. FTP Security commands and arguments
AUTH <SP> <mechanism-name> <CRLF>
ADAT <SP> <base64data> <CRLF>
PROT <SP> <prot-code> <CRLF>
PBSZ <SP> <decimal-integer> <CRLF>
MIC <SP> <base64data> <CRLF>
CONF <SP> <base64data> <CRLF>
Expires: September 30, 1995 [Page 13]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
ENC <SP> <base64data> <CRLF>
<mechanism-name> ::= <string>
<base64data> ::= <string>
; must be formatted as described in section xx
<prot-code> ::= C | S | E | P
<decimal-integer> ::= any decimal integer from 1 to (2^32)-1
8.2. Command-Reply sequences
Authentication
AUTH
234
334
504, 534, 431
500, 501, 421
ADAT
235
335
503, 501, 535
500, 501, 421
Data protection negotiation commands
PBSZ
200
503
500, 501, 421, 530
PROT
504, 536, 503, 534, 431
500, 501, 421, 530
Command channel protection commands
MIC
535, 533
500, 501, 421
CONF
535, 533
500, 501, 421
ENC
535, 533
500, 501, 421
Security-Enhanced login commands (only new replies listed)
USER
232
336
Data channel commands (only new replies listed)
STOR
534, 535
STOU
Expires: September 30, 1995 [Page 14]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
534, 535
RETR
534, 535
LIST
534, 535
NLST
534, 535
APPE
534, 535
In addition to these reply codes, any command can return 631, 632,
633, or 533.
9. Base 64 Encoding
Base 64 encoding is the same as the Printable Encoding described in
Section 4.3.2.4 of [RFC-1421], except that no line breaks should be
included. This encoding 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 neces-
sarily with the same bit patterns (e.g., although the character "E"
is represented in an ASCII-based system as hexadecimal 45 and as hex-
adecimal 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 sub-
set of characters is represented identically in IA5 and ASCII.) The
character "=" signifies a special processing function used for pad-
ding 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 signi-
ficance 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
Expires: September 30, 1995 [Page 15]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
the right) to form an integral number of 6-bit groups. Output char-
acter 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 mul-
tiple 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, CONF, and ENC commands, and in 63z 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 contain-
ing base 64 encodings.
10. Security Considerations
This entire document deals with security considerations related to
the File Transfer Protocol.
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.
11. Acknowledgements
I would like to thank the members of the CAT WG, as well as all par-
ticipants 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. Of course, without Steve Lunt, the author of the first
six revisions of this document, it would not exist at all.
Expires: September 30, 1995 [Page 16]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
12. References
[TELNET-SEC] Borman, D., "Telnet Authentication and Encryption
Option", Internet Draft, Cray Research, Inc, April 1993.
[RFC-1123] Braden, R., "Requirements for Internet Hosts -- Applica-
tion and Support", RFC 1123, October 1989.
[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication Procedures",
RFC 1421, February 1993.
13. Author's Address
Marc Horowitz
Openvision Technologies
1 Main Street
Cambridge, MA 02142
Phone: 617 374 2224
Email: marc@cam.ov.com
Appendix I: Specification under Kerberos version 4
The authentication mechanism name (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 first part of 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 Ker-
beros 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
Expires: September 30, 1995 [Page 17]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
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, con-
vert 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 MIC commands, 631 replies, and Safe
file transfers is:
krb_mk_safe(3) for the sender
krb_rd_safe(3) for the receiver
The procedure associated with ENC commands, 632 replies, and Private
file transfers is:
krb_mk_priv(3) for the sender
krb_rd_priv(3) for the receiver
CONF commands and 633 replies are not supported.
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 mechanism name (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
Expires: September 30, 1995 [Page 18]
draft-ietf-cat-ftpsec-06.txtFTP Security Extensions March, 1995
(initially), and a targ_name equal to output_name from
GSS_Import_Name called with input_name_type of Host-Based Service and
input_name_string of "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
"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_S_CONTINUE_NEEDED, then the client
should expect a token to be returned in the reply to the ADAT com-
mand. 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_S_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_S_COMPLETE, the reply code should
be 235, and the server should consider the client authenticated. If
GSS_Accept_Sec_Context returns GSS_S_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 MIC commands, 631 replies, and Safe
file transfers is:
GSS_Seal for the sender, with conf_flag == FALSE
GSS_Unseal for the receiver
The procedure associated with ENC commands, 632 replies, and Private
file transfers is:
GSS_Seal for the sender, with conf_flag == TRUE
GSS_Unseal for the receiver
CONF commands and 633 replies are not supported.
Both the client and server should inspect the value of conf_avail to
determine whether the peer supports confidentiality services.
Expires: September 30, 1995 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 10:30:50 |