Re: [OPSAWG] Start of WGLC for TACACS+ document.

[Alan DeKok <[e-mail]>]

  My $0.02 on the contents of the Security Considerations section.   I'm sure I've missed things.

  Please also comment if the suggestions here are wrong or unworkable.

----
9. Security Considerations

The protocol described in this document has been in widespread use
since specified in "The Draft" (1998).  However it does not meet
modern security standards, and faces vulnerabilities with privacy and
authenticity.

This section describes issues with the TACACS+ specification, then the
protocol, deployments, followed by recommendations for implementations.

Because of the security issues with TACACS+, the authors intend to
follow up this document with an enhanced specification of the
protocol employing modern security mechanisms.


9.1 Security of The Draft Specification

TACACS+ was originally specified in "The Draft" (1998).  However, this
draft is incomplete, and leaves key points unspecified.  As a result,
software authors have had to make implementation choices about what
should, or should not, be done in certain situations.  These
implementation choices are somewhat constrained by ad hoc
interoperability tests.  That is, all TACACS+ clients and servers
interoperate, so there is a rough consensus on how the protocol works.

While the authors have made every effort to maintain compatibility,
there is no guarantee, however, that this specification matches the
behavior of current or historical implementations.  We believe that
any incompatibilites are due to modern security requirements.  We
therefore suggest that implementors should read this document, and
verify that their implementations follow the security practices
recommended here.


9.2 Security of The Protocol

The major security issue with the TACACS+ protocol is the ad hoc
"encryption" defined in Section 3.6.  This "encryption" is more
properly called "obfuscation", and has had no security analysis.  That
is, the security or insecurity of the protocol is entirely unknown.

Attacks on cryptographic hashes are well known and are getting better
with time, as discussed in [RFC4270].  The security of the TACACS+
protocol is dependent on MD5 [RFC1321], which has security issues as
discussed in [RFC6151].  It is not known if the issues described in
[RFC6151] apply to TACACS+.  <<AD: lifted from RFC 6929 Section 11 >>

The choice of encrypting the body but not the packet header is
unusual.  The lack of security on the packet header means that an
attacker can modify the header without detection.

For example, a "session_id" can be replaced by an alternate one, which
could allow an unprivileged administrator to "steal" the authorization
from a session for a privileged administrator.  An attacker could also
update the "flags" field to indicate that one or the other end of a
connection requires TAC_PLUS_UNENCRYPTED_FLAG, which could remove what
little security is available.

What little security that exists is dependent on implementations
limiting access to known clients, and on the strenght of the secret
key.  Attacks who can guess the key or break the obfuscastion method
can gain unrestricted and undetected access to all TACACS+ traffic.
This access permits the attacker to execute any command on any system,
leaving the attacker in complete control of the network.  The negative
side effects of such a successful attack cannot be overstated.

9.2.1 Security of Authentication Sessions

There are a number of security issues with authentication sessions.
As the sessions enable the exchange of clear-text passwords, an
attacker capable of observing the unencrypted traffic or breakign the
encrypted traffic, can gain complete network access.  Similarly,
MSCHAPv1 and MS-CHAPv2 offer little additional security, while ARAP is
insecure and MUST NOT be used.  As of the publication of this
document, there has been no similar attacks on the CHAP protocol.

Section 4.4.3 permits the redirection of a session to another server
via the TAC_PLUS_AUTHEN_STATUS_FOLLOW mechanism.  As part of this
process, the secret key for a new server can be sent to the client.
This public exchange of secret keys means that once one session is
broken, it may be possible to leverage that attack to attacking
connections to other servers.  Section 9.4, below, has recommendations
for securing this portion of the protocol.

9.2.2 Security of Authorization Sessions

The primary issue with authorization sessions is that unauthenticated
authorization is allowed.  Almost as bad, authorization is permitted
where authentication was done by a third party, such as with
TAC_PLUS_AUTHEN_METH_KRB5.  This third party authentication is based
entirely on the client claiming that the user has been authenticated,
and the server trusting that request.  This practice is entirely
insecure.

There is also no way to cryptographically tie an authorization session
to a particular authentication session.  That is, when the client
indicates "authen_method" in the packet header, the authentication and
authorization sessions are tied together implicitly by the contents of
the other fields, such as "use", "port", "rem_addr", etc.

<<AD: it would be good for Section 5.1 to contain recommendations on
how the server can use these fields to tie together authentication /
authorization sessions.  Perhaps recommend that all AAA include a
"task_id"? >>

The specification allows for the exchange of attribute-value pairs.
While a few such attributes are defined here, the protocol is
extensible, and vendors can define their own attributes.  There is no
registry for such attributes, and in the absence of a published
specification, no way for a client or server to know the meaning of a
new attribute.

