< draft-ietf-isms-dtls-tm-00.txt		draft-ietf-isms-dtls-tm-01.txt >
	ISMS W. Hardaker		ISMS W. Hardaker
	Internet-Draft Sparta, Inc.		Internet-Draft Sparta, Inc.
	Intended status: Standards Track September 1, 2009		Intended status: Standards Track October 22, 2009
	Expires: March 5, 2010		Expires: April 25, 2010
	Transport Layer Security Transport Model for SNMP		Transport Layer Security Transport Model for SNMP
	draft-ietf-isms-dtls-tm-00.txt		draft-ietf-isms-dtls-tm-01.txt
	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 42 ¶		skipping to change at page 1, line 42 ¶
	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 March 5, 2010.		This Internet-Draft will expire on April 25, 2010.
	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 18 ¶		skipping to change at page 3, line 18 ¶
	1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7		1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
	2. The Transport Layer Security Protocol . . . . . . . . . . . . 8		2. The Transport Layer Security Protocol . . . . . . . . . . . . 8
	2.1. SNMP requirements of (D)TLS . . . . . . . . . . . . . . . 8		2.1. SNMP requirements of (D)TLS . . . . . . . . . . . . . . . 8
	3. How the TLSTM fits into the Transport Subsystem . . . . . . . 8		3. How the TLSTM fits into the Transport Subsystem . . . . . . . 8
	3.1. Security Capabilities of this Model . . . . . . . . . . . 10		3.1. Security Capabilities of this Model . . . . . . . . . . . 10
	3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 10		3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 10
	3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12		3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12
	3.1.3. (D)TLS Sessions . . . . . . . . . . . . . . . . . . . 13		3.1.3. (D)TLS Sessions . . . . . . . . . . . . . . . . . . . 13
	3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 13		3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 13
	3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14		3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14
	4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15		4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 14
	4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15		4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15
	4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15		4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15
	4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 16		4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 16		4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 16
	4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 16		4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 16
	4.3.2. SNMP Services for an Incoming Message . . . . . . . . 17		4.3.2. SNMP Services for an Incoming Message . . . . . . . . 17
	4.4. (D)TLS Services . . . . . . . . . . . . . . . . . . . . . 18		4.4. (D)TLS Services . . . . . . . . . . . . . . . . . . . . . 18
	4.4.1. Services for Establishing a Session . . . . . . . . . 18		4.4.1. Services for Establishing a Session . . . . . . . . . 18
	4.4.2. (D)TLS Services for an Incoming Message . . . . . . . 20		4.4.2. (D)TLS Services for an Incoming Message . . . . . . . 19
	4.4.3. (D)TLS Services for an Outgoing Message . . . . . . . 20		4.4.3. (D)TLS Services for an Outgoing Message . . . . . . . 20
	4.5. Cached Information and References . . . . . . . . . . . . 21		4.5. Cached Information and References . . . . . . . . . . . . 21
	4.5.1. TLS Transport Model Cached Information . . . . . . . . 21		4.5.1. TLS Transport Model Cached Information . . . . . . . . 21
	5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 21		5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 21
	5.1. Procedures for an Incoming Message . . . . . . . . . . . . 22		5.1. Procedures for an Incoming Message . . . . . . . . . . . . 22
	5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 22		5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 22
	5.1.2. Transport Processing for Incoming Messages . . . . . . 23		5.1.2. Transport Processing for Incoming Messages . . . . . . 23
	5.2. Procedures for an Outgoing Message . . . . . . . . . . . . 25		5.2. Procedures for an Outgoing Message . . . . . . . . . . . . 25
	5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 26		5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 26
	5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 28		5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 28
	6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 29		6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 29
	6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 29		6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 29
	6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 29		6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 29
	6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 29		6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 29
	6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 29		6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 29
			6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 30
	6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 30		6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 30
	6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 30		6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 30
	7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 30		7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 30
	8. Operational Considerations . . . . . . . . . . . . . . . . . . 53		8. Operational Considerations . . . . . . . . . . . . . . . . . . 53
	8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 53		8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 53
	8.2. Notification Receiver Credential Selection . . . . . . . . 53		8.2. Notification Receiver Credential Selection . . . . . . . . 54
	8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 54		8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 54
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 54		9. Security Considerations . . . . . . . . . . . . . . . . . . . 55
	9.1. Certificates, Authentication, and Authorization . . . . . 54		9.1. Certificates, Authentication, and Authorization . . . . . 55
	9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 55		9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 56
	9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 56		9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 56
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 59		12.1. Normative References . . . . . . . . . . . . . . . . . . . 59
	12.2. Informative References . . . . . . . . . . . . . . . . . . 60		12.2. Informative References . . . . . . . . . . . . . . . . . . 61
	Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 61		Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 62
	A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 61		A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 62
	A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 62		A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 62
	Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 63		Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 63
	Appendix C. Target and Notificaton Configuration Example . . . . 64		Appendix C. Target and Notificaton Configuration Example . . . . 64
			C.1. Configuring the Notification Generator . . . . . . . . . . 65
			C.2. Configuring the Command Responder . . . . . . . . . . . . 65
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 66		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 66
	1. Introduction		1. Introduction
	It is important to understand the modular SNMPv3 architecture as		It is important to understand the modular SNMPv3 architecture as
	defined by [RFC3411] and enhanced by the Transport Subsystem		defined by [RFC3411] and enhanced by the Transport Subsystem
	[I-D.ietf-isms-tmsm]. It is also important to understand the		[RFC5590]. It is also important to understand the terminology of the
	terminology of the SNMPv3 architecture in order to understand where		SNMPv3 architecture in order to understand where the Transport Model
	the Transport Model described in this document fits into the		described in this document fits into the architecture and how it
	architecture and how it interacts with the other architecture		interacts with the other architecture subsystems. For a detailed
	subsystems. For a detailed overview of the documents that describe		overview of the documents that describe the current Internet-Standard
	the current Internet-Standard Management Framework, please refer to		Management Framework, please refer to Section 7 of [RFC3410].
	Section 7 of [RFC3410].
	This document describes a Transport Model that makes use of the		This document describes a Transport Model that makes use of the
	Transport Layer Security (TLS) [RFC5246] and the Datagram Transport		Transport Layer Security (TLS) [RFC5246] and the Datagram Transport
	Layer Security (DTLS) Protocol [RFC4347], within a transport		Layer Security (DTLS) Protocol [RFC4347], within a transport
	subsystem [I-D.ietf-isms-tmsm]. DTLS is the datagram variant of the		subsystem [RFC5590]. DTLS is the datagram variant of the Transport
	Transport Layer Security (TLS) protocol [RFC5246]. The Transport		Layer Security (TLS) protocol [RFC5246]. The Transport Model in this
	Model in this document is referred to as the Transport Layer Security		document is referred to as the Transport Layer Security Transport
	Transport Model (TLSTM). TLS and DTLS take advantage of the X.509		Model (TLSTM). TLS and DTLS take advantage of the X.509 public
	public keying infrastructure [RFC5280]. This transport model is		keying infrastructure [RFC5280]. This transport model is designed to
	designed to meet the security and operational needs of network		meet the security and operational needs of network administrators,
	administrators, operate in both environments where a connectionless		operate in both environments where a connectionless (e.g. UDP or
	(e.g. UDP or SCTP) transport is preferred and in environments where		SCTP) transport is preferred and in environments where large
	large quantities of data need to be sent (e.g. over a TCP based		quantities of data need to be sent (e.g. over a TCP based stream).
	stream). Both TLS and DTLS integrate well into existing public		Both TLS and DTLS integrate well into existing public keying
	keying infrastructures.		infrastructures.
	This document also defines a portion of the Management Information		This document also defines a portion of the Management Information
	Base (MIB) for use with network management protocols. In particular		Base (MIB) for use with network management protocols. In particular
	it defines objects for managing the TLS Transport Model for SNMP.		it defines objects for managing the TLS Transport Model for SNMP.
	For a detailed overview of the documents that describe the current		For a detailed overview of the documents that describe the current
	Internet-Standard Management Framework, please refer to section 7 of		Internet-Standard Management Framework, please refer to section 7 of
	RFC [RFC3410].		RFC [RFC3410].
	Managed objects are accessed via a virtual information store, termed		Managed objects are accessed via a virtual information store, termed
	the Management Information Base or MIB. MIB objects are generally		the Management Information Base or MIB. MIB objects are generally
	accessed through the Simple Network Management Protocol (SNMP).		accessed through the Simple Network Management Protocol (SNMP).
	Objects in the MIB are defined using the mechanisms defined in the		Objects in the MIB are defined using the mechanisms defined in the
	Structure of Management Information (SMI). This memo specifies a MIB		Structure of Management Information (SMI). This memo specifies a MIB
	module that is compliant to the SMIv2, which is described in STD 58,		module that is compliant to the SMIv2, which is described in STD 58:
	[RFC2578] , STD 58, [RFC2579] and STD 58, [RFC2580]		[RFC2578], [RFC2579] and [RFC2580].
	The diagram shown below gives a conceptual overview of two SNMP		The diagram shown below gives a conceptual overview of two SNMP
	entities communicating using the TLS Transport Model. One entity		entities communicating using the TLS Transport Model. One entity
	contains a Command Responder and Notification Originator application,		contains a Command Responder and Notification Originator application,
	and the other a Command Generator and Notification Responder		and the other a Command Generator and Notification Responder
	application. It should be understood that this particular mix of		application. It should be understood that this particular mix of
	application types is an example only and other combinations are		application types is an example only and other combinations are
	equally as legitimate.		equally as legitimate.
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	| Network |		| Network |
	+----------------------------------------------------------------+		+----------------------------------------------------------------+
	^ ^ ^ ^		^ | ^ |
	|Notifications |Commands |Commands |Notifications		|Notifications |Commands |Commands |Notifications
	+---|---------------------|--------+ +--|---------------|-------------+		+---|---------------------|--------+ +--|---------------|-------------+
	| V V | | V V |		| | V | | | V |
	| +------------+ +------------+ | | +-----------+ +----------+ |		| +------------+ +------------+ | | +-----------+ +----------+ |
	| | (D)TLS | | (D)TLS | | | | (D)TLS | | (D)TLS | |		| | (D)TLS | | (D)TLS | | | | (D)TLS | | (D)TLS | |
	| | Service | | Service | | | | Service | | Service | |		| | Service | | Service | | | | Service | | Service | |
	| | (Client) | | (Server) | | | | (Client) | | (Server)| |		| | (Client) | | (Server) | | | | (Client) | | (Server)| |
	| +------------+ +------------+ | | +-----------+ +----------+ |		| +------------+ +------------+ | | +-----------+ +----------+ |
	| ^ ^ | | ^ ^ |		| ^ ^ | | ^ ^ |
	| | | | | | | |		| | | | | | | |
	| +--+----------+ | | +-+--------------+ |		| +--+----------+ | | +-+--------------+ |
	| +-----|---------+----+ | | +---|--------+----+ |		| +-----|---------+----+ | | +---|--------+----+ |
	| | V |LCD | +-------+ | | | V |LCD | +--------+ |		| | V |LCD | +-------+ | | | V |LCD | +--------+ |
	skipping to change at page 7, line 46 ¶		skipping to change at page 7, line 45 ¶
	roles depending on the SNMP application types supported in the		roles depending on the SNMP application types supported in the
	implementation. Where distinction is required, the application names		implementation. Where distinction is required, the application names
	of Command Generator, Command Responder, Notification Originator,		of Command Generator, Command Responder, Notification Originator,
	Notification Receiver, and Proxy Forwarder are used. See "SNMP		Notification Receiver, and Proxy Forwarder are used. See "SNMP
	Applications" [RFC3413] for further information.		Applications" [RFC3413] for further information.
	Throughout this document, the terms "client" and "server" are used to		Throughout this document, the terms "client" and "server" are used to
	refer to the two ends of the (D)TLS transport connection. The client		refer to the two ends of the (D)TLS transport connection. The client
	actively opens the (D)TLS connection, and the server passively		actively opens the (D)TLS connection, and the server passively
	listens for the incoming (D)TLS connection. Either SNMP entity may		listens for the incoming (D)TLS connection. Either SNMP entity may
	act as client or as server, as discussed further below.		act as client or as server.
	The User-Based Security Model (USM) [RFC3414] is a mandatory-to-		The User-Based Security Model (USM) [RFC3414] is a mandatory-to-
	implement Security Model in STD 62. While (D)TLS and USM frequently		implement Security Model in STD 62. While (D)TLS and USM frequently
	refer to a user, the terminology preferred in RFC3411 [RFC3411] and		refer to a user, the terminology preferred in RFC3411 and in this
	in this memo is "principal". A principal is the "who" on whose		memo is "principal". A principal is the "who" on whose behalf
	behalf services are provided or processing takes place. A principal		services are provided or processing takes place. A principal can be,
	can be, among other things, an individual acting in a particular		among other things, an individual acting in a particular role; a set
	role; a set of individuals, with each acting in a particular role; an		of individuals, with each acting in a particular role; an application
	application or a set of applications, or a combination of these		or a set of applications, or a combination of these within an
	within an administrative domain.		administrative domain.
	Throughout this document, the term "session" is used to refer to a		Throughout this document, the term "session" is used to refer to a
	secure association between two TLS Transport Models that permits the		secure association between two TLS Transport Models that permits the
	transmission of one or more SNMP messages within the lifetime of the		transmission of one or more SNMP messages within the lifetime of the
	session.		session.
	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].		document are to be interpreted as described in [RFC2119].
	2. The Transport Layer Security Protocol		2. The Transport Layer Security Protocol
	(D)TLS provides authentication, data message integrity, and privacy		(D)TLS provides authentication, data message integrity, and privacy
	at the transport layer. (See [RFC4347])		at the transport layer. (See [RFC4347])
	The primary goals of the TLS Transport Model are to provide privacy,		The primary goals of the TLS Transport Model are to provide privacy,
	source authentication and data integrity between two communicating		source authentication and data integrity between two communicating
	SNMP entities. The TLS and DTLS protocols provide a secure transport		SNMP entities. The TLS and DTLS protocols provide a secure transport
	upon which the TLSTM is based. An overview of (D)TLS can be found in		upon which the TLSTM is based. An overview of (D)TLS can be found in
	section Appendix A. Please refer to [RFC4347] for a complete		section Appendix A. Please refer to [RFC5246] and [RFC4347] for
	description of the protocol.		complete descriptions of the protocols.
	2.1. SNMP requirements of (D)TLS		2.1. SNMP requirements of (D)TLS
	To properly support the SNMP over TLS Transport Model, the (D)TLS		To properly support the SNMP over TLS Transport Model, the (D)TLS
	implementation requires the following:		implementation requires the following:
	o The TLS Transport Model SHOULD always use authentication of both		o The TLS Transport Model SHOULD always use authentication of both
	the server and the client.		the server and the client.
	o At a minimum the TLS Transport Model MUST support authentication		o At a minimum the TLS Transport Model MUST support authentication
	of the Command Generator principals to guarantee the authenticity		of the Command Generator, Notification Originator and Proxy
	of the securityName.		Forwarder principals to guarantee the authenticity of the
			securityName.
	o The TLS Transport Model SHOULD support the message encryption to		o The TLS Transport Model SHOULD support the message encryption to
	protect sensitive data from eavesdropping attacks.		protect sensitive data from eavesdropping attacks.
	3. How the TLSTM fits into the Transport Subsystem		3. How the TLSTM fits into the Transport Subsystem
	A transport model is a component of the Transport Subsystem. The TLS		A transport model is a component of the Transport Subsystem. The TLS
	Transport Model thus fits between the underlying (D)TLS transport		Transport Model thus fits between the underlying (D)TLS transport
	layer and the message dispatcher [RFC3411] component of the SNMP		layer and the message dispatcher [RFC3411] component of the SNMP
	engine and the Transport Subsystem.		engine and the Transport Subsystem.
	skipping to change at page 11, line 16 ¶		skipping to change at page 11, line 16 ¶
	operations unauthorized for a given principal may be attempted by		operations unauthorized for a given principal may be attempted by
	assuming the identity of another principal that has the		assuming the identity of another principal that has the
	appropriate authorizations.		appropriate authorizations.
	The TLSTM provides for authentication of the Command Generator,		The TLSTM provides for authentication of the Command Generator,
	Command Responder, Notification Generator, Notification Responder		Command Responder, Notification Generator, Notification Responder
	and Proxy Forwarder through the use of X.509 certificates.		and Proxy Forwarder through the use of X.509 certificates.
	The masquerade threat can be mitigated against by using an		The masquerade threat can be mitigated against by using an
	appropriate Access Control Model (ACM) such as the View-based		appropriate Access Control Model (ACM) such as the View-based
	Access Control Module (VACM) [RFC3415]. In addition, it is		Access Control Module (VACM) [RFC3415].
	important to authenticate and verify both the authenticated
	identity of the (D)TLS client and the (D)TLS server to protect
	against this threat. (See Section 9 for more detail.)
	3. Message stream modification - The re-ordering, delay or replay of		3. Message stream modification - The re-ordering, delay or replay of
	messages can and does occur through the natural operation of many		messages can and does occur through the natural operation of many
	connectionless transport services. The message stream		connectionless transport services. The message stream
	modification threat is the danger that messages may be		modification threat is the danger that messages may be
	maliciously re-ordered, delayed or replayed to an extent which is		maliciously re-ordered, delayed or replayed to an extent which is
	greater than can occur through the natural operation of		greater than can occur through the natural operation of
	connectionless transport services, in order to effect		connectionless transport services, in order to effect
	unauthorized management operations.		unauthorized management operations.
	(D)TLS provides replay protection with a MAC that includes a		(D)TLS provides replay protection with a MAC that includes a
	sequence number. Since UDP provides no sequencing ability DTLS		sequence number. Since UDP provides no sequencing ability DTLS
	uses a sliding window protocol with the sequence number for		uses a sliding window protocol with the sequence number for
	replay protection, see [RFC4347]. The technique used is similar		replay protection (see [RFC4347]).
	to that as in IPsec AH/ESP [RFC4302] [RFC4303], by maintaining a
	bitmap window of received records. Records that are too old to
	fit in the window and records that have previously been received
	are silently discarded. The replay detection feature is
	optional, since packet duplication can also occur naturally due
	to routing errors and does not necessarily indicate an active
	attack. Applications may conceivably detect duplicate packets
	and accordingly modify their data transmission strategy.
	4. Disclosure - The disclosure threat is the danger of eavesdropping		4. Disclosure - The disclosure threat is the danger of eavesdropping
	on the exchanges between SNMP engines. Protecting against this		on the exchanges between SNMP engines.
	threat may be required by local policy at the deployment site.
	Symmetric cryptography (e.g., AES [AES], DES [DES] etc.) can be		Symmetric cryptography (e.g., [AES], [DES] etc.) can be used by
	used by (D)TLS for data privacy. The keys for this symmetric		(D)TLS for data privacy. The keys for this symmetric encryption
	encryption are generated uniquely for each session and are based		are generated uniquely for each session and are based on a secret
	on a secret negotiated by another protocol (such as the (D)TLS		negotiated by another protocol (such as the (D)TLS Handshake
	Handshake Protocol).		Protocol).
	5. Denial of Service - the RFC 3411 architecture [RFC3411] states		5. Denial of Service - the RFC 3411 architecture [RFC3411] states
	that denial of service (DoS) attacks need not be addressed by an		that denial of service (DoS) attacks need not be addressed by an
	SNMP security protocol. However, datagram-based security		SNMP security protocol. However, datagram-based security
	protocols like DTLS are susceptible to a variety of denial of		protocols like DTLS are susceptible to a variety of denial of
	service attacks because it is more vulnerable to spoofed		service attacks because it is more vulnerable to spoofed
	messages.		messages.
	In order to counter both of these attacks, DTLS borrows the		In order to counter these attacks, DTLS borrows the stateless
	stateless cookie technique used by Photuris [RFC2522] and IKEv2		cookie technique used by Photuris [RFC2522] and IKEv2 [RFC4306]
	[RFC4306] and is described fully in section 4.2.1 of [RFC4347].		and is described fully in section 4.2.1 of [RFC4347]. This
	This mechanism, though, does not provide any defense against		mechanism, though, does not provide any defense against denial of
	denial of service attacks mounted from valid IP addresses. DTLS		service attacks mounted from valid IP addresses. DTLS Transport
	Transport Model server implementations MUST support DTLS cookies.		Model server implementations MUST support DTLS cookies.
	Implementations are not required to perform the stateless cookie		Implementations are not required to perform the stateless cookie
	exchange for every DTLS handshakes but in environments where		exchange for every DTLS handshakes but in environments where
	amplification could be an issue or has been detected it is		amplification could be an issue or has been detected it is
	RECOMMENDED that the cookie exchange is utilized.		RECOMMENDED that the cookie exchange is utilized.
			See Section 9 for more detail on the security considerations
			associated with the DTLSTM and these security threats.
	3.1.2. Message Protection		3.1.2. Message Protection
	The RFC 3411 architecture recognizes three levels of security:		The RFC 3411 architecture recognizes three levels of security:
	o without authentication and without privacy (noAuthNoPriv)		o without authentication and without privacy (noAuthNoPriv)
	o with authentication but without privacy (authNoPriv)		o with authentication but without privacy (authNoPriv)
	o with authentication and with privacy (authPriv)		o with authentication and with privacy (authPriv)
	The TLS Transport Model determines from (D)TLS the identity of the		The TLS Transport Model determines from (D)TLS the identity of the
	authenticated principal, and the type and address associated with an		authenticated principal, and the type and address associated with an
	incoming message, and the TLS Transport Model provides this		incoming message. The TLS Transport Model provides this information
	information to (D)TLS for an outgoing message.		to (D)TLS for an outgoing message.
	When an application requests a session for a message, through the		When an application requests a session for a message, through the
	cache, the application requests a security level for that session.		cache, the application requests a security level for that session.
	The TLS Transport Model MUST ensure that the (D)TLS session provides		The TLS Transport Model MUST ensure that the (D)TLS session provides
	security at least as high as the requested level of security. How		security at least as high as the requested level of security. How
	the security level is translated into the algorithms used to provide		the security level is translated into the algorithms used to provide
	data integrity and privacy is implementation-dependent. However, the		data integrity and privacy is implementation-dependent. However, the
	NULL integrity and encryption algorithms MUST NOT be used to fulfill		NULL integrity and encryption algorithms MUST NOT be used to fulfill
	security level requests for authentication or privacy.		security level requests for authentication or privacy.
	Implementations MAY choose to force (D)TLS to only allow		Implementations MAY choose to force (D)TLS to only allow
	cipher_suites that provide both authentication and privacy to		cipher_suites that provide both authentication and privacy to
	guarantee this assertion.		guarantee this assertion.
	If a suitable interface between the TLS Transport Model and the		If a suitable interface between the TLS Transport Model and the
	(D)TLS Handshake Protocol is implemented to allow the selection of		(D)TLS Handshake Protocol is implemented to allow the selection of
	security level dependent algorithms, for example a security level to		security level dependent algorithms (for example a security level to
	cipher_suites mapping table, then different security levels may be		cipher_suites mapping table) then different security levels may be
	utilized by the application. However, different port numbers will		utilized by the application.
	need to be used by at least one side of the connection to
	differentiate between the (D)TLS sessions. This is the only way to
	ensured proper selection of a session ID for an incoming (D)TLS
	message.
	The authentication, integrity and privacy algorithms used by the		The authentication, integrity and privacy algorithms used by the
	(D)TLS Protocol [RFC4347] may vary over time as the science of		(D)TLS Protocols may vary over time as the science of cryptography
	cryptography continues to evolve and the development of (D)TLS		continues to evolve and the development of (D)TLS continues over
	continues over time. Implementers are encouraged to plan for changes		time. Implementers are encouraged to plan for changes in operator
	in operator trust of particular algorithms and implementations should		trust of particular algorithms and implementations should offer
	offer configuration settings for mapping algorithms to SNMPv3		configuration settings for mapping algorithms to SNMPv3 security
	security levels.		levels.
	3.1.3. (D)TLS Sessions		3.1.3. (D)TLS Sessions
	(D)TLS sessions are opened by the TLS Transport Model during the		(D)TLS sessions are opened by the TLS Transport Model during the
	elements of procedure for an outgoing SNMP message. Since the sender		elements of procedure for an outgoing SNMP message. Since the sender
	of a message initiates the creation of a (D)TLS session if needed,		of a message initiates the creation of a (D)TLS session if needed,
	the (D)TLS session will already exist for an incoming message.		the (D)TLS session will already exist for an incoming message.
	Implementations MAY choose to instantiate (D)TLS sessions in		Implementations MAY choose to instantiate (D)TLS sessions in
	anticipation of outgoing messages. This approach might be useful to		anticipation of outgoing messages. This approach might be useful to
	ensure that a (D)TLS session to a given target can be established		ensure that a (D)TLS session to a given target can be established
	before it becomes important to send a message over the (D)TLS		before it becomes important to send a message over the (D)TLS
	session. Of course, there is no guarantee that a pre-established		session. Of course, there is no guarantee that a pre-established
	session will still be valid when needed.		session will still be valid when needed.
	DTLS sessions, when used over UDP, are uniquely identified within the		DTLS sessions, when used over UDP, are uniquely identified within the
	TLS Transport Model by the combination of transportDomain,		TLS Transport Model by the combination of transportDomain,
	transportAddress, securityName, and requestedSecurityLevel associated		transportAddress, securityName, and requestedSecurityLevel associated
	with each session. Each unique combination of these parameters MUST		with each session. Each unique combination of these parameters MUST
	have a locally-chosen unique dtlsSessionID associated for active		have a locally-chosen unique tlsSessionID associated for active
	sessions. For further information see Section 4.4 and Section 5.		sessions. For further information see Section 4.4 and Section 5.
	TLS and DTLS over SCTP sessions, on the other hand, do not require a		TLS and DTLS over SCTP sessions, on the other hand, do not require a
	unique paring of attributes since their lower layer protocols (TCP		unique pairing of attributes since their lower layer protocols (TCP
	and SCTP) already provide adequate session framing.		and SCTP) already provide adequate session framing.
	3.2. Security Parameter Passing		3.2. Security Parameter Passing
	For the (D)TLS server-side, (D)TLS-specific security parameters		For the (D)TLS server-side, (D)TLS-specific security parameters
	(i.e., cipher_suites, X.509 certificate fields, IP address and port)		(i.e., cipher_suites, X.509 certificate fields, IP address and port)
	are translated by the TLS Transport Model into security parameters		are translated by the TLS Transport Model into security parameters
	for the TLS Transport Model and security model (i.e., securityLevel,		for the TLS Transport Model and security model (i.e., securityLevel,
	securityName, transportDomain, transportAddress). The transport-		securityName, transportDomain, transportAddress). The transport-
	related and (D)TLS-security-related information, including the		related and (D)TLS-security-related information, including the
	skipping to change at page 14, line 19 ¶		skipping to change at page 14, line 8 ¶
	Interface (ASI) and input from the tmStateReference cache. The		Interface (ASI) and input from the tmStateReference cache. The
	(D)TLS Transport Model converts that information into suitable		(D)TLS Transport Model converts that information into suitable
	security parameters for (D)TLS and establishes sessions as needed.		security parameters for (D)TLS and establishes sessions as needed.
	The elements of procedure in Section 5 discuss these concepts in much		The elements of procedure in Section 5 discuss these concepts in much
	greater detail.		greater detail.
	3.3. Notifications and Proxy		3.3. Notifications and Proxy
	(D)TLS sessions may be initiated by (D)TLS clients on behalf of		(D)TLS sessions may be initiated by (D)TLS clients on behalf of
	command generators or notification originators. Command generators		command generators, notification originators or proxy forwarders.
	are frequently operated by a human, but notification originators are		Command generators are frequently operated by a human, but
	usually unmanned automated processes. The targets to whom		notification originators and proxy forwarders are usually unmanned
	notifications should be sent is typically determined and configured		automated processes. The targets to whom notifications should be
	by a network administrator.		sent is typically determined and configured by a network
			administrator.
	The SNMP-TARGET-MIB module [RFC3413] contains objects for defining		The SNMP-TARGET-MIB module [RFC3413] contains objects for defining
	management targets, including transportDomain, transportAddress,		management targets, including transportDomain, transportAddress,
	securityName, securityModel, and securityLevel parameters, for		securityName, securityModel, and securityLevel parameters, for
	Notification Generator, Proxy Forwarder, and SNMP-controllable		Notification Generator, Proxy Forwarder, and SNMP-controllable
	Command Generator applications. Transport domains and transport		Command Generator applications. Transport domains and transport
	addresses are configured in the snmpTargetAddrTable, and the		addresses are configured in the snmpTargetAddrTable, and the
	securityModel, securityName, and securityLevel parameters are		securityModel, securityName, and securityLevel parameters are
	configured in the snmpTargetParamsTable. This document defines a MIB		configured in the snmpTargetParamsTable. This document defines a MIB
	module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to		module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to
	specify a (D)TLS client-side certificate to use for the connection.		specify a (D)TLS client-side certificate to use for the connection.
	When configuring a (D)TLS target, the snmpTargetAddrTDomain and		When configuring a (D)TLS target, the snmpTargetAddrTDomain and
	snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be		snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be
	set to the snmpTLSDomain, snmpDTLSUDPDomain, or snmpDTLSSCTPDomain		set to the snmpTLSDomain, snmpDTLSUDPDomain, or snmpDTLSSCTPDomain
	object and an appropriate snmpTLSAddress, snmpDTLSUDPAddress or		object and an appropriate snmpTLSAddress, snmpDTLSUDPAddress or
	snmpDTLSSCTPAddress value respectively. The snmpTargetParamsMPModel		snmpDTLSSCTPAddress value respectively. The snmpTargetParamsMPModel
	column of the snmpTargetParamsTable should be set to a value of 3 to		column of the snmpTargetParamsTable should be set to a value of 3 to
	indicate the SNMPv3 message processing model. The		indicate the SNMPv3 message processing model. The
	snmpTargetParamsSecurityName should be set to an appropriate		snmpTargetParamsSecurityName should be set to an appropriate
	securityName value and the tlstmParamsClientHashType and		securityName value and the tlstmParamsClientFingerprint parameter of
	tlstmParamsClientHashValue parameters of the tlstmParamsTable should		the tlstmParamsTable should be set a value that refers to a locally
	be set to values that refer to a locally held certificate to be used.		held certificate to be used. The tlstmAddrServerFingerprint must be
	The tlstmAddrServerHashType and tlstmAddrServerHashValue must be set		set to a hash value that refers to a locally held copy of the
	to a hash value that refers to a locally held copy of the server's		server's presented identity certificate. Other parameters, for
	presented identity certificate. Other parameters, for example		example cryptographic configuration such as cipher suites to use,
	cryptographic configuration such as cipher suites to use, must come		must come from configuration mechanisms not defined in this document.
	from configuration mechanisms not defined in this document. The		The securityName defined in the snmpTargetParamsSecurityName column
	other needed configuration may be configured using SNMP or other		will be used by the access control model to authorize any
	implementation-dependent mechanisms (for example, via a CLI). This		notifications that need to be sent.
	securityName defined in the snmpTargetParamsSecurityName column will
	be used by the access control model to authorize any notifications
	that need to be sent.
	4. Elements of the Model		4. Elements of the Model
	This section contains definitions required to realize the (D)TLS		This section contains definitions required to realize the (D)TLS
	Transport Model defined by this document.		Transport Model defined by this document.
	4.1. X.509 Certificates		4.1. X.509 Certificates
	(D)TLS makes use of X.509 certificates for authentication of both		(D)TLS makes use of X.509 certificates for authentication of both
	sides of the transport. This section discusses the use of		sides of the transport. This section discusses the use of
	certificates in the TLSTM. An overview of X.509 certificate		certificates in the TLSTM. A brief overview of X.509 certificate
	infrastructure can be found in Appendix B.		infrastructure can be found in Appendix B.
	4.1.1. Provisioning for the Certificate		4.1.1. Provisioning for the Certificate
	Authentication using (D)TLS will require that SNMP entities are		Authentication using (D)TLS will require that SNMP entities are
	provisioned with certificates, which are signed by trusted		provisioned with certificates, which are signed by trusted
	certificate authorities. Furthermore, SNMP entities will most		certificate authorities. Furthermore, SNMP entities will most
	commonly need to be provisioned with root certificates which		commonly need to be provisioned with root certificates which
	represent the list of trusted certificate authorities that an SNMP		represent the list of trusted certificate authorities that an SNMP
	entity can use for certificate verification. SNMP entities SHOULD		entity can use for certificate verification. SNMP entities SHOULD
	also be provisioned with a X.509 certificate revocation mechanism		also be provisioned with a X.509 certificate revocation mechanism
	which can be used to verify that a certificate has not been revoked.		which can be used to verify that a certificate has not been revoked.
			The certificate trust anchors, being either CA certificates or public
			keys for use by self-signed certificates, must be installed through
			an out of band trusted mechanism into the server and its authenticity
			MUST be verified before access is granted.
	The authenticated tmSecurityName of the principal is looked up using		Having received a certificate, the authenticated tmSecurityName of
	the tlstmCertToSNTable. This table either:		the principal is looked up using the tlstmCertToSNTable. This table
			either:
	o Maps a certificate's fingerprint hash type and value to a directly		o Maps a certificate's fingerprint type and value to a directly
	specified tmSecurityName.		specified tmSecurityName, or
	o Identifies a certificate issuer's fingerprint hash type and value		o Identifies a certificate issuer's fingerprint and allows a child
	and allows child certificate's subjectAltName or CommonName to		certificate's subjectAltName or CommonName to be mapped to the
	directly used as the tmSecurityNome.		tmSecurityNome.
	The certificate trust anchors, being either CA certificates or public		Implementations MAY choose to discard any connections for which no
	keys for use by self-signed certificates, must be installed through		potential tlstmCertToSNTable mapping exists before performing
	an out of band trusted mechanism into the server and its authenticity		certificate verification to avoid expending computational resources
	MUST be verified before access is granted. Implementations SHOULD		associated with certificate verification.
	choose to discard any connections for which no potential
	tlstmCertToSNTable mapping exists before performing certificate
	verification to avoid expending computational resources associated
	with certificate verification.
	The typical enterprise configuration will map a "subjectAltName"		The typical enterprise configuration will map a "subjectAltName"
	component of the tbsCertificate to the TLSTM specific tmSecurityName.		component of the tbsCertificate to the TLSTM specific tmSecurityName.
	Thus, the authenticated identity can be obtained by the TLS Transport		The authenticated identity can be obtained by the TLS Transport Model
	Model by extracting the subjectAltName(s) from the peer's certificate		by extracting the subjectAltName(s) from the peer's certificate. The
	and the receiving application will have an appropriate tmSecurityName		receiving application will then have an appropriate tmSecurityName
	for use by components like an access control model. This setup		for use by other SNMPv3 components like an access control model.
	requires very little configuration: a single row in the
	tlstmCertToSNTable referencing a certificate authority.
	An example mapping setup can be found in Appendix C		An example of this type of mapping setup can be found in Appendix C
	This tmSecurityName may be later translated from a TLSTM specific		This tmSecurityName may be later translated from a TLSTM specific
	tmSecurityName to a SNMP engine securityName by the security model.		tmSecurityName to a SNMP engine securityName by the security model.
	A security model, like the TSM security model, may perform an		A security model, like the TSM security model [RFC5591], may perform
	identity mapping or a more complex mapping to derive the securityName		an identity mapping or a more complex mapping to derive the
	from the tmSecurityName offered by the TLS Transport Model.		securityName from the tmSecurityName offered by the TLS Transport
			Model.
	4.2. Messages		4.2. Messages
	As stated in Section 4.1.1 of [RFC4347], each DTLS record must fit		As stated in Section 4.1.1 of [RFC4347], each DTLS record must fit
	within a single DTLS datagram. The TLSTM SHOULD prohibit SNMP		within a single DTLS datagram. The TLSTM SHOULD prohibit SNMP
	messages from being sent that exceeds the maximum DTLS message size.		messages from being sent that exceeds the maximum DTLS message size.
	The TLSTM implementation SHOULD return an error when the DTLS message		The TLSTM implementation SHOULD return an error when the DTLS message
	size would be exceeded and the message won't be sent.		size would be exceeded and the message won't be sent.
	4.3. SNMP Services		4.3. SNMP Services
	skipping to change at page 17, line 6 ¶		skipping to change at page 16, line 43 ¶
	statusInformation =		statusInformation =
	sendMessage(		sendMessage(
	IN destTransportDomain -- transport domain to be used		IN destTransportDomain -- transport domain to be used
	IN destTransportAddress -- transport address to be used		IN destTransportAddress -- transport address to be used
	IN outgoingMessage -- the message to send		IN outgoingMessage -- the message to send
	IN outgoingMessageLength -- its length		IN outgoingMessageLength -- its length
	IN tmStateReference -- reference to transport state		IN tmStateReference -- reference to transport state
	)		)
	The abstract data elements passed as parameters in the abstract		The abstract data elements returned from or passed as parameters into
	service primitives are as follows:		the abstract service primitives are as follows:
	statusInformation: An indication of whether the passing of the		statusInformation: An indication of whether the passing of the
	message was successful. If not it is an indication of the		message was successful. If not, it is an indication of the
	problem.		problem.
	destTransportDomain: The transport domain for the associated		destTransportDomain: The transport domain for the associated
	destTransportAddress. The Transport Model uses this parameter to		destTransportAddress. The Transport Model uses this parameter to
	determine the transport type of the associated		determine the transport type of the associated
	destTransportAddress. This parameter may also be used by the		destTransportAddress. This parameter may also be used by the
	transport subsystem to route the message to the appropriate		transport subsystem to route the message to the appropriate
	Transport Model. This document specifies three TLS and DTLS based		Transport Model. This document specifies three TLS and DTLS based
	Transport Domains for use: the snmpTLSDomain, the		Transport Domains for use: the snmpTLSDomain, the
	snmpDTLSUDPDomain and the snmpDTLSSCTPDomain.		snmpDTLSUDPDomain and the snmpDTLSSCTPDomain.
	destTransportAddress: The transport address of the destination TLS		destTransportAddress: The transport address of the destination TLS
	Transport Model in a format specified by the SnmpTLSAddress, the		Transport Model in a format specified by the SnmpTLSAddress, the
	SnmpDTLSUDPAddress or the SnmpDTLSSCTPAddress TEXTUAL-CONVENTIONs.		SnmpDTLSUDPAddress or the SnmpDTLSSCTPAddress TEXTUAL-CONVENTIONs.
	outgoingMessage: The outgoing message to send to (D)TLS for		outgoingMessage: The outgoing message to send to (D)TLS for
	encapsulation.		encapsulation.
	outgoingMessageLength: The length of the outgoing message.		outgoingMessageLength: The length of the outgoingMessage field.
	tmStateReference: A handle/reference to tmSecurityData to be used		tmStateReference: A handle/reference to tmSecurityData to be used
	when securing outgoing messages.		when securing outgoing messages.
	4.3.2. SNMP Services for an Incoming Message		4.3.2. SNMP Services for an Incoming Message
	The TLS Transport Model processes the received message from the		The TLS Transport Model processes the received message from the
	network using the (D)TLS service and then passes it to the dispatcher		network using the (D)TLS service and then passes it to the dispatcher
	using the following ASI:		using the following ASI:
	statusInformation =		statusInformation =
	receiveMessage(		receiveMessage(
	IN transportDomain -- origin transport domain		IN transportDomain -- origin transport domain
	IN transportAddress -- origin transport address		IN transportAddress -- origin transport address
	IN incomingMessage -- the message received		IN incomingMessage -- the message received
	IN incomingMessageLength -- its length		IN incomingMessageLength -- its length
	IN tmStateReference -- reference to transport state		IN tmStateReference -- reference to transport state
	)		)
	The abstract data elements passed as parameters in the abstract		The abstract data elements returned from or passed as parameters into
	service primitives are as follows:		the abstract service primitives are as follows:
	statusInformation: An indication of whether the passing of the		statusInformation: An indication of whether the passing of the
	message was successful. If not it is an indication of the		message was successful. If not, it is an indication of the
	problem.		problem.
	transportDomain: The transport domain for the associated		transportDomain: The transport domain for the associated
	transportAddress. This document specifies three TLS and DTLS		transportAddress. This document specifies three TLS and DTLS
	based Transport Domains for use: the snmpTLSDomain, the		based Transport Domains for use: the snmpTLSDomain, the
	snmpDTLSUDPDomain and the snmpDTLSSCTPDomain.		snmpDTLSUDPDomain and the snmpDTLSSCTPDomain.
	transportAddress: The transport address of the source of the		transportAddress: The transport address of the source of the
	received message in a format specified by the SnmpTLSAddress, the		received message in a format specified by the SnmpTLSAddress, the
	SnmpDTLSUDPAddress or the SnmpDTLSSCTPAddress TEXTUAL-CONVENTION.		SnmpDTLSUDPAddress or the SnmpDTLSSCTPAddress TEXTUAL-CONVENTION.
	incomingMessage: The whole SNMP message stripped of all (D)TLS		incomingMessage: The whole SNMP message after being processed by
	protection data.		(D)TLS and removed of the (D)TLS transport layer data.
	incomingMessageLength: The length of the SNMP message after being		incomingMessageLength: The length of the incomingMessage field.
	processed by (D)TLS.
	tmStateReference: A handle/reference to tmSecurityData to be used by		tmStateReference: A handle/reference to tmSecurityData to be used by
	the security model.		the security model.
	4.4. (D)TLS Services		4.4. (D)TLS Services
	This section describes the services provided by the (D)TLS Transport		This section describes the services provided by the (D)TLS Transport
	Model with their inputs and outputs. These services are between the		Model with their inputs and outputs. These services are between the
	TLS Transport Model and the (D)TLS transport layer. The following		TLS Transport Model and the (D)TLS transport layer. The following
	sections describe services for establishing and closing a session and		sections describe services for establishing and closing a session and
	skipping to change at page 18, line 51 ¶		skipping to change at page 18, line 41 ¶
	statusInformation = -- errorIndication or success		statusInformation = -- errorIndication or success
	openSession(		openSession(
	IN destTransportDomain -- transport domain to be used		IN destTransportDomain -- transport domain to be used
	IN destTransportAddress -- transport address to be used		IN destTransportAddress -- transport address to be used
	IN securityName -- on behalf of this principal		IN securityName -- on behalf of this principal
	IN securityLevel -- Level of Security requested		IN securityLevel -- Level of Security requested
	OUT tlsSessionID -- Session identifier for (D)TLS		OUT tlsSessionID -- Session identifier for (D)TLS
	)		)
	The abstract data elements passed as parameters in the abstract		The abstract data elements returned from or passed as parameters into
	service primitives are as follows:		the abstract service primitives are as follows:
	statusInformation: An indication of whether the process was		statusInformation: An indication of whether the process was
	successful or not. If not, then the status information will		successful or not. If not, then the status information will
	include the error indication provided by (D)TLS.		include the error indication provided by (D)TLS.
	destTransportDomain: The transport domain for the associated		destTransportDomain: The transport domain for the associated
	destTransportAddress. The TLS Transport Model uses this parameter		destTransportAddress. The TLS Transport Model uses this parameter
	to determine the transport type of the associated		to determine the transport type of the associated
	destTransportAddress. This document specifies three TLS and DTLS		destTransportAddress. This document specifies three TLS and DTLS
	based Transport Domains for use: the snmpTLSDomain, the		based Transport Domains for use: the snmpTLSDomain, the
	skipping to change at page 19, line 26 ¶		skipping to change at page 19, line 16 ¶
	destTransportAddress: The transport address of the destination TLS		destTransportAddress: The transport address of the destination TLS
	Transport Model in a format specified by the SnmpTLSAddress, the		Transport Model in a format specified by the SnmpTLSAddress, the
	SnmpDTLSUDPAddress or the SnmpDTLSSCTPAddress TEXTUAL-CONVENTION.		SnmpDTLSUDPAddress or the SnmpDTLSSCTPAddress TEXTUAL-CONVENTION.
	securityName: The security name representing the principal on whose		securityName: The security name representing the principal on whose
	behalf the message will be sent.		behalf the message will be sent.
	securityLevel: The level of security requested by the application.		securityLevel: The level of security requested by the application.
	dtlsSessionID: An implementation-dependent session identifier to		tlsSessionID: An implementation-dependent session identifier to
	reference the specific (D)TLS session.		reference the specific (D)TLS session.
	DTLS and UDP do not provide a session de-multiplexing mechanism and		Neither DTLS or UDP provides a session de-multiplexing mechanism and
	it is possible that implementations will only be able to identify a		it is possible that implementations will only be able to identify a
	unique session based on a unique combination of source address,		unique session based on a unique combination of source address,
	destination address, source UDP port number and destination UDP port		destination address, source UDP port number and destination UDP port
	number. Because of this, when establishing a new sessions		number. Because of this, when establishing a new sessions
	implementations MUST use a different UDP source port number for each		implementations MUST use a different UDP source port number for each
	connection to a remote destination IP-address/port-number combination		connection to a given remote destination IP-address/port-number
	to ensure the remote entity can properly disambiguate between		combination to ensure the remote entity can properly disambiguate
	multiple sessions from a host to the same port on a server. TLS and		between multiple sessions from a host to the same port on a server.
	DTLS over SCTP provide session de-multiplexing so this restriction is		TLS and DTLS over SCTP provide session de-multiplexing so this
	not needed for TLS or DTLS over SCTP implementations.		restriction is not needed for TLS or DTLS over SCTP implementations.
	The procedural details for establishing a session are further		The procedural details for establishing a session are further
	described in Section 5.3.		described in Section 5.3.
	Upon completion of the process the TLS Transport Model returns status		Upon completion of the process the TLS Transport Model returns status
	information and, if the process was successful the dtlsSessionID.		information and, if the process was successful the tlsSessionID for
	Other implementation-dependent data from (D)TLS are also returned.		the session. Other implementation-dependent data from (D)TLS may
	The dtlsSessionID is stored in an implementation- dependent manner		also be returned. The tlsSessionID is formatted and stored in an
	and tied to the tmSecurityData for future use of this session.		implementation-dependent manner. It is tied to the tmSecurityData
			for future use of this session and must remain constant and unique
			while the session is open.
	4.4.2. (D)TLS Services for an Incoming Message		4.4.2. (D)TLS Services for an Incoming Message
	When the TLS Transport Model invokes the (D)TLS record layer to		When the TLS Transport Model invokes the (D)TLS record layer to
	verify proper security for the incoming message, it must use the		verify proper security for the incoming message, it must use the
	following ASI:		following ASI:
	statusInformation = -- errorIndication or success		statusInformation = -- errorIndication or success
	tlsRead(		tlsRead(
	IN tlsSessionID -- Session identifier for (D)TLS		IN tlsSessionID -- Session identifier for (D)TLS
	IN wholeTlsMsg -- as received on the wire		IN wholeTlsMsg -- as received on the wire
	IN wholeTlsMsgLength -- length as received on the wire		IN wholeTlsMsgLength -- length as received on the wire
	OUT incomingMessage -- the whole SNMP message from (D)TLS		OUT incomingMessage -- the whole SNMP message from (D)TLS
	OUT incomingMessageLength -- the length of the SNMP message		OUT incomingMessageLength -- the length of the SNMP message
	)		)
	The abstract data elements passed as parameters in the abstract		The abstract data elements returned from or passed as parameters into
	service primitives are as follows:		the abstract service primitives are as follows:
	statusInformation: An indication of whether the process was		statusInformation: An indication of whether the process was
	successful or not. If not, then the status information will		successful or not. If not, then the status information will
	include the error indication provided by (D)TLS.		include the error indication provided by (D)TLS.
	tlsSessionID: An implementation-dependent session identifier to		tlsSessionID: An implementation-dependent session identifier to
	reference the specific (D)TLS session. How the (D)TLS session ID		reference the specific (D)TLS session. How the (D)TLS session ID
	is obtained for each message is implementation-dependent. As an		is obtained for each message is implementation-dependent. As an
	implementation hint, for dtls over udp the TLS Transport Model can		implementation hint for DTLS over UDP, the TLS Transport Model
	examine incoming messages to determine the source IP address,		might examine incoming messages to determine the source IP
	source port number, destination IP address, and destination port		address, source port number, destination IP address, and
	number and use these values to look up the local tlsSessionID in		destination port number and use these values to look up the local
	the list of active sessions.		tlsSessionID in the list of active sessions.
	wholeDtlsMsg: The whole message as received on the wire.		wholeDtlsMsg: The whole message as received on the wire.
	wholeDtlsMsgLength: The length of the message as it was received on		wholeDtlsMsgLength: The length of the wholeDtlsMsg field.
	the wire.
	incomingMessage: The whole SNMP message stripped of all (D)TLS		incomingMessage: The whole SNMP message after being processed by
	privacy and integrity data.		(D)TLS and removed of the (D)TLS transport layer data.
	incomingMessageLength: The length of the SNMP message stripped of		incomingMessageLength: The length of the incomingMessage field.
	all (D)TLS privacy and integrity data.
	4.4.3. (D)TLS Services for an Outgoing Message		4.4.3. (D)TLS Services for an Outgoing Message
	When the TLS Transport Model invokes the (D)TLS record layer to		When the TLS Transport Model invokes the (D)TLS record layer to
	encapsulate and transmit a SNMP message, it must use the following		encapsulate and transmit a SNMP message, it must use the following
	ASI.		ASI.
	statusInformation = -- errorIndication or success		statusInformation = -- errorIndication or success
	tlsWrite(		tlsWrite(
	IN tlsSessionID -- Session identifier for (D)TLS		IN tlsSessionID -- Session identifier for (D)TLS
	IN outgoingMessage -- the message to send		IN outgoingMessage -- the message to send
	IN outgoingMessageLength -- its length		IN outgoingMessageLength -- its length
	)		)
			The abstract data elements returned from or passed as parameters into
	The abstract data elements passed as parameters in the abstract		the abstract service primitives are as follows:
	service primitives are as follows:
	statusInformation: An indication of whether the process was		statusInformation: An indication of whether the process was
	successful or not. If not, then the status information will		successful or not. If not, then the status information will
	include the error indication provided by (D)TLS.		include the error indication provided by (D)TLS.
	tlsSessionID: An implementation-dependent session identifier to		tlsSessionID: An implementation-dependent session identifier to
	reference the specific (D)TLS session that the message should be		reference the specific (D)TLS session that the message should be
	sent using.		sent using.
	outgoingMessage: The outgoing message to send to (D)TLS for		outgoingMessage: The outgoing message to send to (D)TLS for
	encapsulation.		encapsulation.
	outgoingMessageLength: The length of the outgoing message.		outgoingMessageLength: The length of the outgoingMessage field.
	4.5. Cached Information and References		4.5. Cached Information and References
	When performing SNMP processing, there are two levels of state		When performing SNMP processing, there are two levels of state
	information that may need to be retained: the immediate state linking		information that may need to be retained: the immediate state linking
	a request-response pair, and potentially longer-term state relating		a request-response pair, and potentially longer-term state relating
	to transport and security. "Transport Subsystem for the Simple		to transport and security. "Transport Subsystem for the Simple
	Network Management Protocol" [I-D.ietf-isms-tmsm] defines general		Network Management Protocol" [RFC5590] defines general requirements
	requirements for caches and references.		for caches and references.
	4.5.1. TLS Transport Model Cached Information		4.5.1. TLS Transport Model Cached Information
	The TLSTM has no specific responsibilities regarding the cached		The TLSTM has no specific responsibilities regarding the cached
	information beyond those discussed in "Transport Subsystem for the		information beyond those discussed in "Transport Subsystem for the
	Simple Network Management Protocol" [I-D.ietf-isms-tmsm]		Simple Network Management Protocol" [RFC5590]
	5. Elements of Procedure		5. Elements of Procedure
	Abstract service interfaces have been defined by RFC 3411 to describe		Abstract service interfaces have been defined by [RFC3411] and
	the conceptual data flows between the various subsystems within an		further augmented by [RFC5590] to describe the conceptual data flows
	SNMP entity. The TLSTM uses some of these conceptual data flows when		between the various subsystems within an SNMP entity. The TLSTM uses
	communicating between subsystems. These RFC 3411-defined data flows		some of these conceptual data flows when communicating between
	are referred to here as public interfaces.		subsystems.
	To simplify the elements of procedure, the release of state		To simplify the elements of procedure, the release of state
	information is not always explicitly specified. As a general rule,		information is not always explicitly specified. As a general rule,
	if state information is available when a message gets discarded, the		if state information is available when a message gets discarded, the
	message-state information should also be released. If state		message-state information should also be released. If state
	information is available when a session is closed, the session state		information is available when a session is closed, the session state
	information should also be released. Sensitive information, like		information should also be released. Sensitive information, like
	cryptographic keys, should be overwritten appropriately first prior		cryptographic keys, should be overwritten appropriately first prior
	to being released.		to being released.
	An error indication may return an OID and value for an incremented		An error indication in statusInformation will typically include the
	counter if the information is available at the point where the error		Object Identifier (OID) and value for an incremented error counter.
	is detected.		This may be accompanied by the requested securityLevel and the
			tmStateReference. Per-message context information is not accessible
			to Transport Models, so for the returned counter OID and value,
			contextEngine would be set to the local value of snmpEngineID and
			contextName to the default context for error counters.
	5.1. Procedures for an Incoming Message		5.1. Procedures for an Incoming Message
	This section describes the procedures followed by the (D)TLS		This section describes the procedures followed by the (D)TLS
	Transport Model when it receives a (D)TLS protected packet. The		Transport Model when it receives a (D)TLS protected packet. The
	steps are broken into two different sections. Section 5.1.1		steps are broken into two different sections. Section 5.1.1
	describes the needed steps for de-multiplexing multiple DTLS		describes the needed steps for de-multiplexing multiple DTLS
	sessions, which is specifically needed for DTLS over UDP sessions.		sessions, which is specifically needed for DTLS over UDP sessions.
	Section 5.1.2 describes the steps specific to transport processing		Section 5.1.2 describes the steps specific to transport processing
	once the (D)TLS processing has been completed.		once the (D)TLS processing has been completed. It is assumed that
			TLS and DTLS/SCP protocol implementations already provide appropriate
			message demultiplexing and only the processing steps in Section 5.1.2
			are needed.
	5.1.1. DTLS Processing for Incoming Messages		5.1.1. DTLS Processing for Incoming Messages
	DTLS is significantly different in terms of session handling than		DTLS is significantly different in terms of session handling than
	TCP-based session streams like SSH or TLS. The DTLS protocol, which		when TLS or DTLS is run over session based streaming protocols like
	is datagram-based, does not have a session identifier when run over		TCP or SCTP. Specifically, the DTLS protocol, when run over UDP,
	UDP that allows implementations to determine through what session a		does not have a session identifier that allows implementations to
	packet arrived. DTLS over SCTP and TLS over TCP streams have built		determine through what session a packet arrived. DTLS over SCTP and
	in session demultiplexing and thus the steps in this section are not		TLS over TCP streams have built in session demultiplexing and thus
	necessary for those protocol combinations. It is always critical,		the steps in this section are not necessary for those protocol
	however, that implementations be able to derive a tlsSessionID from		combinations. It is always critical, however, that implementations
	any demultiplexing process.		be able to derive a tlsSessionID from any session demultiplexing
			process.
	A process for de-multiplexing multiple DTLS sessions arriving over		A process for demultiplexing multiple DTLS sessions arriving over UDP
	UDP must be incorporated into the procedures for processing an		must be incorporated into the procedures for processing an incoming
	incoming message. The steps in this section describe how this can be		message. The steps in this section describe one possible method to
	accomplished, although any implementation dependent method should be		accomplish this, although any implementation dependent method should
	suitable as long as the results are consistently deterministic. The		be suitable as long as the results are consistently deterministic.
	important output results from the steps in this process are the		The important output results from the steps in this process are the
	transportDomain, the transportAddress, the wholeMessage, the		transportDomain, the transportAddress, the wholeMessage, the
	wholeMessageLength, and a unique implementation-dependent session		wholeMessageLength, and a unique implementation-dependent session
	identifier (tlsSessionID).		identifier (tlsSessionID).
	This demultiplexing procedure assumes that upon session establishment		This demultiplexing procedure assumes that upon session establishment
	an entry in a local transport mapping table is created in the		an entry in a local transport mapping table is created in the
	Transport Model's Local Configuration Datastore (LCD). The transport		Transport Model's Local Configuration Datastore (LCD). The transport
	mapping table's entry should map a unique combination of the remote		mapping table's entry should map a unique combination of the remote
	address, remote port number, local address and local port number to a		address, remote port number, local address and local port number to
	implementation-dependent tlsSessionID.		an implementation-dependent tlsSessionID.
	1) The TLS Transport Model examines the raw UDP message, in an		1) The TLS Transport Model examines the raw UDP message, in an
	implementation-dependent manner. If the message is not a DTLS		implementation-dependent manner. If the message is not a DTLS
	message then it should be discarded. If the message is not a		message then it should be discarded. If the message is not a
	(D)TLS Application Data message then the message should be		(D)TLS Application Data message (such as a session initialization
	processed by the underlying DTLS framework as it is (for example)		or session modification message) then the message should be
	a session initialization or session modification message and no		processed by the underlying DTLS framework and no further steps
	further steps below should be taken by the DTLS Transport.		below should be taken by the DTLS Transport.
	2) The TLS Transport Model queries the LCD using the transport		2) The TLS Transport Model queries the LCD using the transport
	parameters (source and destination addresses and ports) to		parameters (source and destination addresses and ports) to
	determine if a session already exists and its tlsSessionID.		determine if a session already exists and its tlsSessionID.
	3) If a matching entry in the LCD does not exist then the message is		3) If a matching entry in the LCD does not exist then the message is
	discarded. Increment the tlstmSessionNoAvailableSessions counter		discarded. Increment the tlstmSessionNoAvailableSessions counter
	and stop processing the message.		and stop processing the message.
	Note that an entry would already exist if the client and server's		Note that an entry would already exist if the client and server's
	skipping to change at page 23, line 37 ¶		skipping to change at page 23, line 37 ¶
	entry may not exist, however, if a "rogue" message was routed to		entry may not exist, however, if a "rogue" message was routed to
	the SNMP entity by mistake. An entry might also be missing		the SNMP entity by mistake. An entry might also be missing
	because of a "broken" session (see operational considerations).		because of a "broken" session (see operational considerations).
	4) Retrieve the tlsSessionID from the LCD.		4) Retrieve the tlsSessionID from the LCD.
	5) The tlsWholeMsg, and the tlsSessionID are passed to DTLS for		5) The tlsWholeMsg, and the tlsSessionID are passed to DTLS for
	integrity checking and decryption using the tlsRead() ASI.		integrity checking and decryption using the tlsRead() ASI.
	6) If the message fails integrity checks or other (D)TLS security		6) If the message fails integrity checks or other (D)TLS security
	processing then the tlstmDTLSProtectionErrors counter is		processing then increment the tlstmDTLSProtectionErrors counter,
	incremented, the message is discarded and processing of the		discard and stop processing the message.
	message is stopped.
	7) The output of the tlsRead results in an incomingMessage and an		7) The output of the tlsRead ASI results in an incomingMessage and
	incomingMessageLength. These results and the tlsSessionID are		an incomingMessageLength. These results and the tlsSessionID are
	used below in the Section 5.1.2 to complete the processing of the		used below in the Section 5.1.2 to complete the processing of the
	incoming message.		incoming message.
	5.1.2. Transport Processing for Incoming Messages		5.1.2. Transport Processing for Incoming Messages
	The procedures in this section describe how the TLS Transport Model		The procedures in this section describe how the TLS Transport Model
	should process messages that have already been properly extracted		should process messages that have already been properly extracted
	from the (D)TLS stream.		from the (D)TLS stream.
	Create a tmStateReference cache for the subsequent reference and		Create a tmStateReference cache for the subsequent reference and
	skipping to change at page 24, line 18 ¶		skipping to change at page 24, line 16 ¶
	tmTransportDomain = snmpTLSDomain, snmpDTLSUDPDomain or		tmTransportDomain = snmpTLSDomain, snmpDTLSUDPDomain or
	snmpDTLSSCTPDomain as appropriate.		snmpDTLSSCTPDomain as appropriate.
	tmTransportAddress = The address the message originated from,		tmTransportAddress = The address the message originated from,
	determined in an implementation dependent way.		determined in an implementation dependent way.
	tmSecurityLevel = The derived tmSecurityLevel for the session, as		tmSecurityLevel = The derived tmSecurityLevel for the session, as
	discussed in Section 3.1.2 and Section 5.3.		discussed in Section 3.1.2 and Section 5.3.
	tmSecurityName = The derived tmSecurityName for the session as		tmSecurityName = The derived tmSecurityName for the session as
	discussed in and Section 5.3. This value MUST be constant during		discussed in Section 5.3. This value MUST be constant during the
	the lifetime of the (D)TLS session.		lifetime of the (D)TLS session.
	tmSessionID = The tlsSessionID, which MUST be a unique session		tmSessionID = The tlsSessionID, which MUST be a unique session
	identifier for this (D)TLS session. The contents and format of		identifier for this (D)TLS session. The contents and format of
	this identifier are implementation dependent as long as it is		this identifier are implementation dependent as long as it is
	unique to the session. A session identifier MUST NOT be reused		unique to the session. A session identifier MUST NOT be reused
	until all references to it are no longer in use. The tmSessionID		until all references to it are no longer in use. The tmSessionID
	is equal to the tlsSessionID discussed in Section 5.1.1.		is equal to the tlsSessionID discussed in Section 5.1.1.
	tmSessionID refers to the session identifier when stored in the		tmSessionID refers to the session identifier when stored in the
	tmStateReference and tlsSessionID refers to the session identifier		tmStateReference and tlsSessionID refers to the session identifier
	when stored in the LCD. They MUST always be equal when processing		when stored in the LCD. They MUST always be equal when processing
	skipping to change at page 24, line 47 ¶		skipping to change at page 24, line 45 ¶
	wholeMessage, and wholeMessageLength to the dispatcher using the		wholeMessage, and wholeMessageLength to the dispatcher using the
	receiveMessage ASI:		receiveMessage ASI:
	statusInformation =		statusInformation =
	receiveMessage(		receiveMessage(
	IN transportDomain -- snmpTLSDomain, snmpDTLSUDPDomain,		IN transportDomain -- snmpTLSDomain, snmpDTLSUDPDomain,
	-- or snmpDTLSSCTPDomain		-- or snmpDTLSSCTPDomain
	IN transportAddress -- address for the received message		IN transportAddress -- address for the received message
	IN wholeMessage -- the whole SNMP message from (D)TLS		IN wholeMessage -- the whole SNMP message from (D)TLS
	IN wholeMessageLength -- the length of the SNMP message		IN wholeMessageLength -- the length of the SNMP message
	IN tmStateReference -- (NEW) transport info		IN tmStateReference -- transport info
	)		)
	5.2. Procedures for an Outgoing Message		5.2. Procedures for an Outgoing Message
	The dispatcher sends a message to the TLS Transport Model using the		The dispatcher sends a message to the TLS Transport Model using the
	following ASI:		following ASI:
	statusInformation =		statusInformation =
	sendMessage(		sendMessage(
	IN destTransportDomain -- transport domain to be used		IN destTransportDomain -- transport domain to be used
	IN destTransportAddress -- transport address to be used		IN destTransportAddress -- transport address to be used
	IN outgoingMessage -- the message to send		IN outgoingMessage -- the message to send
	IN outgoingMessageLength -- its length		IN outgoingMessageLength -- its length
	IN tmStateReference -- (NEW) transport info		IN tmStateReference -- transport info
	)		)
	This section describes the procedure followed by the TLS Transport		This section describes the procedure followed by the TLS Transport
	Model whenever it is requested through this ASI to send a message.		Model whenever it is requested through this ASI to send a message.
	1) Extract tmSessionID, tmTransportAddress, tmSecurityName,		1) Extract the tmSessionID, tmTransportAddress, tmSecurityName,
	tmRequestedSecurityLevel. and tmSameSecurity from the		tmRequestedSecurityLevel, and tmSameSecurity values from the
	tmStateReference. Note: The tmSessionID value may be undefined		tmStateReference. Note: The tmSessionID value may be undefined
	if session exists yet.		if no session exists yet over which the message can be sent.
	2) If tmSameSecurity is true and either tmSessionID is undefined or		2) If tmSameSecurity is true and either tmSessionID is undefined or
	refers to a session that is no longer open then increment the		refers to a session that is no longer open then increment the
	tlstmSessionNoAvailableSessions counter, discard the message and		tlstmSessionNoAvailableSessions counter, discard the message and
	return the error indication in the statusInformation. Processing		return the error indication in the statusInformation. Processing
	of this message stops.		of this message stops.
	3) If tmSameSecurity is false and tmSessionID refers to a session		3) If tmSameSecurity is false and tmSessionID refers to a session
	that is no longer available then an implementation SHOULD open a		that is no longer available then an implementation SHOULD open a
	new session using the openSession() ASI as described below in		new session using the openSession() ASI (described in greater
	step 4b. An implementation MAY choose to return an error to the		detail in step 4b). An implementation MAY choose to return an
	calling module.		error to the calling module and stop processing of the message.
	4) If tmSessionID is undefined, then use tmTransportAddress,		4) If tmSessionID is undefined, then use tmTransportAddress,
	tmSecurityName and tmRequestedSecurityLevel to see if there is a		tmSecurityName and tmRequestedSecurityLevel to see if there is a
	corresponding entry in the LCD suitable to send the message over.		corresponding entry in the LCD suitable to send the message over.
	4a) If there is a corresponding LCD entry, then this session		4a) If there is a corresponding LCD entry, then this session
	will be used to send the message.		will be used to send the message.
	4b) If there is not a corresponding LCD entry, then open a		4b) If there is not a corresponding LCD entry, then open a
	session using the openSession() ASI (discussed further in		session using the openSession() ASI (discussed further in
	Section 4.4.1). Implementations MAY wish to offer message		Section 4.4.1). Implementations MAY wish to offer message
	buffering to prevent redundant openSession() calls for the		buffering to prevent redundant openSession() calls for the
	same cache entry. If an error is returned from		same cache entry. If an error is returned from
	OpenSession(), then discard the message, increment the		OpenSession(), then discard the message, increment the
	tlstmSessionOpenErrors, and return an error indication to		tlstmSessionOpenErrors, return an error indication to the
	the calling module.		calling module and stop processing of the message.
	5) Using either the session indicated by the tmSessionID if there		5) Using either the session indicated by the tmSessionID if there
	was one or the session resulting in the previous step, pass the		was one or the session resulting from a previous step (3 or 4),
	outgoingMessage to (D)TLS for encapsulation and transmission.		pass the outgoingMessage to (D)TLS for encapsulation and
			transmission.
	5.3. Establishing a Session		5.3. Establishing a Session
	The TLS Transport Model provides the following primitive to establish		The TLS Transport Model provides the following primitive to establish
	a new (D)TLS session (previously discussed in Section 4.4.1):		a new (D)TLS session (previously discussed in Section 4.4.1):
	statusInformation = -- errorIndication or success		statusInformation = -- errorIndication or success
	openSession(		openSession(
	IN destTransportDomain -- transport domain to be used		IN destTransportDomain -- transport domain to be used
	IN destTransportAddress -- transport address to be used		IN destTransportAddress -- transport address to be used
	IN securityName -- on behalf of this principal		IN securityName -- on behalf of this principal
	IN securityLevel -- Level of Security requested		IN securityLevel -- Level of Security requested
	OUT tlsSessionID -- Session identifier for (D)TLS		OUT tlsSessionID -- Session identifier for (D)TLS
	)		)
	The following describes the procedure to follow to establish a SNMP		The following describes the procedure to follow when establishing a
	over (D)TLS session between SNMP engines to exchange SNMP messages.		SNMP over (D)TLS session between SNMP engines for exchanging SNMP
	This process is followed by any SNMP engine establishing a session		messages. This process is followed by any SNMP engine establishing a
	for subsequent use.		session for subsequent use.
	This MAY be done automatically for SNMP messages which are not		This MAY be done automatically for SNMP messages which are not
	Response or Report messages.		Response or Report messages.
	(D)TLS provides no explicit manner for transmitting an identity the
	client wishes to connect to during or prior to key exchange to
	facilitate certificate selection at the server (e.g. at a
	Notification Receiver). I.E., there is no available mechanism for
	sending notifications to a specific principal at a given TCP, UDP or
	SCTP port. Therefore, implementations MAY support responding with
	multiple identities using separate TCP, UDP or SCTP port numbers to
	indicate the desired principal or some other implementation-dependent
	solution.
	1) The client selects the appropriate certificate and cipher_suites		1) The client selects the appropriate certificate and cipher_suites
	for the key agreement based on the tmSecurityName and the		for the key agreement based on the tmSecurityName and the
	tmRequestedSecurityLevel for the session. For sessions being		tmRequestedSecurityLevel for the session. For sessions being
	established as a result of a SNMP-TARGET-MIB based operation, the		established as a result of a SNMP-TARGET-MIB based operation, the
	certificate will potentially have been identified via the		certificate will potentially have been identified via the
	tlstmParamsTable mapping and the cipher_suites will have to be		tlstmParamsTable mapping and the cipher_suites will have to be
	taken from system-wide or implementation-specific configuration.		taken from system-wide or implementation-specific configuration.
	Otherwise, the certificate and appropriate cipher_suites will		Otherwise, the certificate and appropriate cipher_suites will
	need to be passed to the openSession() ASI as supplemental		need to be passed to the openSession() ASI as supplemental
	information or configured through an implementation-dependent		information or configured through an implementation-dependent
	mechanism. It is also implementation-dependent and possibly		mechanism. It is also implementation-dependent and possibly
	policy-dependent how tmRequestedSecurityLevel will be used to		policy-dependent how tmRequestedSecurityLevel will be used to
	influence the security capabilities provided by the (D)TLS		influence the security capabilities provided by the (D)TLS
	session. However this is done, the security capabilities		session. However this is done, the security capabilities
	provided by (D)TLS MUST be at least as high as the level of		provided by (D)TLS MUST be at least as high as the level of
	security indicated by the tmRequestedSecurityLevel parameter.		security indicated by the tmRequestedSecurityLevel parameter.
	The actual security level of the session should be reported in		The actual security level of the session is reported in the
	the tmStateReference cache as tmSecurityLevel. For (D)TLS to		tmStateReference cache as tmSecurityLevel. For (D)TLS to provide
	provide strong authentication, each principal acting as a Command		strong authentication, each principal acting as a Command
	Generator SHOULD have its own certificate.		Generator SHOULD have its own certificate.
	2) Using the destTransportDomain and destTransportAddress values,		2) Using the destTransportDomain and destTransportAddress values,
	the client will initiate the (D)TLS handshake protocol to		the client will initiate the (D)TLS handshake protocol to
	establish session keys for message integrity and encryption.		establish session keys for message integrity and encryption.
	If the attempt to establish a session is unsuccessful, then		If the attempt to establish a session is unsuccessful, then
	tlstmSessionOpenErrors is incremented, an error indication is		tlstmSessionOpenErrors is incremented, an error indication is
	returned, and session establishment processing stops.		returned, and processing stops.
	3) Once the secure session is established and both sides have been		3) Once a (D)TLS secured session is established and both sides have
	authenticated, certificate validation and identity expectations		performed any appropriate certificate authentication verification
	are performed.		(e.g. [RFC5280]) then each side will determine and/or check the
			identity of the remote entity using the procedures described
			below.
	a) The (D)TLS server side of the connection identifies the		a) The (D)TLS server side of the connection identifies the
	authenticated identity from the (D)TLS client's principal		authenticated identity from the (D)TLS client's principal
	certificate using appropriate certificate path validation		certificate using configuration information from the
	procedures (e.g. [RFC5280]) using configuration information		tlstmCertToSNTable mapping table. The resulting derived
	from the tlstmCertToSNTable mapping table. The resulting		securityName is recorded in the tmStateReference cache as
	derived securityName is recorded in the tmStateReference		tmSecurityName. The details of the lookup process are fully
	cache as tmSecurityName. The details of the lookup process		described in the DESCRIPTION clause of the tlstmCertToSNTable
	are fully described in the DESCRIPTION clause of the		MIB object. If any verification fails in any way (for
	tlstmCertToSNTable MIB object. If this verification fails in		example because of failures in cryptographic verification or
	any way (for example because of failures in cryptographic		because of the lack of an appropriate row in the
	verification or the lack of an appropriate row in the
	tlstmCertToSNTable) then the session establishment MUST fail,		tlstmCertToSNTable) then the session establishment MUST fail,
	the tlstmSessionInvalidClientCertificates object is		the tlstmSessionInvalidClientCertificates object is
	incremented and processing is stopped.		incremented and processing stops.
	b) The (D)TLS client side of the connection SHOULD verify that		b) The (D)TLS client side of the connection MUST verify that
	authenticated identity of the (D)TLS server's certificate is		authenticated identity of the (D)TLS server's certificate is
	the certificate expected. This can be done using the		the certificate expected. This can be done using the
	configuration found in the tlstmAddrTable if the client is		configuration fingerprints found in the tlstmAddrTable if the
	establishing the connection based on SNMP-TARGET-MIB		client is establishing the connection based on SNMP-TARGET-
	configuration. The client MUST always perform appropriate		MIB configuration or based on external certificate path
	certificate path validation procedures (e.g. [RFC5280]) to		validation processes (e.g. [RFC5280]).
	ensure the certificate is cryptographically valid.
	If strong authentication is desired then the (D)TLS server		Methods for verifying that the proper destination was reached
	address or naming mechanism MUST always be verified against		based on the presented certificate are described in
	the certificate's contents. Methods for doing this are		[I-D.saintandre-tls-server-id-check]. Matching the server's
	described in [I-D.saintandre-tls-server-id-check]. Matching		naming against SubjectAltName extension values SHOULD be the
	the server's naming against SubjectAltName extension values		preferred mechanism for comparison, but matching the
	is the preferred mechanism for comparison, but matching the
	CommonName MAY be used.		CommonName MAY be used.
	(D)TLS provides assurance that the authenticated identity has		(D)TLS provides assurance that the authenticated identity has
	been signed by a trusted configured certificate authority.		been signed by a trusted configured certificate authority.
	If verification of the server's certificate fails in any way		If verification of the server's certificate fails in any way
	(for example because of failures in cryptographic		(for example because of failures in cryptographic
	verification or the presented identity was not the expected		verification or the presented identity was not the expected
	identity) then the session establishment MUST fail, the		identity) then the session establishment MUST fail, the
	tlstmSessionInvalidServerCertificates object is incremented		tlstmSessionInvalidServerCertificates object is incremented
	and processing is stopped.		and processing stops.
	4) The (D)TLS-specific session identifier is passed to the TLS		4) The (D)TLS-specific session identifier is passed to the TLS
	Transport Model and associated with the tmStateReference cache		Transport Model and associated with the tmStateReference cache
	entry to indicate that the session has been established		entry to indicate that the session has been established
	successfully and to point to a specific (D)TLS session for future		successfully and to point to a specific (D)TLS session for future
	use.		use.
			(D)TLS provides no explicit manner for transmitting an identity the
			client wishes to connect to during or prior to key exchange to
			facilitate certificate selection at the server (e.g. at a
			Notification Receiver). I.E., there is no available mechanism for
			sending notifications to a specific principal at a given TCP, UDP or
			SCTP port. Therefore, an implementation that wishes to support
			multiple identities MAY use separate TCP, UDP or SCTP port numbers to
			indicate the desired principal or some other implementation-dependent
			solution.
	5.4. Closing a Session		5.4. Closing a Session
	The TLS Transport Model provides the following primitive to close a		The TLS Transport Model provides the following primitive to close a
	session:		session:
	statusInformation =		statusInformation =
	closeSession(		closeSession(
	IN tmStateReference -- transport info		IN tmStateReference -- transport info
	)		)
	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 closing the corresponding SNMP session.		engine closing the corresponding SNMP session.
	1) Look up the session in the cache and the LCD using the		1) Look up the session in the cache and the LCD using the
	tmStateReference.		tmStateReference and its contents.
	2) If there is no session open associated with the tmStateReference,		2) If there is no session open associated with the tmStateReference,
	then closeSession processing is completed.		then closeSession processing is completed.
	3) Delete the entry from the cache and any other implementation-		3) Delete the entry from the cache and any other implementation-
	dependent information in the LCD.		dependent information in the LCD.
	4) Have (D)TLS close the specified session. This SHOULD include		4) Have (D)TLS close the specified session. This SHOULD include
	sending a close_notify TLS Alert to inform the other side that		sending a close_notify TLS Alert to inform the other side that
	session cleanup may be performed.		session cleanup may be performed.
	6. MIB Module Overview		6. MIB Module Overview
	This MIB module provides management of the TLS Transport Model. It		This MIB module provides management of the TLS Transport Model. It
	defines needed textual conventions, statistical counters and		defines needed textual conventions, statistical counters,
	configuration infrastructure necessary for session establishment.		notifications and configuration infrastructure necessary for session
	Example usage of the configuration tables can be found in Appendix C.		establishment. Example usage of the configuration tables can be
			found in Appendix C.
	6.1. Structure of the MIB Module		6.1. Structure of the MIB Module
	Objects in this MIB module are arranged into subtrees. Each subtree		Objects in this MIB module are arranged into subtrees. Each subtree
	is organized as a set of related objects. The overall structure and		is organized as a set of related objects. The overall structure and
	assignment of objects to their subtrees, and the intended purpose of		assignment of objects to their subtrees, and the intended purpose of
	each subtree, is shown below.		each subtree, is shown below.
	6.2. Textual Conventions		6.2. Textual Conventions
	Generic and Common Textual Conventions used in this module can be		Generic and Common Textual Conventions used in this module can be
	found summarized at http://www.ops.ietf.org/mib-common-tcs.html		found summarized at http://www.ops.ietf.org/mib-common-tcs.html
	This module defines the following new Textual Conventions:		This module defines the following new Textual Conventions:
	o A new TransportDomain and TransportAddress format for describing		o New TransportDomain and TransportAddress formats for describing
	(D)TLS connection addressing requirements.		(D)TLS connection addressing requirements.
	o Public certificate fingerprint Hashing Types and Values. These		o Public certificate fingerprint allowing MIB module objects to
	textual conventions allow for MIB module objects to refer		generically refer to a stored X.509 certificate using a
	generically to a stored X.509 certificate using a simple hash		cryptographic hash as a reference pointer.
	value as a reference pointer.
	6.3. Statistical Counters		6.3. Statistical Counters
	The TLSTM-MIB defines some statical counters that can provide network		The TLSTM-MIB defines some statical counters that can provide network
	managers with feedback about (D)TLS session usage and potential		managers with feedback about (D)TLS session usage and potential
	errors that a MIB-instrumented device may be experiencing.		errors that a MIB-instrumented device may be experiencing.
	6.4. Configuration Tables		6.4. Configuration Tables
	The TLSTM-MIB defines configuration tables that a manager can use for		The TLSTM-MIB defines configuration tables that a manager can use for
	help in configuring a MIB-instrumented device for sending and		configuring a MIB-instrumented device for sending and receiving SNMP
	receiving SNMP messages over (D)TLS. In particular, there is a MIB		messages over (D)TLS. In particular, there is are MIB tables that
	table that extends the SNMP-TARGET-MIB for configuring certificates		extend the SNMP-TARGET-MIB for configuring (D)TLS certificate usage
	to be used and a MIB table for mapping incoming (D)TLS client		and a MIB table for mapping incoming (D)TLS client certificates to
	certificates to securityNames.		SNMPv3 securityNames.
			6.4.1. Notifications
			The TLSTM-MIB defines notifications to alert management stations when
			a (D)TLS connection fails because the server's presented certificate
			did not meet an expected value, according to the tlstmAddrTable.
	6.5. Relationship to Other MIB Modules		6.5. Relationship to Other MIB Modules
	Some management objects defined in other MIB modules are applicable		Some management objects defined in other MIB modules are applicable
	to an entity implementing the TLS Transport Model. In particular, it		to an entity implementing the TLS Transport Model. In particular, it
	is assumed that an entity implementing the TLSTM-MIB will implement		is likely that an entity implementing the TLSTM-MIB will implement
	the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411], the SNMP-		the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411], the SNMP-
	TARGET-MIB [RFC3413], the SNMP-NOTIFICATION-MIB [RFC3413] and the		TARGET-MIB [RFC3413], the SNMP-NOTIFICATION-MIB [RFC3413] and the
	SNMP-VIEW-BASED-ACM-MIB [RFC3415].		SNMP-VIEW-BASED-ACM-MIB [RFC3415].
	The TLSTM-MIB module contained in this document is for managing TLS		The TLSTM-MIB module contained in this document is for managing TLS
	Transport Model information.		Transport Model information.
	6.5.1. MIB Modules Required for IMPORTS		6.5.1. MIB Modules Required for IMPORTS
	The TLSTM-MIB module imports items from SNMPV2-SMI [RFC2578],		The TLSTM-MIB module imports items from SNMPv2-SMI [RFC2578],
	SNMPV2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB		SNMPv2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB
	[RFC3413] and SNMP-CONF [RFC2580].		[RFC3413] and SNMPv2-CONF [RFC2580].
	7. MIB Module Definition		7. MIB Module Definition
	TLSTM-MIB DEFINITIONS ::= BEGIN		TLSTM-MIB DEFINITIONS ::= BEGIN
	IMPORTS		IMPORTS
	MODULE-IDENTITY, OBJECT-TYPE,		MODULE-IDENTITY, OBJECT-TYPE,
	OBJECT-IDENTITY, snmpModules, snmpDomains,		OBJECT-IDENTITY, snmpModules, snmpDomains,
	Counter32, Unsigned32		Counter32, Unsigned32, NOTIFICATION-TYPE
	FROM SNMPv2-SMI		FROM SNMPv2-SMI
	TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType		TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType
	FROM SNMPv2-TC		FROM SNMPv2-TC
	MODULE-COMPLIANCE, OBJECT-GROUP		MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
	FROM SNMPv2-CONF		FROM SNMPv2-CONF
	SnmpAdminString		SnmpAdminString
	FROM SNMP-FRAMEWORK-MIB		FROM SNMP-FRAMEWORK-MIB
	snmpTargetParamsName, snmpTargetAddrName		snmpTargetParamsName, snmpTargetAddrName
	FROM SNMP-TARGET-MIB		FROM SNMP-TARGET-MIB
	;		;
	tlstmMIB MODULE-IDENTITY		tlstmMIB MODULE-IDENTITY
	LAST-UPDATED "200807070000Z"		LAST-UPDATED "200807070000Z"
	ORGANIZATION " "		ORGANIZATION "ISMS Working Group"
	CONTACT-INFO "WG-EMail:		CONTACT-INFO "WG-EMail: isms@lists.ietf.org
	Subscribe:		Subscribe: isms-request@lists.ietf.org
	Chairs:		Chairs:
			Juergen Schoenwaelder
			Jacobs University Bremen
			Campus Ring 1
			28725 Bremen
			Germany
			+49 421 200-3587
			j.schoenwaelder@jacobs-university.de
			Russ Mundy
			SPARTA, Inc.
			7110 Samuel Morse Drive
			Columbia, MD 21046
			USA
	Co-editors:		Co-editors:
	"		Wes Hardaker
			Sparta, Inc.
			P.O. Box 382
			Davis, CA 95617
			USA
			ietf@hardakers.net
			"
	DESCRIPTION "The TLS Transport Model MIB		DESCRIPTION "
			The TLS Transport Model MIB
			Copyright (c) 2009 IETF Trust and the persons
			identified as authors of the code. All rights reserved.
			Redistribution and use in source and binary forms, with or
			without modification, are permitted provided that the
			following conditions are met:
			- Redistributions of source code must retain the above copyright
			notice, this list of conditions and the following disclaimer.
			- Redistributions in binary form must reproduce the above
			copyright notice, this list of conditions and the following
			disclaimer in the documentation and/or other materials
			provided with the distribution.
			- Neither the name of Internet Society, IETF or IETF Trust,
			nor the names of specific contributors, may be used to endorse
			or promote products derived from this software without
			specific prior written permission.
			THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
			CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
			INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
			MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
			DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
			CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
			SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
			NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
			LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
			HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
			CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
			OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
			EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
			This version of this MIB module is part of RFC XXXX;
			see the RFC itself for full legal notices."
	Copyright (C) The IETF Trust (2008). This
	version of this MIB module is part of RFC XXXX;
	see the RFC itself for full legal notices."
	-- NOTE to RFC editor: replace XXXX with actual RFC number		-- NOTE to RFC editor: replace XXXX with actual RFC number
	-- for this document and remove this note		-- for this document and remove this note
	REVISION "200807070000Z"		REVISION "200807070000Z"
	DESCRIPTION "The initial version, published in RFC XXXX."		DESCRIPTION "The initial version, published in RFC XXXX."
	-- NOTE to RFC editor: replace XXXX with actual RFC number		-- NOTE to RFC editor: replace XXXX with actual RFC number
	-- for this document and remove this note		-- for this document and remove this note
	::= { snmpModules xxxx }		::= { snmpModules xxxx }
	-- RFC Ed.: replace xxxx with IANA-assigned number and		-- RFC Ed.: replace xxxx with IANA-assigned number and
	-- remove this note		-- remove this note
	-- ************************************************		-- ************************************************
			-- subtrees of the TLSTM-MIB
	-- ************************************************		-- ************************************************
	tlstmNotifications OBJECT IDENTIFIER ::= { tlstmMIB 0 }		tlstmNotifications OBJECT IDENTIFIER ::= { tlstmMIB 0 }
	tlstmObjects OBJECT IDENTIFIER ::= { tlstmMIB 1 }		tlstmObjects OBJECT IDENTIFIER ::= { tlstmMIB 1 }
	tlstmConformance OBJECT IDENTIFIER ::= { tlstmMIB 2 }		tlstmConformance OBJECT IDENTIFIER ::= { tlstmMIB 2 }
	-- ************************************************		-- ************************************************
			-- tlstmObjects - Objects
	-- ************************************************		-- ************************************************
	snmpTLSDomain OBJECT-IDENTITY		snmpTLSDomain OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The SNMP over TLS transport domain. The corresponding		"The SNMP over TLS transport domain. The corresponding
	transport address is of type SnmpTLSAddress.		transport address is of type SnmpTLSAddress.
	The securityName prefix to be associated with the		The securityName prefix to be associated with the
	snmpTLSDomain is 'tls'. This prefix may be used by		snmpTLSDomain is 'tls'. This prefix may be used by
	security models or other components to identify what secure		security models or other components to identify which secure
	transport infrastructure authenticated a securityName."		transport infrastructure authenticated a securityName."
	::= { snmpDomains xx }		::= { snmpDomains xx }
	-- RFC Ed.: replace xx with IANA-assigned number and		-- RFC Ed.: replace xx with IANA-assigned number and
	-- remove this note		-- remove this note
	-- RFC Ed.: replace 'tls' with the actual IANA assigned prefix string		-- RFC Ed.: replace 'tls' with the actual IANA assigned prefix string
	-- if 'tls' is not assigned to this document.		-- if 'tls' is not assigned to this document.
	skipping to change at page 32, line 18 ¶		skipping to change at page 33, line 32 ¶
	"The SNMP over DTLS/UDP transport domain. The corresponding		"The SNMP over DTLS/UDP transport domain. The corresponding
	transport address is of type SnmpDTLSUDPAddress.		transport address is of type SnmpDTLSUDPAddress.
	When an SNMP entity uses the snmpDTLSUDPDomain transport		When an SNMP entity uses the snmpDTLSUDPDomain transport
	model, it must be capable of accepting messages up to		model, it must be capable of accepting messages up to
	the maximum MTU size for an interface it supports, minus the		the maximum MTU size for an interface it supports, minus the
	needed IP, UDP, DTLS and other protocol overheads.		needed IP, UDP, DTLS and other protocol overheads.
	The securityName prefix to be associated with the		The securityName prefix to be associated with the
	snmpDTLSUDPDomain is 'dudp'. This prefix may be used by		snmpDTLSUDPDomain is 'dudp'. This prefix may be used by
	security models or other components to identify what secure		security models or other components to identify which secure
	transport infrastructure authenticated a securityName."		transport 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 'dudp' with the actual IANA assigned prefix string		-- RFC Ed.: replace 'dudp' with the actual IANA assigned prefix string
	-- if 'dtls' is not assigned to this document.		-- if 'dtls' is not assigned to this document.
	snmpDTLSSCTPDomain OBJECT-IDENTITY		snmpDTLSSCTPDomain OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The SNMP over DTLS/SCTP transport domain. The corresponding		"The SNMP over DTLS/SCTP transport domain. The corresponding
	transport address is of type SnmpDTLSSCTPAddress.		transport address is of type SnmpDTLSSCTPAddress.
	When an SNMP entity uses the snmpDTLSSCTPDomain transport
	model, it must be capable of accepting messages up to
	the maximum MTU size for an interface it supports, minus the
	needed IP, SCTP, DTLS and other protocol overheads.
	The securityName prefix to be associated with the		The securityName prefix to be associated with the
	snmpDTLSSCTPDomain is 'dsct'. This prefix may be used by		snmpDTLSSCTPDomain is 'dsct'. This prefix may be used by
	security models or other components to identify what secure		security models or other components to identify which secure
	transport infrastructure authenticated a securityName."		transport infrastructure authenticated a securityName."
	::= { snmpDomains zz }		::= { snmpDomains zz }
	-- RFC Ed.: replace zz with IANA-assigned number and		-- RFC Ed.: replace zz with IANA-assigned number and
	-- remove this note		-- remove this note
	-- RFC Ed.: replace 'dsct' with the actual IANA assigned prefix string		-- RFC Ed.: replace 'dsct' with the actual IANA assigned prefix string
	-- if 'dtls' is not assigned to this document.		-- if 'dtls' is not assigned to this document.
	SnmpTLSAddress ::= TEXTUAL-CONVENTION		SnmpTLSAddress ::= TEXTUAL-CONVENTION
	DISPLAY-HINT "1a"		DISPLAY-HINT "1a"
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Represents a TCP connection address for an IPv4 address, an		"Represents a TCP connection address for an IPv4 address, an
	IPv6 address or an ASCII encoded host name and port number.		IPv6 address or an US-US-ASCII encoded hostname and port number.
	The hostname must be encoded in ASCII, as specified in RFC3490
	(Internationalizing Domain Names in Applications) followed by
	a colon ':' (ASCII character 0x3A) and a decimal port number
	in ASCII. The name SHOULD be fully qualified whenever
	possible.
	An IPv4 address must be a dotted decimal format followed by a		An IPv4 address must be in dotted decimal format followed by a
	colon ':' (ASCII character 0x3A) and a decimal port number in		colon ':' (US-ASCII character 0x3A) and a decimal port number
	ASCII.		in US-ASCII.
	An IPv6 address must be a colon separated format, surrounded		An IPv6 address must be a colon separated format, surrounded
	by square brackets (ASCII characters 0x5B and 0x5D), followed		by square brackets ('[', US-ASCII character 0x5B, and ']',
	by a colon ':' (ASCII character 0x3A) and a decimal port		US-ASCII character 0x5D), followed by a colon ':' (US-ASCII
	number in ASCII.		character 0x3A) and a decimal port number in US-ASCII.
			A hostname is always in US-US-ASCII (as per RFC1033);
			internationalized hostnames are encoded in US-US-ASCII as
			specified in RFC 3490. The hostname is followed by a colon
			':' (US-US-ASCII character 0x3A) and a decimal port number in
			US-US-ASCII. The name SHOULD be fully qualified whenever
			possible.
	Values of this textual convention may not be directly usable		Values of this textual convention may not be directly usable
	as transport-layer addressing information, and may require		as transport-layer addressing information, and may require
	run-time resolution. As such, applications that write them		run-time resolution. As such, applications that write them
	must be prepared for handling errors if such values are not		must be prepared for handling errors if such values are not
	supported, or cannot be resolved (if resolution occurs at the		supported, or cannot be resolved (if resolution occurs at the
	time of the management operation).		time of the management operation).
	The DESCRIPTION clause of TransportAddress objects that may		The DESCRIPTION clause of TransportAddress objects that may
	have snmpTLSAddress values must fully describe how (and		have snmpTLSAddress values must fully describe how (and
	skipping to change at page 33, line 48 ¶		skipping to change at page 35, line 13 ¶
	versa.		versa.
	This textual convention SHOULD NOT be used directly in object		This textual convention SHOULD NOT be used directly in object
	definitions since it restricts addresses to a specific		definitions since it restricts addresses to a specific
	format. However, if it is used, it MAY be used either on its		format. However, if it is used, it MAY be used either on its
	own or in conjunction with TransportAddressType or		own or in conjunction with TransportAddressType or
	TransportDomain as a pair.		TransportDomain as a pair.
	When this textual convention is used as a syntax of an index		When this textual convention is used as a syntax of an index
	object, there may be issues with the limit of 128		object, there may be issues with the limit of 128
	sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED		sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED
	that all MIB documents using this textual convention make		that all MIB documents using this textual convention make
	explicit any limitations on index component lengths that		explicit any limitations on index component lengths that
	management software must observe. This may be done either by		management software must observe. This may be done either by
	including SIZE constraints on the index components or by		including SIZE constraints on the index components or by
	specifying applicable constraints in the conceptual row		specifying applicable constraints in the conceptual row
	DESCRIPTION clause or in the surrounding documentation."		DESCRIPTION clause or in the surrounding documentation."
			REFERENCE
			"RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE
			RFC 3490: Internationalizing Domain Names in Applications
			RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
			RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
			"
	SYNTAX OCTET STRING (SIZE (1..255))		SYNTAX OCTET STRING (SIZE (1..255))
	SnmpDTLSUDPAddress ::= TEXTUAL-CONVENTION		SnmpDTLSUDPAddress ::= TEXTUAL-CONVENTION
	DISPLAY-HINT "1a"		DISPLAY-HINT "1a"
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Represents a UDP connection address for an IPv4 address, an		"Represents a UDP connection address for an IPv4 address, an
	IPv6 address or an ASCII encoded host name and port number.		IPv6 address or an US-ASCII encoded hostname and port number.
	The hostname must be encoded in ASCII, as specified in RFC3490
	(Internationalizing Domain Names in Applications) followed by
	a colon ':' (ASCII character 0x3A) and a decimal port number
	in ASCII. The name SHOULD be fully qualified whenever
	possible.
	An IPv4 address must be a dotted decimal format followed by a		An IPv4 address must be a dotted decimal format followed by a
	colon ':' (ASCII character 0x3A) and a decimal port number in		colon ':' (US-ASCII character 0x3A) and a decimal port number in
	ASCII.		US-ASCII.
	An IPv6 address must be a colon separated format, surrounded		An IPv6 address must be a colon separated format, surrounded
	by square brackets (ASCII characters 0x5B and 0x5D), followed		by square brackets ('[', US-ASCII character 0x5B, and ']',
	by a colon ':' (ASCII character 0x3A) and a decimal port		US-ASCII character 0x5D), followed by a colon ':' (US-ASCII
	number in ASCII.		character 0x3A) and a decimal port number in US-ASCII.
			A hostname is always in US-US-ASCII (as per RFC1033);
			internationalized hostnames are encoded in US-US-ASCII as
			specified in RFC 3490. The hostname is followed by a colon
			':' (US-US-ASCII character 0x3A) and a decimal port number in
			US-US-ASCII. The name SHOULD be fully qualified whenever
			possible.
	Values of this textual convention may not be directly usable		Values of this textual convention may not be directly usable
	as transport-layer addressing information, and may require		as transport-layer addressing information, and may require
	run-time resolution. As such, applications that write them		run-time resolution. As such, applications that write them
	must be prepared for handling errors if such values are not		must be prepared for handling errors if such values are not
	supported, or cannot be resolved (if resolution occurs at the		supported, or cannot be resolved (if resolution occurs at the
	time of the management operation).		time of the management operation).
	The DESCRIPTION clause of TransportAddress objects that may		The DESCRIPTION clause of TransportAddress objects that may
	have snmpDTLSUDPAddress values must fully describe how (and		have snmpDTLSUDPAddress values must fully describe how (and
	skipping to change at page 34, line 51 ¶		skipping to change at page 36, line 22 ¶
	versa.		versa.
	This textual convention SHOULD NOT be used directly in object		This textual convention SHOULD NOT be used directly in object
	definitions since it restricts addresses to a specific		definitions since it restricts addresses to a specific
	format. However, if it is used, it MAY be used either on its		format. However, if it is used, it MAY be used either on its
	own or in conjunction with TransportAddressType or		own or in conjunction with TransportAddressType or
	TransportDomain as a pair.		TransportDomain as a pair.
	When this textual convention is used as a syntax of an index		When this textual convention is used as a syntax of an index
	object, there may be issues with the limit of 128		object, there may be issues with the limit of 128
	sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED		sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED
	that all MIB documents using this textual convention make		that all MIB documents using this textual convention make
	explicit any limitations on index component lengths that		explicit any limitations on index component lengths that
	management software must observe. This may be done either by		management software must observe. This may be done either by
	including SIZE constraints on the index components or by		including SIZE constraints on the index components or by
	specifying applicable constraints in the conceptual row		specifying applicable constraints in the conceptual row
	DESCRIPTION clause or in the surrounding documentation."		DESCRIPTION clause or in the surrounding documentation."
			REFERENCE
			"RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE
			RFC 3490: Internationalizing Domain Names in Applications
			RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
			RFC 4347: Datagram Transport Layer Security
			RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
			"
	SYNTAX OCTET STRING (SIZE (1..255))		SYNTAX OCTET STRING (SIZE (1..255))
	SnmpDTLSSCTPAddress ::= TEXTUAL-CONVENTION		SnmpDTLSSCTPAddress ::= TEXTUAL-CONVENTION
	DISPLAY-HINT "1a"		DISPLAY-HINT "1a"
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Represents a SCTP connection address for an IPv4 address, an		"Represents a SCTP connection address for an IPv4 address, an
	IPv6 address or an ASCII encoded host name and port number.		IPv6 address or an US-ASCII encoded hostname and port number.
	The hostname must be encoded in ASCII, as specified in RFC3490
	(Internationalizing Domain Names in Applications) followed by
	a colon ':' (ASCII character 0x3A) and a decimal port number
	in ASCII. The name SHOULD be fully qualified whenever
	possible.
	An IPv4 address must be a dotted decimal format followed by a		An IPv4 address must be a dotted decimal format followed by a
	colon ':' (ASCII character 0x3A) and a decimal port number in		colon ':' (US-ASCII character 0x3A) and a decimal port number in
	ASCII.		US-ASCII.
	An IPv6 address must be a colon separated format, surrounded		An IPv6 address must be a colon separated format, surrounded
	by square brackets (ASCII characters 0x5B and 0x5D), followed		by square brackets ('[', US-ASCII character 0x5B, and ']',
	by a colon ':' (ASCII character 0x3A) and a decimal port		US-ASCII character 0x5D), followed by a colon ':' (US-ASCII
	number in ASCII.		character 0x3A) and a decimal port number in US-ASCII.
			A hostname is always in US-US-ASCII (as per RFC1033);
			internationalized hostnames are encoded in US-US-ASCII as
			specified in RFC 3490. The hostname is followed by a colon
			':' (US-US-ASCII character 0x3A) and a decimal port number in
			US-US-ASCII. The name SHOULD be fully qualified whenever
			possible.
	Values of this textual convention may not be directly usable		Values of this textual convention may not be directly usable
	as transport-layer addressing information, and may require		as transport-layer addressing information, and may require
	run-time resolution. As such, applications that write them		run-time resolution. As such, applications that write them
	must be prepared for handling errors if such values are not		must be prepared for handling errors if such values are not
	supported, or cannot be resolved (if resolution occurs at the		supported, or cannot be resolved (if resolution occurs at the
	time of the management operation).		time of the management operation).
	The DESCRIPTION clause of TransportAddress objects that may		The DESCRIPTION clause of TransportAddress objects that may
	have snmpDTLSSCTPAddress values must fully describe how (and		have snmpDTLSSCTPAddress values must fully describe how (and
	skipping to change at page 36, line 7 ¶		skipping to change at page 37, line 33 ¶
	versa.		versa.
	This textual convention SHOULD NOT be used directly in object		This textual convention SHOULD NOT be used directly in object
	definitions since it restricts addresses to a specific		definitions since it restricts addresses to a specific
	format. However, if it is used, it MAY be used either on its		format. However, if it is used, it MAY be used either on its
	own or in conjunction with TransportAddressType or		own or in conjunction with TransportAddressType or
	TransportDomain as a pair.		TransportDomain as a pair.
	When this textual convention is used as a syntax of an index		When this textual convention is used as a syntax of an index
	object, there may be issues with the limit of 128		object, there may be issues with the limit of 128
	sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED		sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED
	that all MIB documents using this textual convention make		that all MIB documents using this textual convention make
	explicit any limitations on index component lengths that		explicit any limitations on index component lengths that
	management software must observe. This may be done either by		management software must observe. This may be done either by
	including SIZE constraints on the index components or by		including SIZE constraints on the index components or by
	specifying applicable constraints in the conceptual row		specifying applicable constraints in the conceptual row
	DESCRIPTION clause or in the surrounding documentation."		DESCRIPTION clause or in the surrounding documentation."
	SYNTAX OCTET STRING (SIZE (1..255))		SYNTAX OCTET STRING (SIZE (1..255))
	FingerprintType ::= TEXTUAL-CONVENTION		Fingerprint ::= TEXTUAL-CONVENTION
	STATUS current		DISPLAY-HINT "1x:254x"
	DESCRIPTION
	"Identifies an algorithm type that can be used to uniquely
	reference other data of a potentially arbitrary length. If a
	hashing algorithm is used, then the algorithm should be
	sufficiently robust enough and it's output long enough that
	hash-collisions should not occur. Other mechanisms of defining
	fingerprints include other forms of unique identification such
	as serial numbers or concatenated combinations of data such
	that the result is sufficiently unique.
	Objects making use of this TEXTUAL-CONVENTION SHOULD be
	accompanied by another object or objects of type
	FingerprintValue.
	This TEXTUAL-CONVENTION SHOULD NOT be used as a form of
	cryptographic verification. Two matching sets of
	FingerprintType/FingerprintValue should not be considered
	authenticated. These TEXTUAL-CONVENTIONs are only intended for
	use as a reference to a stored copy of a longer data source and
	the full data sources need to be compared to assure collisions
	have not resulted."
	SYNTAX OBJECT IDENTIFIER
	FingerprintValue ::= TEXTUAL-CONVENTION
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A Fingerprint value that can be used to uniquely reference		"A Fingerprint value that can be used to uniquely reference
	other data of potentially arbitrary length.		other data of potentially arbitrary length.
	Objects making use of this TEXTUAL-CONVENTION SHOULD always be		A Fingerprint value is composed of a 1-octet hashing algorithm
	accompanied by a FingerprintType object that dictates the		type. The octet value encoded is taken from the IANA TLS
	format of values stored in objects of type FingerprintValue.		HashAlgorithm Registry (RFC5246). The remaining octets are
			filled using the results of the hashing algorithm.
	This TEXTUAL-CONVENTION SHOULD NOT be used as a form of		This TEXTUAL-CONVENTION SHOULD NOT be used as a form of
	cryptographic verification. Two matching sets of		cryptographic verification and a data source with a matching
	FingerprintType/FingerprintValue should not be considered		fingerprint should not be considered authenticated because the
	authenticated. These TEXTUAL-CONVENTIONs are only intended for		value matches. This TEXTUAL-CONVENTION is only intended for
	use as a reference to a stored copy of a longer data source and		use as a reference to a stored copy of a longer data source.
	the full data sources need to be compared to assure collisions		The contents of full data source referenced by this fingerprint
	have not resulted."		needs to be compared against to assure collisions have not
	SYNTAX OCTET STRING		resulted."
			REFERENCE
			"RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE
	tlstmFingerprintTypes OBJECT IDENTIFIER ::= { tlstmObjects 1 }		RFC 3490: Internationalizing Domain Names in Applications
			RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
	tlstmMD5 OBJECT-IDENTITY		RFC 4347: Datagram Transport Layer Security
	STATUS current		RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
	DESCRIPTION		"
	"An identifier for the MD5 hashing algorithm to be used with		SYNTAX OCTET STRING (SIZE (1..255))
	FingerprintType objects. The resulting value to be placed into
	the corresponding FingerprintValue object should be a
	full-length MD5 hash (16 octets)."
	::= { tlstmFingerprintTypes 1 }
	tlstmSHA1 OBJECT-IDENTITY
	STATUS current
	DESCRIPTION
	"An identifier for the SHA1 hashing algorithm to be used with
	FingerprintType objects. The resulting value to be placed into
	the corresponding FingerprintValue object should be a
	full-length SHA1 hash (20 octets)."
	::= { tlstmFingerprintTypes 2 }
	tlstmSHA256 OBJECT-IDENTITY
	STATUS current
	DESCRIPTION
	"An identifier for the SHA256 hashing algorithm to be used with
	FingerprintType objects. The resulting value to be placed into
	the corresponding FingerprintValue object should be a
	full-length SHA256 hash (32 octets)."
	::= { tlstmFingerprintTypes 3 }
	-- The tlstmSession Group		-- The tlstmSession Group
	tlstmSession OBJECT IDENTIFIER ::= { tlstmObjects 2 }		tlstmSession OBJECT IDENTIFIER ::= { tlstmObjects 1 }
	tlstmSessionOpens OBJECT-TYPE		tlstmSessionOpens OBJECT-TYPE
	SYNTAX Counter32		SYNTAX Counter32
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The number of times an openSession() request has been		"The number of times an openSession() request has been
	executed as an (D)TLS client, whether it succeeded or failed."		executed as an (D)TLS client, whether it succeeded or failed."
	::= { tlstmSession 1 }		::= { tlstmSession 1 }
	skipping to change at page 39, line 23 ¶		skipping to change at page 40, line 4 ¶
	SYNTAX Counter32		SYNTAX Counter32
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The number of times (D)TLS processing resulted in a message		"The number of times (D)TLS processing resulted in a message
	being discarded because it failed its integrity test,		being discarded because it failed its integrity test,
	decryption processing or other (D)TLS processing."		decryption processing or other (D)TLS processing."
	::= { tlstmSession 7 }		::= { tlstmSession 7 }
	-- Configuration Objects		-- Configuration Objects
			tlstmConfig OBJECT IDENTIFIER ::= { tlstmObjects 2 }
	tlstmConfig OBJECT IDENTIFIER ::= { tlstmObjects 3 }
	-- Certificate mapping		-- Certificate mapping
	tlstmCertificateMapping OBJECT IDENTIFIER ::= { tlstmConfig 1 }		tlstmCertificateMapping OBJECT IDENTIFIER ::= { tlstmConfig 1 }
	tlstmCertToSNCount OBJECT-TYPE		tlstmCertToSNCount OBJECT-TYPE
	SYNTAX Unsigned32		SYNTAX Unsigned32
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A count of the number of entries in the		"A count of the number of entries in the tlstmCertToSNTable"
	tlstmCertToSNTable"
	::= { tlstmCertificateMapping 1 }		::= { tlstmCertificateMapping 1 }
	tlstmCertToSNTableLastChanged OBJECT-TYPE		tlstmCertToSNTableLastChanged OBJECT-TYPE
	SYNTAX TimeStamp		SYNTAX TimeStamp
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The value of sysUpTime.0 when the tlstmCertToSNTable		"The value of sysUpTime.0 when the tlstmCertToSNTable
	was last modified through any means, or 0 if it has not been		was last modified through any means, or 0 if it has not been
	modified since the command responder was started."		modified since the command responder was started."
	skipping to change at page 40, line 16 ¶		skipping to change at page 40, line 43 ¶
	"A table listing the X.509 certificates known to the entity		"A table listing the X.509 certificates known to the entity
	and the associated method for determining the SNMPv3 security		and the associated method for determining the SNMPv3 security
	name from a certificate.		name from a certificate.
	On an incoming (D)TLS/SNMP connection the client's presented		On an incoming (D)TLS/SNMP connection the client's presented
	certificate must be examined and validated based on an		certificate must be examined and validated based on an
	established trusted path from a CA certificate or self-signed		established trusted path from a CA certificate or self-signed
	public certificate (e.g. RFC5280). This table provides a		public certificate (e.g. RFC5280). This table provides a
	mapping from a validated certificate to a SNMPv3 securityName.		mapping from a validated certificate to a SNMPv3 securityName.
	This table does not provide any mechanisms for uploading		This table does not provide any mechanisms for uploading
	trusted certificates and the transfer of any needed trusted		trusted certificates; the transfer of any needed trusted
	certificates for path validation is expected to occur through		certificates for path validation is expected to occur through
	an out-of-band transfer.		an out-of-band transfer.
	Once the authenticity of a certificate has been verified, this		Once the authenticity of a certificate has been verified, this
	table is consulted to determine the appropriate securityName		table is consulted to determine the appropriate securityName
	to identify with the remote connection. This is done by		to identify with the remote connection. This is done by
	considering each active row from this table in prioritized		considering each active row from this table in prioritized
	order according to its tlstmCertToSNID value. Each row's		order according to its tlstmCertToSNID value. Each row's
	tlstmCertToSNHashType and tlstmCertToSNHashValue values		tlstmCertToSNFingerprint value determines whether the row is a
	determine whether the row is a match for the incoming		match for the incoming connection:
	connection:
	1) If the row's tlstmCertToSNHashType and		1) If the row's tlstmCertToSNFingerprint value identifies
	tlstmCertToSNHashValue values identify the presented		the presented certificate and the contents of the
	certificate and the contents of the presented		presented certificate match a locally cached copy of
	certificate match a locally cached copy of the		the certificate then consider the row as a successful
	certificate then consider the row as a successful
	match.		match.
	2) If the row's tlstmCertToSNHashType and		2) If the row's tlstmCertToSNFingerprint value identifies
	tlstmCertToSNHashValue values identify a locally held		a locally held copy of a trusted CA certificate and
	copy of a trusted CA certificate and that CA		that CA certificated was used to validate the path to
	certificated was used to validate the presented		the presented certificate then consider the row as a
	certificate then consider the row as a successful		successful match.
	match.
	Once a matching row has been found, the tlstmCertToSNMapType		Once a matching row has been found, the tlstmCertToSNMapType
	value can be used to determine how the securityName to		value can be used to determine how the securityName to
	associate with the session should be determined. See the		associate with the session should be determined. See the
	tlstmCertToSNMapType column's DESCRIPTION for details on		tlstmCertToSNMapType column's DESCRIPTION for details on
	determining the securityName value. If it is impossible to		determining the securityName value. If it is impossible to
	determine the resulting securityName from the row's data		determine a securityName from the row's data combined with the
	combined with the data presented in the certificate then		data presented in the certificate then additional rows MUST be
	additional rows MUST be searched looking for another potential		searched looking for another potential match. If a resulting
	match. If a resulting securityName mapped from a given row is		securityName mapped from a given row is not compatible with
	not compatible with the needed requirements of a legal		the needed requirements of a securityName (e.g., VACM imposes
	securityName (i.e., VACM imposes a 32-octet-maximum length)		a 32-octet-maximum length and the certificate derived
	then it must be considered an invalid match and additional		securityName could be longer) then it must be considered an
	rows MUST be searched looking for another potential match.		invalid match and additional rows MUST be searched looking for
			another potential match.
	Missing values of tlstmCertToSNID are acceptable and		Missing values of tlstmCertToSNID are acceptable and
	implementations should continue to the next highest numbered		implementations should continue to the next highest numbered
	row. E.G., the table may legally contain only two rows with		row. E.G., the table may legally contain only two rows with
	tlstmCertToSNID values of 10 and 20.		tlstmCertToSNID values of 10 and 20.
	Users are encouraged to make use of certificates with		Users are encouraged to make use of certificates with
	subjectAltName fields that can be used as securityNames so		subjectAltName fields that can be used as securityNames so
	that a single root CA certificate can allow all child		that a single root CA certificate can allow all child
	certificate's subjectAltName to map directly to a securityName		certificate's subjectAltName to map directly to a securityName
	skipping to change at page 41, line 35 ¶		skipping to change at page 42, line 12 ¶
	a securityName is also possible but requires one entry in the		a securityName is also possible but requires one entry in the
	table per securityName and requires more management operations		table per securityName and requires more management operations
	to completely configure a device."		to completely configure a device."
	::= { tlstmCertificateMapping 3 }		::= { tlstmCertificateMapping 3 }
	tlstmCertToSNEntry OBJECT-TYPE		tlstmCertToSNEntry OBJECT-TYPE
	SYNTAX TlstmCertToSNEntry		SYNTAX TlstmCertToSNEntry
	MAX-ACCESS not-accessible		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A row in the tlstmCertToSNTable that specifies a		"A row in the tlstmCertToSNTable that specifies a mapping for
	mapping for an incoming (D)TLS certificate to a securityName		an incoming (D)TLS certificate to a securityName to use for a
	to use for a connection."		connection."
	INDEX { tlstmCertToSNID }		INDEX { tlstmCertToSNID }
	::= { tlstmCertToSNTable 1 }		::= { tlstmCertToSNTable 1 }
	TlstmCertToSNEntry ::= SEQUENCE {		TlstmCertToSNEntry ::= SEQUENCE {
	tlstmCertToSNID Unsigned32,		tlstmCertToSNID Unsigned32,
	tlstmCertToSNHashType FingerprintType,		tlstmCertToSNFingerprint Fingerprint,
	tlstmCertToSNHashValue FingerprintValue,
	tlstmCertToSNMapType INTEGER,		tlstmCertToSNMapType INTEGER,
	tlstmCertToSNSecurityName SnmpAdminString,		tlstmCertToSNSecurityName SnmpAdminString,
	tlstmCertToSNSANType INTEGER,		tlstmCertToSNSANType INTEGER,
	tlstmCertToSNStorageType StorageType,		tlstmCertToSNStorageType StorageType,
	tlstmCertToSNRowStatus RowStatus		tlstmCertToSNRowStatus RowStatus
	}		}
	tlstmCertToSNID OBJECT-TYPE		tlstmCertToSNID OBJECT-TYPE
	SYNTAX Unsigned32		SYNTAX Unsigned32
	MAX-ACCESS not-accessible		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A unique, prioritized index for a given certificate entry."		"A unique, prioritized index for the given entry."
	::= { tlstmCertToSNEntry 1 }		::= { tlstmCertToSNEntry 1 }
	tlstmCertToSNHashType OBJECT-TYPE		tlstmCertToSNFingerprint OBJECT-TYPE
	SYNTAX FingerprintType		SYNTAX Fingerprint
	MAX-ACCESS read-create
	STATUS current
	DESCRIPTION
	"The hash algorithm to use when applying a hash to a X.509
	certificate for purposes of referring to it from the
	tlstmCertToSNHashValue column."
	DEFVAL { tlstmSHA256 }
	::= { tlstmCertToSNEntry 2 }
	tlstmCertToSNHashValue OBJECT-TYPE
	SYNTAX FingerprintValue
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A cryptographic hash of a X.509 certificate. The results of		"A cryptographic hash of a X.509 certificate. The results of
	a successful matching fingerprint is dictated by the		a successful matching fingerprint to either the trusted CA in
	tlstmCertToSNMapType column. A match of the fingerprint MUST		the certificate validation path or to the certificate itself
	only be considered successful if both the fingerprint type		is dictated by the tlstmCertToSNMapType column."
	(tlstmCertToSNMapType) and fingerprint value		::= { tlstmCertToSNEntry 2 }
	(tlstmCertToSNHashValue) columns have been found equal to the
	type and value of the certificate being checked."
	::= { tlstmCertToSNEntry 3 }
	tlstmCertToSNMapType OBJECT-TYPE		tlstmCertToSNMapType OBJECT-TYPE
	SYNTAX INTEGER { specified(1), bySubjectAltName(2), byCN(3) }		SYNTAX INTEGER { specified(1), bySubjectAltName(2), byCN(3) }
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The mapping type used to obtain the securityName from the		"The mapping type used to obtain the securityName from the
	certificate. The possible values of use and their usage		certificate. The possible values of use and their usage
	methods are defined as follows:		methods are defined as follows:
	specified(1): The securityName that should be used to		specified(1): The securityName that should be used to
	associate with the session is directly		associate with the session is directly specified
	specified in the tlstmCertToSNecurityName column		in the tlstmCertToSNecurityName column from this
	from this table.		table. Note: The tlstmCertToSNSecurityName
			column's value is ignored for all other
			tlstmCertToSNMapType values.
	bySubjectAltName(2):		bySubjectAltName(2):
	The securityName that should be used to		The securityName that should be used to
	associate with the session should be taken from		associate with the session should be taken from
	the subjectAltName(s) portion of the client's		the subjectAltName(s) portion of the client's
	X.509 certificate. The subjectAltName used MUST		X.509 certificate. The subjectAltName used MUST
	be the first encountered subjectAltName type		be the first encountered subjectAltName type
	indicated by the tlstmCertToSNSANType column.		indicated by the tlstmCertToSNSANType column.
	If no subjectAltName of the given type is found
	within the certificate then additional rows in		If the resulting mapped value from the
	the tlstmCertToSNTable must be searched.		subjectAltName component is not compatible with
			the needed requirements of a securityName (e.g.,
			VACM imposes a 32-octet-maximum length and the
			certificate derived securityName could be
			longer) then the next appropriate subjectAltName
			of the correct type should be used if available.
			If no appropriate subjectAltName of the given
			type is found within the certificate then
			additional rows in the tlstmCertToSNTable must
			be searched for additional
			tlstmCertToSNFingerprint matches.
	byCN(3): The securityName that should be used to		byCN(3): The securityName that should be used to
	associate with the session should be taken from		associate with the session should be taken from
	the CommonName portion of the Subject field from		the CommonName portion of the Subject field from
	the client's presented X.509 certificate.		the client's presented X.509 certificate.
	If the resulting mapped value from the subjectAltName		If the value of the CommonName component is not
	component is not compatible with the needed requirements of a		compatible with the needed requirements of a
	legal securityName (i.e., VACM imposes a 32-octet-maximum		securityName (e.g., VACM imposes a
	length) then the next appropriate subjectAltName of the		32-octet-maximum length and the certificate
	correct type should be used if available.		derived securityName could be longer) then
			additional rows in the tlstmCertToSNTable must
	If this object is of type bySubjectAltName(2) and no		be searched for additional
	subjectAltName value can be found that meets the requirements		tlstmCertToSNFingerprint matches."
	of this object then any additional rows in the
	tlstmCertToSNTable must be searched.
	If this object is of type byCN(3) and the CommonName value
	does not meet the requirements of this object then any
	additional rows in the tlstmCertToSNTable must be searched."
	DEFVAL { specified }		DEFVAL { specified }
	::= { tlstmCertToSNEntry 4 }		::= { tlstmCertToSNEntry 3 }
	tlstmCertToSNSecurityName OBJECT-TYPE		tlstmCertToSNSecurityName OBJECT-TYPE
	SYNTAX SnmpAdminString (SIZE(0..32))		SYNTAX SnmpAdminString (SIZE(0..32))
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The securityName that the session should use if the		"The securityName that the session should use if the
	tlstmCertToSNMapType is set to specified(1), otherwise the		tlstmCertToSNMapType is set to specified(1), otherwise the
	value in this column should be ignored. If		value in this column should be ignored. If
	tlstmCertToSNMapType is set to specifed(1) and this column		tlstmCertToSNMapType is set to specifed(1) and this column
	contains a zero-length string (which is not a legal		contains a zero-length string (which is not a legal
	securityName value) this row is effectively disabled and the		securityName value) this row is effectively disabled and the
	match will not be considered successful and other rows in the		match will not be considered successful and other rows in the
	table will need to be searched."		table will need to be searched for a proper match."
	DEFVAL { "" }		DEFVAL { "" }
	::= { tlstmCertToSNEntry 5 }		::= { tlstmCertToSNEntry 4 }
	tlstmCertToSNSANType OBJECT-TYPE		tlstmCertToSNSANType OBJECT-TYPE
	SYNTAX INTEGER { any(1), rfc822Name(2), dNSName(3),		SYNTAX INTEGER { any(1), rfc822Name(2), dNSName(3),
	ipAddress(4), otherName(5) }		ipAddress(4), otherName(5) }
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Specifies the subjectAltName type that may be used to extract		"Specifies the subjectAltName type that may be used to extract
	the securityName from.		the securityName from.
	skipping to change at page 44, line 34 ¶		skipping to change at page 44, line 50 ¶
	Values for type ipAddress(4) are converted to a valid		Values for type ipAddress(4) are converted to a valid
	securityName by:		securityName by:
	1) for IPv4 the value is converted into a decimal dotted		1) for IPv4 the value is converted into a decimal dotted
	quad address (e.g. '192.0.2.1')		quad address (e.g. '192.0.2.1')
	2) for IPv6 addresses the value is converted into a		2) for IPv6 addresses the value is converted into a
	32-character hexadecimal string without any colon		32-character hexadecimal string without any colon
	separators.		separators.
			Note that the resulting length is the maximum length
			supported by the View-Based Access Control Model
			(VACM). Note that using both the Transport Security
			Model's support for transport prefixes (see the
			SNMP-TSM-MIB::snmpTsmConfigurationUsePrefix object for
			details) will result in securityName lengths that
			exceed what VACM can handle.
	Values for type otherName(5) are converted to a valid		Values for type otherName(5) are converted to a valid
	securityName by using only the decoded value portion of the		securityName by using only the decoded value portion of the
	OthenName sequence. i.e. the OBJECT IDENTIFIER portion of the		OtherName sequence. I.E. the OBJECT IDENTIFIER portion of the
	OtherName sequence is not included as part of the resulting		OtherName sequence is not included as part of the resulting
	securityName."		securityName."
	DEFVAL { any }		DEFVAL { any }
	::= { tlstmCertToSNEntry 6 }		::= { tlstmCertToSNEntry 5 }
	tlstmCertToSNStorageType OBJECT-TYPE		tlstmCertToSNStorageType OBJECT-TYPE
	SYNTAX StorageType		SYNTAX StorageType
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The storage type for this conceptual row. Conceptual rows		"The storage type for this conceptual row. Conceptual rows
	having the value 'permanent' need not allow write-access to		having the value 'permanent' need not allow write-access to
	any columnar objects in the row."		any columnar objects in the row."
	DEFVAL { nonVolatile }		DEFVAL { nonVolatile }
	::= { tlstmCertToSNEntry 7 }		::= { tlstmCertToSNEntry 6 }
	tlstmCertToSNRowStatus OBJECT-TYPE		tlstmCertToSNRowStatus OBJECT-TYPE
	SYNTAX RowStatus		SYNTAX RowStatus
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The status of this conceptual row. This object may be used		"The status of this conceptual row. This object may be used
	to create or remove rows from this table.		to create or remove rows from this table.
	To create a row in this table, a manager must set this object		To create a row in this table, a manager must set this object
	to either createAndGo(4) or createAndWait(5).		to either createAndGo(4) or createAndWait(5).
	Until instances of all corresponding columns are appropriately		Until instances of all corresponding columns are appropriately
	configured, the value of the corresponding instance of the		configured, the value of the corresponding instance of the
	tlstmParamsRowStatus column is 'notReady'.		tlstmParamsRowStatus column is 'notReady'.
	In particular, a newly created row cannot be made active until		In particular, a newly created row cannot be made active until
	the corresponding tlstmCertToSNHashType,		the corresponding tlstmCertToSNFingerprint,
	tlstmCertToSNHashValue, tlstmCertToSNMapType,		tlstmCertToSNMapType, tlstmCertToSNSecurityName, and
	tlstmCertToSNSecurityName, and tlstmCertToSNSANType columns		tlstmCertToSNSANType columns have been set.
	have been set.
	The following objects may not be modified while the		The following objects may not be modified while the
	value of this object is active(1):		value of this object is active(1):
	- tlstmCertToSNHashType
	- tlstmCertToSNHashValue		- tlstmCertToSNFingerprint
	- tlstmCertToSNMapType		- tlstmCertToSNMapType
	- tlstmCertToSNSecurityName		- tlstmCertToSNSecurityName
	- tlstmCertToSNSANType		- tlstmCertToSNSANType
	An attempt to set these objects while the value of		An attempt to set these objects while the value of
	tlstmParamsRowStatus is active(1) will result in		tlstmParamsRowStatus is active(1) will result in
	an inconsistentValue error."		an inconsistentValue error."
	::= { tlstmCertToSNEntry 8 }		::= { tlstmCertToSNEntry 7 }
	-- Maps securityNames to certificates for use by the SNMP-TARGET-MIB		-- Maps securityNames to certificates for use by the SNMP-TARGET-MIB
	tlstmParamsCount OBJECT-TYPE		tlstmParamsCount OBJECT-TYPE
	SYNTAX Unsigned32		SYNTAX Unsigned32
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A count of the number of entries in the tlstmParamsTable"		"A count of the number of entries in the tlstmParamsTable"
	::= { tlstmCertificateMapping 4 }		::= { tlstmCertificateMapping 4 }
	skipping to change at page 46, line 25 ¶		skipping to change at page 46, line 50 ¶
	snmpTargetParamsTable with an additional (D)TLS client-side		snmpTargetParamsTable with an additional (D)TLS client-side
	certificate fingerprint identifier to use when establishing		certificate fingerprint identifier to use when establishing
	new (D)TLS connections."		new (D)TLS connections."
	::= { tlstmCertificateMapping 6 }		::= { tlstmCertificateMapping 6 }
	tlstmParamsEntry OBJECT-TYPE		tlstmParamsEntry OBJECT-TYPE
	SYNTAX TlstmParamsEntry		SYNTAX TlstmParamsEntry
	MAX-ACCESS not-accessible		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A conceptual row containing a locally held certificate's hash		"A conceptual row containing a fingerprint hash of a locally
	type and hash value for a given snmpTargetParamsEntry. The		held certificate for a given snmpTargetParamsEntry. The
	values in this row should be ignored if the connection that		values in this row should be ignored if the connection that
	needs to be established, as indicated by the SNMP-TARGET-MIB		needs to be established, as indicated by the SNMP-TARGET-MIB
	infrastructure, is not a certificate and (D)TLS based		infrastructure, is not a certificate and (D)TLS based
	connection. The connection SHOULD NOT be established if the		connection. The connection SHOULD NOT be established if the
	certificate fingerprint stored in this entry does not point to		certificate fingerprint stored in this entry does not point to
	a valid locally held certificate or if it points to an usable		a valid locally held certificate or if it points to an usable
	certificate (such as might happen when the certificate's		certificate (such as might happen when the certificate's
	expiration date has been reached)."		expiration date has been reached)."
	INDEX { IMPLIED snmpTargetParamsName }		INDEX { IMPLIED snmpTargetParamsName }
	::= { tlstmParamsTable 1 }		::= { tlstmParamsTable 1 }
	TlstmParamsEntry ::= SEQUENCE {		TlstmParamsEntry ::= SEQUENCE {
	tlstmParamsClientHashType FingerprintType,		tlstmParamsClientFingerprint Fingerprint,
	tlstmParamsClientHashValue FingerprintValue,		tlstmParamsStorageType StorageType,
	tlstmParamsStorageType StorageType,		tlstmParamsRowStatus RowStatus
	tlstmParamsRowStatus RowStatus
	}		}
	tlstmParamsClientHashType OBJECT-TYPE		tlstmParamsClientFingerprint OBJECT-TYPE
	SYNTAX FingerprintType		SYNTAX Fingerprint
	MAX-ACCESS read-create
	STATUS current
	DESCRIPTION
	"The hash algorithm type for the hash stored in the
	tlstmParamsClientHash column to identify a locally-held X.509
	certificate that should be used when initiating a (D)TLS
	connection as a (D)TLS client."
	DEFVAL { tlstmSHA256 }
	::= { tlstmParamsEntry 1 }
	tlstmParamsClientHashValue OBJECT-TYPE
	SYNTAX FingerprintValue
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A cryptographic hash of a X.509 certificate. This object		"A cryptographic hash of a X.509 certificate. This object
	should store the hash of a locally held X.509 certificate that		should store the hash of a locally held X.509 certificate that
	should be used when initiating a (D)TLS connection as a (D)TLS		should be used when initiating a (D)TLS connection as a (D)TLS
	client."		client."
	::= { tlstmParamsEntry 2 }		::= { tlstmParamsEntry 1 }
	tlstmParamsStorageType OBJECT-TYPE		tlstmParamsStorageType OBJECT-TYPE
	SYNTAX StorageType		SYNTAX StorageType
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The storage type for this conceptual row. Conceptual rows		"The storage type for this conceptual row. Conceptual rows
	having the value 'permanent' need not allow write-access to		having the value 'permanent' need not allow write-access to
	any columnar objects in the row."		any columnar objects in the row."
	DEFVAL { nonVolatile }		DEFVAL { nonVolatile }
	::= { tlstmParamsEntry 3 }		::= { tlstmParamsEntry 2 }
	tlstmParamsRowStatus OBJECT-TYPE		tlstmParamsRowStatus OBJECT-TYPE
	SYNTAX RowStatus		SYNTAX RowStatus
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The status of this conceptual row. This object may be used		"The status of this conceptual row. This object may be used
	to create or remove rows from this table.		to create or remove rows from this table.
	To create a row in this table, a manager must set this object		To create a row in this table, a manager must set this object
	to either createAndGo(4) or createAndWait(5).		to either createAndGo(4) or createAndWait(5).
	Until instances of all corresponding columns are appropriately		Until instances of all corresponding columns are appropriately
	configured, the value of the corresponding instance of the		configured, the value of the corresponding instance of the
	tlstmParamsRowStatus column is 'notReady'.		tlstmParamsRowStatus column is 'notReady'.
	In particular, a newly created row cannot be made active until		In particular, a newly created row cannot be made active until
	the corresponding tlstmParamsClientHashType and		the corresponding tlstmParamsClientFingerprint column has
	tlstmParamsClientHashValue columns have been set.		been set.
			The tlstmParamsClientFingerprint object may not be modified
			while the value of this object is active(1).
	The following objects may not be modified while the
	value of this object is active(1):
	- tlstmParamsClientHashType
	- tlstmParamsClientHashValue
	An attempt to set these objects while the value of		An attempt to set these objects while the value of
	tlstmParamsRowStatus is active(1) will result in		tlstmParamsRowStatus is active(1) will result in
	an inconsistentValue error.		an inconsistentValue error.
	If this row is deleted it has no effect on the corresponding		If this row is deleted it has no effect on the corresponding
	row in the targetParamsTable.		row in the targetParamsTable.
	If the corresponding row in the targetParamsTable is deleted		If the corresponding row in the targetParamsTable is deleted
	then this row must be automatically removed."		then this row must be automatically removed."
	::= { tlstmParamsEntry 4 }		::= { tlstmParamsEntry 3 }
	-- Lists expected certificate fingerprints to be presented by a DTLS		-- Lists expected certificate fingerprints to be presented by a DTLS
	-- server		-- server
	tlstmAddrCount OBJECT-TYPE		tlstmAddrCount OBJECT-TYPE
	SYNTAX Unsigned32		SYNTAX Unsigned32
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A count of the number of entries in the tlstmAddrTable"		"A count of the number of entries in the tlstmAddrTable"
	skipping to change at page 49, line 18 ¶		skipping to change at page 49, line 26 ¶
	another certificate validation path algorithm (e.g. RFC5280)		another certificate validation path algorithm (e.g. RFC5280)
	can be followed to a configured trust anchor. "		can be followed to a configured trust anchor. "
	::= { tlstmCertificateMapping 9 }		::= { tlstmCertificateMapping 9 }
	tlstmAddrEntry OBJECT-TYPE		tlstmAddrEntry OBJECT-TYPE
	SYNTAX TlstmAddrEntry		SYNTAX TlstmAddrEntry
	MAX-ACCESS not-accessible		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A conceptual row containing a copy of a locally held		"A conceptual row containing a copy of a locally held
	certificate's hash type and hash value for a given		certificate's fingerprint for a given snmpTargetAddrEntry.
	snmpTargetAddrEntry. The values in this row should be ignored		The values in this row should be ignored if the connection
	if the connection that needs to be established, as indicated		that needs to be established, as indicated by the
	by the SNMP-TARGET-MIB infrastructure, is not a (D)TLS based		SNMP-TARGET-MIB infrastructure, is not a (D)TLS based
	connection. If an tlstmAddrEntry exists for a given		connection. If an tlstmAddrEntry exists for a given
	snmpTargetAddrEntry then the presented server certificate MUST		snmpTargetAddrEntry then the presented server certificate MUST
	match or the connection MUST NOT be established. If a row in		match or the connection MUST NOT be established. If a row in
	this table does not exist to match a snmpTargetAddrEntry row		this table does not exist to match a snmpTargetAddrEntry row
	then the connection SHOULD still proceed if some other		then the connection SHOULD still proceed if some other
	certificate validation path algorithm (e.g. RFC5280) can be		certificate validation path algorithm (e.g. RFC5280) can be
	followed to a configured trust anchor."		followed to a configured trust anchor."
	INDEX { IMPLIED snmpTargetAddrName }		INDEX { IMPLIED snmpTargetAddrName }
	::= { tlstmAddrTable 1 }		::= { tlstmAddrTable 1 }
	TlstmAddrEntry ::= SEQUENCE {		TlstmAddrEntry ::= SEQUENCE {
	tlstmAddrServerHashType FingerprintType,		tlstmAddrServerFingerprint Fingerprint,
	tlstmAddrServerHashValue FingerprintValue,		tlstmAddrStorageType StorageType,
	tlstmAddrStorageType StorageType,		tlstmAddrRowStatus RowStatus
	tlstmAddrRowStatus RowStatus
	}		}
	tlstmAddrServerHashType OBJECT-TYPE		tlstmAddrServerFingerprint OBJECT-TYPE
	SYNTAX FingerprintType		SYNTAX Fingerprint
	MAX-ACCESS read-create
	STATUS current
	DESCRIPTION
	"The hash algorithm type for the hash stored in the
	tlstmAddrServerHash column to identify a local copy of the
	public X.509 certificate presented by the TLS server."
	DEFVAL { tlstmSHA256 }
	::= { tlstmAddrEntry 1 }
	tlstmAddrServerHashValue OBJECT-TYPE
	SYNTAX FingerprintValue
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A cryptographic hash of a public X.509 certificate. This		"A cryptographic hash of a public X.509 certificate. This
	object should store the hash of a local copy of the public		object should store the hash of a local copy of the public
	X.509 certificate that the remote server should present during		X.509 certificate that the remote server should present during
	the (D)TLS connection setup. The presented certificate and		the (D)TLS connection setup. The presented certificate and
	the locally held copy, referred to by this hash value, MUST		the locally held copy, referred to by this hash value, MUST
	match exactly or the connection MUST NOT be established."		match exactly or the connection MUST NOT be established."
	::= { tlstmAddrEntry 2 }		::= { tlstmAddrEntry 1 }
	tlstmAddrStorageType OBJECT-TYPE		tlstmAddrStorageType OBJECT-TYPE
	SYNTAX StorageType		SYNTAX StorageType
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The storage type for this conceptual row. Conceptual rows		"The storage type for this conceptual row. Conceptual rows
	having the value 'permanent' need not allow write-access to		having the value 'permanent' need not allow write-access to
	any columnar objects in the row."		any columnar objects in the row."
	DEFVAL { nonVolatile }		DEFVAL { nonVolatile }
	::= { tlstmAddrEntry 3 }		::= { tlstmAddrEntry 2 }
	tlstmAddrRowStatus OBJECT-TYPE		tlstmAddrRowStatus OBJECT-TYPE
	SYNTAX RowStatus		SYNTAX RowStatus
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The status of this conceptual row. This object may be used		"The status of this conceptual row. This object may be used
	to create or remove rows from this table.		to create or remove rows from this table.
	To create a row in this table, a manager must		To create a row in this table, a manager must
	set this object to either createAndGo(4) or		set this object to either createAndGo(4) or
	createAndWait(5).		createAndWait(5).
	Until instances of all corresponding columns are		Until instances of all corresponding columns are
	appropriately configured, the value of the		appropriately configured, the value of the
	corresponding instance of the tlstmAddrRowStatus		corresponding instance of the tlstmAddrRowStatus
	column is 'notReady'.		column is 'notReady'.
	In particular, a newly created row cannot be made active until		In particular, a newly created row cannot be made active until
	the corresponding tlstmAddrServerHashType, and		the corresponding tlstmAddrServerFingerprint column has been
	tlstmAddrServerHashValue columns have been set.		set.
	The following objects may not be modified while the		The tlstmAddrServerFingerprint object may not be modified
	value of this object is active(1):		while the value of this object is active(1).
	- tlstmAddrServerHashType
	- tlstmAddrServerHashValue
	An attempt to set these objects while the value of		An attempt to set these objects while the value of
	tlstmAddrRowStatus is active(1) will result in		tlstmAddrRowStatus is active(1) will result in
	an inconsistentValue error.		an inconsistentValue error.
	If this row is deleted it has no effect on the corresponding		If this row is deleted it has no effect on the corresponding
	row in the targetAddrTable.		row in the targetAddrTable.
	If the corresponding row in the targetAddrTable is deleted		If the corresponding row in the targetAddrTable is deleted
	then this row must be automatically removed."		then this row must be automatically removed."
	::= { tlstmAddrEntry 4 }		::= { tlstmAddrEntry 3 }
	-- ************************************************		-- ************************************************
			-- tlstmNotifications - Notifications Information
			-- ************************************************
			tlstmServerCertNotFound NOTIFICATION-TYPE
			STATUS current
			DESCRIPTION
			"Notification that the server certificate presented by a SNMP
			over (D)TLS server could not be found in the tlstmAddrTable."
			::= { tlstmNotifications 1 }
			tlstmServerAuthFailure NOTIFICATION-TYPE
			OBJECTS { tlstmAddrServerFingerprint }
			STATUS current
			DESCRIPTION
			"Notification that the server certificate presented by an SNMP
			over (D)TLS server was found, but the connection could not be
			established because of a cryptographic validation failure."
			::= { tlstmNotifications 2 }
			-- ************************************************
			-- tlstmCompliances - Conformance Information
	-- ************************************************		-- ************************************************
	tlstmCompliances OBJECT IDENTIFIER ::= { tlstmConformance 1 }		tlstmCompliances OBJECT IDENTIFIER ::= { tlstmConformance 1 }
	tlstmGroups OBJECT IDENTIFIER ::= { tlstmConformance 2 }		tlstmGroups OBJECT IDENTIFIER ::= { tlstmConformance 2 }
	-- ************************************************		-- ************************************************
	-- Compliance statements		-- Compliance statements
	-- ************************************************		-- ************************************************
	tlstmCompliance MODULE-COMPLIANCE		tlstmCompliance MODULE-COMPLIANCE
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The compliance statement for SNMP engines that support the		"The compliance statement for SNMP engines that support the
	TLSTM-MIB"		TLSTM-MIB"
	MODULE		MODULE
	MANDATORY-GROUPS { tlstmStatsGroup,		MANDATORY-GROUPS { tlstmStatsGroup,
	tlstmIncomingGroup, tlstmOutgoingGroup }		tlstmIncomingGroup,
			tlstmOutgoingGroup,
			tlstmNotificationGroup }
	::= { tlstmCompliances 1 }		::= { tlstmCompliances 1 }
	-- ************************************************		-- ************************************************
	-- Units of conformance		-- Units of conformance
	-- ************************************************		-- ************************************************
	tlstmStatsGroup OBJECT-GROUP		tlstmStatsGroup OBJECT-GROUP
	OBJECTS {		OBJECTS {
	tlstmSessionOpens,		tlstmSessionOpens,
	tlstmSessionCloses,		tlstmSessionCloses,
	tlstmSessionOpenErrors,		tlstmSessionOpenErrors,
	skipping to change at page 52, line 4 ¶		skipping to change at page 52, line 21 ¶
	-- ************************************************		-- ************************************************
	tlstmStatsGroup OBJECT-GROUP		tlstmStatsGroup OBJECT-GROUP
	OBJECTS {		OBJECTS {
	tlstmSessionOpens,		tlstmSessionOpens,
	tlstmSessionCloses,		tlstmSessionCloses,
	tlstmSessionOpenErrors,		tlstmSessionOpenErrors,
	tlstmSessionNoAvailableSessions,		tlstmSessionNoAvailableSessions,
	tlstmSessionInvalidClientCertificates,		tlstmSessionInvalidClientCertificates,
	tlstmSessionInvalidServerCertificates,		tlstmSessionInvalidServerCertificates,
	tlstmTLSProtectionErrors		tlstmTLSProtectionErrors
	}		}
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A collection of objects for maintaining		"A collection of objects for maintaining
	statistical information of an SNMP engine which		statistical information of an SNMP engine which
	implements the SNMP TLS Transport Model."		implements the SNMP TLS Transport Model."
	::= { tlstmGroups 1 }		::= { tlstmGroups 1 }
	tlstmIncomingGroup OBJECT-GROUP		tlstmIncomingGroup OBJECT-GROUP
	OBJECTS {		OBJECTS {
	tlstmCertToSNCount,		tlstmCertToSNCount,
	tlstmCertToSNTableLastChanged,		tlstmCertToSNTableLastChanged,
	tlstmCertToSNHashType,		tlstmCertToSNFingerprint,
	tlstmCertToSNHashValue,
	tlstmCertToSNMapType,		tlstmCertToSNMapType,
	tlstmCertToSNSecurityName,		tlstmCertToSNSecurityName,
	tlstmCertToSNSANType,		tlstmCertToSNSANType,
	tlstmCertToSNStorageType,		tlstmCertToSNStorageType,
	tlstmCertToSNRowStatus		tlstmCertToSNRowStatus
	}		}
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A collection of objects for maintaining		"A collection of objects for maintaining
	incoming connection certificate mappings to		incoming connection certificate mappings to
	securityNames of an SNMP engine which implements the		securityNames of an SNMP engine which implements the
	SNMP TLS Transport Model."		SNMP TLS Transport Model."
	::= { tlstmGroups 2 }		::= { tlstmGroups 2 }
	tlstmOutgoingGroup OBJECT-GROUP		tlstmOutgoingGroup OBJECT-GROUP
	OBJECTS {		OBJECTS {
	tlstmParamsCount,		tlstmParamsCount,
	tlstmParamsTableLastChanged,		tlstmParamsTableLastChanged,
	tlstmParamsClientHashType,		tlstmParamsClientFingerprint,
	tlstmParamsClientHashValue,
	tlstmParamsStorageType,		tlstmParamsStorageType,
	tlstmParamsRowStatus,		tlstmParamsRowStatus,
	tlstmAddrCount,		tlstmAddrCount,
	tlstmAddrTableLastChanged,		tlstmAddrTableLastChanged,
	tlstmAddrServerHashType,		tlstmAddrServerFingerprint,
	tlstmAddrServerHashValue,
	tlstmAddrStorageType,		tlstmAddrStorageType,
	tlstmAddrRowStatus		tlstmAddrRowStatus
	}		}
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A collection of objects for maintaining		"A collection of objects for maintaining
	outgoing connection certificates to use when opening		outgoing connection certificates to use when opening
	connections as a result of SNMP-TARGET-MIB settings."		connections as a result of SNMP-TARGET-MIB settings."
	::= { tlstmGroups 3 }		::= { tlstmGroups 3 }
			tlstmNotificationGroup NOTIFICATION-GROUP
			NOTIFICATIONS {
			tlstmServerCertNotFound,
			tlstmServerAuthFailure
			}
			STATUS current
			DESCRIPTION
			"Notifications"
			::= { tlstmGroups 4 }
	END		END
	8. Operational Considerations		8. Operational Considerations
	This section discusses various operational aspects of the solution		This section discusses various operational aspects of deploying
			TLSTM.
	8.1. Sessions		8.1. Sessions
	A session is discussed throughout this document as meaning a security		A session is discussed throughout this document as meaning a security
	association between the (D)TLS client and the (D)TLS server. State		association between the (D)TLS client and the (D)TLS server. State
	information for the sessions are maintained in each TLSTM and this		information for the sessions are maintained in each TLSTM
	information is created and destroyed as sessions are opened and		implementation and this information is created and destroyed as
	closed. Because of the connectionless nature of UDP, a "broken"		sessions are opened and closed. A "broken" session (one side up and
	session, one side up one side down, could result if one side of a		one side down) can result if one side of a session is brought down
	session is brought down abruptly (i.e., reboot, power outage, etc.).		abruptly (i.e., reboot, power outage, etc.). Whenever possible,
	Whenever possible, implementations SHOULD provide graceful session		implementations SHOULD provide graceful session termination through
	termination through the use of disconnect messages. Implementations		the use of disconnect messages. Implementations SHOULD also have a
	SHOULD also have a system in place for dealing with "broken"		system in place for dealing with "broken" sessions. Implementations
	sessions. Implementations SHOULD support the session resumption		SHOULD support the session resumption feature of TLS.
	feature of TLS.
	To simplify session management it is RECOMMENDED that implementations		To simplify session management it is RECOMMENDED that implementations
	utilize two separate ports, one for Notification sessions and one for		use separate ports for Notification sessions and for Command
	Command sessions. If this implementation recommendation is followed,		sessions. If this implementation recommendation is followed, (D)TLS
	(D)TLS clients will always send REQUEST messages and (D)TLS servers		clients will always send REQUEST messages and (D)TLS servers will
	will always send RESPONSE messages. With this assertion,		always send RESPONSE messages. With this assertion, implementations
	implementations may be able to simplify "broken" session handling,		may be able to simplify "broken" session handling, session
	session resumption, and other aspects of session management such as		resumption, and other aspects of session management such as
	guaranteeing that Request- Response pairs use the same session.		guaranteeing that Request- Response pairs use the same session.
	Implementations SHOULD limit the lifetime of established sessions		Implementations SHOULD limit the lifetime of established sessions
	depending on the algorithms used for generation of the master session		depending on the algorithms used for generation of the master session
	secret, the privacy and integrity algorithms used to protect		secret, the privacy and integrity algorithms used to protect
	messages, the environment of the session, the amount of data		messages, the environment of the session, the amount of data
	transferred, and the sensitivity of the data.		transferred, and the sensitivity of the data.
	8.2. Notification Receiver Credential Selection		8.2. Notification Receiver Credential Selection
	When an SNMP engine needs to establish an outgoing session for		When an SNMP engine needs to establish an outgoing session for
	notifications, the snmpTargetParamsTable includes an entry for the		notifications, the snmpTargetParamsTable includes an entry for the
	snmpTargetParamsSecurityName of the target. However, the receiving		snmpTargetParamsSecurityName of the target. However, the receiving
	SNMP engine (Server) does not know which (D)TLS certificate to offer		SNMP engine (Server) does not know which (D)TLS certificate to offer
	to the Client so that the tmSecurityName identity-authentication will		to the Client so that the tmSecurityName identity-authentication will
	be successful. The best solution would be to maintain a one-to-one		be successful.
	mapping between certificates and incoming ports for notification
	receivers, although other implementation dependent mechanisms may be		One solution is to maintain a one-to-one mapping between certificates
	used instead. This can be handled at the Notification Originator by		and incoming ports for notification receivers. This can be handled
	configuring the snmpTargetAddrTable (snmpTargetAddrTDomain and		at the Notification Originator by configuring the snmpTargetAddrTable
	snmpTargetAddrTAddress) and then requiring the receiving SNMP engine		(snmpTargetAddrTDomain and snmpTargetAddrTAddress) and requiring the
	to monitor multiple incoming static ports based on which principals		receiving SNMP engine to monitor multiple incoming static ports based
	are capable of receiving notifications. Implementations MAY also		on which principals are capable of receiving notifications.
	choose to designate a single Notification Receiver Principal to
	receive all incoming TRAPS and INFORMS.		Implementations MAY also choose to designate a single Notification
			Receiver Principal to receive all incoming TRAPS and INFORMS or
			select an implementation specific method of selecting a server
			certificate to present to clients.
	8.3. contextEngineID Discovery		8.3. contextEngineID Discovery
	Because most Command Responders have contextEngineIDs that are		Most Command Responders have contextEngineIDs that are identical to
	identical to the USM securityEngineID, the USM provides Command		the USM securityEngineID. USM provides a discovery service that
	Generators with the ability to discover a default contextEngineID to		allows Command Generators to determine a securityEngineID and thus a
	use. Because the TLS Transport Model does not make use of a		default contextEngineID to use. Because the TLS Transport Model does
	discoverable securityEngineID like the USM does, it may be difficult		not make use of a securityEngineID, it may be difficult for Command
	for Command Generators to discover a suitable default		Generators to discover a suitable default contextEngineID.
	contextEngineID. Implementations should consider offering another		Implementations should consider offering another engineID discovery
	engineID discovery mechanism to continue providing Command Generators		mechanism to continue providing Command Generators with a suitable
	with a contextEngineID discovery mechanism. A recommended discovery		contextEngineID mechanism. A recommended discovery solution is
	solution is documented in [RFC5343].		documented in [RFC5343].
	9. Security Considerations		9. Security Considerations
	This document describes a transport model that permits SNMP to		This document describes a transport model that permits SNMP to
	utilize (D)TLS security services. The security threats and how the		utilize (D)TLS security services. The security threats and how the
	(D)TLS transport model mitigates these threats are covered in detail		(D)TLS transport model mitigates these threats are covered in detail
	throughout this document. Security considerations for DTLS are		throughout this document. Security considerations for DTLS are
	covered in [RFC4347] and security considerations for TLS are		covered in [RFC4347] and security considerations for TLS are
	described in Section 11 and Appendices D, E, and F of TLS 1.2		described in Section 11 and Appendices D, E, and F of TLS 1.2
	[RFC5246]. DTLS adds to the security considerations of TLS only		[RFC5246]. DTLS adds to the security considerations of TLS only
	because it is more vulnerable to denial of service attacks. A random		because it is more vulnerable to denial of service attacks. A random
	cookie exchange was added to the handshake to prevent anonymous		cookie exchange was added to the handshake to prevent anonymous
	denial of service attacks. RFC 4347 recommends that the cookie		denial of service attacks. RFC 4347 recommends that the cookie
	exchange is utilized for all handshakes and therefore it is		exchange is utilized for all handshakes and therefore this
	RECOMMENDED that implementers also support this cookie exchange.		specification also RECOMMENDEDs that implementers also support this
			cookie exchange.
	9.1. Certificates, Authentication, and Authorization		9.1. Certificates, Authentication, and Authorization
	Implementations are responsible for providing a security certificate		Implementations are responsible for providing a security certificate
	configuration installation . Implementations SHOULD support		installation and configuration mechanism. Implementations SHOULD
	certificate revocation lists and expiration of certificates or other		support certificate revocation lists.
	access control mechanisms.
	(D)TLS provides for both authentication of the identity of the (D)TLS		(D)TLS provides for authentication of the identity of both the (D)TLS
	server and authentication of the identity of the (D)TLS client.		server and the (D)TLS client. Access to MIB objects for the
	Access to MIB objects for the authenticated principal MUST be		authenticated principal MUST be enforced by an access control
	enforced by an access control subsystem (e.g. the VACM).		subsystem (e.g. the VACM).
	Authentication of the Command Generator principal's identity is		Authentication of the Command Generator principal's identity is
	important for use with the SNMP access control subsystem to ensure		important for use with the SNMP access control subsystem to ensure
	that only authorized principals have access to potentially sensitive		that only authorized principals have access to potentially sensitive
	data. The authenticated identity of the Command Generator		data. The authenticated identity of the Command Generator
	principal's certificate is mapped to an SNMP model-independent		principal's certificate is mapped to an SNMP model-independent
	securityName for use with SNMP access control.		securityName for use with SNMP access control.
	Furthermore, the (D)TLS handshake only provides assurance that the		The (D)TLS handshake only provides assurance that the certificate of
	certificate of the authenticated identity has been signed by an		the authenticated identity has been signed by an configured accepted
	configured accepted Certificate Authority. (D)TLS has no way to		Certificate Authority. (D)TLS has no way to further authorize or
	further authorize or reject access based on the authenticated		reject access based on the authenticated identity. An Access Control
	identity. An Access Control Model (such as the VACM) provides access		Model (such as the VACM) provides access control and authorization of
	control and authorization of a Command Generator's requests to a		a Command Generator's requests to a Command Responder and a
	Command Responder and a Notification Responder's authorization to		Notification Responder's authorization to receive Notifications from
	receive Notifications from a Notification Originator. However to		a Notification Originator. However to avoid man-in-the-middle
	avoid man-in-the-middle attacks both ends of the (D)TLS based		attacks both ends of the (D)TLS based connection MUST check the
	connection MUST check the certificate presented by the other side		certificate presented by the other side against what was expected.
	against what was expected. For example, Command Generators must		For example, Command Generators must check that the Command Responder
	check that the Command Responder presented and authenticated itself		presented and authenticated itself with a X.509 certificate that was
	with a X.509 certificate that was expected. Not doing so would allow		expected. Not doing so would allow an impostor, at a minimum, to
	an impostor, at a minimum, to present false data, receive sensitive		present false data, receive sensitive information and/or provide a
	information and/or provide a false-positive belief that configuration		false belief that configuration was actually received and acted upon.
	was actually received and acted upon. Authenticating and verifying		Authenticating and verifying the identity of the (D)TLS server and
	the identity of the (D)TLS server and the (D)TLS client for all		the (D)TLS client for all operations ensures the authenticity of the
	operations ensures the authenticity of the SNMP engine that provides		SNMP engine that provides MIB data.
	MIB data.
	The instructions found in the DESCRIPTION clause of the		The instructions found in the DESCRIPTION clause of the
	tlstmCertToSNTable object must be followed exactly. Specifically, it		tlstmCertToSNTable object must be followed exactly. It is also
	is important that if a row matching a certificate or a certificate's		important that the rows of the table be searched in prioritized order
	issuer is found but the translation to a securityName using the row		starting with the row containing the lowest numbered tlstmCertToSNID
	fails that the lookup process stops and no further rows are		value.
	consulted. It is also important that the rows of the table be search
	in order starting with the row containing the lowest numbered
	tlstmCertToSNID value.
	9.2. Use with SNMPv1/SNMPv2c Messages		9.2. Use with SNMPv1/SNMPv2c Messages
	The SNMPv1 and SNMPv2c message processing described in RFC3484 (BCP		The SNMPv1 and SNMPv2c message processing described in RFC3484 (BCP
	74) [RFC3584] always selects the SNMPv1(1) Security Model for an		74) [RFC3584] always selects the SNMPv1(1) Security Model for an
	SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c		SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c
	message. When running SNMPv1/SNMPv2c over a secure transport like		message. When running SNMPv1/SNMPv2c over a secure transport like
	the TLS Transport Model, the securityName and securityLevel used for		the TLS Transport Model, the securityName and securityLevel used for
	access control decisions are then derived from the community string,		access control decisions are then derived from the community string,
	not the authenticated identity and securityLevel provided by the TLS		not the authenticated identity and securityLevel provided by the TLS
	skipping to change at page 57, line 32 ¶		skipping to change at page 58, line 7 ¶
	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. a TCP port number in the range 1..1023 in the		1. a TCP port number in the range 1..1023 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 port for SNMP command messages over a TLS		be the default port for receipt of SNMP command messages over a
	Transport Model as defined in this document,		TLS Transport Model as defined in this document,
	2. a TCP port number in the range 1..1023 in the		2. a TCP port number in the range 1..1023 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 port for SNMP notification messages over a TLS		be the default port for receipt of SNMP notification messages
	Transport Model as defined in this document,		over a TLS Transport Model as defined in this document,
	3. a UDP port number in the range 1..1023 in the		3. a UDP port number in the range 1..1023 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 port for SNMP command messages over a DTLS/UDP		be the default port for receipt of SNMP command messages over a
	connection as defined in this document,		DTLS/UDP connection as defined in this document,
	4. a UDP port number in the range 1..1023 in the		4. a UDP port number in the range 1..1023 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 port for SNMP notification messages over a DTLS/		be the default port for receipt of SNMP notification messages
	UDP connection as defined in this document,		over a DTLS/UDP connection as defined in this document,
	5. a SCTP port number in the range 1..1023 in the		5. a SCTP port number in the range 1..1023 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 port for SNMP command messages over a DTLS/SCTP		be the default port for receipt of SNMP command messages over a
	connection as defined in this document,		DTLS/SCTP connection as defined in this document,
	6. a SCTP port number in the range 1..1023 in the		6. a SCTP port number in the range 1..1023 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 port for SNMP notification messages over a DTLS/		be the default port for receipt of SNMP notification messages
	SCTP connection as defined in this document,		over a DTLS/SCTP connection as defined in this document,
	7. an SMI number under snmpDomains for the snmpTLSDomain object		7. an SMI number under snmpDomains for the snmpTLSDomain object
	identifier,		identifier,
	8. an SMI number under snmpDomains for the snmpDTLSUDPDomain object		8. an SMI number under snmpDomains for the snmpDTLSUDPDomain object
	identifier,		identifier,
	9. an SMI number under snmpDomains for the snmpDTLSSCTPDomain		9. an SMI number under snmpDomains for the snmpDTLSSCTPDomain
	object identifier,		object identifier,
	skipping to change at page 58, line 36 ¶		skipping to change at page 59, line 8 ¶
	11. "tls" as the corresponding prefix for the snmpTLSDomain in the		11. "tls" as the corresponding prefix for the snmpTLSDomain in the
	SNMP Transport Model registry,		SNMP Transport Model registry,
	12. "dudp" as the corresponding prefix for the snmpDTLSUDPDomain in		12. "dudp" as the corresponding prefix for the snmpDTLSUDPDomain in
	the SNMP Transport Model registry,		the SNMP Transport Model registry,
	13. "dsct" as the corresponding prefix for the snmpDTLSSCTPDomain in		13. "dsct" as the corresponding prefix for the snmpDTLSSCTPDomain in
	the SNMP Transport Model registry;		the SNMP Transport Model registry;
	14. Editor's note: this section should be replaced with appropriate		If possible, IANA is requested to use matching port numbers for all
	descriptive assignment text after IANA assignments are made and		assignments for SNMP Commands being sent over TLS, DTLS/UDP, DTLS/
	prior to publication.		SCTP.
			If possible, IANA is requested to use matching port numbers for all
			assignments for SNMP Notifications being sent over TLS, DTLS/UDP,
			DTLS/SCTP.
			Editor's note: this section should be replaced with appropriate
			descriptive assignment text after IANA assignments are made and prior
			to publication.
	11. Acknowledgements		11. Acknowledgements
	This document closely follows and copies the Secure Shell Transport		This document closely follows and copies the Secure Shell Transport
	Model for SNMP defined by David Harrington and Joseph Salowey in		Model for SNMP defined by David Harrington and Joseph Salowey in
	[I-D.ietf-isms-secshell].		[RFC5292].
	This document was reviewed by the following people who helped provide		This document was reviewed by the following people who helped provide
	useful comments: David Harrington, Alan Luchuk, Ray Purvis.		useful comments (in alphabetical order): Andy Donati, Pasi Eronen,
			David Harrington, Jeffrey Hutzelman, Alan Luchuk, Randy Presuhn, Ray
			Purvis, Joseph Salowey, Jurgen Schonwalder, Dave Shield.
	This work was supported in part by the United States Department of		This work was supported in part by the United States Department of
	Defense. Large portions of this document are based on work by		Defense. Large portions of this document are based on work by
	General Dynamics C4 Systems and the following individuals: Brian		General Dynamics C4 Systems and the following individuals: Brian
	Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John		Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John
	Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul,		Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul,
	Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip.		Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip.
	12. References		12. References
	skipping to change at page 60, line 18 ¶		skipping to change at page 60, line 48 ¶
	Security", RFC 4347, April 2006.		Security", RFC 4347, April 2006.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[I-D.ietf-isms-transport-security-model]		[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem
	Harington, D., "Transport Security Model for SNMP".		for the Simple Network Management Protocol (SNMP)",
			RFC 5590, June 2009.
	[I-D.ietf-isms-tmsm]		[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
	Harington, D. and J. Schoenwaelder, "Transport Subsystem		for the Simple Network Management Protocol (SNMP)",
	for the Simple Network Management Protocol (SNMP)".		RFC 5591, June 2009.
	12.2. Informative References		12.2. Informative References
	[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management		[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
	Protocol", RFC 2522, March 1999.		Protocol", RFC 2522, March 1999.
	[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,		[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
	"Introduction and Applicability Statements for Internet-		"Introduction and Applicability Statements for Internet-
	Standard Management Framework", RFC 3410, December 2002.		Standard Management Framework", RFC 3410, December 2002.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	December 2005.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, December 2005.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	RFC 4306, December 2005.		RFC 4306, December 2005.
	[I-D.ietf-isms-secshell]		[RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound
	Harington, D. and J. Salowey, "Secure Shell Transport		Route Filter for BGP-4", RFC 5292, August 2008.
	Model for SNMP".
	[RFC5343] Schoenwaelder, J., "Simple Network Management Protocol		[RFC5343] Schoenwaelder, J., "Simple Network Management Protocol
	(SNMP) Context EngineID Discovery".		(SNMP) Context EngineID Discovery", RFC 5343,
			September 2008.
	[I-D.saintandre-tls-server-id-check]		[I-D.saintandre-tls-server-id-check]
	Saint-Andre, P., Zeilenga, K., Hodges, J., and B. Morgan,		Saint-Andre, P., Zeilenga, K., Hodges, J., and B. Morgan,
	"Best Practices for Checking of Server Identities in the		"Best Practices for Checking of Server Identities in the
	Context of Transport Layer Security (TLS)".		Context of Transport Layer Security (TLS)".
	[AES] National Institute of Standards, "Specification for the		[AES] National Institute of Standards, "Specification for the
	Advanced Encryption Standard (AES)".		Advanced Encryption Standard (AES)".
	[DES] National Institute of Standards, "American National		[DES] National Institute of Standards, "American National
	skipping to change at page 61, line 41 ¶		skipping to change at page 62, line 22 ¶
	A.1. The (D)TLS Record Protocol		A.1. The (D)TLS Record Protocol
	At the lowest layer, layered on top of the transport control protocol		At the lowest layer, layered on top of the transport control protocol
	or a datagram transport protocol (e.g. UDP or SCTP) is the (D)TLS		or a datagram transport protocol (e.g. UDP or SCTP) is the (D)TLS
	Record Protocol.		Record Protocol.
	The (D)TLS Record Protocol provides security that has three basic		The (D)TLS Record Protocol provides security that has three basic
	properties:		properties:
	o The session can be confidential. Symmetric cryptography is used		o The session can be confidential. Symmetric cryptography is used
	for data encryption (e.g., AES [AES], DES [DES] etc.). The keys		for data encryption (e.g., [AES], [DES] etc.). The keys for this
	for this symmetric encryption are generated uniquely for each		symmetric encryption are generated uniquely for each session and
	session and are based on a secret negotiated by another protocol		are based on a secret negotiated by another protocol (such as the
	(such as the (D)TLS Handshake Protocol). The Record Protocol can		(D)TLS Handshake Protocol). The Record Protocol can also be used
	also be used without encryption.		without encryption.
	o Messages can have data integrity. Message transport includes a		o Messages can have data integrity. Message transport includes a
	message integrity check using a keyed MAC. Secure hash functions		message integrity check using a keyed MAC. Secure hash functions
	(e.g., SHA, MD5, etc.) are used for MAC computations. The Record		(e.g., SHA, MD5, etc.) are used for MAC computations. The Record
	Protocol can operate without a MAC, but is generally only used in		Protocol can operate without a MAC, but is generally only used in
	this mode while another protocol is using the Record Protocol as a		this mode while another protocol is using the Record Protocol as a
	transport for negotiating security parameters.		transport for negotiating security parameters.
	o Messages are protected against replay. (D)TLS uses explicit		o Messages are protected against replay. (D)TLS uses explicit
	sequence numbers and integrity checks. DTLS uses a sliding window		sequence numbers and integrity checks. DTLS uses a sliding window
	skipping to change at page 62, line 25 ¶		skipping to change at page 63, line 4 ¶
	A.2. The (D)TLS Handshake Protocol		A.2. The (D)TLS Handshake Protocol
	The (D)TLS Record Protocol is used for encapsulation of various		The (D)TLS Record Protocol is used for encapsulation of various
	higher-level protocols. One such encapsulated protocol, the (D)TLS		higher-level protocols. One such encapsulated protocol, the (D)TLS
	Handshake Protocol, allows the server and client to authenticate each		Handshake Protocol, allows the server and client to authenticate each
	other and to negotiate an integrity algorithm, an encryption		other and to negotiate an integrity algorithm, an encryption
	algorithm and cryptographic keys before the application protocol		algorithm and cryptographic keys before the application protocol
	transmits or receives its first octet of data. Only the (D)TLS		transmits or receives its first octet of data. Only the (D)TLS
	client can initiate the handshake protocol. The (D)TLS Handshake		client can initiate the handshake protocol. The (D)TLS Handshake
	Protocol provides security that has three basic properties:		Protocol provides security that has four basic properties:
	o The peer's identity can be authenticated using asymmetric (public		o The peer's identity can be authenticated using asymmetric (public
	key) cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This		key) cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
	authentication can be made optional, but is generally required by		authentication can be made optional, but is generally required by
	at least one of the peers.		at least one of the peers.
	(D)TLS supports three authentication modes: authentication of both		(D)TLS supports three authentication modes: authentication of both
	the server and the client, server authentication with an		the server and the client, server authentication with an
	unauthenticated client, and total anonymity. For authentication		unauthenticated client, and total anonymity. For authentication
	of both entities, each entity provides a valid certificate chain		of both entities, each entity provides a valid certificate chain
	leading to an acceptable certificate authority. Each entity is		leading to an acceptable certificate authority. Each entity is
	responsible for verifying that the other's certificate is valid		responsible for verifying that the other's certificate is valid
	and has not expired or been revoked. See		and has not expired or been revoked. See
	[I-D.saintandre-tls-server-id-check] for further details on		[I-D.saintandre-tls-server-id-check] for further details on
	standardized processing when checking Server certificate		standardized processing when checking server certificate
	identities.		identities.
	o The negotiation of a shared secret is secure: the negotiated		o The negotiation of a shared secret is secure: the negotiated
	secret is unavailable to eavesdroppers, and for any authenticated		secret is unavailable to eavesdroppers, and for any authenticated
	handshake the secret cannot be obtained, even by an attacker who		handshake the secret cannot be obtained, even by an attacker who
	can place himself in the middle of the session.		can place himself in the middle of the session.
	o The negotiation is not vulnerable to malicious modification: it is		o The negotiation is not vulnerable to malicious modification: it is
	infeasible for an attacker to modify negotiation communication		infeasible for an attacker to modify negotiation communication
	without being detected by the parties to the communication.		without being detected by the parties to the communication.
	skipping to change at page 63, line 36 ¶		skipping to change at page 64, line 15 ¶
	unsecured storage in certificate-using systems.		unsecured storage in certificate-using systems.
	ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was		ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was
	first published in 1988 as part of the X.500 Directory		first published in 1988 as part of the X.500 Directory
	recommendations, defines a standard certificate format [x509] which		recommendations, defines a standard certificate format [x509] which
	is a certificate which binds a subject (principal) to a public key		is a certificate which binds a subject (principal) to a public key
	value. This was later further documented in [RFC5280].		value. This was later further documented in [RFC5280].
	A X.509 certificate is a sequence of three required fields:		A X.509 certificate is a sequence of three required fields:
	tbsCertificate: The field contains the names of the subject and		tbsCertificate: The tbsCertificate field contains the names of the
	issuer, a public key associated with the subject, a validity		subject and issuer, a public key associated with the subject, a
	period, and other associated information. This field may also		validity period, and other associated information. This field may
	contain extension components.		also contain extension components.
	signatureAlgorithm: The signatureAlgorithm field contains the		signatureAlgorithm: The signatureAlgorithm field contains the
	identifier for the cryptographic algorithm used by the certificate		identifier for the cryptographic algorithm used by the certificate
	authority (CA) to sign this certificate.		authority (CA) to sign this certificate.
	signatureValue: The signatureValue field contains a digital		signatureValue: The signatureValue field contains a digital
	signature computed upon the ASN.1 DER encoded tbsCertificate		signature computed by the CA upon the ASN.1 DER encoded
	field. The ASN.1 DER encoded tbsCertificate is used as the input		tbsCertificate field. The ASN.1 DER encoded tbsCertificate is
	to the signature function. This signature value is then ASN.1 DER		used as the input to the signature function. This signature value
	encoded as a BIT STRING and included in the Certificate's		is then ASN.1 DER encoded as a BIT STRING and included in the
	signature field. By generating this signature, a CA certifies the		Certificate's signature field. By generating this signature, the
	validity of the information in the tbsCertificate field. In		CA certifies the validity of the information in the tbsCertificate
	particular, the CA certifies the binding between the public key		field. In particular, the CA certifies the binding between the
	material and the subject of the certificate.		public key material and the subject of the certificate.
	The basic X.509 authentication procedure is as follows: A system is		The basic X.509 authentication procedure is as follows: A system is
	initialized with a number of root certificates that contain the		initialized with a number of root certificates that contain the
	public keys of a number of trusted CAs. When a system receives a		public keys of a number of trusted CAs. When a system receives a
	X.509 certificate, signed by one of those CAs, the certificate has to		X.509 certificate, signed by one of those CAs, the certificate has to
	be verified. It first checks the signatureValue field by using the		be verified. It first checks the signatureValue field by using the
	public key of the corresponding trusted CA. Then it compares the		public key of the corresponding trusted CA. Then it compares the
	decrypted information with a digest of the tbsCertificate field. If		decrypted information with a digest of the tbsCertificate field. If
	they match, then the subject in the tbsCertificate field is		they match, then the subject in the tbsCertificate field is
	authenticated.		authenticated.
	skipping to change at page 64, line 35 ¶		skipping to change at page 65, line 15 ¶
	The isAccessAllowed() ASI requires configuration to exist in the		The isAccessAllowed() ASI requires configuration to exist in the
	following SNMP-VIEW-BASED-ACM-MIB tables:		following SNMP-VIEW-BASED-ACM-MIB tables:
	vacmSecurityToGroupTable		vacmSecurityToGroupTable
	vacmAccessTable		vacmAccessTable
	vacmViewTreeFamilyTable		vacmViewTreeFamilyTable
	The only table that needs to be discussed as particularly different		The only table that needs to be discussed as particularly different
	here is the vacmSecurityToGroupTable. This table is indexed by both		here is the vacmSecurityToGroupTable. This table is indexed by both
	the SNMPv3 security model and the security name. The security model,		the SNMPv3 security model and the security name. The security model,
	when TLSTM is in use, should be set to the value of XXX corresponding		when TLSTM is in use, should be set to the value of 4, corresponding
	to the TSM [I-D.ietf-isms-transport-security-model]. An example		to the TSM [RFC5591]. An example vacmSecurityToGroupTable row might
	vacmSecurityToGroupTable row might be filled out as follows (using a		be filled out as follows (using a single SNMP SET request):
	single SNMP SET request):
	Note to RFC editor: replace XXX in the previous paragraph above with
	the actual IANA-assigned number for the TSM security model and remove
	this note.
	vacmSecurityModel = XXX (TSM)		vacmSecurityModel = 4 (TSM)
	vacmSecurityName = "blueberry"		vacmSecurityName = "blueberry"
	vacmGroupaName = "administrators"		vacmGroupName = "administrators"
	vacmSecurityToGroupStorageType = 3 (nonVolatile)		vacmSecurityToGroupStorageType = 3 (nonVolatile)
	vacmSecurityToGroupStatus = 4 (createAndGo)		vacmSecurityToGroupStatus = 4 (createAndGo)
	Note to RFC editor: replace XXX in the vacmSecurityModel line above
	with the actual IANA-assigned number for the TSM security model and
	remove this note.
	This example will assume that the "administrators" group has been		This example will assume that the "administrators" group has been
	given proper permissions via rows in the vacmAccessTable and		given proper permissions via rows in the vacmAccessTable and
	vacmViewTreeFamilyTable.		vacmViewTreeFamilyTable.
	Depending on whether this VACM configuration is for a Command		Depending on whether this VACM configuration is for a Command
	Responder or a Command Generator the security name "blueberry" will		Responder or a Command Generator the security name "blueberry" will
	come from a few different locations.		come from a few different locations.
			C.1. Configuring the Notification Generator
	For Notification Generator's performing authorization checks, the		For Notification Generator's performing authorization checks, the
	server's certificate must be verified against the expected		server's certificate must be verified against the expected
	certificate before proceeding to send the notification. The		certificate before proceeding to send the notification. The expected
	securityName be set by the SNMP-TARGET-MIB's		certificate from the server may be listed in the tlstmAddrTable or
	snmpTargetParamsSecurityName column or other configuration mechanism		may be determined through other X.509 path validation mechanisms.
	and the certificate to use would be taken from the appropriate entry		The securityName to use for VACM authorization checks is set by the
	in the tlstmParamsTable. The tlstmParamsTable augments the SNMP-		SNMP-TARGET-MIB's snmpTargetParamsSecurityName column.
	TARGET-MIB's snmpTargetParamsTable with client-side certificate
	information.		The certificate that the notification generator should present to the
			server is taken from the tlstmParamsClientFingerprint column from the
			appropriate entry in the tlstmParamsTable table.
			C.2. Configuring the Command Responder
	For Command Responder applications, the vacmSecurityName "blueberry"		For Command Responder applications, the vacmSecurityName "blueberry"
	value is a value that needs to come from an incoming (D)TLS session.		value is a value that needs derive from an incoming (D)TLS session.
	The mapping from a recevied (D)TLS client certificate to a		The mapping from a recevied (D)TLS client certificate to a
	securityName is done with the tlstmCertToSNTable. The certificates		securityName is done with the tlstmCertToSNTable. The certificates
	must be loaded into the device so that a tlstmCertToSNEntry may refer		must be loaded into the device so that a tlstmCertToSNEntry may refer
	to it. As an example, consider the following entry which will		to it. As an example, consider the following entry which will
	provide a mapping from a X.509's hash fingerprint directly to the		provide a mapping from a client's public X.509's hash fingerprint
	"blueberry" securityName:		directly to the "blueberry" securityName:
	tlstmCertToSNID = 1 (chosen by ordering preference)		tlstmCertToSNID = 1 (chosen by ordering preference)
	tlstmCertToSNHashType = tlstmSHA256		tlstmCertToSNFingerprint = HASH (appropriate fingerprint)
	tlstmCertToSNHashValue = (appropriate sha256 fingerprint)		tlstmCertToSNMapType = 1 (specified)
	tlstmCertToSNMapType = specified(1)
	tlstmCertToSNSecurityName = "blueberry"		tlstmCertToSNSecurityName = "blueberry"
	tlstmCertToSNStorageType = 3 (nonVolatile)		tlstmCertToSNStorageType = 3 (nonVolatile)
	tlstmCertToSNRowStatus = 4 (createAndGo)		tlstmCertToSNRowStatus = 4 (createAndGo)
	The above is an example of how to map a particular certificate to a		The above is an example of how to map a particular certificate to a
	particular securityName. It is recommended that users make use of		particular securityName. It is recommended, however, that users make
	direct subjectAltName or CommonName mappings where possible since it		use of direct subjectAltName or CommonName mappings where possible as
	will provide a more scalable approach to certificate management.		it provides a more scalable approach to certificate management. This
	This entry provides an example of using a subjectAltName mapping:		entry provides an example of using a subjectAltName mapping:
	tlstmCertToSNID = 1 (chosen by ordering preference)		tlstmCertToSNID = 1 (chosen by ordering preference)
	tlstmCertToSNHashType = tlstmSHA256		tlstmCertToSNFingerprint = HASH (appropriate fingerprint)
	tlstmCertToSNHashValue = (appropriate sha256 fingerprint)		tlstmCertToSNMapType = 2 (bySubjectAltName)
	tlstmCertToSNMapType = bySubjectAltName(2)		tlstmCertToSNSANType = 1 (any)
	tlstmCertToSNSANType = 1 (any)		tlstmCertToSNStorageType = 3 (nonVolatile)
	tlstmCertToSNStorageType = 3 (nonVolatile)		tlstmCertToSNRowStatus = 4 (createAndGo)
	tlstmCertToSNRowStatus = 4 (createAndGo)
	The above entry indicates the subjectAltName field for certificates		The above entry indicates the subjectAltName field for certificates
	created by an Issuing certificate with a corresponding hash type and		created by an Issuing certificate with a corresponding fingerprint
	value will be trusted to always produce common names that are		will be trusted to always produce common names that are directly 1 to
	directly 1 to 1 mappable into SNMPv3 securityNames. This type of		1 mappable into SNMPv3 securityNames. This type of configuration
	configuration should only be used when the certificate authorities		should only be used when the certificate authorities naming
	naming conventions are carefully controlled.		conventions are carefully controlled.
	For the example, if the incoming (D)TLS client provided certificate		In the example, if the incoming (D)TLS client provided certificate
	contained a subjectAltName where the first listed subjectAltName in		contained a subjectAltName where the first listed subjectAltName in
	the extension is the rfc822Name of "blueberry" and the certificate		the extension is the rfc822Name of "blueberry", the certificate was
	was signed by a certificate matching the tlstmCertToSNHashType and		signed by a certificate matching the tlstmCertToSNFingerprint value
	tlstmCertToSNHashValue values above and the CA's certificate was		and the CA's certificate was properly installed on the device then
	properly installed on the device then the string "blueberry" would be		the string "blueberry" would be used as the securityName for the
	used as the securityName for the session.		session.
	Author's Address		Author's Address
	Wes Hardaker		Wes Hardaker
	Sparta, Inc.		Sparta, Inc.
	P.O. Box 382		P.O. Box 382
	Davis, CA 95617		Davis, CA 95617
	US		USA
	Phone: +1 530 792 1913		Phone: +1 530 792 1913
	Email: ietf@hardakers.net		Email: ietf@hardakers.net
End of changes. 226 change blocks.
	742 lines changed or deleted		761 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/