RFC 501

Un-Muddling "Free File Transfer" 🎀 (Part 1 of 2)

okay bestie, the title block first! 💖 This one's by K. Pogran from MIT-Multics, written 11 May 1973, filed as RFC 501 (NIC 15718). The header doesn't list any RFCs it obsoletes or updates, so it's just vibing solo ✨

As the ARPA Network starts to mature 🌸, we keep running into stuff that everyone kinda put off at the beginning. The big ones now are access control, user authentication, and accounting 👀. They pop up because people want uniform ways to give limited "free" access to the File Transfer Servers of host systems, for mail transmission and similar services.

Lots of proposals have floated around with names like "login-less mail", "'free' accounts", "free file transfer", etc. 💅 Every single one comes with a built-in idea of how access control and user authentication work. Those ideas, knowingly or not, assume stuff about how things get implemented, so implementors whose systems work totally differently keep roasting them 😭

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". 🫠 ngl, starting from the very first paragraph, the notions of access controls on files (examples of protection mechanisms) and control of access to the system (user authentication) are thoroughly muddled. He also makes sweeping assumptions about the nature and use of accounting mechanisms and accounts at server sites. RFC 487 has assumptions buried deep inside it too, about the access control and user authentication parts of File Transfer Server implementations.

What's needed right now is a lucid discussion of the general concepts behind 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 maybe enough of a discussion to un-muddle what RFC 487 muddled. The rest will have to come down the pike later.

In lots of systems, the mechanisms that control access to the system, the mechanisms that control access to files, and the accounting mechanisms all mesh at one moment: when a prospective user gets authenticated. The system has checked their user-name, password, account, or whatever, and decided they're a valid user. This user, who would like some information processing performed on his behalf, is called a principal in "privacy and protection" parlance 🧚 Some processes get set up for this principal, and some (presumably unforgeable) principal identifier gets associated with those processes, so their requests for files and other system resources can be properly validated. The identity of the account to be charged for the resources those processes use also gets associated with them at this time [1]. On some systems, though, a process can change its account identifier at any time.

Now the first question: 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, usually with a highly privileged principal identifier. When it acts on behalf of a user, it has to interpretively evaluate that user's access to the file they want, all by itself. It also has to 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 setup, validation of the user's access to files is done 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 that are truly concerned about protection might prefer implementation 2), and for good reason. It follows the "principle of least privilege", which says 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 instead of a system daemon's leaves the system way less susceptible to damage caused by incorrect actions of the File Transfer Server [2].

Next question: who do you charge for file transfers? 💸 Bressler tries to set down some guidelines for deciding who to charge for "non-logged-in" (read: "free") file transfer usage: "Clearly, storing a file in a user's directory can be charged to that user." But how is the word "storing" being used here? Sure, "that user" can be billed for the disk or other storage medium charges for that file now taking up space. But is it legit to charge "that user" for the I/O and/or CPU resources someone else used to transfer a file over the Network and drop it into that user's directory? For example, should the recipient of Network mail get charged for the resources someone else burned sending it? (Would you care to pay the postage for all the junk mail that arrives in your home (U.S. Mail) mailbox?) 📬💀

Over the phone, Bob explained that he wanted a mechanism that would let me, at his request, transfer a file from my system to his directory on his system, without me needing to know his password. All well and good 🥰 In that situation, it would make sense to charge Bressler's account for the transfer. But how does an un-authenticated user tell a server "Charge this to Bressler's account because he says it's OK"? Pitfalls abound. The File Transfer Server process would need to be able to charge an arbitrary user's account, and that presupposes implementation 1) of the File Transfer Server from above. Otherwise any user process in the system would have the capability to charge any user's account, which seems undesirable 🙅‍♀️ A more reasonable approach is to charge that instance of the File Transfer Server process to a general "Network services" account. Mechanisms for doing that are presented in RFC 491 [3].

