I'm not sure that any part of RFC 4253 specifies that you must disconnect if a message contains additional info that you don't recognize. The security benefits of doing so are dubious. If there's any way that this could be exploited, it means you (or the other party) have much bigger issues. On the other hand, by implementing this, you absolutely guarantee that future extensibility is impossible without additional signaling.
That being said, my anger is misplaced because if you didn't pull this, someone else would, and god knows there's any number of implementations out there that do... things.
The flaw is really in the protocol, which doesn't provide room for this additional signaling. In hindsight, the SERVICE_REQUEST and SERVICE_ACCEPT messages are useless. They waste an entire roundtrip on the idea that there might be other services for the client to request than user authentication. A decade later, there aren't any such services.
The very least that these messages could have done was add a simple name-list of extensions supported. In that case, at least, this extra round trip would be useful for extension signaling.
You propose signaling via a "publickey2" method. Unfortunately, this still requires the client to waste a round-trip: either by requesting "none" authentication to discover methods supported, or by requesting "publickey2" authentication and finding that it isn't supported.
I think the SSH_MSG_IGNORE strategy is superior - it allows the client to immediately fire the correct public key authentication request with signature.
----- Original Message -----
From: Damien Miller
Sent: Thursday, November 5, 2015 20:19
To: denis bider
Subject: Re: OpenSSH sabotages protocol extension
On Thu, 5 Nov 2015, denis bider wrote:
> Obviously, same thing for SSH2_MSG_USERAUTH_FAILURE:
>
>
> authlist = packet_get_string(NULL);
> partial = packet_get_char();
> packet_check_eom();
RFC4242 section 5.1. I'll quote it for you:
> 5.1. Responses to Authentication Requests
>
> If the server rejects the authentication request, it MUST
respond
> with the following:
>
> byte SSH_MSG_USERAUTH_FAILURE
> name-list authentications that can continue
> boolean partial success
Note the lack of extension fields and the "MUST".
> Awesome work, guys! You have locked down every possible clean way that
the
> protocol could be extended, so as to spare the client several
round-trips to
> discover which signing algorithms it can use for RSA keys.
It sounds like you want to redefine the information flow of public
key
authentication. If you want to do this (and I don't think it is a
good
idea - I'll comment separately on the draft), then the right way to
do
it is to design a new authentication method that can be negotiated by
implementations that support it.
By implementing a new "publickey2" (or whatever) method, you get to
define new SSH_MSG_USERAUTH messages, which is basically what you are
trying to do here.
> You've made it so that the only way to convey such information, and
not risk
> a client disconnect, is to use a specially crafted
SSH_MSG_IGNORE.
Again, RFC4252 made it this way. We just implemented it as it was
written.
-d