Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/ftpext/ftpext-minutes-97apr.txt

Text File | 1997-05-29 | 18KB | 550 lines

Editor's Note:  These minutes have not been edited.


Reported by Bill Curtin <[e-mail]>

                   Minutes for the FTPEXT WG in Memphis

The  working group chair opened the meeting by proposing an agenda which
included discussions on the groups outstanding drafts: security
considerations, variable ftp, ftp internationalization, MLST/MLSD, and
Restart.


- SECURITY CONCIDERATIONS (draft-allman-ftp-sec-consider-01.txt)

A presentation of the security considerations document was made by
the authors. They explained that the document was based on concerns
raised on the mail list. The document recommends ways to reduce
security problems and details bounce attacks associated with 3 way
connections,  access restrictions based on IP addresses, and how to
protect passwords against brute force attacks.

An example of a bounce attack was presented using the PASV and PORT
command to pass a file containing RFC822 commands to the well known
port for SMTP thereby fooling the SMTP server as to the origin of the
mail message. The recommended solution to this attack was to refuse
PORT commands to well known ports (i.e. <1024). A suggestion was made
to use a reply code 504  in response to an attempt by the user-FTP to
use the PORT command with a port number <1024.

It was noted during the description of restricting access based on
network address that the server must verify both the control and data
connection and that this approach would still be open to a "spoof
attack"

The recommended solution to a brute force attack on password guessing
was to limit attempts to 3-5 and then close the connection. An
additional solution was to add in a delay and to use operating system
services where available. The group noted that rather then abruptly
closing the connection that the server should return a 421 reply. It
was also noted that there was still the possibility to using the
brute force attack, even with this recommendation, by simply opening
up numerous control connections. It was noted that the draft should
include sections on port stealing, integrity, and privacy. The
suggestion to the latter 2 was to reference the FTP security
extensions draft (being progressed through the Common Authentication
working group);  the recommendation for the former was to avoid
assigning port numbers sequentially (i.e. assign them randomly) or
to possibly use a cookie passing technique.

- FTP Extensions for Variable Protocol Specification

The authors noted that RFC959 limits the PORT and PASV command to a 32
bit IPV4 and 16 bit TCP addresses and that this will not work with other
network or transport protocols, most notably Ipv6. The authors also
noted that the FOOBAR RFC, while removing this restriction still
associates specific network and transport protocols. In an attempt to
decouple the relationship of the network and transport protocols while
not removing functionality defined in RFC959 the authors defined 2 new
commands, EPRT and EPSV, to replace the PORT and  PASV commands.

The format of the EPRT command is:
EPRT <net-prot>|<trans-prot>|net-addr|<trans-addr
The first 3 fields are optional.  The last is required in all cases.

The protocol also defines field keywords for the EPRT command as:
IP4, IP6, TCP, and RDP. Other keywords will be defined as necessary.

The group commented that the draft needed to clarify that the "|" were
being used as field delimiters by the protocol and did not connote the
word "or". A suggestion was also made to place a delimiter after the
space separating the commands from the fields and to possibly allow the
first non-blank character to represent the delimiter. This would allow
future network protocols maximum freedom to represent network addresses
without concern for colliding with the delimiter defined in this draft.

The format of the EPSV returns information necessary to open a data
connection by the EPRT command in the following format:

(<net-prot>|<trans-prot>|net-addr|<trans-addr) <Text to express that
server is entering extended passive mode>

The parenthesis and the fields within them must be returned from a EPSV
request.

It was noted that there may be a problem if EPSV returns a protocol
which can not be supported. The group commented that possibly there
should be a prior negotiation which could last the entire session or
until it was changed.


- Internationalization of the File Transfer Protocol (draft-ietf-ftpext-
intl-ftp-01.txt)

The editor for this draft gave a brief overview on what was contained in
the draft (e.g. restriction on 7 bit ASCII dropped, use ISO 10646-1
character set, and use UTF-8 transfer encoding). A description of the
changes from the first version of this draft were given: draft
restructured to shorten normative portion and added 2 informative
appendices; and defined use of space and CRLF characters used in
pathnames.

It was noted that there were not many comments on the latest version of
the draft and that all of the editorial comments had already been
changed in the working draft copy. There were 3 outstanding comments to
the latest version: Caveat of ISO's adoption of amendment 5 may no
longer be necessary because ISO may have already approved the amendment;
the code example to check for UTF-8 strings was expanded but needed to
be checked; and it might be nice to have a section which dealt with
transitional issues and backward compatibility.

The presentation finished by asking if this draft should go standards
track and if the RFC 1123 tables needed to be updated to include the new
features and commands being developed in this and other FTP related
drafts. The group seemed to feel that the draft should go to standards
track and that a RFC 1123 type table, while not necessary, might be
nice.


- MLST command and Extensions to FTP (draft-ietf-ftpext-mlst-00.txt)

A proposal by the chair to merge the Restart document with the MLST
document was presented. The chair noted that all of the authors of the
drafts had already concurred with the proposal. The group had no
objection.


