randall@uvaarpa.virginia.edu (Randall Atkinson) (10/26/89)
In article <8910251138.AA11562@alw.nih.gov> RAF@CU.NIH.GOV ("Roger Fajman") writes: >I wish the Internet had BITNET-style sender-initiated file transfer >that did not require the sender to know the receiver's password. It's >very convenient. Sending files as email is not very user friendly. The ability of some arbitrary user elsewhere on a network I'm connected to to put files in my account without (at least) password protection is a security hole. I'm glad my systems aren't directly connected to BITNET. ftp and sending files as mail do work, though I concede a better user interface could be devised if someone had the time (I don't). By the way, those of you running a sendmail that has a "decode" alias built-in (as I gather a number of popular workstations do) may well want to remove it. An acquaintance at a workstation firm tried to mail some font files to me using "decode@domain" and was startled that my systems have that disabled and apparently hadn't realised what a security hole it can be... Regrettably security isn't something most vendors have been paying much attention to until just now and the continuing problems with DECnet virii and worms and the infamous Internet worm seem to have had limited impact on most folks... Ran randall@virginia.EDU
OWEN@DUCVAX.AUBURN.EDU (Larry Owen) (10/26/89)
>>I wish the Internet had BITNET-style sender-initiated file transfer >>that did not require the sender to know the receiver's password. It's >>very convenient. Sending files as email is not very user friendly. >The ability of some arbitrary user elsewhere on a network I'm connected >to to put files in my account without (at least) password protection >is a security hole. I'm glad my systems aren't directly connected to BITNET. This may be the first (or the tenth!) of a series of similar responses, but: Just in case this misconception is shared by many others, files sent over Bitnet (at least on most operating systems) don't go in your directory. You have to actively receive the files from a holding area into your directory. This does not present a security hole. Larry Owen Mgr., Network Support Technical Support Services Auburn University Bitnet: owen@auducvax Internet: owen@ducvax.auburn.edu
jqj@RT-JQJ.STANFORD.EDU (JQ Johnson) (10/26/89)
>>I wish the Internet had BITNET-style sender-initiated file transfer >The ability of some arbitrary user elsewhere on a network I'm connected >to to put files in my account without (at least) password protection >is a security hole. This BITNET feature is usually implemented as writing the files to a remote spool area where disk space is charged to the system rather than the target user, and the target user may retrieve the files or not within some reasonable time. As such, it is not any more a security hole than the ability to send electronic mail to /usr/spool/$USER. The key feature that it has which SMTP-based email lacks is a standard (sort of) for sending non-textual data. X.400 with its provision for arbitrary binary attachments may make this BITNET feature obsolete. But Internet-only users should not be so narrowminded as to think that ftp is the "one true way" to manage file transfer! As Ran remarks, security is a problem on the Internet. One might argue that it is less of a problem on BITNET because the BITNET world developed from the paranoid computing-center-production-IBM-mainframe environment rather than the casual departmental-Unix-workstation environment. JQ Johnson voice: 415-723-3078 Manager, Special Projects Internet: jqj@jessica.stanford.edu Networking and Communications Systems Pine Hall Rm 125-A Stanford University Stanford, CA 94305-4122
ittai@SHEMESH.GBA.NYU.EDU (Ittai Hershman) (10/27/89)
>I wish the Internet had BITNET-style sender-initiated file transfer >that did not require the sender to know the receiver's password. It's >very convenient. Sending files as email is not very user friendly. The ability of some arbitrary user elsewhere on a network I'm connected to to put files in my account without (at least) password protection is a security hole. I'm glad my systems aren't directly connected to BITNET. ftp and sending files as mail do work, though I concede a better user interface could be devised if someone had the time (I don't). I manage a site with both BITnet and Internet connections. I have never held BITnet in high esteem (on a technical level), but I have changed my view on this subject. There are many legitimate cases where sender-initiated file transfer is warranted. The one that comes most quickly to mind, is the case where two (or more) researchers are collaborating on a paper and need to send drafts back and forth; they are also working on other papers and therefore do not want to swap password information. On the Internet, this basically leaves them at the mercy of using e-mail. And not all e-mail UA's are capable of being used as file-transfer utilities. While not perfect, and decidedly implemented for brain damaged reasons, the BITnet service is adaptable at low risk. The security mechanism is quite simple -- all sender-initiated file transfers are collected in a spool directory, and users run a "RECEIVE" utility (a la Joiner's JNET implementation of RSCS for VMS) to actually bring the file into their directory. The spool area then becomes a DMZ, no more risky than anonymous FTP. Yes, I agree this is not optimal. Yes, I agree that this service could be abused. I think, though, that this would be a terribly useful service to add until such a time when a more elegant solution is found. -Ittai
RAF@CU.NIH.GOV ("Roger Fajman") (10/28/89)
> >I wish the Internet had BITNET-style sender-initiated file transfer > >that did not require the sender to know the receiver's password. It's > >very convenient. Sending files as email is not very user friendly. > > The ability of some arbitrary user elsewhere on a network I'm connected > to to put files in my account without (at least) password protection > is a security hole. I'm glad my systems aren't directly connected to BITNET. > > ftp and sending files as mail do work, though I concede a better user > interface could be devised if someone had the time (I don't). You misunderstand the way that BITNET file transfer works. While it's up to the implementor, the general rule is that incoming files are stored on spool or in some other temporary area. The receiving user is notified that a file is waiting for him. He then is able to decide to accept or reject the file. If he accepts it, he generally is able to rename it before it is stored in his own area. Thus there is no security loophole. The whole business is analogous to mail. The difference is in the user interface at each end. A file to be sent is not composed on the spot and a file to be received is not displayed on the user's screen (except upon request). Files can be text or binary data. The fact that people often UUENCODE files and send them as mail shows that the desire for this type of file transfer is out there. I've heard it said that the space required to store temporary copies of tranfered files would be prohibitive. BITNET sites generally do not find that to be so. Anyway, the space is being used anyway when the files are being sent as mail.
smart@ditmela.oz (Robert Smart) (10/28/89)
In Australia there is a network, ACSnet, running Australian software which also supports sender initiated file transfer in exactly the same style as BITNET. It also has a batch-style equivalent of anonymous ftp, called getfile. These capabilities seem extremely valuable. Many people expect that ACSnet will continue to run over TCP/IP when Australia has a real Australia-wide IP network, just to provide these capabilities. Yet these capabilities could easily be implemented on top of TCP/IP. I wish someone would do it. Bob Smart
chris@CS.UMD.EDU (Chris Torek) (10/29/89)
>From: jqj@rt-jqj.Stanford.EDU (JQ Johnson) > >This ... is usually implemented as writing the files to a remote spool >area where disk space is charged to the system rather than the target >user, and the target user may retrieve the files or not within some >reasonable time. ... The key feature that it has which SMTP-based email >lacks is a standard (sort of) for sending non-textual data. X.400 with >its provision for arbitrary binary attachments may make this BITNET >feature obsolete. But Internet-only users should not be so >narrowminded as to think that ftp is the "one true way" to manage file >transfer! % ftp remotehost.biguniv.edu <greeting stuff> User: anonymous Password: me@here <restriction stuff> type image <image mode OK> put local-file incoming/remote-file <file goes across> quit Now all we need is to write it up as an RFC (changing the `put local-file incoming/remote-file' sequence to a new `give' command, so that the `incoming/' can go away), and write a front end called `give' or whatever that does the above automatically. Hosts can expire stuff in ~ftp/incoming, or whatever they name this spool directory, as often as desired. In other words, we need only one change to the FTP protocol (to add a command that means `I am sending you a file that you should put in your spool directory, whatever its name may be'), along with some front ends so that `given' files are handled much like mail: spooled on the local machine until the transfer can happen. -- `They were supposed to be green.' In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
barmar@kulla (Barry Margolin) (10/29/89)
BITNET-style file transfer is easily accomplished using FTP. Many FTP
servers support anonymous FTP, which generally restricts the user to a
subset of the file system (on Unix it's generally a particular subtree, on
TOPS-20 it's world-accessible directories). Sender-initiated file transfer
is done by using FTP to put the file into a directory to which anonymous
FTP has write access, then sending mail to the recipient telling him the
file's name.
Some BITNET hosts may provide better access control over the spool area
than the above, because the protocol includes the recipient's name and it
can distinguish writable spool areas from readable spool areas. But for
many purposes the above mechanism is adequate.
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar