Dear Opsawg, The TACACS+ Draft Version 9 contains a security section, the last three subsections of which are recommendations. There is some overlap and repetition between sections where the same issues are covered from different angles, which we believe may lead to ambiguity.
So instead we propose to refactor the recommendations section to bring recommendation points of each aspect into their own subsections, as below. Please note that this section is within the context of the security section, where the security vulnerabilities are discussed in sections 9.1-9.4. This new model should replace sections 9.5-9.7. Many thanks. Proposed recommendations section follows: 9.5 Deployment Best Practices In view of the observations about the security issues described above, it is critical that TACACS+ MUST BE deployed over secure networks which ensure an appropriate level of privacy and integrity of the communication. Two methods are used in common practice. The preferred method, where such a facility is available in the organization, is to use a dedicated secure management network. Where this is not available, it is recommended to use IPSec. In summary: It is strongly advised that TACACS+ MUST be used within a secure deployment. Failure to do so may impact overall network security. 9.5.1 Client-Server Connections In order to help administrators to protect against brute-force attacks from unknown clients, TACACS+ Servers MUST allow the definition of individual clients and MUST allow a dedicated secret key to be defined for each client. With these mandatory requirements in place, the following recommendations should be followed: Configure Servers to accept only those network connection attempts that arrive from known clients. This limits the exposure and prevents remote brute force attacks from unknown clients. Configure a secret key on the server for each client. It is recommended that Servers SHOULD warn administrators if secret keys are not unique per client. Configure Server to reject connections which have the TAC_PLUS_UNENCRYPTED_FLAG. Servers SHOULD allow administrators to reject those packets with applicable ERROR response for type of packet. Consequently, clients should avoid using TAC_PLUS_UNENCRYPTED_FLAG, even on networks with secured transport. In summary: do not use the TAC_PLUS_UNENCRYPTED_FLAG option. 9.5.2 Secret Key Management In order to maximize the effectiveness of the obfuscation mechanism, it recommended to use secret keys of minimum 16 characters length. Secrets MUST be regarded as sensitive data, and managed securely on server and client. Secret keys should be changed at regular intervals. 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. 9.5.3 Authentication options The strongest authentication options in the TACACS+ protocol are the challenge-response options (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for authen_type). Consequently, The Server implementation MUST allow the administrator to mandate that only these challenge/response options will be accepted for authentication. It is recommended that administrators use this option. Administrators should allow other options only when unavoidable due to requirements of identity/password systems. Due to their security implications, the TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in the original draft should not be used. 9.5.4 Authorization Options The authorization and accounting features are intended to provide extensible flexibility. There is a base dictionary defined in this document, but is may be extended in deployments by using new attribute names. The cost of the flexibility is that administrators MUST ensure that the attribute and value pairs shared between the clients and servers have consistent interpretation. If a client receives receiving a mandatory authorization attribute that its implementation does not define, then it should, behave as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL. Require TACACS+ authentication for authorization requests (i.e. TAC_PLUS_AUTHEN_METH_TACACSPLUS is used). 9.5.5 The Redirection Mechanism The redirection mechanism (TAC_PLUS_AUTHEN_STATUS_FOLLOW) that was defined in the original draft is difficult to secure. It is recommended to disable the feature, and so to avoid its use altogether. It is recommended that clients treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. If the option must be used for legacy application reasons, then it is recommended to avoid the option to send secret keys in the server list. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
