Re: An additional-auth mechanism for SSH to protect against scanning/probing attacks

On Wed, Dec 7, 2022, 01:43 Peter Gutmann <[email protected]> wrote:

>
> 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

>