Hello Opsawg,
We have uploaded a new version of the TACACS+ informational draft which
includes corrections for typos over the document as a whole, but also revised
the security section. We anticipate this security section will get most
comments, so it is reproduced below.
We will endeavor to be much more reactive to comments, whether on section
below, or any other in rest of uploaded document.
Many thanks,
The authors.
9. TACACS+ Security Considerations
The original TACACS+ Draft[1] from 1998 did not address all of the
key security concerns which are considered when designing modern
standards. This section addresses known limitations and concerns
which will impact overall security of the protocol and systems where
this protocol is deployed to manage central authentication,
authorization or accounting for network device administration.
Multiple implementations of the protocol described in the draft[1]
have been deployed. As the protocol was never standardized, current
implementations may be incompatible in non-obvious ways, giving rise
to additional security risks. This section does not claim to
enumerate all possible security vulnerabilities.
9.1. General Security of The Protocol
TACACS+ protocol does not include a security mechanism that would
meet modern-day requirements. Support for MD5-based crypto pad
encryption fails to provide any kind of transport integrity, which
presents at least the following risks:
Accounting information may be modified by the man-in-the-middle
attacker, making such logs unsuitable and untrustable for auditing
purposes.
Only the body of the request is encrypted which leaves all header
fields open to trivial modification by the man-in-the-middle
attacker. For this reason, connections with
TAC_PLUS_UNENCRYPTED_FLAG are disallowed, as mentioned in the
recommendations section.
Invalid or misleading values may be inserted by the man-in-the-
middle attacker in various fields at known offsets to try and
circumvent the authentication or authorization checks even inside
the encrypted body.
While the protocol provides some measure of transport privacy, it is
vulnerable to at least the following attacks:
Brute force attacks exploiting increased efficiency of MD5 digest
computation.
Known plaintext attacks which may decrease the cost of brute force
attack.
Chosen plaintext attacks which may decrease the cost of a brute
force attack.
No forward secrecy.
Even though, to the best knowledge of authors, this method of
encryption wasn't rigorously tested, enough information is available
that it is best referred to as "obfuscation" and not "encryption".
For these reasons, users deploying TACACS+ protocol in their
environments MUST limit access to known clients and MUST control the
security of the entire transmission path. Attacks who can guess the
key or otherwise break the obfuscation will gain unrestricted and
undetected access to all TACACS+ traffic. Ensuring that a
centralized AAA system like TACACS+ is deployed on a secured
transport is essential to managing security risk of such an attack.
The following parts of this section enumerate only the session-
specific risks which are in addition to general risk associated with
bare obfuscation and lack of integrity checking.
9.2. Security of Authentication Sessions
Authentication sessions SHOULD NOT be used via insecure transport as
the man-in-the-middle attack may completely subvert them. Even CHAP,
which may be considered resistant to password interception, is unsafe
as it does not protect the username from a trivial man-in-the-middle
attack.
This document deprecates the redirection mechanism using the
TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the
original draft. As part of this process, the secret key for a new
server was sent to the client. This public exchange of secret keys
means that once one session is broken, it may be possible to leverage
that key to attacking connections to other servers. This mechanism
SHOULD NOT be used in modern deployments. It MUST NOT be used
outside a secured deployment.
9.3. Security of Authorization Sessions
Authorization sessions MUST be used via secure transport only as it's
trivial to execute a successful man-in-the-middle attacks that
changes well-known plaintext in either requests or responses.
As an example, take the field "authen_method". It's not unusual in
actual deployments to authorize all commands received via the device
local serial port (a console port) as that one is usually considered
secure by virtue of the device located in a physically secure
location. If an administrator would configure the authorization
system to allow all commands entered by the user on a local console
to aid in troubleshooting, that would give all access to all commands
to any attacker that would be able to change the "authen_method" from
TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE. In
this regard, the obfuscation provided by the protocol itself wouldn't
help much, because:
Lack of integrity means that any byte in the payload may be
changed without either side detecting the change.
Known plaintext means that an attacker would know with certainty
which octet is the target of the attack (in this case, 1st octet
after the header).
In combination with known plaintext, the attacker can determine
with certainty the value of the crypto-pad octet used to obfuscate
the original octet.
9.4. Security of Accounting Sessions
Accounting sessions are not directly involved in authentication or
authorizing operations on the device. However, man-in-the-middle
attacker may do any of the following:
Replace accounting data with new valid or garbage which prevents
to provide distraction or hide information related to their
authentication and/or authorization attack attempts.
Try and poison accounting log with entries designed to make
systems behave in unintended ways (which includes TACACS+ server
and any other systems that would manage accounting entries).
In addition to these direct manipulations, different client
implementations pass different fidelity of accounting data. Some
vendors have been observed in the wild that pass sensitive data like
passwords, encryption keys and similar as part of the accounting log.
Due to lack of strong encryption with perfect forward secrecy, this
data may be revealed in future, leading to a security incident.
9.5. TACACS+ Client Implementation Recommendations
The following recommendations are made when implementing a TACACS+
client:
Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks
that are considered secure.
Treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as
TAC_PLUS_AUTHEN_STATUS_FAIL.
If receiving an unknown mandatory authorization attribute, behave
as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL.
9.6. TACACS+ Server Implementation Recommendations
The following recommendations are made when implementing a TACACS+
server:
The Server SHOULD NOT accept any connections which have the
TAC_PLUS_UNENCRYPTED_FLAG set and SHOULD reject those packets with
applicable ERROR response for type of packet.
The configuration of dedicated secret keys per individual client MUST
be supported by the Server implementation. It is also recommended
that Servers SHOULD warn administrators if secret keys are not unique
per client.
If an invalid shared secret is detected, Servers MUST NOT accept any
new sessions on a connection, and terminate the connection on
completion of any sessions previously established with a valid shared
secret.
The Server implementation must allow the administrator to mandate:
TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type
TAC_PLUS_AUTHEN_METH_TACACSPLUS for authen_method in authorization
Minimum length for shared secrets.
9.7. TACACS+ Deployment Best Practices
Due to above observations about the TACACS+ protocol, it is critical
to only deploy it using secure transport. A secure transport for
TACACS+ is defined as any means that ensure privacy and integrity of
all data passed between clients and servers. There are multiple
means of achieving this, all of them beyond the scope of this
document.
Symmetric encryption key represents a possible attack vector at the
protocol itself. For this reason, servers SHOULD accept only those
network connection attempts that arrive from known clients. This
limits the exposure and prevents remote brute force attacks from
unknown clients.
Due to the security deficiencies of the protocol, it is critical that
it be deployed in a secure manner. The following recommendations are
made for those deploying and configuring TACACS+ as a solution for
device administration:
Secure the Deployment: TACACS+ MUST BE deployed over networks
which ensure an appropriate privacy and integrity of the
communication. The way this is ensured will depend upon the
organizational means: a dedicated and secure management network
where available in enterprise deployments, or IPsec where
dedicated networks are not available.
Do not use the TAC_PLUS_UNENCRYPTED_FLAG option.
Always configure a secret key (recommended minimum 16 characters)
on the server for each client.
Consider shared secrets to be sensitive data, and manage securely
on server and client.
Change secret keys at regular intervals.
Do not use TAC_PLUS_AUTHEN_SENDAUTH or TAC_PLUS_AUTHEN_SENDPASS
options.
Use TAC_PLUS_AUTHEN_TYPE_CHAP or MS_CHAP options for authen_type
where possible. Use other options only when unavoidable due to
requirements of identity/password systems.
Require TACACS+ authentication for authorization requests (i.e.
TAC_PLUS_AUTHEN_METH_TACACSPLUS is used).
Do not use the redirection mechanism
(TAC_PLUS_AUTHEN_STATUS_FOLLOW). Specifically avoid the option to
send secret keys in the server list.
Take case when applying extensions to the dictionary of
authorization/accounting arguments. Ensure that the client and
server use of new argument names are consistent.
In summary: It is strongly advised that TACACS+ MUST be used within a
secure deployment. Failure to do so may impact overall network
security.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
