Dear OPSAWG,
Below is a revised version of the recommendations. I have understood the
consensus to be, that we should keep the strength of the recommendations, but
explain how these should be applies in the real world with many, potentially
very old implementations in place.
Consequently, pretty much the only changes are in the first section. Please let
us know if this matches the consensus intent.
Many thanks,
Regards,
Doug.
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 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.
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.
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.
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.
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 deployments SHOULD use secret keys of minimum 16 characters
length.
TACACS+ server deployments 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 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 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.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
