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