Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!samsung!dali.cs.montana.edu!ogicse!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.protocols.tcp-ip Subject: Re: RFC 931 "Not Recommended" (Re: Authenticated SMTP, anyone done one?) Message-ID: <29102.Jun1800.35.2891@kramden.acf.nyu.edu> Date: 18 Jun 91 00:35:28 GMT References: <1991Jun14.142800.27168@Daisy.EE.UND.AC.ZA> <6201.Jun1504.10.2091@kramden.acf.nyu.edu> Organization: IR Lines: 90 In article stjohns@umd5.umd.edu (Mike St. Johns) writes: > In article <6201.Jun1504.10.2091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > it does make some sense that Party babies should get ahead... :-) ) > Speaking as both the author of RFC931 and a charter member of the > IETF... AND as a member of the Security Area Advisory Group of the IETF... Da, Comrade, I am suitably impressed vit your qualifikations. You zhould be nominated for ze Central Kommittee tomorrow mornink. (I was kidding, Mike...) > The > functionality of RFC931 was very limited and in any case has been > subsumed by two other very good protocols - KERBEROS and SNMP. I have nothing against Kerberos. I think it's a good start; I even wrote some code for Kerberos v5. But the current implementation simply cannot be used to authenticate, e.g., mail between nyu.edu and umd.edu, at least not without a lot of work. Surely you want some authentication outside your local network? I just heard about SNMP's proposed security mechanism. I don't like it. It's ridiculously vulnerable to known-plaintext, even chosen-plaintext attacks, especially given the stylized format of SNMP output. And it still won't help you outside your local network unless you've exchanged a whole bunch of keys in advance. I agree that RFC 931 doesn't do a whole lot. It just provides usernames. But that's enough to stop what is by far the most common type of mail forgery. > Admittedly, SNMP does not have the MIB variables written to extract > 931 data, but the mechanism is there. But the implementation is not. Any knowledgeable BSD sysadmin can ftp the RFC 931 server source from stealth.acf.nyu.edu in five minutes, compile and install it in ten, and (if he already has sendmail source) add sendmail authentication in five more. If it takes more than five minutes to repeat the whole job on the next several machines, I'll eat my hat. There's only one known incompatibility: Sun gratuitously changed some things in SunOS 4.1.1, so you have to change NETSTATREMOTE to 53 in my source under that system. That's it. How long does it take you, right now, to achieve the same security through SNMP or Kerberos? Hmmm? > If you have a revision, submit it now as an internet draft - send it > to Steve Crocker - Security Area Directory for the IETF > (crocker@tis.com). Okay, I'll continue this via e-mail. > > How seriously should people take the suggestion that experimental > > protocols should not be implemented without coordination with their > > developers? > Answer 1: You mean someone takes that seriously? Uh-oh. > Please take this seriously - its given us great benefits in the past. C'mon, where's your sense of humor? We're only discussing one implementation anyway, and I did talk about it with you beforehand. > Its gratifying to see that someone actually reads the old RFC's, and I > appreciate all the work Dan has put into his implementation, but if I > could put a stake through the heart of 931, I would do it - its just > too limited. It completely stops all username forgeries above the TCP level. To break RFC 931 security means that you have to break TCP security. A typical user, without a machine of his own and without physical network access, has no means to do this. Sure, you can get more mileage out of Kerberos, but where's the Kerberized version of sendmail that I can install later tonight in my sleep? Question to all university sysadmins reading this: How many of you have never watched an undergraduate telnet to your SMTP server and forge a message? How many of you just don't think this is a problem? How many of you wouldn't stop these forgeries if a simple software solution were available? Well, a simple software solution is available: RFC 931. Sure, in two or three years you'll have Kerberos, and in a couple more Kerberos might even work across networks, but don't you want to fix the problem now? My authd doesn't bite: it won't hurt any legitimate applications, and even if you never use it it'll only waste the disk space for one small executable. In the meantime it will raise the ante for mail forgers and system crackers, help CERT track intruders, and give normal users a way to write secure networked applications across diverse machines. Isn't that worth a few minutes of your time? ---Dan