< draft-hardaker-isms-dtls-tm-00.txt		draft-hardaker-isms-dtls-tm-01.txt >
	ISMS W. Hardaker		ISMS W. Hardaker
	Internet-Draft Sparta, Inc.		Internet-Draft Sparta, Inc.
	Intended status: Informational July 7, 2008		Intended status: Informational November 3, 2008
	Expires: January 8, 2009		Expires: May 7, 2009
	Datagram Transport Layer Security Transport Model for SNMP		Datagram Transport Layer Security Transport Model for SNMP
	draft-hardaker-isms-dtls-tm-00.txt		draft-hardaker-isms-dtls-tm-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 January 8, 2009.		This Internet-Draft will expire on May 7, 2009.
	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 the Datagram Transport Layer		Management Protocol (SNMP), that uses the Datagram Transport Layer
	Security (DTLS) protocol. The DTLS protocol provides authentication		Security (DTLS) protocol. The DTLS protocol provides authentication
	and privacy services for SNMP applications. This document describes		and privacy services for SNMP applications. This document describes
	how the DTLS Transport Model (DTLSTM) implements the needed features		how the DTLS Transport Model (DTLSTM) implements the needed features
	of a SNMP Transport Subsystem to make this protection possible in an		of a SNMP Transport Subsystem to make this protection possible in an
	interoperable way.		interoperable way.
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 6		1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 6
	1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6		1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
	2. The Datagram Transport Layer Security Protocol . . . . . . . . 6		2. The Datagram Transport Layer Security Protocol . . . . . . . . 6
	2.1. The DTLS Record Protocol . . . . . . . . . . . . . . . . . 7		2.1. The DTLS Record Protocol . . . . . . . . . . . . . . . . . 7
	2.2. The DTLS Handshake Protocol . . . . . . . . . . . . . . . 7		2.2. The DTLS Handshake Protocol . . . . . . . . . . . . . . . 7
	3. How the DTLSTM fits into the Transport Subsystem . . . . . . . 8		3. How the DTLSTM 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. Security Level . . . . . . . . . . . . . . . . . . . . 12		3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12
	3.1.3. DTLS Sessions . . . . . . . . . . . . . . . . . . . . 13		3.1.3. DTLS Sessions . . . . . . . . . . . . . . . . . . . . 13
	3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 14		3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 14
	3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14		3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14
	4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15		4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15
	4.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 15		4.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 15
	4.1.1. The Certificate Infrastructure . . . . . . . . . . . . 15		4.1.1. The Certificate Infrastructure . . . . . . . . . . . . 15
	4.1.2. Provisioning for the Certificate . . . . . . . . . . . 16		4.1.2. Provisioning for the Certificate . . . . . . . . . . . 16
	4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 17		4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.3. tmStateReference Cache . . . . . . . . . . . . . . . . . . 17		4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 17
	4.3.1. tmTransportDomain and tmTransportAddress . . . . . . . 18		4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 18
	4.3.2. tmRequestedSecurityLevel . . . . . . . . . . . . . . . 18		4.3.2. SNMP Services for an Incoming Message . . . . . . . . 18
	4.3.3. tmSecurityLevel . . . . . . . . . . . . . . . . . . . 18		4.4. DTLS Services . . . . . . . . . . . . . . . . . . . . . . 19
	4.3.4. tmSecurityName . . . . . . . . . . . . . . . . . . . . 18		4.4.1. Services for Establishing a Session . . . . . . . . . 19
	4.4. Transport Model LCD . . . . . . . . . . . . . . . . . . . 19		4.4.2. DTLS Services for an Incoming Message . . . . . . . . 21
	4.5. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 19		4.4.3. DTLS Services for an Outgoing Message . . . . . . . . 22
	4.5.1. SNMP Services for an Outgoing Message . . . . . . . . 19		4.5. Cached Information and References . . . . . . . . . . . . 22
	4.5.2. SNMP Services for an Incoming Message . . . . . . . . 20		4.5.1. securityStateReference . . . . . . . . . . . . . . . . 23
	4.6. DTLS Services . . . . . . . . . . . . . . . . . . . . . . 21		4.5.2. tmStateReference . . . . . . . . . . . . . . . . . . . 23
	4.6.1. Services for Establishing a Session . . . . . . . . . 21		4.5.2.1. Transport information . . . . . . . . . . . . . . 24
	4.6.2. DTLS Services for an Incoming Message . . . . . . . . 22		4.5.2.2. securityName . . . . . . . . . . . . . . . . . . . 24
	4.6.3. DTLS Services for an Outgoing Message . . . . . . . . 23		4.5.2.3. securityLevel . . . . . . . . . . . . . . . . . . 25
	5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 24		4.5.2.4. Session Information . . . . . . . . . . . . . . . 25
	5.1. Receiving an Incoming Message . . . . . . . . . . . . . . 24		4.5.3. DTLS Transport Model Cached Information . . . . . . . 26
	5.2. Sending an Outgoing Message . . . . . . . . . . . . . . . 25		4.5.3.1. Transport Information . . . . . . . . . . . . . . 26
	5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 26		4.5.3.2. tmRequestedSecurityLevel . . . . . . . . . . . . . 26
	5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 28		4.5.3.3. tmSecurityLevel . . . . . . . . . . . . . . . . . 27
	6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 28		4.5.3.4. tmSecurityName . . . . . . . . . . . . . . . . . . 27
	6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28		4.5.4. Transport Model LCD . . . . . . . . . . . . . . . . . 27
	6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 29		5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 27
	6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 29		5.1. Procedures for an Incoming Message . . . . . . . . . . . . 28
	6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 29		5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 28
	6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29		5.1.2. Transport Processing for Incoming Messages . . . . . . 29
	6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29		5.2. Procedures for an Outgoing Message . . . . . . . . . . . . 30
	7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29		5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 32
	8. Operational Considerations . . . . . . . . . . . . . . . . . . 40		5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 34
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 41		6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 34
	9.1. Certificates, Authentication, and Authorization . . . . . 41		6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 35
	9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 42		6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 35
	9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 42		6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 35
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 35
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43		6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 35
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43		6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 35
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 43		7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 36
	12.2. Informative References . . . . . . . . . . . . . . . . . . 45		8. Operational Considerations . . . . . . . . . . . . . . . . . . 47
	Appendix A. Target and Notificaton Configuration Example . . . . 45		8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 47
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47		8.2. Notification Receiver Credential Selection . . . . . . . . 48
	Intellectual Property and Copyright Statements . . . . . . . . . . 48		8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 48
			9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
			9.1. Certificates, Authentication, and Authorization . . . . . 49
			9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 49
			9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 50
			10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
			11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
			12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
			12.2. Informative References . . . . . . . . . . . . . . . . . . 53
			Appendix A. Target and Notificaton Configuration Example . . . . 53
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55
			Intellectual Property and Copyright Statements . . . . . . . . . . 56
	1. Introduction		1. Introduction
	It is important to understand the SNMPv3 architecture [RFC3411], as		It is important to understand the SNMPv3 architecture [RFC3411], as
	enhanced by the Transport Subsystem [I-D.ietf-isms-tmsm]. It is also		enhanced by the Transport Subsystem [I-D.ietf-isms-tmsm]. It is also
	important to understand the terminology of the SNMPv3 architecture in		important to understand the terminology of the SNMPv3 architecture in
	order to understand where the Transport Model described in this		order to understand where the Transport Model described in this
	document fits into the architecture and how it interacts with the		document fits into the architecture and how it interacts with the
	other architecture subsystems. For a detailed overview of the		other architecture subsystems. For a detailed overview of the
	documents that describe the current Internet-Standard Management		documents that describe the current Internet-Standard Management
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 25 ¶
	client, and total anonymity. For authentication of both entities,		client, and total anonymity. For authentication of both entities,
	each entity provides a valid certificate chain leading to an		each entity provides a valid certificate chain leading to an
	acceptable certificate authority. Each entity is responsible for		acceptable certificate authority. Each entity is responsible for
	verifying that the other's certificate is valid and has not expired		verifying that the other's certificate is valid and has not expired
	or been revoked. The DTLS Transport Model SHOULD always use		or been revoked. The DTLS Transport Model SHOULD always use
	authentication of both the server and the client. At a minimum the		authentication of both the server and the client. At a minimum the
	DTLS Transport MUST support authentication of the Command Generator		DTLS Transport MUST support authentication of the Command Generator
	principals to guarantee the authenticity of the securityName (a		principals to guarantee the authenticity of the securityName (a
	parameter used to pass the authenticated identity name from the		parameter used to pass the authenticated identity name from the
	transport model to security model for even later use by the access		transport model to security model for even later use by the access
	control subsystem. See Section 4.3.4). The DTLS Transport SHOULD		control subsystem. See Section 4.5.3.4). The DTLS Transport SHOULD
	support the message encryption to protect sensitive data from		support the message encryption to protect sensitive data from
	eavesdropping attacks.		eavesdropping attacks. See [I-D.hodges-server-ident-check] for
			further details on standardized processing when checking Server
			certificate identities.
	o The negotiation of a shared secret is secure: the negotiated		o The negotiation of a shared secret is secure: the negotiated
	secret is unavailable to eavesdroppers, and for any authenticated		secret is unavailable to eavesdroppers, and for any authenticated
	handshake the secret cannot be obtained, even by an attacker who		handshake the secret cannot be obtained, even by an attacker who
	can place himself in the middle of the session.		can place himself in the middle of the session.
	o The negotiation is not vulnerable to malicious modification: it is		o The negotiation is not vulnerable to malicious modification: it is
	infeasible for an attacker to modify negotiation communication		infeasible for an attacker to modify negotiation communication
	without being detected by the parties to the communication.		without being detected by the parties to the communication.
	skipping to change at page 11, line 13 ¶		skipping to change at page 11, line 15 ¶
	The DTLSTM provides for authentication of the Principal Command		The DTLSTM provides for authentication of the Principal Command
	Generator and Notification Generator and for authentication of		Generator and Notification Generator and for authentication of
	the Command Responder, Notification Responder and Proxy Forwarder		the Command Responder, Notification Responder and Proxy Forwarder
	through the use of X.509 certificates.		through the use of X.509 certificates.
	The masquerade threat can be mitigated against by using an		The masquerade threat can be mitigated against by using an
	appropriate Access Control Model (ACM) such as the View-based		appropriate Access Control Model (ACM) such as the View-based
	Access Control Module (VACM) [RFC3415]. In addition, it is		Access Control Module (VACM) [RFC3415]. In addition, it is
	important to authenticate and verify both the authenticated		important to authenticate and verify both the authenticated
	identity of the DTLS client and the DTLS server to protect		identity of the DTLS client and the DTLS server to protect
	against this threat. (See Security Considerations for more		against this threat. (See Section 9 for more detail.)
	detail.)
	3. Message stream modification - The re-ordering, delay or replay of		3. Message stream modification - The re-ordering, delay or replay of
	messages can and does occur through the natural operation of many		messages can and does occur through the natural operation of many
	connectionless transport services. The message stream		connectionless transport services. The message stream
	modification threat is the danger that messages may be		modification threat is the danger that messages may be
	maliciously re-ordered, delayed or replayed to an extent which is		maliciously re-ordered, delayed or replayed to an extent which is
	greater than can occur through the natural operation of		greater than can occur through the natural operation of
	connectionless transport services, in order to effect		connectionless transport services, in order to effect
	unauthorized management operations.		unauthorized management operations.
	skipping to change at page 12, line 35 ¶		skipping to change at page 12, line 35 ¶
	mechanism forces the attacker/client to be able to receive the		mechanism forces the attacker/client to be able to receive the
	cookie, which makes DoS attacks with spoofed IP addresses		cookie, which makes DoS attacks with spoofed IP addresses
	difficult. This mechanism does not provide any defense against		difficult. This mechanism does not provide any defense against
	denial of service attacks mounted from valid IP addresses.		denial of service attacks mounted from valid IP addresses.
	Implementations are not required to perform the stateless cookie		Implementations are not required to perform the stateless cookie
	exchange for every DTLS handshakes but in environments where		exchange for every DTLS handshakes but in environments where
	amplification could be an issue it is RECOMMENDED that the cookie		amplification could be an issue it is RECOMMENDED that the cookie
	exchange is utilized.		exchange is utilized.
	3.1.2. Security Level		3.1.2. Message Protection
	The RFC 3411 architecture recognizes three levels of security:		The RFC 3411 architecture recognizes three levels of security:
	o without authentication and without privacy (noAuthNoPriv)		o without authentication and without privacy (noAuthNoPriv)
	o with authentication but without privacy (authNoPriv)		o with authentication but without privacy (authNoPriv)
	o with authentication and with privacy (authPriv)		o with authentication and with privacy (authPriv)
	The DTLS Transport Model determines from DTLS the identity of the		The DTLS Transport Model determines from DTLS the identity of the
	skipping to change at page 13, line 51 ¶		skipping to change at page 13, line 51 ¶
	ensure that a DTLS session to a given target can be established		ensure that a DTLS session to a given target can be established
	before it becomes important to send a message over the DTLS session.		before it becomes important to send a message over the DTLS session.
	Of course, there is no guarantee that a pre-established session will		Of course, there is no guarantee that a pre-established session will
	still be valid when needed.		still be valid when needed.
	DTLS sessions are uniquely identified within the DTLS Transport Model		DTLS sessions are uniquely identified within the DTLS Transport Model
	by the combination of transportDomain, transportAddress,		by the combination of transportDomain, transportAddress,
	securityName, and requestedSecurityLevel associated with each		securityName, and requestedSecurityLevel associated with each
	session. Each unique combination of these parameters MUST have a		session. Each unique combination of these parameters MUST have a
	locally-chosen unique dtlsSessionID associated for active sessions.		locally-chosen unique dtlsSessionID associated for active sessions.
	For further information see Section 4.6 and Section 5.		For further information see Section 4.4 and Section 5.
	3.2. Security Parameter Passing		3.2. Security Parameter Passing
	For the DTLS server-side, DTLS-specific security parameters (i.e.,		For the DTLS server-side, DTLS-specific security parameters (i.e.,
	cipher_suites, common name of X.509 certificate, IP address and port)		cipher_suites, common name of X.509 certificate, IP address and port)
	are translated by the DTLS Transport Model into security parameters		are translated by the DTLS Transport Model into security parameters
	for the DTLS Transport Model and security model (i.e., securityLevel,		for the DTLS Transport Model and security model (i.e., securityLevel,
	securityName, transportDomain, transportAddress). The transport-		securityName, transportDomain, transportAddress). The transport-
	related and DTLS-security-related information, including the		related and DTLS-security-related information, including the
	authenticated identity, are stored in a cache referenced by		authenticated identity, are stored in a cache referenced by
	skipping to change at page 14, line 49 ¶		skipping to change at page 14, line 49 ¶
	address are configured in the snmpTargetAddrTable, and the		address 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 DTLS client-side certificate to use for the connection.		specify a DTLS client-side certificate to use for the connection.
	When configuring a DTLS target, the snmpTargetAddrTDomain and		When configuring a DTLS target, the snmpTargetAddrTDomain and
	snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be		snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be
	set to the snmpDTLSDomain object and an appropriate snmpDTLSAddress		set to the snmpDTLSDomain object and an appropriate snmpDTLSAddress
	value respectively. The snmpTargetParamsMPModel column of the		value respectively. The snmpTargetParamsMPModel column of the
	snmpTargetParamsTable should be set to the XXX:TMSM value. The		snmpTargetParamsTable should be set to a value of 3 to indicate the
	snmpTargetParamsSecurityName should be set to an appropriate		SNMPv3 message processing model. The snmpTargetParamsSecurityName
	securityName value and the dtlstmParamsSubject parameter of the		should be set to an appropriate securityName value and the
	dtlstmParamsTable should be set to the Subject of the locally held		dtlstmParamsSubject parameter of the dtlstmParamsTable should be set
	certificate to be used. Other parameters, for example cipher suites,		to the Subject of the locally held certificate to be used. Other
	must come from configuration mechanisms not defined in this document.		parameters, for example cryptographic configuration such as cipher
	The other needed configuration may be configured using SNMP or other		suites to use, must come from configuration mechanisms not defined in
	implementation-dependent mechanisms (such as via a CLI or a		this document. The other needed configuration may be configured
	configuration system). This securityName defined in the		using SNMP or other implementation-dependent mechanisms (for example,
			via a CLI). This securityName defined in the
	snmpTargetParamsSecurityName column will be used by the access		snmpTargetParamsSecurityName column will be used by the access
	control model to authorize any notifications that need to be sent.		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 DTLS		This section contains definitions required to realize the DTLS
	Transport Model defined by this document.		Transport Model defined by this document.
	4.1. Certificates		4.1. Certificates
			DTLS makes use of X.509 certificates for authentication of both sides
			of the transport. This section discusses the use of certificates in
			DTLS and the its effects on SNMP over DTLS.
	4.1.1. The Certificate Infrastructure		4.1.1. The Certificate Infrastructure
	Users of a public key SHALL be confident that the associated private		Users of a public key SHALL be confident that the associated private
	key is owned by the correct remote subject (person or system) with		key is owned by the correct remote subject (person or system) with
	which an encryption or digital signature mechanism will be used.		which an encryption or digital signature mechanism will be used.
	This confidence is obtained through the use of public key		This confidence is obtained through the use of public key
	certificates, which are data structures that bind public key values		certificates, which are data structures that bind public key values
	to subjects. The binding is asserted by having a trusted CA		to subjects. The binding is asserted by having a trusted CA
	digitally sign each certificate. The CA may base this assertion upon		digitally sign each certificate. The CA may base this assertion upon
	technical means (i.e., proof of possession through a challenge-		technical means (i.e., proof of possession through a challenge-
	skipping to change at page 16, line 12 ¶		skipping to change at page 16, line 17 ¶
	period, and other associated information. This field may also		period, and other associated information. This field may also
	contain extensions.		contain extensions.
	signatureAlgorithm: The signatureAlgorithm field contains the		signatureAlgorithm: The signatureAlgorithm field contains the
	identifier for the cryptographic algorithm used by the certificate		identifier for the cryptographic algorithm used by the certificate
	authority (CA) to sign this certificate.		authority (CA) to sign this certificate.
	signatureValue: The signatureValue field contains a digital		signatureValue: The signatureValue field contains a digital
	signature computed upon the ASN.1 DER encoded tbsCertificate		signature computed upon the ASN.1 DER encoded tbsCertificate
	field. The ASN.1 DER encoded tbsCertificate is used as the input		field. The ASN.1 DER encoded tbsCertificate is used as the input
	to the signature function. This signature value is then ASN.1		to the signature function. This signature value is then ASN.1 DER
	encoded as a BIT STRING and included in the Certificate's		encoded as a BIT STRING and included in the Certificate's
	signature field. By generating this signature, a CA certifies the		signature field. By generating this signature, a CA certifies the
	validity of the information in the tbsCertificate field. In		validity of the information in the tbsCertificate field. In
	particular, the CA certifies the binding between the public key		particular, the CA certifies the binding between the public key
	material and the subject of the certificate.		material and the subject of the certificate.
	The basic X.509 authentication procedure is as follows: A system,		The basic X.509 authentication procedure is as follows: A system,
	which uses the X.509 key management infrastructure, is initialized		which uses the X.509 key management infrastructure, is initialized
	with a number of root certificates which contain the public keys of a		with a number of root certificates which contain the public keys of a
	number of trusted CAs. When a system receives a X.509 certificate,		number of trusted CAs. When a system receives a X.509 certificate,
	skipping to change at page 16, line 40 ¶		skipping to change at page 16, line 45 ¶
	Authentication using DTLS will require that SNMP entities are		Authentication using DTLS will require that SNMP entities are
	provisioned with certificates, which are signed by trusted		provisioned with certificates, which are signed by trusted
	certificate authorities. Furthermore, SNMP entities will most		certificate authorities. Furthermore, SNMP entities will most
	commonly need to be provisioned with root certificates which		commonly need to be provisioned with root certificates which
	represent the list of trusted certificate authorities that an SNMP		represent the list of trusted certificate authorities that an SNMP
	entity can use for certificate verification. SNMP entities MAY also		entity can use for certificate verification. SNMP entities MAY also
	be provisioned with X.509 certificate revocation mechanism which will		be provisioned with X.509 certificate revocation mechanism which will
	be used to verify that a certificate has not been revoked.		be used to verify that a certificate has not been revoked.
	The authenticated securityName of the principal is looked up using		The authenticated tmSecurityName of the principal is looked up using
	the dtlstmCertificateToSNTable. This table maps the certificates		the dtlstmCertificateToSNTable. This table maps the certificates
	issuer's distinguished name to a directly specified securityName or		issuer's distinguished name to a directly specified tmSecurityName or
	it specifies that the CommonName field of the certificate's Subject		it specifies that the CommonName field of the certificate's Subject
	should be used as the securityName. The certificate trust anchors,		should be used as the tmSecurityName. The certificate trust anchors,
	being either CA certificates or public keys for use by self-signed		being either CA certificates or public keys for use by self-signed
	certificates, must be installed through an out of band trusted		certificates, must be installed through an out of band trusted
	mechanism into the server and its authenticity MUST be verified		mechanism into the server and its authenticity MUST be verified
	before access is granted. Implementations MAY choose to discard any		before access is granted. Implementations MAY choose to discard any
	connections for which no dtlstmCertificateToSNTable mapping exists		connections for which no dtlstmCertificateToSNTable mapping exists
	for the issuer to avoid the computational resources associated with a		for the issuer to avoid the computational resources associated with a
	certificate verification check since the verified certificate would		certificate verification check since the verified certificate would
	be unusable anyway.		be unusable anyway.
	The typical setting will map the "CommonName" component of the		The typical enterprise configuration will map the "CommonName"
	Subject field in the tbsCertificate to the DTLSSM specific		component of the Subject field in the tbsCertificate to the DTLSSM
	securityName. Thus, the authenticated identity can be verified by		specific tmSecurityName. Thus, the authenticated identity can be
	the DTLS Transport Model by extracting the CommonName from the		verified by the DTLS Transport Model by extracting the CommonName
	Subject of the peer certificate and the receiving application will		from the Subject of the peer certificate and the receiving
	have an appropriate securityName for use by components like an access		application will have an appropriate tmSecurityName for use by
	control model.		components like an access control model. This setup requires very
			little configuration: a single row in the dtlstmCertificateToSNTable.
	An example mapping setup can be found in Appendix A		An example mapping setup can be found in Appendix A
	[XXX: This securityName may be later translated from a DTLSSM		This tmSecurityName may be later translated from a DTLSSM specific
	specific securityName to a SNMP engine securityName by the TMSM or TM		tmSecurityName to a SNMP engine securityName by the security model.
	component configuration. Waiting on discussion/resolution within the		A security model, like the TSM security model, may perform an
	ISMS list about this].		identity mapping or a more complex mapping to derive the securityName
			from the tmSecurityName.
	4.2. Messages		4.2. Messages
	As stated in RFC4347, each DTLS message must fit within a single		As stated in RFC4347, each DTLS message must fit within a single
	datagram. The DTLSTM MUST prohibit SNMP messages from being set that		datagram. The DTLSTM MUST prohibit SNMP messages from being set that
	exceed the MTU size. The DTLSTM implementation MUST return an error		exceed the MTU size. The DTLSTM implementation MUST return an error
	when the MTU size would be exceeded and the message won't be sent.		when the MTU size would be exceeded and the message won't be sent.
	For Ethernet the MTU size is 1500 and thus the maximum allowable SNMP		For Ethernet the MTU size is 1500 and thus the maximum allowable SNMP
	message that can be sent over DTLSTM after UDP/IP/DTLS overhead is		message that can be sent over DTLSTM after UDP/IP/DTLS overhead is
	taken into account will be 1455 for IPv6 (MTU:1500 - IPv6:40 - UDP:8		taken into account will be 1455 for IPv6 (MTU:1500 - IPv6:40 - UDP:8
	- DTLS:13) and 1475 for IPv4 (MTU:1500 - IPv4:20 - UDP:8 - DTLS:13).		- DTLS:13) and 1475 for IPv4 (MTU:1500 - IPv4:20 - UDP:8 - DTLS:13).
	From this integrity and encryption over head also needs to be		From this integrity and encryption overhead also needs to be
	subtracted, which are integrity and encryption algorithm specific.		subtracted, which are integrity and encryption algorithm specific.
	4.3. tmStateReference Cache		4.3. SNMP Services
	For the DTLS Transport Model, the session state is maintained using
	tmStateReference. Upon opening each DTLS session, the DTLS Transport
	Model stores model- and mechanism-specific information about the
	session in a cache, referenced by tmStateReference. An
	implementation might store the contents of the cache in a Local
	Configuration Datastore (LCD).
	The following four parameters, referred to as tmSecurityData, are
	stored in the cache:
	tmTransportDomain = Specified by the application
	tmTransportAddress = Specified by the application
	tmRequestedSecurityLevel = ["noAuthNoPriv" | "authNoPriv" |
	"authPriv" ] the security level requested by the application
	tmSecurityLevel = ["noAuthNoPriv" | "authNoPriv" | "authPriv" ] the
	security level of the established DTLS session
	tmSecurityName = the security name associated with a principal
	The tmStateReference cache is used to pass a reference to the
	tmSecurityData between the DTLS Transport Model and the security
	model.
	The DTLS Transport Model has the responsibility for releasing the
	complete tmStateReference and deleting the associated information
	when the session is destroyed.
	4.3.1. tmTransportDomain and tmTransportAddress
	The tmTransportDomain and tmTransportAddress identify the type and
	address of the DTLS transport endpoint. The domain for address types
	DTLS SHOULD be "snmpDTLSDomain" and the address should be one that
	conforms to the details specified in the "SnmpDTLSAddress" textual
	convention. These parameters are stored in a cache for active
	sessions and referenced by tmStateReference.
	4.3.2. tmRequestedSecurityLevel
	The tmRequestedSecurityLevel is the security level requested by the
	application. This parameter is set in the cache by the security
	model and used by DTLS Transport Model initiating a session to select
	the appropriate cipher_suites and other configuration needed settings
	for establishing the session. The DTLS Transport Model MUST ensure
	that the actual security provided by the session (tmSecurityLevel) is
	at least as high as the requested security level
	(tmRequestedSecurityLevel).
	4.3.3. tmSecurityLevel
	The tmSecurityLevel is the actual security level of the established
	session. See Section 3.1.2 for more detail about security levels.
	How the chosen cipher_suites and other DTLS session parameters are
	translated into a security level at the DTLS Transport Model is
	implementation dependent and/or policy specific. Implementations
	MUST NOT use NULL algorithms for fulfilling authentication or
	encryption needs indicated by the tmSecurityLevel.
	4.3.4. tmSecurityName
	The tmSecurityName is the name of the principal on whose behalf the
	message is being sent. This field is set via the mapping defined in
	the dtlstmCertificateToSNTable when mapping incoming client
	connection certificates to a tmSecurityName. For outgoing
	connections, the application will specify the value that should be
	placed in this field possibly by extracting it from the SNMP-TARGET-
	MIB's snmpTargetParamsSecurityName value. The tmSecurityName is
	stored in a cache for active sessions and referenced by
	tmStateReference.
	4.4. Transport Model LCD
	Implementations may store DTLS-specific and model-specific
	information in a LCD. The DTLS session ID is one such parameter that
	could be stored in the LCD. When messages are to be routed for
	encapsulation or for integrity verification and decryption the
	message and the DTLS session ID must be passed to the DTLS transport
	layer for processing. Therefore, the DTLS Transport Model MUST
	maintain a one-to-one mapping between the DTLS session ID and the
	tmStateReference cache entry for that session. Implementations MAY
	choose to store the DTLS session ID in the tmStateReference cache to
	simplify the procedure.
	4.5. SNMP Services
	This section describes the services provided by the DTLS Transport		This section describes the services provided by the DTLS Transport
	Model with their inputs and outputs. The services are between the		Model with their inputs and outputs. The services are between the
	Transport Model and the Dispatcher.		Transport Model and the Dispatcher.
	The services are described as primitives of an abstract service		The services are described as primitives of an abstract service
	interface (ASI) and the inputs and outputs are described as abstract		interface (ASI) and the inputs and outputs are described as abstract
	data elements as they are passed in these abstract service		data elements as they are passed in these abstract service
	primitives.		primitives.
	4.5.1. SNMP Services for an Outgoing Message		4.3.1. SNMP Services for an Outgoing Message
	The Dispatcher passes the information to the DTLS Transport Model		The Dispatcher passes the information to the DTLS Transport Model
	using the ASI defined in the transport subsystem:		using the ASI defined in the transport subsystem:
	statusInformation =		statusInformation =
	sendMessage(		sendMessage(
	IN destTransportDomain -- transport domain to be used		IN destTransportDomain -- transport domain to be used
	IN destTransportAddress -- transport address to be used		IN destTransportAddress -- transport address to be used
	IN outgoingMessage -- the message to send		IN outgoingMessage -- the message to send
	IN outgoingMessageLength -- its length		IN outgoingMessageLength -- its length
	skipping to change at page 20, line 28 ¶		skipping to change at page 18, line 45 ¶
	TEXTUAL-CONVENTION.		TEXTUAL-CONVENTION.
	outgoingMessage: The outgoing message to send to DTLS for		outgoingMessage: The outgoing message to send to DTLS for
	encapsulation.		encapsulation.
	outgoingMessageLength: The length of the outgoing message.		outgoingMessageLength: The length of the outgoing message.
	tmStateReference: A handle/reference to tmSecurityData to be used		tmStateReference: A handle/reference to tmSecurityData to be used
	when securing outgoing messages.		when securing outgoing messages.
	4.5.2. SNMP Services for an Incoming Message		4.3.2. SNMP Services for an Incoming Message
	The DTLS Transport Model processes the received message from the		The DTLS Transport Model processes the received message from the
	network using the DTLS service and then passes it to the Dispatcher		network using the DTLS service and then passes it to the Dispatcher
	using the following ASI:		using the following ASI:
	receiveMessage(		receiveMessage(
	IN transportDomain -- origin transport domain		IN transportDomain -- origin transport domain
	IN transportAddress -- origin transport address		IN transportAddress -- origin transport address
	IN incomingMessage -- the message received		IN incomingMessage -- the message received
	IN incomingMessageLength -- its length		IN incomingMessageLength -- its length
	skipping to change at page 21, line 21 ¶		skipping to change at page 19, line 36 ¶
	incomingMessage: The whole SNMP message stripped of all DTLS		incomingMessage: The whole SNMP message stripped of all DTLS
	protection data.		protection data.
	incomingMessageLength: The length of the SNMP message after being		incomingMessageLength: The length of the SNMP message after being
	processed by DTLS.		processed by DTLS.
	tmStateReference: A handle/reference to tmSecurityData to be used by		tmStateReference: A handle/reference to tmSecurityData to be used by
	the security model.		the security model.
	4.6. DTLS Services		4.4. DTLS Services
	This section describes the services provided by the DTLS Transport		This section describes the services provided by the DTLS Transport
	Model with their inputs and outputs. These services are between the		Model with their inputs and outputs. These services are between the
	DTLS Transport Model and the DTLS transport layer. The following		DTLS Transport Model and the DTLS transport layer. The following
	sections describe services for establishing and closing a session and		sections describe services for establishing and closing a session and
	for passing messages between the DTLS transport layer and the DTLS		for passing messages between the DTLS transport layer and the DTLS
	Transport Model.		Transport Model.
	4.6.1. Services for Establishing a Session		4.4.1. Services for Establishing a Session
	The DTLS Transport Model provides the following ASI to describe the		The DTLS Transport Model provides the following ASI to describe the
	data passed between the Transport Model and the DTLS transport layer		data passed between the Transport Model and the DTLS transport layer
	for session establishment.		for session establishment.
	statusInformation = -- errorIndication or success		statusInformation = -- errorIndication or success
	openSession(		openSession(
	IN destTransportDomain -- transport domain to be used		IN destTransportDomain -- transport domain to be used
	IN destTransportAddress -- transport address to be used		IN destTransportAddress -- transport address to be used
	IN securityName -- on behalf of this principal		IN securityName -- on behalf of this principal
	skipping to change at page 22, line 22 ¶		skipping to change at page 20, line 38 ¶
	TEXTUAL-CONVENTION.		TEXTUAL-CONVENTION.
	securityName: The security name representing the principal on whose		securityName: The security name representing the principal on whose
	behalf the message will be sent.		behalf the message will be sent.
	securityLevel: The level of security requested by the application.		securityLevel: The level of security requested by the application.
	dtlsSessionID: An implementation-dependent session identifier to		dtlsSessionID: An implementation-dependent session identifier to
	reference the specific DTLS session.		reference the specific DTLS session.
			DTLS and UDP do not provide a session de-multiplexing mechanism and
			it is possible that implementations will only be able to identify a
			unique session based on a unique combination of source address,
			destination address, source UDP port number and destination UDP port
			number. Because of this, when establishing a new sessions
			implementations MUST use a different UDP source port number for each
			connection to a remote destination IP-address/port-number combination
			to ensure the remote entity can properly disambiguate between
			multiple sessions from a host to the same port on a server.
	The procedural details for establishing a session are further		The procedural details for establishing a session are further
	described in Section 5.3.		described in Section 5.3.
	Upon completion of the process the DTLS Transport Model returns		Upon completion of the process the DTLS Transport Model returns
	status information and, if the process was successful the		status information and, if the process was successful the
	dtlsSessionID and other implementation-dependent data from DTLS are		dtlsSessionID and other implementation-dependent data from DTLS are
	also returned. The dtlsSessionID is stored in an implementation-		also returned. The dtlsSessionID is stored in an implementation-
	dependent manner and tied to the tmSecurityData for future use of		dependent manner and tied to the tmSecurityData for future use of
	this session.		this session.
	4.6.2. DTLS Services for an Incoming Message		4.4.2. DTLS Services for an Incoming Message
	When the DTLS Transport Model invokes the DTLS record layer to verify		When the DTLS Transport Model invokes the DTLS record layer to verify
	proper security for the incoming message, it must use the following		proper security for the incoming message, it must use the following
	ASI:		ASI:
	statusInformation = -- errorIndication or success		statusInformation = -- errorIndication or success
	dtlsRead(		dtlsRead(
	IN dtlsSessionID -- Session identifier for DTLS		IN dtlsSessionID -- Session identifier for DTLS
	IN wholeDtlsMsg -- as received on the wire		IN wholeDtlsMsg -- as received on the wire
	IN wholeDtlsMsgLength -- length as received on the wire		IN wholeDtlsMsgLength -- length as received on the wire
	skipping to change at page 23, line 28 ¶		skipping to change at page 22, line 5 ¶
	wholeDtlsMsgLength: The length of the message as it was received on		wholeDtlsMsgLength: The length of the message as it was received on
	the wire.		the wire.
	incomingMessage: The whole SNMP message stripped of all DTLS privacy		incomingMessage: The whole SNMP message stripped of all DTLS privacy
	and integrity data.		and integrity data.
	incomingMessageLength: The length of the SNMP message stripped of		incomingMessageLength: The length of the SNMP message stripped of
	all DTLS privacy and integrity data.		all DTLS privacy and integrity data.
	4.6.3. DTLS Services for an Outgoing Message		4.4.3. DTLS Services for an Outgoing Message
	When the DTLS Transport Model invokes the DTLS record layer to		When the DTLS Transport Model invokes the DTLS record layer to
	encapsulate and transmit a SNMP message, it must use the following		encapsulate and transmit a SNMP message, it must use the following
	ASI.		ASI.
	statusInformation = -- errorIndication or success		statusInformation = -- errorIndication or success
	dtlsWrite(		dtlsWrite(
	IN dtlsSessionID -- Session identifier for DTLS		IN dtlsSessionID -- Session identifier for DTLS
	IN outgoingMessage -- the message to send		IN outgoingMessage -- the message to send
	IN outgoingMessageLength -- its length		IN outgoingMessageLength -- its length
	skipping to change at page 24, line 10 ¶		skipping to change at page 22, line 34 ¶
	dtlsSessionID: An implementation-dependent session identifier to		dtlsSessionID: An implementation-dependent session identifier to
	reference the specific DTLS session that the message should be		reference the specific DTLS session that the message should be
	sent using.		sent using.
	outgoingMessage: The outgoing message to send to DTLS for		outgoingMessage: The outgoing message to send to DTLS for
	encapsulation.		encapsulation.
	outgoingMessageLength: The length of the outgoing message.		outgoingMessageLength: The length of the outgoing message.
			4.5. Cached Information and References
			When performing SNMP processing, there are two levels of state
			information that may need to be retained: the immediate state linking
			a request-response pair, and potentially longer-term state relating
			to transport and security.
			The RFC3411 architecture uses caches to maintain the short-term
			message state, and uses references in the ASIs to pass this
			information between subsystems.
			This document defines the requirements for a cache to handle the
			longer-term transport state information, using a tmStateReference
			parameter to pass this information between subsystems.
			To simplify the elements of procedure, the release of state
			information is not always explicitly specified. As a general rule,
			if state information is available when a message being processed gets
			discarded, the state related to that message SHOULD also be
			discarded. If state information is available when a relationship
			between engines is severed, such as the closing of a transport
			session, the state information for that relationship SHOULD also be
			discarded.
			Since the contents of a cache are meaningful only within an
			implementation, and not on-the-wire, the format of the cache and the
			LCD are implementation-specific.
			4.5.1. securityStateReference
			The securityStateReference parameter is defined in RFC3411. Its
			primary purpose is to provide a mapping between a request and the
			corresponding response. This cache is not accessible to Transport
			Models, and an entry is typically only retained for the lifetime of a
			request-response pair of messages.
			4.5.2. tmStateReference
			For each transport session, information about the transport security
			is stored in a cache. The tmStateReference parameter is used to pass
			model-specific and mechanism-specific parameters between the
			Transport subsystem and transport-aware Security Models.
			The tmStateReference cache will typically remain valid for the
			duration of the transport session, and hence may be used for several
			messages.
			Since this cache is only used within an implementation, and not on-
			the-wire, the precise contents and format are implementation-
			dependent. However, for interoperability between Transport Models
			and transport-aware Security Models, entries in this cache must
			include at least the following fields:
			transportDomain
			transportAddress
			tmSecurityName
			tmRequestedSecurityLevel
			tmTransportSecurityLevel
			tmSameSecurity
			tmSessionID
			4.5.2.1. Transport information
			Information about the source of an incoming SNMP message is passed up
			from the Transport subsystem as far as the Message Processing
			subsystem. However these parameters are not included in the
			processIncomingMsg ASI defined in RFC3411, and hence this information
			is not directly available to the Security Model.
			A transport-aware Security Model might wish to take account of the
			transport protocol and originating address when authenticating the
			request, and setting up the authorization parameters. It is
			therefore necessary for the Transport Model to include this
			information in the tmStateReference cache, so that it is accessible
			to the Security Model.
			o transportDomain: the transport protocol (and hence the Transport
			Model) used to receive the incoming message
			o transportAddress: the source of the incoming message.
			The ASIs used for processing an outgoing message all include explicit
			transportDomain and transportAddress parameters. The values within
			the securityStateReference cache might override these parameters for
			outgoing messages.
			4.5.2.2. securityName
			There are actually three distinct "identities" that can be identified
			during the processing of an SNMP request over a secure transport:
			o transport principal: the transport-authenticated identity, on
			whose behalf the secure transport connection was (or should be)
			established. This value is transport-, mechanism- and
			implementation- specific, and is only used within a given
			Transport Model.
			o tmSecurityName: a human-readable name (in snmpAdminString format)
			representing this transport identity. This value is transport-
			and implementation-specific, and is only used (directly) by the
			Transport and Security Models.
			o securityName: a human-readable name (in snmpAdminString format)
			representing the SNMP principal in a model-independent manner.
			The transport principal may or may not be the same as the
			tmSecurityName. Similarly, the tmSecurityName may or may not be the
			same as the securityName as seen by the Application and Access
			Control subsystems. In particular, a non-transport-aware Security
			Model will ignore tmSecurityName completely when determining the SNMP
			securityName.
			However it is important that the mapping between the transport
			principal and the SNMP securityName (for transport-aware Security
			Models) is consistent and predictable, to allow configuration of
			suitable access control and the establishment of transport
			connections.
			4.5.2.3. securityLevel
			There are two distinct issues relating to security level as applied
			to secure transports. For clarity, these are handled by separate
			fields in the tmStateReference cache:
			o tmTransportSecurityLevel: an indication from the Transport Model
			of the level of security offered by this session. The Security
			Model can use this to ensure that incoming messages were suitably
			protected before acting on them.
			o tmRequestedSecurityLevel: an indication from the Security Model of
			the level of security required to be provided by the transport
			protocol. The Transport Model can use this to ensure that
			outgoing messages will not be sent over an insufficiently secure
			session.
			4.5.2.4. Session Information
			For security reasons, if a secure transport session is closed between
			the time a request message is received and the corresponding response
			message is sent, then the response message SHOULD be discarded, even
			if a new session has been established. The SNMPv3 WG decided that
			this should be a SHOULD architecturally, and it is a security-model-
			specific decision whether to REQUIRE this.
			o tmSameSecurity: this flag is used by a transport-aware Security
			Model to indicate whether the Transport Model MUST enforce this
			restriction.
			o tmSessionID: in order to verify whether the session has changed,
			the Transport Model must be able to compare the session used to
			receive the original request with the one to be used to send the
			response. This typically requires some form of session
			identifier. This value is only ever used by the Transport Model,
			so the format and interpretation of this field are model-specific
			and implementation-dependent.
			When processing an outgoing message, if tmSameSecurity is true, then
			the tmSessionID MUST match the current transport session, otherwise
			the message MUST be discarded, and the dispatcher notified that
			sending the message failed.
			4.5.3. DTLS Transport Model Cached Information
			For the DTLS Transport Model, the session state is maintained using
			tmStateReference. Upon opening each DTLS session, the DTLS Transport
			Model stores model- and mechanism-specific information about the
			session in a cache, referenced by tmStateReference. An
			implementation might store the contents of the cache in a Local
			Configuration Datastore (LCD).
			At a minimum, the following parameters are stored in the cache:
			tmTransportDomain = Specified by the application tmSameSecurity =
			boolean value set by the security model or false by default
			tmTransportAddress = Specified by the application
			tmRequestedSecurityLevel = ["noAuthNoPriv" | "authNoPriv" |
			"authPriv" ] the security level requested by the application
			tmSecurityLevel = ["noAuthNoPriv" | "authNoPriv" | "authPriv" ] the
			security level of the established DTLS session
			tmSecurityName = the security name associated with a principal
			The tmStateReference cache is used to pass a reference to these
			values between the DTLS Transport Model and the security model.
			The DTLS Transport Model has the responsibility for releasing the
			complete tmStateReference and deleting the associated information
			when the session is destroyed.
			4.5.3.1. Transport Information
			The tmTransportDomain and tmTransportAddress identify the type and
			address of the remote DTLS transport endpoint. The domain for
			address types for DTLS sessions SHOULD be "snmpDTLSDomain" and the
			address SHOULD be one that conforms to the details specified in the
			"SnmpDTLSAddress" textual convention.
			4.5.3.2. tmRequestedSecurityLevel
			The tmRequestedSecurityLevel is the security level requested by the
			application. This parameter is set in the cache by the security
			model and used by DTLS Transport Model initiating a session to select
			the appropriate cipher_suites and other configuration needed settings
			for establishing the session. The DTLS Transport Model MUST ensure
			that the actual security provided by the session (tmSecurityLevel) is
			at least as high as the requested security level
			(tmRequestedSecurityLevel).
			4.5.3.3. tmSecurityLevel
			The tmSecurityLevel is the actual security level of the established
			session. See Section 3.1.2 for more detail about security levels.
			How the chosen cipher_suites and other DTLS session parameters are
			translated into a security level at the DTLS Transport Model is
			implementation dependent and/or policy specific. Implementations
			MUST NOT use NULL algorithms for fulfilling authentication or
			encryption needs indicated by the tmSecurityLevel.
			4.5.3.4. tmSecurityName
			The tmSecurityName is the name of the principal on whose behalf the
			message is being sent. This field is set via the mapping defined in
			the dtlstmCertificateToSNTable when mapping incoming client
			connection certificates to a tmSecurityName. For outgoing
			connections, the application will specify the value that should be
			placed in this field (possibly by extracting it from the SNMP-TARGET-
			MIB's snmpTargetParamsSecurityName value).
			4.5.4. Transport Model LCD
			Implementations may store DTLS-specific and model-specific
			information in a LCD. The DTLS session ID is one such parameter that
			could be stored in the LCD. When messages are to be routed for
			encapsulation or for integrity verification and decryption the
			message and the DTLS session ID must be passed to the DTLS transport
			layer for processing. Therefore, the DTLS Transport Model MUST
			maintain a one-to-one mapping between the DTLS session ID and the
			tmStateReference cache entry for that session. Implementations will
			need to store the DTLS session ID in the tmStateReference cache to
			simplify the procedure.
	5. Elements of Procedure		5. Elements of Procedure
	Abstract service interfaces have been defined by RFC 3411 to describe		Abstract service interfaces have been defined by RFC 3411 to describe
	the conceptual data flows between the various subsystems within an		the conceptual data flows between the various subsystems within an
	SNMP entity. The DTLSTM uses some of these conceptual data flows		SNMP entity. The DTLSTM uses some of these conceptual data flows
	when communicating between subsystems. These RFC 3411-defined data		when communicating between subsystems. These RFC 3411-defined data
	flows are referred to here as public interfaces.		flows are referred to here as public interfaces.
	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,
	skipping to change at page 24, line 31 ¶		skipping to change at page 28, line 18 ¶
	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 with zero value or random		cryptographic keys, should be overwritten with zero value or random
	value data prior to being released.		value data prior to being released.
	An error indication may return an OID and value for an incremented		An error indication may return an OID and value for an incremented
	counter if the information is available at the point where the error		counter if the information is available at the point where the error
	is detected.		is detected.
	5.1. Receiving an Incoming Message		5.1. Procedures for an Incoming Message
	The following section describes the procedures followed by the DTLS		The following section describes the procedures followed by the DTLS
	Transport Model when it receives a DTLS protected packet. A process		Transport Model when it receives a DTLS protected packet. The steps
	for multiplexing sessions must be incorporated into the procedures		are broken into two different sections. The first section describes
	for an incoming message. Steps one through four of this section		the needed steps for de-multiplexing multiple DTLS sessions and the
	describe how this is done. This procedure assumes that upon session		second section describes the steps which are specific to transport
	establishment, a transport mapping table is created in the Transport		processing once the DTLS processing has been completed.
	Model LCD. The transport mapping table associates dtlsSessionID with
	the source and destination addresses and ports used for the session.
	It also assumes that the LCD entry is tied to the cache entry so the
	tmStateReference can be retrieved for the receiveMessage() ASI.
	1) The DTLS Transport Model examines the message, in an		5.1.1. DTLS Processing for Incoming Messages
	implementation-dependent manner, to determine the transport
	parameters for the received message.
	As an implementation hint, the source and destination addresses		DTLS is significantly different in terms of session handling than
	and ports of the message should uniquely assign the message to a		SSH, TLS or other TCP-based session streams. The DTLS protocol,
	specific session. However, another implementation-dependent		which is UDP-based, does not have a session identifier that allows
	method may be used if so desired.		implementations to determine through which session a packet is
			arriving like TCP-based streams have. Thus, a process for de-
			multiplexing sessions must be incorporated into the procedures for an
			incoming message. The steps in this section describe how this can be
			accomplished, although any implementation dependent method for doing
			so should be suitable as long as the results are consistently
			deterministic. The important results from the steps in this section
			are the transportDomain, the transportAddress, the wholeMessage, the
			wholeMessageLength, and a unique implementation-dependent session
			identifier.
			This procedure assumes that upon session establishment, an entry in a
			local transport mapping table is created in the Transport Model's
			LCD. This transport mapping table entry should be able to map a
			unique combination of the remote address, remote port number, local
			address and local port number to a implementation-dependent
			dtlsSessionID.
			1) The DTLS Transport Model examines the raw UDP message, in an
			implementation-dependent manner. If the message is not a DTLS
			message then it should be discarded. If the message is not a
			(D)TLS Application Data message then the message should be
			processed by the underlying DTLS framework as it is (for example)
			a session initialization or session modification message and no
			further steps below should be taken by the DTLS Transport.
	2) The DTLS Transport Model queries the LCD using the transport		2) The DTLS Transport Model queries the LCD using the transport
	parameters to determine if a session already exists and its		parameters to determine if a session already exists and its
	dtlsSessionID.		dtlsSessionID. As noted previously, the source and destination
			addresses and ports of the message should uniquely assign the
			message to a specific session identifier. However, another
			implementation-dependent method may be used if so desired.
	3) If a matching entry in the LCD does not exist then the message is		3) If a matching entry in the LCD does not exist then the message is
	discarded. Increment the dtlstmSessionNoAvailableSessions		discarded. Increment the dtlstmSessionNoAvailableSessions
	counter and stop processing the message.		counter and stop processing the message.
	Note that an entry would already exist if the client and server's		Note that an entry would already exist if the client and server's
	session establishment procedures had been successfully completed		session establishment procedures had been successfully completed
	(as described in Section 5.3) even if no message had been sent		(as described both above and in Section 5.3) even if no message
	through the newly established session. An entry may not exist,		had yet been sent through the newly established session. An
	however, because of a "rogue" message being routed to the SNMP		entry may not exist, however, if a "rogue" message was routed to
	entity by mistake but it could also be the result of a "broken"		the SNMP entity by mistake. An entry might also be missing
	session (see operational considerations).		because of a "broken" session (see operational considerations).
	4) If a matching entry is found, the dtlsSessionID is retrieved from		4) Retrieve the dtlsSessionID from the LCD.
	the LCD.
	5) The dtlsWholeMsg and dtlsSessionID are passed to DTLS for		5) The dtlsWholeMsg, and the dtlsSessionID are passed to DTLS for
	decryption and integrity checking using the dtlsRead() ASI.		integrity checking and decryption using the dtlsRead() ASI.
	6) If the message fails integrity checks or other DTLS security		6) If the message fails integrity checks or other DTLS security
	processing then the message is discarded by DTLS and an error		processing then the dtlstmDTLSProtectionErrors counter is
	indication may be returned by DTLS.		incremented, the message is discarded and processing of the
			message is stopped.
	7) If the message passes all integrity checks and DTLS security		7) The output of the dtlsRead results in an incomingMessage and an
	processing then the message is returned to the DTLS Transport		incomingMessageLength. These results and the dtlsSessionID are
	Model as a wholeMessage.		used below in the Section 5.1.2 to complete the processing of the
			incoming message.
	8) The DTLS Transport Model retrieves the tmStateReference for the		5.1.2. Transport Processing for Incoming Messages
	message and passes the message to the dispatcher using the
	receiveMessage() ASI.
	5.2. Sending an Outgoing Message		The procedures in this section describe how the DTLS Transport should
			process messages that have already been properly extracted from the
			DTLS stream, as described in Section 5.1.1.
			1) Create a tmStateReference cache for the subsequent reference and
			assign the following values within it:
			tmTransportDomain = snmpDTLSDomain
			tmTransportAddress = The address the message originated from,
			determined in an implementation dependent way.
			tmSecurityLevel = The derived tmSecurityLevel for the session,
			as discussed in Section 3.1.2 and Section 5.3.
			tmSecurityName = The derived tmSecurityName for the session as
			discussed in and Section 5.3.
			tmSessionID = A unique session identifier for this DTLS session.
			The contents and format of this identifier are implementation
			dependent as long as it is unique to the session. A session
			identifier MUST NOT be reused until all references to it are
			no longer in use.
			2) The wholeMessage and the wholeMessageLength are assigned values
			from the incomingMessage and incomingMessageLength values from
			the DTLS processing.
			3) The DTLS Transport Model passes the transportDomain,
			transportAddress, wholeMessage, and wholeMessageLength to the
			Dispatcher using the receiveMessage ASI:
			statusInformation =
			receiveMessage(
			IN transportDomain -- snmpSSHDomain
			IN transportAddress -- address for the received message
			IN wholeMessage -- the whole SNMP message from SSH
			IN wholeMessageLength -- the length of the SNMP message
			IN tmStateReference -- (NEW) transport info
			)
			5.2. Procedures for an Outgoing Message
			The Dispatcher sends a message to the DTLS Transport Model using the
			following ASI:
			statusInformation =
			sendMessage(
			IN destTransportDomain -- transport domain to be used
			IN destTransportAddress -- transport address to be used
			IN outgoingMessage -- the message to send
			IN outgoingMessageLength -- its length
			IN tmStateReference -- (NEW) transport info
			)
	This section describes the procedure followed by the DTLS Transport		This section describes the procedure followed by the DTLS Transport
	Model whenever it sends an outgoing SNMP message to another SNMP		Model whenever it is requested through this ASI to send a message.
	engine.
	1) Determine if there is an active session for the tmStateReference		1) Extract tmSessionID, tmTransportAddress, tmSecurityName,
	and determine in an implementation-dependent way if this is the		tmRequestedSecurityLevel. and tmSameSecurity from the
	first message to be passed through the session.		tmStateReference. Note: The tmSessionID value may be undefined
			if session exists yet.
	As an implementation hint, the DTLS Transport Model can examine		2) If tmSameSecurity is true and either tmSessionID is undefined or
	its cache and the LCD to determine if there is a cache entry with		refers to a session that is no longer open then increment the
	an existing established session. If this is the first message		dtlstmSessionNoAvailableSessions counter, discard the message and
	then there should be a cache entry with tmSecurityData associated		return the error indication in the statusInformation. Processing
	with the tmStateReference but there will be no LCD entry		of this message stops.
	containing the dtlsSessionID yet.
	2a) If there is an active session then determine the dtlsSessionID		3) If tmSameSecurity is false and tmSessionID refers to a session
	and pass the outgoingMessage to the DTLS record layer for		that is no longer available then an implementation SHOULD open a
	encapsulation and transmission. Processing for this message is		new session using the openSession() ASI as described below in
	complete.		step 3b. An implementation MAY choose to return an error to the
			calling module.
	2b) If there is no active session and this is not the first message,		4) If tmSessionID is undefined, then use tmTransportAddress,
	discard the message, increment the		tmSecurityName and tmRequestedSecurityLevel to see if there is a
	dtlstmSessionNoAvailableSessions counter, and return an error		corresponding entry in the LCD suitable to send the message over.
	indication to the calling module. Processing for this message
	is complete.
	2c) If there is no active session associated with the		3a) If there is a corresponding LCD entry, then this session
	tmStateReference and this is the first message, open a session		will be used to send the message.
	with the remote SNMP engine using the openSession() ASI
	(discussed further in Section 4.6.1). Implementations MAY wish
	to offer message buffering to prevent redundant openSession()
	calls for the same cache entry.
	3a) If an error is returned from OpenSession(), then discard the		3b) If there is not a corresponding LCD entry, then open a
	message, increment the dtlstmSessionOpenErrors, and return an		session using the openSession() ASI (discussed further in
	error indication to the calling module.		Section 4.4.1). Implementations MAY wish to offer message
			buffering to prevent redundant openSession() calls for the
			same cache entry. If an error is returned from
			OpenSession(), then discard the message, increment the
			dtlstmSessionOpenErrors, and return an error indication to
			the calling module.
	3b) If openSession() is successful, then pass the outgoingMessage to		5) Using either the session indicated by the tmSessionID if there
	DTLS for encapsulation and transmission.		was one or the session resulting in the previous step, pass the
			outgoingMessage to DTLS for encapsulation and transmission.
	5.3. Establishing a Session		5.3. Establishing a Session
	The openSession() ASI, as mentioned in Section 4.6.1, is used to		The DTLS Transport Model provides the following primitive to
	establish a DTLS session.		establish a new DTLS session (previously discussed in Section 4.4.1):
			statusInformation = -- errorIndication or success
			openSession(
			IN destTransportDomain -- transport domain to be used
			IN destTransportAddress -- transport address to be used
			IN securityName -- on behalf of this principal
			IN securityLevel -- Level of Security requested
			OUT dtlsSessionID -- Session identifier for DTLS
			)
	The following sections describe the procedures followed by a DTLS		The following sections describe the procedures followed by a DTLS
	Transport Model when establishing a session as a Command Generator, a		Transport Model when establishing a session as a Command Generator, a
	Notification Originator or as part of a Proxy Forwarder.		Notification Originator or as part of a Proxy Forwarder.
	The following describes the procedure to follow to establish a		The following describes the procedure to follow to establish a
	session between SNMP engines to exchange SNMP messages. This process		session between SNMP engines to exchange SNMP messages. This process
	is followed by any SNMP engine establishing a session for subsequent		is followed by any SNMP engine establishing a session for subsequent
	use.		use.
	skipping to change at page 27, line 40 ¶		skipping to change at page 33, line 26 ¶
	2) Using the destTransportDomain and destTransportAddress values,		2) Using the destTransportDomain and destTransportAddress values,
	the client will initiate the DTLS handshake protocol to establish		the client will initiate the DTLS handshake protocol to establish
	session keys for message integrity and encryption.		session keys for message integrity and encryption.
	If the attempt to establish a session is unsuccessful, then		If the attempt to establish a session is unsuccessful, then
	dtlstmSessionOpenErrors is incremented, an error indication is		dtlstmSessionOpenErrors is incremented, an error indication is
	returned, and session establishment processing stops.		returned, and session establishment processing stops.
	3) Once the secure session is established and both sides have been		3) Once the secure session is established and both sides have been
	authenticated, the DTLS server side of the connection identifies		authenticated, certificate validation and identity expectations
	the authenticated identity from the DTLS client's principal		are performed.
	certificate using the dtlstmCertificateToSNTable mapping table
	and records this in the tmStateReference cache as tmSecurityName.
	4) The DTLS client side of the connection SHOULD verify that		a) The DTLS server side of the connection identifies the
	authenticated identity of the DTLS server's certificate is the		authenticated identity from the DTLS client's principal
	expected identity and MUST do so if the application is a		certificate using the dtlstmCertificateToSNTable mapping
	Notification Generator. If strong authentication is desired then		table and records this in the tmStateReference cache as
	DTLS server certificate MUST always be verified and checked		tmSecurityName. If this verification fails in any way (for
	against the expected identity. DTLS provides assurance that the		example because of failures in cryptographic verification or
	authenticated identity has been signed by a trusted configured		the lack of an appropriate row in the
	certificate authority.		dtlstmCertificateToSNTable) then the session establishment
			MUST fail, the dtlstmSessionInvalidClientCertificates object
			is incremented and processing is stopped.
	5) The DTLS-specific session identifier is passed to the DTLS		b) The DTLS client side of the connection SHOULD verify that
			authenticated identity of the DTLS server's certificate is
			the expected identity and MUST do so if the client
			application is a Notification Generator. If strong
			authentication is desired then the DTLS server certificate
			MUST always be verified and checked against the expected
			identity. Methods for doing this are described in
			[I-D.hodges-server-ident-check]. DTLS provides assurance
			that the authenticated identity has been signed by a trusted
			configured certificate authority. If verification of the
			server's certificate fails in any way (for example because of
			failures in cryptographic verification or the presented
			identity was not the expected identity) then the session
			establishment MUST fail, the
			dtlstmSessionInvalidServerCertificates object is incremented
			and processing is stopped.
			4) The DTLS-specific session identifier is passed to the DTLS
	Transport Model and associated with the tmStateReference cache		Transport Model and associated with the tmStateReference cache
	entry to indicate that the session has been established		entry to indicate that the session has been established
	successfully and to point to a specific DTLS session for future		successfully and to point to a specific DTLS session for future
	use.		use.
	5.4. Closing a Session		5.4. Closing a Session
	The DTLS Transport Model provides the following primitive to close a		The DTLS Transport Model provides the following primitive to close a
	session:		session:
	skipping to change at page 30, line 4 ¶		skipping to change at page 36, line 6 ¶
	This MIB module is for managing DTLS Transport Model information.		This MIB module is for managing DTLS Transport Model information.
	6.5.1. MIB Modules Required for IMPORTS		6.5.1. MIB Modules Required for IMPORTS
	The following MIB module imports items from SNMPV2-SMI [RFC2578],		The following MIB module imports items from SNMPV2-SMI [RFC2578],
	SNMPV2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB		SNMPV2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB
	[RFC3413] and SNMP-CONF [RFC2580].		[RFC3413] and SNMP-CONF [RFC2580].
	7. MIB Module Definition		7. MIB Module Definition
	DTLSTM-MIB DEFINITIONS ::= BEGIN
	IMPORTS		DTLSTM-MIB DEFINITIONS ::= BEGIN
	MODULE-IDENTITY, OBJECT-TYPE,
	OBJECT-IDENTITY, snmpModules, snmpDomains,
	Counter32, Unsigned32
	FROM SNMPv2-SMI
	TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType
	FROM SNMPv2-TC
	MODULE-COMPLIANCE, OBJECT-GROUP
	FROM SNMPv2-CONF
	SnmpAdminString
	FROM SNMP-FRAMEWORK-MIB
	snmpTargetParamsEntry
	FROM SNMP-TARGET-MIB
	;
	dtlstmMIB MODULE-IDENTITY		IMPORTS
	LAST-UPDATED "200807070000Z"		MODULE-IDENTITY, OBJECT-TYPE,
	ORGANIZATION " "		OBJECT-IDENTITY, snmpModules, snmpDomains,
	CONTACT-INFO "WG-EMail:		Counter32, Unsigned32
	Subscribe:		FROM SNMPv2-SMI
			TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType
			FROM SNMPv2-TC
			MODULE-COMPLIANCE, OBJECT-GROUP
			FROM SNMPv2-CONF
			SnmpAdminString
			FROM SNMP-FRAMEWORK-MIB
			snmpTargetParamsEntry
			FROM SNMP-TARGET-MIB
			;
	Chairs:		dtlstmMIB MODULE-IDENTITY
	Co-editors:		LAST-UPDATED "200807070000Z"
	"		ORGANIZATION " "
			CONTACT-INFO "WG-EMail:
			Subscribe:
	DESCRIPTION "The DTLS Transport Model MIB		Chairs:
			Co-editors:
			"
	Copyright (C) The IETF Trust (2007). This		DESCRIPTION "The DTLS Transport Model MIB
	version of this MIB module is part of RFC XXXX;
	see the RFC itself for full legal notices.
	-- NOTE to RFC editor: replace XXXX with actual RFC number
	-- for this document and remove this note
	"
	REVISION "200807070000Z"		Copyright (C) The IETF Trust (2008). This
	DESCRIPTION "The initial version, published in RFC XXXX.		version of this MIB module is part of RFC XXXX;
	-- NOTE to RFC editor: replace XXXX with actual RFC number		see the RFC itself for full legal notices."
	-- for this document and remove this note		-- NOTE to RFC editor: replace XXXX with actual RFC number
	"		-- for this document and remove this note
	- for this document and remove this note		REVISION "200807070000Z"
	::= { snmpModules xxxx }		DESCRIPTION "The initial version, published in RFC XXXX."
	-- RFC Ed.: replace xxxx with IANA-assigned number and		-- NOTE to RFC editor: replace XXXX with actual RFC number
	-- remove this note		-- for this document and remove this note
	- <span class="insert">for this document and</span> remove this note		::= { snmpModules xxxx }
	-- ************************************************		-- RFC Ed.: replace xxxx with IANA-assigned number and
	-- subtrees of the SNMP-DTLS-TM-MIB		-- remove this note
	-- ************************************************
	dtlstmNotifications OBJECT IDENTIFIER ::= { dtlstmMIB 0 }		-- ************************************************
	dtlstmObjects OBJECT IDENTIFIER ::= { dtlstmMIB 1 }		-- subtrees of the SNMP-DTLS-TM-MIB
	dtlstmConformance OBJECT IDENTIFIER ::= { dtlstmMIB 2 }		-- ************************************************
	-- ************************************************		dtlstmNotifications OBJECT IDENTIFIER ::= { dtlstmMIB 0 }
	-- Objects		dtlstmObjects OBJECT IDENTIFIER ::= { dtlstmMIB 1 }
	-- ************************************************		dtlstmConformance OBJECT IDENTIFIER ::= { dtlstmMIB 2 }
	snmpDTLSDomain OBJECT-IDENTITY		-- ************************************************
	STATUS current		-- Objects
	DESCRIPTION		-- ************************************************
	"The SNMP over DTLS transport domain. The corresponding
	transport address is of type SnmpDTLSAddress.
	When an SNMP entity uses the snmpDTLSDomain transport		snmpDTLSDomain OBJECT-IDENTITY
	model, it must be capable of accepting messages up to		STATUS current
	the maximum MTU size for an interface it supports, minus the		DESCRIPTION
	needed IP, UDP, DTLS and other protocol overheads."		"The SNMP over DTLS transport domain. The corresponding
	::= { snmpDomains yy }		transport address is of type SnmpDTLSAddress.
	-- RFC Ed.: replace yy with IANA-assigned number and		When an SNMP entity uses the snmpDTLSDomain transport
	-- remove this note		model, it must be capable of accepting messages up to
			the maximum MTU size for an interface it supports, minus the
			needed IP, UDP, DTLS and other protocol overheads.
	SnmpDTLSAddress ::= TEXTUAL-CONVENTION		The securityName prefix to be associated with the
	DISPLAY-HINT "1a"		snmpDTLSDomain is 'dtls'. This prefix may be used by
	STATUS current		security models or other components to identify what secure
	DESCRIPTION		transport infrastructure authenticated a securityName."
	"Represents a UDP connection address for an IPv4 address,
	an IPv6 address or an ASCII encoded host name and port
	number.
	The hostname must be encoded in ASCII, as specified in		::= { snmpDomains yy }
	RFC3490 (Internationalizing Domain Names in Applications)
	followed by a colon ':' (ASCII character 0x3A) and a
	decimal port number in ASCII. The name SHOULD be fully
	qualified whenever possible.
	An IPv4 address must be a dotted decimal format followed by		-- RFC Ed.: Please replace the I-D reference with a proper one once it
	a colon ':' (ASCII character 0x3A) and a decimal port		-- has been published. Note: xml2rfc doesn't handle refs within artwork
	number in ASCII.
	An IPv6 address must be a colon separated format,		-- RFC Ed.: replace yy with IANA-assigned number and
	surrounded by square brackets (ASCII characters 0x5B and		-- remove this note
	0x5D), followed by a colon ':' (ASCII character 0x3A) and a
	decimal port number in ASCII.
	Values of this textual convention may not be directly		-- RFC Ed.: replace 'dtls' with the actual IANA assigned prefix string
	usable as transport-layer addressing information, and may		-- if 'dtls' is not assigned to this document.
	require run-time resolution. As such, applications that
	write them must be prepared for handling errors if such
	values are not supported, or cannot be resolved (if
	resolution occurs at the time of the management operation).
	The DESCRIPTION clause of TransportAddress objects that may		SnmpDTLSAddress ::= TEXTUAL-CONVENTION
	have snmpDTLSAddress values must fully describe how (and		DISPLAY-HINT "1a"
	when) such names are to be resolved to IP addresses and		STATUS current
	vice versa.		DESCRIPTION
			"Represents a UDP connection address for an IPv4 address, an
			IPv6 address or an ASCII encoded host name and port number.
	This textual convention SHOULD NOT be used directly in		The hostname must be encoded in ASCII, as specified in RFC3490
	object definitions since it restricts addresses to a		(Internationalizing Domain Names in Applications) followed by
	specific format. However, if it is used, it MAY be used		a colon ':' (ASCII character 0x3A) and a decimal port number
	either on its own or in conjunction with		in ASCII. The name SHOULD be fully qualified whenever
	TransportAddressType or TransportDomain as a pair.		possible.
	When this textual convention is used as a syntax of an		An IPv4 address must be a dotted decimal format followed by a
	index object, there may be issues with the limit of 128		colon ':' (ASCII character 0x3A) and a decimal port number in
	sub-identifiers specified in SMIv2, STD 58. It is		ASCII.
	RECOMMENDED that all MIB documents using this textual
	convention make explicit any limitations on index component
	lengths that management software must observe. This may be
	done either by including SIZE constraints on the index
	components or by specifying applicable constraints in the
	conceptual row DESCRIPTION clause or in the surrounding
	documentation."
	SYNTAX OCTET STRING (SIZE (1..255))
	-- The dtlstmSession Group		An IPv6 address must be a colon separated format, surrounded
			by square brackets (ASCII characters 0x5B and 0x5D), followed
			by a colon ':' (ASCII character 0x3A) and a decimal port
			number in ASCII.
	dtlstmSession OBJECT IDENTIFIER ::= { dtlstmObjects 1 }		Values of this textual convention may not be directly usable
			as transport-layer addressing information, and may require
			run-time resolution. As such, applications that write them
			must be prepared for handling errors if such values are not
			supported, or cannot be resolved (if resolution occurs at the
			time of the management operation).
	dtlstmSessionOpens OBJECT-TYPE		The DESCRIPTION clause of TransportAddress objects that may
	SYNTAX Counter32		have snmpDTLSAddress values must fully describe how (and when)
	MAX-ACCESS read-only		such names are to be resolved to IP addresses and vice versa.
	STATUS current
	DESCRIPTION "The number of times an openSession() request has been
	executed, whether it succeeded or failed."
	::= { dtlstmSession 1 }
	dtlstmSessionCloses OBJECT-TYPE		This textual convention SHOULD NOT be used directly in object
	SYNTAX Counter32		definitions since it restricts addresses to a specific
	MAX-ACCESS read-only		format. However, if it is used, it MAY be used either on its
	STATUS current		own or in conjunction with TransportAddressType or
	DESCRIPTION "The number of times a closeSession() request has been		TransportDomain as a pair.
	executed, whether it succeeded or failed."
	::= { dtlstmSession 2 }
	dtlstmSessionOpenErrors OBJECT-TYPE		When this textual convention is used as a syntax of an index
	SYNTAX Counter32		object, there may be issues with the limit of 128
	MAX-ACCESS read-only		sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED
	STATUS current		that all MIB documents using this textual convention make
	DESCRIPTION "The number of times an openSession() request		explicit any limitations on index component lengths that
	failed to open a Session, for any reason."		management software must observe. This may be done either by
	::= { dtlstmSession 3 }		including SIZE constraints on the index components or by
			specifying applicable constraints in the conceptual row
			DESCRIPTION clause or in the surrounding documentation."
			SYNTAX OCTET STRING (SIZE (1..255))
	dtlstmSessionNoAvailableSessions OBJECT-TYPE		-- The dtlstmSession Group
	SYNTAX Counter32
	MAX-ACCESS read-only
	STATUS current
	DESCRIPTION "The number of times an outgoing message was dropped
	because the session associated with the passed
	tmStateReference was no longer (or was never)
	available."
	::= { dtlstmSession 4 }
	-- Configuration Objects		dtlstmSession OBJECT IDENTIFIER ::= { dtlstmObjects 1 }
	dtlstmConfig OBJECT IDENTIFIER ::= { dtlstmObjects 2 }		dtlstmSessionOpens OBJECT-TYPE
			SYNTAX Counter32
			MAX-ACCESS read-only
			STATUS current
			DESCRIPTION
			"The number of times an openSession() request has been
			executed as an SSH client, whether it succeeded or failed."
			::= { dtlstmSession 1 }
	-- Certificate mapping		dtlstmSessionCloses OBJECT-TYPE
			SYNTAX Counter32
			MAX-ACCESS read-only
			STATUS current
			DESCRIPTION
			"The number of times a closeSession() request has been
			executed as an SSH client, whether it succeeded or failed."
			::= { dtlstmSession 2 }
	dtlstmCertificateMapping OBJECT IDENTIFIER ::= { dtlstmConfig 1 }		dtlstmSessionOpenErrors OBJECT-TYPE
			SYNTAX Counter32
			MAX-ACCESS read-only
			STATUS current
			DESCRIPTION
			"The number of times an openSession() request failed to open a
			session as a SSH client, for any reason."
			::= { dtlstmSession 3 }
	dtlstmCertificateToSNCount OBJECT-TYPE		dtlstmSessionNoAvailableSessions OBJECT-TYPE
	SYNTAX Unsigned32		SYNTAX Counter32
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A count of the number of entries in the		"The number of times an outgoing message was dropped because
	dtlstmCertificateToSNTable"		the session associated with the passed tmStateReference was no
	::= { dtlstmCertificateMapping 1 }		longer (or was never) available."
			::= { dtlstmSession 4 }
	dtlstmCertificateToSNTableLastChanged OBJECT-TYPE		dtlstmSessionInvalidClientCertificates OBJECT-TYPE
	SYNTAX TimeStamp		SYNTAX Counter32
	MAX-ACCESS read-only		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The value of sysUpTime.0 when the dtlstmCertificateToSNTable		"The number of times an incoming session was not established
	was last modified through any means, or 0 if it has not been		on an SSH server because the presented client certificate was
	modified since the command responder was started."		invalid. Reasons for invalidation includes, but is not
	::= { dtlstmCertificateMapping 2 }		limited to, crypographic validation failures and lack of a
			suitable mapping row in the dtlstmCertificateToSNTable."
			::= { dtlstmSession 5 }
	dtlstmCertificateToSNTable OBJECT-TYPE		dtlstmSessionInvalidServerCertificates OBJECT-TYPE
	SYNTAX SEQUENCE OF DtlstmCertificateToSNEntry		SYNTAX Counter32
	MAX-ACCESS not-accessible		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A table listing the X.509 certificates known to the entity		"The number of times an outgoing session was not established
	and the associated method for determining the SNMPv3 security		on an SSH client because the presented server certificate was
	name from a certificate.		invalid. Reasons for invalidation includes, but is not
			limited to, crypographic validation failures and an unexpected
			presented certificate identity."
			::= { dtlstmSession 6 }
	On an incoming DTLS/SNMP connection the client's presented		dtlstmDTLSProtectionErrors OBJECT-TYPE
	certificate should be examined and validated based on		SYNTAX Counter32
	an established trusted CA certificate or self-signed public		MAX-ACCESS read-only
	certificate. This table does not provide		STATUS current
	a mechanism for uploading the certificates as that is expected		DESCRIPTION
	to occur through an out-of-band transfer.		"The number of times DTLS processing resulted in a message
			being discarded because it failed its integrity test,
			decryption processing or other DTLS processing."
			::= { dtlstmSession 7 }
	Once the authenticity of the certificate has been verified,		-- Configuration Objects
	this table can be consulted to determine the appropriate
	securityName to identify the remote connection. This is done
	by comparing the issuer's distinguished name against the
	dtlstmCertDN value. If a matching entry is found then the
	securityName is selected based on the dtlstmCertMapType,
	dtlstmCertSubject and dtlstmCertSecurityName fields and the
	resulting securityName is used to identify the other side of
	the DTLS connection.
	Users are encouraged to make use of certificates with		dtlstmConfig OBJECT IDENTIFIER ::= { dtlstmObjects 2 }
	CommonName fields that can be used as securityNames so that a
	single root CA certificate can allow all child certificate's
	CommonName to map directly to a securityName via a 1:1
	transformation. However, this table is flexible enough to
	allow for situations where existing an existing deployed
	certificate infrastructures dose not provide adequate
	CommonName values for use as SNMPv3 securityNames."
	::= { dtlstmCertificateMapping 3 }
	dtlstmCertificateToSNEntry OBJECT-TYPE		-- Certificate mapping
	SYNTAX DtlstmCertificateToSNEntry
	MAX-ACCESS not-accessible
	STATUS current
	DESCRIPTION
	"A row in the dtlstmCertificateToSNTable that specifies a
	mapping for an incoming DTLS certificate to a securityName to
	use for the connection."
	INDEX { dtlstmCertID }
	::= { dtlstmCertificateToSNTable 1 }
	DtlstmCertificateToSNEntry ::= SEQUENCE {		dtlstmCertificateMapping OBJECT IDENTIFIER ::= { dtlstmConfig 1 }
	dtlstmCertID Unsigned32,
	dtlstmCertIssuerDN OCTET STRING,
	dtlstmCertMapType INTEGER,
	dtlstmCertSecurityName SnmpAdminString,
	dtlstmCertStorageType StorageType,
	dtlstmCertRowStatus RowStatus
	}
	dtlstmCertID OBJECT-TYPE		dtlstmCertificateToSNCount OBJECT-TYPE
	SYNTAX Unsigned32		SYNTAX Unsigned32
	MAX-ACCESS not-accessible		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A unique arbitrary number index for a given certificate		"A count of the number of entries in the
	entry."		dtlstmCertificateToSNTable"
	::= { dtlstmCertificateToSNEntry 1 }		::= { dtlstmCertificateMapping 1 }
	dtlstmCertIssuerDN OBJECT-TYPE		dtlstmCertificateToSNTableLastChanged OBJECT-TYPE
	SYNTAX OCTET STRING		SYNTAX TimeStamp
	MAX-ACCESS read-create		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The issuer's 'distinguished name' field matching the		"The value of sysUpTime.0 when the dtlstmCertificateToSNTable
	certificate to be used for this mapping entry.		was last modified through any means, or 0 if it has not been
	"		modified since the command responder was started."
	-- XXX: allow specification via serial no too?		::= { dtlstmCertificateMapping 2 }
	::= { dtlstmCertificateToSNEntry 2 }
	dtlstmCertMapType OBJECT-TYPE		dtlstmCertificateToSNTable OBJECT-TYPE
	SYNTAX INTEGER { specified(1), byCN(2) }		SYNTAX SEQUENCE OF DtlstmCertificateToSNEntry
	MAX-ACCESS read-create		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The mapping type used to obtain the securityName from the		"A table listing the X.509 certificates known to the entity
	certificate. The possible values of use and their usage		and the associated method for determining the SNMPv3 security
	methods are defined as follows:		name from a certificate.
	specified(1): The securityName that should be used locally to		On an incoming DTLS/SNMP connection the client's presented
	identify the remote entity is directly specified		certificate should be examined and validated based on
	in the dtlstmCertSecurityName column from this		an established trusted CA certificate or self-signed public
	table.		certificate. This table does not provide
			a mechanism for uploading the certificates as that is expected
			to occur through an out-of-band transfer.
	byCN(2): The securityName that should be used locally to		Once the authenticity of the certificate has been verified,
	identify the remote entity should be taken from		this table can be consulted to determine the appropriate
	the CommonName portion of the Subject field from		securityName to identify the remote connection. This is done
	the X.509 certificate."		by comparing the issuer's distinguished name against the
	DEFVAL { specified }		dtlstmCertDN value. If a matching entry is found then the
	::= { dtlstmCertificateToSNEntry 3 }		securityName is selected based on the dtlstmCertMapType,
			dtlstmCertSubject and dtlstmCertSecurityName fields and the
			resulting securityName is used to identify the other side of
			the DTLS connection.
	dtlstmCertSecurityName OBJECT-TYPE		Users are encouraged to make use of certificates with
	SYNTAX SnmpAdminString (SIZE(0..32))		CommonName fields that can be used as securityNames so that a
	MAX-ACCESS read-create		single root CA certificate can allow all child certificate's
	STATUS current		CommonName to map directly to a securityName via a 1:1
	DESCRIPTION		transformation. However, this table is flexible enough to
	"The securityName that the session should use if the		allow for situations where existing an existing deployed
	dtlstmCertMapType is set to specified(1), otherwise the value		certificate infrastructures dose not provide adequate
	in this column should be ignored. If dtlstmCertMapType is set		CommonName values for use as SNMPv3 securityNames."
	to specifed(1) and this column contains a zero-length string		::= { dtlstmCertificateMapping 3 }
	(which is not a legal securityName value) this row is
	effectively disabled and the match will not be considered
	successful."
	DEFVAL { "" }
	::= { dtlstmCertificateToSNEntry 4 }
	dtlstmCertStorageType OBJECT-TYPE		dtlstmCertificateToSNEntry OBJECT-TYPE
	SYNTAX StorageType		SYNTAX DtlstmCertificateToSNEntry
	MAX-ACCESS read-create		MAX-ACCESS not-accessible
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The storage type for this conceptual row. Conceptual rows		"A row in the dtlstmCertificateToSNTable that specifies a
	having the value 'permanent' need not allow write-access to		mapping for an incoming DTLS certificate to a securityName to
	any columnar objects in the row."		use for the connection."
	DEFVAL { nonVolatile }		INDEX { dtlstmCertID }
	::= { dtlstmCertificateToSNEntry 5 }		::= { dtlstmCertificateToSNTable 1 }
	dtlstmCertRowStatus OBJECT-TYPE		DtlstmCertificateToSNEntry ::= SEQUENCE {
	SYNTAX RowStatus		dtlstmCertID Unsigned32,
	MAX-ACCESS read-create		dtlstmCertIssuerDN OCTET STRING,
	STATUS current		dtlstmCertMapType INTEGER,
	DESCRIPTION		dtlstmCertSecurityName SnmpAdminString,
	"The status of this conceptual row. This object may be used		dtlstmCertStorageType StorageType,
	to create or remove rows from this table.		dtlstmCertRowStatus RowStatus
			}
	The value of this object has no effect on whether		dtlstmCertID OBJECT-TYPE
	other objects in this conceptual row can be modified."		SYNTAX Unsigned32
	::= { dtlstmCertificateToSNEntry 6 }		MAX-ACCESS not-accessible
			STATUS current
			DESCRIPTION
			"A unique arbitrary number index for a given certificate
			entry."
			::= { dtlstmCertificateToSNEntry 1 }
	-- Maps securityNames to certificates for use by the SNMP-TARGET-MIB		dtlstmCertIssuerDN OBJECT-TYPE
			SYNTAX OCTET STRING
			MAX-ACCESS read-create
			STATUS current
			DESCRIPTION
			"The issuer's 'distinguished name' field matching the
			certificate to be used for this mapping entry.
			"
			-- XXX: allow specification via serial no too?
			::= { dtlstmCertificateToSNEntry 2 }
	dtlstmParamsCount OBJECT-TYPE		dtlstmCertMapType OBJECT-TYPE
	SYNTAX Unsigned32		SYNTAX INTEGER { specified(1), byCN(2) }
	MAX-ACCESS read-only		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A count of the number of entries in the		"The mapping type used to obtain the securityName from the
	dtlstmParamsTable"		certificate. The possible values of use and their usage
			methods are defined as follows:
	::= { dtlstmCertificateMapping 4 }		specified(1): The securityName that should be used locally to
			identify the remote entity is directly specified
			in the dtlstmCertSecurityName column from this
			table.
	dtlstmParamsTableLastChanged OBJECT-TYPE		byCN(2): The securityName that should be used locally to
	SYNTAX TimeStamp		identify the remote entity should be taken from
	MAX-ACCESS read-only		the CommonName portion of the Subject field from
	STATUS current		the X.509 certificate."
	DESCRIPTION		DEFVAL { specified }
	"The value of sysUpTime.0 when the dtlstmParamsTable		::= { dtlstmCertificateToSNEntry 3 }
	was last modified through any means, or 0 if it has not been
	modified since the command responder was started."
	::= { dtlstmCertificateMapping 5 }
	dtlstmParamsTable OBJECT-TYPE		dtlstmCertSecurityName OBJECT-TYPE
	SYNTAX SEQUENCE OF DtlstmParamsEntry		SYNTAX SnmpAdminString (SIZE(0..32))
	MAX-ACCESS not-accessible		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"This table augments the SNMP-TARGET-MIB's		"The securityName that the session should use if the
	snmpTargetParamsTable with additional a DTLS client-side		dtlstmCertMapType is set to specified(1), otherwise the value
	certificate certificate identifier to use when establishing		in this column should be ignored. If dtlstmCertMapType is set
	new DTLS connections."		to specifed(1) and this column contains a zero-length string
	::= { dtlstmCertificateMapping 6 }		(which is not a legal securityName value) this row is
			effectively disabled and the match will not be considered
			successful."
			DEFVAL { "" }
			::= { dtlstmCertificateToSNEntry 4 }
	dtlstmParamsEntry OBJECT-TYPE		dtlstmCertStorageType OBJECT-TYPE
	SYNTAX DtlstmParamsEntry		SYNTAX StorageType
	MAX-ACCESS not-accessible		MAX-ACCESS read-create
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"A conceptual row containing the certificate subject name for		"The storage type for this conceptual row. Conceptual rows
	a given snmpTargetParamsEntry. The values in this row should		having the value 'permanent' need not allow write-access to
	be ignored if not the connection that needs to be established,		any columnar objects in the row."
	as indicated by the SNMP-TARGET-MIB infrastructure, is not a		DEFVAL { nonVolatile }
	DTLS based connection."		::= { dtlstmCertificateToSNEntry 5 }
	AUGMENTS { snmpTargetParamsEntry }
	::= { dtlstmParamsTable 1 }
	DtlstmParamsEntry ::= SEQUENCE {		dtlstmCertRowStatus OBJECT-TYPE
	dtlstmParamsSubject OCTET STRING,		SYNTAX RowStatus
	dtlstmParamsStorageType StorageType,		MAX-ACCESS read-create
	dtlstmParamsRowStatus RowStatus		STATUS current
	}		DESCRIPTION
			"The status of this conceptual row. This object may be used
			to create or remove rows from this table.
	dtlstmParamsSubject OBJECT-TYPE		The value of this object has no effect on whether
	SYNTAX OCTET STRING (SIZE(1..4096))		other objects in this conceptual row can be modified."
	MAX-ACCESS read-create		::= { dtlstmCertificateToSNEntry 6 }
	STATUS current
	DESCRIPTION
	"The subject name of the locally-held X.509 certificate that
	should be used when initiating a DTLS connection as a DTLS
	client."
	::= { dtlstmParamsEntry 1 }
	dtlstmParamsStorageType OBJECT-TYPE		-- Maps securityNames to certificates for use by the SNMP-TARGET-MIB
	SYNTAX StorageType
	MAX-ACCESS read-create
	STATUS current
	DESCRIPTION
	"The storage type for this conceptual row. Conceptual rows
	having the value 'permanent' need not allow write-access to
	any columnar objects in the row."
	DEFVAL { nonVolatile }
	::= { dtlstmParamsEntry 2 }
	dtlstmParamsRowStatus OBJECT-TYPE		dtlstmParamsCount OBJECT-TYPE
	SYNTAX RowStatus		SYNTAX Unsigned32
	MAX-ACCESS read-create		MAX-ACCESS read-only
	STATUS current		STATUS current
	DESCRIPTION		DESCRIPTION
	"The status of this conceptual row. This object may be used		"A count of the number of entries in the
	to create or remove rows from this table.		dtlstmParamsTable"
	The value of this object has no effect on whether		::= { dtlstmCertificateMapping 4 }
	other objects in this conceptual row can be modified."
	::= { dtlstmParamsEntry 3 }
	-- ************************************************		dtlstmParamsTableLastChanged OBJECT-TYPE
	-- dtlstmMIB - Conformance Information		SYNTAX TimeStamp
	-- ************************************************		MAX-ACCESS read-only
			STATUS current
			DESCRIPTION
			"The value of sysUpTime.0 when the dtlstmParamsTable
			was last modified through any means, or 0 if it has not been
			modified since the command responder was started."
			::= { dtlstmCertificateMapping 5 }
	dtlstmCompliances OBJECT IDENTIFIER ::= { dtlstmConformance 1 }		dtlstmParamsTable OBJECT-TYPE
			SYNTAX SEQUENCE OF DtlstmParamsEntry
			MAX-ACCESS not-accessible
			STATUS current
			DESCRIPTION
			"This table augments the SNMP-TARGET-MIB's
			snmpTargetParamsTable with additional a DTLS client-side
			certificate certificate identifier to use when establishing
			new DTLS connections."
			::= { dtlstmCertificateMapping 6 }
	dtlstmGroups OBJECT IDENTIFIER ::= { dtlstmConformance 2 }		dtlstmParamsEntry OBJECT-TYPE
			SYNTAX DtlstmParamsEntry
			MAX-ACCESS not-accessible
			STATUS current
			DESCRIPTION
			"A conceptual row containing the certificate subject name for
			a given snmpTargetParamsEntry. The values in this row should
			be ignored if not the connection that needs to be established,
			as indicated by the SNMP-TARGET-MIB infrastructure, is not a
			DTLS based connection."
			AUGMENTS { snmpTargetParamsEntry }
			::= { dtlstmParamsTable 1 }
	-- ************************************************		DtlstmParamsEntry ::= SEQUENCE {
	-- Compliance statements		dtlstmParamsSubject OCTET STRING,
	-- ************************************************		dtlstmParamsStorageType StorageType,
			dtlstmParamsRowStatus RowStatus
			}
	dtlstmCompliance MODULE-COMPLIANCE		dtlstmParamsSubject OBJECT-TYPE
	STATUS current		SYNTAX OCTET STRING (SIZE(1..4096))
	DESCRIPTION		MAX-ACCESS read-create
	"The compliance statement for SNMP engines that support the		STATUS current
	SNMP-DTLS-TM-MIB"		DESCRIPTION
	MODULE		"The subject name of the locally-held X.509 certificate that
	MANDATORY-GROUPS { dtlstmStatsGroup,		should be used when initiating a DTLS connection as a DTLS
	dtlstmIncomingGroup, dtlstmOutgoingGroup }		client."
	::= { dtlstmCompliances 1 }		::= { dtlstmParamsEntry 1 }
	-- ************************************************		dtlstmParamsStorageType OBJECT-TYPE
	-- Units of conformance		SYNTAX StorageType
	-- ************************************************		MAX-ACCESS read-create
	dtlstmStatsGroup OBJECT-GROUP		STATUS current
	OBJECTS {		DESCRIPTION
			"The storage type for this conceptual row. Conceptual rows
			having the value 'permanent' need not allow write-access to
			any columnar objects in the row."
			DEFVAL { nonVolatile }
			::= { dtlstmParamsEntry 2 }
			dtlstmParamsRowStatus OBJECT-TYPE
			SYNTAX RowStatus
			MAX-ACCESS read-create
			STATUS current
			DESCRIPTION
			"The status of this conceptual row. This object may be used
			to create or remove rows from this table.
			The value of this object has no effect on whether
			other objects in this conceptual row can be modified."
			::= { dtlstmParamsEntry 3 }
			-- ************************************************
			-- dtlstmMIB - Conformance Information
			-- ************************************************
			dtlstmCompliances OBJECT IDENTIFIER ::= { dtlstmConformance 1 }
			dtlstmGroups OBJECT IDENTIFIER ::= { dtlstmConformance 2 }
			-- ************************************************
			-- Compliance statements
			-- ************************************************
			dtlstmCompliance MODULE-COMPLIANCE
			STATUS current
			DESCRIPTION
			"The compliance statement for SNMP engines that support the
			SNMP-DTLS-TM-MIB"
			MODULE
			MANDATORY-GROUPS { dtlstmStatsGroup,
			dtlstmIncomingGroup, dtlstmOutgoingGroup }
			::= { dtlstmCompliances 1 }
			-- ************************************************
			-- Units of conformance
			-- ************************************************
			dtlstmStatsGroup OBJECT-GROUP
			OBJECTS {
	dtlstmSessionOpens,		dtlstmSessionOpens,
	dtlstmSessionCloses,		dtlstmSessionCloses,
	dtlstmSessionOpenErrors,		dtlstmSessionOpenErrors,
	dtlstmSessionNoAvailableSessions		dtlstmSessionNoAvailableSessions,
	}		dtlstmSessionInvalidClientCertificates,
	STATUS current		dtlstmSessionInvalidServerCertificates,
	DESCRIPTION "A collection of objects for maintaining		dtlstmDTLSProtectionErrors
	statistical information of an SNMP engine which		}
	implements the SNMP DTLS Transport Model."		STATUS current
	::= { dtlstmGroups 1 }		DESCRIPTION
			"A collection of objects for maintaining
			statistical information of an SNMP engine which
			implements the SNMP DTLS Transport Model."
			::= { dtlstmGroups 1 }
	dtlstmIncomingGroup OBJECT-GROUP		dtlstmIncomingGroup OBJECT-GROUP
	OBJECTS {		OBJECTS {
	dtlstmCertificateToSNCount,		dtlstmCertificateToSNCount,
	dtlstmCertificateToSNTableLastChanged,		dtlstmCertificateToSNTableLastChanged,
	dtlstmCertIssuerDN,		dtlstmCertIssuerDN,
	dtlstmCertMapType,		dtlstmCertMapType,
	dtlstmCertSecurityName,		dtlstmCertSecurityName,
	dtlstmCertStorageType,		dtlstmCertStorageType,
	dtlstmCertRowStatus		dtlstmCertRowStatus
	}		}
	STATUS current		STATUS current
	DESCRIPTION "A collection of objects for maintaining		DESCRIPTION
	incoming connection certificate mappings to		"A collection of objects for maintaining
	securityNames of an SNMP engine which implements the		incoming connection certificate mappings to
	SNMP DTLS Transport Model."		securityNames of an SNMP engine which implements the
	::= { dtlstmGroups 2 }		SNMP DTLS Transport Model."
			::= { dtlstmGroups 2 }
	dtlstmOutgoingGroup OBJECT-GROUP		dtlstmOutgoingGroup OBJECT-GROUP
	OBJECTS {		OBJECTS {
	dtlstmParamsCount,		dtlstmParamsCount,
	dtlstmParamsTableLastChanged,		dtlstmParamsTableLastChanged,
	dtlstmParamsSubject,		dtlstmParamsSubject,
	dtlstmParamsStorageType,		dtlstmParamsStorageType,
	dtlstmParamsRowStatus		dtlstmParamsRowStatus
	}		}
	STATUS current		STATUS current
	DESCRIPTION "A collection of objects for maintaining		DESCRIPTION
	outgoing connection certificates to use when opening		"A collection of objects for maintaining
	connections as a result of SNMP-TARGET-MIB settings."		outgoing connection certificates to use when opening
	::= { dtlstmGroups 3 }		connections as a result of SNMP-TARGET-MIB settings."
			::= { dtlstmGroups 3 }
	END		END
	8. Operational Considerations		8. Operational Considerations
			This section discusses various operational aspects of the solution
			8.1. Sessions
	A session is discussed throughout this document as meaning a security		A session is discussed throughout this document as meaning a security
	association between the DTLS client and the DTLS server. State		association between the DTLS client and the DTLS server. State
	information for the sessions are maintained in each DTLSTM and this		information for the sessions are maintained in each DTLSTM and this
	information is created and destroyed as sessions are opened and		information is created and destroyed as sessions are opened and
	closed. Because of the connectionless nature of UDP, a "broken"		closed. Because of the connectionless nature of UDP, a "broken"
	session, one side up one side down, could result if one side of a		session, one side up one side down, could result if one side of a
	session is brought down abruptly (i.e., reboot, power outage, etc.).		session is brought down abruptly (i.e., reboot, power outage, etc.).
	Whenever possible, implementations SHOULD provide graceful session		Whenever possible, implementations SHOULD provide graceful session
	termination through the use of disconnect messages. Implementations		termination through the use of disconnect messages. Implementations
	SHOULD also have a system in place for dealing with "broken"		SHOULD also have a system in place for dealing with "broken"
	sessions.		sessions. Implementations SHOULD support the session resumption
			feature of TLS.
	To simplify session management it is RECOMMENDED that implementations		To simplify session management it is RECOMMENDED that implementations
	utilize two separate ports, one for Notification sessions and one for		utilize two separate ports, one for Notification sessions and one for
	Command sessions. If this implementation recommendation is followed,		Command sessions. If this implementation recommendation is followed,
	DTLS clients will always send REQUEST messages and DTLS servers will		DTLS clients will always send REQUEST messages and DTLS servers will
	always send RESPONSE messages. With this assertion, implementations		always send RESPONSE messages. With this assertion, implementations
	may be able to simplify "broken" session handling, session		may be able to simplify "broken" session handling, session
	resumption, and other aspects of session management such as		resumption, and other aspects of session management such as
	guaranteeing that Request- Response pairs use the same session.		guaranteeing that Request- Response pairs use the same session.
	Depending on the algorithms used for generation of the master session		Depending on the algorithms used for generation of the master session
	secret, the privacy and integrity algorithms used to protect		secret, the privacy and integrity algorithms used to protect
	messages, the environment of the session, the amount of data		messages, the environment of the session, the amount of data
	transferred, and the sensitivity of the data, a time-to-live (TTL)		transferred, and the sensitivity of the data, a time-to-live (TTL)
	value SHOULD be established for sessions. An upper limit of 24 hours		value SHOULD be established for sessions. An upper limit of 24 hours
	is suggested for this TTL value. The TTL value could be stored in		is suggested for this TTL value. The TTL value could be stored in
	the LCD and checked before passing a message to the DTLS session.		the LCD and checked before passing a message to the DTLS session.
			8.2. Notification Receiver Credential Selection
	When an SNMP engine needs to establish an outgoing session for		When an SNMP engine needs to establish an outgoing session for
	notifications, the snmpTargetParamsTable includes an entry for the		notifications, the snmpTargetParamsTable includes an entry for the
	snmpTargetParamsSecurityName of the target. However, the receiving		snmpTargetParamsSecurityName of the target. However, the receiving
	SNMP engine (Server) does not know which DTLS certificate to offer to		SNMP engine (Server) does not know which DTLS certificate to offer to
	the Client so that the tmSecurityName identity-authentication will be		the Client so that the tmSecurityName identity-authentication will be
	successful. The best solution would be to maintain a one-to-one		successful. The best solution would be to maintain a one-to-one
	mapping between certificates and incoming ports for notification		mapping between certificates and incoming ports for notification
	receivers, although other implementation dependent mechanisms may be		receivers, although other implementation dependent mechanisms may be
	used instead. This can be handled at the Notification Originator by		used instead. This can be handled at the Notification Originator by
	configuring the snmpTargetAddrTable (snmpTargetAddrTDomain and		configuring the snmpTargetAddrTable (snmpTargetAddrTDomain and
	snmpTargetAddrTAddress) and then requiring the receiving SNMP engine		snmpTargetAddrTAddress) and then requiring the receiving SNMP engine
	to monitor multiple incoming static ports based on which principals		to monitor multiple incoming static ports based on which principals
	are capable of receiving notifications. Implementations MAY also		are capable of receiving notifications. Implementations MAY also
	choose to designate a single Notification Receiver Principal to		choose to designate a single Notification Receiver Principal to
	receive all incoming TRAPS and INFORMS.		receive all incoming TRAPS and INFORMS.
			8.3. contextEngineID Discovery
			Because most Command Responders have contextEngineIDs that are
			identical to the USM securityEngineID, the USM provides Command
			Generators with the ability to discover a default contextEngineID to
			use. Because the DTLS transport does not make use of a discoverable
			securityEngineID like the USM does, it may be difficult for Command
			Generators to discover a suitable default contextEngineID.
			Implementations should consider offering another engineID discovery
			mechanism to continue providing Command Generators with a
			contextEngineID discovery mechanism. A recommended discovery
			solution is documented in [RFC5343].
	9. Security Considerations		9. Security Considerations
	This document describes a transport model that permits SNMP to		This document describes a transport model that permits SNMP to
	utilize DTLS security services. The security threats and how the		utilize DTLS security services. The security threats and how the
	DTLS transport model mitigates these threats are covered in detail		DTLS 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 Appendices D, E, and F of TLS 1.1 [RFC4346]. DTLS adds		described in Appendices D, E, and F of TLS 1.1 [RFC4346]. DTLS adds
	to the security considerations of TLS only because it is more		to the security considerations of TLS only because it is more
	vulnerable to denial of service attacks. A random cookie exchange		vulnerable to denial of service attacks. A random cookie exchange
	skipping to change at page 41, line 42 ¶		skipping to change at page 49, line 23 ¶
	server and authentication of the identity of the DTLS client. Access		server and authentication of the identity of the DTLS client. Access
	to MIB objects for the authenticated principal MUST be enforced by an		to MIB objects for the authenticated principal MUST be enforced by an
	access control subsystem (e.g. the VACM).		access control subsystem (e.g. the VACM).
	Authentication of the Command Generator principal's identity is		Authentication of the Command Generator principal's identity is
	important for use with the SNMP access control subsystem to ensure		important for use with the SNMP access control subsystem to ensure
	that only authorized principals have access to potentially sensitive		that only authorized principals have access to potentially sensitive
	data. The authenticated identity of the Command Generator		data. The authenticated identity of the Command Generator
	principal's certificate is mapped to an SNMP model-independent		principal's certificate is mapped to an SNMP model-independent
	securityName for use with SNMP access control, as discussed in		securityName for use with SNMP access control, as discussed in
	Section 4.3.4, Section 7 and other sections.		Section 4.5.3.4, Section 7 and other sections.
	Furthermore, the DTLS handshake only provides assurance that the		Furthermore, the DTLS handshake only provides assurance that the
	certificate of the authenticated identity has been signed by an		certificate of the authenticated identity has been signed by an
	configured accepted Certificate Authority. DTLS has no way to		configured accepted Certificate Authority. DTLS has no way to
	further authorize or reject access based on the authenticated		further authorize or reject access based on the authenticated
	identity. An Access Control Model (such as the VACM) provides access		identity. An Access Control Model (such as the VACM) provides access
	control and authorization of a Command Generator's requests to a		control and authorization of a Command Generator's requests to a
	Command Responder and a Notification Responder's authorization to		Command Responder and a Notification Responder's authorization to
	receive Notifications from a Notification Originator. However to		receive Notifications from a Notification Originator. However to
	avoid man-in-the-middle attacks both ends of the DTLS based		avoid man-in-the-middle attacks both ends of the DTLS based
	skipping to change at page 43, line 21 ¶		skipping to change at page 50, line 47 ¶
	http://www.iana.org/assignments/port-numbers registry which will		http://www.iana.org/assignments/port-numbers registry which will
	be the default port for SNMPTRAP over a DTLS Transport Model as		be the default port for SNMPTRAP over a DTLS Transport Model as
	defined in this document,		defined in this document,
	3. an SMI number under snmpDomains for the snmpDTLSDomain object		3. an SMI number under snmpDomains for the snmpDTLSDomain object
	identifier,		identifier,
	4. a SMI number under snmpModules, for the MIB module in this		4. a SMI number under snmpModules, for the MIB module in this
	document,		document,
			5. "dtls" as the corresponding prefix for the snmpDTLSDomain in the
			SNMP Transport Model registry;
	11. Acknowledgements		11. Acknowledgements
	This document closely follows and copies the Secure Shell Transport		This document closely follows and copies the Secure Shell Transport
	Model for SNMP defined by David Harrington and Joseph Salowey in		Model for SNMP defined by David Harrington and Joseph Salowey in
	[I-D.ietf-isms-secshell].		[I-D.ietf-isms-secshell].
	Large portions of this document are based on work that will be		This work was supported in part by the United States Department of
	acknowledge in a future version of the document once a proper		Defense. Large portions of this document are based on work by
	attribution list has been obtained.		General Dynamics C4 Systems and the following individuals: Brian
			Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John
			Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul,
			Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management		[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
	Protocol", RFC 2522, March 1999.		Protocol", RFC 2522, March 1999.
	skipping to change at page 44, line 48 ¶		skipping to change at page 52, line 34 ¶
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security", RFC 4347, April 2006.		Security", RFC 4347, April 2006.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
			[I-D.ietf-isms-transport-security-model]
			Harington, D., "Transport Security Model for SNMP".
	[I-D.ietf-isms-tmsm]		[I-D.ietf-isms-tmsm]
	Harington, D. and J. Schoenwaelder, "Transport Subsystem		Harington, D. and J. Schoenwaelder, "Transport Subsystem
	for the Simple Network Management Protocol (SNMP)".		for the Simple Network Management Protocol (SNMP)".
	[X509] Rivest, R., Shamir, A., and L. M. Adleman, "A Method for		[X509] Rivest, R., Shamir, A., and L. M. Adleman, "A Method for
	Obtaining Digital Signatures and Public-Key		Obtaining Digital Signatures and Public-Key
	Cryptosystems".		Cryptosystems".
	[AES] National Institute of Standards, "Specification for the		[AES] National Institute of Standards, "Specification for the
	Advanced Encryption Standard (AES)".		Advanced Encryption Standard (AES)".
	skipping to change at page 45, line 37 ¶		skipping to change at page 53, line 24 ¶
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, December 2005.		RFC 4303, December 2005.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	RFC 4306, December 2005.		RFC 4306, December 2005.
	[I-D.ietf-isms-secshell]		[I-D.ietf-isms-secshell]
	Harington, D. and J. Salowey, "Secure Shell Transport		Harington, D. and J. Salowey, "Secure Shell Transport
	Model for SNMP".		Model for SNMP".
			[RFC5343] Schoenwaelder, J., "Simple Network Management Protocol
			(SNMP) Context EngineID Discovery".
			[I-D.hodges-server-ident-check]
			Hodges, J. and B. Morgan, "Generic Server Identity Check".
	Appendix A. Target and Notificaton Configuration Example		Appendix A. Target and Notificaton 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:
	vacmSecurityToGroupTable		vacmSecurityToGroupTable
	vacmAccessTable		vacmAccessTable
	vacmViewTreeFamilyTable		vacmViewTreeFamilyTable
	The only table that needs to be discussed as particularly different		The only table that needs to be discussed as particularly different
	here is the vacmSecurityToGroupTable. This table is indexed by both		here is the vacmSecurityToGroupTable. This table is indexed by both
	the SNMPv3 security model and the security name. The security model,		the SNMPv3 security model and the security name. The security model,
	when DTLSTM is in use, should be XXX corresponding to the TMSM		when DTLSTM is in use, should be set to the value of XXX
	[I-D.ietf-isms-tmsm]. An example vacmSecurityToGroupTable row might		corresponding to the TSM [I-D.ietf-isms-transport-security-model].
	be filled out as follows (using a single SNMP SET request):		An example vacmSecurityToGroupTable row might be filled out as
			follows (using a single SNMP SET request):
	vacmSecurityModel = XXX:TMSM		vacmSecurityModel = XXX:TSM
	vacmSecurityName = "blueberry"		vacmSecurityName = "blueberry"
	vacmGroupaName = "administrators"		vacmGroupaName = "administrators"
	vacmSecurityToGroupStorageType = 3 (nonVolatile)		vacmSecurityToGroupStorageType = 3 (nonVolatile)
	vacmSecurityToGroupStatus = 4 (createAndGo)		vacmSecurityToGroupStatus = 4 (createAndGo)
			Note to RFC editor: replace XXX with the actual IANA-assigned number
			for the TSM security model and remove this note.
	This example will assume that the "administrators" group has been		This example will assume that the "administrators" group has been
	given proper permissions via rows in the vacmAccessTable and		given proper permissions via rows in the vacmAccessTable and
	vacmViewTreeFamilyTable.		vacmViewTreeFamilyTable.
	Depending on whether this VACM configuration is for a Command		Depending on whether this VACM configuration is for a Command
	Responder or a Command Generator the security name "blueberry" will		Responder or a Command Generator the security name "blueberry" will
	come from a few different locations.		come from a few different locations.
	For Notification Generator's performing authorization checks, the		For Notification Generator's performing authorization checks, the
	server's certificate must be verified against the expected		server's certificate must be verified against the expected
End of changes. 134 change blocks.
	671 lines changed or deleted		1051 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/