Hi Joe, Thanks Joe, all useful comments. I believe that most of them were caught in the previous upload (in which we responded to Alan’s last mail), I will make sure that any missing are in the next.
On 16/07/2018, 0:20, "Joe Clarke" <[email protected]> wrote: On 7/14/18 00:57, Douglas Gash (dcmgash) wrote: > 9.5 Deployment Best Practices > > With respect to the observations about the security issues described above, a network administrator MUST NOT rely on the obfuscation of the TACACS+ protocol and TACACS+ MUST be deployed over networks which ensure privacy and integrity of the communication. TACACS+ MUST be used within a secure deployment. Failure to do so may impact overall network security. Agree with Alan that failure to deploy T+ securely _will_ impact overall network security. > > The following recommendations impose restrictions on how the protocol is applied. > > The document identifies two constituencies: implementors of TACACS+ components (servers and clients), and administrators of TACACS+ deployments in the field. The document assumes that it will only be read by the implementors. Mandatory actions are therefore assigned to implementors to either deprecate insecure features or to steer the administrators to the practices they should adopt by defaulting to the recommended options and warning when the restrictions are not adopted. I assume that administrators _will_ read this document. Why wouldn't they if it has guidance that will help them make their T+ deployments more secure? My comment is I would remove that sentence, as well as the "therefore" in the sentence after it. > > Some of the specific requirements mandated for TACACS+ servers and TACACS+ clients may not be present in currently deployed implementations. New implementations, and upgrades of current implementations, MUST implement the recommendations. > > 9.5.1 Server Side Connections > > TACACS+ server implementations MUST allow the definition of individual clients, and the servers MUST only accept network connection attempts from these defined, known clients. > > If an invalid shared secret is detected on a connection, TACACS+ server implementations MUST NOT accept any new sessions on that connection. TACACS+ servers MUST terminate the connection on completion of any sessions that were previously established with a valid shared secret on that connection. > > When a client secret is defined, TACACS+ Server implementations MUST not use the TAC_PLUS_UNENCRYPTED_FLAG option when processing connections from that client. > > 9.5.2 Shared Secrets > > TACACS+ Server and client implementations MUST treat secrets as sensitive data to be managed securely. > > TACACS+ Server implementations MUST allow a dedicated secret key to be defined for each client, and the servers SHOULD warn administrators if secret keys are not unique per client. > > TACACS+ server deployment administrators SHOULD always define a secret for each client. > > TACACS+ server deployment administrators SHOULD use secret keys of minimum 16 characters length. > > TACACS+ server deployment administrators SHOULD change secret keys at regular intervals. I'm not sure you need to keep saying, "server deployment administrators". Seems like "server administrators" is clear enough. > > 9.5.3 Authentication > > TACACS+ server implementations MUST allow the administrator to mandate that only challenge/response options will be accepted for authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for authen_type). > > TACACS+ server deployment administrators SHOULD use the option mentioned in the previous paragraph. TACACS+ Server deployments SHOULD ONLY use other options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of identity/password systems. > > TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in the original draft SHOULD not be used, due to their security implications. TACACS+ server implementations SHOULD deprecate them, if they are not deprecated, the implementations MUST default to the options being disabled and MUST warn the user of their security impact if they are enabled. > > 9.5.4 Authorization > > The authorization and accounting features are intended to provide extensibility and 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 and implementors MUST ensure that the attribute and value pairs shared between the clients and servers have consistent interpretation. > > If a client implementation 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. Receives receiving? That should be reworded. > > TACACS+ server deployment administrators SHOULD mandate that TACACS+ authentication was used when processing authorization requests (i.e. authen_method value is set to TAC_PLUS_AUTHEN_METH_TACACSPLUS). > > 9.5.5 Redirection Mechanism > > The original draft described a redirection mechanism (TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to secure. The the option to send secret keys in the server list is particularly problematic. You have "The the". Remove the second "the". Joe _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
