On 7/6/18 09:39, Douglas Gash (dcmgash) wrote: > > Hi, > > Below is revised version of the subsection, based upon Alan’s comments, > > Many thanks.
Below are some of my comments. They mainly revolve around the strength of the normative language with respect to the fact that this draft is supported to document the protocol as it is today. To me, the security considerations should reflect best common practices without over-enforcing things that would invalidate current implementations. But I want the WG's thoughts on this. How do we handle the case where we have existing deployments that we want to document while at the same time recommending new _implementations_ do better things? And if new implementations should be using a new security paradigm to be described in a new document, do we need strong normative language in this draft? These comments are my own as a contributor. > > > > > 9.5 TACACS+ Deployment Best Practices > > In view of the observations about the security issues described above, a > network administrator MUST NOT rely on the Maybe "With respect to the observations..." 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. This works for me. The strong normative language makes sense here. > > 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. > > TACACS+ servers MUST NOT accept any new sessions on any connection where an > invalid shared secret is detected. TACACS+ servers MUST terminate the > connection on completion of any sessions that were previously established > with a valid shared secret on that connection. The MUST here seems too strong given that some implementations that are working today may not/may do these things. These don't seem to be things completely within the operator's control as they deploy T+. > > 9.5.2 Shared Secrets > > TACACS+ server and client implementations MUST treat shared secrets as > sensitive data to be managed securely. How is this done? This seems like it could be handled in different ways, and making this a mandatory requirement could invalidate current implementations. That said, I agree that in principle this makes sense. > > TACACS+ server implementations MUST allow a dedicated shared secret to be > defined for each client. The server implementations SHOULD warn > administrators if secret keys are not unique per client. The MUST here again seems that it might preclude existing implementations. > > TACACS+ Server implementations MUST NOT use the TAC_PLUS_UNENCRYPTED_FLAG > option when processing connections from any client when a client secret has > been defined. I agree with this in that in seems like it would be a bug otherwise. > > TACACS+ server administrators SHOULD always define a shared secret for each > client. > > TACACS+ server administrators SHOULD use shared secrets of minimum 16 > characters length. > > TACACS+ server administrators SHOULD change shared secrets at regular > intervals. These seem reasonable. They read more as recommendations. > > 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). Same comment as above that this may be too strong. > > TACACS+ server deployments 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. > > 9.5.4 Authorization > > 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 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. > > TACACS+ server deployments 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 > option to send secret keys in the server list is particularly problematic. > > TACACS+ server implementations SHOULD deprecate the redirection mechanism. > > TACACS+ server implementations MUST warn users of the security implications > if the option to send the secret keys in the server list is configured. Same comment here. > > TACACS+ client implementations SHOULD deprecate this feature by treating > TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. So, again, strong normative language makes sense if I'm building a new implementation, but this is a doc to define the protocol as-is. In light of that, I am asking the WG if we need to go down this path or should we try and focus on recommendations, especially for operators, that can better secure the T+ they have today. Joe > > > > > > > On 28/06/2018, 17:23, "Douglas Gash (dcmgash)" <dcmg...@cisco.com> wrote: > > Hi Alan, > > Thank you for the response. Please see responses below. > > On 28/06/2018, 14:22, "Alan DeKok" <al...@deployingradius.com> wrote: > > On Jun 28, 2018, at 2:03 AM, Douglas Gash (dcmgash) > <dcmgash=40cisco....@dmarc.ietf.org> 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 > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
