mleech@bnr.ca (Marcus Leech) (06/03/91)
Has anyone done an authenticated SMTP, and if so, is there an RFC in existence that describes it? What I have in mind is something like the following: Assume that there's a secure/authenticated channel between the User Agent and the MTA (sendmail or its equivalent). When the MTA establishes a connection to another SMTP MTA, that MTA issues a "challenge" or something to authenticate the transaction. Anyone done one? I realize that this breaks the existing SMTP philosophy of allowing any SMTP to connect to any other. I'm thinking of corporate internets, rather than "the INTERNET". -- Marcus Leech, 4Y11 Bell-Northern Research |opinions expressed mleech@bnr.ca P.O. Box 3511, Stn. C |are my own, and not VE3MDL@VE3JF.ON.CAN.NA Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/12/91)
In article <1991Jun3.163841.4114@bwdls61.bnr.ca> mleech@bnr.ca (Marcus Leech) writes: > Has anyone done an authenticated SMTP, and if so, is there an RFC in > existence that describes it? 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 realize that this breaks the existing SMTP philosophy of allowing any > SMTP to connect to any other. I'm thinking of corporate internets, rather > than "the INTERNET". RFC 931 can be used over any part of the Internet. In fact, it's the only working freely available wide-area TCP authentication code I know of. If you do want to restrict access to the local net or to authenticated connections, you can use my attachport (comp.sources.unix volume 22) or shuctld (coming very soon to a source group near you). ---Dan
Will@cup.portal.com (Will E Estes) (06/13/91)
<RFC 931 can be used over any part of the Internet. In fact, it's the
<only working freely available wide-area TCP authentication code I know
<of. If you do want to restrict access to the local net or to
<authenticated connections, you can use my attachport (comp.sources.unix
<volume 22) or shuctld (coming very soon to a source group near you).
Then what is the purpose of RFCs 1113, 1114, and 1115 on Privacy
Enhanced Mail (PEM)? My understanding was that this service was going
into effect very soon throughout the Internet.
Maybe someone with more knowledge on these subjects could clarify
the following issues:
1) Does PEM address all of the security and authorization issues for
sending mail on the Internet?
2) Is PEM the preferred approach for building security into private
company Internets as well?
Thanks,
Will Estes Internet: Will@cup.portal.com
UUCP: apple!cup.portal.com!Willhughes@logos.ucs.indiana.edu (larry hughes) (06/14/91)
In article <43225@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >Then what is the purpose of RFCs 1113, 1114, and 1115 on Privacy >Enhanced Mail (PEM)? My understanding was that this service was going >into effect very soon throughout the Internet. PEM is basically plain ol' SMTP mail, but the message text is RSA encrypted for transmission over the net. You have to have an encrytor on your end, and the other end has to have a decryptor. Its use is strictly voluntary, and unless both sender and recipient implement it, it's not very useful. >Maybe someone with more knowledge on these subjects could clarify >the following issues: > >1) Does PEM address all of the security and authorization issues for >sending mail on the Internet? No, PEM for example does not solve mail forging, for example. Again, it simply encrypts (presumably sensitive) mail text. //=========================================================================\\ || Larry J. Hughes, Jr. || hughes@indiana.edu || || Indiana University || || || University Computing Services || "The person who knows everything || || 750 N. State Road 46 Bypass || has a lot to learn." || || Bloomington, IN 47405 || || || (812) 855-9255 || Disclaimer: Same as my quote... || \\==========================================================================//
imp@solbourne.com (Warner Losh) (06/14/91)
In article <1991Jun13.222559.7574@bronze.ucs.indiana.edu> hughes@logos.ucs.indiana.edu (larry hughes) writes: >[PEM's] use is strictly voluntary, and unless both sender and recipient >implement it, it's not very useful. So is RFC 931. RFC 931 is on more hosts than PEM. There are a LARGE number of hosts that don't use RFC 931. Warner -- Warner Losh imp@Solbourne.COM Free to a good home: 10,000 Miller Moths. Must promise not to breed them.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/15/91)
In article <43225@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: > <RFC 931 can be used over any part of the Internet. In fact, it's the > <only working freely available wide-area TCP authentication code I know > <of. If you do want to restrict access to the local net or to > <authenticated connections, you can use my attachport (comp.sources.unix > <volume 22) or shuctld (coming very soon to a source group near you). > Then what is the purpose of RFCs 1113, 1114, and 1115 on Privacy > Enhanced Mail (PEM)? PEM is not, and for the next several years will not be, a freely available system. It also is not a link-level SMTP authentication protocol, as the original poster was asking for; it is an end-to-end privacy protocol. However wondeful PEM might be, it is not available now, in a form that works on most machines on the Internet. RFC 931 is, in a tiny package with every compile/install step completely automated. Basically, you can put RFC 931 on a BSD mail server now. For free. If you apply the sendmail patch, every mail message coming through the system will be marked with a username with at least as much security as the IP address in every packet. Your users won't notice the change, but you'll suddenly be able to trace forgeries much more easily---or you can just chop all forgeries tomorrow morning. None of this is true of PEM. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/15/91)
In article <1991Jun14.053704.1059@solbourne.com> imp@solbourne.com (Warner Losh) writes: > In article <1991Jun13.222559.7574@bronze.ucs.indiana.edu> hughes@logos.ucs.indiana.edu (larry hughes) writes: > >[PEM's] use is strictly voluntary, and unless both sender and recipient > >implement it, it's not very useful. > So is RFC 931. RFC 931 is on more hosts than PEM. There are a LARGE > number of hosts that don't use RFC 931. Sure, but the beauty of a link-level security protocol is that you can add it in bits and pieces. If you add RFC 931 support at just one mail exchanger, you've suddenly made every message through that exchanger a bit more secure. If a year from now someone's message happens to wend its way through several RFC 931 sites, forgeries are suddenly that much more difficult. It would help if more vendors supported RFC 931. I've offered my implementation (as well as the sendmail and talk patches) to Sun and Berkeley, but they don't seem to understand how it's better than Kerberos. (Two answers: immediate availability of a simple, working implementation; wide-area network support.) I'd love to help people add RFC 931 support to their programs; I'm happy to report that the new ftpd release from Chris Myers will include RFC 931 authentication as an option. ---Dan
kent@BBN.COM (Steve Kent) (06/18/91)
Larry, A few comments in response to our recent message about PEM and what facilities it provides: - PEM operates in conjunction with SMTP and RFC 822 mail. It is compatible with both and thus can be used to protect any RFC 822 message that can be sent via SMTP mail relays. Use of PEM is strictly voluntary; only Internet users who want the security services of PEM are expected to make use of it and, as you observed, it takes two to tango. - Your description of PEM security services and mechanisms was a bit short and not quite accurate. PEM uses DES, not RSA, to encrypt messages, but encryption is optional. PEM uses computes a message integrity check (MIC) on each message and encrypts it to provide message integrity and authenticity. The integrity and authentication functions are not optional, i.e., they are always employed. The version of PEM that we expect to be widely used employs RSA keys both to encrypt the MIC (for authenticity, integrity and a basis for non-repudiation) and to encrypt the DES key in support of confidentiality (secrecy). A key management infrastructure, based on the CCITT/ISO Directory authentication standards (X.509) is used by PEM to support distribution of the RSA keys. - A sender of a PEM-protected message can ensure that the message content is decipherable only by the intended recipients and that each recipient can verify the message inetgrity and the sender ID. PEM does not address directly more subtle confidentiality issues, e.g., traffic analysis, though "double-enveloping" can be employed to mitigate this threat as well. I hope this clarifies the issue of "what PEM does." As for timing, those of use working on the PEM standards are behind schedule, as noted. Three RFCs were issued almost 2 years ago and we are now trying to get revised standards out this summer. Several independent implementations of PEM are now undergoing testing on the Internet and arrangements for the key management infrastructure are progressing. The latter work includes a numer of activities, e.g., license agreements with RSA to enable a PEM freeware implementation to be made available and interoperable with product-level PEM implementations in the Internet. The bottom line on RSA licenses for PEM is that they are expected to be quite cheap, as little $2.50 per-user (maybe even less for students), if the keys are locally managed (by the school, company, or whatever organization with which the user is affiliated). I recommed you review the existing RFCs (1113-1115), or the Internet-Drafts which will replace them, for more info on PEM. Steve Kent Chair Internet Privacy and Security Research Group
ggm@brolga.cc.uq.oz.au (George Michaelson) (06/18/91)
kent@BBN.COM (Steve Kent) writes: > ..... ....... ....... ....... ....... ...... Several independent >implementations of PEM are now undergoing testing on the Internet and >arrangements for the key management infrastructure are progressing. >The latter work includes a numer of activities, e.g., license >agreements with RSA to enable a PEM freeware implementation to be made >available and interoperable with product-level PEM implementations in >the Internet. The bottom line on RSA licenses for PEM is that they >are expected to be quite cheap, as little $2.50 per-user (maybe even >less for students), if the keys are locally managed (by the school, >company, or whatever organization with which the user is affiliated). And what arrangements are being made to legalize and manage distribution of keys in the "Internet-at-large" that lies outside the US, such as the national and regional networks of Australasia, the Pacific rim, Scandanavia, Europe, etc etc etc. Who, if anybody is going to licence and distribute PEM keys to bodies outside of the RSA patent area? Will PEM capable mailers be embedded into software distributions such as SunOS and Ultrix and BSD4.4 for export, or will export versions of the tapes be cut which lack this functionality? How does PEM behave when software DES is used? -As it stands, hardware DES and some libraries for DES usage are not available outside of the US. -george -- George Michaelson G.Michaelson@cc.uq.oz.au The Prentice Centre | There's no market for University of Queensland | hippos in Philadelphia Phone: +61 7 365 4079 QLD Australia 4072 | -Bertold Brecht
galvin@TIS.COM (James M Galvin) (06/21/91)
1) Does PEM address all of the security and authorization issues for sending mail on the Internet? Depends on what you mean by all. I believe that PEM addresses the principal security issues, since it supports message integrity, message origin authentication and message confidentiality. Since public-key technology is used, our implementation will also support non-repudiation. Of course, you must "trust" your local host as far as protecting your private key is concerned, but this is an acceptable risk. 2) Is PEM the preferred approach for building security into private company Internets as well? PEM may satisfy most, if not all, private company E-Mail security requirements. As for whether or not it is a preferred approach for building security, recent developments with respect to the licensing of the technology may make this true. However, this discussion is best held on "pem-dev@tis.com". Send mail to "pem-dev-request@tis.com" if you want to get added to the list. Jim