🚀 go-pugleaf

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