draft-ietf-opsawg-tacacs-09.txt   draft-ietf-opsawg-tacacs-10.txt 
Operations T. Dahm Operations T. Dahm
Internet-Draft A. Ota Internet-Draft A. Ota
Intended status: Informational Google Inc Intended status: Informational Google Inc
Expires: September 22, 2018 D. Medway Gash Expires: October 17, 2018 D. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
D. Carrel D. Carrel
vIPtela, Inc. vIPtela, Inc.
L. Grant L. Grant
March 21, 2018 April 15, 2018
The TACACS+ Protocol The TACACS+ Protocol
draft-ietf-opsawg-tacacs-09 draft-ietf-opsawg-tacacs-10
Abstract Abstract
TACACS+ provides Device Administration for routers, network access TACACS+ provides Device Administration for routers, network access
servers and other networked computing devices via one or more servers and other networked computing devices via one or more
centralized servers. This document describes the protocol that is centralized servers. This document describes the protocol that is
used by TACACS+. used by TACACS+.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2018. This Internet-Draft will expire on October 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30
7.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31 7.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31
7.2. Authorization Attributes . . . . . . . . . . . . . . . . 31 7.2. Authorization Attributes . . . . . . . . . . . . . . . . 31
7.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 7.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34
8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35
9. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36 9. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36
9.1. General Security of The Protocol . . . . . . . . . . . . 36 9.1. General Security of The Protocol . . . . . . . . . . . . 36
9.2. Security of Authentication Sessions . . . . . . . . . . . 38 9.2. Security of Authentication Sessions . . . . . . . . . . . 38
9.3. Security of Authorization Sessions . . . . . . . . . . . 38 9.3. Security of Authorization Sessions . . . . . . . . . . . 38
9.4. Security of Accounting Sessions . . . . . . . . . . . . . 39 9.4. Security of Accounting Sessions . . . . . . . . . . . . . 39
9.5. TACACS+ Deployment Recommendations . . . . . . . . . . . 39 9.5. TACACS+ Client Implementation Recommendations . . . . . . 39
9.6. TACACS+ Client Implementation Recommendations . . . . . . 40 9.6. TACACS+ Server Implementation Recommendations . . . . . . 39
9.7. TACACS+ Server Implementation Recommendations . . . . . . 41 9.7. TACACS+ Deployment Best Practices . . . . . . . . . . . . 40
9.8. TACACS+ Security and Operational Concerns . . . . . . . . 41 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
Terminal Access Controller Access-Control System Plus (TACACS+) was Terminal Access Controller Access-Control System Plus (TACACS+) was
conceived initially as a general Authentication, Authorization and conceived initially as a general Authentication, Authorization and
Accounting protocol. It is primarily used today for Device Accounting protocol. It is primarily used today for Device
Administration: authenticating access to network devices, providing Administration: authenticating access to network devices, providing
central authorization of operations, and audit of those operations. central authorization of operations, and audit of those operations.
skipping to change at page 36, line 42 skipping to change at page 36, line 42
9. TACACS+ Security Considerations 9. TACACS+ Security Considerations
The original TACACS+ Draft[1] from 1998 did not address all of the The original TACACS+ Draft[1] from 1998 did not address all of the
key security concerns which are considered when designing modern key security concerns which are considered when designing modern
standards. This section addresses known limitations and concerns standards. This section addresses known limitations and concerns
which will impact overall security of the protocol and systems where which will impact overall security of the protocol and systems where
this protocol is deployed to manage central authentication, this protocol is deployed to manage central authentication,
authorization or accounting for network device administration. authorization or accounting for network device administration.
Multiple implementations of the protocol described in the draft[1] Multiple implementations of the protocol described in the draft[1]
have been deployed. As the protocol was never standardised, current have been deployed. As the protocol was never standardized, current
implementations may be incompatible in non-obvious ways, giving rise implementations may be incompatible in non-obvious ways, giving rise
to additional security risks about which authors might not be aware to additional security risks. This section does not claim to
of. This section does not claim to enumerate all possible security enumerate all possible security vulnerabilities.
vulnerabilities.
9.1. General Security of The Protocol 9.1. General Security of The Protocol
TACACS+ protocol does not include a security mechanism that would TACACS+ protocol does not include a security mechanism that would
meet modern-day requirements. Support for MD5-based crypto pad meet modern-day requirements. Support for MD5-based crypto pad
encryption fails to provide any kind of transport integrity, which encryption fails to provide any kind of transport integrity, which
presents at least the following risks: presents at least the following risks:
Accounting information may be modified by the man-in-the-middle Accounting information may be modified by the man-in-the-middle
attacker, making such logs unsuitable and untrustable for auditing attacker, making such logs unsuitable and untrustable for auditing
purposes. purposes.
Only the body of the request is encrypted which leaves all header Only the body of the request is encrypted which leaves all header
fields open to trivial modification by the man-in-the-middle fields open to trivial modification by the man-in-the-middle
attacker. 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- Invalid or misleading values may be inserted by the man-in-the-
middle attacker in various fields at known offsets to try and middle attacker in various fields at known offsets to try and
circumvent the authentication or authorization checks even inside circumvent the authentication or authorization checks even inside
the encrypted body. the encrypted body.
While the protocol provides some measure of transport privacy, it is While the protocol provides some measure of transport privacy, it is
vulnerable to at least the following attacks: vulnerable to at least the following attacks:
Brute force attacks exploiting increased efficiency of MD5 digest Brute force attacks exploiting increased efficiency of MD5 digest
skipping to change at page 37, line 35 skipping to change at page 37, line 35
Known plaintext attacks which may decrease the cost of brute force Known plaintext attacks which may decrease the cost of brute force
attack. attack.
Chosen plaintext attacks which may decrease the cost of a brute Chosen plaintext attacks which may decrease the cost of a brute
force attack. force attack.
No forward secrecy. No forward secrecy.
Even though, to the best knowledge of authors, this method of Even though, to the best knowledge of authors, this method of
encryption wasn't rigorously tested, authors feel that enough encryption wasn't rigorously tested, enough information is available
information is available that it is best referred to as "obfuscation" that it is best referred to as "obfuscation" and not "encryption".
and not "encryption".
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 would subvert the obfuscation mechanism.
For these reasons, users deploying TACACS+ protocol in their For these reasons, users deploying TACACS+ protocol in their
environments MUST limit access to known clients and MUST control the environments MUST limit access to known clients and MUST control the
security of the entire transmission path. Attacks who can guess the security of the entire transmission path. Attacks who can guess the
key or otherwise break the obfuscation will gain unrestricted and key or otherwise break the obfuscation will gain unrestricted and
undetected access to all TACACS+ traffic. The security risk of such undetected access to all TACACS+ traffic. Ensuring that a
attack succeeding against a centralised AAA system like TACACS+ centralized AAA system like TACACS+ is deployed on a secured
cannot be overstated. transport is essential to managing security risk of such an attack.
The following parts of this section enumerate only the session- The following parts of this section enumerate only the session-
specific risks which are in addition to general risk associated with specific risks which are in addition to general risk associated with
bare obfuscation and lack of integrity checking. bare obfuscation and lack of integrity checking.
9.2. Security of Authentication Sessions 9.2. Security of Authentication Sessions
Authentication sessions SHOULD NOT be used via insecure transport as Authentication sessions SHOULD NOT be used via insecure transport as
the man-in-the-middle attack may completely subvert them. Even CHAP, the man-in-the-middle attack may completely subvert them. Even CHAP,
which may be considered resistant to password interception, is unsafe which may be considered resistant to password interception, is unsafe
as it does not protect the username from a trivial man-in-the-middle as it does not protect the username from a trivial man-in-the-middle
attack. attack.
Section 4.4.3 permits the redirection of a session to another server This document deprecates the redirection mechanism using the
via the TAC_PLUS_AUTHEN_STATUS_FOLLOW mechanism. As part of this TAC_PLUS_AUTHEN_STATUS_FOLLOW option which was included in the
process, the secret key for a new server can be sent to the client. original draft. As part of this process, the secret key for a new
This public exchange of secret keys means that once one session is server was sent to the client. This public exchange of secret keys
broken, it may be possible to leverage that key to attacking means that once one session is broken, it may be possible to leverage
connections to other servers. This option MUST NOT be used outside a that key to attacking connections to other servers. This mechanism
secured deployment of protocol clients or outside of secure SHOULD NOT be used in modern deployments. It MUST NOT be used
transport. outside a secured deployment.
9.3. Security of Authorization Sessions 9.3. Security of Authorization Sessions
Authorization sessions MUST be used via secure transport only as it's Authorization sessions MUST be used via secure transport only as it's
trivial to execute a successful man-in-the-middle attacks that trivial to execute a successful man-in-the-middle attacks that
changes well-known plaintext in either requests or responses. changes well-known plaintext in either requests or responses.
As an example, take the field "authen_method". It's not unusual in As an example, take the field "authen_method". It's not unusual in
actual deployments to authorize all commands received via the device actual deployments to authorize all commands received via the device
local serial port (a console port) as that one is usually considered local serial port (a console port) as that one is usually considered
secure by virtue of the device located in a physically secure secure by virtue of the device located in a physically secure
location. If an administrator would configure the authorization location. If an administrator would configure the authorization
system to allow all commands entered by the user on a local console 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 aid in troubleshooting, that would give all access to all commands
to any attacker that would be able to change the "authen_method" from 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 TAC_PLUS_AUTHEN_METH_TACACSPLUS to TAC_PLUS_AUTHEN_METH_LINE. In
this regard, the obfuscation provided by the protocol itself wouldn't this regard, the obfuscation provided by the protocol itself wouldn't
help much, because: help much, because:
Lack of integrity means that any byte in the payload may be Lack of integrity means that any byte in the payload may be
changed w/o either side detecting the change. changed without either side detecting the change.
Known plaintext means that an attacker would know with certainty Known plaintext means that an attacker would know with certainty
which octet is the target of the attack (in this case, 1st octet which octet is the target of the attack (in this case, 1st octet
after the header). after the header).
In combination with known plaintext, the attacker can determine In combination with known plaintext, the attacker can determine
with certainty the value of the crypto-pad octet used to obfuscate with certainty the value of the crypto-pad octet used to obfuscate
the original octet. the original octet.
9.4. Security of Accounting Sessions 9.4. Security of Accounting Sessions
skipping to change at page 39, line 30 skipping to change at page 39, line 26
systems behave in unintended ways (which includes TACACS+ server systems behave in unintended ways (which includes TACACS+ server
and any other systems that would manage accounting entries). and any other systems that would manage accounting entries).
In addition to these direct manipulations, different client In addition to these direct manipulations, different client
implementations pass different fidelity of accounting data. Some implementations pass different fidelity of accounting data. Some
vendors have been observed in the wild that pass sensitive data like vendors have been observed in the wild that pass sensitive data like
passwords, encryption keys and similar as part of the accounting log. passwords, encryption keys and similar as part of the accounting log.
Due to lack of strong encryption with perfect forward secrecy, this Due to lack of strong encryption with perfect forward secrecy, this
data may be revealed in future, leading to a security incident. data may be revealed in future, leading to a security incident.
9.5. TACACS+ Deployment Recommendations 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 Due to above observations about the TACACS+ protocol, it is critical
to only deploy it using secure transport. A secure transport for to only deploy it using secure transport. A secure transport for
TACACS+ is defined as any means that ensure privacy and integrity of TACACS+ is defined as any means that ensure privacy and integrity of
all data passed between clients and servers. There are multiple all data passed between clients and servers. There are multiple
means of achieving this, all of them beyond the scope of this means of achieving this, all of them beyond the scope of this
document. document.
Symmetric encryption key represents a possible attack vector at the Symmetric encryption key represents a possible attack vector at the
protocol itself. For this reason, servers SHOULD accept only those protocol itself. For this reason, servers SHOULD accept only those
skipping to change at page 39, line 52 skipping to change at page 40, line 40
limits the exposure and prevents remote brute force attacks from limits the exposure and prevents remote brute force attacks from
unknown clients. unknown clients.
Due to the security deficiencies of the protocol, it is critical that Due to the security deficiencies of the protocol, it is critical that
it be deployed in a secure manner. The following recommendations are it be deployed in a secure manner. The following recommendations are
made for those deploying and configuring TACACS+ as a solution for made for those deploying and configuring TACACS+ as a solution for
device administration: device administration:
Secure the Deployment: TACACS+ MUST BE deployed over networks Secure the Deployment: TACACS+ MUST BE deployed over networks
which ensure an appropriate privacy and integrity of the which ensure an appropriate privacy and integrity of the
communication. Definition of an appropriate level of privacy and communication. The way this is ensured will depend upon the
integrity is organisation-dependent What is appropriate level of organizational means: a dedicated and secure management network
The way this is ensured will depend upon the organisational means: where available in enterprise deployments, or IPsec where
a dedicated and secure management network where available in dedicated networks are not available.
enterprise deployments, or IPsec where dedicated networks are not
available.
Always set a secret key (recommended minimum 14 characters) on the Do not use the TAC_PLUS_UNENCRYPTED_FLAG option.
client and server when configuring the connection between them.
Servers MUST be configured with a list of known clients. Servers Always configure a secret key (recommended minimum 16 characters)
MUST be configured to reject requests from clients not on the on the server for each client.
list. A unique secret key SHOULD be configured for every
individual client.
Implementors should consider shared secrets to be sensitive data, Consider shared secrets to be sensitive data, and manage securely
and managed securely. on server and client.
Restrict to TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type where Change secret keys at regular intervals.
possible. Use other options only when unavoidable due to
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. requirements of identity/password systems.
Servers SHOULD be restricted to requiring TACACS+ authentication Require TACACS+ authentication for authorization requests (i.e.
for authorization requests (i.e. TAC_PLUS_AUTHEN_METH_TACACSPLUS TAC_PLUS_AUTHEN_METH_TACACSPLUS is used).
is used).
Avoid the use of the redirection mechanism. Do not use the redirection mechanism
TAC_PLUS_AUTHEN_STATUS_FOLLOW, specifically avoid the option to (TAC_PLUS_AUTHEN_STATUS_FOLLOW). Specifically avoid the option to
send secret keys in the server list. send secret keys in the server list.
Take case when applying extensions to the dictionary of Take case when applying extensions to the dictionary of
authorization/accounting arguments. Ensure that the client and authorization/accounting arguments. Ensure that the client and
server use of new argument names are consistent. server use of new argument names are consistent.
9.6. TACACS+ Client Implementation Recommendations
When implementing TACACS+ Clients it is recommended:
Clients SHOULD not use TAC_PLUS_UNENCRYPTED_FLAG, even on networks
that are considered secure.
Ignore redirects to hosts which are outside of the pre-configured
range or list. A client SHOULD ignore any key provided via
TAC_PLUS_AUTHEN_STATUS_FOLLOW, and SHOULD instead use a
preconfigured key for that host.
If receiving an unknown mandatory authorization attribute, behave
as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL. For full
details, refer to (Authorization attributes section).
9.7. TACACS+ Server Implementation Recommendations
When implementing TACACS+ Servers, it is recommended:
Server SHOULD reject all connections which have the
TAC_PLUS_UNENCRYPTED_FLAG with applicable ERROR response for type
of packet.
Servers MUST permit configuration of secret keys per individual
client. Servers SHOULD warn administrators if secret keys are not
unique per client.
On detection of an invalid shared secret: Servers SHOULD NOT
accept any new sessions on a connection, and terminate the
connection on completion of any sessions previously established
with a valid shared secret.
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.8. TACACS+ Security and Operational Concerns
This section identifies some of the known security and operational
concerns. It is important to acknowledge that TACACS+ on its own
does not provide modern levels of security, and that it MUST be used
within a secure deployment.
The "encryption" is based upon MD5. In modern terms this can be
regarded merely as "obfuscation".
Only the packet body (not header) is obfuscated. For example,
session_id, flags containing TAC_PLUS_UNENCRYPTED_FLAG is exposed
in cleartext.
Support of insecure authentication protocols such as plaintext,
MS-CHAP.
Difficulty to correlate authentication, authorization, and
accounting requests for a single unit of end client activity.
Potential confusion between clients and servers from different
vendors of the meaning of specific argument attributes.
Potential confusion between clients and servers from different
vendors of the meaning of specific commands.
In summary: It is strongly advised that TACACS+ MUST be used within a In summary: It is strongly advised that TACACS+ MUST be used within a
secure deployment. Failure to do so may impact overall network secure deployment. Failure to do so may impact overall network
security. security.
10. Acknowledgements 10. Acknowledgements
The Authors would like to thank the following reviewers whose The authors would like to thank the following reviewers whose
comments and contributions made considerable improvements to the comments and contributions made considerable improvements to the
document: Alan DeKok (who provided significant insights and document: Alan DeKok, Alexander Clouter, Chris Janicki, Tom Petch,
recommendations on all aspects of documenting the protocol), Robert Drake, among many others.
Alexander Clouter, Chris Janicki, Tom Petch, Robert Drake
The Authors would also like to thanks the support from the OPSAWG The authors would particularly like to thank Alan DeKok, who provided
significant insights and recommendations on all aspects of the
document and the protocol. Alan DeKok has dedicated considerable
effort to identify weaknesses and provide remedies to help improve
the document.
The authors would also like to thanks the support from the OPSAWG
Chairs and advisors. Chairs and advisors.
11. References 11. References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", [RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols",
RFC 1334, DOI 10.17487/RFC1334, October 1992, RFC 1334, DOI 10.17487/RFC1334, October 1992,
<http://www.rfc-editor.org/info/rfc1334>. <http://www.rfc-editor.org/info/rfc1334>.
 End of changes. 24 change blocks. 
127 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/