RFC 487 UNKNOWN FTP · ACCESS CONTROL

FTP: Free file transfer

A proposal for allowing FTP access to files marked as available to everyone.

On rfc-editor.org ↗
PUBLISHED
April 1973
AUTHORS
R.D. Bressler
STREAM
Legacy
ACCESS LEVELS DESCRIBED
3 (user, group, everyone)
POSSIBLE USER NAMES
FREE or ANONYMOUS
DOI
10.17487/RFC0487

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                       Bob Bressler
Request for Comments #487                                   BBN
NIC #15065                                                  6 April 1973


                           Free File Transfer


    In the past several months, many people have commented to me about
their difficulty in transferring files.  The hang up appears to be with
systems that have some flavor of security, but on which the user has no
access privileges.  Specifically, the FTP server demands a user and
password before it will grant any system access.  The loophole which
people have been using is the MAIL FILE facility, which is both limited
in scope and intended for other purposes.

    A frequently used model for file protection is to define three
levels of user access:  1) only the user himself; 2) all users in a
group; 3) everyone.  Up until now, "everyone" has meant anyone already
granted logon privileges.  A new class is, perhaps, needed to cover
everyone, exclusive of whether or not they are logged on.

    With all this in mind, I propose the following course of action:

    If a user connects to an FTP server and makes a file request without
supplying a user name-password, the server should then examine the file
access parameters.  If the file is listed as accessible to anyone, then
the transfer should be allowed to proceed.

    This scheme can be implemented so as not to yield file creations
privileges - for example, store commands can be implemented via an
append mechanism.  If I wanted a file sent to me I could create an empty
file with unlimited append access.  I would then inform the foreign user
to store (append?) to that file.

    The problem of accounting is somewhat more complex.  Clearly,
storing a file in a user's directory can be charged to that user.  When
retrieving a file from a general system directory, there is no "user"
specified, and overhead may have to be billed.  The former case involved
both CPU time for transfer and secondary storage charges for storing the
new file.  In the latter case, only CPU charges are involved, and these
may be sufficiently small to not cause a major problem.

    BBN TENEX has agreed to modify their FTP server to allow general
access transfers as described above.  Specific details for usage will be
available when installation is complete.  I urge other systems to make
this service available, if only on an experimental basis.  The success
of such an experiment will be judged by the reaction of the general user

community and the uses to which FTP is put.





NOTE:  Bob Clements tells me that the BBN TENEX implementation will
       probably require a user name of something like "FREE" or
       "ANONYMOUS", but not require a password.

RB/jm










       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.             9/99 ]

ISO Plain Language

On this page
PROBLEMFTP servers often required a user name and password even when a person wanted a file without having an account on that host.
MECHANISMThe proposal asks a server to check a file's access settings when a request has no user name or password, and allow transfer if the file is marked accessible to anyone.
THE PROPOSALThe RFC says BBN TENEX agreed to modify its FTP server and urges other systems to try the service experimentally.

§1Why FTP Access Was a Problem

Bob Bressler says users had difficulty transferring files from systems with security controls when they did not have access privileges. FTP servers required a user name and password before granting system access, so a person without an account could not request an otherwise accessible file.

The memo says people were using the FTP MAIL FILE facility as a workaround, although that facility was limited and intended for other purposes.

A server could require a login even when someone only wanted a file available to everyone. The author says users were using the mail feature as a workaround.

§1Access for Everyone

The RFC describes a common file protection model with access for an individual user, a group, or everyone. It proposes defining “everyone” to include people who are not logged in.

Under the proposal, a request without a user name and password causes the FTP server to examine the file's access parameters. If those parameters say the file is accessible to anyone, the transfer should proceed. The memo says the scheme need not grant file-creation privileges and gives an example of receiving a file by appending to an empty file that has unlimited append access.

The server checks the file's access setting rather than requiring an account for every request. The proposal separates permission to retrieve an open file from permission to create files.

§1Accounting and the Suggested Trial

The RFC notes that accounting is harder when a file is retrieved from a general system directory because there is no particular user to charge. It says retrieval involves CPU costs, while storing a file in a user's directory also involves secondary-storage charges.

BBN TENEX agreed to modify its FTP server. A note says the implementation would probably require a user name such as FREE or ANONYMOUS but no password. The author urges other systems to offer the service experimentally and says its success should be judged by user response and how FTP is used.

The proposal recognizes that a site may need to account for the cost of public retrievals. It asks systems to try the idea and judge it by users' responses and use.