Hi Alan, Thank you for the response. Please see responses below.
On 28/06/2018, 14:22, "Alan DeKok" <[email protected]> wrote: On Jun 28, 2018, at 2:03 AM, Douglas Gash (dcmgash) <[email protected]> wrote: > > Dear Opsawg, > > The TACACS+ Draft Version 9 contains a security section, the last three subsections of which are recommendations. There is some overlap and repetition between sections where the same issues are covered from different angles, which we believe may lead to ambiguity. > > So instead we propose to refactor the recommendations section to bring recommendation points of each aspect into their own subsections, as below. There are common requirements for client-server connections. However, there are different security requirements for clients and servers. Even the new text you propose below makes this clear. I think that merging such text into one section makes the requirements less clear. I can see what you mean, especially in the Client-Server connection subsection. I propose to split this subsection in view of your comments. > Please note that this section is within the context of the security section, where the security vulnerabilities are discussed in sections 9.1-9.4. The new text has many long sentences, and a generally "conversational" feel. i.e. it's not simple, short, and technical. That is a fair comment. The intent was to provide a “Because of X, then do Y” pattern, but it does result in an overly dialectic result. We will refactor to provide more focus on the “do Y” part, but look to enhance the detail of the Y. > This new model should replace sections 9.5-9.7. > > Many thanks. > > Proposed recommendations section follows: > > > > 9.5 Deployment Best Practices > > In view of the observations about the security issues described above, it is critical that TACACS+ MUST BE deployed over secure networks which ensure an appropriate level of privacy and integrity of the communication. I'm not sure "appropriate" is the nest word here. It's vague, non-technical, and entirely unhelpful to the reader. In contrast, the earlier text was clearer: Agreed. It will be removed. TACACS+ MUST BE employed over networks which ensure privacy and integrity of the communication. I find that the draft has gone *backwards* here, by removing technical and descriptive text. > Two methods are used in common practice. The preferred method, where such a facility is available in the organization, is to use a dedicated secure management network. Where this is not available, it is recommended to use IPSec. > > In summary: It is strongly advised that TACACS+ MUST be used within a secure deployment. Failure to do so may impact overall network security. "strongly advised that you MUST do something" ? This statement is contradictory and unclear. Agreed. Propose to distill to: “In summary: TACACS+ MUST be used within a secure deployment. Failure to do so may impact overall network security.” > 9.5.1 Client-Server Connections > > In order to help administrators to protect against brute-force attacks from unknown clients, TACACS+ Servers MUST allow the definition of individual clients and MUST allow a dedicated secret key to be defined for each client. How does defining individual clients or secrets protect against "brute-force" attacks? Is this not just listing known clients, and rejecting connections from unknown clients? To be fair the claim is caveated to say to protect against "brute-force attacks from unknown clients", but I do agree that as you say, it does mean simply rejecting from unknown clients. Another example of “Because of X, then do Y”. We will refocus this to the “do Y” part, but include the part about unknown clients”. The earlier text was clearer: Servers MUST be configured with a list of known clients. Servers MUST be configured to reject requests from clients not on the list. A unique secret key SHOULD be configured for every individual client. > With these mandatory requirements in place, the following recommendations should be followed: > > Configure Servers to accept only those network connection attempts that arrive from known clients. This limits the exposure and prevents remote brute force attacks from unknown clients. Is this "configure" a requirement on implementors or administrators? And why not use mandatory language here, as was used in draft-06? The current text is not very prescriptive. The intent overall is: Implement this so that administrators can configure that. But the whole section needs to be taken together to implicitly deduce this, I take the point that a little extra text will make each part of the section more explicitly clear. > Configure a secret key on the server for each client. It is recommended that Servers SHOULD warn administrators if secret keys are not unique per client. "it is recommended" is redundant with "SHOULD" Agreed. > Configure Server to reject connections which have the TAC_PLUS_UNENCRYPTED_FLAG. Servers SHOULD allow administrators to reject those packets with applicable ERROR response for type of packet. Consequently, clients should avoid using TAC_PLUS_UNENCRYPTED_FLAG, even on networks with secured transport. In summary: do not use the TAC_PLUS_UNENCRYPTED_FLAG option. Is this "configure" a requirement on administrators? Do administrators have to read the RFCs in order to configure the systems correctly? It is a valid point. I think it is fair to say the implementations SHOULD indicate that administrators SHOULD not configure the unencrypted option. I don’t think that either of the two SHOULDs should be a M UST, but possibly the first could be. Or should implementors make the software do this by default? I’m not sure we can do that, because it would require a default secret, and that would contravene most security analysis for an implementation. But would welcome proposals. And the redundancy continues: " clients should avoid using " .. "In summary: do not use " Agreed. The text is vague, rambling, and redundant. > Will remove the redundancy. > The strongest authentication options in the TACACS+ protocol are the challenge-response options (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for authen_type). Consequently, The Server implementation MUST allow the administrator to mandate that only these challenge/response options will be accepted for authentication. > > It is recommended that administrators use this option. Administrators should allow other options only when unavoidable due to requirements of identity/password systems. Is there prescriptive text here instead of "it is recommended"? Maybe SHOULD ? Agreed. > Due to their security implications, the TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in the original draft should not be used. Maybe "MUST NOT be used" ? I would agree to it, but we may need wider consensus. Do we have any options between MUST and SHOULD ;-) > 9.5.4 Authorization Options > > The authorization and accounting features are intended to provide extensible 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 MUST ensure that the attribute and value pairs shared between the clients and servers have consistent interpretation. > > If a client 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. > > Require TACACS+ authentication for authorization requests (i.e. TAC_PLUS_AUTHEN_METH_TACACSPLUS is used). That last sentence seems unfinished. Agreed. The sentence has dropped a subject, will re-install one. > 9.5.5 The Redirection Mechanism > > The redirection mechanism (TAC_PLUS_AUTHEN_STATUS_FOLLOW) that was defined in the original draft is difficult to secure. It is recommended to disable the feature, and so to avoid its use altogether. It is recommended that clients treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. Is there prescriptive text here instead of "it is recommended"? Earlier text had such prescriptive text. Agreed, I will add the prescriptive text to be consistent with the body of the document. > If the option must be used for legacy application reasons, then it is recommended to avoid the option to send secret keys in the server list. Again, "it is recommended" The new text is a step backwards from earlier drafts. I've taken a look at the rest of Section 9, and it's similar. As an implementor, this text gives me only vague guidance as to what to do. With less clarity and fewer prescriptions than earlier text. I've said before that the text is philosophical and conversational instead of technical. This style is continuing with new text. The other parts of section 9 will be addressed in another thread, but both they and this section will be addressed with your comments as above ASAP. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
