draft-ietf-opsawg-tacacs-12.txt   draft-ietf-opsawg-tacacs-13.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: June 5, 2019 D. Medway Gash Expires: September 28, 2019 D. Medway Gash
Cisco Systems, Inc. Cisco Systems, Inc.
D. Carrel D. Carrel
vIPtela, Inc. vIPtela, Inc.
L. Grant L. Grant
December 2, 2018 March 27, 2019
The TACACS+ Protocol The TACACS+ Protocol
draft-ietf-opsawg-tacacs-12 draft-ietf-opsawg-tacacs-13
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 June 5, 2019. This Internet-Draft will expire on September 28, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 3, line 7
6.1. The Authorization REQUEST Packet Body . . . . . . . . . . 23 6.1. The Authorization REQUEST Packet Body . . . . . . . . . . 23
6.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26 6.2. The Authorization REPLY Packet Body . . . . . . . . . . . 26
7. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28 7.1. The Account REQUEST Packet Body . . . . . . . . . . . . . 28
7.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29 7.2. The Accounting REPLY Packet Body . . . . . . . . . . . . 29
8. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30 8. Attribute-Value Pairs . . . . . . . . . . . . . . . . . . . . 30
8.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31 8.1. Value Encoding . . . . . . . . . . . . . . . . . . . . . 31
8.2. Authorization Attributes . . . . . . . . . . . . . . . . 31 8.2. Authorization Attributes . . . . . . . . . . . . . . . . 31
8.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34 8.3. Accounting Attributes . . . . . . . . . . . . . . . . . . 34
9. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35 9. Privilege Levels . . . . . . . . . . . . . . . . . . . . . . 35
10. TACACS+ Security Considerations . . . . . . . . . . . . . . . 36 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10.1. General Security of the Protocol . . . . . . . . . . . . 37 10.1. General Security of the Protocol . . . . . . . . . . . . 37
10.2. Security of Authentication Sessions . . . . . . . . . . 38 10.2. Security of Authentication Sessions . . . . . . . . . . 38
10.3. Security of Authorization Sessions . . . . . . . . . . . 38 10.3. Security of Authorization Sessions . . . . . . . . . . . 38
10.4. Security of Accounting Sessions . . . . . . . . . . . . 39 10.4. Security of Accounting Sessions . . . . . . . . . . . . 39
10.5. TACACS+ Best Practices . . . . . . . . . . . . . . . . . 39 10.5. TACACS+ Best Practices . . . . . . . . . . . . . . . . . 39
10.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 39 10.5.1. Shared Secrets . . . . . . . . . . . . . . . . . . . 39
10.5.2. Connections and Obfuscation . . . . . . . . . . . . 40 10.5.2. Connections and Obfuscation . . . . . . . . . . . . 40
10.5.3. Authentication . . . . . . . . . . . . . . . . . . . 41 10.5.3. Authentication . . . . . . . . . . . . . . . . . . . 41
10.5.4. Authorization . . . . . . . . . . . . . . . . . . . 41 10.5.4. Authorization . . . . . . . . . . . . . . . . . . . 41
10.5.5. Redirection Mechanism . . . . . . . . . . . . . . . 42 10.5.5. Redirection Mechanism . . . . . . . . . . . . . . . 42
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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.
A wide range of TACACS+ clients and servers are already deployed in A wide range of TACACS+ clients and servers are already deployed in
skipping to change at page 4, line 24 skipping to change at page 4, line 28
implementation or configuration is not required to employ all three. implementation or configuration is not required to employ all three.
Separating the elements is useful for Device Administration use case, Separating the elements is useful for Device Administration use case,
specifically, for authorization of individual commands in a session. specifically, for authorization of individual commands in a session.
Note that there is no provision made at the protocol level for Note that there is no provision made at the protocol level for
association of an authentication to each authorization request. association of an authentication to each authorization request.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119] document are to be interpreted as described in RFC 2119 RFC2119
[RFC2119].
3. Technical Definitions 3. Technical Definitions
This section provides a few basic definitions that are applicable to This section provides a few basic definitions that are applicable to
this document this document
Client Client
The client is any device, (often a Network Access Server) that The client is any device, (often a Network Access Server) that
provides access services. The clients usually provide a character provides access services. The clients usually provide a character
skipping to change at page 11, line 35 skipping to change at page 11, line 35
This flag is used to allow a client and server to negotiate Single This flag is used to allow a client and server to negotiate Single
Connection Mode. Connection Mode.
session_id session_id
The Id for this TACACS+ session. This field does not change for the The Id for this TACACS+ session. This field does not change for the
duration of the TACACS+ session. This number MUST be generated by a duration of the TACACS+ session. This number MUST be generated by a
cryptographically strong random number generation method. Failure to cryptographically strong random number generation method. Failure to
do so will compromise security of the session. For more details do so will compromise security of the session. For more details
refer to RFC 1750 [RFC1750] refer to RFC 4086 [RFC4086]
length length
The total length of the packet body (not including the header). The total length of the packet body (not including the header).
4.9. The TACACS+ Packet Body 4.9. The TACACS+ Packet Body
The TACACS+ body types are defined in the packet header. The next The TACACS+ body types are defined in the packet header. The next
sections of this document will address the contents of the different sections of this document will address the contents of the different
TACACS+ bodies. The following general rules apply to all TACACS+ TACACS+ bodies. The following general rules apply to all TACACS+
skipping to change at page 34, line 27 skipping to change at page 34, line 27
The following attributes are defined for TACACS+ accounting only. The following attributes are defined for TACACS+ accounting only.
They MUST precede any attribute-value pairs that are defined in the They MUST precede any attribute-value pairs that are defined in the
authorization section (Section 6) above. authorization section (Section 6) above.
task_id (String) task_id (String)
Start and stop records for the same event MUST have matching task_id Start and stop records for the same event MUST have matching task_id
attribute values. The client MUST ensure that active task_ids are attribute values. The client MUST ensure that active task_ids are
not duplicated: a client MUST NOT reuse a task_id a start record not duplicated: a client MUST NOT reuse a task_id a start record
until it has sent a stop record for that task_id. Servers MUST not until it has sent a stop record for that task_id. Servers MUST NOT
make assumptions about the format of a task_id. make assumptions about the format of a task_id.
start_time (Date Time) start_time (Date Time)
The time the action started (in seconds since the epoch.). The time the action started (in seconds since the epoch.).
stop_time (Date Time) stop_time (Date Time)
The time the action stopped (in seconds since the epoch.) The time the action stopped (in seconds since the epoch.)
skipping to change at page 36, line 35 skipping to change at page 36, line 35
authentication request. authentication request.
The use of Privilege levels to determine session-based access to The use of Privilege levels to determine session-based access to
commands and resources is not mandatory for clients. Although the commands and resources is not mandatory for clients. Although the
privilege level scheme is widely supported, its lack of flexibility privilege level scheme is widely supported, its lack of flexibility
in requiring a single monotonic hierarchy of permissions means that in requiring a single monotonic hierarchy of permissions means that
other session-based command authorization schemes have evolved, and other session-based command authorization schemes have evolved, and
so it is no longer mandatory for clients to use it. However, it is so it is no longer mandatory for clients to use it. However, it is
still common enough that it SHOULD be supported by servers. still common enough that it SHOULD be supported by servers.
10. TACACS+ Security Considerations 10. Security Considerations
The original TACACS+ Draft `The Draft' [TheDraft] from 1998 did not The original TACACS+ Draft `The Draft' [TheDraft] from 1998 did not
address all of the key security concerns which are considered when address all of the key security concerns which are considered when
designing modern standards. This section addresses known limitations designing modern standards. This section addresses known limitations
and concerns which will impact overall security of the protocol and and concerns which will impact overall security of the protocol and
systems where this protocol is deployed to manage central systems where this protocol is deployed to manage central
authentication, authorization or accounting for network device authentication, authorization or accounting for network device
administration. administration.
Multiple implementations of the protocol described in the original Multiple implementations of the protocol described in the original
skipping to change at page 40, line 4 skipping to change at page 40, line 4
The following recommendations impose restrictions on how the protocol The following recommendations impose restrictions on how the protocol
is applied. These restrictions were not imposed in the original is applied. These restrictions were not imposed in the original
draft. New implementations, and upgrades of current implementations, draft. New implementations, and upgrades of current implementations,
MUST implement these recommendations. MUST implement these recommendations.
10.5.1. Shared Secrets 10.5.1. Shared Secrets
TACACS+ servers and clients MUST treat shared secrets as sensitive TACACS+ servers and clients MUST treat shared secrets as sensitive
data to be managed securely, as would be expected for other sensitive data to be managed securely, as would be expected for other sensitive
data such as identity credential information. TACACS+ servers MUST data such as identity credential information. TACACS+ servers MUST
not leak sensitive data. For example, TACACS+ servers should not NOT leak sensitive data. For example, TACACS+ servers should not
expose shared secrets in logs. expose shared secrets in logs.
TACACS+ servers MUST allow a dedicated secret key to be defined for TACACS+ servers MUST allow a dedicated secret key to be defined for
each client. each client.
TACACS+ servers SHOULD warn administrators if secret keys are not TACACS+ servers SHOULD warn administrators if secret keys are not
unique per client. unique per client.
TACACS+ server administrators SHOULD always define a secret for each TACACS+ server administrators SHOULD always define a secret for each
client. client.
skipping to change at page 41, line 41 skipping to change at page 41, line 41
TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of
identity/password systems. identity/password systems.
TACACS+ server administrators SHOULD NOT allow the same credentials TACACS+ server administrators SHOULD NOT allow the same credentials
to be applied in challenge-based (TAC_PLUS_AUTHEN_TYPE_CHAP or to be applied in challenge-based (TAC_PLUS_AUTHEN_TYPE_CHAP or
TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2) and non TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2) and non
challenge-based authen_type options as the insecurity of the latter challenge-based authen_type options as the insecurity of the latter
will compromise the security of the former. will compromise the security of the former.
TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options
mentioned in the original draft SHOULD not be used, due to their mentioned in the original draft SHOULD NOT be used, due to their
security implications. TACACS+ servers SHOULD NOT implement them. security implications. TACACS+ servers SHOULD NOT implement them.
If they must be implemented, the servers MUST default to the options If they must be implemented, the servers MUST default to the options
being disabled and MUST warn the administrator that these options are being disabled and MUST warn the administrator that these options are
not secure. not secure.
10.5.4. Authorization 10.5.4. Authorization
The authorization and accounting features are intended to provide The authorization and accounting features are intended to provide
extensibility and flexibility. There is a base dictionary defined in extensibility and flexibility. There is a base dictionary defined in
this document, but it may be extended in deployments by using new this document, but it may be extended in deployments by using new
skipping to change at page 42, line 29 skipping to change at page 42, line 29
TACACS+ servers SHOULD deprecate the redirection mechanism. TACACS+ servers SHOULD deprecate the redirection mechanism.
If the redirection mechanism is implemented then TACACS+ servers MUST If the redirection mechanism is implemented then TACACS+ servers MUST
disable it by default, and MUST warn TACACS+ server administrators disable it by default, and MUST warn TACACS+ server administrators
that it must only be enabled within a secure deployment due to the that it must only be enabled within a secure deployment due to the
risks of revealing shared secrets. risks of revealing shared secrets.
TACACS+ clients SHOULD deprecate this feature by treating TACACS+ clients SHOULD deprecate this feature by treating
TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
11. Acknowledgements 11. IANA Considerations
This informational document describes TACACS+ protocol and its common
deployments. There is no further consideration required from IANA.
12. 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, Alexander Clouter, Chris Janicki, Tom Petch, document: Alan DeKok, Alexander Clouter, Chris Janicki, Tom Petch,
Robert Drake, among many others. Robert Drake, among many others.
The authors would particularly like to thank Alan DeKok, who provided The authors would particularly like to thank Alan DeKok, who provided
significant insights and recommendations on all aspects of the significant insights and recommendations on all aspects of the
document and the protocol. Alan DeKok has dedicated considerable document and the protocol. Alan DeKok has dedicated considerable
time and effort to help improve the document, identifying weaknesses time and effort to help improve the document, identifying weaknesses
and providing remediation. and providing remediation.
The authors would also like to thanks the support from the OPSAWG The authors would also like to thanks the support from the OPSAWG
Chairs and advisors. Chairs and advisors.
12. References 13. References
13.1. Normative 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>.
[RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
DOI 10.17487/RFC1750, December 1994,
<http://www.rfc-editor.org/info/rfc1750>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC4086] Eastlake 3rd, D., Crocker, S., and J. Schiller,
"Randomness Requirements for Security", RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
13.2. Informative References
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[TheDraft] [TheDraft]
Carrel, D. and L. Grant, "The TACACS+ Protocol Version Carrel, D. and L. Grant, "The TACACS+ Protocol Version
1.78", June 1997, 1.78", June 1997,
<https://tools.ietf.org/html/draft-grant-tacacs-02>. <https://tools.ietf.org/html/draft-grant-tacacs-02>.
[TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and [TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and
 End of changes. 17 change blocks. 
22 lines changed or deleted 35 lines changed or added

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