bernsten@phoenix.Princeton.EDU (Dan Bernstein) (03/24/89)
I propose the following abstract protocol for positive identification of both sides in an Internet user-to-user network conversation. This is not intended as a method of obtaining full security; its intent is to let users of current UNIX machines have a standard for positively identifying the other side of a conversation, with no IP-or-lower-level changes necessary. This has been developed under the framework of TCP ports on UNIX (particularly, BSD-variant) computers on the Internet. It is easily implementable at the user level using the abstraction of sockets. In the following description, port n at machine B is currently controlled by user v at machine B, who wishes to connect to the server process of user u at machine A. We assume the following: A. The server port (m at A) has true ID of the machine (B) connecting to it. B. The server port (m at A) has true ID of the port (n) connecting to it. C. The port (n at B) has true ID of the machine (A) it is connecting to. D. The port (n at B) has true ID of the server port (m) it is connecting to. E. Each machine has a secure facility that gives correct ``finger information'' about a user on the machine; F. The ``finger information'' about a user can only be changed by that user. The idea is that port numbers are communicated through finger information. Each process places messages, each stating ``server #m,'' ``port #n,'' or ``connect #n@B,'' into the finger information of the user running it. Of course, these messages would in practice be formatted more nicely, and made specific to the type of service in question. 1. port n for user v fingers u at machine A, gets server #m. 2. port n connects to port m at machine A. 3. server m for user u receives connection from port n at machine B. 4. server m acknowledges connection. 5. port n receives acknowledgment. 6. port n sends username v. 7. server m receives username v. 8. server m fingers v at machine B, does not get port #n. 9. server m sends acknowledgment of v. 10. port n receives acknowldgment. 11. port n places port #n into finger of v at machine B. 12. port n acknowledges acknowledgment. 13. server m receives acknowledgment. 14. server m fingers v at machine B, gets port #n. 15. server m acknowledges identity of port n. 16. port n receives acknowledgment. 17. port n fingers u at machine A, does not get connect #n@B. 18. port n acknowledges acknowledgment. 19. server m receives acknowledgment. 20. server m places connect #n@B into finger of u at machine A. 21. server m acknowledges acknowledgment. 22. port n receives acknowledgment. 23. port n fingers u at machine A, gets connect #n@B. 24. port n acknowledges identity of server m. 25. server m receives acknowledgment. 26. Both sides now have positive ID and can communicate normally. 27. Both sides agree to disconnect. 28. server m removes connect #n@B from finger of u at machine A. 29. server m sends acknowledgment of a successful conversation. 30. port n receives acknowledgment. 31. port n removes port #n from finger of v at machine B. 32. port n sends acknowledgment of a successful conversation. 33. server m receives acknowledgment. 34. Both sides disconnect. Step 28 can be done any time after 25 and before 29. Step 31 can be done any time after 16 and before 32. If any step in the protocol fails, the connection may be broken immediately, or whatever. An important practical problem here is that it may not be possible to remove information when it should be removed. For example, when server m finishes (suppose it's a talk server and u just logged out), it removes mention of m from u's finger. Unfortunately, if the server is killed, the machine crashes, or whatever, there will be a spurious and incorrect mention of m in u's finger. I consider it likely that there will be such an incorrect mention---and therefore that another user could quickly set up a charlatan server m---at some point. Thus the fact that u@A's finger includes m is considered simply an informational convenience for ports attempting to connect, and so the connecting side performs the same identification test as the server side does. (A similar problem may arise if either side of the conversation is killed---a spurious port or connect message will remain in the finger. This does not compromise the security of the protocol, but it could invalidate further connections for no reason. The solution is to have port n remove mention of itself from the finger when it starts up, and to have server m remove mention of n@B when it receives a connection from n@B.) Finally, the big question: Does this protocol really guarantee correct identification, given the assumptions? Well, each side certainly knows the machine that the other's coming from, with no question. (So if our assumption about the validity of finger information is false, we'll be able to say all messages from machine B are suspect, and we do know which messages come from B.) Since only user v can change v's finger, server m knows that it is user v who has placed the port #n message there. If the only possible cause of such a message is a port obeying the above protocol, then we know user v is running port #n, which by TCP definition is unique. The same analysis applies in reverse. The security of this scheme can be summed up as follows: If a user doesn't protect his finger information, he loses. If a user places spurious messages that this protocol understands into his finger information, he loses. If a machine doesn't correctly report finger information, everybody on the machine loses. Otherwise, we get positive ID. Comments? Have I duplicated somebody else's well-known work? Have I correctly constructed and analyzed the protocol? Is it easy to implement on anything other than a BSD UNIX Internet machine under TCP? Does anybody else support this protocol? Would I be wasting my time to write mail, talk, uucp programs based on this? Is there anything in the standards that messes this up? Would it be possible for this to be supported by root (Complicated Positive ID Mail Transmission Protocol) and thus eliminate mail forging? Does this reduce privacy? Would it improve security to have the finger information include random numbers generated by the other side? (There are some serious problems with that, and I believe that it wouldn't improve security at all---it doesn't matter that somebody else can find out your port number and put it into his finger, just that you can put it into yours.) I hope I'm not starting a 40-day flood of replies and followups... ---Dan Bernstein, bernsten@phoenix.princeton.edu
galvin@TWG.COM (James M Galvin) (03/25/89)
> A. The server port (m at A) has true ID of the machine (B) connecting to it. > B. The server port (m at A) has true ID of the port (n) connecting to it. Whew! Talk about assumptions. Do you realize how sweeping these assumptions are? I will posit that if you can give me an environment where these two assumptions are true, your protocol is unnecessary. I say that because any environment that supports the above two assumptions has so much "security" in place it provides authentication by default. Jim
bernsten@phoenix.Princeton.EDU (Dan Bernstein) (03/25/89)
In article <27904.606784987@twg.com> (in comp.protocols.misc only) James M Galvin <galvin@twg.com> writes: > > A. The server port (m at A) has true ID of the machine (B) connecting to it. > > B. The server port (m at A) has true ID of the port (n) connecting to it. > > Whew! Talk about assumptions. Do you realize how sweeping these > assumptions are? Yes. However, I designed the protocol for positive user-to-user identification, given no root support but given root security. As long as root is safe on both sides and on each gateway in the middle of the connection, those assumptions are true. In fact, we don't need assumptions A and B if we're given assumptions C and D, viz., you know who you're connecting to (even if you don't know where an incoming connection is coming from). Given that, it will not matter that machine X claims to be machine Y---because it will not survive the identification test, in which we connect to machine Y. The security here is exactly like the security of any other callback mechanism, even without A and B. I believe I made it clear that I was working under the framework of TCP/IP. I believe that the requirements for gateways include correct routing. I think that any security breach implying that you can't be assured of a correct connect() to a root-supported port at a valid address is, realistically, such a major low-level problem that one should not invalidate a high-level protocol (is TELNET a good example?) that does not control it. It is for the same reason that when discussing any protocol above the IP layer you don't keep reminding yourself that the packets may be changed by a malicious gateway en route. You just hope that the low-level problem is corrected quickly. > I will posit that if you can give me an environment where these two > assumptions are true, your protocol is unnecessary. I say that because > any environment that supports the above two assumptions has so much > "security" in place it provides authentication by default. Is that so clearly true if we don't assume positive ID of incoming addresses? TCP makes no provision for one end to receive knowledge of the userid on the other end. It is because of that gap that I have proposed this protocol. BTW, any suggestions for a protocol name, just in case someone other than me starts using it? How about QUIP (the Q User Identification Protocol [don't ask about the Q])? ... > Jim ---Dan Bernstein, bernsten@phoenix.princeton.edu
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (03/26/89)
In article <27904.606784987@twg.com>, galvin@TWG.COM (James M Galvin) writes: > Whew! Talk about assumptions. Do you realize how sweeping these > assumptions are? Jim Galvin is quite correct; relying on accurate knowledge on the remote machine id in tcp/ip is hopeless. In fact, that's one of the major recurring themes of a paper of mine that will appear in the April '89 issue of Computer Communications Review. (Aside: Craig Partridge, the editor, posted a blurb for several articles in that issue to comp.protocols.tcp-ip, as well as information on how to join SIGCOMM and get the journal.) --Steve Bellovin smb@ulysses.att.com