Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!MIT-MULTICS.ARPA!JSLove From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords Message-ID: <870112152639.858014@MIT-MULTICS.ARPA> Date: Mon, 12-Jan-87 10:26:00 EST Article-I.D.: MIT-MULT.870112152639.858014 Posted: Mon Jan 12 10:26:00 1987 Date-Received: Mon, 12-Jan-87 21:35:45 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 90 Approved: tcp-ip@sri-nic.arpa 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.