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.
> 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.
> 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:
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.
> 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?
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.
> 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"
> 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?
Or should implementors make the software do this by default?
And the redundancy continues: " clients should avoid using " .. "In summary:
do not use "
The text is vague, rambling, and redundant.
>
> 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
?
> 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" ?
> 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.
> 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.
> 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.
Alan DeKok.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
