Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt

["Douglas Gash (dcmgash)" <[e-mail]>]

Hello Opsawg,

We have uploaded a new version of the TACACS+ informational draft which includes corrections for typos over the document as a whole, but also revised the security section. We anticipate this security section will get most comments, so it is reproduced below.

We will endeavor to be much more reactive to comments, whether on section below, or any other in rest of uploaded document.

Many thanks,

The authors.



9.  TACACS+ Security Considerations

   The original TACACS+ Draft[1] from 1998 did not address all of the
   key security concerns which are considered when designing modern
   standards.  This section addresses known limitations and concerns
   which will impact overall security of the protocol and systems where
   this protocol is deployed to manage central authentication,
   authorization or accounting for network device administration.

   Multiple implementations of the protocol described in the draft[1]
   have been deployed.  As the protocol was never standardized, current
   implementations may be incompatible in non-obvious ways, giving rise
   to additional security risks.  This section does not claim to
   enumerate all possible security vulnerabilities.

9.1.  General Security of The Protocol

   TACACS+ protocol does not include a security mechanism that would
   meet modern-day requirements.  Support for MD5-based crypto pad
   encryption fails to provide any kind of transport integrity, which
   presents at least the following risks:

      Accounting information may be modified by the man-in-the-middle
      attacker, making such logs unsuitable and untrustable for auditing
      purposes.

      Only the body of the request is encrypted which leaves all header
      fields open to trivial modification by the man-in-the-middle
      attacker.  For this reason, connections with
      TAC_PLUS_UNENCRYPTED_FLAG are disallowed, as mentioned in the
      recommendations section.

      Invalid or misleading values may be inserted by the man-in-the-
      middle attacker in various fields at known offsets to try and
      circumvent the authentication or authorization checks even inside
      the encrypted body.

   While the protocol provides some measure of transport privacy, it is
   vulnerable to at least the following attacks:

      Brute force attacks exploiting increased efficiency of MD5 digest
      computation.

      Known plaintext attacks which may decrease the cost of brute force
      attack.

      Chosen plaintext attacks which may decrease the cost of a brute
      force attack.

      No forward secrecy.

   Even though, to the best knowledge of authors, this method of
   encryption wasn't rigorously tested, enough information is available
   that it is best referred to as "obfuscation" and not "encryption".

   For these reasons, users deploying TACACS+ protocol in their
   environments MUST limit access to known clients and MUST control the
   security of the entire transmission path.  Attacks who can guess the
   key or otherwise break the obfuscation will gain unrestricted and
   undetected access to all TACACS+ traffic.  Ensuring that a
   centralized AAA system like TACACS+ is deployed on a secured
   transport is essential to managing security risk of such an attack.

   The following parts of this section enumerate only the session-
   specific risks which are in addition to general risk associated with
   bare obfuscation and lack of integrity checking.

9.2.  Security of Authentication Sessions

   Authentication sessions SHOULD NOT be used via insecure transport as
   the man-in-the-middle attack may completely subvert them.  Even CHAP,
   which may be considered resistant to password interception, is unsafe
   as it does not protect the username from a trivial man-in-the-middle
   attack.

   This document deprecates the redirection mechanism using the
   TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the
   original draft.  As part of this process, the secret key for a new
   server was sent to the client.  This public exchange of secret keys
   means that once one session is broken, it may be possible to leverage
   that key to attacking connections to other servers.  This mechanism
   SHOULD NOT be used in modern deployments.  It MUST NOT be used
   outside a secured deployment.

9.3.  Security of Authorization Sessions

   Authorization sessions MUST be used via secure transport only as it's
   trivial to execute a successful man-in-the-middle attacks that
   changes well-known plaintext in either requests or responses.

   As an example, take the field "authen_method".  It's not unusual in
   actual deployments to authorize all commands received via the device
   local serial port (a console port) as that one is usually considered
   secure by virtue of the device located in a physically secure
   location.  If an administrator would configure the authorization
   system to allow all commands entered by the user on a local console
   to aid in troubleshooting, that would give all access to all commands
   to any attacker that would be able to change the "authen_method" from
   TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE.  In
   this regard, the obfuscation provided by the protocol itself wouldn't
   help much, because:

      Lack of integrity means that any byte in the payload may be
      changed without either side detecting the change.

      Known plaintext means that an attacker would know with certainty
      which octet is the target of the attack (in this case, 1st octet
      after the header).

      In combination with known plaintext, the attacker can determine
      with certainty the value of the crypto-pad octet used to obfuscate
      the original octet.

