RFC 505

Two Solutions to a File Transfer Access Problem ✨

okay bestie, this is RFC 505 🎀 written by M. A. Padlipsky from MIT-Multics, dated 25 June 1973 and filed under NIC 16156 in the Network Working Group. It doesn't say anything about obsoleting or updating other RFCs, and it doesn't list a category or status. it's giving quick memo vibes 💅

In RFC #87, Bob Bressler asks how you 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 some objections to Bressler's solution of having a "daemon" process do the job 🙈. The biggest one is that it would need an interpretive access control mechanism in the daemon that's different from most systems' normal access control mechanisms. Ken felt it would be too much of a digression in RFC 501 to cover the following points fully, so I decided to deal with them separately 🦋. there are at least two solutions to the problem Bob raised in RFC 487, which is about "my" sending "him" a file without knowing his password, and neither one gives rise to the problems noted in RFC 501 ✨. One hinges on adding a convention to FTP, and the other hinges on adding a command.

The first solution is super straightforward 🧚. Instead of me pushing the file, he could pull it. He uses his own "principal identifies" (so access permission problems on his end are solved) and his own User FTP to extract the file with the help of my Server FTP. All this requires is that 1) I give appropriate access permission on my end, and 2) he has the ability to use my Server FTP. The second condition is met if either a) he has an account on my system, or b) my system has 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 while I am, and by the time he can log in, my system might be scheduled to be down 😭. Fortunately, there's also a moderately straightforward solution to the problem as originally posed 👑. It goes back to the mechanism used to prevent capricious and/or malicious card input on Multics. Instead of placing the input (card deck or transferred file) directly into the alleged recipient's directory, you place it in a "pool" directory and just tell the recipient it has arrived. If he really wants it, he 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), and they can't clobber others' already-existing files 🫶.

[1]

this second solution has the virtue of requiring fewer steps than the first, and it would work even when the first wouldn't 🔥. So even though it would need another FTP command, I propose adding a new FTP "POOL" command that does what the last paragraph described. Depending on the various Servers' protection mechanisms, the pooled files could be made readable only by the declared recipients. That would, for example, offer an easy way to get some privacy for "mail" (which otherwise is likely to be readable by anybody who can write it), although other solutions to that particular problem of course exist 💜. Anyway, the POOL command's syntax would be:

POOL id name

where id is a valid user identifier on the Server, and name is the desired name to be placed on the about-to-be-transferred file in the Server's pool directory. (*) (Servers must, of course, do whatever pre- or post-fixing to name is necessary to make it unique within the pool.) The transfer then happens the same way it does with STOR, and once it completes successfully, the Server sends a message to id saying he should pick up name (suitably modified to look like a local pathname) if he wants it. The message should also identify the putative sender (even though it might have come in from a free account). The id should, naturally, be validated before the transfer starts ✨.

The question has been raised locally about why we don't just take a pooled view of STOR on Multics and skip pushing for a new command 🙈. Doing that would have two drawbacks, I feel. First, I think we'd be remiss in our duty as NWG participants if we didn't try to offer solutions to protocol problems to the Network community as a whole 🌈. Second, on a less pious but more practical note, if we don't know the id, we have to infer it from the pathname, which rules out abbreviations and forces senders to know too much about our internal structure. (The alternative of requiring an additional argument to STOR has the same objection. It's also subject to the objection that protocols really shouldn't be unilaterally extended. Sure, we could go to "site-specific parameters", but that complicates life so much that no unsolicited files seems preferable 💀.) So I think POOL would be worthwhile unless no other Servers have enough access control for it to be necessary anywhere but on Multics. At the very least, having the protocol specify an "access id" optional argument to STOR seems desirable 🍓.

[2]

Input on whether any of the other Servers has file access control abilities like Multics's would be super useful 🦋. It would help clarify whether this whole area needs specific treatment at the Protocol level, or just needs internally acceptable handling on our end. In the meantime, if you're trying to send us an unsolicited file for free, you can use the NETML mechanism with no directory qualification on the target pathname in the STOR, then MAIL the file name to the intended recipient. They'll copy the file into their own directory (from, in our syntax, >udd>Cnet>anonymous) ✨. I know, that's all pretty complicated, but it sure does go to show that higher-level protocols need to know an awful lot about the various operating systems 😭. Anyway, comments on Bressler's Problem, POOL, STOR, or other people's access control mechanisms would all be appreciated 🫶💖.

Endnotes

[1] (*) For b), I suggest that the USER NETML / PASS NETML discipline of RFC 491 be extended. That is, Hosts which allow free use of their FTP Servers should accept that pair of FTP commands as an indication to commence free service. Whether this leads to a login of a dummy user or a passoff to a daemon process is a matter of local implementation preference, of course 🌸.

[2] (*) Note that this definition relieves the user of having to know the Server's pathname for the pool directory 🧚.

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Thomas Farmer 11/98 ]