< draft-ietf-isms-secshell-17.txt		draft-ietf-isms-secshell-18.txt >
	Network Working Group D. Harrington		Network Working Group D. Harrington
	Internet-Draft Huawei Technologies (USA)		Internet-Draft Huawei Technologies (USA)
	Intended status: Standards Track J. Salowey		Intended status: Standards Track J. Salowey
	Expires: November 7, 2009 Cisco Systems		Expires: November 12, 2009 Cisco Systems
	W. Hardaker		W. Hardaker
	Sparta, Inc.		Sparta, Inc.
	May 6, 2009		May 11, 2009
	Secure Shell Transport Model for SNMP		Secure Shell Transport Model for SNMP
	draft-ietf-isms-secshell-17		draft-ietf-isms-secshell-18
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 7, 2009.		This Internet-Draft will expire on November 12, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 41 ¶
	5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 21		5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 21
	6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 21		6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 21
	6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 21		6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 21
	6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 21		6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 21
	6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 21		6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 21
	6.3.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 22		6.3.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 22
	7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 22		7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 22
	8. Operational Considerations . . . . . . . . . . . . . . . . . . 29		8. Operational Considerations . . . . . . . . . . . . . . . . . . 29
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 30		9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	9.1. Skipping Public Key Verification . . . . . . . . . . . . . 31		9.1. Skipping Public Key Verification . . . . . . . . . . . . . 31
	9.2. Notification Authorizaton Considerations . . . . . . . . . 31		9.2. Notification Authorization Considerations . . . . . . . . 31
	9.3. SSH User and Key Selection . . . . . . . . . . . . . . . . 32		9.3. SSH User and Key Selection . . . . . . . . . . . . . . . . 32
	9.4. Conceptual Differences Between USM and SSHTM . . . . . . . 32		9.4. Conceptual Differences Between USM and SSHTM . . . . . . . 32
	9.5. The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 32		9.5. The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 32
	9.6. Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 32		9.6. Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 32
	9.7. MIB Module Security . . . . . . . . . . . . . . . . . . . 33		9.7. MIB Module Security . . . . . . . . . . . . . . . . . . . 33
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 34		12.1. Normative References . . . . . . . . . . . . . . . . . . . 34
	12.2. Informative References . . . . . . . . . . . . . . . . . . 36		12.2. Informative References . . . . . . . . . . . . . . . . . . 37
	1. Introduction		1. Introduction
	This memo describes a Transport Model for the Simple Network		This memo describes a Transport Model for the Simple Network
	Management Protocol, using the Secure Shell protocol (SSH) [RFC4251]		Management Protocol, using the Secure Shell protocol (SSH) [RFC4251]
	within a transport subsystem [I-D.ietf-isms-tmsm]. The transport		within a transport subsystem [I-D.ietf-isms-tmsm]. The transport
	model specified in this memo is referred to as the Secure Shell		model specified in this memo is referred to as the Secure Shell
	Transport Model (SSHTM).		Transport Model (SSHTM).
	This memo also defines a portion of the Management Information Base		This memo also defines a portion of the Management Information Base
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 21 ¶
	imposing any specific requirements on implementation.		imposing any specific requirements on implementation.
	1.4. Motivation		1.4. Motivation
	Version 3 of the Simple Network Management Protocol (SNMPv3) added		Version 3 of the Simple Network Management Protocol (SNMPv3) added
	security to the protocol. The User-based Security Model (USM)		security to the protocol. The User-based Security Model (USM)
	[RFC3414] was designed to be independent of other existing security		[RFC3414] was designed to be independent of other existing security
	infrastructures, to ensure it could function when third party		infrastructures, to ensure it could function when third party
	authentication services were not available, such as in a broken		authentication services were not available, such as in a broken
	network. As a result, USM utilizes a separate user and key		network. As a result, USM utilizes a separate user and key
	management infrastructure. Operators have reported that deploying		management infrastructure. Operators have reported that having to
	another user and key management infrastructure in order to use SNMPv3		deploy another user and key management infrastructure in order to use
	is a reason for not deploying SNMPv3.		SNMPv3 is a reason for not deploying SNMPv3.
	This memo describes a transport model that will make use of the		This memo describes a transport model that will make use of the
	existing and commonly deployed Secure Shell security infrastructure.		existing and commonly deployed Secure Shell security infrastructure.
	This transport model is designed to meet the security and operational		This transport model is designed to meet the security and operational
	needs of network administrators, maximize usability in operational		needs of network administrators, maximize usability in operational
	environments to achieve high deployment success and at the same time		environments to achieve high deployment success and at the same time
	minimize implementation and deployment costs to minimize deployment		minimize implementation and deployment costs to minimize deployment
	time.		time.
	This document addresses the requirement for the SSH client to		This document addresses the requirement for the SSH client to
	skipping to change at page 21, line 12 ¶		skipping to change at page 21, line 12 ¶
	the session MUST be associated with this tmSecurityName value.		the session MUST be associated with this tmSecurityName value.
	How this is accomplished is implementation-dependent.		How this is accomplished is implementation-dependent.
	5.4. Closing a Session		5.4. Closing a Session
	The Secure Shell Transport Model provides the following ASI to close		The Secure Shell Transport Model provides the following ASI to close
	a session:		a session:
	statusInformation =		statusInformation =
	closeSession(		closeSession(
	IN tmSessionID -- transport address to be used		IN tmSessionID -- session ID of session to be closed
	)		)
	The following describes the procedure to follow to close a session		The following describes the procedure to follow to close a session
	between a client and server . This process is followed by any SNMP		between a client and server. This process is followed by any SNMP
	engine to close an SSH session. It is implementation-dependent when		engine to close an SSH session. It is implementation-dependent when
	a session should be closed. The calling code should release the		a session should be closed. The calling code should release the
	associated tmStateReference.		associated tmStateReference.
	1. Increment the snmpSshtmSessionCloses counter.		1. Increment the snmpSshtmSessionCloses counter.
	2. If there is no session corresponding to tmSessionID, then		2. If there is no session corresponding to tmSessionID, then
	closeSession processing is completed.		closeSession processing is completed.
	3. Have SSH close the session associated with tmSessionID.		3. Have SSH close the session associated with tmSessionID.
	skipping to change at page 23, line 15 ¶		skipping to change at page 23, line 15 ¶
	Germany		Germany
	+49 6221 90511-15		+49 6221 90511-15
	quittek@netlab.nec.de		quittek@netlab.nec.de
	Juergen Schoenwaelder		Juergen Schoenwaelder
	Jacobs University Bremen		Jacobs University Bremen
	Campus Ring 1		Campus Ring 1
	28725 Bremen		28725 Bremen
	Germany		Germany
	+49 421 200-3587		+49 421 200-3587
	j.schoenwaelder@iu-bremen.de		j.schoenwaelder@jacobs-university.de
	Co-editors:		Co-editors:
	David Harrington		David Harrington
	Huawei Technologies USA		Huawei Technologies USA
	1700 Alma Drive		1700 Alma Drive
	Plano Texas 75075		Plano Texas 75075
	USA		USA
	+1 603-436-8634		+1 603-436-8634
	ietfdbh@comcast.net		ietfdbh@comcast.net
	skipping to change at page 25, line 23 ¶		skipping to change at page 25, line 23 ¶
	model, it must be capable of accepting messages up to		model, it must be capable of accepting messages up to
	and including 8192 octets in size. Implementation of		and including 8192 octets in size. Implementation of
	larger values is encouraged whenever possible.		larger values is encouraged whenever possible.
	The securityName prefix to be associated with the		The securityName prefix to be associated with the
	snmpSSHDomain is 'ssh'. This prefix may be used by security		snmpSSHDomain is 'ssh'. This prefix may be used by security
	models or other components to identify which secure transport		models or other components to identify which secure transport
	infrastructure authenticated a securityName."		infrastructure authenticated a securityName."
	::= { snmpDomains yy }		::= { snmpDomains yy }
	-- RFC Ed.: replace yy with IANA-assigned number and		-- RFC Ed.: replace yy with IANA-assigned number and
	-- remove this note		-- remove this note
	-- RFC Ed.: replace 'ssh' with the actual IANA assigned prefix string		-- RFC Ed.: replace 'ssh' with the actual IANA assigned prefix string
	-- if 'ssh' is not assigned to this document.		-- if 'ssh' is not assigned to this document.
	SnmpSSHAddress ::= TEXTUAL-CONVENTION		SnmpSSHAddress ::= TEXTUAL-CONVENTION
	DISPLAY-HINT "1a"		DISPLAY-HINT "1a"
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	skipping to change at page 29, line 39 ¶		skipping to change at page 29, line 36 ¶
	SNMP Secure Shell Transport Model.		SNMP Secure Shell Transport Model.
	"		"
	::= { snmpSshtmGroups 2 }		::= { snmpSshtmGroups 2 }
	END		END
	8. Operational Considerations		8. Operational Considerations
	The SSH Transport Model will likely not work in conditions where		The SSH Transport Model will likely not work in conditions where
	remote access to the CLI has stopped working. Remote access to a CLI		remote access to the CLI has stopped working. The SSH Transport
	is often over TCP, which is also used by SSH. In situations where		Model assumes that TCP and IP continue to operate correctly between
	SNMP access has to work when the CLI has stopped working, a UDP		the communicating nodes. Failures in either node, death of the
	transport model should be considered instead of the SSH Transport		deamon serving the communication, routing problems in the network
	Model.		between, firewalls that block the traffic, and other problems can
			prevent the SSH Transport Model from working. In situations where
			management access has to be very reliable, operators should consider
			mitigating measures. These measures may include dedicated
			management-only networks, point-to-point links, and the ability to
			use alternate protocols and transports.
	To have SNMP properly utilize the security services provided by SSH,		To have SNMP properly utilize the security services provided by SSH,
	the SSH Transport Model MUST be used with a Security Model that knows		the SSH Transport Model MUST be used with a Security Model that knows
	how to process a tmStateReference, such as the Transport Security		how to process a tmStateReference, such as the Transport Security
	Model for SNMP [I-D.ietf-isms-transport-security-model].		Model for SNMP [I-D.ietf-isms-transport-security-model].
	If the SSH Transport Model is configured to utilize AAA services,		If the SSH Transport Model is configured to utilize AAA services,
	operators should consider configuring support for local		operators should consider configuring support for local
	authentication mechanisms, such as local passwords, so SNMP can		authentication mechanisms, such as local passwords, so SNMP can
	continue operating during times of network stress.		continue operating during times of network stress.
	skipping to change at page 31, line 46 ¶		skipping to change at page 31, line 48 ¶
	when an attacker can insert himself between the client and the real		when an attacker can insert himself between the client and the real
	SSH server. Note that some userauth methods may defend against this		SSH server. Note that some userauth methods may defend against this
	situation, but many of the common ones (including password and		situation, but many of the common ones (including password and
	keyboard-interactive) do not, and in fact depend on the fact that the		keyboard-interactive) do not, and in fact depend on the fact that the
	server's identity has been verified (so passwords are not disclosed		server's identity has been verified (so passwords are not disclosed
	to an attacker).		to an attacker).
	SSH MUST NOT be configured to skip public key verification for use		SSH MUST NOT be configured to skip public key verification for use
	with the SSH Transport Model.		with the SSH Transport Model.
	9.2. Notification Authorizaton Considerations		9.2. Notification Authorization Considerations
	SNMP Notifications are authorized to be sent to a receiver based on		SNMP Notifications are authorized to be sent to a receiver based on
	the securityName used by the notification originator's SNMP engine.		the securityName used by the notification originator's SNMP engine.
	This authorization is performed before the message is actually sent		This authorization is performed before the message is actually sent
	and before the credentials of the remote receiver have been verified.		and before the credentials of the remote receiver have been verified.
	It is thus critical that the credentials presented by a notification		It is thus critical that the credentials presented by a notification
	receiver MUST match the expected value(s) for a given transport		receiver MUST match the expected value(s) for a given transport
	address and that ownership of the credentials MUST be properly		address and that ownership of the credentials MUST be properly
	cryptographically verified.		cryptographically verified.
	skipping to change at page 33, line 21 ¶		skipping to change at page 33, line 21 ¶
	module via direct SNMP SET operations.		module via direct SNMP SET operations.
	Some of the readable objects in this MIB module (i.e., objects with a		Some of the readable objects in this MIB module (i.e., objects with a
	MAX-ACCESS other than not-accessible) may be considered sensitive or		MAX-ACCESS other than not-accessible) may be considered sensitive or
	vulnerable in some network environments. It is thus important to		vulnerable in some network environments. It is thus important to
	control even GET and/or NOTIFY access to these objects and possibly		control even GET and/or NOTIFY access to these objects and possibly
	to even encrypt the values of these objects when sending them over		to even encrypt the values of these objects when sending them over
	the network via SNMP. These are the tables and objects and their		the network via SNMP. These are the tables and objects and their
	sensitivity/vulnerability:		sensitivity/vulnerability:
	o The readable objects in this MIB module are not sensitive.		o The information in the snmpSshtmSession group is generated locally
			when a client session is being opened or closed. This information
			can reflect the configured capabilities of a remote SSH server,
			which could be helpful to an attacker for focusing an attack.
	SNMP versions prior to SNMPv3 did not include adequate security.		SNMP versions prior to SNMPv3 did not include adequate security.
	Even if the network itself is secure (for example by using IPSec or		Even if the network itself is secure (for example by using IPSec or
	SSH), even then, there is no control as to who on the secure network		SSH), even then, there is no control as to who on the secure network
	is allowed to access and GET/SET (read/change/create/delete) the		is allowed to access and GET/SET (read/change/create/delete) the
	objects in this MIB module.		objects in this MIB module.
	It is RECOMMENDED that implementers consider the security features as		It is RECOMMENDED that implementers consider the security features as
	provided by the SNMPv3 framework (see [RFC3410] section 8), including		provided by the SNMPv3 framework (see [RFC3410] section 8), including
	full support for the USM and the SSH Transport Model cryptographic		full support for cryptographic mechanisms for authentication and
	mechanisms (for authentication and privacy).		privacy, such as those found in the User-based Security Model
			[RFC3414], the Transport Security Model
			[I-D.ietf-isms-transport-security-model] and the SSH Transport Model
			described in this document.
	Further, deployment of SNMP versions prior to SNMPv3 is NOT		Further, deployment of SNMP versions prior to SNMPv3 is NOT
	RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to		RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
	enable cryptographic security. It is then a customer/operator		enable cryptographic security. It is then a customer/operator
	responsibility to ensure that the SNMP entity giving access to an		responsibility to ensure that the SNMP entity giving access to an
	instance of this MIB module is properly configured to give access to		instance of this MIB module is properly configured to give access to
	the objects only to those principals (users) that have legitimate		the objects only to those principals (users) that have legitimate
	rights to indeed GET or SET (change/create/delete) them.		rights to indeed GET or SET (change/create/delete) them.
	10. IANA Considerations		10. IANA Considerations
	IANA is requested to assign:		IANA is requested to assign:
	1. two TCP registered port numbers in the		1. two TCP registered port numbers in the
	http://www.iana.org/assignments/port-numbers registry which will		http://www.iana.org/assignments/port-numbers registry which will
	be the default ports for SNMP over an SSH Transport Model as		be the default ports for SNMP over an SSH Transport Model as
	defined in this document, and SNMP over an SSH Transport Model		defined in this document, and SNMP over an SSH Transport Model
	for notifications as defined in this document. It would be good		for notifications as defined in this document. It would be good
	if the assigned keywords were "snmpssh" and "snmpssh-trap" and		if the assigned keywords were "snmpssh" and "snmpssh-trap" and
	the port numbers were x161 and x162.		the port numbers were x161 and x162 (where x represents a number,
			such as '5' or '6', so that we end up with ports 5161 and 5162,
			or 6161 and 6162).
	2. an SMI number under mib-2, for the MIB module in this document,		2. an SMI number under mib-2, for the MIB module in this document,
	3. an SMI number under snmpDomains, for the snmpSSHDomain,		3. an SMI number under snmpDomains, for the snmpSSHDomain,
	4. "ssh" as the corresponding prefix for the snmpSSHDomain in the		4. "ssh" as the corresponding prefix for the snmpSSHDomain in the
	SNMP Transport Model registry; defined in [I-D.ietf-isms-tmsm]		SNMP Transport Model registry; defined in [I-D.ietf-isms-tmsm]
	5. "snmp" as an SSH Subsystem Name in the		5. "snmp" as an SSH Subsystem Name in the
	http://www.iana.org/assignments/ssh-parameters registry.		http://www.iana.org/assignments/ssh-parameters registry.
	skipping to change at page 36, line 38 ¶		skipping to change at page 36, line 47 ¶
	[RFC4254] Ylonen, T. and C. Lonvick,		[RFC4254] Ylonen, T. and C. Lonvick,
	"The Secure Shell (SSH)		"The Secure Shell (SSH)
	Connection Protocol",		Connection Protocol",
	RFC 4254, January 2006.		RFC 4254, January 2006.
	[I-D.ietf-isms-tmsm] Harrington, D. and J.		[I-D.ietf-isms-tmsm] Harrington, D. and J.
	Schoenwaelder, "Transport		Schoenwaelder, "Transport
	Subsystem for the Simple		Subsystem for the Simple
	Network Management Protocol		Network Management Protocol
	(SNMP)",		(SNMP)",
	draft-ietf-isms-tmsm-17		draft-ietf-isms-tmsm-18
	(work in progress),		(work in progress),
	April 2009.		May 2009.
	12.2. Informative References		12.2. Informative References
	[RFC1994] Simpson, W., "PPP Challenge		[RFC1994] Simpson, W., "PPP Challenge
	Handshake Authentication		Handshake Authentication
	Protocol (CHAP)", RFC 1994,		Protocol (CHAP)", RFC 1994,
	August 1996.		August 1996.
	[RFC2865] Rigney, C., Willens, S.,		[RFC2865] Rigney, C., Willens, S.,
	Rubens, A., and W. Simpson,		Rubens, A., and W. Simpson,
	skipping to change at page 38, line 4 ¶		skipping to change at page 38, line 15 ¶
	RFC 4462, May 2006.		RFC 4462, May 2006.
	[RFC5090] Sterman, B., Sadolevsky,		[RFC5090] Sterman, B., Sadolevsky,
	D., Schwartz, D., Williams,		D., Schwartz, D., Williams,
	D., and W. Beck, "RADIUS		D., and W. Beck, "RADIUS
	Extension for Digest		Extension for Digest
	Authentication", RFC 5090,		Authentication", RFC 5090,
	February 2008.		February 2008.
	[RFC4742] Wasserman, M. and T.		[RFC4742] Wasserman, M. and T.
	Goddard, "Using the NETCONF		Goddard, "Using the NETCONF
	Configuration Protocol over		Configuration Protocol over
	Secure SHell (SSH)",		Secure SHell (SSH)",
	RFC 4742, December 2006.		RFC 4742, December 2006.
	[I-D.ietf-isms-transport-security-model] Harrington, D. and W.		[I-D.ietf-isms-transport-security-model] Harrington, D. and W.
	Hardaker, "Transport		Hardaker, "Transport
	Security Model for SNMP", d		Security Model for SNMP", d
	raft-ietf-isms-transport-		raft-ietf-isms-transport-
	security-model-13 (work in		security-model-14 (work in
	progress), April 2009.		progress), May 2009.
	Authors' Addresses		Authors' Addresses
	David Harrington		David Harrington
	Huawei Technologies (USA)		Huawei Technologies (USA)
	1700 Alma Dr. Suite 100		1700 Alma Dr. Suite 100
	Plano, TX 75075		Plano, TX 75075
	USA		USA
	Phone: +1 603 436 8634		Phone: +1 603 436 8634
End of changes. 20 change blocks.
	28 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/