Hello, T+ authors. Did you have a chance to read over my comments below? What thoughts do you have? Some of these points admittedly need some discussion.
Thanks. Joe On 4/30/18 10:30, Joe Clarke wrote: > 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
