Thanks Alan…
On 14/07/2018, 15:00, "Alan DeKok" <[email protected]> wrote:
On Jul 14, 2018, at 12:57 AM, Douglas Gash (dcmgash) <[email protected]>
wrote:
>
> Dear Alan,
>
> Do the changes below clarify the intent sufficiently? (please find diff
below) The changes are mainly in first section with a few tweaks in later
sections.
Let's see...
> 9.5 Deployment Best Practices
>
> With respect to 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.
Again "may" is simply not true. It WILL impact network security.
Updated
> The following recommendations impose restrictions on how the protocol is
applied.
>
> The document identifies two constituencies: implementors of TACACS+
components (servers and clients), and administrators of TACACS+ deployments in
the field. The document assumes that it will only be read by the implementors.
That's a problem. As I've been saying for a while now, in many messages,
the document must give guidance for people implementing *and* deploying the
protocol.
Well, I had aligned based upon an earlier comment that we had received for the
draft:
“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.”
The comment was: “Is this "configure" a requirement on administrators? Do
administrators have to read the RFCs in order to configure the systems
correctly?”
I believe that we want to assign the implementors mandatory actions so that the
administrators do not have to read the RFC. But for now, I will drop the
paragraph.
> Mandatory actions are therefore assigned to implementors to either
deprecate insecure features or to steer the administrators to the practices
they should adopt by defaulting to the recommended options and warning when the
restrictions are not adopted.
That sentence follows from the previous mistake. It's also wrong.
It's sufficient to just say "implementors must/should do A, B, and C.
Deployments must/should do D, E, and F".
It's not necessary to describe what the specification is for, or how
specifications are written.
The para is removed.
> Some of the specific requirements mandated for TACACS+ servers and
TACACS+ clients may not be present in currently deployed implementations. New
implementations, and upgrades of current implementations, MUST implement the
recommendations.
>
> 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.
There's no need to keep saying "server implementations". The requirement
is on servers, and it's sufficient to say that.
*TACACS+ servers MUST allow... *
Sure.
> If an invalid shared secret is detected on a connection, TACACS+ server
implementations MUST NOT accept any new sessions on that connection. TACACS+
servers MUST terminate the connection on completion of any sessions that were
previously established with a valid shared secret on that connection.
>
> When a client secret is defined, TACACS+ Server implementations MUST not
use the TAC_PLUS_UNENCRYPTED_FLAG option when processing connections from that
client.
What does it mean to "use" that flag? And what about "processing
connections"? This is all vague and non-technical.
These are issues I've commented on for a *long* time now. I would have
hoped for progress here. A better phrasing is:
*When a client secret is defined, TACACS+ servers MUST NOT accept
connections from that client which have the TAC_PLUS_UNENCRYPTED_FLAG option
set.*
Will adjust along those lines.
How do they do that? It doesn't matter. The spec requires security, and
it's up to whomever (implementation or deployment) to make that happen.
> 9.5.2 Shared Secrets
>
> TACACS+ Server and client implementations MUST treat secrets as sensitive
data to be managed securely.
>
> TACACS+ Server implementations MUST allow a dedicated secret key to be
defined for each client, and the servers SHOULD warn administrators if secret
keys are not unique per client.
>
> TACACS+ server deployment administrators SHOULD always define a secret
for each client.
>
> TACACS+ server deployment administrators SHOULD use secret keys of
minimum 16 characters length.
>
> TACACS+ server deployment administrators SHOULD change secret keys at
regular intervals.
That's all good. It's OK to talk specifically about implementation and
deployments when the requirements are on implementation internals, or on
managing a deployment.
> 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).
NIT: I would sat "allow the administrator to configure that"
Again, "mandate" is philosophical. Administrators "configure"
implementations. They don't "mandate" implementations.
Sure.
> TACACS+ server deployment administrators SHOULD use
"configure". Not "use". I "use" a pencil. I "configure" an
implementation.
TBH, you should audit the document for instances of "use", and replace
them with something more appropriate.
> 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,
That's one instance where "used" is appropriate.
> due to their security implications. TACACS+ server implementations SHOULD
deprecate them, if they are not deprecated, the implementations MUST default to
the options being disabled and MUST warn the user of their security impact if
they are enabled.
That's good.
> 9.5.4 Authorization
>
> The authorization and accounting features are intended to provide
extensibility and 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.
And how is that done? The appropriate IETF answer here is "run away
screaming". :(
i.e. not a subject you want to touch in this draft.
> 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.
I'm wary of the word "behave" here. It seems philosophical again. I
can't offer much better here tho.
“Behave” may lead to adoption n of BDD in T+ clients! I was initially going to
suggest “process the connection as if”, before comment above… so maybe just
change “behave” to “evaluate server response…”
> TACACS+ server deployment administrators SHOULD mandate that TACACS+
authentication was used when processing authorization requests (i.e.
authen_method value is set to TAC_PLUS_AUTHEN_METH_TACACSPLUS).
Again, "mandate".
Why not "administrators SHOULD configure TACACS+ authentication for
processing authorization requests..."
> 9.5.5 Redirection Mechanism
>
> The original draft described a redirection mechanism
(TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to secure. The the
option to send secret keys in the server list is particularly problematic.
nit: "the the".
Will fix.
And why is it problematic? Perhaps "insecure", with an explanation as to
why.
> TACACS+ server implementations SHOULD deprecate the redirection mechanism.
"implementations" is fine here. Perhaps also "SHOULD deprecate the
redirection mechanism, and disable it by default."
> TACACS+ server implementations MUST warn deployment administrators of the
security implications if the option to send the secret keys in the server list
is configured.
Security implications which are...? The draft doesn't say.
Perhaps just "MUST warn administrators that the option is insecure and
should only be used inside of a trusted environment"
> TACACS+ client implementations SHOULD deprecate this feature by treating
TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
Sounds reasonable.
Alan DeKok.
Thanks.
Please see version with revisions below:
9.5 Deployment Best Practices
With respect to 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 will impact overall network security.
The following recommendations impose restrictions on how the protocol is
applied. These restrictions were not imposed in the original draft. New
implementations, and upgrades of current implementations, MUST implement the
recommendations.
9.5.1 Server Side Connections
TACACS+ servers MUST allow the definition of individual clients. The servers
MUST only accept network connection attempts from these defined, known clients.
If an invalid shared secret is detected on a connection, TACACS+ servers MUST
NOT accept any new sessions on that connection. 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+ servers and client MUST treat secrets as sensitive data to be managed
securely.
TACACS+ servers MUST allow a dedicated secret key to be defined for each
client,
TACACS+ servers MUST reject connections with TAC_PLUS_UNENCRYPTED_FLAG set,
when there is a shared secret set on the server for the client requesting the
connection.
TACACS+ servers SHOULD warn administrators if secret keys are not unique per
client.
TACACS+ server deployment administrators SHOULD always define a secret for each
client.
TACACS+ server deployment administrators SHOULD configure secret keys of
minimum 16 characters length.
TACACS+ server deployment administrators SHOULD change secret keys at regular
intervals.
9.5.3 Authentication
TACACS+ servers MUST allow the administrator to configure the server to only
accept challenge/response options for authentication (TAC_PLUS_AUTHEN_TYPE_CHAP
or TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for
authen_type).
TACACS+ server deployment administrators SHOULD enable the option mentioned in
the previous paragraph. TACACS+ Server deployments SHOULD ONLY enable 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. TACACS+
servers SHOULD deprecate them. If they are not deprecated, the servers MUST
default to the options being disabled and MUST warn the administrator that
these options are not secure.
9.5.4 Authorization
The authorization and accounting features are intended to provide extensibility
and flexibility. There is a base dictionary defined in this document, but it
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 receives a mandatory authorization attribute that its
implementation does not define, then it SHOULD evaluate server response as if
it had received TAC_PLUS_AUTHOR_STATUS_FAIL.
TACACS+ server deployment administrators SHOULD configure the server to reject
authorization requests if authen_method value is not 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 insecure, as it
can reveal client shared secrets.
TACACS+ servers SHOULD deprecate the redirection mechanism.
If the redirection mechanism is implemented then TACACS+ servers MUST disable
it by default, and MUST warn deployment administrators that it must only be
enabled within a secure deployment due to the risks of revealing shared secrets.
TACACS+ clients SHOULD deprecate this feature by treating
TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
Diff as follows.
3c3
< With respect to 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.
---
> With respect to 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 will impact overall network security.
5,9c5
< The following recommendations impose restrictions on how the protocol is
applied.
<
< The document identifies two constituencies: implementors of TACACS+
components (servers and clients), and administrators of TACACS+ deployments in
the field. The document assumes that it will only be read by the implementors.
Mandatory actions are therefore assigned to implementors to either deprecate
insecure features or to steer the administrators to the practices they should
adopt by defaulting to the recommended options and warning when the
restrictions are not adopted.
<
< Some of the specific requirements mandated for TACACS+ servers and TACACS+
clients may not be present in currently deployed implementations. New
implementations, and upgrades of current implementations, MUST implement the
recommendations.
---
> The following recommendations impose restrictions on how the protocol is
> applied. These restrictions were not imposed in the original draft. New
> implementations, and upgrades of current implementations, MUST implement the
> recommendations.
13,15c9
< TACACS+ server implementations MUST allow the definition of individual
clients, and the servers MUST only accept network connection attempts from
these defined, known clients.
<
< If an invalid shared secret is detected on a connection, TACACS+ server
implementations MUST NOT accept any new sessions on that connection. TACACS+
servers MUST terminate the connection on completion of any sessions that were
previously established with a valid shared secret on that connection.
---
> TACACS+ servers MUST allow the definition of individual clients. The servers
> MUST only accept network connection attempts from these defined, known
> clients.
17c11
< When a client secret is defined, TACACS+ Server implementations MUST not use
the TAC_PLUS_UNENCRYPTED_FLAG option when processing connections from that
client.
---
> If an invalid shared secret is detected on a connection, TACACS+ servers MUST
> NOT accept any new sessions on that connection. TACACS+ servers MUST
> terminate the connection on completion of any sessions that were previously
> established with a valid shared secret on that connection.
21c15,19
< TACACS+ Server and client implementations MUST treat secrets as sensitive
data to be managed securely.
---
> TACACS+ servers and client MUST treat secrets as sensitive data to be managed
> securely.
>
> TACACS+ servers MUST allow a dedicated secret key to be defined for each
> client,
>
> TACACS+ servers MUST reject connections with TAC_PLUS_UNENCRYPTED_FLAG set,
> when there is a shared secret set on the server for the client requesting the
> connection.
23c21
< TACACS+ Server implementations MUST allow a dedicated secret key to be
defined for each client, and the servers SHOULD warn administrators if secret
keys are not unique per client.
---
> TACACS+ servers SHOULD warn administrators if secret keys are not unique per
> client.
27c25
< TACACS+ server deployment administrators SHOULD use secret keys of minimum 16
characters length.
---
> TACACS+ server deployment administrators SHOULD configure secret keys of
> minimum 16 characters length.
33c31
< 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+ servers MUST allow the administrator to configure the server to only
> accept challenge/response options for authentication
> (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or
> TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for authen_type).
35c33
< TACACS+ server deployment administrators 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.
---
> TACACS+ server deployment administrators SHOULD enable the option mentioned
> in the previous paragraph. TACACS+ Server deployments SHOULD ONLY enable
> other options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or
> TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of
> identity/password systems.
37c35
< TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in
the original draft SHOULD not be used, due to their security implications.
TACACS+ server implementations SHOULD deprecate them, if they are not
deprecated, the implementations MUST default to the options being disabled and
MUST warn the user of their security impact if they are enabled.
---
> TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in
> the original draft SHOULD not be used, due to their security implications.
> TACACS+ servers SHOULD deprecate them. If they are not deprecated, the
> servers MUST default to the options being disabled and MUST warn the
> administrator that these options are not secure.
41c39
< The authorization and accounting features are intended to provide
extensibility and 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.
---
> The authorization and accounting features are intended to provide
> extensibility and flexibility. There is a base dictionary defined in this
> document, but it 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.
43c41
< 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.
---
> If a client receives a mandatory authorization attribute that its
> implementation does not define, then it SHOULD evaluate server response as if
> it had received TAC_PLUS_AUTHOR_STATUS_FAIL.
45c43
< TACACS+ server deployment administrators SHOULD mandate that TACACS+
authentication was used when processing authorization requests (i.e.
authen_method value is set to TAC_PLUS_AUTHEN_METH_TACACSPLUS).
---
> TACACS+ server deployment administrators SHOULD configure the server to
> reject authorization requests if authen_method value is not set to
> TAC_PLUS_AUTHEN_METH_TACACSPLUS.
49c47
< The original draft described a redirection mechanism
(TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to secure. The the
option to send secret keys in the server list is particularly problematic.
---
> 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 insecure, as it
> can reveal client shared secrets.
51c49
< TACACS+ server implementations SHOULD deprecate the redirection mechanism.
---
> TACACS+ servers SHOULD deprecate the redirection mechanism.
53c51
< TACACS+ server implementations MUST warn deployment administrators of the
security implications if the option to send the secret keys in the server list
is configured.
---
> If the redirection mechanism is implemented then TACACS+ servers MUST disable
> it by default, and MUST warn deployment administrators that it must only be
> enabled within a secure deployment due to the risks of revealing shared
> secrets.
55c53
< TACACS+ client implementations SHOULD deprecate this feature by treating
TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
---
> TACACS+ clients SHOULD deprecate this feature by treating
> TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
