hedrick@TOPAZ.RUTGERS.EDU.UUCP (01/11/87)
Does anyone know of good replacements for the normal "please type your password" approach to login validation? We're thinking of moving our administrative computing onto a campus-wide network. I'm nervous about having people updating student records on a system that is as easy to tap as the typical Ethernet. Obviously we'd like to prevent people from seeing the data at all. But I'm most concerned with preventing people from changing it. My theory is that once a TCP connection is established, it's likely that no one will be able to break in on it. The gateways and backbone are likely to be physically secure, so any breaking in would have to happen on the local net. I think we can tweak the implementations so that is either impossible or leaves immediately obvious evidence. So what I'd like is a way, once the connection is established, to validate the person who is on it. It strikes me that fairly simple cryptographic techniques should work here. I had in mind something like the host sends me a random number, I ask the user for his password, I encrypt the random number with the password, and send back the results. The host knows the password (This is not Unix, so the password files are not public.), and duplicates the results at its end. The only constraint on the encryption technique is that it has to be able to survive a known plaintext attack on the random number. Presumably that is short enough that any reasonable technique (DES?) would work, as long as we choose the passwords. Obviously if the user chooses the passwords, the space of passwords will be so small that it would be easy to search. Does this seem reasonable? Anybody have a better idea? I'm looking for something that I can practically implement myself. Probably all access with be a micro running pc/tn3270, when it becomes available, and the mainframe will be running the UCLA MVS TCP/IP code. I'm looking for something I can hack into that software. Also, it would be sort of nice to encrypt the data itself. Does anybody know whether this is practical? My feeling is that it might be worth coming up with a random bit stream once for each connection and just XOR'ing all the data with it. Of course this would be a sitting duck for known plaintext attack, but at least it would require some work to see what was going on. The security against change would not depend upon this, but upon the security of the connections and the password mechanism. This would be designed simply to discourage casual wiretapping. I know nothing I'm going to come up with is going to prevent the NSA from finding out our student grades. But what bothers me is the common approach that because the perfect is unobtainable, we do nothing. What I'd really like to do is to get something that is at least as secure as locking your gradebook in your desk and then locking your office door. There are obviously many people on our campus who can get past those locks. But there is still a difference between using the locks and leaving the grade book out on a coffee table in a public lounge.
LYNCH@A.ISI.EDU.UUCP (01/11/87)
Charles, I hope Brian Reid at DECWRL reads this list as he has dealt with this problem at STanford and, as you note, no one has done anything yet to at least put up a line of defense for "us nice citizens who once in a while get tempted". Your concern in advance is commendable. I have been secretly worring about "security" of internetworking for a long while now because I fear the backlash when the first big "thefts/damages" happen and the world finds out how spartan our security features are. I have worked in the security arena long enough to know that anything that one comes up with as a protective measure can be countervailed. It is only a matter of the price one is willing to pay. So, please, some of you out there who know of some reasonable barriers to tampering on campus LANs, give Charles some feedback on his request. Thanks, Dan -------
Murray.pa@XEROX.COM (01/12/87)
As long as you can work on the software at both ends, then your goals are reasonable. Needham and Schroeder published a scheme back in '78. Check out the Dec '78 CACM. The basic idea you are looking for is pretty much the following. The user calls the server, and sends his claimed identity (username) in the clear. The server picks a random number and a session key, encrypts them with the users password and sends them back to the user. The user decrypts them, and uses the session key to encrypt the random number and sends that back to the server. DES will eat a lot of cycles if you do it in software. That's not a problem if you only use it for authentication, but if you are encrypting everything going to/from a terminal session, response will probably be unacceptably slow. Micros are getting pretty fast these days. Check it out. You might just make it. (Sorry I don't have any numbers handy.) I strongly suggest a physically separate network for administrative work. Don't even connect it to the rest of the world via any gateways. This transforms the problem back into physical security. Most administrative people understand that. In any case, it becomes their problem and you (we?) can't get a black eye because some tricky point got overlooked. Keep in mind that observing terminal traffic is just the tip of the iceberg. As your users get more sophisticated and upgrade to more powerful machines, you will have to worry about printing things directly from a workstation, swapping to remote disks, remote debugging sessions, and strange new things that nobody has even imagined yet. Our administrative people upstairs have their own ethernet (and printer and file server and ...).
JSLove@MIT-MULTICS.ARPA.UUCP (01/12/87)
Both TELNET and FTP-CONTROL (not FTP-DATA) sessions use the TELNET
protocol, so you could do some password protection in that layer. For
example, if the TELNET turns off echoing, you could turn on encryption,
which would protect a password (and also emacs sessions, but you could
deal with that separately). You could define negotiations to turn some
form of data protection on and off.
The alternative is to invent new protocols for login, file transfer and
so on. This has been done already for Unix (at least in part), so specs
and implementations exist of protocols which dispense with the normal
login dialogue for user authentication. You will probably have to
design and implement your own authenticator.
I recommend against keeping a cleartext password file. Even if it is
secure, scramble the passwords. You can use the scrambled passwords as
encryption keys. Since the password will be supplied to the
authentication server scrambled by another key, the initial password
scrambling (when new passwords are set) might be done at the
authentication server as well.
In your login dialogue, start out using a key used by that
workstation-server pair. Scramble the userid with this key (K1) so that
a listener can't easify find out who owns the connection. The server
will unscramble it and look up the user. Then the server will send back
a session key and a random number, encrypted with the userid and
workstation-server keys. The workstation will decrypt this and ask the
user for a password. It will then scramble the password, and encrypt
the random number with the session key and the scrambled password as
keys, returning the result to the server. The server checks the
returned random number after decryption.
The session key is remembered for use during the session by operations
which require a high degree of protection, such as changing passwords.
However, it would probably use DES or some other form of encryption
which might be too expensive to use on all traffic. I believe there are
network interfaces available for some machines which will encrypt your
entire packet with special hardware, but they may make it difficult to
communicate with any machine which doesn't have exactly the same
interface hardware.
For regular traffic, there are cheap forms of encipherment which will be
better than using the same XOR string for every connection. For
example, you could use a character translate table, which is harder to
break than an XOR mask. Don't use the same table for every byte. You
could cycle between several, or you could select which table based on
some more complex algorithm. For example, if you had 64K of table
space, you could use the previous byte to select the translation. You
could have a circular list of tables and step to the next table using
the modular addition of the current table index and the previous
character.
This is certainly breakable in principle, but it is cheaper than
software DES. Each translate table must be isomorphic (invertible) but
no relationship need exist between multiple tables. The tables could be
mechanically generated and changed often, perhaps being distributed over
the network in encrypted form. Encipherment would be done only on the
byte stream, so it probably could be implemented outside the operating
system kernal or without changes deep within the TCP/IP.
Rather than partition the network physically, consider an implementation
based on IP security options in the IP headers. This would be enforced
by the gateways. An IP gateway must be present between the ethernets
which have sensitive traffic and the rest of the internet. The gateway
would refuse to pass packets off the sensitive network which contained
the security option. Ideally, the hosts on the sensitive networks would
place the security options in the packets. If that isn't feasible, the
gateways could. Consider a campus network with subnets A, B, C, D and
E:
B D
\ /
A---C
\
E---ARPANET
Subnets B and D belong to the administration. The AB gateway passes
packets from A to B only if the have the security option, and passes
packets from B to A adding the security option to the IP header.
Gateway CD has similar behavior. Gateway AC ignores the option.
Gateway CE refuses to pass in either direction packets which contain the
security option. (This description has been simplified for pedagogical
purposes so much that it resembles "community of interest" routing,
which is also a possibility, but which is more limiting.)
Subnets A and C must be physically secured just as networks B and D.
However, they can carry traffic from unsecured subnets. It is desirable
for backbone networks to be able to carry traffic from all subnets. The
AB, CD and CE gateways must be secured from tampering, but anyone on
subnet E or other networks connected to it will be completely unable to
send packets to or receive packets from subnets B and D.mckee@MITRE.ARPA (H. Craig McKee) (01/12/87)
Charles Hedrick I suggest you review DoD Password Management Guideline (CSC-STD-002-85), 12 April 85. The Guideline was developed by the Computer Security Center, Ft. Meade, Maryland 20755. The point of contact is the Office of Standards and Products, Attn: Chief, Computer Security Standards. (If you like I'll make a copy and mail it to you.) The Guideline offers many recommendations, two of which follow. The password should be a three-word phrase, because it is easier to remember, rather than a random string of characters. The words are drawn randomly from a dictionary of at least 2000 words. The passwords should be encrypted; thus, the clear text form of the password exists only in the mind of the user, and very briefly in the memory of the host. Regards - Craig
geof@decwrl.DEC.COM@apolling.UUCP (Geof Cooper) (01/13/87)
> My theory is that once a TCP > connection is established, it's likely that no one will be able to > break in on it.... I'm not sure you'll have enough secure pieces. All networks traversed by packets that are part of the "secure" tcp connection must be physically secure. Otherwise, it is easy to interpose data into a TCP connection and monitor the result. For example: Monitor the connection and wait until it has been idle for some time (around lunch time, so the user is probably not looking at the terminal). Then spoof the server into receiving a packet with a particular input command in it. Examine the data that results. Then spoof a packet that causes the server to clear the screen. Note that the legit TCP client will merrily receive all the data. I wonder if it will get upset that the ACK numbers are too high... I'd bet few TCP's would. When the legit user returns, he/she will type a bit with no results (since the server will ignore those packets). Eventually things will start working again, and he/she will probably just think it a magical glitch and not report the problem. The idea of Needham/Schroeder authentication is the best way to go. One option in the scheme was to have the encryption key for the next packet in this packet, so the above kind of spoofing would be hard (and would certainly be detected at the legitimate receiver). Needham/Schroeder doesn't assume that DES is used (as I remember, certainly there is no need for them to make that assumption). You can increase the work factor needed to spoof the system sufficiently by just XOR-ing passwords into the datastream. I would think that this would be "enough security" for a campus environment for the next few years. - Geof PS: On further consideration, you could probably get around TCP spoofing by just arranging to never leave a connection idle for more than 30 seconds or so. If the system dis- and re-connected to the server automatically, the users probably wouldn't rebel. - GHC
yerazuws@CSV.RPI.EDU (Crah) (01/13/87)
In article <8701111745.AA01536@ucbvax.Berkeley.EDU>, LYNCH@A.ISI.EDU (Dan Lynch) writes: > So, please, > some of you out there who know of some reasonable barriers to > tampering on campus LANs, give Charles some feedback on his request. > Here at RPI we have a relatively tamperproof LAN system - but it wasn't meant to be that way. For example, Professor A gets a pair of Sun 2's. One diskless Sun goes in his office up on the sixth floor, and the fileserver goes down in the basement lab. A piece of Ethernet goes in between them. Then Center for XXX gets in a flock of uVAXen and puts them on an Ethernet. Different piece of coax, of course. Then Center for YYY interconnects their MV10000 and their /780's and a couple of GPX's - on yet a third Ethernet. All of these Ethernets coexist physically in the same building, run down the same cable trays, etc. But they're all physically separate and since the watchword is cost - there are NO bridges/gateways. You see, who pays for the gateway? What "added value" is there in a gateway? Ah, you say that XXX and YYY should have gone on A's cable? Well, A already paid for that cable and it's his bandwidth and he doesn't want to clog down his diskless SUN 2 with all that DECnet traffic (which, having used a diskless Sun 2, I do not blame him at all for. I wouldn't either, if I had any way to avoid sharing that cable.) But XXX and YYY should have used the same cable? Then who pays for it? Each center has to bill out expenditures. So, financially speaking, it isn't reasonable for either party to put in some LAN that it isn't going to use. Or that might need to be upgraded because a "sharing" arrangement is overloading the LAN. Now you say "Why not at least install bridges/gateways"? Again, who pays for it? So there are no gateways. Instead, each machine has one or two RS232 lines to a data switch. At 9600 baud. You dial out and tell the data switch where to connect- and then you log in there. Meanwhile, those three Ethernets sit there, safe and protected from the "other" guy. Forgive the sarcasm and the flames, dear reader. But restricting use of a LAN (or access to bandwidth on a broadband system) may be what you want, although it pretty much negates the usefulness of the LAN in the first place. I'd personally advise against such physical protection systems where the stakes are low (How much can a college campus net intruder get for his trouble? Ten grand maybe, at best?). If the stakes were higher (like a case of national security) I'd say this is the way to go. Hang the multiple Ethernet coaxes or fiber optics along the ceiling in the middle of a patrolled hall and NOBODY is going to get to it without much pain. What it boils down to is that you can have security, or you can have a useful LAN, or you can go crazy. Those are your options. -Regrets for the depressing truth... Bill Yerazunis
JSLove@MIT-MULTICS.ARPA.UUCP (01/13/87)
I don't know about your TCP, but the Multics TCP will send a RST immediately if it receives a packet with an ACK that it`s too high. I believe that this is clearly spelled out in the specification, but I am at home and don't have the specification handy. To prevent this, your penetrator must break network routing (e.g., using ARP) to prevent the acknowledgements from reaching the workstation or the RSTs they provoke from getting back to the server. If you don't mind breaking the connection, any damage you can do with a single packet is perfectly possible. I don't think most TCPs would give out any indication of why the connection was broken, either on the scren or in a debugging log. An workstation in debug mode might note that an out-of-sequence acknowledgement was received, but the server would only note that the user had aborted the connection. If you really have control of network routing, it would be interesting to see if you could insert the penetrator between the workstation and server, effectively splitting an existing session into two sessions with the penetrator in the middle. The potential for mischief would be awesome. Receiving a packet which contains out-of-sequence acknowledgement should probably ring alarm bells. Even out-of-sequence packets which don't contain acknowledgement (and thus must be SYN packets) are illegal, but they probably indicate that the other end has crashed or a TTL anomaly, rather than a penetration attempt. Something else that might help is putting reasons for aborts into RST packets as data, and having the receiving TCP log the abort reason. Then there would be a record of the break-in at both ends of the connection. I believe that there are TCPs which implement this, but have no idea which ones. It certainly isn't in the spec. (This could be circumvented by having the penetrator abort the connection, but unless routing is subverted, this gives too short a window to do much other mischief.)
matt@oddjob.uchicago.edu.UUCP (01/18/87)
J. Spencer Love writes:
) I don't know about your TCP, but the Multics TCP will send a RST
) immediately if it receives a packet with an ACK that it`s too high. I
) believe that this is clearly spelled out in the specification, but I am
) at home and don't have the specification handy.
Nope, RFC-793 says "If the ACK acks something not yet sent
(SEG.ACK > SND.NXT) then send an ACK, drop the segment, and
return.JSLove@MIT-MULTICS.ARPA.UUCP (03/01/87)
Date: 18 January 1987 15:57 est
From: The Matt Crawford of net.* <matt at ODDJOB.UCHICAGO.EDU>
Subject: Re: secure replacements for passwords
J. Spencer Love writes:
) I don't know about your TCP, but the Multics TCP will send a RST
) immediately if it receives a packet with an ACK that is too high. I
) believe that this is clearly spelled out in the specification, but I am
) at home and don't have the specification handy.
Nope, RFC-793 says "If the ACK acks something not yet sent
(SEG.ACK > SND.NXT) then send an ACK, drop the segment, and
return.
Thank you for pointing this out. I'm sorry that this reply is so
delayed.
The Multics TCP does, in fact, behave as I claimed. I have examined
RFC-793, and the sentence which Matt Crawford quoted is on page 72 (page
2-256 of the DDN PROTOCOL HANDBOOK). This deals with the ESTABLISHED
state. In the pre-ESTABLISHED states (LISTEN, SYN-SENT and
SYN-RECEIVED), the specification directs the implementor to form a RST
packet based on the invalid acknowledgement. Thus, the Multics
implementation's behavior is conformant until the connection is
established, and deviant thereafter.
Does anyone know what the specifiers had in mind when they made this
distinction? The rest of this message attempts to explain my reasons
for believing that the specification is wrong here and should be
changed.
If someone attempts to spoof the connection, they can do so by
monitoring the connection and inserting a packet. This packet might
contain commands (via the TELNET server), spurious mail, or faked output
(back to the user TELNET). Because packets routinely come from gateways
which are not the IP header source, it is difficult to detect this
spoofing by examining the lower layer's packet source.
There are two cases. In the "hard" case, the spoofer has corrupted
network routing, so that no packets are exchanged between the original
connection endpoints. The spoofer can insert itself into the
connection, completely concealing its presence, or permit one side of
the connection to time out, replacing it to the other side of the
connection. Hopefully, this type of spoofing can be prevented by other
means.
In the "easy" case, the connection routing is not disrupted. The bogus
packet is merely inserted into the stream. The receiver of the bogus
packet will issue an acknowledgement which will get back to the other
end of the connection. If we are lucky, this packet will appear to
acknowledge something which hasn't yet been sent. If it *has* been
sent, then the chance of the bogus packet's being accepted is reduced,
unless routing has also been corrupted. If routing has been corrupted
in the direction that the bogus packet's acknowledgement will travel,
then this is effectively the same as the "hard" case.
I can't think of a situation where a "precognitive" acknowledgement is
valid. If one arrives, it indicates either that a spoof attempt has
been made, or that a packet has long outlived its TTL and emerged from
some network backwater like some kind of glacier-preserved SF creature.
The chance that such an anachronism will also pass the sequence number
check is hopefully small, but certain operating systems which we all
know are very repetitious about selecting port and sequence numbers.
The receiver of the precognitive acknowledgement should send a RST
packet. Ideally, it should also refrain from sending data up to the
precognition point for awhile (some function of RTT and TTL), but that
is probably too much to ask. It should also log the precognitive ACK as
a possible spoof attempt.
If the precognitive ACK really emerged from the glacier, then (ignoring
race conditions), the RST packet which it elicits will fail the sequence
number test at the other end of the connection and is thus harmless. If
routing has been corrupted in the direction the RST travels, at least
the spoof has been detected and logged at one end so that
troubleshooting can find it later. If the RST gets through, it will
abort the spoofed connection and hopefully minimize the damage. If the
RST packet carries an "explanation" in its otherwise unused data field,
then this also can be logged at the receiving end so that both ends of
the connection have a record of the spoof.
The likelihood of having normal service clobbered by this RST is low.
The likelihood of a spoof is hard to estimate, but the protocol should
act to limit, as much as possible, the effects of spoofing, and to
detect such attempts, especially when no extra work is involved.
With this in mind, I don't plan to change Multics to conform to the
specification in this area, although I would be interested in and would
act upon a convincing refutation.
-- Spencer Love