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 loca
