Apologies for the interruption in the conversation.
Attached should incorporate yours and Alan’s latest comments, and some client
side comments have been addressed.
Please find attached.
Many thanks.
On 16/07/2018, 6:56, "Douglas Gash (dcmgash)" <dcmg...@cisco.com> wrote:
Hi Joe,
Thanks Joe, all useful comments. I believe that most of them were caught in
the previous upload (in which we responded to Alan’s last mail), I will make
sure that any missing are in the next.
On 16/07/2018, 0:20, "Joe Clarke" <jclarke=40cisco....@dmarc.ietf.org>
wrote:
On 7/14/18 00:57, Douglas Gash (dcmgash) wrote:
> 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.
Agree with Alan that failure to deploy T+ securely _will_ impact overall
network security.
>
> 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.
I assume that administrators _will_ read this document. Why wouldn't
they if it has guidance that will help them make their T+ deployments
more secure?
My comment is I would remove that sentence, as well as the "therefore"
in the sentence after it.
>
> 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.
>
> 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.
>
> 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.
I'm not sure you need to keep saying, "server deployment
administrators". Seems like "server administrators" is clear enough.
>
> 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 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.
>
> 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.
>
> 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.
>
> 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.
Receives receiving? That should be reworded.
>
> 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).
>
> 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.
You have "The the". Remove the second "the".
Joe
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 these
recommendations.
9.5.2 Shared Secrets
TACACS+ servers and clients MUST treat shared secrets as sensitive data to be
managed securely, as would be expected for passwords, hashes, etc. TACACS+
servers MUST not leak sensitive info (for example, expose shared secrets in
logs)
TACACS+ servers MUST allow a dedicated secret key to be defined for each
client,
TACACS+ servers SHOULD warn administrators if secret keys are not unique per
client.
TACACS+ server administrators SHOULD always define a secret for each client.
TACACS+ servers and clients MUST support shared keys that are at least 32
characters long.
TACACS+ clients SHOULD NOT allow servers to be configured without shared secret
key, or shared key that is less than 16 characters long.
TACACS+ server administrators SHOULD configure secret keys of minimum 16
characters length.
TACACS+ server administrators SHOULD change secret keys at regular intervals.
9.5.3 Connections
TACACS+ servers MUST allow the definition of individual clients. The servers
MUST only accept network connection attempts from these defined, known clients.
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.
If an invalid shared secret is detected when processing packets for a client,
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.
TACACS+ clients MUST NOT set TAC_PLUS_UNENCRYPTED_FLAG when a secret is
defined. Clients MUST be implemented in a way that requires explicit
configuration to enable the use of TAC_PLUS_UNENCRYPTED_FLAG.
In the following cases:
- Packet received from the server configured with shared key, but with
TAC_PLUS_UNENCRYPTED_FLAG set.
- Packet received from the server configured not to use obfuscation but with
TAC_PLUS_UNENCRYPTED_FLAG not set.
TACACS+ clients MUST close TCP session, stop all further processing of the
packet data and process the response in the same way that a
TAC_PLUS_AUTHEN_STATUS_FAIL (authentication sessions) or
TAC_PLUS_AUTHOR_STATUS_FAIL (authorization sessions) was received
9.5.4 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 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.
TACACS+ server administrators MUST NOT allow the same credentials to be applied
in challenge-based (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or
TAC_PLUS_AUTHEN_TYPE_MSCHAPV2) and non challenge-based authen_type options as
the insecurity of the latter will compromise the security of the former.
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 NOT implement them. If they must be implemented, the servers
MUST default to the options being disabled and MUST warn the administrator that
these options are not secure.
9.5.4 Authorizatio
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.
TACACS+ clients that receive an unrecognised mandatory attribute MUST evaluate
server response as if they received TAC_PLUS_AUTHOR_STATUS_FAIL.
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 TACACS+ server 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 RecommendationsPrev1.txt Recommendations.txt
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.
5c5
< The following recommendations impose restrictions on how the protocol is
applied.
---
> 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
> these recommendations.
7c7
< 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.
---
> 9.5.2 Shared Secrets
9c9
< 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.
---
> TACACS+ servers and clients MUST treat shared secrets as sensitive data to be
> managed securely, as would be expected for passwords, hashes, etc. TACACS+
> servers MUST not leak sensitive info (for example, expose shared secrets in
> logs)
11c11
< 9.5.1 Server Side Connections
---
> TACACS+ servers MUST allow a dedicated secret key to be defined for each
> client,
13c13
< 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 SHOULD warn administrators if secret keys are not unique per
> client.
15c15
< 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+ server administrators SHOULD always define a secret for each client.
17c17
< When a client secret is defined, TACACS+ Server implementations MUST not use
the TAC_PLUS_UNENCRYPTED_FLAG option when processing connections from that
client.
---
> TACACS+ servers and clients MUST support shared keys that are at least 32
> characters long.
19c19,25
< 9.5.2 Shared Secrets
---
> TACACS+ clients SHOULD NOT allow servers to be configured without shared
> secret key, or shared key that is less than 16 characters long.
>
> TACACS+ server administrators SHOULD configure secret keys of minimum 16
> characters length.
>
> TACACS+ server administrators SHOULD change secret keys at regular intervals.
>
> 9.5.3 Connections
21c27
< TACACS+ Server and client implementations MUST treat secrets as sensitive
data to be managed securely.
---
> TACACS+ servers MUST allow the definition of individual clients. The servers
> MUST only accept network connection attempts from these defined, known
> clients.
23c29
< 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 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.
25c31
< TACACS+ server deployment administrators SHOULD always define a secret for
each client.
---
> If an invalid shared secret is detected when processing packets for a client,
> 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.
27c33
< TACACS+ server deployment administrators SHOULD use secret keys of minimum 16
characters length.
---
> TACACS+ clients MUST NOT set TAC_PLUS_UNENCRYPTED_FLAG when a secret is
> defined. Clients MUST be implemented in a way that requires explicit
> configuration to enable the use of TAC_PLUS_UNENCRYPTED_FLAG.
29c35,38
< TACACS+ server deployment administrators SHOULD change secret keys at regular
intervals.
---
> In the following cases:
> - Packet received from the server configured with shared key, but with
> TAC_PLUS_UNENCRYPTED_FLAG set.
> - Packet received from the server configured not to use obfuscation but with
> TAC_PLUS_UNENCRYPTED_FLAG not set.
> TACACS+ clients MUST close TCP session, stop all further processing of the
> packet data and process the response in the same way that a
> TAC_PLUS_AUTHEN_STATUS_FAIL (authentication sessions) or
> TAC_PLUS_AUTHOR_STATUS_FAIL (authorization sessions) was received
31c40
< 9.5.3 Authentication
---
> 9.5.4 Authentication
33c42
< 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).
35c44
< 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 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.
37c46
< 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.
---
> TACACS+ server administrators MUST NOT allow the same credentials to be
> applied in challenge-based (TAC_PLUS_AUTHEN_TYPE_CHAP or
> TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2) and non
> challenge-based authen_type options as the insecurity of the latter will
> compromise the security of the former.
39c48
< 9.5.4 Authorization
---
> 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 NOT implement them. If they must be implemented, the
> servers MUST default to the options being disabled and MUST warn the
> administrator that these options are not secure.
41c50
< 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.
---
> 9.5.4 Authorizatio
43c52
< 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.
---
> 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.
45c54
< 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+ clients that receive an unrecognised mandatory attribute MUST
> evaluate server response as if they received TAC_PLUS_AUTHOR_STATUS_FAIL.
49c58
< 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.
51c60
< TACACS+ server implementations SHOULD deprecate the redirection mechanism.
---
> TACACS+ servers SHOULD deprecate the redirection mechanism.
53c62
< 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 TACACS+ server administrators that it must only
> be enabled within a secure deployment due to the risks of revealing shared
> secrets.
55c64
< 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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
