idnits 2.17.00 (12 Aug 2021) /tmp/idnits44688/draft-hardaker-isms-dtls-tm-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 448 has weird spacing: '...patcher v ...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 4820 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 2522 ** Downref: Normative reference to an Informational RFC: RFC 3410 ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: draft-ietf-isms-transport-security-model has been published as RFC 5591 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-transport-security-model' == Outdated reference: draft-ietf-isms-tmsm has been published as RFC 5590 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-tmsm' -- Possible downref: Non-RFC (?) normative reference: ref. 'X509' -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: draft-ietf-isms-secshell has been published as RFC 5592 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ISMS W. Hardaker 3 Internet-Draft Sparta, Inc. 4 Intended status: Standards Track March 9, 2009 5 Expires: September 10, 2009 7 Datagram Transport Layer Security Transport Model for SNMP 8 draft-hardaker-isms-dtls-tm-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 10, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document describes a Transport Model for the Simple Network 57 Management Protocol (SNMP), that uses the Datagram Transport Layer 58 Security (DTLS) protocol. The DTLS protocol provides authentication 59 and privacy services for SNMP applications. This document describes 60 how the DTLS Transport Model (DTLSTM) implements the needed features 61 of a SNMP Transport Subsystem to make this protection possible in an 62 interoperable way. 64 This transport model is designed to meet the security and operational 65 needs of network administrators, operate in environments where a 66 connectionless (e.g. UDP or SCTP) transport is preferred, and 67 integrates well into existing public keying infrastructures. 69 This document also defines a portion of the Management Information 70 Base (MIB) for monitoring and managing the DTLS Transport Model for 71 SNMP. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 7 77 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 78 2. The Datagram Transport Layer Security Protocol . . . . . . . . 8 79 2.1. The DTLS Record Protocol . . . . . . . . . . . . . . . . . 8 80 2.2. The DTLS Handshake Protocol . . . . . . . . . . . . . . . 9 81 2.3. SNMP requirements of DTLS . . . . . . . . . . . . . . . . 10 82 3. How the DTLSTM fits into the Transport Subsystem . . . . . . . 10 83 3.1. Security Capabilities of this Model . . . . . . . . . . . 12 84 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 12 85 3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 14 86 3.1.3. DTLS Sessions . . . . . . . . . . . . . . . . . . . . 15 87 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 15 88 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 16 89 4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 17 90 4.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 17 91 4.1.1. The Certificate Infrastructure . . . . . . . . . . . . 17 92 4.1.2. Provisioning for the Certificate . . . . . . . . . . . 18 93 4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 19 95 4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 19 96 4.3.2. SNMP Services for an Incoming Message . . . . . . . . 20 97 4.4. DTLS Services . . . . . . . . . . . . . . . . . . . . . . 21 98 4.4.1. Services for Establishing a Session . . . . . . . . . 21 99 4.4.2. DTLS Services for an Incoming Message . . . . . . . . 23 100 4.4.3. DTLS Services for an Outgoing Message . . . . . . . . 24 101 4.5. Cached Information and References . . . . . . . . . . . . 24 102 4.5.1. DTLS Transport Model Cached Information . . . . . . . 25 103 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 25 104 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 25 105 5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 25 106 5.1.2. Transport Processing for Incoming Messages . . . . . . 27 107 5.2. Procedures for an Outgoing Message . . . . . . . . . . . . 28 108 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 29 109 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 31 110 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 32 111 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 32 112 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 32 113 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 32 114 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 32 115 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 33 116 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 33 117 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 33 118 8. Operational Considerations . . . . . . . . . . . . . . . . . . 48 119 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 48 120 8.2. Notification Receiver Credential Selection . . . . . . . . 49 121 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 49 122 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 123 9.1. Certificates, Authentication, and Authorization . . . . . 50 124 9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 51 125 9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 51 126 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 127 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 128 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 129 12.1. Normative References . . . . . . . . . . . . . . . . . . . 52 130 12.2. Informative References . . . . . . . . . . . . . . . . . . 54 131 Appendix A. Target and Notificaton Configuration Example . . . . 55 132 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 57 134 1. Introduction 136 It is important to understand the SNMPv3 architecture [RFC3411], as 137 enhanced by the Transport Subsystem [I-D.ietf-isms-tmsm]. It is also 138 important to understand the terminology of the SNMPv3 architecture in 139 order to understand where the Transport Model described in this 140 document fits into the architecture and how it interacts with the 141 other architecture subsystems. For a detailed overview of the 142 documents that describe the current Internet-Standard Management 143 Framework, please refer to Section 7 of [RFC3410]. 145 This document describes a Transport Model that makes use of the 146 Datagram Transport Layer Security (DTLS) Protocol [RFC4347], the 147 datagram variant of the existing and commonly deployed Transport 148 Layer Security (TLS) protocol [RFC5246], within a transport subsystem 149 [I-D.ietf-isms-tmsm]. The Transport Model in this document is 150 referred to as the Datagram Transport Layer Security Transport Model 151 (DTLSTM). DTLS takes advantage of the X.509 public keying 152 infrastructure [X509]. This transport model is designed to meet the 153 security and operational needs of network administrators, operate in 154 environments where a connectionless (e.g. UDP or SCTP) transport is 155 preferred, and integrate well into existing public keying 156 infrastructures. 158 Managed objects are accessed via a virtual information store, termed 159 the Management Information Base or MIB. MIB objects are generally 160 accessed through the Simple Network Management Protocol (SNMP). 161 Objects in the MIB are defined using the mechanisms defined in the 162 Structure of Management Information (SMI). This memo specifies a MIB 163 module that is compliant to the SMIv2, which is described in STD 58, 164 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 165 [RFC2580]. 167 This document also specifies a portion of the Management Information 168 Base (MIB) to define objects for monitoring and managing the DTLS 169 Transport Model for SNMP. 171 The diagram shown below gives a conceptual overview of two SNMP 172 entities communicating using the DTLS Transport Model. One entity 173 contains a Command Responder and Notification Originator application, 174 and the other a Command Generator and Notification Responder 175 application. It should be understood that this particular mix of 176 application types is an example only and other combinations are 177 equally as legitimate. 179 +----------------------------------------------------------------+ 180 | Network | 181 +----------------------------------------------------------------+ 182 ^ ^ ^ ^ 183 |Notifications |Commands |Commands |Notifications 184 +---|---------------------|--------+ +--|---------------|-------------+ 185 | V V | | V V | 186 | +------------+ +------------+ | | +-----------+ +----------+ | 187 | | DTLS | | DTLS | | | | DTLS | | DTLS | | 188 | | Service | | Service | | | | Service | | Service | | 189 | | (Client) | | (Server) | | | | (Client) | | (Server)| | 190 | +------------+ +------------+ | | +-----------+ +----------+ | 191 | ^ ^ | | ^ ^ | 192 | | | | | | | | 193 | +--+----------+ | | +-+--------------+ | 194 | +-----|---------+----+ | | +---|--------+----+ | 195 | | V |LCD | +-------+ | | | V |LCD | +--------+ | 196 | | +------+ +----+ | | | | | +------+ +----+ | | | 197 | | | DTLS | <---------->| Cache | | | | | DTLS | <---->| Cache | | 198 | | | TM | | | | | | | | TM | | | | | 199 | | +------+ | +-------+ | | | +------+ | +--------+ | 200 | |Transport Subsystem | ^ | | |Transport Sub. | ^ | 201 | +--------------------+ | | | +-----------------+ | | 202 | ^ +----+ | | ^ | | 203 | | | | | | | | 204 | v | | | V | | 205 | +-------+ +----------+ +-----+ | | | +-----+ +------+ +-----+ | | 206 | | | |Message | |Sec. | | | | | | | MP | |Sec. | | | 207 | | Disp. | |Processing| |Sub- | | | | |Disp.| | Sub- | |Sub- | | | 208 | | | |Subsystem | |sys. | | | | | | |system| |sys. | | | 209 | | | | | | | | | | | | | | | | | | 210 | | | | | |+---+| | | | | | | | |+---+| | | 211 | | | | +-----+ | || || | | | | | |+----+| || || | | 212 | | <--->|v3MP |<-->||TSM|<-+ | | | <-->|v3MP|<->|TSM|<-+ | 213 | | | | +-----+ | || || | | | | |+----+| || || | 214 | +-------+ | | |+---+| | | +-----+ | | |+---+| | 215 | ^ | | | | | | ^ | | | | | 216 | | +----------+ +-----+ | | | +------+ +-----+ | 217 | +-+------------+ | | +-+------------+ | 218 | ^ ^ | | ^ ^ | 219 | | | | | | | | 220 | v v | | V V | 221 | +-------------+ +--------------+ | | +-----------+ +--------------+ | 222 | | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | | 223 | | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RESPONDER | | 224 | | application | | applications | | | |application| | application | | 225 | +-------------+ +--------------+ | | +-----------+ +--------------+ | 226 | SNMP entity | | SNMP entity | 227 +----------------------------------+ +--------------------------------+ 229 1.1. Requirements Terminology 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 233 document are to be interpreted as described in [RFC2119]. 235 1.2. Conventions 237 For consistency with SNMP-related specifications, this document 238 favors terminology as defined in STD62 rather than favoring 239 terminology that is consistent with non-SNMP specifications. This is 240 consistent with the IESG decision to not require the SNMPv3 241 terminology be modified to match the usage of other non-SNMP 242 specifications when SNMPv3 was advanced to Full Standard. 244 Authentication in this document typically refers to the English 245 meaning of "serving to prove the authenticity of" the message, not 246 data source authentication or peer identity authentication. 248 The terms "manager" and "agent" are not used in this document, 249 because in the RFC 3411 architecture [RFC3411], all SNMP entities 250 have the capability of acting in either manager or agent or in both 251 roles depending on the SNMP application types supported in the 252 implementation. Where distinction is required, the application names 253 of Command Generator, Command Responder, Notification Originator, 254 Notification Receiver, and Proxy Forwarder are used. See "SNMP 255 Applications" [RFC3413] for further information. 257 Throughout this document, the terms "client" and "server" are used to 258 refer to the two ends of the SSH transport connection. The client 259 actively opens the SSH connection, and the server passively listens 260 for the incoming SSH connection. Either SNMP entity may act as 261 client or as server, as discussed further below. 263 The User-Based Security Model (USM) [RFC3414] is a mandatory-to- 264 implement Security Model in STD 62. While SSH and USM frequently 265 refer to a user, the terminology preferred in RFC3411 [RFC3411] and 266 in this memo is "principal". A principal is the "who" on whose 267 behalf services are provided or processing takes place. A principal 268 can be, among other things, an individual acting in a particular 269 role; a set of individuals, with each acting in a particular role; an 270 application or a set of applications, or a combination of these 271 within an administrative domain. 273 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 274 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 275 document are to be interpreted as described in [RFC2119]. 277 Throughout this document, the terms "client" and "server" are used to 278 refer to the two ends of the DTLS session. The client actively opens 279 the DTLS session, and the server passively listens for the incoming 280 DTLS session. Any SNMP entity may act as a client or as a server. 282 While security protocols (like DTLS [RFC4347] and USM [RFC3414]) 283 frequently refer to a "user", the terminology preferred in RFC3411 284 [RFC3411] and in this document is "principal". A principal is the 285 "who" on whose behalf services are provided or processing takes 286 place. A principal can be, among other things, an individual acting 287 in a particular role; a set of individuals, with each acting in a 288 particular role; an application or a set of applications, or a 289 combination of these within an administrative domain. 291 Throughout this document, the term "session" is used to refer to a 292 secure association between two DTLS Transport Models that permits the 293 transmission of one or more SNMP messages within the lifetime of the 294 session. 296 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 297 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 298 document are to be interpreted as described in [RFC2119]. 300 2. The Datagram Transport Layer Security Protocol 302 The DTLS protocol is a datagram-compatible variant of the commonly 303 used Transport Layer Security (TLS) protocol. DTLS provides 304 authentication, data message integrity, and privacy at the transport 305 layer. (See [RFC4347]) 307 The primary goals of the DTLS Transport Model are to provide privacy, 308 source authentication and data integrity between two communicating 309 SNMP entities. The DTLS protocol is composed of two layers: the DTLS 310 Record Protocol and the DTLS Handshake Protocol. The following 311 sections provide an overview of these two layers. Please refer to 312 [RFC4347] for a complete description of the protocol. Readers 313 familiar with DTLS can skip Section 2 except for section Section 2.3. 315 2.1. The DTLS Record Protocol 317 At the lowest layer, layered on top of a datagram transport protocol 318 (e.g. UDP or SCTP) is the DTLS Record Protocol. 320 The DTLS Record Protocol provides security that has three basic 321 properties: 323 o The session can be confidential. Symmetric cryptography is used 324 for data encryption (e.g., AES [AES], DES [DES] etc.). The keys 325 for this symmetric encryption are generated uniquely for each 326 session and are based on a secret negotiated by another protocol 327 (such as the DTLS Handshake Protocol). The Record Protocol can 328 also be used without encryption. 330 o Messages can have data integrity. Message transport includes a 331 message integrity check using a keyed MAC. Secure hash functions 332 (e.g., SHA, MD5, etc.) are used for MAC computations. The Record 333 Protocol can operate without a MAC, but is generally only used in 334 this mode while another protocol is using the Record Protocol as a 335 transport for negotiating security parameters. 337 o Messages are protected against replay. DTLS uses explicit 338 sequence numbers, integrity checks, and a sliding window to 339 protect against replay of messages within a session. 341 DTLS also provides protection against replay of entire sessions. In 342 a properly-implemented keying material exchange, both sides will 343 generate new random numbers for each exchange. This results in 344 different encryption and integrity keys for every session. 346 2.2. The DTLS Handshake Protocol 348 The DTLS Record Protocol is used for encapsulation of various higher- 349 level protocols. One such encapsulated protocol, the DTLS Handshake 350 Protocol, allows the server and client to authenticate each other and 351 to negotiate an integrity algorithm, an encryption algorithm and 352 cryptographic keys before the application protocol transmits or 353 receives its first octet of data. Only the DTLS client can initiate 354 the handshake protocol. The DTLS Handshake Protocol provides 355 security that has three basic properties: 357 o The peer's identity can be authenticated using asymmetric (public 358 key) cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This 359 authentication can be made optional, but is generally required by 360 at least one of the peers. 362 DTLS supports three authentication modes: authentication of both 363 the server and the client, server authentication with an 364 unauthenticated client, and total anonymity. For authentication 365 of both entities, each entity provides a valid certificate chain 366 leading to an acceptable certificate authority. Each entity is 367 responsible for verifying that the other's certificate is valid 368 and has not expired or been revoked. See 369 [I-D.hodges-server-ident-check] for further details on 370 standardized processing when checking Server certificate 371 identities. 373 o The negotiation of a shared secret is secure: the negotiated 374 secret is unavailable to eavesdroppers, and for any authenticated 375 handshake the secret cannot be obtained, even by an attacker who 376 can place himself in the middle of the session. 378 o The negotiation is not vulnerable to malicious modification: it is 379 infeasible for an attacker to modify negotiation communication 380 without being detected by the parties to the communication. 382 o DTLS uses a stateless cookie exchange to protect against anonymous 383 denial of service attacks and has retransmission timers, sequence 384 numbers, and counters to handle message loss, reordering, and 385 fragmentation. 387 2.3. SNMP requirements of DTLS 389 To properly support the SNMP over DTLS Transport Model, the DTLS 390 implementation requires the following: 392 o The DTLS Transport Model SHOULD always use authentication of both 393 the server and the client. 395 o At a minimum the DTLS Transport MUST support authentication of the 396 Command Generator principals to guarantee the authenticity of the 397 securityName (a parameter used to pass the authenticated identity 398 name from the transport model to security model for even later use 399 by the access control subsystem). 401 o The DTLS Transport SHOULD support the message encryption to 402 protect sensitive data from eavesdropping attacks. 404 3. How the DTLSTM fits into the Transport Subsystem 406 A transport model is a component of the Transport Subsystem. The 407 DTLS Transport Model thus fits between the underlying DTLS transport 408 layer and the message Dispatcher [RFC3411] component of the SNMP 409 engine and the Transport Subsystem. 411 The DTLS Transport Model will establish a session between itself and 412 the DTLS Transport Model of another SNMP engine. The sending 413 transport model passes unprotected messages from the dispatcher to 414 DTLS to be protected, and the receiving transport model accepts 415 decrypted and authenticated/integrity-checked incoming messages from 416 DTLS and passes them to the dispatcher. 418 After a DTLS Transport model session is established, SNMP messages 419 can conceptually be sent through the session from one SNMP message 420 dispatcher to another SNMP message dispatcher. If multiple SNMP 421 messages are needed to be passed between two SNMP applications they 422 SHOULD be passed through the same session. A DTLSTM implementation 423 engine MAY choose to close a DTLS session to conserve resources. 425 The DTLS Transport Model of an SNMP engine will perform the 426 translation between DTLS-specific security parameters and SNMP- 427 specific, model-independent parameters. 429 The diagram below depicts where the DTLS Transport Model fits into 430 the architecture described in RFC3411 and the Transport Subsystem: 432 +------------------------------+ 433 | Network | 434 +------------------------------+ 435 ^ ^ ^ 436 | | | 437 v v v 438 +-------------------------------------------------------------------+ 439 | +--------------------------------------------------+ | 440 | | Transport Subsystem | +--------+ | 441 | | +-----+ +-----+ +-----+ +-----+ +-------+ | | | | 442 | | | UDP | | TCP | | SSH | |DTLS | . . . | other |<--->| Cache | | 443 | | | | | | | TM | TM | | | | | | | 444 | | +-----+ +-----+ +-----+ +-----+ +-------+ | +--------+ | 445 | +--------------------------------------------------+ ^ | 446 | ^ | | 447 | | | | 448 | Dispatcher v | | 449 | +--------------+ +---------------------+ +----------------+ | | 450 | | Transport | | Message Processing | | Security | | | 451 | | Dispatch | | Subsystem | | Subsystem | | | 452 | | | | +------------+ | | +------------+ | | | 453 | | | | +->| v1MP |<--->| | USM | | | | 454 | | | | | +------------+ | | +------------+ | | | 455 | | | | | +------------+ | | +------------+ | | | 456 | | | | +->| v2cMP |<--->| | Transport | | | | 457 | | Message | | | +------------+ | | | Security |<--+ | 458 | | Dispatch <---->| +------------+ | | | Model | | | 459 | | | | +->| v3MP |<--->| +------------+ | | 460 | | | | | +------------+ | | +------------+ | | 461 | | PDU Dispatch | | | +------------+ | | | Other | | | 462 | +--------------+ | +->| otherMP |<--->| | Model(s) | | | 463 | ^ | +------------+ | | +------------+ | | 464 | | +---------------------+ +----------------+ | 465 | v | 466 | +-------+-------------------------+---------------+ | 467 | ^ ^ ^ | 468 | | | | | 469 | v v v | 470 | +-------------+ +---------+ +--------------+ +-------------+ | 471 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 472 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 473 | | application | | | | applications | | application | | 474 | +-------------+ +---------+ +--------------+ +-------------+ | 475 | ^ ^ | 476 | | | | 477 | v v | 478 | +----------------------------------------------+ | 479 | | MIB instrumentation | SNMP entity | 480 +-------------------------------------------------------------------+ 482 3.1. Security Capabilities of this Model 484 3.1.1. Threats 486 The DTLS Transport Model provides protection against the threats 487 identified by the RFC 3411 architecture [RFC3411]: 489 1. Modification of Information - The modification threat is the 490 danger that some unauthorized entity may alter in-transit SNMP 491 messages generated on behalf of an authorized principal in such a 492 way as to effect unauthorized management operations, including 493 falsifying the value of an object. 495 DTLS provides verification that the content of each received 496 message has not been modified during its transmission through the 497 network, data has not been altered or destroyed in an 498 unauthorized manner, and data sequences have not been altered to 499 an extent greater than can occur non-maliciously. 501 2. Masquerade - The masquerade threat is the danger that management 502 operations unauthorized for a given principal may be attempted by 503 assuming the identity of another principal that has the 504 appropriate authorizations. 506 The DTLSTM provides for authentication of the Command Generator, 507 Command Responder, Notification Generator, Notification Responder 508 and Proxy Forwarder through the use of X.509 certificates. 510 The masquerade threat can be mitigated against by using an 511 appropriate Access Control Model (ACM) such as the View-based 512 Access Control Module (VACM) [RFC3415]. In addition, it is 513 important to authenticate and verify both the authenticated 514 identity of the DTLS client and the DTLS server to protect 515 against this threat. (See Section 9 for more detail.) 517 3. Message stream modification - The re-ordering, delay or replay of 518 messages can and does occur through the natural operation of many 519 connectionless transport services. The message stream 520 modification threat is the danger that messages may be 521 maliciously re-ordered, delayed or replayed to an extent which is 522 greater than can occur through the natural operation of 523 connectionless transport services, in order to effect 524 unauthorized management operations. 526 DTLS provides replay protection with a MAC that includes a 527 sequence number. DTLS uses a sliding window protocol with the 528 sequence number for replay protection, see [RFC4347]. The 529 technique used is the same as in IPsec AH/ESP [RFC4302] 530 [RFC4303], by maintaining a bitmap window of received records. 531 Records that are too old to fit in the window and records that 532 have previously been received are silently discarded. The replay 533 detection feature is optional, since packet duplication can also 534 occur naturally due to routing errors and does not necessarily 535 indicate an active attack. Applications may conceivably detect 536 duplicate packets and accordingly modify their data transmission 537 strategy. 539 4. Disclosure - The disclosure threat is the danger of eavesdropping 540 on the exchanges between SNMP engines. Protecting against this 541 threat may be required by local policy at the deployment site. 543 Symmetric cryptography (e.g., AES [AES], DES [DES] etc.) can be 544 used by DTLS for data privacy. The keys for this symmetric 545 encryption are generated uniquely for each session and are based 546 on a secret negotiated by another protocol (such as the DTLS 547 Handshake Protocol). 549 5. Denial of Service - the RFC 3411 architecture [RFC3411] states 550 that denial of service (DoS) attacks need not be addressed by an 551 SNMP security protocol. However, datagram security protocols are 552 susceptible to a variety of denial of service attacks. Two 553 attacks are of particular concern: 555 o An attacker can consume excessive resources on the server by 556 transmitting a series of handshake initiation requests, 557 causing the server to allocate state and potentially to 558 perform expensive cryptographic operations. 560 o An attacker can use the server as an amplifier by sending 561 session initiation messages with a forged source of the 562 victim. The server then sends its next message (in DTLS, a 563 Certificate message, which can be quite large) to the victim 564 machine, thus flooding it. 566 In order to counter both of these attacks, DTLS borrows the 567 stateless cookie technique used by Photuris [RFC2522] and IKEv2 568 [RFC4306]. When the client sends its ClientHello message to the 569 server, the server MAY respond with a HelloVerifyRequest message. 570 This message contains a stateless cookie generated using the 571 technique of [RFC2522]. The client MUST retransmit the 572 ClientHello with the cookie added. The server then verifies the 573 cookie and proceeds with the handshake only if it is valid. This 574 mechanism forces the attacker/client to be able to receive the 575 cookie, which makes DoS attacks with spoofed IP addresses 576 difficult. This mechanism does not provide any defense against 577 denial of service attacks mounted from valid IP addresses. 579 Implementations are not required to perform the stateless cookie 580 exchange for every DTLS handshakes but in environments where 581 amplification could be an issue it is RECOMMENDED that the cookie 582 exchange is utilized. 584 3.1.2. Message Protection 586 The RFC 3411 architecture recognizes three levels of security: 588 o without authentication and without privacy (noAuthNoPriv) 590 o with authentication but without privacy (authNoPriv) 592 o with authentication and with privacy (authPriv) 594 The DTLS Transport Model determines from DTLS the identity of the 595 authenticated principal, and the type and address associated with an 596 incoming message, and the DTLS Transport Model provides this 597 information to DTLS for an outgoing message. 599 When an application requests a session for a message, through the 600 cache, the application requests a security level for that session. 601 The DTLS Transport Model MUST ensure that the DTLS session provides 602 security at least as high as the requested level of security. How 603 the security level is translated into the algorithms used to provide 604 data integrity and privacy is implementation-dependent. However, the 605 NULL integrity and encryption algorithms MUST NOT be used to fulfill 606 security level requests for authentication or privacy. 608 Implementations MAY choose to force DTLS to only allow cipher_suites 609 that provide both authentication and privacy to guarantee this 610 assertion. 612 If a suitable interface between the DTLS Transport Model and the DTLS 613 Handshake Protocol is implemented to allow the selection of security 614 level dependent algorithms, for example a security level to 615 cipher_suites mapping table, then different security levels may be 616 utilized by the application. However, different port numbers will 617 need to be used by at least one side of the connection to 618 differentiate between the DTLS sessions. This is the only way to 619 ensured proper selection of a session ID for an incoming DTLS 620 message. 622 The authentication, integrity and privacy algorithms used by the DTLS 623 Protocol [RFC4347] may vary over time as the science of cryptography 624 continues to evolve and the development of DTLS continues over time. 625 Implementers are encouraged to plan for changes in operator trust of 626 particular algorithms and implementations should offer configuration 627 settings for mapping algorithms to SNMPv3 security levels. 629 3.1.3. DTLS Sessions 631 DTLS sessions are opened by the DTLS Transport Model during the 632 elements of procedure for an outgoing SNMP message. Since the sender 633 of a message initiates the creation of a DTLS session if needed, the 634 DTLS session will already exist for an incoming message. 636 Implementations MAY choose to instantiate DTLS sessions in 637 anticipation of outgoing messages. This approach might be useful to 638 ensure that a DTLS session to a given target can be established 639 before it becomes important to send a message over the DTLS session. 640 Of course, there is no guarantee that a pre-established session will 641 still be valid when needed. 643 DTLS sessions are uniquely identified within the DTLS Transport Model 644 by the combination of transportDomain, transportAddress, 645 securityName, and requestedSecurityLevel associated with each 646 session. Each unique combination of these parameters MUST have a 647 locally-chosen unique dtlsSessionID associated for active sessions. 648 For further information see Section 4.4 and Section 5. 650 3.2. Security Parameter Passing 652 For the DTLS server-side, DTLS-specific security parameters (i.e., 653 cipher_suites, X.509 certificate fields, IP address and port) are 654 translated by the DTLS Transport Model into security parameters for 655 the DTLS Transport Model and security model (i.e., securityLevel, 656 securityName, transportDomain, transportAddress). The transport- 657 related and DTLS-security-related information, including the 658 authenticated identity, are stored in a cache referenced by 659 tmStateReference. 661 For the DTLS client-side, the DTLS Transport Model takes input 662 provided by the dispatcher in the sendMessage() Abstract Service 663 Interface (ASI) and input from the tmStateReference cache. The DTLS 664 Transport Model converts that information into suitable security 665 parameters for DTLS and establishes sessions as needed. 667 The elements of procedure in Section 5 discuss these concepts in much 668 greater detail. 670 3.3. Notifications and Proxy 672 DTLS sessions may be initiated by DTLS clients on behalf of command 673 generators or notification originators. Command generators are 674 frequently operated by a human, but notification originators are 675 usually unmanned automated processes. The targets to whom 676 notifications should be sent is typically determined and configured 677 by a network administrator. 679 The SNMP-TARGET-MIB module [RFC3413] contains objects for defining 680 management targets, including transportDomain, transportAddress, 681 securityName, securityModel, and securityLevel parameters, for 682 Notification Generator, Proxy Forwarder, and SNMP-controllable 683 Command Generator applications. Transport domains and transport 684 addresses are configured in the snmpTargetAddrTable, and the 685 securityModel, securityName, and securityLevel parameters are 686 configured in the snmpTargetParamsTable. This document defines a MIB 687 module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to 688 specify a DTLS client-side certificate to use for the connection. 690 When configuring a DTLS target, the snmpTargetAddrTDomain and 691 snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be 692 set to the snmpDTLSUDPDomain or snmpDTLSSCTPDomain object and an 693 appropriate snmpDTLSUDPAddress or snmpDTLSSCTPAddress value 694 respectively. The snmpTargetParamsMPModel column of the 695 snmpTargetParamsTable should be set to a value of 3 to indicate the 696 SNMPv3 message processing model. The snmpTargetParamsSecurityName 697 should be set to an appropriate securityName value and the 698 dtlstmParamsHashType and dtlstmParamsHashValue parameters of the 699 dtlstmParamsTable should be set to values that refer to a locally 700 held certificate to be used. Other parameters, for example 701 cryptographic configuration such as cipher suites to use, must come 702 from configuration mechanisms not defined in this document. The 703 other needed configuration may be configured using SNMP or other 704 implementation-dependent mechanisms (for example, via a CLI). This 705 securityName defined in the snmpTargetParamsSecurityName column will 706 be used by the access control model to authorize any notifications 707 that need to be sent. 709 4. Elements of the Model 711 This section contains definitions required to realize the DTLS 712 Transport Model defined by this document. Readers familiar with 713 X.509 certificates can skip this section until Section 4.1.2. 715 4.1. Certificates 717 DTLS makes use of X.509 certificates for authentication of both sides 718 of the transport. This section discusses the use of certificates in 719 DTLS and the its effects on SNMP over DTLS. 721 4.1.1. The Certificate Infrastructure 723 Users of a public key SHALL be confident that the associated private 724 key is owned by the correct remote subject (person or system) with 725 which an encryption or digital signature mechanism will be used. 726 This confidence is obtained through the use of public key 727 certificates, which are data structures that bind public key values 728 to subjects. The binding is asserted by having a trusted CA 729 digitally sign each certificate. The CA may base this assertion upon 730 technical means (i.e., proof of possession through a challenge- 731 response protocol), presentation of the private key, or on an 732 assertion by the subject. A certificate has a limited valid lifetime 733 which is indicated in its signed contents. Because a certificate's 734 signature and timeliness can be independently checked by a 735 certificate-using client, certificates can be distributed via 736 untrusted communications and server systems, and can be cached in 737 unsecured storage in certificate-using systems. 739 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 740 first published in 1988 as part of the X.500 Directory 741 recommendations, defines a standard certificate format [X509] which 742 is a certificate which binds a subject (principal) to a public key 743 value. This was later further documented in [RFC5280]. 745 A X.509 certificate is a sequence of three required fields: 747 tbsCertificate: The field contains the names of the subject and 748 issuer, a public key associated with the subject, a validity 749 period, and other associated information. This field may also 750 contain extension components. 752 signatureAlgorithm: The signatureAlgorithm field contains the 753 identifier for the cryptographic algorithm used by the certificate 754 authority (CA) to sign this certificate. 756 signatureValue: The signatureValue field contains a digital 757 signature computed upon the ASN.1 DER encoded tbsCertificate 758 field. The ASN.1 DER encoded tbsCertificate is used as the input 759 to the signature function. This signature value is then ASN.1 DER 760 encoded as a BIT STRING and included in the Certificate's 761 signature field. By generating this signature, a CA certifies the 762 validity of the information in the tbsCertificate field. In 763 particular, the CA certifies the binding between the public key 764 material and the subject of the certificate. 766 The basic X.509 authentication procedure is as follows: A system is 767 initialized with a number of root certificates that contain the 768 public keys of a number of trusted CAs. When a system receives a 769 X.509 certificate, signed by one of those CAs, the certificate has to 770 be verified. It first checks the signatureValue field by using the 771 public key of the corresponding trusted CA. Then it compares the 772 decrypted information with a digest of the tbsCertificate field. If 773 they match, then the subject in the tbsCertificate field is 774 authenticated. 776 4.1.2. Provisioning for the Certificate 778 Authentication using DTLS will require that SNMP entities are 779 provisioned with certificates, which are signed by trusted 780 certificate authorities. Furthermore, SNMP entities will most 781 commonly need to be provisioned with root certificates which 782 represent the list of trusted certificate authorities that an SNMP 783 entity can use for certificate verification. SNMP entities MAY also 784 be provisioned with a X.509 certificate revocation mechanism which 785 can be used to verify that a certificate has not been revoked. 787 The authenticated tmSecurityName of the principal is looked up using 788 the dtlstmCertificateToSNTable. This table either: 790 o Maps a certificate's fingerprint hash type and value to a directly 791 specified tmSecurityName. 793 o Identifies a certificate issuer's fingerprint hash type and value 794 and allows child certificate's subjectAltName or CommonName to 795 directly used as the tmSecurityNome. 797 The certificate trust anchors, being either CA certificates or public 798 keys for use by self-signed certificates, must be installed through 799 an out of band trusted mechanism into the server and its authenticity 800 MUST be verified before access is granted. Implementations SHOULD 801 choose to discard any connections for which no potential 802 dtlstmCertificateToSNTable mapping exists before performing 803 certificate verification to avoid expending computational resources 804 associated with certificate verification. 806 The typical enterprise configuration will map the "subjectAltName" 807 component of the tbsCertificate to the DTLSSM specific 808 tmSecurityName. Thus, the authenticated identity can be obtained by 809 the DTLS Transport Model by extracting the subjectAltName from the 810 peer's certificate and the receiving application will have an 811 appropriate tmSecurityName for use by components like an access 812 control model. This setup requires very little configuration: a 813 single row in the dtlstmCertificateToSNTable referencing a 814 certificate authority. 816 An example mapping setup can be found in Appendix A 818 This tmSecurityName may be later translated from a DTLSSM specific 819 tmSecurityName to a SNMP engine securityName by the security model. 820 A security model, like the TSM security model, may perform an 821 identity mapping or a more complex mapping to derive the securityName 822 from the tmSecurityName offered by the DTLS Transport Model. 824 4.2. Messages 826 As stated in Section 4.1.1 of [RFC4347], each DTLS record must fit 827 within a single DTLS datagram. The DTLSTM SHOULD prohibit SNMP 828 messages from being sent that exceeds the maximum DTLS message. The 829 DTLSTM implementation SHOULD return an error when the DTLS message 830 size would be exceeded and the message won't be sent. 832 4.3. SNMP Services 834 This section describes the services provided by the DTLS Transport 835 Model with their inputs and outputs. The services are between the 836 Transport Model and the Dispatcher. 838 The services are described as primitives of an abstract service 839 interface (ASI) and the inputs and outputs are described as abstract 840 data elements as they are passed in these abstract service 841 primitives. 843 4.3.1. SNMP Services for an Outgoing Message 845 The Dispatcher passes the information to the DTLS Transport Model 846 using the ASI defined in the transport subsystem: 848 statusInformation = 849 sendMessage( 850 IN destTransportDomain -- transport domain to be used 851 IN destTransportAddress -- transport address to be used 852 IN outgoingMessage -- the message to send 853 IN outgoingMessageLength -- its length 854 IN tmStateReference -- reference to transport state 855 ) 857 The abstract data elements passed as parameters in the abstract 858 service primitives are as follows: 860 statusInformation: An indication of whether the passing of the 861 message was successful. If not it is an indication of the 862 problem. 864 destTransportDomain: The transport domain for the associated 865 destTransportAddress. The Transport Model uses this parameter to 866 determine the transport type of the associated 867 destTransportAddress. This parameter may also be used by the 868 transport subsystem to route the message to the appropriate 869 Transport Model. This document specifies two DTLS based Transport 870 Domains for use: the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain. 872 destTransportAddress: The transport address of the destination DTLS 873 Transport Model in a format specified by the SnmpDTLSUDPAddress or 874 the SnmpDTLSSCTPAddress TEXTUAL-CONVENTIONs. 876 outgoingMessage: The outgoing message to send to DTLS for 877 encapsulation. 879 outgoingMessageLength: The length of the outgoing message. 881 tmStateReference: A handle/reference to tmSecurityData to be used 882 when securing outgoing messages. 884 4.3.2. SNMP Services for an Incoming Message 886 The DTLS Transport Model processes the received message from the 887 network using the DTLS service and then passes it to the Dispatcher 888 using the following ASI: 890 receiveMessage( 891 IN transportDomain -- origin transport domain 892 IN transportAddress -- origin transport address 893 IN incomingMessage -- the message received 894 IN incomingMessageLength -- its length 895 IN tmStateReference -- reference to transport state 896 ) 898 The abstract data elements passed as parameters in the abstract 899 service primitives are as follows: 901 statusInformation: An indication of whether the passing of the 902 message was successful. If not it is an indication of the 903 problem. 905 transportDomain: The transport domain for the associated 906 transportAddress. This document specifies two DTLS based 907 Transport Domains for use: the snmpDTLSUDPDomain and the 908 snmpDTLSSCTPDomain. 910 transportAddress: The transport address of the source of the 911 received message in a format specified by the SnmpDTLSUDPAddress 912 or the SnmpDTLSSCTPAddress TEXTUAL-CONVENTION. 914 incomingMessage: The whole SNMP message stripped of all DTLS 915 protection data. 917 incomingMessageLength: The length of the SNMP message after being 918 processed by DTLS. 920 tmStateReference: A handle/reference to tmSecurityData to be used by 921 the security model. 923 4.4. DTLS Services 925 This section describes the services provided by the DTLS Transport 926 Model with their inputs and outputs. These services are between the 927 DTLS Transport Model and the DTLS transport layer. The following 928 sections describe services for establishing and closing a session and 929 for passing messages between the DTLS transport layer and the DTLS 930 Transport Model. 932 4.4.1. Services for Establishing a Session 934 The DTLS Transport Model provides the following ASI to describe the 935 data passed between the Transport Model and the DTLS transport layer 936 for session establishment. 938 statusInformation = -- errorIndication or success 939 openSession( 940 IN destTransportDomain -- transport domain to be used 941 IN destTransportAddress -- transport address to be used 942 IN securityName -- on behalf of this principal 943 IN securityLevel -- Level of Security requested 944 OUT dtlsSessionID -- Session identifier for DTLS 945 ) 947 The abstract data elements passed as parameters in the abstract 948 service primitives are as follows: 950 statusInformation: An indication of whether the process was 951 successful or not. If not, then the status information will 952 include the error indication provided by DTLS. 954 destTransportDomain: The transport domain for the associated 955 destTransportAddress. The DTLS Transport Model uses this 956 parameter to determine the transport type of the associated 957 destTransportAddress. This document specifies two DTLS based 958 Transport Domains for use: the snmpDTLSUDPDomain and the 959 snmpDTLSSCTPDomain. 961 destTransportAddress: The transport address of the destination DTLS 962 Transport Model in a format specified by the SnmpDTLSUDPAddress or 963 the SnmpDTLSSCTPAddress TEXTUAL-CONVENTION. 965 securityName: The security name representing the principal on whose 966 behalf the message will be sent. 968 securityLevel: The level of security requested by the application. 970 dtlsSessionID: An implementation-dependent session identifier to 971 reference the specific DTLS session. 973 DTLS and UDP do not provide a session de-multiplexing mechanism and 974 it is possible that implementations will only be able to identify a 975 unique session based on a unique combination of source address, 976 destination address, source UDP port number and destination UDP port 977 number. Because of this, when establishing a new sessions 978 implementations MUST use a different UDP source port number for each 979 connection to a remote destination IP-address/port-number combination 980 to ensure the remote entity can properly disambiguate between 981 multiple sessions from a host to the same port on a server. SCTP 982 does provide session de-multiplexing so this restriction is not 983 needed for DTLS/SCTP implementations. 985 The procedural details for establishing a session are further 986 described in Section 5.3. 988 Upon completion of the process the DTLS Transport Model returns 989 status information and, if the process was successful the 990 dtlsSessionID. Other implementation-dependent data from DTLS are 991 also returned. The dtlsSessionID is stored in an implementation- 992 dependent manner and tied to the tmSecurityData for future use of 993 this session. 995 4.4.2. DTLS Services for an Incoming Message 997 When the DTLS Transport Model invokes the DTLS record layer to verify 998 proper security for the incoming message, it must use the following 999 ASI: 1001 statusInformation = -- errorIndication or success 1002 dtlsRead( 1003 IN dtlsSessionID -- Session identifier for DTLS 1004 IN wholeDtlsMsg -- as received on the wire 1005 IN wholeDtlsMsgLength -- length as received on the wire 1006 OUT incomingMessage -- the whole SNMP message from DTLS 1007 OUT incomingMessageLength -- the length of the SNMP message 1008 ) 1010 The abstract data elements passed as parameters in the abstract 1011 service primitives are as follows: 1013 statusInformation: An indication of whether the process was 1014 successful or not. If not, then the status information will 1015 include the error indication provided by DTLS. 1017 dtlsSessionID: An implementation-dependent session identifier to 1018 reference the specific DTLS session. How the DTLS session ID is 1019 obtained for each message is implementation-dependent. As an 1020 implementation hint, the DTLS Transport Model can examine incoming 1021 messages to determine the source IP address, source port number, 1022 destination IP address, and destination port number and use these 1023 values to look up the local DTLS session ID in the list of active 1024 sessions. 1026 wholeDtlsMsg: The whole message as received on the wire. 1028 wholeDtlsMsgLength: The length of the message as it was received on 1029 the wire. 1031 incomingMessage: The whole SNMP message stripped of all DTLS privacy 1032 and integrity data. 1034 incomingMessageLength: The length of the SNMP message stripped of 1035 all DTLS privacy and integrity data. 1037 4.4.3. DTLS Services for an Outgoing Message 1039 When the DTLS Transport Model invokes the DTLS record layer to 1040 encapsulate and transmit a SNMP message, it must use the following 1041 ASI. 1043 statusInformation = -- errorIndication or success 1044 dtlsWrite( 1045 IN dtlsSessionID -- Session identifier for DTLS 1046 IN outgoingMessage -- the message to send 1047 IN outgoingMessageLength -- its length 1048 ) 1050 The abstract data elements passed as parameters in the abstract 1051 service primitives are as follows: 1053 statusInformation: An indication of whether the process was 1054 successful or not. If not, then the status information will 1055 include the error indication provided by DTLS. 1057 dtlsSessionID: An implementation-dependent session identifier to 1058 reference the specific DTLS session that the message should be 1059 sent using. 1061 outgoingMessage: The outgoing message to send to DTLS for 1062 encapsulation. 1064 outgoingMessageLength: The length of the outgoing message. 1066 4.5. Cached Information and References 1068 When performing SNMP processing, there are two levels of state 1069 information that may need to be retained: the immediate state linking 1070 a request-response pair, and potentially longer-term state relating 1071 to transport and security. "Transport Subsystem for the Simple 1072 Network Management Protocol" [I-D.ietf-isms-tmsm] defines general 1073 requirements for caches and references. 1075 4.5.1. DTLS Transport Model Cached Information 1077 The DTLSTM has no specific responsibilities regarding the cached 1078 information beyond those discussed in "Transport Subsystem for the 1079 Simple Network Management Protocol" [I-D.ietf-isms-tmsm] 1081 5. Elements of Procedure 1083 Abstract service interfaces have been defined by RFC 3411 to describe 1084 the conceptual data flows between the various subsystems within an 1085 SNMP entity. The DTLSTM uses some of these conceptual data flows 1086 when communicating between subsystems. These RFC 3411-defined data 1087 flows are referred to here as public interfaces. 1089 To simplify the elements of procedure, the release of state 1090 information is not always explicitly specified. As a general rule, 1091 if state information is available when a message gets discarded, the 1092 message-state information should also be released. If state 1093 information is available when a session is closed, the session state 1094 information should also be released. Sensitive information, like 1095 cryptographic keys, should be overwritten with zero value or random 1096 value data prior to being released. 1098 An error indication may return an OID and value for an incremented 1099 counter if the information is available at the point where the error 1100 is detected. 1102 5.1. Procedures for an Incoming Message 1104 The following section describes the procedures followed by the DTLS 1105 Transport Model when it receives a DTLS protected packet. The steps 1106 are broken into two different sections. The first section describes 1107 the needed steps for de-multiplexing multiple DTLS sessions and the 1108 second section describes the steps which are specific to transport 1109 processing once the DTLS processing has been completed. 1111 5.1.1. DTLS Processing for Incoming Messages 1113 DTLS is significantly different in terms of session handling than 1114 SSH, TLS or other TCP-based session streams. The DTLS protocol, 1115 which is datagram-based, does not have a session identifier when run 1116 over UDP that allows implementations to determine through which 1117 session a packet is arriving like SCTP-based and TCP-based streams 1118 have. Thus, a process for de-multiplexing sessions when used over 1119 UDP must be incorporated into the procedures for an incoming message. 1120 The steps in this section describe how this can be accomplished, 1121 although any implementation dependent method for doing so should be 1122 suitable as long as the results are consistently deterministic. The 1123 important results from the steps in this section are the 1124 transportDomain, the transportAddress, the wholeMessage, the 1125 wholeMessageLength, and a unique implementation-dependent session 1126 identifier. 1128 This procedure assumes that upon session establishment, an entry in a 1129 local transport mapping table is created in the Transport Model's 1130 LCD. This transport mapping table entry should be able to map a 1131 unique combination of the remote address, remote port number, local 1132 address and local port number to a implementation-dependent 1133 dtlsSessionID. 1135 1) The DTLS Transport Model examines the raw UDP message, in an 1136 implementation-dependent manner. If the message is not a DTLS 1137 message then it should be discarded. If the message is not a 1138 (D)TLS Application Data message then the message should be 1139 processed by the underlying DTLS framework as it is (for example) 1140 a session initialization or session modification message and no 1141 further steps below should be taken by the DTLS Transport. 1143 2) The DTLS Transport Model queries the LCD using the transport 1144 parameters to determine if a session already exists and its 1145 dtlsSessionID. As noted previously, the source and destination 1146 addresses and ports of the message should uniquely assign the 1147 message to a specific session identifier. However, another 1148 implementation-dependent method may be used if so desired. 1150 3) If a matching entry in the LCD does not exist then the message is 1151 discarded. Increment the dtlstmSessionNoAvailableSessions 1152 counter and stop processing the message. 1154 Note that an entry would already exist if the client and server's 1155 session establishment procedures had been successfully completed 1156 (as described both above and in Section 5.3) even if no message 1157 had yet been sent through the newly established session. An 1158 entry may not exist, however, if a "rogue" message was routed to 1159 the SNMP entity by mistake. An entry might also be missing 1160 because of a "broken" session (see operational considerations). 1162 4) Retrieve the dtlsSessionID from the LCD. 1164 5) The dtlsWholeMsg, and the dtlsSessionID are passed to DTLS for 1165 integrity checking and decryption using the dtlsRead() ASI. 1167 6) If the message fails integrity checks or other DTLS security 1168 processing then the dtlstmDTLSProtectionErrors counter is 1169 incremented, the message is discarded and processing of the 1170 message is stopped. 1172 7) The output of the dtlsRead results in an incomingMessage and an 1173 incomingMessageLength. These results and the dtlsSessionID are 1174 used below in the Section 5.1.2 to complete the processing of the 1175 incoming message. 1177 5.1.2. Transport Processing for Incoming Messages 1179 The procedures in this section describe how the DTLS Transport should 1180 process messages that have already been properly extracted from the 1181 DTLS stream, as described in Section 5.1.1. 1183 1) Create a tmStateReference cache for the subsequent reference and 1184 assign the following values within it: 1186 tmTransportDomain = snmpDTLSUDPDomain or snmpDTLSSCTPDomain as 1187 appropriate. 1189 tmTransportAddress = The address the message originated from, 1190 determined in an implementation dependent way. 1192 tmSecurityLevel = The derived tmSecurityLevel for the session, 1193 as discussed in Section 3.1.2 and Section 5.3. 1195 tmSecurityName = The derived tmSecurityName for the session as 1196 discussed in and Section 5.3. This value MUST be constant 1197 during the lifetime of the DTLS session. 1199 tmSessionID = The dtlsSessionID, which MUST be A unique session 1200 identifier for this DTLS session. The contents and format of 1201 this identifier are implementation dependent as long as it is 1202 unique to the session. A session identifier MUST NOT be 1203 reused until all references to it are no longer in use. The 1204 tmSessionID is equal to the dtlsSessionID discussed in 1205 Section 5.1.1. tmSessionID refers to the session identifier 1206 when stored in the tmStateReference and dtlsSessionID refers 1207 to the session identifier when stored in the LCD. They MUST 1208 always be equal when processing a given session's traffic. 1210 2) The wholeMessage and the wholeMessageLength are assigned values 1211 from the incomingMessage and incomingMessageLength values from 1212 the DTLS processing. 1214 3) The DTLS Transport Model passes the transportDomain, 1215 transportAddress, wholeMessage, and wholeMessageLength to the 1216 Dispatcher using the receiveMessage ASI: 1218 statusInformation = 1219 receiveMessage( 1220 IN transportDomain -- snmpSSHDomain 1221 IN transportAddress -- address for the received message 1222 IN wholeMessage -- the whole SNMP message from SSH 1223 IN wholeMessageLength -- the length of the SNMP message 1224 IN tmStateReference -- (NEW) transport info 1225 ) 1227 5.2. Procedures for an Outgoing Message 1229 The Dispatcher sends a message to the DTLS Transport Model using the 1230 following ASI: 1232 statusInformation = 1233 sendMessage( 1234 IN destTransportDomain -- transport domain to be used 1235 IN destTransportAddress -- transport address to be used 1236 IN outgoingMessage -- the message to send 1237 IN outgoingMessageLength -- its length 1238 IN tmStateReference -- (NEW) transport info 1239 ) 1241 This section describes the procedure followed by the DTLS Transport 1242 Model whenever it is requested through this ASI to send a message. 1244 1) Extract tmSessionID, tmTransportAddress, tmSecurityName, 1245 tmRequestedSecurityLevel. and tmSameSecurity from the 1246 tmStateReference. Note: The tmSessionID value may be undefined 1247 if session exists yet. 1249 2) If tmSameSecurity is true and either tmSessionID is undefined or 1250 refers to a session that is no longer open then increment the 1251 dtlstmSessionNoAvailableSessions counter, discard the message and 1252 return the error indication in the statusInformation. Processing 1253 of this message stops. 1255 3) If tmSameSecurity is false and tmSessionID refers to a session 1256 that is no longer available then an implementation SHOULD open a 1257 new session using the openSession() ASI as described below in 1258 step 4b. An implementation MAY choose to return an error to the 1259 calling module. 1261 4) If tmSessionID is undefined, then use tmTransportAddress, 1262 tmSecurityName and tmRequestedSecurityLevel to see if there is a 1263 corresponding entry in the LCD suitable to send the message over. 1265 4a) If there is a corresponding LCD entry, then this session 1266 will be used to send the message. 1268 4b) If there is not a corresponding LCD entry, then open a 1269 session using the openSession() ASI (discussed further in 1270 Section 4.4.1). Implementations MAY wish to offer message 1271 buffering to prevent redundant openSession() calls for the 1272 same cache entry. If an error is returned from 1273 OpenSession(), then discard the message, increment the 1274 dtlstmSessionOpenErrors, and return an error indication to 1275 the calling module. 1277 5) Using either the session indicated by the tmSessionID if there 1278 was one or the session resulting in the previous step, pass the 1279 outgoingMessage to DTLS for encapsulation and transmission. 1281 5.3. Establishing a Session 1283 The DTLS Transport Model provides the following primitive to 1284 establish a new DTLS session (previously discussed in Section 4.4.1): 1286 statusInformation = -- errorIndication or success 1287 openSession( 1288 IN destTransportDomain -- transport domain to be used 1289 IN destTransportAddress -- transport address to be used 1290 IN securityName -- on behalf of this principal 1291 IN securityLevel -- Level of Security requested 1292 OUT dtlsSessionID -- Session identifier for DTLS 1293 ) 1295 The following sections describe the procedures followed by a DTLS 1296 Transport Model when establishing a session as a Command Generator, a 1297 Notification Originator or as part of a Proxy Forwarder. 1299 The following describes the procedure to follow to establish a 1300 session between SNMP engines to exchange SNMP messages. This process 1301 is followed by any SNMP engine establishing a session for subsequent 1302 use. 1304 This MAY be done automatically for SNMP messages which are not 1305 Response or Report messages. 1307 DTLS provides no explicit manner for transmitting an identity the 1308 client wishes to connect to during or prior to key exchange to 1309 facilitate certificate selection at the server (e.g. at a 1310 Notification Receiver). I.E., there is no available mechanism for 1311 sending notifications to a specific principal at a given UDP or SCTP 1312 port. Therefore, implementations MAY support responding with 1313 multiple identities using separate UDP or SCTP port numbers to 1314 indicate the desired principal or some other implementation-dependent 1315 solution. 1317 1) The client selects the appropriate certificate and cipher_suites 1318 for the key agreement based on the tmSecurityName and the 1319 tmRequestedSecurityLevel for the session. For sessions being 1320 established as a result of a SNMP-TARGET-MIB based operation, the 1321 certificate will potentially have been identified via the 1322 dtlstmParamsTable mapping and the cipher_suites will have to be 1323 taken from system-wide or implementation-specific configuration. 1324 Otherwise, the certificate and appropriate cipher_suites will 1325 need to be passed to the openSession() ASI as supplemental 1326 information or configured through an implementation-dependent 1327 mechanism. It is also implementation-dependent and possibly 1328 policy-dependent how tmRequestedSecurityLevel will be used to 1329 influence the security capabilities provided by the DTLS session. 1330 However this is done, the security capabilities provided by DTLS 1331 MUST be at least as high as the level of security indicated by 1332 the tmRequestedSecurityLevel parameter. The actual security 1333 level of the session should be reported in the tmStateReference 1334 cache as tmSecurityLevel. For DTLS to provide strong 1335 authentication, each principal acting as a Command Generator 1336 SHOULD have its own certificate. 1338 2) Using the destTransportDomain and destTransportAddress values, 1339 the client will initiate the DTLS handshake protocol to establish 1340 session keys for message integrity and encryption. 1342 If the attempt to establish a session is unsuccessful, then 1343 dtlstmSessionOpenErrors is incremented, an error indication is 1344 returned, and session establishment processing stops. 1346 3) Once the secure session is established and both sides have been 1347 authenticated, certificate validation and identity expectations 1348 are performed. 1350 a) The DTLS server side of the connection identifies the 1351 authenticated identity from the DTLS client's principal 1352 certificate using the dtlstmCertificateToSNTable mapping 1353 table and records this in the tmStateReference cache as 1354 tmSecurityName. The details of the lookup process are fully 1355 described in the DESCRIPTION clause of the 1356 dtlstmCertificateToSNTable MIB object. If this verification 1357 fails in any way (for example because of failures in 1358 cryptographic verification or the lack of an appropriate row 1359 in the dtlstmCertificateToSNTable) then the session 1360 establishment MUST fail, the 1361 dtlstmSessionInvalidClientCertificates object is incremented 1362 and processing is stopped. 1364 b) The DTLS client side of the connection SHOULD verify that 1365 authenticated identity of the DTLS server's certificate is 1366 the expected identity and MUST do so if the client 1367 application is a Notification Generator. If strong 1368 authentication is desired then the DTLS server certificate 1369 MUST always be verified and checked against the expected 1370 identity. Methods for doing this are described in 1371 [I-D.hodges-server-ident-check]. DTLS provides assurance 1372 that the authenticated identity has been signed by a trusted 1373 configured certificate authority. If verification of the 1374 server's certificate fails in any way (for example because of 1375 failures in cryptographic verification or the presented 1376 identity was not the expected identity) then the session 1377 establishment MUST fail, the 1378 dtlstmSessionInvalidServerCertificates object is incremented 1379 and processing is stopped. 1381 4) The DTLS-specific session identifier is passed to the DTLS 1382 Transport Model and associated with the tmStateReference cache 1383 entry to indicate that the session has been established 1384 successfully and to point to a specific DTLS session for future 1385 use. 1387 5.4. Closing a Session 1389 The DTLS Transport Model provides the following primitive to close a 1390 session: 1392 statusInformation = 1393 closeSession( 1394 IN tmStateReference -- transport info 1395 ) 1397 The following describes the procedure to follow to close a session 1398 between a client and server. This process is followed by any SNMP 1399 engine closing the corresponding SNMP session. 1401 1) Look up the session in the cache and the LCD using the 1402 tmStateReference. 1404 2) If there is no session open associated with the tmStateReference, 1405 then closeSession processing is completed. 1407 3) Delete the entry from the cache and any other implementation- 1408 dependent information in the LCD. 1410 4) Have DTLS close the specified session. This SHOULD include 1411 sending a close_notify TLS Alert to inform the other side that 1412 session cleanup may be performed. 1414 6. MIB Module Overview 1416 This MIB module provides management of the DTLS Transport Model. It 1417 defines needed textual conventions, statistical counters and 1418 configuration infrastructure necessary for session establishment. 1419 Example usage of the configuration tables can be found in Appendix A. 1421 6.1. Structure of the MIB Module 1423 Objects in this MIB module are arranged into subtrees. Each subtree 1424 is organized as a set of related objects. The overall structure and 1425 assignment of objects to their subtrees, and the intended purpose of 1426 each subtree, is shown below. 1428 6.2. Textual Conventions 1430 Generic and Common Textual Conventions used in this module can be 1431 found summarized at http://www.ops.ietf.org/mib-common-tcs.html 1433 This module defines two new Textual Conventions: a new 1434 TransportDomain and TransportAddress format for describing DTLS 1435 connection addressing requirements. 1437 6.3. Statistical Counters 1439 The DTLSTM-MIB defines some statical counters that can provide 1440 network managers with feedback about DTLS session usage and potential 1441 errors that a MIB-instrumented device may be experiencing. 1443 6.4. Configuration Tables 1445 The DTLSTM-MIB defines configuration tables that a manager can use 1446 for help in configuring a MIB-instrumented device for sending and 1447 receiving SNMP messages over DTLS. In particular, there is a MIB 1448 table that extends the SNMP-TARGET-MIB for configuring certificates 1449 to be used and a MIB table for mapping incoming DTLS client 1450 certificates to securityNames. 1452 6.5. Relationship to Other MIB Modules 1454 Some management objects defined in other MIB modules are applicable 1455 to an entity implementing the DTLS Transport Model. In particular, 1456 it is assumed that an entity implementing the DTLSTM-MIB will 1457 implement the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411], 1458 the SNMP-TARGET-MIB [RFC3413], the SNMP-NOTIFICATION-MIB [RFC3413] 1459 and the SNMP-VIEW-BASED-ACM-MIB [RFC3415]. 1461 This MIB module is for managing DTLS Transport Model information. 1463 6.5.1. MIB Modules Required for IMPORTS 1465 The following MIB module imports items from SNMPV2-SMI [RFC2578], 1466 SNMPV2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB 1467 [RFC3413] and SNMP-CONF [RFC2580]. 1469 7. MIB Module Definition 1471 DTLSTM-MIB DEFINITIONS ::= BEGIN 1473 IMPORTS 1474 MODULE-IDENTITY, OBJECT-TYPE, 1475 OBJECT-IDENTITY, snmpModules, snmpDomains, 1476 Counter32, Unsigned32 1477 FROM SNMPv2-SMI 1478 TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType 1479 FROM SNMPv2-TC 1480 MODULE-COMPLIANCE, OBJECT-GROUP 1481 FROM SNMPv2-CONF 1482 SnmpAdminString 1483 FROM SNMP-FRAMEWORK-MIB 1484 snmpTargetParamsEntry 1485 FROM SNMP-TARGET-MIB 1486 ; 1488 dtlstmMIB MODULE-IDENTITY 1489 LAST-UPDATED "200807070000Z" 1490 ORGANIZATION " " 1491 CONTACT-INFO "WG-EMail: 1492 Subscribe: 1494 Chairs: 1495 Co-editors: 1496 " 1498 DESCRIPTION "The DTLS Transport Model MIB 1500 Copyright (C) The IETF Trust (2008). This 1501 version of this MIB module is part of RFC XXXX; 1502 see the RFC itself for full legal notices." 1503 -- NOTE to RFC editor: replace XXXX with actual RFC number 1504 -- for this document and remove this note 1506 REVISION "200807070000Z" 1507 DESCRIPTION "The initial version, published in RFC XXXX." 1508 -- NOTE to RFC editor: replace XXXX with actual RFC number 1509 -- for this document and remove this note 1511 ::= { snmpModules xxxx } 1512 -- RFC Ed.: replace xxxx with IANA-assigned number and 1513 -- remove this note 1515 -- ************************************************ 1516 -- subtrees of the SNMP-DTLS-TM-MIB 1517 -- ************************************************ 1519 dtlstmNotifications OBJECT IDENTIFIER ::= { dtlstmMIB 0 } 1520 dtlstmObjects OBJECT IDENTIFIER ::= { dtlstmMIB 1 } 1521 dtlstmConformance OBJECT IDENTIFIER ::= { dtlstmMIB 2 } 1523 -- ************************************************ 1524 -- Objects 1525 -- ************************************************ 1527 snmpDTLSUDPDomain OBJECT-IDENTITY 1528 STATUS current 1529 DESCRIPTION 1530 "The SNMP over DTLS transport domain. The corresponding 1531 transport address is of type SnmpDTLSUDPAddress. 1533 When an SNMP entity uses the snmpDTLSUDPDomain transport 1534 model, it must be capable of accepting messages up to 1535 the maximum MTU size for an interface it supports, minus the 1536 needed IP, UDP, DTLS and other protocol overheads. 1538 The securityName prefix to be associated with the 1539 snmpDTLSUDPDomain is 'dudp'. This prefix may be used by 1540 security models or other components to identify what secure 1541 transport infrastructure authenticated a securityName." 1543 ::= { snmpDomains yy } 1545 -- RFC Ed.: replace yy with IANA-assigned number and 1546 -- remove this note 1548 -- RFC Ed.: replace 'dudp' with the actual IANA assigned prefix string 1549 -- if 'dtls' is not assigned to this document. 1551 snmpDTLSSCTPDomain OBJECT-IDENTITY 1552 STATUS current 1553 DESCRIPTION 1554 "The SNMP over DTLS transport domain. The corresponding 1555 transport address is of type SnmpDTLSSCTPAddress. 1557 When an SNMP entity uses the snmpDTLSSCTPDomain transport 1558 model, it must be capable of accepting messages up to 1559 the maximum MTU size for an interface it supports, minus the 1560 needed IP, SCTP, DTLS and other protocol overheads. 1562 The securityName prefix to be associated with the 1563 snmpDTLSSCTPDomain is 'dsct'. This prefix may be used by 1564 security models or other components to identify what secure 1565 transport infrastructure authenticated a securityName." 1567 ::= { snmpDomains zz } 1569 -- RFC Ed.: replace zz with IANA-assigned number and 1570 -- remove this note 1572 -- RFC Ed.: replace 'dsct' with the actual IANA assigned prefix string 1573 -- if 'dtls' is not assigned to this document. 1575 SnmpDTLSUDPAddress ::= TEXTUAL-CONVENTION 1576 DISPLAY-HINT "1a" 1577 STATUS current 1578 DESCRIPTION 1579 "Represents a UDP connection address for an IPv4 address, an 1580 IPv6 address or an ASCII encoded host name and port number. 1582 The hostname must be encoded in ASCII, as specified in RFC3490 1583 (Internationalizing Domain Names in Applications) followed by 1584 a colon ':' (ASCII character 0x3A) and a decimal port number 1585 in ASCII. The name SHOULD be fully qualified whenever 1586 possible. 1588 An IPv4 address must be a dotted decimal format followed by a 1589 colon ':' (ASCII character 0x3A) and a decimal port number in 1590 ASCII. 1592 An IPv6 address must be a colon separated format, surrounded 1593 by square brackets (ASCII characters 0x5B and 0x5D), followed 1594 by a colon ':' (ASCII character 0x3A) and a decimal port 1595 number in ASCII. 1597 Values of this textual convention may not be directly usable 1598 as transport-layer addressing information, and may require 1599 run-time resolution. As such, applications that write them 1600 must be prepared for handling errors if such values are not 1601 supported, or cannot be resolved (if resolution occurs at the 1602 time of the management operation). 1604 The DESCRIPTION clause of TransportAddress objects that may 1605 have snmpDTLSUDPAddress values must fully describe how (and 1606 when) such names are to be resolved to IP addresses and vice 1607 versa. 1609 This textual convention SHOULD NOT be used directly in object 1610 definitions since it restricts addresses to a specific 1611 format. However, if it is used, it MAY be used either on its 1612 own or in conjunction with TransportAddressType or 1613 TransportDomain as a pair. 1615 When this textual convention is used as a syntax of an index 1616 object, there may be issues with the limit of 128 1617 sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED 1618 that all MIB documents using this textual convention make 1619 explicit any limitations on index component lengths that 1620 management software must observe. This may be done either by 1621 including SIZE constraints on the index components or by 1622 specifying applicable constraints in the conceptual row 1623 DESCRIPTION clause or in the surrounding documentation." 1624 SYNTAX OCTET STRING (SIZE (1..255)) 1626 SnmpDTLSSCTPAddress ::= TEXTUAL-CONVENTION 1627 DISPLAY-HINT "1a" 1628 STATUS current 1629 DESCRIPTION 1630 "Represents a SCTP connection address for an IPv4 address, an 1631 IPv6 address or an ASCII encoded host name and port number. 1633 The hostname must be encoded in ASCII, as specified in RFC3490 1634 (Internationalizing Domain Names in Applications) followed by 1635 a colon ':' (ASCII character 0x3A) and a decimal port number 1636 in ASCII. The name SHOULD be fully qualified whenever 1637 possible. 1639 An IPv4 address must be a dotted decimal format followed by a 1640 colon ':' (ASCII character 0x3A) and a decimal port number in 1641 ASCII. 1643 An IPv6 address must be a colon separated format, surrounded 1644 by square brackets (ASCII characters 0x5B and 0x5D), followed 1645 by a colon ':' (ASCII character 0x3A) and a decimal port 1646 number in ASCII. 1648 Values of this textual convention may not be directly usable 1649 as transport-layer addressing information, and may require 1650 run-time resolution. As such, applications that write them 1651 must be prepared for handling errors if such values are not 1652 supported, or cannot be resolved (if resolution occurs at the 1653 time of the management operation). 1655 The DESCRIPTION clause of TransportAddress objects that may 1656 have snmpDTLSSCTPAddress values must fully describe how (and 1657 when) such names are to be resolved to IP addresses and vice 1658 versa. 1660 This textual convention SHOULD NOT be used directly in object 1661 definitions since it restricts addresses to a specific 1662 format. However, if it is used, it MAY be used either on its 1663 own or in conjunction with TransportAddressType or 1664 TransportDomain as a pair. 1666 When this textual convention is used as a syntax of an index 1667 object, there may be issues with the limit of 128 1668 sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED 1669 that all MIB documents using this textual convention make 1670 explicit any limitations on index component lengths that 1671 management software must observe. This may be done either by 1672 including SIZE constraints on the index components or by 1673 specifying applicable constraints in the conceptual row 1674 DESCRIPTION clause or in the surrounding documentation." 1675 SYNTAX OCTET STRING (SIZE (1..255)) 1677 X509IdentifierHashType ::= TEXTUAL-CONVENTION 1678 STATUS current 1679 DESCRIPTION 1680 "Identifies a hashing algorithm type that will be used for 1681 identifying an X.509 certificate. 1683 The md5(1) value SHOULD NOT be used." 1684 SYNTAX INTEGER { md5(1), sha1(2), sha256(3) } 1686 X509IdentifierHash ::= TEXTUAL-CONVENTION 1687 STATUS current 1688 DESCRIPTION 1689 "A hash value that uniquely identifies a certificate within a 1690 systems local certificate store. The length of the value 1691 stored in an object of type X509IdentifierHash is dependent on 1692 the hashing algorithm that produced the hash. 1694 MIB structures making use of this textual convention should 1695 have an accompanying object of type X509IdentifierHashType. 1696 " 1697 SYNTAX OCTET STRING 1699 -- The dtlstmSession Group 1701 dtlstmSession OBJECT IDENTIFIER ::= { dtlstmObjects 1 } 1703 dtlstmSessionOpens OBJECT-TYPE 1704 SYNTAX Counter32 1705 MAX-ACCESS read-only 1706 STATUS current 1707 DESCRIPTION 1708 "The number of times an openSession() request has been 1709 executed as an SSH client, whether it succeeded or failed." 1710 ::= { dtlstmSession 1 } 1712 dtlstmSessionCloses OBJECT-TYPE 1713 SYNTAX Counter32 1714 MAX-ACCESS read-only 1715 STATUS current 1716 DESCRIPTION 1717 "The number of times a closeSession() request has been 1718 executed as an SSH client, whether it succeeded or failed." 1719 ::= { dtlstmSession 2 } 1721 dtlstmSessionOpenErrors OBJECT-TYPE 1722 SYNTAX Counter32 1723 MAX-ACCESS read-only 1724 STATUS current 1725 DESCRIPTION 1726 "The number of times an openSession() request failed to open a 1727 session as a SSH client, for any reason." 1728 ::= { dtlstmSession 3 } 1730 dtlstmSessionNoAvailableSessions OBJECT-TYPE 1731 SYNTAX Counter32 1732 MAX-ACCESS read-only 1733 STATUS current 1734 DESCRIPTION 1735 "The number of times an outgoing message was dropped because 1736 the session associated with the passed tmStateReference was no 1737 longer (or was never) available." 1738 ::= { dtlstmSession 4 } 1740 dtlstmSessionInvalidClientCertificates OBJECT-TYPE 1741 SYNTAX Counter32 1742 MAX-ACCESS read-only 1743 STATUS current 1744 DESCRIPTION 1745 "The number of times an incoming session was not established 1746 on an SSH server because the presented client certificate was 1747 invalid. Reasons for invalidation includes, but is not 1748 limited to, crypographic validation failures and lack of a 1749 suitable mapping row in the dtlstmCertificateToSNTable." 1750 ::= { dtlstmSession 5 } 1752 dtlstmSessionInvalidServerCertificates OBJECT-TYPE 1753 SYNTAX Counter32 1754 MAX-ACCESS read-only 1755 STATUS current 1756 DESCRIPTION 1757 "The number of times an outgoing session was not established 1758 on an SSH client because the presented server certificate was 1759 invalid. Reasons for invalidation includes, but is not 1760 limited to, crypographic validation failures and an unexpected 1761 presented certificate identity." 1762 ::= { dtlstmSession 6 } 1764 dtlstmDTLSProtectionErrors OBJECT-TYPE 1765 SYNTAX Counter32 1766 MAX-ACCESS read-only 1767 STATUS current 1768 DESCRIPTION 1769 "The number of times DTLS processing resulted in a message 1770 being discarded because it failed its integrity test, 1771 decryption processing or other DTLS processing." 1772 ::= { dtlstmSession 7 } 1774 -- Configuration Objects 1776 dtlstmConfig OBJECT IDENTIFIER ::= { dtlstmObjects 2 } 1778 -- Certificate mapping 1780 dtlstmCertificateMapping OBJECT IDENTIFIER ::= { dtlstmConfig 1 } 1781 dtlstmCertificateToSNCount OBJECT-TYPE 1782 SYNTAX Unsigned32 1783 MAX-ACCESS read-only 1784 STATUS current 1785 DESCRIPTION 1786 "A count of the number of entries in the 1787 dtlstmCertificateToSNTable" 1788 ::= { dtlstmCertificateMapping 1 } 1790 dtlstmCertificateToSNTableLastChanged OBJECT-TYPE 1791 SYNTAX TimeStamp 1792 MAX-ACCESS read-only 1793 STATUS current 1794 DESCRIPTION 1795 "The value of sysUpTime.0 when the dtlstmCertificateToSNTable 1796 was last modified through any means, or 0 if it has not been 1797 modified since the command responder was started." 1798 ::= { dtlstmCertificateMapping 2 } 1800 dtlstmCertificateToSNTable OBJECT-TYPE 1801 SYNTAX SEQUENCE OF DtlstmCertificateToSNEntry 1802 MAX-ACCESS not-accessible 1803 STATUS current 1804 DESCRIPTION 1805 "A table listing the X.509 certificates known to the entity 1806 and the associated method for determining the SNMPv3 security 1807 name from a certificate. 1809 On an incoming DTLS/SNMP connection the client's presented 1810 certificate should be examined and validated based on an 1811 established trusted CA certificate or self-signed public 1812 certificate. This table does not provide a mechanism for 1813 uploading the certificates as that is expected to occur 1814 through an out-of-band transfer. 1816 Once the authenticity of the certificate has been verified, 1817 this table can be consulted to determine the appropriate 1818 securityName to identify the remote connection. This is done 1819 by comparing the issuer's fingerprint hash type and value and 1820 the certificate's fingerprint hash type and value against the 1821 dtlstmCertHashType and dtlstmCertHashValue values in each 1822 entry of this table. If a matching entry is found then the 1823 securityName is selected based on the dtlstmCertMapType, 1824 dtlstmCertHashType, dtlstmCertHashValue and 1825 dtlstmCertSecurityName fields and the resulting securityName 1826 is used to identify the other side of the DTLS connection. 1828 This table should be treated as an ordered list of mapping 1829 rules to check. The first mapping rule appropriately matching 1830 a certificate in the local certificate store with a 1831 corresponding hash type (dtlstmCertHashType) and hash value 1832 (dtlstmCertHashValue) will be used to perform the mapping from 1833 X.509 certificate values to a securityName. If, after a 1834 matching row is found but the mapping can not succeed for some 1835 other reason then further attempts to perform the mapping MUST 1836 NOT be taken. For example, if the entry being checked 1837 contains a dtlstmCertMapType of bySubjectAltName(2) and an 1838 incoming connection uses a certificate with an issuer 1839 certificate matching the dtlstmCertHashType and 1840 dtlstmCertHashValue fields but the connecting certificate does 1841 not contain a subjectAltName field then the lookup operation 1842 must be treated as a failure. No further rows are examined for 1843 other potential mappings. 1845 Missing values of dtlstmCertID are acceptable and 1846 implementations should treat missing entries as a failed match 1847 and should continue to the next highest numbered row. E.G., 1848 the table may legally contain only two rows with dtlstmCertID 1849 values of 10 and 20. 1851 Users are encouraged to make use of certificates with 1852 subjectAltName fields that can be used as securityNames so 1853 that a single root CA certificate can allow all child 1854 certificate's subjectAltName to map directly to a securityName 1855 via a 1:1 transformation. However, this table is flexible 1856 enough to allow for situations where existing deployed 1857 certificate infrastructures do not provide adequate 1858 subjectAltName values for use as SNMPv3 securityNames. 1859 Certificates may also be mapped to securityNames using the 1860 CommonName portion of the Subject field which is also a 1861 scalable method of mapping certificate components to 1862 securityNames. Finally, direct mapping from each individual 1863 certificate fingerprint to a securityName is possible but 1864 requires one entry in the table per securityName." 1865 ::= { dtlstmCertificateMapping 3 } 1867 dtlstmCertificateToSNEntry OBJECT-TYPE 1868 SYNTAX DtlstmCertificateToSNEntry 1869 MAX-ACCESS not-accessible 1870 STATUS current 1871 DESCRIPTION 1872 "A row in the dtlstmCertificateToSNTable that specifies a 1873 mapping for an incoming DTLS certificate to a securityName to 1874 use for the connection." 1875 INDEX { dtlstmCertID } 1876 ::= { dtlstmCertificateToSNTable 1 } 1878 DtlstmCertificateToSNEntry ::= SEQUENCE { 1879 dtlstmCertID Unsigned32, 1880 dtlstmCertHashType X509IdentifierHashType, 1881 dtlstmCertHashValue X509IdentifierHash, 1882 dtlstmCertMapType INTEGER, 1883 dtlstmCertSecurityName SnmpAdminString, 1884 dtlstmCertStorageType StorageType, 1885 dtlstmCertRowStatus RowStatus 1886 } 1888 dtlstmCertID OBJECT-TYPE 1889 SYNTAX Unsigned32 1890 MAX-ACCESS not-accessible 1891 STATUS current 1892 DESCRIPTION 1893 "A unique arbitrary number index for a given certificate 1894 entry." 1895 ::= { dtlstmCertificateToSNEntry 1 } 1897 dtlstmCertHashType OBJECT-TYPE 1898 SYNTAX X509IdentifierHashType 1899 MAX-ACCESS read-create 1900 STATUS current 1901 DESCRIPTION 1902 "The hash algorithm to use when applying a hash to a X.509 1903 certificate for purposes of referring to it from the 1904 dtlstmCertHashValue column. 1906 The md5(1) value SHOULD NOT be used." 1907 DEFVAL { sha256 } 1908 ::= { dtlstmCertificateToSNEntry 2 } 1910 dtlstmCertHashValue OBJECT-TYPE 1911 SYNTAX X509IdentifierHash 1912 MAX-ACCESS read-create 1913 STATUS current 1914 DESCRIPTION 1915 "A cryptographic hash of a X.509 certificate. The use of this 1916 hash is dictated by the dtlstmCertMapType column. 1917 " 1918 ::= { dtlstmCertificateToSNEntry 3 } 1920 dtlstmCertMapType OBJECT-TYPE 1921 SYNTAX INTEGER { specified(1), bySubjectAltName(2), byCN(3) } 1922 MAX-ACCESS read-create 1923 STATUS current 1924 DESCRIPTION 1925 "The mapping type used to obtain the securityName from the 1926 certificate. The possible values of use and their usage 1927 methods are defined as follows: 1929 specified(1): The securityName that should be used locally to 1930 identify the remote entity is directly specified 1931 in the dtlstmCertSecurityName column from this 1932 table. The dtlstmCertHashValue MUST refer to a 1933 X.509 client certificate that will be mapped 1934 directly to the securityName specified in the 1935 dtlstmCertSecurityName column. 1937 bySubjectAltName(2): 1938 The securityName that should be used locally to 1939 identify the remote entity should be taken from 1940 the subjectAltName portion of the X.509 1941 certificate. The dtlstmCertHashValue MUST refer 1942 to a trust anchor certificate that is 1943 responsible for issuing certificates with 1944 carefully controlled subjectAltName fields. 1946 byCN(3): The securityName that should be used locally to 1947 identify the remote entity should be taken from 1948 the CommonName portion of the Subject field from 1949 the X.509 certificate. The dtlstmCertHashValue 1950 MUST refer to a trust anchor certificate that is 1951 responsible for issuing certificates with 1952 carefully controlled CommonName fields." 1953 DEFVAL { specified } 1954 ::= { dtlstmCertificateToSNEntry 4 } 1956 dtlstmCertSecurityName OBJECT-TYPE 1957 SYNTAX SnmpAdminString (SIZE(0..32)) 1958 MAX-ACCESS read-create 1959 STATUS current 1960 DESCRIPTION 1961 "The securityName that the session should use if the 1962 dtlstmCertMapType is set to specified(1), otherwise the value 1963 in this column should be ignored. If dtlstmCertMapType is set 1964 to specifed(1) and this column contains a zero-length string 1965 (which is not a legal securityName value) this row is 1966 effectively disabled and the match will not be considered 1967 successful." 1968 DEFVAL { "" } 1969 ::= { dtlstmCertificateToSNEntry 5 } 1971 dtlstmCertStorageType OBJECT-TYPE 1972 SYNTAX StorageType 1973 MAX-ACCESS read-create 1974 STATUS current 1975 DESCRIPTION 1976 "The storage type for this conceptual row. Conceptual rows 1977 having the value 'permanent' need not allow write-access to 1978 any columnar objects in the row." 1979 DEFVAL { nonVolatile } 1980 ::= { dtlstmCertificateToSNEntry 6 } 1982 dtlstmCertRowStatus OBJECT-TYPE 1983 SYNTAX RowStatus 1984 MAX-ACCESS read-create 1985 STATUS current 1986 DESCRIPTION 1987 "The status of this conceptual row. This object may be used 1988 to create or remove rows from this table. 1990 The value of this object has no effect on whether 1991 other objects in this conceptual row can be modified." 1992 ::= { dtlstmCertificateToSNEntry 7 } 1994 -- Maps securityNames to certificates for use by the SNMP-TARGET-MIB 1996 dtlstmParamsCount OBJECT-TYPE 1997 SYNTAX Unsigned32 1998 MAX-ACCESS read-only 1999 STATUS current 2000 DESCRIPTION 2001 "A count of the number of entries in the 2002 dtlstmParamsTable" 2003 ::= { dtlstmCertificateMapping 4 } 2005 dtlstmParamsTableLastChanged OBJECT-TYPE 2006 SYNTAX TimeStamp 2007 MAX-ACCESS read-only 2008 STATUS current 2009 DESCRIPTION 2010 "The value of sysUpTime.0 when the dtlstmParamsTable 2011 was last modified through any means, or 0 if it has not been 2012 modified since the command responder was started." 2013 ::= { dtlstmCertificateMapping 5 } 2015 dtlstmParamsTable OBJECT-TYPE 2016 SYNTAX SEQUENCE OF DtlstmParamsEntry 2017 MAX-ACCESS not-accessible 2018 STATUS current 2019 DESCRIPTION 2020 "This table augments the SNMP-TARGET-MIB's 2021 snmpTargetParamsTable with additional a DTLS client-side 2022 certificate certificate identifier to use when establishing 2023 new DTLS connections." 2024 ::= { dtlstmCertificateMapping 6 } 2026 dtlstmParamsEntry OBJECT-TYPE 2027 SYNTAX DtlstmParamsEntry 2028 MAX-ACCESS not-accessible 2029 STATUS current 2030 DESCRIPTION 2031 "A conceptual row containing a locally held certificate's hash 2032 type and hash value for a given snmpTargetParamsEntry. The 2033 values in this row should be ignored if not the connection 2034 that needs to be established, as indicated by the 2035 SNMP-TARGET-MIB infrastructure, is not a DTLS based 2036 connection." 2037 AUGMENTS { snmpTargetParamsEntry } 2038 ::= { dtlstmParamsTable 1 } 2040 DtlstmParamsEntry ::= SEQUENCE { 2041 dtlstmParamsHashType X509IdentifierHashType, 2042 dtlstmParamsHashValue X509IdentifierHash, 2043 dtlstmParamsStorageType StorageType, 2044 dtlstmParamsRowStatus RowStatus 2045 } 2047 dtlstmParamsHashType OBJECT-TYPE 2048 SYNTAX X509IdentifierHashType 2049 MAX-ACCESS read-create 2050 STATUS current 2051 DESCRIPTION 2052 "The hash algorithm type for the hash stored in the 2053 dtlstmParamsHash column to identify a locally-held X.509 2054 certificate that should be used when initiating a DTLS 2055 connection as a DTLS client." 2056 DEFVAL { sha256 } 2057 ::= { dtlstmParamsEntry 1 } 2059 dtlstmParamsHashValue OBJECT-TYPE 2060 SYNTAX X509IdentifierHash 2061 MAX-ACCESS read-create 2062 STATUS current 2063 DESCRIPTION 2064 "A cryptographic hash of a X.509 certificate. This object 2065 should store the hash of a locally held X.509 certificate that 2066 should be used when initiating a DTLS connection as a DTLS 2067 client." 2069 ::= { dtlstmParamsEntry 2 } 2071 dtlstmParamsStorageType OBJECT-TYPE 2072 SYNTAX StorageType 2073 MAX-ACCESS read-create 2074 STATUS current 2075 DESCRIPTION 2076 "The storage type for this conceptual row. Conceptual rows 2077 having the value 'permanent' need not allow write-access to 2078 any columnar objects in the row." 2079 DEFVAL { nonVolatile } 2080 ::= { dtlstmParamsEntry 3 } 2082 dtlstmParamsRowStatus OBJECT-TYPE 2083 SYNTAX RowStatus 2084 MAX-ACCESS read-create 2085 STATUS current 2086 DESCRIPTION 2087 "The status of this conceptual row. This object may be used 2088 to create or remove rows from this table. 2090 The value of this object has no effect on whether 2091 other objects in this conceptual row can be modified." 2092 ::= { dtlstmParamsEntry 4 } 2094 -- ************************************************ 2095 -- dtlstmMIB - Conformance Information 2096 -- ************************************************ 2098 dtlstmCompliances OBJECT IDENTIFIER ::= { dtlstmConformance 1 } 2100 dtlstmGroups OBJECT IDENTIFIER ::= { dtlstmConformance 2 } 2102 -- ************************************************ 2103 -- Compliance statements 2104 -- ************************************************ 2106 dtlstmCompliance MODULE-COMPLIANCE 2107 STATUS current 2108 DESCRIPTION 2109 "The compliance statement for SNMP engines that support the 2110 SNMP-DTLS-TM-MIB" 2111 MODULE 2112 MANDATORY-GROUPS { dtlstmStatsGroup, 2113 dtlstmIncomingGroup, dtlstmOutgoingGroup } 2115 ::= { dtlstmCompliances 1 } 2117 -- ************************************************ 2118 -- Units of conformance 2119 -- ************************************************ 2120 dtlstmStatsGroup OBJECT-GROUP 2121 OBJECTS { 2122 dtlstmSessionOpens, 2123 dtlstmSessionCloses, 2124 dtlstmSessionOpenErrors, 2125 dtlstmSessionNoAvailableSessions, 2126 dtlstmSessionInvalidClientCertificates, 2127 dtlstmSessionInvalidServerCertificates, 2128 dtlstmDTLSProtectionErrors 2129 } 2130 STATUS current 2131 DESCRIPTION 2132 "A collection of objects for maintaining 2133 statistical information of an SNMP engine which 2134 implements the SNMP DTLS Transport Model." 2135 ::= { dtlstmGroups 1 } 2137 dtlstmIncomingGroup OBJECT-GROUP 2138 OBJECTS { 2139 dtlstmCertificateToSNCount, 2140 dtlstmCertificateToSNTableLastChanged, 2141 dtlstmCertHashType, 2142 dtlstmCertHashValue, 2143 dtlstmCertMapType, 2144 dtlstmCertSecurityName, 2145 dtlstmCertStorageType, 2146 dtlstmCertRowStatus 2147 } 2148 STATUS current 2149 DESCRIPTION 2150 "A collection of objects for maintaining 2151 incoming connection certificate mappings to 2152 securityNames of an SNMP engine which implements the 2153 SNMP DTLS Transport Model." 2154 ::= { dtlstmGroups 2 } 2156 dtlstmOutgoingGroup OBJECT-GROUP 2157 OBJECTS { 2158 dtlstmParamsCount, 2159 dtlstmParamsTableLastChanged, 2160 dtlstmParamsHashType, 2161 dtlstmParamsHashValue, 2162 dtlstmParamsStorageType, 2163 dtlstmParamsRowStatus 2164 } 2165 STATUS current 2166 DESCRIPTION 2167 "A collection of objects for maintaining 2168 outgoing connection certificates to use when opening 2169 connections as a result of SNMP-TARGET-MIB settings." 2170 ::= { dtlstmGroups 3 } 2172 END 2174 8. Operational Considerations 2176 This section discusses various operational aspects of the solution 2178 8.1. Sessions 2180 A session is discussed throughout this document as meaning a security 2181 association between the DTLS client and the DTLS server. State 2182 information for the sessions are maintained in each DTLSTM and this 2183 information is created and destroyed as sessions are opened and 2184 closed. Because of the connectionless nature of UDP, a "broken" 2185 session, one side up one side down, could result if one side of a 2186 session is brought down abruptly (i.e., reboot, power outage, etc.). 2187 Whenever possible, implementations SHOULD provide graceful session 2188 termination through the use of disconnect messages. Implementations 2189 SHOULD also have a system in place for dealing with "broken" 2190 sessions. Implementations SHOULD support the session resumption 2191 feature of TLS. 2193 To simplify session management it is RECOMMENDED that implementations 2194 utilize two separate ports, one for Notification sessions and one for 2195 Command sessions. If this implementation recommendation is followed, 2196 DTLS clients will always send REQUEST messages and DTLS servers will 2197 always send RESPONSE messages. With this assertion, implementations 2198 may be able to simplify "broken" session handling, session 2199 resumption, and other aspects of session management such as 2200 guaranteeing that Request- Response pairs use the same session. 2202 Depending on the algorithms used for generation of the master session 2203 secret, the privacy and integrity algorithms used to protect 2204 messages, the environment of the session, the amount of data 2205 transferred, and the sensitivity of the data, a time-to-live (TTL) 2206 value SHOULD be established for sessions. An upper limit of 24 hours 2207 is suggested for this TTL value. The TTL value could be stored in 2208 the LCD and checked before passing a message to the DTLS session. 2210 8.2. Notification Receiver Credential Selection 2212 When an SNMP engine needs to establish an outgoing session for 2213 notifications, the snmpTargetParamsTable includes an entry for the 2214 snmpTargetParamsSecurityName of the target. However, the receiving 2215 SNMP engine (Server) does not know which DTLS certificate to offer to 2216 the Client so that the tmSecurityName identity-authentication will be 2217 successful. The best solution would be to maintain a one-to-one 2218 mapping between certificates and incoming ports for notification 2219 receivers, although other implementation dependent mechanisms may be 2220 used instead. This can be handled at the Notification Originator by 2221 configuring the snmpTargetAddrTable (snmpTargetAddrTDomain and 2222 snmpTargetAddrTAddress) and then requiring the receiving SNMP engine 2223 to monitor multiple incoming static ports based on which principals 2224 are capable of receiving notifications. Implementations MAY also 2225 choose to designate a single Notification Receiver Principal to 2226 receive all incoming TRAPS and INFORMS. 2228 8.3. contextEngineID Discovery 2230 Because most Command Responders have contextEngineIDs that are 2231 identical to the USM securityEngineID, the USM provides Command 2232 Generators with the ability to discover a default contextEngineID to 2233 use. Because the DTLS transport does not make use of a discoverable 2234 securityEngineID like the USM does, it may be difficult for Command 2235 Generators to discover a suitable default contextEngineID. 2236 Implementations should consider offering another engineID discovery 2237 mechanism to continue providing Command Generators with a 2238 contextEngineID discovery mechanism. A recommended discovery 2239 solution is documented in [RFC5343]. 2241 9. Security Considerations 2243 This document describes a transport model that permits SNMP to 2244 utilize DTLS security services. The security threats and how the 2245 DTLS transport model mitigates these threats are covered in detail 2246 throughout this document. Security considerations for DTLS are 2247 covered in [RFC4347] and security considerations for TLS are 2248 described in Section 11 and Appendices D, E, and F of TLS 1.2 2249 [RFC5246]. DTLS adds to the security considerations of TLS only 2250 because it is more vulnerable to denial of service attacks. A random 2251 cookie exchange was added to the handshake to prevent anonymous 2252 denial of service attacks. RFC 4347 recommends that the cookie 2253 exchange is utilized for all handshakes and therefore it is 2254 RECOMMENDED that implementers also support this cookie exchange. 2256 9.1. Certificates, Authentication, and Authorization 2258 Implementations are responsible for providing a security certificate 2259 configuration installation . Implementations SHOULD support 2260 certificate revocation lists and expiration of certificates or other 2261 access control mechanisms. 2263 DTLS provides for both authentication of the identity of the DTLS 2264 server and authentication of the identity of the DTLS client. Access 2265 to MIB objects for the authenticated principal MUST be enforced by an 2266 access control subsystem (e.g. the VACM). 2268 Authentication of the Command Generator principal's identity is 2269 important for use with the SNMP access control subsystem to ensure 2270 that only authorized principals have access to potentially sensitive 2271 data. The authenticated identity of the Command Generator 2272 principal's certificate is mapped to an SNMP model-independent 2273 securityName for use with SNMP access control. 2275 Furthermore, the DTLS handshake only provides assurance that the 2276 certificate of the authenticated identity has been signed by an 2277 configured accepted Certificate Authority. DTLS has no way to 2278 further authorize or reject access based on the authenticated 2279 identity. An Access Control Model (such as the VACM) provides access 2280 control and authorization of a Command Generator's requests to a 2281 Command Responder and a Notification Responder's authorization to 2282 receive Notifications from a Notification Originator. However to 2283 avoid man-in-the-middle attacks both ends of the DTLS based 2284 connection MUST check the certificate presented by the other side 2285 against what was expected. For example, Command Generators must 2286 check that the Command Responder presented and authenticated itself 2287 with a X.509 certificate that was expected. Not doing so would allow 2288 an impostor, at a minimum, to present false data, receive sensitive 2289 information and/or provide a false-positive belief that configuration 2290 was actually received and acted upon. Authenticating and verifying 2291 the identity of the DTLS server and the DTLS client for all 2292 operations ensures the authenticity of the SNMP engine that provides 2293 MIB data. 2295 The instructions found in the DESCRIPTION clause of the 2296 dtlstmCertificateToSNTable object must be followed exactly. 2297 Specifically, it is important that if a row matching a certificate or 2298 a certificate's issuer is found but the translation to a securityName 2299 using the row fails that the lookup process stops and no further rows 2300 are consulted. It is also important that the rows of the table be 2301 search in order starting with the row containing the lowest numbered 2302 dtlstmCertID value. 2304 9.2. Use with SNMPv1/SNMPv2c Messages 2306 The SNMPv1 and SNMPv2c message processing described in RFC3484 (BCP 2307 74) [RFC3584] always selects the SNMPv1(1) Security Model for an 2308 SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c 2309 message. When running SNMPv1/SNMPv2c over a secure transport like 2310 the DTLS Transport Model, the securityName and securityLevel used for 2311 access control decisions are then derived from the community string, 2312 not the authenticated identity and securityLevel provided by the DTLS 2313 Transport Model. 2315 9.3. MIB Module Security 2317 The MIB objects in this document must be protected with an adequate 2318 level of at least integrity protection, especially those objects 2319 which are writable. Since knowledge of authorization rules and 2320 certificate usage mechanisms may be considered sensitive, protection 2321 from disclosure of the SNMP traffic via encryption is also highly 2322 recommended. 2324 SNMP versions prior to SNMPv3 did not include adequate security. 2325 Even if the network itself is secure (for example by using IPSec or 2326 DTLS) there is no control as to who on the secure network is allowed 2327 to access and GET/SET (read/change/create/delete) the objects in this 2328 MIB module. 2330 It is RECOMMENDED that implementers consider the security features as 2331 provided by the SNMPv3 framework (see section 8 of [RFC3410]), 2332 including full support for the USM (see [RFC3414]) and the DTLS 2333 Transport Model cryptographic mechanisms (for authentication and 2334 privacy). 2336 10. IANA Considerations 2338 IANA is requested to assign: 2340 1. a UDP port number in the range 1..1023 in the 2341 http://www.iana.org/assignments/port-numbers registry which will 2342 be the default port for SNMP command messages over a DTLS/UDP 2343 Transport Model as defined in this document, 2345 2. a UDP port number in the range 1..1023 in the 2346 http://www.iana.org/assignments/port-numbers registry which will 2347 be the default port for SNMP notification messages over a DTLS/ 2348 UDP Transport Model as defined in this document, 2350 3. a SCTP port number in the range 1..1023 in the 2351 http://www.iana.org/assignments/port-numbers registry which will 2352 be the default port for SNMP command messages over a DTLS/SCTP 2353 Transport Model as defined in this document, 2355 4. a SCTP port number in the range 1..1023 in the 2356 http://www.iana.org/assignments/port-numbers registry which will 2357 be the default port for SNMP notification messages over a DTLS/ 2358 SCTP Transport Model as defined in this document, 2360 5. an SMI number under snmpDomains for the snmpDTLSUDPDomain object 2361 identifier, 2363 6. an SMI number under snmpDomains for the snmpDTLSSCTPDomain object 2364 identifier, 2366 7. a SMI number under snmpModules, for the MIB module in this 2367 document, 2369 8. "dudp" as the corresponding prefix for the snmpDTLSUDPDomain in 2370 the SNMP Transport Model registry, 2372 9. "dsct" as the corresponding prefix for the snmpDTLSSCTPDomain in 2373 the SNMP Transport Model registry; 2375 11. Acknowledgements 2377 This document closely follows and copies the Secure Shell Transport 2378 Model for SNMP defined by David Harrington and Joseph Salowey in 2379 [I-D.ietf-isms-secshell]. 2381 This work was supported in part by the United States Department of 2382 Defense. Large portions of this document are based on work by 2383 General Dynamics C4 Systems and the following individuals: Brian 2384 Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John 2385 Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul, 2386 Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip. 2388 12. References 2390 12.1. Normative References 2392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2393 Requirement Levels", BCP 14, RFC 2119, March 1997. 2395 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2396 Protocol", RFC 2522, March 1999. 2398 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2399 Schoenwaelder, Ed., "Structure of Management Information 2400 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2402 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2403 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 2404 STD 58, RFC 2579, April 1999. 2406 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2407 "Conformance Statements for SMIv2", STD 58, RFC 2580, 2408 April 1999. 2410 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 2411 "Introduction and Applicability Statements for Internet- 2412 Standard Management Framework", RFC 3410, December 2002. 2414 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2415 Architecture for Describing Simple Network Management 2416 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2417 December 2002. 2419 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 2420 Management Protocol (SNMP) Applications", STD 62, 2421 RFC 3413, December 2002. 2423 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 2424 (USM) for version 3 of the Simple Network Management 2425 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 2427 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 2428 Access Control Model (VACM) for the Simple Network 2429 Management Protocol (SNMP)", STD 62, RFC 3415, 2430 December 2002. 2432 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 2433 Simple Network Management Protocol (SNMP)", STD 62, 2434 RFC 3418, December 2002. 2436 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 2437 "Coexistence between Version 1, Version 2, and Version 3 2438 of the Internet-standard Network Management Framework", 2439 BCP 74, RFC 3584, August 2003. 2441 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2442 Security", RFC 4347, April 2006. 2444 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2445 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2447 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2448 Housley, R., and W. Polk, "Internet X.509 Public Key 2449 Infrastructure Certificate and Certificate Revocation List 2450 (CRL) Profile", RFC 5280, May 2008. 2452 [I-D.ietf-isms-transport-security-model] 2453 Harington, D., "Transport Security Model for SNMP". 2455 [I-D.ietf-isms-tmsm] 2456 Harington, D. and J. Schoenwaelder, "Transport Subsystem 2457 for the Simple Network Management Protocol (SNMP)". 2459 [X509] Rivest, R., Shamir, A., and L. M. Adleman, "A Method for 2460 Obtaining Digital Signatures and Public-Key 2461 Cryptosystems". 2463 [AES] National Institute of Standards, "Specification for the 2464 Advanced Encryption Standard (AES)". 2466 [DES] National Institute of Standards, "American National 2467 Standard for Information Systems-Data Link Encryption". 2469 [DSS] National Institute of Standards, "Digital Signature 2470 Standard". 2472 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 2473 Obtaining Digital Signatures and Public-Key 2474 Cryptosystems". 2476 12.2. Informative References 2478 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2479 December 2005. 2481 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2482 RFC 4303, December 2005. 2484 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2485 RFC 4306, December 2005. 2487 [I-D.ietf-isms-secshell] 2488 Harington, D. and J. Salowey, "Secure Shell Transport 2489 Model for SNMP". 2491 [RFC5343] Schoenwaelder, J., "Simple Network Management Protocol 2492 (SNMP) Context EngineID Discovery". 2494 [I-D.hodges-server-ident-check] 2495 Hodges, J. and B. Morgan, "Generic Server Identity Check". 2497 Appendix A. Target and Notificaton Configuration Example 2499 Configuring the SNMP-TARGET-MIB and NOTIFICATION-MIB along with 2500 access control settings for the SNMP-VIEW-BASED-ACM-MIB can be a 2501 daunting task without an example to follow. The following section 2502 describes an example of what pieces must be in place to accomplish 2503 this configuration. 2505 The isAccessAllowed() ASI requires configuration to exist in the 2506 following SNMP-VIEW-BASED-ACM-MIB tables: 2508 vacmSecurityToGroupTable 2509 vacmAccessTable 2510 vacmViewTreeFamilyTable 2512 The only table that needs to be discussed as particularly different 2513 here is the vacmSecurityToGroupTable. This table is indexed by both 2514 the SNMPv3 security model and the security name. The security model, 2515 when DTLSTM is in use, should be set to the value of XXX 2516 corresponding to the TSM [I-D.ietf-isms-transport-security-model]. 2517 An example vacmSecurityToGroupTable row might be filled out as 2518 follows (using a single SNMP SET request): 2520 Note to RFC editor: replace XXX in the previous paragraph above with 2521 the actual IANA-assigned number for the TSM security model and remove 2522 this note. 2524 vacmSecurityModel = XXX (TSM) 2525 vacmSecurityName = "blueberry" 2526 vacmGroupaName = "administrators" 2527 vacmSecurityToGroupStorageType = 3 (nonVolatile) 2528 vacmSecurityToGroupStatus = 4 (createAndGo) 2530 Note to RFC editor: replace XXX in the vacmSecurityModel line above 2531 with the actual IANA-assigned number for the TSM security model and 2532 remove this note. 2534 This example will assume that the "administrators" group has been 2535 given proper permissions via rows in the vacmAccessTable and 2536 vacmViewTreeFamilyTable. 2538 Depending on whether this VACM configuration is for a Command 2539 Responder or a Command Generator the security name "blueberry" will 2540 come from a few different locations. 2542 For Notification Generator's performing authorization checks, the 2543 server's certificate must be verified against the expected 2544 certificate before proceeding to send the notification. The 2545 securityName be set by the SNMP-TARGET-MIB's 2546 snmpTargetParamsSecurityName column or other configuration mechanism 2547 and the certificate to use would be taken from the appropriate entry 2548 in the dtlstmParamsTable. The dtlstmParamsTable augments the SNMP- 2549 TARGET-MIB's snmpTargetParamsTable with client-side certificate 2550 information. 2552 For Command Responder applications, the vacmSecurityName "blueberry" 2553 value is a value that needs to come from an incoming DTLS session. 2554 The mapping from a recevied DTLS client certificate to a securityName 2555 is done with the dtlstmCertificateToSNTable. The certificates must 2556 be loaded into the device so that a dtlstmCertificateToSNEntry may 2557 refer to it. As an example, consider the following entry which will 2558 provide a mapping from a X.509's hash fingerprint directly to the 2559 "blueberry" securityName: 2561 dtlstmCertID = 1 (arbitrarily chosen) 2562 dtlstmCertHashType = sha256 2563 dtlstmCertHashValue = (appropriate sha256 fingerprint) 2564 dtlstmCertMapType = specified(1) 2565 dtlstmCertSecurityName = "blueberry" 2566 dtlstmCertStorageType = 3 (nonVolatile) 2567 dtlstmCertRowStatus = 4 (createAndGo) 2569 The above is an example of how to map a particular certificate to a 2570 particular securityName. It is recommended that users make use of 2571 direct subjectAltName or CommonName mappings where possible since it 2572 will provide a more scalable approach to certificate management. 2573 This entry provides an example of using a subjectAltName mapping: 2575 dtlstmCertID = 1 (arbitrarily chosen) 2576 dtlstmCertHashType = sha256 2577 dtlstmCertHashValue = (appropriate sha256 fingerprint) 2578 dtlstmCertMapType = bySubjectAltName(2) 2579 dtlstmCertStorageType = 3 (nonVolatile) 2580 dtlstmCertRowStatus = 4 (createAndGo) 2582 The above entry indicates the subjectAltName field for certificates 2583 created by an Issuing certificate with a corresponding hash type and 2584 value will be trusted to always produce common names that are 2585 directly 1 to 1 mappable into SNMPv3 securityNames. This type of 2586 configuration should only be used when the certificate authorities 2587 naming conventions are carefully controlled. 2589 For the example, if the incoming DTLS client provided certificate 2590 contained a subjectAltName of "blueberry" and the certificate was 2591 signed by a certificate matching the dtlstmCertHashType and 2592 dtlstmCertHashValue values above and the CA's certificate was 2593 properly installed on the device then the CommonName of "blueberry" 2594 would be used as the securityName for the session. 2596 Author's Address 2598 Wes Hardaker 2599 Sparta, Inc. 2600 P.O. Box 382 2601 Davis, CA 95617 2602 US 2604 Phone: +1 530 792 1913 2605 Email: ietf@hardakers.net