On 8/2/18 00:23, Douglas Gash (dcmgash) wrote: > Apologies for the interruption in the conversation. > > Attached should incorporate yours and Alan’s latest comments, and some client > side comments have been addressed. > > Please find attached.
Thanks, Douglas. I read through these changes, and I'm fine with this text. I would like to get Alan's thoughts. Additionally, you should package a new revision of the whole document and submit so we can begin the process of WGLC. Joe > > Many thanks. > > > > > > > > On 16/07/2018, 6:56, "Douglas Gash (dcmgash)" <dcmg...@cisco.com> wrote: > > 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" <jclarke=40cisco....@dmarc.ietf.org> > 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