There was a discussion on directory and filename concatenation. It was
noted that trend is toward virtual file names and may not be able to
concatenate directory and filename. Suggestion to maybe allow
directory/filename without doing a CWD. But not the weird things.

The author agreed to align the UTC time to the format given in the
RESTART draft.

The consensus at the meeting was to drop MLST replies over the control
connection. It was suggested that the STAT command could be used for the
same behavior. A server which supports MLST would use the same format if
STAT is used.

The author asked if it made sense to allow implementation specific
extensions to be case sensitive (i.e. x -vs- X). The group opinion was
that extensions should by case insensitive.

After some discussion about the need or use of the link "type" fact it
was decided that it added no real value and should be removed from the
specification.

There was a discussion on what use the x value of the "perm" fact has
given that there is no guarantee that the file can execute on a given
platform. The suggestion is to remove the x value from the draft.

There was a discussion on the ability to cache the FEAT command for use
in subsequent sessions. The group felt that caching should not be a
condoned strategy and that it should not be addressed in the draft.

- REST Command and Extensions to FTP (draft-ietf-ftpext-restart-00.txt)

It was decided that the REST command must immediately precede the
operative command (RETR/STOR). Anywhere else and its effect will be
undefined.

There was some questions on the need for a manual restart and whether
the same results couldn't be achieved by doing an ABOR and later use the
SIZE command to get the restart marker. This topic was left for further
discussion on the list.

======================================================================
IPv6 Slides

---Slide 1---

        FTP Extensions for Variable
           Protocol Specification

      draft-allman-ftp-variable-04.txt

         April 9, 1997

      Mark Allman and Shawn Ostermann

      {mallman,ostermann}@cs.ohiou.edu

        Ohio University

         http://jarok.cs.ohiou.edu/

---Slide 2---

       PORT/PASV Examples

PORT Command

    PORT EXAMPLE - FIGURE

PASV Command

    PASV EXAMPLE - FIGURE

---Slide 3---

          Introduction

FTP [RFC 959] limits addresses to IPv4/TCP
    -32 bit network address (IP address)
    -16 bit transport address (TCP port number)

This will not work with IPv6 network addresses (128 bits).

Piscitello's FOOBAR [RFC 1639] mechanism solves the problem, but...
    -Network and transport protocols are linked together.
    -Choosing a network protocol automatically chooses a transport
     protocol.

---Slide 4---

             Goals

Design more general versions of the PORT and PASV FTP commands.
    -Should work over any combination of network and transport
     protocols supported by a given client/server pair.

Maintain all the functionality present in RFC 959.

New commands: EPRT and EPSV

---Slide 5---

        EPRT

FTP command sent from one machine to another.

Allows the use of \textit{extended addresses}.

Format: EPRT <NP>|<TP>|<NA>|<TA>
    <NP> - network protocol
    <TP> - transport protocol
    <NA> - network address
    <TA> - transport address

---Slide 6---
       Defined Protocols

Protocols MUST be upper-case strings indicating the protocol (and,
implicitly, address length)

Network Protocols defined in the draft:

    Text    Meaning
    ----    -------
    IP4     Internet Protocol, Version 4
    IP6     Internet Protocol, Version 6

Transport Protocols defined in the draft:
    Text    Meaning
    ----    -------
    TCP     Transmission Control Protocol
    RDP     Reliable Data Protocol

---Slide 7---

          Network Address Formats

For each of the following keywords, the address in the EPRT command
MUST be in the format given:

IP4
    -String representation of dotted decimal format address.
    -Example: 132.235.1.2

IP6
    -IPv6 string representations defined in RFC 1884.
    -Example: 1080::8:800:200C:417A

---Slide 8---

         Transport Address Formats

TCP
    -String representation of decimal port number.
    -Example: 6446

RDP
    -String representation of decimal port number.
    -Example: 3684

---Slide 9---

         Default Values

The network and transport protocols and the network address have
default values if they are not specified in the EPRT command, as
follows.

    Network Protocol - defaults to network protocol used for the
  control connection
    Transport Protocol - defaults to the transport protocol used for
  the control connection
    Network Address - defaults to the network address of the remote
  machine on the control connection

EPRT Examples:
    EPRT IP4|TCP|132.235.1.2|6275
    EPRT |RDP||5282
    EPRT |||6446

---Slide 10---

          Return Codes

Upon receipt of a valid EPRT command, a return code of 200 MUST be
sent.

    This is the same return code sent in response to valid
        PORT commands.

The standard return codes 500 and 501 are sufficient to handle
most errors (e.g., syntax errors).

Two new response codes are needed:
    -522 - network protocol unknown
    -523 - transport protocol unknown

If the remote host does not support either the network or transport
protocol, the error returned should be 522 (invalid network
protocol).

---Slide 11---

      Return Codes (cont.)

The text portion of a 522 or 523 response MUST list the supported
protocols followed by an optional human readable description.

Text response format:
    (prot1,prot2,...,protN) <text for people>