As a result, vendors SHOULD NOT define new attribute-value pairs,
unless such pairs are used only to communicate between client and
server implementations both written by the same vendor.

The "cmd" and "cmd-arg" attributes define shell commands and
arguments, but does not specify what these are.  The specific
commands, therefore, are undefined.


9.2.3 Security of Accounting Sessions

The security considerations for accounting sessions are largely the
same as for authorization sessions.  This section describes additional
issues specific to accounting sessions.

There is no way in TACACS+ to signal that accounting is required.
There is no way for a server to signal a client how often accounting
is required.  The accounting packets are received solely at the
clients discretion.  Adding such functionality would assist with
auditing of user actions.

The "task_id" field is defined only for accounting packets, and not
for authentication or authorization packets.  As such, it is difficult
to correlate accounting data with a previous authentication or
authorization request.

<<AD: re-use the recommendations suggested for Section 5.1, above? >>


9.4 Security of Deployments

Due to the above concerns with the protocol, it is critical that it be
deployed in a secure manner.

Systems using TACACS+ MUST be configured so that TACACS+ traffic is
secured.  Any user or service who is not interacting with the TACACS+
protocol MUST NOT be able to observe TACACS+ traffic, even when
TACACS+ "encryption" is used.

When used inside of enterprises, TACACS+ traffic MUST be sent over
management networks.  When used on the wider internet, TACACS+ traffic
MUST be secured via a modern security protocol such as TLS or IPSec.
As this specification describes the historic protocol, recommendations
on TLS and IPSec parameters are outside of the scope of this document.


9.4 Recommendations for Implementations

The following recommendations are for clients and servers which
implement the TACACS+ protocol.  These recommendations describe end
user interaction or user interface design.  While not part of the
protocol itself, good designs can prevent insecure configurations.

Clients and servers MUST default to rejecting all connections which
have the TAC_PLUS_UNENCRYPTED_FLAG set.  Clients and servers MAY
permit such connections when a debugging or test flag is set.  Clients
and servers MUST NOT run with this flag set in normal environments.

Similarly, the default for both clients and servers MUST be to require
a secret key when configuring a new server or client.  The secret key
MUST NOT be empty, and SHOULD be at least eight (8) characters in
length.  Clients and servers SHOULD permit the user of keys unique to
each server or client which they are connecting to.  They SHOULD warn
the administrator if a secret key is re-used.  Documentation for
implementations SHOULD recommend the use of strong secret keys.

Servers should maintain list of known clients, and reject connections
which originate from other systems.  Servers SHOULD NOT permit the
configuration of wildcard clients.  e.g. clients which map to a
network range.

Where a client or server detects that the secret key is incorrect, it
SHOULD terminate the underlying TCP connection, and log a message to
the system administrator.  There is no good reason to keep a
connection open when the systems are unable to communicate in a
meaningful fashion.

Implementions MUST default to using TAC_PLUS_AUTHEN_TYPE_CHAP for
authentication.  We recognize, however, that this authentication
method is incompatible with many password storage systems.  As a
result, other authentication methods are still in the protocol, and
can be used so long as administrators recognize the security issues
with their use.

Clients MUST default to treating TAC_PLUS_AUTHEN_STATUS_FOLLOW as if
TAC_PLUS_AUTHEN_STATUS_FAIL had been received instead.  Clients
SHOULD allow administrators to explicitly enable the
TAC_PLUS_AUTHEN_STATUS_FOLLOW functionality.  When the functionality
is enabled, clients SHOULD permit administrators to specify ranges of
addresses, and/or sets of hosts, along with corresponding secret keys,
for which redirection will be permitted.  Clients SHOULD ignore
redirects to hosts which are outside of the pre-configured range or
list.  Clients SHOULD ignore any key provided via
TAC_PLUS_AUTHEN_STATUS_FOLLOW, and SHOULD instead use a preconfigured
key for that host.

For authorization, servers SHOULD default to requiring
TAC_PLUS_AUTHEN_METH_TACACSPLUS.  Servers SHOULD track authentication
sessions via methods "to be described" in Section 5.1.

Where a server receives an unknown attribute-value pair, it SHOULD
reply with TAC_PLUS_AUTHOR_STATUS_FAIL.  Where a server receives an
unrecognized values in authorization attributes such as "cmd",
"cmd-arg", "acl", etc., the server SHOULD reply with
TAC_PLUS_AUTHOR_STATUS_FAIL.  When a client receives an unknown
authorization attribute, it SHOULD behave as if it had received
TAC_PLUS_AUTHOR_STATUS_FAIL.