Re: [OPSAWG] Start of WGLC for TACACS+ document.

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

Many thanks Alan for the thorough review.

We¹ll collate all your comments and respond shortly.

On 12/10/2016 22:35, "Alan DeKok" <[e-mail]> wrote:

>  My $0.02 on the contents of the Security Considerations section.   I'm
>sure I've missed things.
>
>  Please also comment if the suggestions here are wrong or unworkable.
>
>----
>9. Security Considerations
>
>The protocol described in this document has been in widespread use
>since specified in "The Draft" (1998).  However it does not meet
>modern security standards, and faces vulnerabilities with privacy and
>authenticity.
>
>This section describes issues with the TACACS+ specification, then the
>protocol, deployments, followed by recommendations for implementations.
>
>Because of the security issues with TACACS+, the authors intend to
>follow up this document with an enhanced specification of the
>protocol employing modern security mechanisms.
>
>
>9.1 Security of The Draft Specification
>
>TACACS+ was originally specified in "The Draft" (1998).  However, this
>draft is incomplete, and leaves key points unspecified.  As a result,
>software authors have had to make implementation choices about what
>should, or should not, be done in certain situations.  These
>implementation choices are somewhat constrained by ad hoc
>interoperability tests.  That is, all TACACS+ clients and servers
>interoperate, so there is a rough consensus on how the protocol works.
>
>While the authors have made every effort to maintain compatibility,
>there is no guarantee, however, that this specification matches the
>behavior of current or historical implementations.  We believe that
>any incompatibilites are due to modern security requirements.  We
>therefore suggest that implementors should read this document, and
>verify that their implementations follow the security practices
>recommended here.
>
>
>9.2 Security of The Protocol
>
>The major security issue with the TACACS+ protocol is the ad hoc
>"encryption" defined in Section 3.6.  This "encryption" is more
>properly called "obfuscation", and has had no security analysis.  That
>is, the security or insecurity of the protocol is entirely unknown.
>
>Attacks on cryptographic hashes are well known and are getting better
>with time, as discussed in [RFC4270].  The security of the TACACS+
>protocol is dependent on MD5 [RFC1321], which has security issues as
>discussed in [RFC6151].  It is not known if the issues described in
>[RFC6151] apply to TACACS+.  <<AD: lifted from RFC 6929 Section 11 >>
>
>The choice of encrypting the body but not the packet header is
>unusual.  The lack of security on the packet header means that an
>attacker can modify the header without detection.
>
>For example, a "session_id" can be replaced by an alternate one, which
>could allow an unprivileged administrator to "steal" the authorization
>from a session for a privileged administrator.  An attacker could also
>update the "flags" field to indicate that one or the other end of a
>connection requires TAC_PLUS_UNENCRYPTED_FLAG, which could remove what
>little security is available.
>
>What little security that exists is dependent on implementations
>limiting access to known clients, and on the strenght of the secret
>key.  Attacks who can guess the key or break the obfuscastion method
>can gain unrestricted and undetected access to all TACACS+ traffic.
>This access permits the attacker to execute any command on any system,
>leaving the attacker in complete control of the network.  The negative
>side effects of such a successful attack cannot be overstated.
>
>9.2.1 Security of Authentication Sessions
>
>There are a number of security issues with authentication sessions.
>As the sessions enable the exchange of clear-text passwords, an
>attacker capable of observing the unencrypted traffic or breakign the
>encrypted traffic, can gain complete network access.  Similarly,
>MSCHAPv1 and MS-CHAPv2 offer little additional security, while ARAP is
>insecure and MUST NOT be used.  As of the publication of this
>document, there has been no similar attacks on the CHAP protocol.
>
>Section 4.4.3 permits the redirection of a session to another server
>via the TAC_PLUS_AUTHEN_STATUS_FOLLOW mechanism.  As part of this
>process, the secret key for a new server can be sent to the client.
>This public exchange of secret keys means that once one session is
>broken, it may be possible to leverage that attack to attacking
>connections to other servers.  Section 9.4, below, has recommendations
>for securing this portion of the protocol.
>
>9.2.2 Security of Authorization Sessions
>
>The primary issue with authorization sessions is that unauthenticated
>authorization is allowed.  Almost as bad, authorization is permitted
>where authentication was done by a third party, such as with
>TAC_PLUS_AUTHEN_METH_KRB5.  This third party authentication is based
>entirely on the client claiming that the user has been authenticated,
>and the server trusting that request.  This practice is entirely
>insecure.
>
>There is also no way to cryptographically tie an authorization session
>to a particular authentication session.  That is, when the client
>indicates "authen_method" in the packet header, the authentication and
>authorization sessions are tied together implicitly by the contents of
>the other fields, such as "use", "port", "rem_addr", etc.
>
><<AD: it would be good for Section 5.1 to contain recommendations on
>how the server can use these fields to tie together authentication /
>authorization sessions.  Perhaps recommend that all AAA include a
>"task_id"? >>
>
>The specification allows for the exchange of attribute-value pairs.
>While a few such attributes are defined here, the protocol is
>extensible, and vendors can define their own attributes.  There is no
>registry for such attributes, and in the absence of a published
>specification, no way for a client or server to know the meaning of a
>new attribute.
>
>As a result, vendors SHOULD NOT define new attribute-value pairs,
>unless such pairs are used only to communicate between client and
>server implementations both written by the same vendor.
>
>The "cmd" and "cmd-arg" attributes define shell commands and
>arguments, but does not specify what these are.  The specific
>commands, therefore, are undefined.
>
>
>9.2.3 Security of Accounting Sessions
>
>The security considerations for accounting sessions are largely the
>same as for authorization sessions.  This section describes additional
>issues specific to accounting sessions.
>
>There is no way in TACACS+ to signal that accounting is required.
>There is no way for a server to signal a client how often accounting
>is required.  The accounting packets are received solely at the
>clients discretion.  Adding such functionality would assist with
>auditing of user actions.
>
>The "task_id" field is defined only for accounting packets, and not
>for authentication or authorization packets.  As such, it is difficult
>to correlate accounting data with a previous authentication or
>authorization request.
>
><<AD: re-use the recommendations suggested for Section 5.1, above? >>
>
>
>9.4 Security of Deployments
>
>Due to the above concerns with the protocol, it is critical that it be
>deployed in a secure manner.
>
>Systems using TACACS+ MUST be configured so that TACACS+ traffic is
>secured.  Any user or service who is not interacting with the TACACS+
>protocol MUST NOT be able to observe TACACS+ traffic, even when
>TACACS+ "encryption" is used.
>
>When used inside of enterprises, TACACS+ traffic MUST be sent over
>management networks.  When used on the wider internet, TACACS+ traffic
>MUST be secured via a modern security protocol such as TLS or IPSec.
>As this specification describes the historic protocol, recommendations
>on TLS and IPSec parameters are outside of the scope of this document.
>
>
>9.4 Recommendations for Implementations
>
>The following recommendations are for clients and servers which
>implement the TACACS+ protocol.  These recommendations describe end
>user interaction or user interface design.  While not part of the
>protocol itself, good designs can prevent insecure configurations.
>
>Clients and servers MUST default to rejecting all connections which
>have the TAC_PLUS_UNENCRYPTED_FLAG set.  Clients and servers MAY
>permit such connections when a debugging or test flag is set.  Clients
>and servers MUST NOT run with this flag set in normal environments.
>
>Similarly, the default for both clients and servers MUST be to require
>a secret key when configuring a new server or client.  The secret key
>MUST NOT be empty, and SHOULD be at least eight (8) characters in
>length.  Clients and servers SHOULD permit the user of keys unique to
>each server or client which they are connecting to.  They SHOULD warn
>the administrator if a secret key is re-used.  Documentation for
>implementations SHOULD recommend the use of strong secret keys.
>
>Servers should maintain list of known clients, and reject connections
>which originate from other systems.  Servers SHOULD NOT permit the
>configuration of wildcard clients.  e.g. clients which map to a
>network range.
>
>Where a client or server detects that the secret key is incorrect, it
>SHOULD terminate the underlying TCP connection, and log a message to
>the system administrator.  There is no good reason to keep a
>connection open when the systems are unable to communicate in a
>meaningful fashion.
>
>Implementions MUST default to using TAC_PLUS_AUTHEN_TYPE_CHAP for
>authentication.  We recognize, however, that this authentication
>method is incompatible with many password storage systems.  As a
>result, other authentication methods are still in the protocol, and
>can be used so long as administrators recognize the security issues
>with their use.
>
>Clients MUST default to treating TAC_PLUS_AUTHEN_STATUS_FOLLOW as if
>TAC_PLUS_AUTHEN_STATUS_FAIL had been received instead.  Clients
>SHOULD allow administrators to explicitly enable the
>TAC_PLUS_AUTHEN_STATUS_FOLLOW functionality.  When the functionality
>is enabled, clients SHOULD permit administrators to specify ranges of
>addresses, and/or sets of hosts, along with corresponding secret keys,
>for which redirection will be permitted.  Clients SHOULD ignore
>redirects to hosts which are outside of the pre-configured range or
>list.  Clients SHOULD ignore any key provided via
>TAC_PLUS_AUTHEN_STATUS_FOLLOW, and SHOULD instead use a preconfigured
>key for that host.
>
>For authorization, servers SHOULD default to requiring
>TAC_PLUS_AUTHEN_METH_TACACSPLUS.  Servers SHOULD track authentication
>sessions via methods "to be described" in Section 5.1.
>
>Where a server receives an unknown attribute-value pair, it SHOULD
>reply with TAC_PLUS_AUTHOR_STATUS_FAIL.  Where a server receives an
>unrecognized values in authorization attributes such as "cmd",
>"cmd-arg", "acl", etc., the server SHOULD reply with
>TAC_PLUS_AUTHOR_STATUS_FAIL.  When a client receives an unknown
>authorization attribute, it SHOULD behave as if it had received
>TAC_PLUS_AUTHOR_STATUS_FAIL.
>