The listed protocols MUST be in the form of the protocol keywords
defined above.

Example responses:
    522 (IP4,IP6) supported network protocols
    523 (TCP) supported transport protocols

---Slide 12---

        EPSV

Allows a machine to request a passive connection be setup using the
extended address format.

The response includes all information needed to setup a data
connection using the EPRT command.

The new response code 229 MUST be returned when entering passive
mode using an extended address.

The text portion of the response MUST be of the following format:
    (<NP>|<TP>|<NA>|<TA>) <text for people>

---Slide 13---

          EPSV (cont.)

The portion enclosed in parenthesis MUST be in the format defined
above for EPRT.

Example response:
    229 (|||6446) Entering Passive Mode

Again, as in EPRT, the <NP>, <TP> and <NA> fields may be omitted to
assume their default values.

The existing standard negative error codes 500 and 501 are
sufficient to handle all errors involving EPSV (e.g., syntax
errors).

---Slide 14---

        Work in Progress

As defined in the draft, FTP using EPSV has a problem.
    -If the response to EPSV contains protocols not supported by the
     machine issuing the EPSV command, no data connection can be
     established.

This problem can be fixed by appending an argument to the EPSV
command that advertises the supported protocols.

Example new EPSV command:
    EPSV IP4,IP6|TCP

---Slide 15---

          Work in Progress (cont.)

The advertisement of one or both protocols is OPTIONAL.
    -If an advertisement is not sent, the host sending the EPSV
     command must be prepared to abort the transfer if the response
     includes an unsupported protocol.
  -The ABOR command followed by a new EPSV command (with an
   advertisement) will need to be sent on the control
   connection.

If the none of the advertised protocols are supported by the host
receiving the EPSV command,  the existing error code 504 (``command
not implemented for that parameter'') MUST be returned.

---Slide 16---

        Security Issues

Using an extended address increases the scope of the FTP ``bounce
attack'' by making it possible to use non-TCP transport protocols to
attack servers.

A companion Internet Draft discusses FTP security issues in more
detail.

======================================================================

FTP Security Slides

---Slide 1---

        FTP Security Considerations

    draft-allman-ftp-sec-consider-01.txt

         April 9, 1997

      Mark Allman and Shawn Ostermann

      {mallman,ostermann}@cs.ohiou.edu

        Ohio University

         http://jarok.cs.ohiou.edu/

---Slide 2---

             Goals

Recommend ways to reduce security problems with FTP.

The draft currently addresses:
    -The ``bounce attack''
    -Restricting access based on network address.
    -Protecting passwords.

---Slide 3---

        Normal 3-Way FTP

Normal 3-way transfer:

    3-WAY FTP FIGURE

---Slide 4---

       The Bounce Attack

Example using FTP to ``attack'' SMTP server on a third machine:

    BOUNCE ATTACK FIGURE

---Slide 5---

    Protecting Against the Bounce Attack

TCP port numbers in the range 0-1023 are reserved for well known
services.

The FTP specification [RFC 959] makes no restrictions on the TCP
port number used for the data connection.

This allows FTP clients to instruct FTP servers to ``attack''
well-known TCP ports on any host on the network.

It is SUGGESTED that servers refuse to open data connections to TCP
ports less than 1024.

---Slide 6---

      Protecting Against the Bounce Attack (cont.)

If a server receives a PORT command containing a TCP port number
less than 1024, the SUGGESTED response code is 504 (``command not
implemented for that parameter'').

Note: This still leaves non-well known servers vulnerable to bounce
attacks.

The companion Internet-Draft and RFC 1639 (FOOBAR) provide
mechanisms to use transport protocols besides TCP.  Similar
precautions should be taken to protect well-known services when
these protocols are used.

---Slide 7---

       Restricted Access

For some FTP servers, it is desireable to restrict access based on
network address.

In such situations, a server SHOULD verify both the remote address
on the data connection and the remote address on the control
connection before transmitting a file.

This protects against the case when the control connection is
established with a trusted host and the data connection is not.

Note that restricting access based on network address leaves a
server vulnerable to ``spoof'' attacks.

---Slide 8---

      Protecting Passwords

To minimize the risk of brute force password guessing through the
FTP server, it is SUGGESTED that servers limit the number of
attempts to send the correct password to a small number (3-5).
    -After 3-5 attempts, the server SHOULD close the control
     connection.

It is also SUGGESTED that FTP servers impose a small delay (5
seconds) before responding to invalid PASS commands.

If available, mechanisms provided by the operating system to
accomplish the above SHOULD be used.

---Slide 9---

        Protecting Passwords (cont.)

It is SUGGESTED that FTP clients and servers use alternate
encryption mechanisms, such as draft-ietf-cat-ftpsec-09.txt, to
prevent eavesdropping.

---Slide 10---

        Work in Progress

Develop a simple and effective way to diminish the chance of port
stealing.

Some suggestions
    -A cookie mechanism.
    -Ensure the TCP port chosen is random.