Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA (07/30/85)
Lots of people appear to be thinking that a verification of IP
addresses, e.g., in the case of SMTP is not necessary. I am not sure
whether and where this was already discussed before, but I get the
impression that the proliferation of low cost workstations connected to,
say, campus computer networks might change our minds in two to three
years in an environment where most of the power (besides parts of
routing) will go to these hosts. I presume that this will be a newly
evolving problem which could not easily show up so far. What are the
suggested measures against faked message headers in that case? IP source
verification? Something else? Or is this considered to be no problem at
all?
-- Hans-Werneralt%sri-lanka@sri-tsc.ARPA (E. Howard Alt) (07/30/85)
One good way to do authentication is with encryption of the public
key variety. The person would encrypt the message with his
private key, and people would decrypt the information with
his public key (carried along with the message) to read the
headers and text. No one can change the headers of text
of the message, because they can't make ciphertext that will
be decrypted with his public key. You can't lie about who
sent the message because you wouldn't be able to decrypt the message.
Simple, eh? The logistics are a bit more complicated...
Howard.alt%sri-lanka@sri-tsc.ARPA (E. Howard Alt) (07/31/85)
One good way to do authentication is with encryption of the public key variety. The person would encrypt the message with his private key, and people would decrypt the information with his public key (carried along with the message) to read the headers and text. No one can change the headers of text of the message, because they can't make ciphertext that will be decrypted with his public key. You can't lie about who sent the message because you wouldn't be able to decrypt the message. Simple, eh? The logistics are a bit more complicated... Howard.
salex@RICE.ARPA (Scott Alexander) (07/31/85)
So you check my ip addr and it agrees with my name in the host table. But if this is my workstation, I can cause it to build ip packets w/ any addr I like. So now instead of just faking the HELO command I have to fake ip packets, too. On an ethernet, even checking the ethernet addr doesn't tell you anything since I can often reset it. There is no way to get around faking mail. You can make it harder. The people with whom I have dealt who are willing to go to the trouble to fake mail are willing to format ip packets also. Scott Alexander Rice University salex@rice (713) 527-6012
stef@uci-icsa.ARPA (Einar Stefferud) (07/31/85)
The authentication of network mail issue has been discussed many times over the last decade, in various discussion lists, including header-people and msggroup. Each such discussion has ended by recognizing that authenication always requires some kind of out-of-band verification mechanism, like the county recorder for property deeds and important legal documents. Use of encryption fits this solution. The keys are issued/distriuted out of band (or you have done something magic to include the key in the message in such a way that it cannot be faked). Sending the public key in the message is not the case I mean here. it is the private keys that go out of band. It is important to note that the need for authentication is relative to the cost of being unsure of a sender's identity. In most netmail cases, it is easy to verify by checking back via reply mail (or forwarding back a copy) to the supposed sender. This is going out of band again though. And, I must agree that SMTP is rather too promiscuous for me as we populate our local area networks with Unix Class Workstations which are administered by whoever happens to be at the console in too many cases. I worry about them in more ways than just mail! In too many cases, anyone can become root and can then use those privs to attack other hosts, and ... Sigh! Stef
Hans-Werner_Braun%UMich-MTS.Mailnet@MIT-MULTICS.ARPA (07/31/85)
Ok, but you'd have to be careful not to mess up IP routing back to you.
I was not intending to say that IP source verification would resolve all the
SMTP authentication problems but rather asking what others think whether
it would be a worthwile thing to do to improve the situation to some extend,
even while confusing layering.
-- Hans-Wernerjordan@ucbvax.ARPA (Jordan Hayes) (08/01/85)
Hmmm... what's wrong with faked headers? Why should e-mail be any different from snail mail? All you can do is "postmark" what you get with time/date and where you think it's from. Caveat reader... ------------ Jordan Hayes jordan@UCB-VAX.BERKELEY.EDU UC Berkeley ucbvax!jordan +1 (415) 835-8767 37' 52.29" N 122' 15.41" W
Mats_Ohlin_FOA2%QZCOM.MAILNET@MIT-MULTICS.ARPA (08/07/85)
Within the Commission of the European Communities there is a project OSIS (Open Shops for Information Services) that aims to develop a "smart card" including a chips for RSA-encryption used so that (only) the legitimate user could produce (using the secret key) signed (and timestamped) messages that anyone could decrypt (using the public key) thus verifying the identity of the sender. The interational banking organisations are very interested as well - even if the first step aims to provide a simple, non-contract technique for data base users to get access. The OSIS project also includes contracting procedures via electronic media.
darling@uwmacc.UUCP (Jean Darling) (08/07/85)
We are bringing up a local TCP/IP network connecting a heterogeneous bunch of operating systems. One of the things we want our network to do for us is allow certain peripheral output devices (plotter, photo- typesetter, laser printer, etc) to be shareable by any authorized user on the network (under our administration, they have to pay!). We expect to have some sort of global authorization system which would contain network ids and passwords. We will need some kind of global queues for these devices as well. We are beginning the process of designing some network servers to do this sort of thing, but we'd prefer not to re-invent the wheel. The authentication problem comes up for PC users of the network; we *think* that having a network password would protect us fairly well, and perhaps would take care of making sure the right PC user is collecting the right mail. Perhaps we would have to use the encryption scheme to make sure someone wasn't pretending to be the authorization server. [How feasible is it to try to treat some local IP addresses like ports, available to PCs on a first-come first-served basis? (These addresses could only be known locally...users from outside would have to mail to the gateway nameserver machine.)] Please help clear away the fog. Any comments, suggestions, or pointers to references will be welcomed. Jean Darling