X forwarding

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

I'd like to dredge up something from the past (most recently, and
perhaps most significantly, last November).

I was starting to implement X forwarding, when I realized that the
x11-req defined in connect-18 was unnecessarily complex, and, as far as
I could see, pointlessly so.  Rather than drag out stuff that I see
from the archives has been hashed over before, I'll just ask two
questions that I didn't see answers to in the archives.  (It's possible
I missed them; I just grepped for "x11-req".  If they have been
answered, something like a message-ID to grep for would be much
appreciated.)

I can see no value whatever in making the client pass an X
authentication method and data blob to the server.  The client has no
idea what authentication methods may be supported by the X
implementation on the server side, so it has no way to select an
appropriate authentication method.  There is no additional security
gained from doing so, since any forwarded X connection will perforce be
coming from the same entity the client gave the data blob to, so it
serves no authentication use to return it.

However, the people who designed the protocol are not stupid, so there
must be something I'm missing.  This, then, is my first question: why
are those fields there?

nisse%lysator.liu.se@localhost wrote, of X forwarding, that another field -
"display id" is what I remember seeing - seems called for.  I find this
necessary too, for reasons very similar to what I mentioned recently
when writing about forwarding TCP connections.

> In more general terms, letting the server do the authentication is in
> a way making an (X11) client responsible for X11 server security,
> which is not good practice.

I don't understand the point here.  I have been unable to come up with
a threat model against which having the client provide an
authentication method and data blob provides any defense.  My other
question: can anyone give an example?

I'm implementing X forwarding as a private request which carries only a
uint32 cookie and a screen number; when the server wants to forward an
X connection, the channel open carries the cookie and the first six
bytes of the X protocol stream sent by the client (I could have sent
these as the first data on the new connection, but this way seems
marginally simpler).  The rest of the Xclient->Xserver protocol setup
data (the authorization name and data) are not sent; the client is
expected to replace that anyway.

What security horrors am I risking thereby?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B