9.4.  Security of Accounting Sessions

   Accounting sessions are not directly involved in authentication or
   authorizing operations on the device.  However, man-in-the-middle
   attacker may do any of the following:

      Replace accounting data with new valid or garbage which prevents
      to provide distraction or hide information related to their
      authentication and/or authorization attack attempts.

      Try and poison accounting log with entries designed to make
      systems behave in unintended ways (which includes TACACS+ server
      and any other systems that would manage accounting entries).

   In addition to these direct manipulations, different client
   implementations pass different fidelity of accounting data.  Some
   vendors have been observed in the wild that pass sensitive data like
   passwords, encryption keys and similar as part of the accounting log.
   Due to lack of strong encryption with perfect forward secrecy, this
   data may be revealed in future, leading to a security incident.

9.5.  TACACS+ Client Implementation Recommendations

   The following recommendations are made when implementing a TACACS+
   client:

      Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks
      that are considered secure.

      Treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as
      TAC_PLUS_AUTHEN_STATUS_FAIL.

      If receiving an unknown mandatory authorization attribute, behave
      as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL.

9.6.  TACACS+ Server Implementation Recommendations

   The following recommendations are made when implementing a TACACS+
   server:

   The Server SHOULD NOT accept any connections which have the
   TAC_PLUS_UNENCRYPTED_FLAG set and SHOULD reject those packets with
   applicable ERROR response for type of packet.

   The configuration of dedicated secret keys per individual client MUST
   be supported by the Server implementation.  It is also recommended
   that Servers SHOULD warn administrators if secret keys are not unique
   per client.

   If an invalid shared secret is detected, Servers MUST NOT accept any
   new sessions on a connection, and terminate the connection on
   completion of any sessions previously established with a valid shared
   secret.

   The Server implementation must allow the administrator to mandate:

   TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type

   TAC_PLUS_AUTHEN_METH_TACACSPLUS for authen_method in authorization

   Minimum length for shared secrets.

9.7.  TACACS+ Deployment Best Practices

   Due to above observations about the TACACS+ protocol, it is critical
   to only deploy it using secure transport.  A secure transport for
   TACACS+ is defined as any means that ensure privacy and integrity of
   all data passed between clients and servers.  There are multiple
   means of achieving this, all of them beyond the scope of this
   document.

   Symmetric encryption key represents a possible attack vector at the
   protocol itself.  For this reason, servers SHOULD accept only those
   network connection attempts that arrive from known clients.  This
   limits the exposure and prevents remote brute force attacks from
   unknown clients.

   Due to the security deficiencies of the protocol, it is critical that
   it be deployed in a secure manner.  The following recommendations are
   made for those deploying and configuring TACACS+ as a solution for
   device administration:

      Secure the Deployment: TACACS+ MUST BE deployed over networks
      which ensure an appropriate privacy and integrity of the
      communication.  The way this is ensured will depend upon the
      organizational means: a dedicated and secure management network
      where available in enterprise deployments, or IPsec where
      dedicated networks are not available.

      Do not use the TAC_PLUS_UNENCRYPTED_FLAG option.

      Always configure a secret key (recommended minimum 16 characters)
      on the server for each client.

      Consider shared secrets to be sensitive data, and manage securely
      on server and client.

      Change secret keys at regular intervals.

      Do not use TAC_PLUS_AUTHEN_SENDAUTH or TAC_PLUS_AUTHEN_SENDPASS
      options.

      Use TAC_PLUS_AUTHEN_TYPE_CHAP or MS_CHAP options for authen_type
      where possible.  Use other options only when unavoidable due to
      requirements of identity/password systems.

      Require TACACS+ authentication for authorization requests (i.e.
      TAC_PLUS_AUTHEN_METH_TACACSPLUS is used).

      Do not use the redirection mechanism
      (TAC_PLUS_AUTHEN_STATUS_FOLLOW).  Specifically avoid the option to
      send secret keys in the server list.

      Take case when applying extensions to the dictionary of
      authorization/accounting arguments.  Ensure that the client and
      server use of new argument names are consistent.

   In summary: It is strongly advised that TACACS+ MUST be used within a
   secure deployment.  Failure to do so may impact overall network
   security.