One Hat Cyber Team

Edit File: draft-bonachea-sftp-00.txt

Network Working Group                                    D. Bonachea
<draft-bonachea-sftp-00.txt>                             S. McPeak
Updates: RFC 2228
Internet-Draft
Expires in January, 2000                                 June, 1999

Protocol Negotiation Extensions to Secure FTP

Status of this Memo

This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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."

The list of current Internet-Drafts can be accessed at

http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

This document presents refinements to RFC 2228, "FTP Security
   Extensions" (October 1997) [1].  It lends support for more efficient
   and secure protocol negotiation in the presence of multiple protocol
   possibilities, by adding one new optional command and several new
   reply codes.

The following new optional command is introduced in this
   specification:

DIGT (Protocol Negotiation Digest)

This document also seeks to solidify several issues that were left
   underspecified in RFC 2228.  Specifically, it adds additional reply
   codes to cover cases not mentioned in the original specification and
   it defines a legal naming convention for security mechanisms.

Bonachea & McPeak                                               [Page 1]

INTERNET DRAFT          Extensions to Secure FTP           June 18, 1999

1.   Introduction

Recently, the authors implemented the RFC 2228 protocol, FTP Security
   Extensions [1].  This protocol extends the basic File Transfer
   Protocol (FTP) specified in RFC 959 [2], adding security services
   including authentication and privacy.  We assume the reader is
   familiar with RFC 2228.

During the implementation of RFC 2228 we found it necessary and
   useful to make several changes to the protocol.  This memo details
   those changes.

Section 2 describes changes which extend RFC 2228, to improve
   security and efficiency.  Section 3 closes specification holes in RFC
   2228 itself. Section 4 lifts a RFC 959 restriction, thereby improving
   total system security.

2.   Protocol Negotiation Improvements

DIGT (Protocol Negotiation Digest) command

This new command provides a way for a client to verify that an
   attacker didn't interfere with the protocol negotiation sequence.
   This is important because a client that supports multiple security
   mechanisms might be "tricked" into using its weakest security
   mechanism by an attacker who interferes with protocol negotiation
   (i.e. by modifying the appropriate mechanism acceptance replies to
   look like refusals).  The client may issue this optional command at
   any time after authentication is complete, and the server will reply
   with a secure hash digest computed over the entire protocol
   negotiation exchange. The client can then compare this digest to the
   locally computed digest to verify that both server and client
   experienced the same protocol negotiation sequence (i.e. there was no
   outside interference).  The hash function is Sha1, and is computed
   over the entire negotiation sequence from the first character in the
   first client command (usually an AUTH), to the last character in the
   server reply which indicates the security data exchange is complete
   (the LF character on a 234 or 235 reply). The form of the server
   reply to DIGT will be:

211 DIGT=base64data
      ; base64data is a placeholder for the actual digest block,
      ; which must be encoded using the base64 format, as
      ; described in RFC 2228 (see [1] for details).

The server may also send a 502 response if the DIGT command is not
   implemented.

Bonachea & McPeak                                               [Page 2]

INTERNET DRAFT          Extensions to Secure FTP           June 18, 1999

Note the efficacy of this security measure depends on the client
   asking for the digest faster than an attacker can compromise the
   current (weaker) security mechanism and substitute a modified digest.

Efficiency improvements to protocol negotiation

RFC 2228 allows for the possibility of clients and servers that
   implement a large number of security mechanisms, yet it provides no
   efficient means for the client to discover and request a supported
   mechanism.  Under the RFC 2228 specification, the client repeatedly
   issues AUTH commands for each security mechanism it supports (in
   order of preference) until finding one the server will accept.  For
   clients that implement a large number of mechanisms, this could
   potentially lead to an unreasonably large number of network round
   trips in order to complete the protocol negotiation sequence.  In
   order to alleviate this problem, this specification adds two new
   optional server reply codes that allow the server to reveal a list of
   acceptable security mechanisms in a single reply. This enables the
   client to perform the search locally and select an acceptable
   mechanism in a single network roundtrip.

The new reply codes to the AUTH command are:

504 Security mechanism unrecognized. [LIST=mechlist]
   504 Security mechanism unrecognized. [ILST=mechlist]

