Hi,
Below is revised version of the subsection, based upon Alan’s comments,
Many thanks.
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 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.
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.
9.5.2 Shared Secrets
TACACS+ server and client implementations MUST treat shared secrets as
sensitive data to be managed securely.
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.
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.
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.
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 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.
TACACS+ client implementations SHOULD deprecate this feature by treating
TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
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
