draft-ietf-opsawg-tacacs-06.txt   draft-ietf-opsawg-tacacs-07.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: August 22, 2017 D. Medway Gash Expires: February 22, 2018 D. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
D. Carrel D. Carrel
vIPtela, Inc. vIPtela, Inc.
L. Grant L. Grant
February 18, 2017 August 21, 2017
The TACACS+ Protocol The TACACS+ Protocol
draft-ietf-opsawg-tacacs-06 draft-ietf-opsawg-tacacs-07
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 August 22, 2017. This Internet-Draft will expire on February 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 7 skipping to change at page 3, line 7
5.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26 5.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26
6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 6.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28
6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 6.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29
7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30 7. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30
7.1. Authorization Attributes . . . . . . . . . . . . . . . . 31 7.1. Authorization Attributes . . . . . . . . . . . . . . . . 31
7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 7.2. Accounting Attributes . . . . . . . . . . . . . . . . . . 34
8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 8. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35
9. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36 9. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36
9.1. Security of The Protocol . . . . . . . . . . . . . . . . 36 9.1. Overall Security of The Protocol . . . . . . . . . . . . 36
9.2. Security of Authentication Sessions . . . . . . . . . . . 37 9.2. Security of Authentication Sessions . . . . . . . . . . . 38
9.3. Security of Authorization Sessions . . . . . . . . . . . 37 9.3. Security of Authorization Sessions . . . . . . . . . . . 38
9.4. Security of Accounting Sessions . . . . . . . . . . . . . 38 9.4. Security of Accounting Sessions . . . . . . . . . . . . . 38
9.5. TACACS+ Deployment Recommendations . . . . . . . . . . . 38 9.5. TACACS+ Deployment Recommendations . . . . . . . . . . . 39
9.6. TACACS+ Client Implementation Recommendations . . . . . . 39 9.6. TACACS+ Client Implementation Recommendations . . . . . . 39
9.7. TACACS+ Server Implementation Recommendations . . . . . . 39 9.7. TACACS+ Server Implementation Recommendations . . . . . . 40
9.8. TACACS+ Security and Operational Concerns . . . . . . . . 40 9.8. TACACS+ Security and Operational Concerns . . . . . . . . 40
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
Terminal Access Controller Access-Control System Plus (TACACS+) was Terminal Access Controller Access-Control System Plus (TACACS+) was
originally conceived as a general Authentication, Authorization and originally conceived 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 47 skipping to change at page 36, line 47
secure version of the protocol. secure version of the protocol.
TACACS+ was originally specified in "The Draft" (1998) is incomplete, TACACS+ was originally specified in "The Draft" (1998) is incomplete,
and leaves key points unspecified. As a result, software authors and leaves key points unspecified. As a result, software authors
have had to make implementation choices about what should, or should have had to make implementation choices about what should, or should
not, be done in certain situations. These implementation choices are not, be done in certain situations. These implementation choices are
somewhat constrained by ad hoc interoperability tests. That is, all somewhat constrained by ad hoc interoperability tests. That is, all
TACACS+ clients and servers interoperate, so there is a rough TACACS+ clients and servers interoperate, so there is a rough
consensus on how the protocol works. consensus on how the protocol works.
9.1. Security of The Protocol 9.1. Overall Security of The Protocol
The major security issue with the TACACS+ protocol is the absence of TACACS+ protocol does not include a security mechanism that would
a security mechanism that would meet modern day requirements. The meet modern day requirements. Support for MD5-based crypto pad
draft included an "encryption" mechanism, however this has been more encryption fails to provide any kind of transport integrity, which
correctly referred to as "obfuscation" in this document. presents at least the following risks:
The choice of obfuscating the body but not the packet header means Accounting information may be modified by the man-in-the-middle
that an attacker can modify the header without detection. 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.
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 means that original data may be revealed at the
later time and still provide valuable information to the attacker.
Even though, to the best knowledge of authors, this method of
encryption wasn't rigorously tested, authors feel that enough
information is available that it is best referred to as "obfuscation"
and not "encryption" and as such it MUST NOT BE relied upon to
provide privacy.
For example, a "session_id" can be replaced by an alternate one, For example, a "session_id" can be replaced by an alternate one,
which could allow an unprivileged administrator to "steal" the which could allow an unprivileged administrator to "steal" the
authorization from a session for a privileged administrator. An authorization from a session for a privileged administrator. An
attacker could also update the "flags" field to indicate that one or attacker could also update the "flags" field to indicate that one or
the other end of a connection requires TAC_PLUS_UNENCRYPTED_FLAG, the other end of a connection requires TAC_PLUS_UNENCRYPTED_FLAG,
which would subvert the obfuscation mechanism. which would subvert the obfuscation mechanism.
Without application of alternative secure transport, implementations For this reasons, users deploying TACACS+ protocol in their
rely on limiting access to known clients. Attacks who can guess the environments MUST limit access to known clients and MUST control the
key or break the obfuscastion method can gain unrestricted and security of the entire transmission path. Attacks who can guess the
undetected access to all TACACS+ traffic. The negative side effects key or otherwise break the obfuscation WILL gain unrestricted and
of such a successful attack cannot be overstated. undetected access to all TACACS+ traffic. The security risk of such
attack succeeding against a centralised AAA system like TACACS+
cannot be overstated.
9.2. Security of Authentication Sessions 9.2. Security of Authentication Sessions
The authentication options include options which MUST NOT be used The authentication options include options which MUST NOT be used
outside a secured deployment. Specifically, options which permit the outside a secured deployment. Specifically, options which permit the
exchange of clear-text passwords or MSCHAPv1 and MS-CHAPv2. As of exchange of clear-text passwords or MSCHAPv1 and MS-CHAPv2. As of
the publication of this document, there has been no similar attacks the publication of this document, there has been no similar attacks
on the CHAP protocol. on the CHAP protocol.
Section 4.4.3 permits the redirection of a session to another server Section 4.4.3 permits the redirection of a session to another server
skipping to change at page 40, line 37 skipping to change at page 41, line 23
Potential confusion between clients and servers from different Potential confusion between clients and servers from different
vendors of the meaning of specific commands. 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. References 10. References
[TheDraft]
Carrel, D. and L. Grant, "The TACACS+ Protocol Version
1.78", June 1997, <https://tools.ietf.org/html/draft-
grant-tacacs-02>.
[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>.
[RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC 1750, "Randomness Recommendations for Security", RFC 1750,
DOI 10.17487/RFC1750, December 1994, DOI 10.17487/RFC1750, December 1994,
<http://www.rfc-editor.org/info/rfc1750>. <http://www.rfc-editor.org/info/rfc1750>.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, DOI 10.17487/RFC2433, October 1998, RFC 2433, DOI 10.17487/RFC2433, October 1998,
<http://www.rfc-editor.org/info/rfc2433>. <http://www.rfc-editor.org/info/rfc2433>.
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
RFC 2759, DOI 10.17487/RFC2759, January 2000, RFC 2759, DOI 10.17487/RFC2759, January 2000,
<http://www.rfc-editor.org/info/rfc2759>. <http://www.rfc-editor.org/info/rfc2759>.
Authors' Addresses [TheDraft]
Carrel, D. and L. Grant, "The TACACS+ Protocol Version
1.78", June 1997, <https://tools.ietf.org/html/draft-
grant-tacacs-02>.
Authors' Addresses
Thorsten Dahm Thorsten Dahm
Google Inc Google Inc
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
EMail: thorstendlux@google.com EMail: thorstendlux@google.com
Andrej Ota Andrej Ota
Google Inc Google Inc
 End of changes. 15 change blocks. 
28 lines changed or deleted 60 lines changed or added

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