Subject: [OPSAWG] TACACS+ information Draft Security Recommendations refactor

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Thu, 28 Jun 2018 06:03:27 +0000

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. 

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.

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. 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.

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. 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.

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.

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.

9.5.2 Secret Key Management

In order to maximize the effectiveness of the obfuscation mechanism, it recommended to use secret keys of minimum 16 characters length.

Secrets MUST be regarded as sensitive data, and managed securely on server and client.

Secret keys should be changed at regular intervals.

If an invalid shared secret is detected, Servers MUST NOT accept any new sessions on a connection, and terminate the connection on completion of any sessions previously established with a valid shared secret.

9.5.3 Authentication options

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.

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. 

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).

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. 

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.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 28 Jun 2018 07:22:02 -0400

> 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.

> 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.
> 

  "strongly advised that you MUST do something" ?

  This statement is contradictory and unclear.

> 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:
> 

  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. Conse…

  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.

> 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" ?

> Require TACACS+ authentication for authorization requests (i.e. TAC_PLUS_AUTHEN_METH_TACACSPLUS is used).

  That last sentence seems unfinished.

> 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…

  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.

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Thu, 28 Jun 2018 14:23:49 +0000

Hi Alan,

Thank you for the response. Please see responses below.

On 28/06/2018, 14:22, "Alan DeKok" <[email-masked]> wrote:

    

I can see what you mean, especially in the Client-Server connection subsection. I propose to split this subsection in view of your comments. 

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.

    
Agreed. It will be removed.

    

Agreed. Propose to distill to: “In summary: TACACS+ MUST be used within a secure deployment.  Failure to do so may impact overall network security.”

    
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 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.

Agreed.

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.

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.

Agreed.

Will remove the redundancy.

Agreed.

I would agree to it, but we may need wider consensus. Do we have any options between MUST and SHOULD ;-)

Agreed. The sentence has dropped a subject, will re-install one.

Agreed, I will add the prescriptive text to be consistent with the body of the document.

    

    
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.