RFC 505 (rfc505) - Page 1 of 3

Two solutions to a file transfer access problem

Network Working Group                                    M. A. Padlipsky
Request for Comments: 505                                    MIT-Multics
NIC: 16156                                                  25 June 1973


            Two Solutions to a File Transfer Access Problem

   In RFC #87, Bob Bressler raises the issue of how one can use the File
   Transfer Protocol to send a file to a user on another system without
   knowing that user's password.  In RFC 501, Kan Pogran points out
   certain objections to Bressler's solution of having a "daemon"
   process do the job -- in particular, the fact that it would require
   an interpretive access control mechanism in the daemon different from
   most system's normal access control mechanisms.  Because Ken felt
   that it would be too much of a digression in RFC 501 for him to cover
   the following points fully, I decided it might be of interest to deal
   with them separately: There are at least two solutions to the problem
   Bob raised in RFC 487 -- in regard to "my" sending "him" a file
   without knowing his password -- which don't give rise to the problems
   noted in RFC 501.  One hinges on adding a convention to the FTP, the
   other on adding a command.

   The first solution is very straightforward.  Instead of having me
   push the file, he could pull it.  That is, he uses his own "principal
   identifies" (thus solving access permission problems at his end) and
   his own User FTP to extract the file with the aid of my Server FTP.
   All this requires is that 1) I give appropriate access permission on
   my end, and 2) he have the ability to use my Server FTP.  The second
   condition is met by either a) his having an account on my system, or
   b) my system's having a known account for "free" Server FTP use. (*)

   So standing the model on its head solves the functional problem,
   although he has to pay for the User FTP.  But, then, it's he who
   wants the file, so why shouldn't he?  On the other hand, "he" might
   not be logged in right now and I might be -- and by the time he can
   get logged in my system might be scheduled to be down.  Fortunately,
   there's also a moderately straightforward solution to the problem as
   originally posed.  This goes back to the mechanism used to prevent
   capricious and/or malicious card input on Multics: Instead of placing
   input (card deck or transferred file) directly into the alleged
   recipient's directory, place it in a "pool" directory and merely
   inform the recipient of its arrival.  If he really wanted it, he then
   copies it into his own directory.  That way, unauthorized people
   can't freeload on somebody else's directory (and the pool is, of
   course, periodically purged), nor can they clobber others' already-
   existing files.





Padlipsky