Here, mechlist is a space-delimited list of security mechanisms that
   the server understands and might accept from this client. The keyword
   LIST indicates that mechlist is a complete list of acceptable
   security mechanisms, and any mechanisms not listed will be refused.
   The keyword ILST indicates that mechlist is an incomplete list of
   acceptable security mechanisms, and that other acceptable unlisted
   security mechanisms might exist.  The square brackets are not to be
   included in the actual reply, but indicate that the mechanism list is
   optional.

3. Amendments to RFC 2228

New server replies

This section presents several new server reply codes which were
   missing in the original specification.

234 Security data exchange complete. [ADAT=base64data]
    ;  This reply to AUTH indicates the security data exchange
    ;  completed successfully.  The square brackets are not to be
    ;  included in the reply, but indicate that security data in
    ;  the reply is optional.

Bonachea & McPeak                                               [Page 3]

INTERNET DRAFT          Extensions to Secure FTP           June 18, 1999

This reply code existed in RFC 2228, but did not allow for the
   possibility of the server sending security data (for protocols where
   the only data exchange necessary is for the server to send a block to
   the client).

503 Reauthentication is prohibited.
    ;  This reply code to an AUTH indicates that a successful
    ;  security data exchange has completed, and this server is
    ;  unwilling to begin a new authentication session (the
    ;  client must "hang up" and reconnect)

RFC 2228 specifies that a server may prohibit the client from
   reissuing the AUTH command in order to establish new authentication,
   but provides no reply code to communicate this.

PBSZ Negotiation

During PBSZ (Protocol Buffer Size) negotiation, the client proposes a
   buffer size, and the server may accept this size, reply with a
   smaller size, or give an error. The size agreed upon is subsequently
   used during data transfers as a maximum bound on the size of each
   encrypted block.  However, some protocol mechanisms have a minimum
   encrypted block size, and RFC 2228 doesn't provide a way for the
   server to indicate that the proposed block size is too small.  To
   remedy this, this specification adds a new reply code:

538 PBSZ too small. [PBSZmin=numBytes]
    ;  This reply to PBSZ indicates the proposed buffer size is
    ;  unacceptably small. The server may also include an optional
    ;  string of the form PBSZmin=numBytes to indicate the smallest
    ;  buffer size it will accept. The square brackets are not to be
    ;  included in the reply, but indicate that the PBSZmin argument
    ;  in the reply is optional.

Protocol Mechanism Naming Specification

The guidelines provided by RFC 2228 for the naming of new protocol
   mechanisms are somewhat vague, and as such are insufficient for the
   purposes of successful protocol negotiation as described in section
   2.  Following is a revised, more rigorous specification for the
   naming of protocol mechanisms:

The protocol mechanism name must not exceed 255 characters, and may
   only contain the characters with codes 33...126 in the USASCII
   character set.  Names are case-insensitive.  All names must be
   registered with the IANA, except names beginning with "X-", which are
   reserved for local use.

Bonachea & McPeak                                               [Page 4]

INTERNET DRAFT          Extensions to Secure FTP           June 18, 1999

4. Miscellaneous changes to RFC 2228

Port 20 restriction for outgoing server data connections:

RFC 2228 is a superset specification of RFC 959 [2], which defines
   the basic FTP protocol. RFC 959 requires that while in active mode,
   all outgoing data connections from the FTP server must be bound to
   port 20, as a weak form of authentication. However, most FTP clients
   fail to enforce this port restriction (i.e. they don't check).
   However, implementation experience has shown that the port
   restriction is also the only hindrance to running a legitimate RFC
   2228 server as an entirely user-level proxy (which augments overall
   system security). Because RFC 2228 provides more comprehensive
   support for strong, cryptographic authentication mechanisms, it has
   made the port 20 restriction for outgoing server data connections
   obsolete, and the restriction is hereby lifted.

5.  Security Considerations

This entire memo is about security mechanisms.

6.  References

[1] - M. Horowitz and S. J. Lunt.  FTP Security Extensions.
        RFC 2228, October, 1997

[2] - J. Postel and J. Reynolds.  File Transfer Protocol (FTP).
        RFC 959, October, 1985

7.  Authors' Addresses

Dan Bonachea
   Computer Science Division
   566 Soda Hall
   Berkeley, CA 94720   USA
   Phone: +1 510 642-8493
   Email: bonachea@cs.berkeley.edu

Scott McPeak
   Computer Science Division
   566 Soda Hall
   Berkeley, CA 94720   USA
   Phone: +1 510 642-8493
   Email: smcpeak@cs.berkeley.edu

Bonachea & McPeak                                               [Page 5]