Xref: utzoo comp.protocols.misc:531 comp.mail.misc:1739 comp.unix.wizards:15217 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!njin!princeton!phoenix!bernsten From: bernsten@phoenix.Princeton.EDU (Dan Bernstein) Newsgroups: comp.protocols.misc,comp.mail.misc,comp.unix.wizards Subject: Re: Proposed protocol for positive ID over Internet Message-ID: <7383@phoenix.Princeton.EDU> Date: 25 Mar 89 10:40:15 GMT References: <7361@phoenix.Princeton.EDU> <27904.606784987@twg.com> Reply-To: bernsten@phoenix.Princeton.EDU (Dan Bernstein) Followup-To: comp.protocols.misc Distribution: usa Organization: Princeton U. Undergrad Math Majors, last time I checked Lines: 53 In article <27904.606784987@twg.com> (in comp.protocols.misc only) James M Galvin 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