barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett) (06/14/91)
In article <17169:Jun1122:04:5791@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > RFC 931, the Authentication Server, provides enough additional security > to stop those pesky undergraduates from forging mail (at least without a > network machine of their own). You can get my implementation of RFC 931 > for BSD machines in stealth.acf.nyu.edu:pub/hier/inet/rfc931/authd.3.01. > You can make sendmail (5.61, 5.65, possibly others) understand RFC 931 > by applying sendmail-patches-djb, available from the same place; after > the patch, $F in an H line in sendmail.cf will print the remote user > name for any SMTP connection. I could find only two references to authentication protocols in RFC1200, and both are marked "Experimental" and "Not Recommended". Why? How seriously should people take the suggestion that experimental protocols should not be implemented without coordination with their developers? " Network Working Group Internet Activities Board " Request for Comments: 1200 J. Postel, Editor " Obsoletes: RFCs 1140, April 1991 " 1100, 1083, 1130 " " " " IAB OFFICIAL PROTOCOL STANDARDS " " [...] " " 4.1.4. Experimental Protocol " " A system should not implement an experimental protocol unless it " is participating in the experiment and has coordinated its use of " the protocol with the developer of the protocol. " " [...] " " 4.2.5. Not Recommended Protocol " " These protocols are not recommended for general use. This may be " because of their limited functionality, specialized nature, or " experimental or historic state. " " [...] " " 6.6. Experimental Protocols " " Protocol Name Status RFC " ======== ===================================== =============== ==== " [...] " COOKIE-JAR Authentication Scheme Not Recommended 1004 " [...] " AUTH Authentication Service Not Recommended 931 " [...] --apb Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa RFC822: barrett@ee.und.ac.za Bang: m2xenix!quagga!undeed!barrett
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/15/91)
In article <1991Jun14.142800.27168@Daisy.EE.UND.AC.ZA> barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett) writes: > I could find only two references to authentication protocols in RFC1200, > and both are marked "Experimental" and "Not Recommended". Why? Basically, because they haven't been widely enough field-tested. (This requirement rarely applies to the pet protocols of established IETFers; it does make some sense that Party babies should get ahead... :-) ) As soon as some vendor adopts any RFC 931 code, I'll submit my revision of the RFC and propose that it advance in status. > 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. Answer 2: I hereby extend to all current and prospective users of RFC 931 this offer to become part of My Experiment. Of course, My Experiment does not require anyone's active participation, as it is a low-profile, long-term project. In fact, it's so low-profile that you shouldn't even bother letting me know that you're part of it. Just use the code. :-) Seriously, I am conducting a large-scale Internet survey, to see how many hosts on the directly connected net support various TCP protocols, including RFC 931. This should provide an interesting alternative (old-fashioned, I guess) viewpoint to the recursive DNS searches currently in vogue. ---Dan
stjohns@umd5.umd.edu (Mike St. Johns) (06/17/91)
In article <6201.Jun1504.10.2091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: In article <1991Jun14.142800.27168@Daisy.EE.UND.AC.ZA> barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett) writes: > I could find only two references to authentication protocols in RFC1200, > and both are marked "Experimental" and "Not Recommended". Why? Basically, because they haven't been widely enough field-tested. (This requirement rarely applies to the pet protocols of established IETFers; 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... I wrote RFC931 as an experiment and an exercise in writing an RFC back in the days when there weren't as many being published. The functionality of RFC931 was very limited and in any case has been subsumed by two other very good protocols - KERBEROS and SNMP. Kerberos provides a much better authentication mechanism while SNMP provides the mechanism for retrieving general data from a host. Admittedly, SNMP does not have the MIB variables written to extract 931 data, but the mechanism is there. Given a choice, I'd rather have someone write an experimental MIB covering user data than implement 931. As soon as some vendor adopts any RFC 931 code, I'll submit my revision of the RFC and propose that it advance in status. 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). Almost anything can enter the standards track - RFC931 could enter today as a Proposed Standard - no experience with the protocol is necessare for this step. > 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. Instead of 5 virtually identical but non-interoperable transport protocols (ala OSI) we have 2, each with a distinct category of service. 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. Mike
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/18/91)
In article <STJOHNS.91Jun16205511@umd5.umd.edu> 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
blknowle@frodo.JDSSC.DCA.MIL (Brad L. Knowles) (06/19/91)
Mike, Dan, and any others who might be interested,
Please do not interpret this as a flame, but somehow I get the
impression that you are on opposite sides of the fence on this issue (no
matter what kind of friends you may be), and I think it's about time we
let the issue drop.
I am perfectly well interested in RFC implementations, no matter what
the status of the RFC, as well as the status of upcoming RFCs that may
well obsolete previous ones. However, the argument of Kerberos/SNMP vs.
RFC 931 seems to be getting more emotional than rational.
For my own part, I will ftp the source for the RFC 931 implementation,
if only to look at it. I will also take a long look at any upcoming
network security RFCs or software (like Kerberos or the security features
of SNMP), because that is part of my job. I think you agree on the goal,
but not how to get there (which is precisely the problem the Soviet Union
and the U.S. have had historically, as well as any other relatively large
country I know of).
________________________________________________________________________
| Brad Knowles | Internet: blknowle@frodo.jdssc.dca.mil |
| DISA/DSSO/JNSL | Ph: (703) 693-5849 Fax: (703) 693-7329 |
| The Pentagon, Room BE685 |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|
| Washington, D.C. 20301-7010 | Speaking from, not for DISA (nee DCA) |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~