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/