4. Description
The pre-authentication mechanism for SSH takes the existing exchange
of client and server ID strings and adds a simple challenge/response
to them, preventing the exchange of any SSH handshake messages unless
the pre-authentication succeeds. It does this by adding a random
challenge in the Comment field of the server's SSH ID, with the
client responding with the respose in the comment field of its SSH
ID. The server challenge in the comment field is denoted with
'C=<challenge>' and the client response with 'R=<response>'. These
MUST be the first values in the Comment field, with any further
extries that follow separated by either a comma or a space.
i think this is overly rigid. it turns the comment field into an extensibility mechanism, but with other extensions as second-class citizens. if every such extension does this, you can never use more than one, because they all want to be first.
I think it is worth noting (in the draft) that using the comment field like this risks interop issues with implementations that don't handle it correctly. That may be acceptable here, because any such implementation won't be able to give a valid response anyway, but may be an issue for others who follow this example. For that matter, it may be an issue here, in the scenario where you only want to require valid preauth from clients on an external network.
If password authentication is being used the HMAC key is:
key = SHA256( string challenge
string username
string password )
This doesn't work. The server cannot compute or validate such a challenge, because it almost never knows the password.
If public-key authentication is being used the HMAC key is:
key = SHA256( string challenge
string username
string publickey )
Which public key? The public key userauth method requires the client to specify which key is used.
for that matter, which user? I see no mechanism for the client to indicate either the username it will connect as or the userauth method(s) it intends to use. These things are not known in advance to the server.
Following Grigg's Law, "There is only one mode and that is secure",
the pre-authentication mechanism hardcodes use of SHA256, the de
facto universal standard hash in SSH implementations.
Under that philosophy, you don't get to have this extension at all, because extensibility is inherently bad, and you don't get to rev the protocol version and require that everyone implement your feature in order to get whatever's in the version after yours.
This needs algorithm negotiation, even if it's just the server saying "use this hash" or the client saying "this is what i used".
-- Jeff