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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg