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

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

I've thrown together an RFC draft for this, thought I'd post it here for
comment first.  In particular what do people think of the comment in the
security considerations about security tradeoffs?

Peter.

-- Snip --

                 A Pre-Authentication Mechanism for SSH
                      draft-gutmann-ssh-preauth-00

1.  Introduction

   Devices running SSH are frequently exposed on the Internet, either
   because of operational considerations or through misconfiguration,
   making them vulnerable to the constant 3-degree background radiation
   of scanning and probing attacks that pervade the Internet.  This
   document describes a simple pre- authentication mechanism that limits
   these attacks with minimal changes to the SSH implementation, no
   changes to the SSH protocol itself, and no visible changes for the
   user.

2.  Threat Model

   This document considers three different SSH usage scenarios:

   1.  A conventional server, possibly behind a firewall.  Firewall
       rules and security/access-control proxies, if available, can
       handle any required SSH access control.

   2.  An embedded device that, for operational reasons or possibly just
       through misconfiguration, is exposed to the Internet.

   3.  As above, but on a private network that's been penetrated by
       attackers who are probing it for targets.  In other words the
       call is coming from inside the building.

   The pre-authentication mechanism described in this document is
   primarily targeted at the latter two scenarios.

   In addition the document considers two different attacker types:

   1.  The generic three-degree background radiation of non-targeted
       Internet scanning and probing from off-path attackers.  Any pre-
       authentication measure, for example including a static non-public
       value at the start of the handshake, will stop this type of
       attack.

   2.  More targeted attacks from on-path attackers, which require
       something like a challenge/response mechanism to stop.

   This document targets both off-path and on-path attackers.

3.  Requirements

   The mechanism to limit scanning and probing attacks needs to meet the
   following requirements:

   *  It should stop attackers at the gate, preventing probing past the
      first message exchanged.  This both limits information leakage and
      mitigates against exploitation of pre-auth vulnerabilities in
      implementations.

   *  It should require no changes to the SSH protocol, for example the
      addition of new handshake messages or changes to existing
      handshake messages.

   *  It should require no user-visible changes to the operation of an
      SSH client or server, in other words no need to supply additional
      or auxiliary keying material or perform other configuration
      changes.

   In addition to these requirements there are also additional desirable
   properties:

   *  In order to encourage adoption by implementers of embedded SSH, it
      should require minimal effort to retrofit to existing SSH
      implementations, both because embedded systems using SSH are
      frequent targets and because these systems often only have minimal
      effort applied to keep current with new mechanisms.

   Note that although this mechanism can be applied to any SSH
   implementation, its primary intended target is embedded SSH, where
   the usage model is one account/user per device and few if any
   mitigations such as privilege separation or frequent patches to
   address vulnerabilities are possible.

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.

   The challenge is a 64-bit server-generated nonce which is then
   base64-encoded to create a text string suitable for use in the
   Comment field.  This encoded form, and the base64-encoded response
   from the client, are sent without any base64 padding characters '='
   at the end.

   The response to the challenge is a truncated SHA256 HMAC of the
   challenge, with the HMAC key depending on which form of
   authentication the client uses.  The challenge is MAC'd in base64
   form as sent, without decoding back to binary form.

   If password authentication is being used the HMAC key is:

       key = SHA256( string    challenge
                     string    username
                     string    password )

   If public-key authentication is being used the HMAC key is:

       key = SHA256( string    challenge
                     string    username
                     string    publickey )

   The public key rather than the key fingerprint is hashed both because
   the full key is less likely to be known than the identifying
   fingerprint and because differences in fingerprint calculation
   methods and representations would lead to interoperability problems
   across implementations.

   The response is then computed as a truncated HMAC:

       rawResponse = HMAC-SHA256( key, challenge )
       response = base64( rawRespone[ 0...2 ]

   In other words the response is the base64 encoding (without adding
   base64 padding) of the first 24 bits of the HMAC value.

7.  Security Considerations

   As the introduction points out, using this pre-authentication
   mechanism for SSH is not intended to be all things to all people but
   to address a specific problem, stopping scanning and probing attacks
   of SSH-enabled devices at the gates.  It is not intended for use with
   public SSH systems with large numbers of users and/or complex
   authentication requirements, which in any case are expected to have
   up-to-date software and proper mitigations in place.

   The use of existing authentication information presents a slight risk
   that an attacker can mount a dictionary attack on the pre-
   authentication mechanism.  For this reason the MAC key contains both
   the server challenge as a salt and as many unlikely-to-be-known
   values as possible, and only a truncated result is sent to the
   server, leaving a potential dictionary attacker both with multiple
   values to guess and drowning in false positives.  The intent is to
   make a pre-authentication mechanism dictionary attack no more useful
   than a standard dictionary attack while at the same time mitigating
   any pre-auth vulnerabilities that may be present in the SSH handshake
   implementation.

   A second possibility is that a determined on-path attacker who can
   intercept many challenge/response pairs over time can use those to
   reduce the number of false positives.

   // How much of a problem is this really, compared to just running a
   // dictionary attack on the SSH handshake?  It assumes a fairly
   // determined on- path attacker who can record many challenge/
   // response pairs over time, and still only gives a false-positive-
   // riddled offline attack, which is a very targeted attack compared
   // to the scanning/probing that we're trying to defend against, for
   // example see the recent news about KmsdBot compromising SSH-
   // enabled systems which didn't have to go beyond trying a few common
   // passwords.
   //
   // It's also a side-effect of trying to not introduce additional
   // keying material to manage, if you can specify use of a different
   // shared secret for the pre-authentication then this problem goes
   // away, but that's likely to severely limit adoption and use, or
   // lead to use of the password for both pre- authentication and
   // standard authentication anyway even if a separate shared secret is
   // specified.  I'm open to suggestions here, another option is to
   // specify iterated PBKDF2-SHA2 between the key and challenge
   // response.

   To additionally limit the potential for dictionary attacks, it is
   recommended that implementations perform rate-limiting on pre-
   authentication attempts, throttling back responses if too many pre-
   authentication failures occur in a given time interval.

   To further confound attackers, servers may in addition opt to
   continue with an emulated handshake if the pre-authentication fails,
   eventually failing anyway or dropping the attacker into a tarpit.

   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.