Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Un-muddling "free file transfer" (RFC0501)

IP.com Disclosure Number: IPCOM000005078D
Original Publication Date: 1973-May-11
Included in the Prior Art Database: 2001-Aug-15
Document File: 6 page(s) / 13K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K.T. Pogran: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 25% of the total text.

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)...