Will@cup.portal.com (Will E Estes) (02/07/91)
Can someone briefly discuss any standards that might exist, or be in the process of development, for the sending of secure mail via SMTP or via the Internet. Also, are there any relevant RFCs on this topic? Thanks, Will Estes (apple!cup.portal.com!Will)
leo@unipalm.uucp (E.J. Leoni-Smith) (02/08/91)
Will@cup.portal.com (Will E Estes) writes: >Can someone briefly discuss any standards that might exist, or be >in the process of development, for the sending of secure mail via >SMTP or via the Internet. Also, are there any relevant RFCs on >this topic? >Thanks, >Will Estes (apple!cup.portal.com!Will) Do you mean secure as in - 'I know the guy got it', or secure as in 'if someone else got it they need 20 years on a Cray to decrypt it?' Surely encryption/decryption of data is not a tcp/ip issue? Or is it.
imp@Solbourne.COM (Warner Losh) (02/09/91)
Will@cup.portal.com (Will E Estes) writes: >Can someone briefly discuss any standards that might exist, or be >in the process of development, for the sending of secure mail via >SMTP or via the Internet. Also, are there any relevant RFCs on >this topic? There are a couple of RFC's (1113, 1114, 1115) on something called "Privacy enhancment for Internet electronic mail", which is mail that has been encrypted. There are some provisions for authenticating the sending user, but they are "weak". While there is an account called "root" with all the privs that it has, there will be no way to have "totally secure, authenticated mail". After all, if I wanted to send mail from Joe Hothead to his boss calling him a jerk, then I could su, then su jhothed and flame away. And it could be done w/o a way to trace it back it me (after all, root can nuke accounting files). User authentication is a difficult problem to solve completely. Also, while there are sites on the Internet with older mailers (and can't be upgraded to the latest sendmail since they aren't running Unix), there will be a problem with mailer spoofing. Even with the latest sendmail, I could send mail to Joe's boss as Joe w/o any privs. Or, in other words, you can't trust your mail 100%, since it is relatively easy to forge. However, I encourage all reasonable steps that can be taken to authenticate a connection. There are many hueristics that can be used to detect clumsy forgeries. Warner -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show.
rickert@mp.cs.niu.edu (Neil Rickert) (02/09/91)
In article <1991Feb8.180500.11290@Solbourne.COM> imp@Solbourne.COM (Warner Losh) writes: >While there is an account called "root" with all the privs that it >has, there will be no way to have "totally secure, authenticated >mail". After all, if I wanted to send mail from Joe Hothead to his >boss calling him a jerk, then I could su, then su jhothed and flame >away. And it could be done w/o a way to trace it back it me (after >all, root can nuke accounting files). Forget about root. Sure root can violate privacy. But what does that matter when anybody with a terminal server can telnet to the SMTP port of any host, and start entering an SMTP mail transaction. In this case even the 'Received:' headers won't be of much help in narrowing down the source of the message. If you want 100 percent secure communication, talk face to face with the person intended. Actually, even that is not 100% foolproof, or else there would be little point in having agencies such as the CIA. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
jis@MIT.EDU (Jeffrey I. Schiller) (02/10/91)
Date: 8 Feb 91 18:05:00 GMT From: stan!imp@uunet.uu.net (Warner Losh) Organization: Solbourne Computer, Inc., Longmont, CO References: <38975@cup.portal.com>, <1991Feb8.110317.3949@unipalm.uucp> Sender: tcp-ip-relay@nic.ddn.mil Will@cup.portal.com (Will E Estes) writes: >Can someone briefly discuss any standards that might exist, or be >in the process of development, for the sending of secure mail via >SMTP or via the Internet. Also, are there any relevant RFCs on >this topic? There are a couple of RFC's (1113, 1114, 1115) on something called "Privacy enhancment for Internet electronic mail", which is mail that has been encrypted. There are some provisions for authenticating the sending user, but they are "weak". Actually the provisions for authenticating the sending user are quite strong. Each sender must have a "Certificate" to send privacy enhanced mail. A Certificate is a signed (via public key technology) piece of information that binds the senders name (as an X.500 distinguished name, separate from any concept of "login" name) and their public key. There will be at least three ways of obtaining a Certificate. The direct (and most expensive) way will be to get one issued directly from RSADSI (the company that is managing the authentication hierarchy) for $25.00. This method will also require that you submit a notarized statement of your identity (ie. a Notary Public will have to notarize a piece of paper that you send to RSADSI, testifying that the notary was shown sufficient evidence that you are who you claim to be). The cheaper mechanism (and more efficient one because no paperwork is required) will involve someone in your company acting as an "Organizational Notary" (ON). ONs will vouch for people in the company. However ONs will be under contract to only issue Certificates legitimately. While there is an account called "root" with all the privs that it has, there will be no way to have "totally secure, authenticated mail". After all, if I wanted to send mail from Joe Hothead to his boss calling him a jerk, then I could su, then su jhothed and flame away. And it could be done w/o a way to trace it back it me (after all, root can nuke accounting files). Not quite as easy as that. To send mail as me, will require knowledge of my private encryption key (the "secret" key that corresponds to the public key embedded in my Certificate). In my implementation of Privacy Enhanced Mail, the secret key is stored not only in a file readable only to me, but is also encrypted by a password that only I know. "root" (or others) can still steal my private key, however to do so will require either stealing my keyboard input when I am sending private mail, or otherwise installing a trojan horse in the Privacy Enhanced Mail software to steal my key. Although both of these steps are doable by one who has sufficient privileges and/or skill, it is a *lot* harder then merely "su" and then "su jhothed". User authentication is a difficult problem to solve completely. Also, while there are sites on the Internet with older mailers (and can't be upgraded to the latest sendmail since they aren't running Unix), there will be a problem with mailer spoofing. Even with the latest sendmail, I could send mail to Joe's boss as Joe w/o any privs. Privacy Enhanced Mail is not a function of the mail transport system, it is a step you take prior to sending mail or after having received the mail. My implementation is in fact done as an editing step. First you format your message in an editor, then you transform it to the "enhanced" form and only then do you mail the message. In fact I have a version which is implemented as a UNIX filter. You can pipe the unenhanced message in, and get the enhanced message out. Or, in other words, you can't trust your mail 100%, since it is relatively easy to forge. The goal of privacy enhanced mail is to allow you to trust your mail closer to 100% then to 0%. The whole point is to make it hard to forge. However, I encourage all reasonable steps that can be taken to authenticate a connection. There are many hueristics that can be used to detect clumsy forgeries. The problem with using heuristics is that they often will flag a legitimate message as a forgery! My strategy is to not trust any information provided by the IP layer, as all of it can be forged. The mechanisms in Privacy Enhanced Mail are designed to be trusted, and were designed by people who know their business. -Jeff
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/10/91)
Apologies for the advertisement, but it seems appropriate to point out that I just posted a public-domain RFC 931 implementation under BSD to alt.sources, along with patches to sendmail (5.65, 5.61, et al.) that let you use $F in sendmail.cf for the remote user as per RFC 931. I recommend that you add ``, auth $F'' to one of the Received: lines, preferably the second, as a semi-standard format. Sure, RFC 931 isn't a panacea. But it does turn mail into a secure protocol, provided that TCP is made secure. Any university sysadmin knows that 99% of all sendmail forgers don't have any resources other than a telnet connection. Now we can close that hole for good. authd 3.01 has been reported to work under SunOS 4.0 on a Sun 2/170, SunOS 4.0.3 on a Sun 4/280, SunOS 4.1 on Sun 3/80, 3/160, 3/180, 4/60, and 4/330, Ultrix 4.0 on a DECsystem-5820, Ultrix 4.1 on DECsystem-5820, DECstation-5400, and VAX 8650, BSD 4.3 on some VAX, and Convex UNIX 8.0 on a Convex C210. It does peek in a few kernel data structures, but it seems perfectly portable so far. ---Dan
jis@MIT.EDU (Jeffrey I. Schiller) (02/11/91)
Date: 10 Feb 91 15:07:57 GMT From: kramden.acf.nyu.edu!brnstnd@nyu.edu (Dan Bernstein) Organization: IR References: <1991Feb8.110317.3949@unipalm.uucp>, <1991Feb8.180500.11290@Solbourne.COM>, <1991Feb8.185044.22132@mp.cs.niu.edu> Sender: tcp-ip-relay@nic.ddn.mil ... Sure, RFC 931 isn't a panacea. But it does turn mail into a secure protocol, provided that TCP is made secure. Any university sysadmin knows that 99% of all sendmail forgers don't have any resources other than a telnet connection. Now we can close that hole for good. I wouldn't go so far as to say it makes mail a "secure" protocol. Though it does help. However for it to be really useful, all the mail relays between sender and receiver need to implement it. This is not only unlikely, but is also beyond the control of the individual sender and receiver. Furthermore even if all the hosts on the Internet adopted it tomorrow, you still need to trust the administrations of all the way points your mail is relayed through. This doesn't lend itself well to anything but the weakest definition of the term "authentication." The Privacy Enhanced Mail RFCs (sorry to sound like a salesman myself here!) define an end-to-end mechanism exactly so that sender and recipient need have no trust in the intermediate mail relays (and no requirements on the software that they run). This permits me for example to route an encrypted, signed mail message to you via Iraq and the Soviet Union and when you receive it (if you receive it, but that is a different problem :-) ) know that only you can decrypt its contents and also know that only I could have originated the message. -Jeff
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/12/91)
In article <9102102022.AA26112@osiris.MIT.EDU> jis@MIT.EDU (Jeffrey I. Schiller) writes: [ RFC 931 ] > I wouldn't go so far as to say it makes mail a "secure" protocol. But it does---again, provided that TCP is made secure. The problem until now is that mail introduced its own security holes over and above those of TCP: it didn't even try to verify the remote username. Now at least we can reduce the problem to TCP. > However for it to be really useful, all the mail relays > between sender and receiver need to implement it. I'm not convinced that this is such a problem. The Internet mail I send rarely goes through more than three hops: nyu.edu, bar.com, foo.bar.com. If sending organization and receiving organization support RFC 931, that's enough. > The Privacy Enhanced Mail RFCs (sorry to sound like a salesman myself > here!) define an end-to-end mechanism exactly so that sender and > recipient need have no trust in the intermediate mail relays (and no > requirements on the software that they run). I have no objection to end-to-end security (although I don't like the current fashion of putting it into every single protocol instead of making the link level secure). But we don't have the software yet. I also hope that if NYU decides to spend any money on RSA Inc., it starts by putting a few thousand dollars into challenging the RSA patent. Furthermore, mail encryption doesn't do anything for news, telnet, rlogin, talk, or any of the other services people use. RFC 931 helps all of them the same way it helps mail. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/13/91)
In article <1991Feb12.135915.1@rogue.llnl.gov> oberman@rogue.llnl.gov writes: [ RFC 931 doesn't help him, and it doesn't help on any non-TCP/IP net ] > I do think it's a bad idea to espouse a method because "it will be good enough > for me". A real solution should be good enough for everyone. Dave Borman told me the same thing about RFC 1143. ``It isn't the only way to stop TELNET's option negotiation loops,'' he said (paraphrased), ``and I don't like its approach. So it must not become a standard.'' There's one missing step. Why does a solution have to be perfect for everyone? Why can't all solutions be published in parallel? People who like one solution will use it. People who like another will use that. I've never said that RFC 1143 is the *only* way to fix TELNET, and I'm not saying now that RFC 931 is the *only* way to improve mail security. RFC 931 would, however, prevent many---if not most---of the SMTP forgeries that go on now. So it is worthwhile for many Internet sites, even if not for LLNL or BITNET or the United States Postal Service. Below is a typescript of compiling, installing, and testing authd 3.01 on a Sun 4. Sure, RFC 931 is limited to the Internet. Sure, RFC 931 doesn't fix TCP's security holes. But it's a damn sight better than nothing, it's hellishly easy to get going, it helps Internet security for more than just mail, it will help CERT track network intruders, and I don't understand the mindset of anyone who would recommend that it *not* be installed. (For the people who don't get alt.sources, I've made authd 3.01, my sendmail and talk patches, and Nick Sayer's nntpd patches available for anonymous ftp from 128.122.128.22 in pub/hier/inet/rfc931. More coming.) ---Dan Script started on Wed Feb 13 10:05:04 1991 csh> make cc -g -o authd authd.c rm -f tcpuid ln authd tcpuid rm -f tcpuname ln authd tcpuname cc -g -c authuser.c cc -g -o test test.c authuser.o csh> ./INSTALL Each action will be printed before it is run. Press return to proceed. 1. Install authd, tcpuid, and tcpuname. ! install -c -g kmem -m 02755 authd /etc/authd: ! rm -f /etc/tcpuid; ln /etc/authd /etc/tcpuid: ! rm -f /etc/tcpuname; ln /etc/authd /etc/tcpuname: 2. Install the authuser library. ! install -c -m 0444 authuser.h /usr/include/authuser.h: ! ar rv /usr/lib/libauthuser.a authuser.o: r - authuser.o ! ranlib /usr/lib/libauthuser.a: ! chmod 644 /usr/lib/libauthuser.a: 3. Make the man pages available. ! install -c -m 0444 authuser.3 /usr/man/man3/authuser.3: ! install -c -m 0444 authd.8 /usr/man/man8/authd.8: ! install -c -m 0444 tcpuid.8 /usr/man/man8/tcpuid.8: ! install -c -m 0444 tcpuname.8 /usr/man/man8/tcpuname.8: 4. Make sure an auth port is in /etc/services. Let me glance at /etc/services for you... Okay, you have it already. Let's continue. 5. Enable auth in /etc/inetd.conf. Let me glance at /etc/inetd.conf for you... Okay, it's already there. That's it! csh> ./test system says host is 127.0.0.1 authuser says host is 127.0.0.1 system says username is root authd says username is root Everything looks okay to me. csh> exit csh> script done on Wed Feb 13 10:05:50 1991
kasten@europa.clearpoint.COM (Frank Kastenholz) (02/16/91)
> From tcp-ip-RELAY@NIC.DDN.MIL Fri Feb 15 01:02:31 1991 > From: portal!cup.portal.com!Will@apple.com (Will E Estes) > Organization: The Portal System (TM) > Subject: Are There Standards For Secure Mail Transfer Via SMTP? > Sender: tcp-ip-relay@nic.ddn.mil > To: tcp-ip@nic.ddn.mil > > Can someone briefly discuss any standards that might exist, or be > in the process of development, for the sending of secure mail via > SMTP or via the Internet. Also, are there any relevant RFCs on > this topic? > > Thanks, > Will Estes (apple!cup.portal.com!Will) > Will, Try the following RFC's Frank Kastenholz Clearpoint Research ------- 1115 Linn, J. Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers [Draft]. 1989 August; 8 p. (Format: TXT=18226 bytes) 1114 Kent, S.T.; Linn, J. Privacy enhancement for Internet electronic mail: Part II - certificate-based key management [Draft]. 1989 August; 25 p. (Format: TXT=69661 bytes) 1113 Linn, J. Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures [Draft]. 1989 August; 34 p. (Format: TXT=89293 bytes) (Obsoletes RFC 989, RFC 1040)