Un-muddling "free file transfer"
RFC 501

Document Type RFC - Unknown (May 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 501 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          K. Pogran
Request for Comments: 501                                    MIT-Multics
NIC: 15718                                                   11 May 1973

                    Un-Muddling "Free File Transfer"

   As the ARPA Network begin to mature, we find ourselves addressing
   issues and concepts deliberately put off and left untouched at
   earlier stages of Network development.  Among the issues now coming
   to the fore are access control, user authentication, and accounting.
   These issues arise immediately out of efforts to develop uniform
   methods for providing limited "free" access to the File Transfer
   Servers of the host systems, to meet user needs for mail transmission
   and similar services.

   Several proposals have been made, described by such phrases as
   "login-less mail", "'free' accounts", "free file transfer", etc.
   These proposals inevitably have imbedded in them some particular
   notion of how such things as access control and user authentication
   are accomplished and these proposals, which knowingly or unknowingly
   make presumptions about the implementation of such mechanisms,
   inevitably meet with strong criticism from implementors whose
   systems' mechanisms are quite different.

   In RFC 467, Bob Bressler proposes ways of helping out users who wish
   to transfer files to or from "systems which have some flavor of
   security, but on which the user has no access privileges".
   Unfortunately, beginning with the first paragraph of the RFC, the
   notions of access controls on files (examples of protection
   mechanisms), and control of access to the system (user
   authentication) are thoroughly muddled.  In addition, he makes
   sweeping assumptions about the nature and use of accounting
   mechanisms and accounts at server sites.  RFC 487 also has buried
   deep within it assumptions about the nature of the access control and
   user authentication aspects of File Transfer Server implementations.

   What's needed at this juncture, of course, is a lucid discussion of
   the general concepts involved in protection mechanisms, and file
   system access controls in particular.  Well, you won't find that in
   the remainder of this RFC.  What you will find is perhaps enough of a
   discussion to un-muddle that which RFC 487 has muddled; the rest will
   have to come down the pike at a later time.

   In many systems, mechanisms which control access to the system,
   mechanism which control access to files, and accounting mechanisms
   all mesh at the moment at which a prospective user of the system is
   authenticated: the system has checked his user-name, password,

Pogran                                                          [Page 1]
RFC 501             Un-Muddling "Free File Transfer"         11 May 1973

   account, or whatever, and decided that he is, indeed, a valid user of
   the system.  This user, who would like to have some information
   processing performed on his behalf, is termed a principal in "privacy
   and protection" parlance.  Some number of processes are initially set
   up for this principal, and some (presumably unforgeable) principal
   identifier is associated with the process(es), so that their requests
   for access to files and other system resources may be properly
   validated.  In addition, the identify of the account to be charged
   for the resources consumed by these processes is associated with the
   processes at this time [1], although on some systems, a process may
   change its account identifier at any time.

   The first question is: Whose principal identifier does a File
   Transfer Server process use? There are at least two possibilities: 1)
   the File Transfer Server can run as a "system daemon" process, with
   (usually) a highly privileged principal identifier.  When acting on
   behalf of a user, it must, itself, interpretively evaluate that
   user's access to a desired file.  Also, it must be able to charge
   that user's account for the resources it uses.  2) A File Transfer
   Server process can be given the user's own principal identifier.
   With this implementation, validation of the user's access to files is
   performed automatically by the usual file system mechanisms.

   Paragraph four of RFC 487 clearly presumes implementation 1): "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 ..." Systems truly concerned about protection
   may prefer implementation 2), and for good reason -- it follows the
   "principle of least privilege", which states that a process should
   execute with as little access privilege as it requires to perform its
   tasks properly.  Running a File Transfer Server process with a user's
   principal identifier rather than with that of a system daemon leaves
   the system far less susceptible to damage caused by incorrect actions
Show full document text