Subject: X forwarding: suggestions

From: Simon Tatham <[email-masked]>
Date: Tue, 23 Jan 2001 11:21:24 +0000

Hi,

I maintain PuTTY, a Windows SSH1/SSH2 client. I've recently
implemented X forwarding, and I have a couple of suggestions about
authentication of the X client connections.

(I'm currently considering the usual case of forwarding X
connections from the SSH server to the SSH client, so I'll use the
terms `client' and `server' that way round. I'm aware SSH2 is more
symmetric than that really.)

Suggestion 1: allow the client to do better
-------------------------------------------

Currently, the auth data PuTTY invents to send to the server uses
the MIT-MAGIC-COOKIE-1 protocol: the client demonstrates that it
possesses the same shared secret as the server by simply quoting the
whole secret. This is of course vulnerable to a passive network
listener.

(An active man-in-the-middle can _always_ subvert an X connection,
because after the auth phase there is no integrity protection. So
I'll consider passive attacks only.)

A slightly better protocol is XDM-AUTHORIZATION-1, in which the
client uses half the shared secret as a DES key with which it
encrypts:

 - the other half of the shared secret
 - the source IP address and port of the X connection (or other
   equivalent data for connections over media other than IP)
 - a timestamp.

The server decrypts this claim and verifies the components. The XDM
specification states that the timestamp should be verified to within
a 20 minute tolerance either way.

I would like PuTTY to be able to provide this auth protocol as an
alternative to MIT-MAGIC-COOKIE-1. In order to do so, PuTTY would
need to know the source IP and port of the forwarded connection.
SSH2, in the protocol spec, claims to provide this:

  string    originator address (e.g. "192.168.7.38")
  uint32    originator port

but in practice, OpenSSH provided a hostname instead of an address.
This is useless for verifying an IP, because one hostname may map to
more than one IP, and/or the DNS at the other end may be different
(for example, consider a private network with internal DNS).

If the SSH2 protocol were to mandate the provision of an actual IP
address rather than a hostname, X forwarding would become
significantly more secure against passive network listeners.

(IPv6 and other network protocols would also be a consideration; I
don't know what support the X protocol has for IPv6 as yet.)

Suggestion 2: make the server do it!
------------------------------------

Better still, it seems to me, why not make the SSH _server_ invent
the remote auth data and verify it?

This doesn't allow any new attacks by somebody subverting the SSH
server and causing it to accept unauthenticated connections, because
the SSH server already has access to the fake auth data, so anyone
who subverts it can _already_ pull off this attack. So it places no
additional trust in the SSH server to let it authenticate incoming
X connections.

The advantage would be that the server can perform
XDM-AUTHORIZATION-1 or other complex authentications very easily,
because it obviously does have access to the source IP/port of the
incoming connection - or to the equivalent if the connection should
come in on a Unix domain socket. It seems silly to forward all the
details back to the client and make the client do it, when there's
no reason for the server not to just do it itself.

The server would them strip out the auth strings from the X
connection before forwarding it back to the client; and the client
could insert the real auth strings to allow the connection to be
accepted by the real X server. So each end deals only with what's
important at that end.

Cheers,
Simon
-- 
Simon Tatham         "loop, infinite _see_ infinite loop"
<[email-masked]>     - Index, Borland Pascal Language Guide

---

From: [email-masked] (Niels M�ller)
Date: 23 Jan 2001 16:23:26 +0100

> but in practice, OpenSSH provided a hostname instead of an address.

If so, that seems to be a bug in OpenSSH, the "originator address"
ought to be either an ipv4 address (in dotted decimal notation), or an
IPv6 address literal.

But fixing that would not quite solve your problem, I'm afraid. For
instance, "127.0.0.1" is a reasonable address but probably not very
useful for authentication purposes. And the originator may also be
using an AF_LOCAL socket, in which case an empty string may be a
reasonable thing to put in the "originator address" field.

> Suggestion 2: make the server do it!

[...]

> accepted by the real X server. So each end deals only with what's

Sounds very reasonable to me.

Regards,
/Niels

---

From: Tatu Ylonen <[email-masked]>
Date: Thu, 25 Jan 2001 13:58:09 +0200 (EET)

> (for example, consider a private network with internal DNS).

The intention was for it to always be an actual IP address (IPv4 or IPv6).

It looks like most of the other channel opens already say "originator IP
address" and explain "Originator IP address is the numeric IP address of
the machine where the connection request comes from".  In the case of
"x11" channels, it says "originator address" and gives a
numeric example.

Perhaps the draft shoud be clarified to have the same text for X11
channels as for the other channels, but I certainly don't think any
delay in the process should be caused by this.

> the remote auth data and verify it?

You basically mean double-faking the cookies?  One reason not to do it is
that the server would need to know about authentication methods to do
something useful there.  (Of course, the client would too, but the client
is usually on the same machine as the X11 server, and can more easily be
controlled by the same administrator, whereas the server may be in a
different administrative domain.)

> no reason for the server not to just do it itself.

The client should already be getting the IP address, not a host name.

I don't think we should do X11 auth cookie faking in the server for the
following reasons:

   - it adds no security, but adds complexity

   - the client should already have the required info (IP address) in
     correct implementations

   - the server should not need to know about new X11 auth methods,
     because it is often in a different administrative domain and cannot
     be upgraded at the same time as X11 servers.

Furthermore, I would hate to change the protocol at this point unless
there is some very critical issue.  In this case, I don't think the
benefit justifies the delay that would be caused by the change (I
personally don't think it should be done in the server at all).  Also,
whether server does cookie faking is not really a protocol issue.  A
conforming server could do it regardless of whether the client does it.

    Tatu

---

From: Simon Tatham <[email-masked]>
Date: Thu, 25 Jan 2001 12:13:22 +0000

> delay in the process should be caused by this.

Fair enough. That's good enough for me.

> You basically mean double-faking the cookies?

No, just single-faking them in a different place. Provided the
server is faking some auth data and thus controlling what
connections get forwarded, the client has no _need_ to fake any auth
data. The reason being, the server knows the cookie the client has
made up, so a malicious server could get a hostile connection
through to the client's X server _anyway_, so there's no security
loss involved in just having the client trust anything the server
forwards to it.

>    - it adds no security, but adds complexity

Well, it adds complexity in the server, but that's the price of
removing complexity in the protocol. *shrug*

> One reason not to do it is that the server would need to know about
> authentication methods to do something useful there.  (Of course,
> the client would too, but the client is usually on the same machine
> as the X11 server, and can more easily be controlled by the same
> administrator, whereas the server may be in a different
> administrative domain.)

This seems like a reasonable point though. Fair enough. As long as
there are good grounds for getting OpenSSH to fix their originator
addresses, I've got everything I need to do a proper job in any
case.

Many thanks,
Simon

---

From: [email-masked] (Niels M�ller)
Date: 25 Jan 2001 15:23:34 +0100

Tatu Ylonen <[email-masked]> writes:

> something useful there.

I don't see any need for passing any cookies across the ssh protocol.
The ssh client and server are already talking to eachother over a
mutually authenticated channel.

>    - it adds no security, but adds complexity

I'm not so sure about the complexity in doing that, but I haven't yet
implemented X11 forwarding.

>    - the client should already have the required info (IP address) in

Except that if the ipaddress is 127.0.0.1 (or some other address that isn't
globally unique, like an IPv6 site local or IPv4 private use address),
it isn't terribly useful on the client side. And then we have the case
of non-tcp connections, which have been discussed earlier.

>      be upgraded at the same time as X11 servers.

To me, different administrative domains are an argument *against*
having the client know about authentication of X clients at the
server. What if the X infrastructure at the server (including the ssh
server) only knows about the authentication method FOO, while the X
system at the client, including the ssh client, only knows the
authentication method BAR? Then forwarding fails, while it would have
worked fine if the server had handled authentication at its end.

In practice, I expect that both ends would fall back to the
magic-cookie authentication instead of failing, but it would still be
better if the X authentication at the client and at the server were
independent.

> there is some very critical issue.

I understand that.

> Also, whether server does cookie faking is not really a protocol
> issue. A conforming server could do it regardless of whether the
> client does it.

You're right, the situation could be improved by just adding proper X
authentication and cookie-generation to the server. Then clients could
send an empty string as it's cookie in the x11-request (and a null x11
authentication protocol, if there is such a thing), or some more or
less random string if they want to forward several displays.

This doesn't change the wire formats, but it's still a slight protocol
change. A client would want to know if the server will do proper
authentication or not (because at least one of the client and server
has to do it).

/Niels

---

From: Tatu Ylonen <[email-masked]>
Date: Thu, 25 Jan 2001 19:19:35 +0200 (EET)

> loss involved in just having the client trust anything the server

For MIT-MAGIC-COOKIE-1 the client has to do the faking, unless it wants to
tell the server what the real cookie is.  The reason for doing the faking
in the client was that many people keep their X logins open for
days/weeks/months.  We don't want the X11 cookies on every machine we have
ever logged into during a period of weeks/months, because a break-in to
any of those could be used to break into the X server.  As the faking is
done in the client, the cookies left on the server (anything told to the
server) will be useless as soon as the connection has been closed.

> removing complexity in the protocol. *shrug*

I don't think it is adding/removing any complexity in the protocol.  The
originator address is there for e.g. debugging/logging purposes anyway, so
I don't think any change would simplify the protocol.

    Tatu

---

From: Simon Tatham <[email-masked]>
Date: Thu, 25 Jan 2001 17:30:53 +0000

Tatu Ylonen <[email-masked]> wrote:

> tell the server what the real cookie is.

If the server does the faking, the client doesn't have to transmit
any auth data _at all_. The X connections forwarded over the
protocol are unauthenticated - this is why I said it makes the
protocol simpler.

The server validates and removes the auth data it receives from the
remote X client. The client inserts valid auth data for the local X
server. The client need not invent anything faked at all.

> The reason for doing the faking in the client was that many people
> keep their X logins open for days/weeks/months.

This is an excellent argument against transmitting the real cookie
to the server. But it doesn't follow that a fake cookie must be
transmitted in its place. My scheme suggests that the client
transmits _no_ cookie.

> I don't think it is adding/removing any complexity in the protocol.
> The originator address is there for e.g. debugging/logging purposes
> anyway, so I don't think any change would simplify the protocol.

... see above. The complexity removed is the auth component of the
original request for X forwarding.

(I'm not actually arguing very hard for this any more; I'm just
trying to correct misunderstandings.)

Cheers,
Simon
-- 
Simon Tatham         "The distinction between the enlightened and the
<[email-masked]>    terminally confused is only apparent to the latter."

---

From: Tatu Ylonen <[email-masked]>
Date: Thu, 25 Jan 2001 19:48:55 +0200 (EET)

> worked fine if the server had handled authentication at its end.

I've always throught that authentication is a policy of the X server
(which typically runs on the same machine as the SSH client).  If one uses
an unusual (non-MIT-MAGIC-COOKIE-1) authentication, one has an unusual X
server (i.e., on the same machine as the SSH client).

In my opinion we are entering an area of complexity with the X11
forwarding issues that is not a really a problem for practical deployment
but that we could spend weeks discussing, and might still not get the
right solution.

I would vote to not change the documents related to this at this time.  I
don't think we should delay the standard because of this, and I don't
think we should make any hasty modifications here.

Note also that since the cookies are encrypted by secure shell, and the
real cookie is never sent over the X11 forwarding tunnel, the more
advanced (e.g. DES-based) authentication methods don't actually provide
very much additional security.

> authentication or not (because at least one of the client and server

If someone wants to experiment with this, support for it can be easily
negotiated by first trying to connect with a new channel type that implies
support for server-side faking (e.g., "[email-masked]"), and if
the server rejects the channel open request, then fall back to the
ordinary "x11" channel type and protocol.  If it turns out to be very
useful, it could later become either an informational RFC or be added to
the standard at a later stage.

    Tatu

---

From: Tatu Ylonen <[email-masked]>
Date: Thu, 25 Jan 2001 23:14:24 +0200 (EET)

> protocol are unauthenticated - this is why I said it makes the

It is also very different from the way the current installed base (which
is rather large) uses...

> transmitted in its place. My scheme suggests that the client

Ok, sorry, I didn't understand that.  I now think the two methods are
roughly equivalent in advantages/disadvantages (each some advantages and
disadvantages).

I would prefer not to introduce an unnecessary incompatibility and change
at this stage unless there is some very pressing reason to do so.

    Tatu

---

From: [email-masked] (Niels M�ller)
Date: 26 Jan 2001 12:59:22 +0100

> think we should make any hasty modifications here.

Although I think the scheme described by Simon Tatham is better, I
agree that we should not delay the standard because of this.

/Niels

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Fri, 26 Jan 2001 07:11:20 -0700

> agree that we should not delay the standard because of this.

I agree.  We should not delay moving the drafts forward
because of this issue.

Jeff P. Van Dyke
[email-masked]