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.
Many thanks.
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.
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.
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.
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.
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.
TACACS+ server implementations SHOULD deprecate the redirection mechanism.
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.
TACACS+ client implementations SHOULD deprecate this feature by treating
TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
Diff from previous version:
5c5
< The following recommendations are not part of the definition of the protocol.
Rather, they impose restrictions on how the protocol is applied. Specific
requirements of the TACACS+ server and TACACS+ client implementations are
mandated to make it easier for the administrators who deploy TACACS+ to adopt
the restrictions.
---
> The following recommendations impose restrictions on how the protocol is
> applied.
7c7,9
< Some of the specific requirements mandated for TACACS+ servers and TACACS+
clients may not be present in currently deployed implementations. This is
accepted as situational fact, and these implementations may still be regarded
as correctly implementing the TACACS+ protocol as long as they conform to the
details in other sections of this document. New implementations, and upgrades
of current implementations, SHOULD implement the recommendations.
---
> 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.
14a17,18
> When a client secret is defined, TACACS+ Server implementations MUST not use
> the TAC_PLUS_UNENCRYPTED_FLAG option when processing connections from that
> client.
>
21,23c25
< 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+ server deployments SHOULD always define a secret for each client.
---
> TACACS+ server deployment administrators SHOULD always define a secret for
> each client.
25c27
< TACACS+ server deployments SHOULD use secret keys of minimum 16 characters
length.
---
> TACACS+ server deployment administrators SHOULD use secret keys of minimum 16
> characters length.
27c29
< TACACS+ server deployments SHOULD change secret keys at regular intervals.
---
> TACACS+ server deployment administrators SHOULD change secret keys at regular
> intervals.
33c35
< 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.
---
> 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.
35c37
< TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in
the original draft SHOULD not be used, due to their security implications.
---
> 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.
39c41
< 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.
---
> 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.
43c45
< 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).
---
> 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).
49c51,58
< TACACS+ Server implementations SHOULD deprecate the redirection mechanism.
---
> TACACS+ server implementations SHOULD deprecate the redirection mechanism.
>
> 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.
>
> TACACS+ client implementations SHOULD deprecate this feature by treating
> TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
>
>
>
51c60
< TACACS+ Server implementations MUST warn users of the security implications
if the option to send the secret keys in the server list is configured.
---
>
53d61
< TACACS+ client implementations 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
