On 4/15/18 02:27, Douglas Gash (dcmgash) wrote: > 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.
Thank you, Douglas. My individual comments on this new security requirements section in line below (since you copied it to email). > 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. JC: Disallowed for discouraged? This is a doc defining a currently-deployed protocol. Implementations MAY allow for this to work. However, from a best current practice standpoint, this should be strongly discouraged. > 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. JC: s/Attacks who/Attackers who/ > 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. JC: Your statement makes a lot of sense, but I struggle with how this can be achieved in the current implementation of T+. To use normative language here, you are saying that all T+ servers and all NASes must implement something like an IPSec tunnel to exchange authz details? Again, I get the recommendation, but in light of existing, interoperable implementations, I don't see this being a reality. > 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: JC: Should this be MUST? I ask while still grappling with the use of such strong language for an informational doc citing recommendations when so many existing implementations exist in the wild. > > 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. JC: This dedicated and restricted network, I agree with. This is realistic in the vast majority (if not all) of T+ implementations. But this dedicated network is not necessarily secure in the IPSec sense. I can run a physical wire from all NASes back to my T+ server, but that doesn't mean that the transport ensures integrity or confidentiality. JC: My (contributor) recommendation is to say MUST to this and SHOULD to the encrypted transport given that the latter is likely not done in the majority of deployments today (though I'm willing to hear the argument here). > > 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. JC: s/client and server use of/client and server uses of/ Joe _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