RFC 487 matter-of-factly suggests that retrieving files from "system" directories should be charged to "overhead". This also makes broad assumptions about the nature of accounting mechanisms and accounts at server sites. Worse, it imposes an undesirable loss of generality on the File Transfer Server, which would now have to be able to tell the pathnames of "system" files apart from those of "user" files. On a number of systems there's no syntactic distinction between the two, and the same general mechanisms can be used to manipulate both kinds of files (if a distinction between them can be made at all). Adding code to the File Transfer Server that examines the pathname of each request to figure out which sort it is seems totally antithetical to the goals of uniformity and generality that many of today's systems have worked so hard for 😤

The statement that a Network user's file transfer activity can be charged to a system-wide "overhead" account contains two assumptions. First, such an account can't be presumed to exist on all systems. Second, even if it does exist, in some cases it just isn't the right account to charge 🤷‍♀️ A good case can be made that the cost of fostering inter-user communication within the ARPA Network community (which is what "free" file transfer amounts to) should be borne by ARPA, meaning that such activity should be charged to ARPA-funded accounts. If a host system's operation is entirely funded by ARPA (or its management doesn't care who pays for this activity), then charging "free" file transfer activity to a "system overhead" account makes sense. On the other hand, that's not the right move for a host system whose operation is not funded by ARPA. Charging "free" file transfers to "system overhead" would pass the cost along to local customers who may have no interest at all in the ARPA Network 😬

Last one: Bressler suggests that for file retrieval, CPU charges "may be sufficiently small to not cause a major problem". To believe this is naivete. 🫣 It may look true on a system that doesn't charge the user for time spent executing supervisor code or I/O routines, where Network software overhead never shows up on the user's bill. In that case, Network software overhead has to contribute to "general system overhead", and everyone has to pay for that. I don't think many people in the Network community would call the actual (as opposed to charged) CPU time spent transferring a file negligible. And if a system is very popular or busy from a Network standpoint, the cumulative CPU time spent on "free" file transfers, looked at the end of an accounting period (a week? a month? a year?), will not be negligible! 📈🔥

In this RFC, I've picked apart Bob Bressler's RFC 487 🧐 mostly because it confuses several distinct (although related) issues, and because its implementation assumptions conflict with, or badly bend out of shape, mechanisms and design philosophies that exist on other systems. The system I know best is Multics [4]. I think the discussion here goes beyond that, though. We have to admit it's hard to propose Network-wide mechanisms for providing desirable services without building in assumptions about how they'll be implemented. We're asking for pretty sophisticated services and proposing correspondingly sophisticated mechanisms. It's time to start talking about how various systems accomplish things like user authentication and access control, so we can all understand these issues better and propose mechanisms with fewer implementation assumptions baked in. that's the whole vibe ✨

END NOTES ✨

[1] On some systems, there is a one-to-one correspondence between principals and accounts.

[2] It's worth noting that systems which choose implementation 2) may require a user authentication sequence (USER, PASS, and possibly ACCT commands) before permitting any file transfers, as explicitly stated on page 17 of RFC 354 (NIC 10596), and page 20 of RFC 4554 (NIC 14333). That authentication sequence would be needed to ascertain the principal identifier to be associated with the newly-spawned File Transfer Server process. The process isn't allowed to proceed until its principal identifier has been established 🔐

[3] okay so there are literally at least two ways Bressler could get his file, and I'm obsessed with how they differ 🧚 Option one: I "push" the file, using my "User FTP" and his system's "FTP Server" 📤. Option two: he "pulls" it, using his "User FTP" and my system's "FTP Server" 📥. Bob went with option one, but ngl, since Bob is the one who wants the file, option two is giving more main character energy 👑. A forthcoming RFC by Mike Padlipsky goes deeper on all of this, plus a totally different alternative 🦋.

[4] Padlipsky keeps saying I've shown that implementation 2) of the File Transfer Server (from above) is the superior one 😭, but I'm not buying it 💅. If you're curious, check out his Unified User-Level Protocol specification 🌸. It's built on a similar premise, so it's a good next read 🫶.

   [ This RFC was put into machine readable form for entry ]
              [ into the online RFC archives by Via Genie]