< draft-ietf-isms-dtls-tm-05.txt		draft-ietf-isms-dtls-tm-06.txt >
	ISMS W. Hardaker		ISMS W. Hardaker
	Internet-Draft Sparta, Inc.		Internet-Draft Sparta, Inc.
	Intended status: Standards Track January 8, 2010		Intended status: Standards Track January 27, 2010
	Expires: July 12, 2010		Expires: July 31, 2010
	Transport Layer Security (TLS) Transport Model for SNMP		Transport Layer Security (TLS) Transport Model for SNMP
	draft-ietf-isms-dtls-tm-05.txt		draft-ietf-isms-dtls-tm-06.txt
	Abstract		Abstract
	This document describes a Transport Model for the Simple Network		This document describes a Transport Model for the Simple Network
	Management Protocol (SNMP), that uses either the Transport Layer		Management Protocol (SNMP), that uses either the Transport Layer
	Security protocol or the Datagram Transport Layer Security (DTLS)		Security protocol or the Datagram Transport Layer Security (DTLS)
	protocol. The TLS and DTLS protocols provide authentication and		protocol. The TLS and DTLS protocols provide authentication and
	privacy services for SNMP applications. This document describes how		privacy services for SNMP applications. This document describes how
	the TLS Transport Model (TLSTM) implements the needed features of a		the TLS Transport Model (TLSTM) implements the needed features of a
	SNMP Transport Subsystem to make this protection possible in an		SNMP Transport Subsystem to make this protection possible in an
	skipping to change at page 2, line 9 ¶		skipping to change at page 2, line 9 ¶
	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 July 12, 2010.		This Internet-Draft will expire on July 31, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 10 ¶		skipping to change at page 3, line 10 ¶
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7		1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
	2. The Transport Layer Security Protocol . . . . . . . . . . . . 8		2. The Transport Layer Security Protocol . . . . . . . . . . . . 8
	3. How the TLSTM fits into the Transport Subsystem . . . . . . . 9		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 . . . . . . . . . . . . . . . . . . . 12
	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 . . . . . . . . 17		4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 17
	4.3.2. SNMP Services for an Incoming Message . . . . . . . . 18		4.3.2. SNMP Services for an Incoming Message . . . . . . . . 17
	4.4. Cached Information and References . . . . . . . . . . . . 18		4.4. Cached Information and References . . . . . . . . . . . . 18
	4.4.1. TLS Transport Model Cached Information . . . . . . . . 19		4.4.1. TLS Transport Model Cached Information . . . . . . . . 18
	4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 19		4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 19
	4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 19		4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 19
	4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 19		4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 19
	5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20		5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19
	5.1. Procedures for an Incoming Message . . . . . . . . . . . . 20		5.1. Procedures for an Incoming Message . . . . . . . . . . . . 20
	5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 20		5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 20
	5.1.2. Transport Processing for Incoming SNMP Messages . . . 22		5.1.2. Transport Processing for Incoming SNMP Messages . . . 22
	5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 23		5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 23
	5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 24		5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 24
	5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27		5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27
	6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 28		6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 27
	6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28		6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28
	6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28		6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28
	6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28		6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28
	6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28		6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28
	6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 29		6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 28
	6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29		6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29
	6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29		6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29
	7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29		7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29
	8. Operational Considerations . . . . . . . . . . . . . . . . . . 50		8. Operational Considerations . . . . . . . . . . . . . . . . . . 50
	8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51		8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51
	8.2. Notification Receiver Credential Selection . . . . . . . . 51		8.2. Notification Receiver Credential Selection . . . . . . . . 51
	8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 52		8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 52
	8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52		8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 52		9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
	9.1. Certificates, Authentication, and Authorization . . . . . 52		9.1. Certificates, Authentication, and Authorization . . . . . 52
	skipping to change at page 4, line 14 ¶		skipping to change at page 4, line 14 ¶
	9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 54		9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 54
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 57		12.1. Normative References . . . . . . . . . . . . . . . . . . . 57
	12.2. Informative References . . . . . . . . . . . . . . . . . . 58		12.2. Informative References . . . . . . . . . . . . . . . . . . 58
	Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59		Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59
	A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 59		A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 59
	A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60		A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60
	Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61		Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61
	Appendix C. Target and Notificaton Configuration Example . . . . 62		Appendix C. Target and Notification Configuration Example . . . . 62
	C.1. Configuring the Notification Generator . . . . . . . . . . 63		C.1. Configuring the Notification Originator . . . . . . . . . 63
	C.2. Configuring the Command Responder . . . . . . . . . . . . 63		C.2. Configuring the Command Responder . . . . . . . . . . . . 63
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64
	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
	[RFC5590]. It is also important to understand the terminology of the		[RFC5590]. It is also important to understand the terminology of the
	SNMPv3 architecture in order to understand where the Transport Model		SNMPv3 architecture in order to understand where the Transport Model
	described in this document fits into the architecture and how it		described in this document fits into the architecture and how it
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 8 ¶
	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 valid. Note: this diagram shows the Transport Security Model		equally valid. Note: this diagram shows the Transport Security Model
	(TSM) being used as the security model which is defined in [RFC5591].		(TSM) being used as the security model which is defined in [RFC5591].
	+----------------------------------------------------------------+		+---------------------------------------------------------------------+
	| Network |		| Network |
	+----------------------------------------------------------------+		+---------------------------------------------------------------------+
	^ | ^ |		^ | ^ |
	|Notifications |Commands |Commands |Notifications		|Notifications |Commands |Commands |Notifications
	+---|---------------------|--------+ +--|---------------|-------------+		+---|---------------------|--------+ +--|---------------|-------------+
	| | 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 | +-------+ | | | V | +--------+ |
	| | +------+ +----+ | | | | | +------+ +----+ | | |		| | +--------+ | | | | | | +--------+ | | | |
	| | | TLS | <---------->| Cache | | | | | TLS | <---->| Cache | |		| | | TLS TM |---------->| Cache | | | | | TLS TM | <---->| Cache | |
	| | | TM | | | | | | | | TM | | | | |		| | | | | | | | | | | | | | | |
	| | +------+ | +-------+ | | | +------+ | +--------+ |		| | +--------+ | +-------+ | | | +--------+ | +--------+ |
	| |Transport Subsystem | ^ | | |Transport Sub. | ^ |		| |Transport Subsystem | ^ | | |Transport Sub. | ^ |
	| +--------------------+ | | | +-----------------+ | |		| +--------------------+ | | | +-----------------+ | |
	| ^ +----+ | | ^ | |		| ^ +----+ | | ^ | |
	| | | | | | | |		| | | | | | | |
	| v | | | V | |		| v | | | V | |
	| +-------+ +----------+ +-----+ | | | +-----+ +------+ +-----+ | |		| +-------+ +----------+ +-----+ | | | +-----+ +------+ +-----+ | |
	| | | |Message | |Sec. | | | | | | | MP | |Sec. | | |		| | | |Message | |Sec. | | | | | | | MP | |Sec. | | |
	| | Disp. | |Processing| |Sub- | | | | |Disp.| | Sub- | |Sub- | | |		| | Disp. | |Processing| |Sub- | | | | |Disp.| | Sub- | |Sub- | | |
	| | | |Subsystem | |sys. | | | | | | |system| |sys. | | |		| | | |Subsystem | |sys. | | | | | | |system| |sys. | | |
	| | | | | | | | | | | | | | | | | |		| | | | | | | | | | | | | | | | | |
	| | | | | |+---+| | | | | | | | |+---+| | |		| | | | | |+---+| | | | | | | | |+---+| | |
	| | | | +-----+ | || || | | | | | |+----+| || || | |		| | | | +-----+ | || || | | | | | |+----+| || || | |
	| | <--->|v3MP |<-->||TSM|<-+ | | | <-->|v3MP|<->|TSM|<-+ |		| | <--->|v3MP |<--->|TSM|<-+ | | | <-->|v3MP|<->|TSM|<-+ |
	| | | | +-----+ | || || | | | | |+----+| || || |		| | | | +-----+ | || || | | | | |+----+| || || |
	| +-------+ | | |+---+| | | +-----+ | | |+---+| |		| +-------+ | | |+---+| | | +-----+ | | |+---+| |
	| ^ | | | | | | ^ | | | | |		| ^ | | | | | | ^ | | | | |
	| | +----------+ +-----+ | | | +------+ +-----+ |		| | +----------+ +-----+ | | | +------+ +-----+ |
	| +-+------------+ | | +-+------------+ |		| +-+------------+ | | +-+----------+ |
	| ^ ^ | | ^ ^ |		| ^ ^ | | | ^ |
	| | | | | | | |		| | | | | | | |
	| v v | | V V |		| v v | | v V |
	| +-------------+ +--------------+ | | +-----------+ +--------------+ |		| +-------------+ +--------------+ | | +-----------+ +--------------+ |
	| | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | |		| | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | |
	| | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RECEIVER | |		| | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RECEIVER | |
	| | application | | application | | | |application| | application | |		| | application | | application | | | |application| | application | |
	| +-------------+ +--------------+ | | +-----------+ +--------------+ |		| +-------------+ +--------------+ | | +-----------+ +--------------+ |
	| SNMP entity | | SNMP entity |		| SNMP entity | | SNMP entity |
	+----------------------------------+ +--------------------------------+		+----------------------------------+ +--------------------------------+
	1.1. Conventions		1.1. Conventions
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 25 ¶
	terminology that is consistent with non-SNMP specifications. This is		terminology that is consistent with non-SNMP specifications. This is
	consistent with the IESG decision to not require the SNMPv3		consistent with the IESG decision to not require the SNMPv3
	terminology be modified to match the usage of other non-SNMP		terminology be modified to match the usage of other non-SNMP
	specifications when SNMPv3 was advanced to Full Standard.		specifications when SNMPv3 was advanced to Full Standard.
	"Authentication" in this document typically refers to the English		"Authentication" in this document typically refers to the English
	meaning of "serving to prove the authenticity of" the message, not		meaning of "serving to prove the authenticity of" the message, not
	data source authentication or peer identity authentication.		data source authentication or peer identity authentication.
	The terms "manager" and "agent" are not used in this document		The terms "manager" and "agent" are not used in this document
	because, in the RFC 3411 architecture, all SNMP entities have the		because, in the [RFC3411] architecture, all SNMP entities have the
	capability of acting as manager, agent, or both depending on the SNMP		capability of acting as manager, agent, or both depending on the SNMP
	application types supported in the implementation. Where distinction		application types supported in the implementation. Where distinction
	is required, the application names of command generator, command		is required, the application names of command generator, command
	responder, notification originator, notification receiver, and proxy		responder, notification originator, notification receiver, and proxy
	forwarder are used. See "SNMP Applications" [RFC3413] for further		forwarder are used. See "SNMP Applications" [RFC3413] for further
	information.		information.
	Authentication in this document typically refers to the English
	meaning of "serving to prove the authenticity of" the message, not
	data source authentication or peer identity authentication.
	The terms "manager" and "agent" are not used in this document,
	because in the RFC 3411 architecture [RFC3411], all SNMP entities
	have the capability of acting in either manager or agent or in both
	roles depending on the SNMP application types supported in the
	implementation. Where distinction is required, the application names
	of command generator, command responder, notification originator,
	Notification Receiver, and proxy forwarder are used. See "SNMP
	Applications" [RFC3413] for further information.
	Large portions of this document simultaneously refer to both TLS and		Large portions of this document simultaneously refer to both TLS and
	DTLS when discussing TLSTM components that function equally with		DTLS when discussing TLSTM components that function equally with
	either protocol. "(D)TLS" is used in these places to indicate that		either protocol. "(D)TLS" is used in these places to indicate that
	the statement applies to either or both protocols as appropriate.		the statement applies to either or both protocols as appropriate.
	When a distinction between the protocols is needed they are referred		When a distinction between the protocols is needed they are referred
	to independently through the use of "TLS" or "DTLS". The Transport		to independently through the use of "TLS" or "DTLS". The Transport
	Model, however, is named "TLS Transport Model" and refers not to the		Model, however, is named "TLS Transport Model" and refers not to the
	TLS or DTLS protocol but to the standard defined in this document,		TLS or DTLS protocol but to the standard defined in this document,
	which includes support for both TLS and DTLS.		which includes support for both TLS and DTLS.
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 15 ¶
	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 used for
	replay protection (see [RFC4347]).		replay protection (see [RFC4347]).
	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.		on the exchanges between SNMP engines.
	(D)TLS provides protection against the disclosure of information		(D)TLS provides protection against the disclosure of information
	to unauthorized recipients or eavesdroppers by allowing for		to unauthorized recipients or eavesdroppers by allowing for
	encryption of all traffic between SNMP engines. The TLS		encryption of all traffic between SNMP engines. The TLS
	Transport Model SHOULD support the message encryption to protect		Transport Model SHOULD support the message encryption to protect
	sensitive data from eavesdropping attacks.		sensitive data from eavesdropping attacks.
	skipping to change at page 12, line 31 ¶		skipping to change at page 12, line 21 ¶
	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, the transport type and the transport address		authenticated principal, the transport type and the transport address
	associated with an incoming message. The TLS Transport Model		associated with an incoming message. The TLS Transport Model
	provides the identity and destination type and address to (D)TLS for		provides the identity and destination type and address to (D)TLS for
	outgoing messages.		outgoing messages.
	When an application requests a session for a message, through the		When an application requests a session for a message it also requests
	cache, the application requests a security level for that session.		a security level for that session. The TLS Transport Model MUST
	The TLS Transport Model MUST ensure that the (D)TLS session provides		ensure that the (D)TLS session provides security at least as high as
	security at least as high as the requested level of security. How		the requested level of security. How the security level is
	the security level is translated into the algorithms used to provide		translated into the algorithms used to provide data integrity and
	data integrity and privacy is implementation-dependent. However, the		privacy is implementation-dependent. However, the NULL integrity and
	NULL integrity and encryption algorithms MUST NOT be used to fulfill		encryption algorithms MUST NOT be used to fulfill security level
	security level requests for authentication or privacy.		requests for authentication or privacy. Implementations MAY choose
	Implementations MAY choose to force (D)TLS to only allow		to force (D)TLS to only allow cipher_suites that provide both
	cipher_suites that provide both authentication and privacy to		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.		utilized by the application.
	The authentication, integrity and privacy algorithms used by the		The authentication, integrity and privacy algorithms used by the
	(D)TLS Protocols may vary over time as the science of cryptography		(D)TLS Protocols may vary over time as the science of cryptography
	continues to evolve and the development of (D)TLS continues over		continues to evolve and the development of (D)TLS continues over
	skipping to change at page 13, line 50 ¶		skipping to change at page 13, line 39 ¶
	duration of the session from the TLSTM's perspective even if the TLS		duration of the session from the TLSTM's perspective even if the TLS
	internal session identifier does change.		internal session identifier does change.
	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 (e.g.,		for the TLS Transport Model and security model (e.g.,
	tmSecurityLevel, tmSecurityName, transportDomain, transportAddress).		tmSecurityLevel, tmSecurityName, transportDomain, transportAddress).
	The transport- related and (D)TLS-security-related information,		The transport-related and (D)TLS-security-related information,
	including the authenticated identity, are stored in a cache		including the authenticated identity, are stored in a cache
	referenced by tmStateReference.		referenced by tmStateReference.
	For the (D)TLS client-side, the TLS Transport Model takes input		For the (D)TLS client-side, the TLS Transport Model takes input
	provided by the Dispatcher in the sendMessage() Abstract Service		provided by the Dispatcher in the sendMessage() Abstract Service
	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
	skipping to change at page 14, line 29 ¶		skipping to change at page 14, line 19 ¶
	generators, notification originators, proxy forwarders. Command		generators, notification originators, proxy forwarders. Command
	generators are frequently operated by a human, but notification		generators are frequently operated by a human, but notification
	originators and proxy forwarders are usually unmanned automated		originators and proxy forwarders are usually unmanned automated
	processes. The targets to whom notifications and proxied requests		processes. The targets to whom notifications and proxied requests
	should be sent is typically determined and configured by a network		should be sent is typically determined and configured by a network
	administrator.		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 originator, 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 snmpTLSTCPDomain, snmpDTLSUDPDomain, or snmpDTLSSCTPDomain		set to the snmpTLSTCPDomain, snmpDTLSUDPDomain, or snmpDTLSSCTPDomain
	object and an appropriate snmpTLSAddress value. When used with the		object and an appropriate snmpTLSAddress value. When used with the
	SNMPv3 message processing model, the snmpTargetParamsMPModel column		SNMPv3 message processing model, the snmpTargetParamsMPModel column
	of the snmpTargetParamsTable should be set to a value of 3. The		of the snmpTargetParamsTable should be set to a value of 3. The
	snmpTargetParamsSecurityName should be set to an appropriate		snmpTargetParamsSecurityName should be set to an appropriate
	securityName value and the tlstmParamsClientFingerprint parameter of		securityName value and the tlstmParamsClientFingerprint parameter of
	the tlstmParamsTable should be set a value that refers to a locally		the tlstmParamsTable should be set a value that refers to a locally
	held certificate to be used. Other parameters, for example		held certificate to be used. Other parameters, for example
	cryptographic configuration such as cipher suites to use, must come		cryptographic configuration such as which cipher suites to use, must
	from configuration mechanisms not defined in this document. The		come from configuration mechanisms not defined in this document.
	securityName defined in the snmpTargetParamsSecurityName column will
	be used by the access control model to authorize any notifications		The securityName defined in the snmpTargetParamsSecurityName column
	that need to be sent.		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 can make use of X.509 certificates for authentication of both		(D)TLS can make use of X.509 certificates for authentication of both
	sides of the transport. This section discusses the use of X.509		sides of the transport. This section discusses the use of X.509
	skipping to change at page 15, line 34 ¶		skipping to change at page 15, line 29 ¶
	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 (possibly the certificate itself).		certificate authorities (possibly the certificate itself).
	Furthermore, SNMP entities will most commonly need to be provisioned		Furthermore, SNMP entities will most commonly need to be provisioned
	with root certificates which represent the list of trusted		with root certificates which represent the list of trusted
	certificate authorities that an SNMP entity can use for certificate		certificate authorities that an SNMP entity can use for certificate
	verification. SNMP entities SHOULD also be provisioned with a X.509		verification. SNMP entities SHOULD also be provisioned with a X.509
	certificate revocation mechanism which can be used to verify that a		certificate revocation mechanism which can be used to verify that a
	certificate has not been revoked. Trusted public keys from either CA		certificate has not been revoked. Trusted public keys from either CA
	certificates and/or self-signed certificates, MUST be installed		certificates and/or self-signed certificates, MUST be installed into
	through a trusted out of band mechanism into the server and its		the server through a trusted out of band mechanism and their
	authenticity MUST be verified before access is granted.		authenticity MUST be verified before access is granted.
	Having received a certificate from a connecting TLSTM client, the		Having received a certificate from a connecting TLSTM client, the
	authenticated tmSecurityName of the principal is derived using the		authenticated tmSecurityName of the principal is derived using the
	tlstmCertToTSNTable. This table allows mapping of incoming		tlstmCertToTSNTable. This table allows mapping of incoming
	connections to tmSecurityNames through defined transformations. The		connections to tmSecurityNames through defined transformations. The
	transformations defined in the TLSTM-MIB include:		transformations defined in the TLSTM-MIB include:
	o Mapping a certificate's fingerprint type and value to a directly
	specified tmSecurityName, or
	o Mapping a certificate's subjectAltName or CommonName components to		o Mapping a certificate's subjectAltName or CommonName components to
	a tmSecurityName.		a tmSecurityName, or
			o Mapping a certificate's fingerprint value to a directly specified
			tmSecurityName
	As an implementation hint: implementations may choose to discard any		As an implementation hint: implementations may choose to discard any
	connections for which no potential tlstmCertToTSNTable mapping exists		connections for which no potential tlstmCertToTSNTable mapping exists
	before performing certificate verification to avoid expending		before performing certificate verification to avoid expending
	computational resources associated with certificate verification.		computational resources associated with certificate verification.
	Enterprise configurations are encouraged to map a "subjectAltName"		Enterprise configurations are encouraged to map a "subjectAltName"
	component of the X.509 certificate to the TLSTM specific		component of the X.509 certificate to the TLSTM specific
	tmSecurityName. The authenticated identity can be obtained by the		tmSecurityName. The authenticated identity can be obtained by the
	TLS Transport Model by extracting the subjectAltName(s) from the		TLS Transport Model by extracting the subjectAltName(s) from the
	skipping to change at page 16, line 26 ¶		skipping to change at page 16, line 21 ¶
	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 [RFC5591], may perform		A security model, like the TSM security model [RFC5591], may perform
	an identity mapping or a more complex mapping to derive the		an identity mapping or a more complex mapping to derive the
	securityName from the tmSecurityName offered by the TLS Transport		securityName from the tmSecurityName offered by the TLS Transport
	Model.		Model.
	A pictorial view of the complete transformation process (using the		A pictorial view of the complete transformation process (using the
	TSM security model for the example) is shown below:		TSM security model for the example) is shown below:
	+-------------+ +-------+ +----------------+ +-----+		+-------------+ +-------+ +-----+
	| Certificate | | | | | | |		| Certificate | | | | |
	| Path | | TLSTM | | tmSecurityName | | TSM |		| Path | | TLSTM | tmpSecurityName | TSM |
	| Validation | --> | | --> | | --> | |		| Validation | --> | | ----------------->| |
	+-------------+ +-------+ +----------------+ +-----+		+-------------+ +-------+ +-----+
	|		|
	V		| securityName
	+-------------+ +--------------+		V
	| application | <-- | securityName |		+-------------+
	+-------------+ +--------------+		| application |
			+-------------+
	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 25 ¶		skipping to change at page 17, line 22 ¶
	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 returned from or passed as parameters into		The abstract data elements returned from or passed as parameters into
	the abstract 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 sending 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 document specifies the snmpTLSDomain,		destTransportAddress. This document specifies the snmpTLSDomain,
	the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport		the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain transport
	domains.		domains.
	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		Transport Model in a format specified by the SnmpTLSAddress
	TEXTUAL-CONVENTION.		TEXTUAL-CONVENTION.
	outgoingMessage: The outgoing message to send to (D)TLS for		outgoingMessage: The outgoing message to send to (D)TLS for
	encapsulation.		encapsulation and transmission.
	outgoingMessageLength: The length of the outgoingMessage field.		outgoingMessageLength: The length of the outgoingMessage field.
	tmStateReference: A handle/reference to tmState to be used when		tmStateReference: A reference to tmState to be used when securing
	securing outgoing messages.		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
	skipping to change at page 18, line 29 ¶		skipping to change at page 18, line 23 ¶
	The abstract data elements returned from or passed as parameters into		The abstract data elements returned from or passed as parameters into
	the abstract 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 the snmpTLSDomain, the		transportAddress. This document specifies the snmpTLSDomain, the
	snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport domains.		snmpDTLSUDPDomain and the snmpDTLSSCTPDomain transport domains.
	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		received message in a format specified by the SnmpTLSAddress
	TEXTUAL-CONVENTION.		TEXTUAL-CONVENTION.
	incomingMessage: The whole SNMP message after being processed by		incomingMessage: The whole SNMP message after being processed by
	(D)TLS and removed of the (D)TLS transport layer data.		(D)TLS and the (D)TLS transport layer data has been removed.
	incomingMessageLength: The length of the incomingMessage field.		incomingMessageLength: The length of the incomingMessage field.
	tmStateReference: A handle/reference to tmSecurityData to be used by		tmStateReference: A reference to tmSecurityData to be used by the
	the security model.		security model.
	4.4. Cached Information and References		4.4. 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" [RFC5590] defines general requirements		Network Management Protocol" [RFC5590] defines general requirements
	for caches and references.		for caches and references.
	skipping to change at page 20, line 19 ¶		skipping to change at page 20, line 9 ¶
	between the various subsystems within an SNMP entity. The TLSTM uses		between the various subsystems within an SNMP entity. The TLSTM uses
	some of these conceptual data flows when communicating between		some of these conceptual data flows when communicating between
	subsystems.		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 prior to
	to being released.		being released.
	An error indication in statusInformation will typically include the		An error indication in statusInformation will typically include the
	Object Identifier (OID) and value for an incremented error counter.		Object Identifier (OID) and value for an incremented error counter.
	This may be accompanied by the requested securityLevel and the		This may be accompanied by the requested securityLevel and the
	tmStateReference. Per-message context information is not accessible		tmStateReference. Per-message context information is not accessible
	to Transport Models, so for the returned counter OID and value,		to Transport Models, so for the returned counter OID and value,
	contextEngine would be set to the local value of snmpEngineID and		contextEngine would be set to the local value of snmpEngineID and
	contextName to the default context for error counters.		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		required functionality is broken into two different sections.
	describes the needed steps for de-multiplexing multiple DTLS
	sessions, which is specifically needed for DTLS over UDP sessions.		Section 5.1.1 describes the processing required for de-multiplexing
	Section 5.1.2 describes the steps specific to transport processing		multiple DTLS sessions, which is specifically needed for DTLS over
	once the (D)TLS processing has been completed. It is assumed that		UDP sessions. It is assumed that TLS and DTLS/SCP protocol
	TLS and DTLS/SCP protocol implementations already provide appropriate		implementations already provide appropriate message demultiplexing.
	message demultiplexing and only the processing steps in Section 5.1.2
	are needed.		Section 5.1.2describes the transport processing required once the
			(D)TLS processing has been completed. This will be needed for all
			(D)TLS-based sessions.
	5.1.1. DTLS Processing for Incoming Messages		5.1.1. DTLS Processing for Incoming Messages
	DTLS over UDP is significantly different in terms of session handling		DTLS over UDP is significantly different in terms of session handling
	than when TLS or DTLS is run over session based streaming protocols		than when TLS or DTLS is run over session based streaming protocols
	like TCP or SCTP. Specifically, the DTLS protocol, when run over		like TCP or SCTP. Specifically, the DTLS protocol, when run over
	UDP, does not have a session identifier that allows implementations		UDP, does not have a session identifier that allows implementations
	to determine through which session a packet arrived. It is always		to determine through which session a packet arrived. It is critical,
	critical, however, that implementations be able to derive a		however, that implementations are always able to derive a
	tlstmSessionID from any session demultiplexing process. When		tlstmSessionID from any session demultiplexing process. When
	establishing a new session implementations MUST use a different UDP		establishing a new session implementations MUST use a different UDP
	source port number for each connection to a remote destination IP-		source port number for each active connection to a remote destination
	address/port-number combination to ensure the remote entity can		IP-address/port-number combination to ensure the remote entity can
	easily disambiguate between multiple sessions from a host to the same		easily disambiguate between multiple sessions from a host to the same
	port on a server.		port on a server.
	A process for demultiplexing multiple DTLS sessions arriving over UDP		A process for demultiplexing multiple DTLS sessions arriving over UDP
	must be incorporated into the procedures for processing an incoming		must be incorporated into the procedures for processing an incoming
	message. The steps in this section describe one possible method to		message. The steps in this section describe one possible method to
	accomplish this, although any implementation-dependent method should		accomplish this, although any implementation-dependent method should
	be suitable as long as the results are deterministic. The important		be suitable as long as the results are deterministic. The important
	output results from the steps in this process are the		output results from the steps in this process are the
	transportDomain, the transportAddress, the wholeMessage, the		transportDomain, the transportAddress, the wholeMessage, the
	skipping to change at page 21, line 31 ¶		skipping to change at page 21, line 24 ¶
	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		address, remote port number, local address and local port number to
	an implementation-dependent tlstmSessionID.		an implementation-dependent tlstmSessionID.
	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.		implementation-dependent manner.
	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 tlstmSessionID.		determine if a session already exists.
	If a matching entry in the LCD does not exist then the message is		If a matching entry in the LCD does not exist then the message is
	passed to DTLS for processing without a corresponding		passed to DTLS for processing without a corresponding
	tlstmSessionID. The incoming packet may result in a new session		tlstmSessionID. The incoming packet may result in a new session
	being established if the receiving entity is acting as a DTLS		being established if the receiving entity is acting as a DTLS
	server. If DTLS returns success then stop processing of this		server. If DTLS returns success then stop processing of this
	message. If DTLS returns an error then increment the		message. If DTLS returns an error then increment the
	snmpTlstmSessionNoSessions counter and stop processing the		snmpTlstmSessionNoSessions counter and stop processing the
	message.		message.
	skipping to change at page 22, line 16 ¶		skipping to change at page 22, line 7 ¶
	4) The UDP packet and the tlstmSessionID are passed to DTLS for		4) The UDP packet and the tlstmSessionID are passed to DTLS for
	integrity checking and decryption.		integrity checking and decryption.
	If the message fails integrity checks or other (D)TLS security		If the message fails integrity checks or other (D)TLS security
	processing then increment the tlstmDTLSProtectionErrors counter,		processing then increment the tlstmDTLSProtectionErrors counter,
	discard and stop processing the message.		discard and stop processing the message.
	5) DTLS should return an incomingMessage and an		5) DTLS should return an incomingMessage and an
	incomingMessageLength. These results and the tlstmSessionID are		incomingMessageLength. These results and the tlstmSessionID are
	used below in the Section 5.1.2 to complete the processing of the		used below in Section 5.1.2 to complete the processing of the
	incoming message.		incoming message.
	5.1.2. Transport Processing for Incoming SNMP Messages		5.1.2. Transport Processing for Incoming SNMP 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. Note that care must be taken when processing		from the (D)TLS stream. Note that care must be taken when processing
	messages originating from either TLS or DTLS to ensure they're		messages originating from either TLS or DTLS to ensure they're
	complete and single. For example, multiple SNMP messages can be		complete and single. For example, multiple SNMP messages can be
	passed through a single DTLS message and partial SNMP messages may be		passed through a single DTLS message and partial SNMP messages may be
	received from a TLS stream. These steps describe the processing of a		received from a TLS stream. These steps describe the processing of a
	singular SNMP message after it has been delivered from the (D)TLS		singular SNMP message after it has been delivered from the (D)TLS
	stream.		stream.
	Create a tmStateReference cache for the subsequent reference and		1) Create a tmStateReference cache for the subsequent reference and
	assign the following values within it:		assign the following values within it:
	tmTransportDomain = snmpTLSTCPDomain, snmpDTLSUDPDomain or		tmTransportDomain = snmpTLSTCPDomain, snmpDTLSUDPDomain or
	snmpDTLSSCTPDomain as appropriate.		snmpDTLSSCTPDomain as appropriate.
	tmTransportAddress = The address the message originated from.		tmTransportAddress = The address the message originated from.
	tmSecurityLevel = The derived tmSecurityLevel for the session, as		tmSecurityLevel = The derived tmSecurityLevel for the session,
	discussed in Section 3.1.2 and Section 5.3.		as 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 Section 5.3. This value MUST be constant during the		discussed in Section 5.3. This value MUST be constant during
	lifetime of the (D)TLS session.		the lifetime of the (D)TLS session.
	tmSessionID = The tlstmSessionID, which MUST be a unique session		tmSessionID = The tlstmSessionID, which MUST be a unique session
	identifier for this (D)TLS connection. The contents and format of		identifier for this (D)TLS connection. The contents and
	this identifier are implementation-dependent as long as it is		format of this identifier are implementation-dependent as long
	unique to the session. A session identifier MUST NOT be reused		as it is unique to the session. A session identifier MUST NOT
	until all references to it are no longer in use. The tmSessionID		be reused until all references to it are no longer in use.
	is equal to the tlstmSessionID discussed in Section 5.1.1.		The tmSessionID is equal to the tlstmSessionID discussed in
	tmSessionID refers to the session identifier when stored in the		Section 5.1.1. tmSessionID refers to the session identifier
	tmStateReference and tlstmSessionID refers to the session		when stored in the tmStateReference and tlstmSessionID refers
	identifier when stored in the LCD. They MUST always be equal when		to the session identifier when stored in the LCD. They MUST
	processing a given session's traffic.		always be equal when processing a given session's traffic.
	The wholeMessage and the wholeMessageLength are assigned values from		2) The incomingMessage and incomingMessageLength are assigned values
	the incomingMessage and incomingMessageLength values from the (D)TLS		from the (D)TLS processing.
	processing.
	The TLS Transport Model passes the transportDomain, transportAddress,		3) The TLS Transport Model passes the transportDomain,
	wholeMessage, and wholeMessageLength to the Dispatcher using the		transportAddress, incomingMessage, and incomingMessageLength to
	receiveMessage ASI:		the Dispatcher using the receiveMessage ASI:
	statusInformation =		statusInformation =
	receiveMessage(		receiveMessage(
	IN transportDomain -- snmpTLSTCPDomain, snmpDTLSUDPDomain,		IN transportDomain -- snmpTLSTCPDomain, 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 incomingMessage -- the whole SNMP message from (D)TLS
	IN wholeMessageLength -- the length of the SNMP message		IN incomingMessageLength -- the length of the SNMP message
	IN tmStateReference -- transport info		IN tmStateReference -- transport info
	)		)
	5.2. Procedures for an Outgoing SNMP Message		5.2. Procedures for an Outgoing SNMP 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(
	skipping to change at page 24, line 43 ¶		skipping to change at page 24, line 32 ¶
	session using the openSession() ASI (discussed further in		session using the openSession() ASI (discussed further in
	Section 5.3). Implementations MAY wish to offer message		Section 5.3). 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, discard the		openSession(), then discard the message, discard the
	tmStateReference, increment the snmpTlstmSessionOpenErrors,		tmStateReference, increment the snmpTlstmSessionOpenErrors,
	return an error indication to the calling module and stop		return an error indication to the calling module and stop
	processing of the message.		processing of the message.
	6) Using either the session indicated by the tmSessionID if there		6) Using either the session indicated by the tmSessionID if there
	was one or the session resulting from a previous step (3 or 4),		was one or the session resulting from a previous step (4 or 5),
	pass the outgoingMessage to (D)TLS for encapsulation and		pass the outgoingMessage to (D)TLS for encapsulation and
	transmission.		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:		a new (D)TLS session:
	statusInformation = -- errorIndication or success		statusInformation = -- errorIndication or success
	openSession(		openSession(
	skipping to change at page 26, line 43 ¶		skipping to change at page 26, line 33 ¶
	b) The (D)TLS client side of the connection MUST verify that the		b) The (D)TLS client side of the connection MUST verify that the
	(D)TLS server's presented certificate is the expected		(D)TLS server's presented certificate is the expected
	certificate. The (D)TLS client MUST NOT transmit SNMP		certificate. The (D)TLS client MUST NOT transmit SNMP
	messages until the server certificate has been authenticated		messages until the server certificate has been authenticated
	and the client certificate has been transmitted.		and the client certificate has been transmitted.
	If the connection is being established from configuration		If the connection is being established from configuration
	based on SNMP-TARGET-MIB configuration then the procedures in		based on SNMP-TARGET-MIB configuration then the procedures in
	the tlstmAddrTable DESCRIPTION clause should be followed to		the tlstmAddrTable DESCRIPTION clause should be followed to
	determine if the presented identity matches the expectations		determine if the presented identity matches the expectations
	of the configuration. Path validation procedures (like those		of the configuration. Validation procedures (like the path
	defined in [RFC5280]) MUST be followed. If a server identity		validation procedures defined in [RFC5280] or through the use
	name has been configured in the tlstmAddrServerIdentity		of fingerprints as defined by the tlstmAddrServerIdentity
	column then this reference identity must be compared against		column) MUST be followed. If a server identity name has been
	the presented identity (for example using procedures		configured in the tlstmAddrServerIdentity column then this
	described in [I-D.saintandre-tls-server-id-check]).		reference identity must be compared against the presented
			identity (for example using procedures described in
			[I-D.saintandre-tls-server-id-check]).
	If the connection is being established for other reasons then		If the connection is being established for other reasons then
	configuration and procedures outside the scope of this		configuration and procedures outside the scope of this
	document should be followed.		document should be followed.
	(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 did not match the		verification or the presented identity did not match the
	expected named entity) then the session establishment MUST		expected named entity) then the session establishment MUST
	fail, the snmpTlstmSessionInvalidServerCertificates object is		fail, the snmpTlstmSessionInvalidServerCertificates object is
	incremented and processing stops.		incremented and processing stops.
	4) The TLSTM-specific session identifier (tlstmSessionID) is set in		4) The TLSTM-specific session identifier (tlstmSessionID) is set in
	the tmSessionID of the tmStateReference passed to the TLS		the tmSessionID of the tmStateReference passed to the TLS
	Transport Model to indicate that the session has been established		Transport Model 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. The tlstmSessionID is also stored in the LCD for later
			lookup during processing of incoming messages (Section 5.1.2).
	Servers that wish to support multiple principals at a particular port		Servers that wish to support multiple principals at a particular port
	SHOULD make use of a (D)TLS extension that allows server-side		SHOULD make use of a (D)TLS extension that allows server-side
	principal selection like the Server Name Indication extension defined		principal selection like the Server Name Indication extension defined
	in Section 3.1 of [RFC4366]. Supporting this will allow, for		in Section 3.1 of [RFC4366]. Supporting this will allow, for
	example, sending notifications to a specific principal at a given		example, sending notifications to a specific principal at a given
	TCP, UDP or SCTP port.		TCP, UDP or SCTP port.
	5.4. Closing a Session		5.4. Closing a Session
	skipping to change at page 28, line 31 ¶		skipping to change at page 28, line 21 ¶
	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 New TransportDomain and TransportAddress formats for describing		o A new TransportAddress format for describing (D)TLS connection
	(D)TLS connection addressing requirements.		addressing requirements.
	o A certificate fingerprint allowing MIB module objects to		o A certificate fingerprint allowing MIB module objects to
	generically refer to a stored X.509 certificate using a		generically refer to a stored X.509 certificate using a
	cryptographic hash as a reference pointer.		cryptographic hash as a reference pointer.
	6.3. Statistical Counters		6.3. Statistical Counters
	The TLSTM-MIB defines some counters that can provide network managers		The TLSTM-MIB defines some counters that can provide network managers
	with information about (D)TLS session usage and potential errors that		with information about (D)TLS session usage and potential errors that
	a MIB-instrumented device may be experiencing.		a MIB-instrumented device may be experiencing.
	skipping to change at page 30, line 6 ¶		skipping to change at page 29, line 44 ¶
	FROM SNMPv2-TC		FROM SNMPv2-TC
	MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-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 "201001080000Z"		LAST-UPDATED "201001270000Z"
	ORGANIZATION "ISMS Working Group"		ORGANIZATION "ISMS Working Group"
	CONTACT-INFO "WG-EMail: isms@lists.ietf.org		CONTACT-INFO "WG-EMail: isms@lists.ietf.org
	Subscribe: isms-request@lists.ietf.org		Subscribe: isms-request@lists.ietf.org
	Chairs:		Chairs:
	Juergen Schoenwaelder		Juergen Schoenwaelder
	Jacobs University Bremen		Jacobs University Bremen
	Campus Ring 1		Campus Ring 1
	28725 Bremen		28725 Bremen
	Germany		Germany
	skipping to change at page 31, line 4 ¶		skipping to change at page 30, line 44 ¶
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this MIB module is part of RFC XXXX;		This version of this MIB module is part of RFC XXXX;
	see the RFC itself for full legal notices."		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 "201001080000Z"
			REVISION "201001270000Z"
	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		-- subtrees of the TLSTM-MIB
	skipping to change at page 32, line 16 ¶		skipping to change at page 32, line 9 ¶
	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 which 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 'dudp' 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 SnmpTLSAddress.		transport address is of type SnmpTLSAddress.
	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 which 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 'dsct' 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 IPv4 address, an IPv6 address or an US-ASCII		"Represents a IPv4 address, an IPv6 address or an US-ASCII
	encoded hostname and port number.		encoded hostname and port number.
	An IPv4 address must be in dotted decimal format followed by a		An IPv4 address must be in dotted decimal format followed by a
	colon ':' (US-ASCII character 0x3A) and a decimal port number		colon ':' (US-ASCII character 0x3A) and a decimal port number
	skipping to change at page 34, line 19 ¶		skipping to change at page 34, line 11 ¶
	encoded is taken from the IANA TLS HashAlgorithm Registry		encoded is taken from the IANA TLS HashAlgorithm Registry
	(RFC5246). The remaining octets are filled using the results		(RFC5246). The remaining octets are filled using the results
	of the hashing algorithm.		of the hashing algorithm.
	This TEXTUAL-CONVENTION allows for a zero-length (blank)		This TEXTUAL-CONVENTION allows for a zero-length (blank)
	Fingerprint value for use in tables where the fingerprint value		Fingerprint value for use in tables where the fingerprint value
	may be optional. MIB definitions or implementations may refuse		may be optional. MIB definitions or implementations may refuse
	to accept a zero-length value as appropriate."		to accept a zero-length value as appropriate."
	REFERENCE		REFERENCE
	"RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2		"RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
			http://www.iana.org/assignments/tls-parameters/
	"		"
	SYNTAX OCTET STRING (SIZE (0..255))		SYNTAX OCTET STRING (SIZE (0..255))
			-- Identities for use in the tlstmCertToTSNTable
	tlstmCertToTSNMIdentities OBJECT IDENTIFIER ::= { tlstmIdentities 1 }		tlstmCertToTSNMIdentities OBJECT IDENTIFIER ::= { tlstmIdentities 1 }
	tlstmCertSpecified OBJECT-IDENTITY		tlstmCertSpecified OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION "Directly specifies the tmSecurityName to be used for		DESCRIPTION "Directly specifies the tmSecurityName to be used for
	this certificate. The value of the tmSecurityName to		this certificate. The value of the tmSecurityName
	use is specified in the tlstmCertToTSNData column.		to use is specified in the tlstmCertToTSNData
	The column must contain a SnmpAdminString compliant		column. The tlstmCertToTSNData column must contain
	value or contains a zero length string then the		a non-zero length SnmpAdminString compliant value or
	mapping will be considered a failure."		the mapping described in this row must be considered
			a failure."
	::= { tlstmCertToTSNMIdentities 1 }		::= { tlstmCertToTSNMIdentities 1 }
	tlstmCertSANRFC822Name OBJECT-IDENTITY		tlstmCertSANRFC822Name OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION "Maps a subjectAltName's rfc822Name to a		DESCRIPTION "Maps a subjectAltName's rfc822Name to a
	tmSecurityName. The local part of the rfc822Name is		tmSecurityName. The local part of the rfc822Name is
	passed unaltered but the host-part of the name must		passed unaltered but the host-part of the name must
	be passed in lower case.		be passed in lower case.
	Example rfc822Name Field: FooBar@Example.COM		Example rfc822Name Field: FooBar@Example.COM
	is mapped to tmSecurityName: FooBar@exmaple.com"		is mapped to tmSecurityName: FooBar@example.com"
	::= { tlstmCertToTSNMIdentities 2 }		::= { tlstmCertToTSNMIdentities 2 }
	tlstmCertSANDNSName OBJECT-IDENTITY		tlstmCertSANDNSName OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION "Maps a subjectAltName's dNSName to a		DESCRIPTION "Maps a subjectAltName's dNSName to a
	tmSecurityName by directly passing the value without		tmSecurityName by directly passing the value without
	any transformations."		any transformations."
	::= { tlstmCertToTSNMIdentities 3 }		::= { tlstmCertToTSNMIdentities 3 }
	tlstmCertSANIpAddress OBJECT-IDENTITY		tlstmCertSANIpAddress OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION "Maps a subjectAltName's ipAddress to a		DESCRIPTION "Maps a subjectAltName's iPAddress to a
	tmSecurityName by transforming the binary encoded		tmSecurityName by transforming the binary encoded
	address as follows:		address as follows:
	1) for IPv4 the value is converted into a decimal		1) for IPv4 the value is converted into a decimal
	dotted quad address (e.g. '192.0.2.1')		dotted 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.
	skipping to change at page 35, line 40 ¶		skipping to change at page 35, line 32 ¶
	tlstmCertSANAny OBJECT-IDENTITY		tlstmCertSANAny OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION "Maps any of the following fields using the		DESCRIPTION "Maps any of the following fields using the
	corresponding mapping algorithms:		corresponding mapping algorithms:
	|------------+------------------------|		|------------+------------------------|
	| Type | Algorithm |		| Type | Algorithm |
	|------------+------------------------|		|------------+------------------------|
	| rfc822Name | tlstmCertSANRFC822Name |		| rfc822Name | tlstmCertSANRFC822Name |
	| dNSName | tlstmCertSANDNSName |		| dNSName | tlstmCertSANDNSName |
	| ipAddress | tlstmCertSANIpAddress |		| iPAddress | tlstmCertSANIpAddress |
	|------------+------------------------|		|------------+------------------------|
	The first matching subjectAltName value found in the		The first matching subjectAltName value found in the
	certificate any of the above types MUST be used when		certificate of the above types MUST be used when
	deriving the tmSecurityName."		deriving the tmSecurityName."
	::= { tlstmCertToTSNMIdentities 5 }		::= { tlstmCertToTSNMIdentities 5 }
	tlstmCertCommonName OBJECT-IDENTITY		tlstmCertCommonName OBJECT-IDENTITY
	STATUS current		STATUS current
	DESCRIPTION "Maps a certificate's CommonName to a		DESCRIPTION "Maps a certificate's CommonName to a
	tmSecurityName by directly passing the value without		tmSecurityName by directly passing the value without
	any transformations."		any transformations."
	::= { tlstmCertToTSNMIdentities 6 }		::= { tlstmCertToTSNMIdentities 6 }
	skipping to change at page 37, line 22 ¶		skipping to change at page 37, line 13 ¶
	snmpTlstmSessionUnknownServerCertificate OBJECT-TYPE		snmpTlstmSessionUnknownServerCertificate 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 outgoing session was not established		"The number of times an outgoing session was not established
	on an (D)TLS client because the server certificate presented		on an (D)TLS client because the server certificate presented
	by a SNMP over (D)TLS server was invalid because no		by a SNMP over (D)TLS server was invalid because no
	configured fingerprint or CA was acceptable to validate it.		configured fingerprint or CA was acceptable to validate it.
	This may result because there was no entry in the		This may result because there was no entry in the
	tlstmAddrTable or because no path could be found to known		tlstmAddrTable or because no path could be found to a known
	certificate authority."		certificate authority."
	::= { snmpTlstmSession 6 }		::= { snmpTlstmSession 6 }
	snmpTlstmSessionInvalidServerCertificates OBJECT-TYPE		snmpTlstmSessionInvalidServerCertificates 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 outgoing session was not established		"The number of times an outgoing session was not established
	on an (D)TLS client because the server certificate presented		on an (D)TLS client because the server certificate presented
	by an SNMP over (D)TLS server could not be validated even if		by an SNMP over (D)TLS server could not be validated even if
	the fingerprint or expected validation path was known. I.E.,		the fingerprint or expected validation path was known. I.E.,
	a cryptographic validation occurred during certificate		a cryptographic validation error occurred during certificate
	validation processing.		validation processing.
	Reasons for invalidation include, but are not		Reasons for invalidation include, but are not
	limited to, cryptographic validation failures."		limited to, cryptographic validation failures."
	::= { snmpTlstmSession 7 }		::= { snmpTlstmSession 7 }
	snmpTlstmSessionInvalidCaches OBJECT-TYPE		snmpTlstmSessionInvalidCaches OBJECT-TYPE
	SYNTAX Counter32		SYNTAX Counter32
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The number of outgoing messages dropped because the		"The number of outgoing messages dropped because the
	tmStateReference referred to an invalid cache."		tmStateReference referred to an invalid cache."
	::= { snmpTlstmSession 8 }		::= { snmpTlstmSession 8 }
	tlstmTLSProtectionErrors OBJECT-TYPE		snmpTlstmTLSProtectionErrors OBJECT-TYPE
	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."
	::= { snmpTlstmSession 9 }		::= { snmpTlstmSession 9 }
	-- Configuration Objects		-- Configuration Objects
	skipping to change at page 38, line 44 ¶		skipping to change at page 38, line 36 ¶
	"The value of sysUpTime.0 when the tlstmCertToTSNTable		"The value of sysUpTime.0 when the tlstmCertToTSNTable
	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."
	::= { tlstmCertificateMapping 2 }		::= { tlstmCertificateMapping 2 }
	tlstmCertToTSNTable OBJECT-TYPE		tlstmCertToTSNTable OBJECT-TYPE
	SYNTAX SEQUENCE OF TlstmCertToTSNEntry		SYNTAX SEQUENCE OF TlstmCertToTSNEntry
	MAX-ACCESS not-accessible		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A table listing the X.509 certificates known to the entity		"A table listing the fingerprints of X.509 certificates known
	and the associated method for determining the SNMPv3 security		to the entity and the associated method for determining the
	name from a certificate.		SNMPv3 security 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 tmSecurityName.		mapping from a validated certificate to a tmSecurityName.
	This table does not provide any mechanisms for uploading		This table does not provide any mechanisms for uploading
	trusted certificates; 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.
	skipping to change at page 39, line 25 ¶		skipping to change at page 39, line 15 ¶
	order according to its tlstmCertToTSNID value. Each row's		order according to its tlstmCertToTSNID value. Each row's
	tlstmCertToTSNFingerprint value determines whether the row is a		tlstmCertToTSNFingerprint value determines whether the row is a
	match for the incoming connection:		match for the incoming connection:
	1) If the row's tlstmCertToTSNFingerprint value identifies		1) If the row's tlstmCertToTSNFingerprint value identifies
	the presented certificate then consider the row as a		the presented certificate then consider the row as a
	successful match.		successful match.
	2) If the row's tlstmCertToTSNFingerprint value identifies		2) If the row's tlstmCertToTSNFingerprint value identifies
	a locally held copy of a trusted CA certificate and		a locally held copy of a trusted CA certificate and
	that CA certificated was used to validate the path to		that CA certificate was used to validate the path to
	the presented certificate then consider the row as a		the presented certificate then consider the row as a
	successful match.		successful match.
	Once a matching row has been found, the tlstmCertToTSNMapType		Once a matching row has been found, the tlstmCertToTSNMapType
	value can be used to determine how the tmSecurityName to		value can be used to determine how the tmSecurityName to
	associate with the session should be determined. See the		associate with the session should be determined. See the
	tlstmCertToTSNMapType column's DESCRIPTION for details on		tlstmCertToTSNMapType column's DESCRIPTION for details on
	determining the tmSecurityName value. If it is impossible to		determining the tmSecurityName value. If it is impossible to
	determine a tmSecurityName from the row's data combined with the		determine a tmSecurityName from the row's data combined with the
	data presented in the certificate then additional rows MUST be		data presented in the certificate then additional rows MUST be
	skipping to change at page 40, line 4 ¶		skipping to change at page 39, line 42 ¶
	another potential match.		another potential match.
	Missing values of tlstmCertToTSNID are acceptable and		Missing values of tlstmCertToTSNID 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
	tlstmCertToTSNID values of 10 and 20.		tlstmCertToTSNID 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 tmSecurityNames so		subjectAltName fields that can be used as tmSecurityNames 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 tmSecurityName		certificate's subjectAltName to map directly to a
	via a 1:1 transformation. However, this table is flexible to		tmSecurityName via a 1:1 transformation. However, this table
	allow for situations where existing deployed certificate		is flexible to allow for situations where existing deployed
	infrastructures do not provide adequate subjectAltName values		certificate infrastructures do not provide adequate
	for use as tmSecurityNames. Certificates may also be		subjectAltName values for use as tmSecurityNames.
	mapped to tmSecurityNames using the CommonName portion of the		Certificates may also be mapped to tmSecurityNames using the
	Subject field but usage of the CommonName field is deprecated.		CommonName portion of the Subject field. However, the usage
	Direct mapping from each individual certificate fingerprint to		of the CommonName field is deprecated and thus this usage is
	a tmSecurityName is also possible but requires one entry in the		NOT RECOMMENDED. Direct mapping from each individual
	table per tmSecurityName and requires more management operations		certificate fingerprint to a tmSecurityName is also possible
	to completely configure a device."		but requires one entry in the table per tmSecurityName and
			requires more management operations to completely configure a
			device."
	::= { tlstmCertificateMapping 3 }		::= { tlstmCertificateMapping 3 }
	tlstmCertToTSNEntry OBJECT-TYPE		tlstmCertToTSNEntry OBJECT-TYPE
	SYNTAX TlstmCertToTSNEntry		SYNTAX TlstmCertToTSNEntry
	MAX-ACCESS not-accessible		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A row in the tlstmCertToTSNTable that specifies a mapping for		"A row in the tlstmCertToTSNTable that specifies a mapping for
	an incoming (D)TLS certificate to a tmSecurityName to use for a		an incoming (D)TLS certificate to a tmSecurityName to use for a
	connection."		connection."
	skipping to change at page 40, line 42 ¶		skipping to change at page 40, line 34 ¶
	tlstmCertToTSNData OCTET STRING,		tlstmCertToTSNData OCTET STRING,
	tlstmCertToTSNStorageType StorageType,		tlstmCertToTSNStorageType StorageType,
	tlstmCertToTSNRowStatus RowStatus		tlstmCertToTSNRowStatus RowStatus
	}		}
	tlstmCertToTSNID OBJECT-TYPE		tlstmCertToTSNID OBJECT-TYPE
	SYNTAX Unsigned32 (1..4294967295)		SYNTAX Unsigned32 (1..4294967295)
	MAX-ACCESS not-accessible		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A unique, prioritized index for the given entry."		"A unique, prioritized index for the given entry. Lower
			numbers indicate a higher priority."
	::= { tlstmCertToTSNEntry 1 }		::= { tlstmCertToTSNEntry 1 }
	tlstmCertToTSNFingerprint OBJECT-TYPE		tlstmCertToTSNFingerprint OBJECT-TYPE
	SYNTAX Fingerprint (SIZE(1..255))		SYNTAX Fingerprint (SIZE(1..255))
	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 to either the trusted CA in		a successful matching fingerprint to either the trusted CA in
	the certificate validation path or to the certificate itself		the certificate validation path or to the certificate itself
	skipping to change at page 41, line 34 ¶		skipping to change at page 41, line 27 ¶
	searched for additional tlstmCertToTSNFingerprint matches to		searched for additional tlstmCertToTSNFingerprint matches to
	look for a mapping that succeeds."		look for a mapping that succeeds."
	DEFVAL { tlstmCertSpecified }		DEFVAL { tlstmCertSpecified }
	::= { tlstmCertToTSNEntry 3 }		::= { tlstmCertToTSNEntry 3 }
	tlstmCertToTSNData OBJECT-TYPE		tlstmCertToTSNData OBJECT-TYPE
	SYNTAX OCTET STRING (SIZE(0..1024))		SYNTAX OCTET STRING (SIZE(0..1024))
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Axillary data used as optional configuration information for		"Auxiliary data used as optional configuration information for
	a given mapping specified by the tlstmCertToTSNMapType column.		a given mapping specified by the tlstmCertToTSNMapType column.
	Only some mapping systems will make use of this column. The		Only some mapping systems will make use of this column. The
	value in this column MUST be ignored for any mapping type that		value in this column MUST be ignored for any mapping type that
	does not require data present in this column."		does not require data present in this column."
	DEFVAL { "" }		DEFVAL { "" }
	::= { tlstmCertToTSNEntry 4 }		::= { tlstmCertToTSNEntry 4 }
	tlstmCertToTSNStorageType OBJECT-TYPE		tlstmCertToTSNStorageType OBJECT-TYPE
	SYNTAX StorageType		SYNTAX StorageType
	MAX-ACCESS read-create		MAX-ACCESS read-create
	skipping to change at page 43, line 4 ¶		skipping to change at page 42, line 46 ¶
	::= { tlstmCertificateMapping 4 }		::= { tlstmCertificateMapping 4 }
	tlstmParamsTableLastChanged OBJECT-TYPE		tlstmParamsTableLastChanged 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 tlstmParamsTable		"The value of sysUpTime.0 when the tlstmParamsTable
	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."
	::= { tlstmCertificateMapping 5 }		::= { tlstmCertificateMapping 5 }
	tlstmParamsTable OBJECT-TYPE		tlstmParamsTable OBJECT-TYPE
	SYNTAX SEQUENCE OF TlstmParamsEntry		SYNTAX SEQUENCE OF TlstmParamsEntry
	MAX-ACCESS not-accessible		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"This table extends the SNMP-TARGET-MIB's		"This table is used by a (D)TLS client when a (D)TLS session is
	snmpTargetParamsTable with an additional (D)TLS client-side		being set up using an entry in the SNMP-TARGET-MIB. It
	certificate fingerprint identifier to use when establishing		extends the SNMP-TARGET-MIB's snmpTargetParamsTable with a
	new (D)TLS connections."		fingerprint of a certificate to use when establishing such a
			(D)TLS connection."
	::= { 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 fingerprint hash of a locally		"A conceptual row containing a fingerprint hash of a locally
	held certificate 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
	skipping to change at page 44, line 43 ¶		skipping to change at page 44, line 37 ¶
	been set.		been set.
	The tlstmParamsClientFingerprint object may not be modified		The tlstmParamsClientFingerprint object may not be modified
	while the value of this object is active(1).		while the value of this object is active(1).
	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."
	::= { tlstmParamsEntry 3 }		::= { tlstmParamsEntry 3 }
	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"
	::= { tlstmCertificateMapping 7 }		::= { tlstmCertificateMapping 7 }
	tlstmAddrTableLastChanged OBJECT-TYPE		tlstmAddrTableLastChanged 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 tlstmAddrTable		"The value of sysUpTime.0 when the tlstmAddrTable
	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."
	::= { tlstmCertificateMapping 8 }		::= { tlstmCertificateMapping 8 }
	tlstmAddrTable OBJECT-TYPE		tlstmAddrTable OBJECT-TYPE
	SYNTAX SEQUENCE OF TlstmAddrEntry		SYNTAX SEQUENCE OF TlstmAddrEntry
	MAX-ACCESS not-accessible		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"This table extends the SNMP-TARGET-MIB's snmpTargetAddrTable		"This table is used by a (D)TLS client when a (D)TLS session
	with an expected (D)TLS server-side certificate identifier to		is being set up using an entry in the SNMP-TARGET-MIB. It
	expect when establishing a new (D)TLS connections. If a		extends the SNMP-TARGET-MIB's snmpTargetAddrTable so that the
	matching row in this table exists and the row is active then		client can validate the certificate that the server presents.
	the fingerprint identifier from the tlstmAddrServerFingerprint
	columnshould be compared against the fingerprint of the
	certificate being presented by the server. If the fingerprint
	of the certificate presented by the server does not match the
	tlstmAddrServerFingerprint column's value then the connection
	MUST NOT be established.
	If a matching row exists with a zero-length		If there is a row in this table corresponding to the entry in
	tlstmAddrServerFingerprint value and the certificate can still		the SNMP-TARGET-MIB that was used to establish the session
	be validated through another certificate validation path		(and that row is active), then the fingerprint of the server's
	(e.g. RFC5280) then the server's presented identity should be		presented certificate is compared with the value of the
	checked against the value of the tlstmAddrServerIdentity		tlstmAddrServerFingerprint column. If fingerprint does not
	column. If the server's identity does not match the reference		match, then the connection MUST NOT be established.
	identity found in the tlstmAddrServerIdentity column then the
	connection MUST NOT be established. A tlstmAddrServerIdentity
	may contain a '*' to match any server's identity or may
	contain a '*.' prefix to match any server identity from a
	given domain (e.g. '*.example.com').
	If no matching row exists in this table then the connection		If the row exists with a zero-length
	SHOULD still proceed if another certificate validation path		tlstmAddrServerFingerprint value and the certificate can be
	algorithm (e.g. RFC5280) can be followed to a configured trust		validated through another certificate validation path (such as
	anchor."		the path validation procedures defined in [RFC5280]) then the
			server's presented identity should be checked against the
			value of the tlstmAddrServerIdentity column. If the server's
			identity does not match the reference identity found in the
			tlstmAddrServerIdentity column then the connection MUST NOT be
			established.
			A tlstmAddrServerIdentity may contain a single ASCII '*'
			character (ASCII code 0x2a) to match any server's identity if
			the tlstmAddrServerFingerprint column is not blank. A row
			MUST NOT contain both a blank tlstmAddrServerFingerprint
			column and a '*' in the tlstmAddrServerIdentity column since
			this would insecurely accept any presented certificate.
			If there is no row in this table corresponding to an entry in
			the SNMP-TARGET-MIB and another certificate validation path
			algorithm (such as the path validation procedures defined in
			[RFC5280]) can be used, then the connection SHOULD still
			proceed."
	::= { 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 certificate's		"A conceptual row containing a copy of a certificate's
	fingerprint for a given snmpTargetAddrEntry. The values in		fingerprint for a given snmpTargetAddrEntry. The values in
	this row should be ignored if the connection that needs to be		this row should be ignored if the connection that needs to be
	established, as indicated by the SNMP-TARGET-MIB		established, as indicated by the SNMP-TARGET-MIB
	infrastructure, is not a (D)TLS based connection. If an		infrastructure, is not a (D)TLS based connection. If an
	tlstmAddrEntry exists for a given snmpTargetAddrEntry then the		tlstmAddrEntry exists for a given snmpTargetAddrEntry then the
	presented server certificate MUST match or the connection MUST		presented server certificate MUST match or the connection MUST
	NOT be established. If a row in this table does not exist to		NOT be established. If a row in this table does not exist to
	match a snmpTargetAddrEntry row then the connection SHOULD		match a snmpTargetAddrEntry row then the connection SHOULD
	still proceed if some other certificate validation path		still proceed if some other certificate validation path
	algorithm (e.g. RFC5280) can be followed to a configured trust		algorithm (e.g. RFC5280) can be used."
	anchor."
	INDEX { IMPLIED snmpTargetAddrName }		INDEX { IMPLIED snmpTargetAddrName }
	::= { tlstmAddrTable 1 }		::= { tlstmAddrTable 1 }
	TlstmAddrEntry ::= SEQUENCE {		TlstmAddrEntry ::= SEQUENCE {
	tlstmAddrServerFingerprint Fingerprint,		tlstmAddrServerFingerprint Fingerprint,
	tlstmAddrServerIdentity SnmpAdminString,		tlstmAddrServerIdentity SnmpAdminString,
	tlstmAddrStorageType StorageType,		tlstmAddrStorageType StorageType,
	tlstmAddrRowStatus RowStatus		tlstmAddrRowStatus RowStatus
	}		}
	skipping to change at page 46, line 51 ¶		skipping to change at page 46, line 49 ¶
	::= { tlstmAddrEntry 1 }		::= { tlstmAddrEntry 1 }
	tlstmAddrServerIdentity OBJECT-TYPE		tlstmAddrServerIdentity OBJECT-TYPE
	SYNTAX SnmpAdminString		SYNTAX SnmpAdminString
	MAX-ACCESS read-create		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The reference identity to check against the identity		"The reference identity to check against the identity
	presented by the remote system. A single ASCII '*' character		presented by the remote system. A single ASCII '*' character
	(ASCII code 0x2a) may be used as a wildcard string and will		(ASCII code 0x2a) may be used as a wildcard string and will
	match any presented server identity. A '*.' prefix may also		match any presented server identity."
	be used to match any identity within a given domain
	(e.g. '*.example.com' will match both 'foo.example.com' and
	'bar.example.com')."
	REFERENCE "draft-saintandre-tls-server-id-check"		REFERENCE "draft-saintandre-tls-server-id-check"
	DEFVAL { "*" }		DEFVAL { "*" }
	::= { tlstmAddrEntry 2 }		::= { tlstmAddrEntry 2 }
	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
	skipping to change at page 47, line 43 ¶		skipping to change at page 47, line 38 ¶
	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 tlstmAddrServerFingerprint column has been		the corresponding tlstmAddrServerFingerprint column has been
	set.		set.
			Rows MUST NOT be active if the tlstmAddrServerFingerprint
			column is blank and the tlstmAddrServerIdentity is set to '*'
			since this would insecurely accept any presented certificate.
	The tlstmAddrServerFingerprint object may not be modified		The tlstmAddrServerFingerprint object may not be modified
	while the value of this object is active(1).		while the value of this object is active(1).
	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."
	::= { tlstmAddrEntry 4 }		::= { tlstmAddrEntry 4 }
	-- ************************************************		-- ************************************************
	-- tlstmNotifications - Notifications Information		-- tlstmNotifications - Notifications Information
	-- ************************************************		-- ************************************************
	tlstmServerCertificateUnknown NOTIFICATION-TYPE		tlstmServerCertificateUnknown NOTIFICATION-TYPE
	OBJECTS { snmpTlstmSessionUnknownServerCertificate }		OBJECTS { snmpTlstmSessionUnknownServerCertificate }
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"Notification that the server certificate presented by a SNMP		"Notification that the server certificate presented by a SNMP
	over (D)TLS server was invalid because no configured		over (D)TLS server was invalid because no configured
	fingerprint or CA was acceptable to validate it. This may		fingerprint or CA was acceptable to validate it. This may
	result because there was no entry in the tlstmAddrTable or		be because there was no entry in the tlstmAddrTable or
	because no path could be found to known certificate		because no path could be found to known certificate
	authority.		authority.
	To avoid notification loops, this notification MUST NOT be		To avoid notification loops, this notification MUST NOT be
	sent to servers that themselves have triggered the		sent to servers that themselves have triggered the
	notification."		notification."
	::= { tlstmNotifications 1 }		::= { tlstmNotifications 1 }
	tlstmServerInvalidCertificate NOTIFICATION-TYPE		tlstmServerInvalidCertificate NOTIFICATION-TYPE
	OBJECTS { tlstmAddrServerFingerprint,		OBJECTS { tlstmAddrServerFingerprint,
	skipping to change at page 49, line 31 ¶		skipping to change at page 49, line 31 ¶
	tlstmStatsGroup OBJECT-GROUP		tlstmStatsGroup OBJECT-GROUP
	OBJECTS {		OBJECTS {
	snmpTlstmSessionOpens,		snmpTlstmSessionOpens,
	snmpTlstmSessionCloses,		snmpTlstmSessionCloses,
	snmpTlstmSessionOpenErrors,		snmpTlstmSessionOpenErrors,
	snmpTlstmSessionNoSessions,		snmpTlstmSessionNoSessions,
	snmpTlstmSessionInvalidClientCertificates,		snmpTlstmSessionInvalidClientCertificates,
	snmpTlstmSessionUnknownServerCertificate,		snmpTlstmSessionUnknownServerCertificate,
	snmpTlstmSessionInvalidServerCertificates,		snmpTlstmSessionInvalidServerCertificates,
	snmpTlstmSessionInvalidCaches,		snmpTlstmSessionInvalidCaches,
	tlstmTLSProtectionErrors		snmpTlstmTLSProtectionErrors
	}		}
	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 {
	skipping to change at page 52, line 43 ¶		skipping to change at page 52, line 43 ¶
	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 this		exchange is utilized for all handshakes. It is also RECOMMENDED by
	specification also RECOMMENDEDs that implementers also support this		this specification that users enable this cookie exchange.
	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
	installation and configuration mechanism. Implementations SHOULD		installation and configuration mechanism. Implementations SHOULD
	support certificate revocation lists.		support certificate revocation lists.
	(D)TLS provides for authentication of the identity of both the (D)TLS		(D)TLS provides for authentication of the identity of both the (D)TLS
	server and the (D)TLS client. Access to MIB objects for the		server and the (D)TLS client. Access to MIB objects for the
	authenticated principal MUST be enforced by an access control		authenticated principal MUST be enforced by an access control
	skipping to change at page 57, line 10 ¶		skipping to change at page 57, line 10 ¶
	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
	[RFC5292].		[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 (in alphabetical order): Andy Donati, Pasi Eronen,		useful comments (in alphabetical order): Andy Donati, Pasi Eronen,
	David Harrington, Jeffrey Hutzelman, Alan Luchuk, Tom Petch, Randy		David Harrington, Jeffrey Hutzelman, Alan Luchuk, Tom Petch, Randy
	Presuhn, Ray Purvis, Joseph Salowey, Jurgen Schonwalder, Dave Shield.		Presuhn, Ray Purvis, Joseph Salowey, Jurgen Schonwalder, Dave Shield,
			Robert Story.
	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 62, line 34 ¶		skipping to change at page 62, line 34 ¶
	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
	digest of the received certificate with a digest of the		digest of the received certificate with a digest of the
	tbsCertificate field. If they match, then the subject in the		tbsCertificate field. If they match, then the subject in the
	tbsCertificate field is authenticated.		tbsCertificate field is authenticated.
	Appendix C. Target and Notificaton Configuration Example		Appendix C. Target and Notification Configuration Example
	Configuring the SNMP-TARGET-MIB and NOTIFICATION-MIB along with		Configuring the SNMP-TARGET-MIB and NOTIFICATION-MIB along with
	access control settings for the SNMP-VIEW-BASED-ACM-MIB can be a		access control settings for the SNMP-VIEW-BASED-ACM-MIB can be a
	daunting task without an example to follow. The following section		daunting task without an example to follow. The following section
	describes an example of what pieces must be in place to accomplish		describes an example of what pieces must be in place to accomplish
	this configuration.		this configuration.
	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:
	skipping to change at page 63, line 22 ¶		skipping to change at page 63, line 22 ¶
	vacmSecurityToGroupStatus = 4 (createAndGo)		vacmSecurityToGroupStatus = 4 (createAndGo)
	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		C.1. Configuring the Notification Originator
	For notification generators performing authorization checks, the		For notification originators 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 expected		certificate before proceeding to send the notification. The expected
	certificate from the server may be listed in the tlstmAddrTable or		certificate from the server may be listed in the tlstmAddrTable or
	may be determined through other X.509 path validation mechanisms.		may be determined through other X.509 path validation mechanisms.
	The securityName to use for VACM authorization checks is set by the		The securityName to use for VACM authorization checks is set by the
	SNMP-TARGET-MIB's snmpTargetParamsSecurityName column.		SNMP-TARGET-MIB's snmpTargetParamsSecurityName column.
	The certificate that the notification generator should present to the		The certificate that the notification originator should present to
	server is taken from the tlstmParamsClientFingerprint column from the		the server is taken from the tlstmParamsClientFingerprint column from
	appropriate entry in the tlstmParamsTable table.		the appropriate entry in the tlstmParamsTable table.
	C.2. Configuring the Command Responder		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 derived from an incoming (D)TLS session. The		value is a value that derived from an incoming (D)TLS session. The
	mapping from a recevied (D)TLS client certificate to a tmSecurityName		mapping from a recevied (D)TLS client certificate to a tmSecurityName
	is done with the tlstmCertToTSNTable. The certificates must be		is done with the tlstmCertToTSNTable. The certificates must be
	loaded into the device so that a tlstmCertToTSNEntry may refer to it.		loaded into the device so that a tlstmCertToTSNEntry may refer to it.
	As an example, consider the following entry which will provide a		As an example, consider the following entry which will provide a
	mapping from a client's public X.509's hash fingerprint directly to		mapping from a client's public X.509's hash fingerprint directly to
End of changes. 91 change blocks.
	226 lines changed or deleted		231 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/