Hi Joe,
Thanks for the comments. We will be sending out a new version of the
recommendations section today. It actually intends to clarify in the first
section how the guidance should be interpreted, which I think should allow our
strong recommendations to be kept, as I hope it will answer your question on
current implmentations,
On 09/07/2018, 23:55, "Joe Clarke" <jclarke=40cisco....@dmarc.ietf.org> wrote:
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+.
This is about the implementation, I will clarify it.
>
> 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
