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