Many thanks Alan for the thorough review.
We¹ll collate all your comments and respond shortly.
On 12/10/2016 22:35, "Alan DeKok" <al...@deployingradius.com> 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
>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
>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
>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
>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
>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
><<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
>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
>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
OPSAWG mailing list