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
