idnits 2.17.1 draft-hardaker-isms-dtls-tm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2198. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2222. 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 Copyright Line does not match the current year == Line 386 has weird spacing: '...patcher v ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2008) is 5772 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 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: Informational July 7, 2008 5 Expires: January 8, 2009 7 Datagram Transport Layer Security Transport Model for SNMP 8 draft-hardaker-isms-dtls-tm-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 8, 2009. 35 Abstract 37 This document describes a Transport Model for the Simple Network 38 Management Protocol (SNMP), that uses the Datagram Transport Layer 39 Security (DTLS) protocol. The DTLS protocol provides authentication 40 and privacy services for SNMP applications. This document describes 41 how the DTLS Transport Model (DTLSTM) implements the needed features 42 of a SNMP Transport Subsystem to make this protection possible in an 43 interoperable way. 45 This transport model is designed to meet the security and operational 46 needs of network administrators, operate in environments where a 47 connectionless (UDP) transport is preferred, and integrates well into 48 existing public keying infrastructures. 50 This document also defines a portion of the Management Information 51 Base (MIB) for monitoring and managing the DTLS Transport Model for 52 SNMP. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 6 58 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 59 2. The Datagram Transport Layer Security Protocol . . . . . . . . 6 60 2.1. The DTLS Record Protocol . . . . . . . . . . . . . . . . . 7 61 2.2. The DTLS Handshake Protocol . . . . . . . . . . . . . . . 7 62 3. How the DTLSTM fits into the Transport Subsystem . . . . . . . 8 63 3.1. Security Capabilities of this Model . . . . . . . . . . . 10 64 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.1.2. Security Level . . . . . . . . . . . . . . . . . . . . 12 66 3.1.3. DTLS Sessions . . . . . . . . . . . . . . . . . . . . 13 67 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 14 68 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14 69 4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15 70 4.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.1.1. The Certificate Infrastructure . . . . . . . . . . . . 15 72 4.1.2. Provisioning for the Certificate . . . . . . . . . . . 16 73 4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 4.3. tmStateReference Cache . . . . . . . . . . . . . . . . . . 17 75 4.3.1. tmTransportDomain and tmTransportAddress . . . . . . . 18 76 4.3.2. tmRequestedSecurityLevel . . . . . . . . . . . . . . . 18 77 4.3.3. tmSecurityLevel . . . . . . . . . . . . . . . . . . . 18 78 4.3.4. tmSecurityName . . . . . . . . . . . . . . . . . . . . 18 79 4.4. Transport Model LCD . . . . . . . . . . . . . . . . . . . 19 80 4.5. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 19 81 4.5.1. SNMP Services for an Outgoing Message . . . . . . . . 19 82 4.5.2. SNMP Services for an Incoming Message . . . . . . . . 20 83 4.6. DTLS Services . . . . . . . . . . . . . . . . . . . . . . 21 84 4.6.1. Services for Establishing a Session . . . . . . . . . 21 85 4.6.2. DTLS Services for an Incoming Message . . . . . . . . 22 86 4.6.3. DTLS Services for an Outgoing Message . . . . . . . . 23 87 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 24 88 5.1. Receiving an Incoming Message . . . . . . . . . . . . . . 24 89 5.2. Sending an Outgoing Message . . . . . . . . . . . . . . . 25 90 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 26 91 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 28 92 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 28 93 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28 94 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 29 95 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 29 96 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 29 97 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29 98 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29 99 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29 100 8. Operational Considerations . . . . . . . . . . . . . . . . . . 40 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 102 9.1. Certificates, Authentication, and Authorization . . . . . 41 103 9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 42 104 9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 42 105 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 106 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 108 12.1. Normative References . . . . . . . . . . . . . . . . . . . 43 109 12.2. Informative References . . . . . . . . . . . . . . . . . . 45 110 Appendix A. Target and Notificaton Configuration Example . . . . 45 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 112 Intellectual Property and Copyright Statements . . . . . . . . . . 48 114 1. Introduction 116 It is important to understand the SNMPv3 architecture [RFC3411], as 117 enhanced by the Transport Subsystem [I-D.ietf-isms-tmsm]. It is also 118 important to understand the terminology of the SNMPv3 architecture in 119 order to understand where the Transport Model described in this 120 document fits into the architecture and how it interacts with the 121 other architecture subsystems. For a detailed overview of the 122 documents that describe the current Internet-Standard Management 123 Framework, please refer to Section 7 of [RFC3410]. 125 This document describes a Transport Model that makes use of the 126 Datagram Transport Layer Security (DTLS) Protocol [RFC4347], the 127 datagram variant of the existing and commonly deployed Transport 128 Layer Security (TLS) protocol [RFC4346], within a transport subsystem 129 [I-D.ietf-isms-tmsm]. The Transport Model in this document is 130 referred to as the Datagram Transport Layer Security Transport Model 131 (DTLSTM). DTLS takes advantage of the X.509 public keying 132 infrastructure [X509]. This transport model is designed to meet the 133 security and operational needs of network administrators, operate in 134 environments where a connectionless (UDP) transport is preferred, and 135 integrate well into existing public keying infrastructures. 137 Managed objects are accessed via a virtual information store, termed 138 the Management Information Base or MIB. MIB objects are generally 139 accessed through the Simple Network Management Protocol (SNMP). 140 Objects in the MIB are defined using the mechanisms defined in the 141 Structure of Management Information (SMI). This document specifies a 142 MIB module that is compliant to the SMIv2, which is described in STD 143 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 144 2580 [RFC2580]. 146 This document also defines a portion of the Management Information 147 Base (MIB) for use with network management protocols in IP based 148 networks. In particular it defines objects for monitoring and 149 managing the DTLS Transport Model for SNMP. 151 The diagram shown below gives a conceptual overview of two SNMP 152 entities communicating using the DTLS Transport Model. One entity 153 contains a Command Responder and Notification Originator application, 154 and the other a Command Generator and Notification Responder 155 application. It should be understood that this particular mix of 156 application types is an example only and other combinations are 157 equally as legitimate. 159 +----------------------------------------------------------------+ 160 | Network | 161 +----------------------------------------------------------------+ 162 ^ ^ ^ ^ 163 |Notifications |Commands |Commands |Notifications 164 +---|---------------------|--------+ +--|---------------|-------------+ 165 | V V | | V V | 166 | +------------+ +------------+ | | +-----------+ +----------+ | 167 | | DTLS | | DTLS | | | | DTLS | | DTLS | | 168 | | Service | | Service | | | | Service | | Service | | 169 | | (Client) | | (Server) | | | | (Client) | | (Server)| | 170 | +------------+ +------------+ | | +-----------+ +----------+ | 171 | ^ ^ | | ^ ^ | 172 | +--+----------+ | | +-+--------------+ | 173 | +-----|---------+----+ | | +---|--------+----+ | 174 | | V |LCD | +-------+ | | | V |LCD | +--------+ | 175 | | +------+ +----+ | | | | | +------+ +----+ | | | 176 | | | DTLS | <---------->| Cache | | | | | DTLS | <---->| Cache | | 177 | | | TM | | | | | | | | TM | | | | | 178 | | +------+ | +-------+ | | | +------+ | +--------+ | 179 | |Transport Subsystem | ^ | | |Transport Sub. | ^ | 180 | +--------------------+ | | | +-----------------+ | | 181 | ^ +----+ | | ^ | | 182 | | | | | | | | 183 | v | | | V | | 184 | +-------+ +----------+ +-----+ | | | +-----+ +------+ +-----+ | | 185 | | | |Message | |Sec. | | | | | | | MP | |Sec. | | | 186 | | Disp. | |Processing| |Sub- | | | | |Disp.| | Sub- | |Sub- | | | 187 | | | |Subsystem | |sys. | | | | | | |system| |sys. | | | 188 | | | | | | | | | | | | | | | | | | 189 | | | | | |+---+| | | | | | | | |+---+| | | 190 | | | | +-----+ | || || | | | | | |+----+| || || | | 191 | | <--->|v3MP |<-->||TSM|<-+ | | | <-->|v3MP|<->|TSM|<-+ | 192 | | | | +-----+ | || || | | | | |+----+| || || | 193 | +-------+ | | |+---+| | | +-----+ | | |+---+| | 194 | ^ | | | | | | ^ | | | | | 195 | | +----------+ +-----+ | | | +------+ +-----+ | 196 | +-+----------+ | | +-+------------+ | 197 | ^ ^ | | ^ ^ | 198 | | | | | | | | 199 | v v | | V V | 200 | +-------------+ +--------------+ | | +-----------+ +--------------+ | 201 | | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | | 202 | | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RESPONDER | | 203 | | application | | applications | | | |application| | application | | 204 | +-------------+ +--------------+ | | +-----------+ +--------------+ | 205 | SNMP entity | | SNMP entity | 206 +----------------------------------+ +--------------------------------+ 208 1.1. Requirements Terminology 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [RFC2119]. 214 1.2. Conventions 216 For consistency with SNMP-related specifications, this document 217 favors terminology as defined in STD62 rather than favoring 218 terminology that is consistent with non-SNMP specifications that use 219 different variations of the same terminology. This is consistent 220 with the IESG decision to not require the SNMPv3 terminology be 221 modified to match the usage of other non-SNMP specifications when 222 SNMPv3 was advanced to Full Standard. 224 In particular, where distinction is required the application names of 225 "Command Generator", "Command Responder", "Notification Originator", 226 "Notification Receiver", and "Proxy Forwarder" are used. See the 227 "SNMP Applications" in [RFC3413] for further information. 229 Authentication in this document typically refers to source 230 authentication or peer identity authentication performed in the 231 transport subsystem. 233 Throughout this document, the terms "client" and "server" are used to 234 refer to the two ends of the DTLS session. The client actively opens 235 the DTLS session, and the server passively listens for the incoming 236 DTLS session. Any SNMP entity may act as client or as server. 238 While security protocols frequently refer to a "user", the term used 239 in RFC3411 [RFC3411] and in this document is "principal". A 240 principal is the "who" on whose behalf services are provided or 241 processing takes place. A principal can be, among other things, an 242 individual acting in a particular role; a set of individuals, with 243 each acting in a particular role; an application or a set of 244 applications, or a combination of these within an administrative 245 domain. 247 Throughout this document, the term "session" is used to refer to a 248 secure association between two DTLS Transport Models that permits the 249 transmission of one or more SNMP messages within the lifetime of the 250 session. 252 2. The Datagram Transport Layer Security Protocol 254 The DTLS protocol is a datagram-compatible variant of the commonly 255 used Transport Layer Security (TLS) protocol. DTLS provides 256 authentication, data message integrity, and privacy at the transport 257 layer. (See [RFC4347]) 259 The primary goals of the DTLS Transport Model are to provide privacy, 260 source authentication and data integrity between two communicating 261 SNMP entities. The DTLS protocol is composed of two layers: the DTLS 262 Record Protocol and the DTLS Handshake Protocol. The following 263 sections provide an overview of these two layers. Please refer to 264 [RFC4347] for a complete description of the protocol. 266 2.1. The DTLS Record Protocol 268 At the lowest layer, layered on top of the transport protocol (UDP) 269 is the DTLS Record Protocol. 271 The DTLS Record Protocol provides security that has three basic 272 properties: 274 o The session can be confidential. Symmetric cryptography is used 275 for data encryption (e.g., AES [AES], DES [DES] etc.). The keys 276 for this symmetric encryption are generated uniquely for each 277 session and are based on a secret negotiated by another protocol 278 (such as the DTLS Handshake Protocol). The Record Protocol can 279 also be used without encryption. 281 o Messages can have data integrity. Message transport includes a 282 message integrity check using a keyed MAC. Secure hash functions 283 (e.g., SHA, MD5, etc.) are used for MAC computations. The Record 284 Protocol can operate without a MAC, but is generally only used in 285 this mode while another protocol is using the Record Protocol as a 286 transport for negotiating security parameters. 288 o Messages are protected against replay. DTLS uses explicit 289 sequence numbers, integrity checks, and a sliding window to 290 protect against replay of messages within a session. 292 DTLS also provides protection against replay of entire sessions. In 293 a properly-implemented keying material exchange, both sides will 294 generate new random numbers for each exchange. This results in 295 different encryption and integrity keys for every session. 297 2.2. The DTLS Handshake Protocol 299 The DTLS Record Protocol is used for encapsulation of various higher- 300 level protocols. One such encapsulated protocol, the DTLS Handshake 301 Protocol, allows server and client to authenticate each other and to 302 negotiate an encryption algorithm and cryptographic keys before the 303 application protocol transmits or receives its first octet of data. 304 Only the DTLS client can initiate the handshake protocol. The DTLS 305 Handshake Protocol provides security that has three basic properties: 307 o The peer's identity can be authenticated using asymmetric, or 308 public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This 309 authentication can be made optional, but is generally required by 310 at least one of the peers. 312 DTLS supports three authentication modes: authentication of both the 313 server and the client, server authentication with an unauthenticated 314 client, and total anonymity. For authentication of both entities, 315 each entity provides a valid certificate chain leading to an 316 acceptable certificate authority. Each entity is responsible for 317 verifying that the other's certificate is valid and has not expired 318 or been revoked. The DTLS Transport Model SHOULD always use 319 authentication of both the server and the client. At a minimum the 320 DTLS Transport MUST support authentication of the Command Generator 321 principals to guarantee the authenticity of the securityName (a 322 parameter used to pass the authenticated identity name from the 323 transport model to security model for even later use by the access 324 control subsystem. See Section 4.3.4). The DTLS Transport SHOULD 325 support the message encryption to protect sensitive data from 326 eavesdropping attacks. 328 o The negotiation of a shared secret is secure: the negotiated 329 secret is unavailable to eavesdroppers, and for any authenticated 330 handshake the secret cannot be obtained, even by an attacker who 331 can place himself in the middle of the session. 333 o The negotiation is not vulnerable to malicious modification: it is 334 infeasible for an attacker to modify negotiation communication 335 without being detected by the parties to the communication. 337 o DTLS uses a stateless cookie exchange to protect against anonymous 338 denial of service attacks and has retransmission timers, sequence 339 numbers, and counters to handle message loss, reordering, and 340 fragmentation. 342 3. How the DTLSTM fits into the Transport Subsystem 344 A transport model is a component of the Transport Subsystem. The 345 DTLS Transport Model thus fits between the underlying DTLS transport 346 layer and the message Dispatcher [RFC3411] component of the SNMP 347 engine and the Transport Subsystem [I-D.ietf-isms-tmsm]. 349 The DTLS Transport Model will establish a session between itself and 350 the DTLS Transport Model of another SNMP engine. The sending 351 transport model passes unprotected messages from the dispatcher to 352 DTLS to be protected, and the receiving transport model accepts 353 decrypted and authenticated/integrity-checked incoming messages from 354 DTLS and passes them to the dispatcher. 356 After a DTLS Transport model session is established, SNMP messages 357 can conceptually be sent through the session from one SNMP message 358 dispatcher to another SNMP message dispatcher. If multiple SNMP 359 messages are needed to be passed between two SNMP applications they 360 SHOULD be passed through the same session. A DTLSTM implementation 361 engine MAY choose to close a DTLS session to conserve resources. 363 The DTLS Transport Model of an SNMP engine will perform the 364 translation between DTLS-specific security parameters and SNMP- 365 specific, model-independent parameters. 367 The diagram below depicts where the DTLS Transport Model fits into 368 the architecture described in RFC3411 and the Transport Subsystem: 370 +------------------------------+ 371 | Network | 372 +------------------------------+ 373 ^ ^ ^ 374 | | | 375 v v v 376 +-------------------------------------------------------------------+ 377 | +--------------------------------------------------+ | 378 | | Transport Subsystem | +--------+ | 379 | | +-----+ +-----+ +-----+ +-----+ +-------+ | | | | 380 | | | UDP | | TCP | | SSH | |DTLS | . . . | other |<--->| Cache | | 381 | | | | | | | TM | TM | | | | | | | 382 | | +-----+ +-----+ +-----+ +-----+ +-------+ | +--------+ | 383 | +--------------------------------------------------+ ^ | 384 | ^ | | 385 | | | | 386 | Dispatcher v | | 387 | +--------------+ +---------------------+ +----------------+ | | 388 | | Transport | | Message Processing | | Security | | | 389 | | Dispatch | | Subsystem | | Subsystem | | | 390 | | | | +------------+ | | +------------+ | | | 391 | | | | +->| v1MP |<--->| | USM | | | | 392 | | | | | +------------+ | | +------------+ | | | 393 | | | | | +------------+ | | +------------+ | | | 394 | | | | +->| v2cMP |<--->| | Transport | | | | 395 | | Message | | | +------------+ | | | Security |<--+ | 396 | | Dispatch <---->| +------------+ | | | Model | | | 397 | | | | +->| v3MP |<--->| +------------+ | | 398 | | | | | +------------+ | | +------------+ | | 399 | | PDU Dispatch | | | +------------+ | | | Other | | | 400 | +--------------+ | +->| otherMP |<--->| | Model(s) | | | 401 | ^ | +------------+ | | +------------+ | | 402 | | +---------------------+ +----------------+ | 403 | v | 404 | +-------+-------------------------+---------------+ | 405 | ^ ^ ^ | 406 | | | | | 407 | v v v | 408 | +-------------+ +---------+ +--------------+ +-------------+ | 409 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 410 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 411 | | application | | | | applications | | application | | 412 | +-------------+ +---------+ +--------------+ +-------------+ | 413 | ^ ^ | 414 | | | | 415 | v v | 416 | +----------------------------------------------+ | 417 | | MIB instrumentation | SNMP entity | 418 +-------------------------------------------------------------------+ 420 3.1. Security Capabilities of this Model 422 3.1.1. Threats 424 The DTLS Transport Model provides protection against the threats 425 identified by the RFC 3411 architecture [RFC3411]: 427 1. Modification of Information - The modification threat is the 428 danger that some unauthorized entity may alter in-transit SNMP 429 messages generated on behalf of an authorized principal in such a 430 way as to effect unauthorized management operations, including 431 falsifying the value of an object. 433 DTLS provides verification that the content of each received 434 message has not been modified during its transmission through the 435 network, data has not been altered or destroyed in an 436 unauthorized manner, and data sequences have not been altered to 437 an extent greater than can occur non-maliciously. 439 2. Masquerade - The masquerade threat is the danger that management 440 operations unauthorized for a given principal may be attempted by 441 assuming the identity of a principal with appropriate 442 authorizations. 444 The DTLSTM provides for authentication of the Principal Command 445 Generator and Notification Generator and for authentication of 446 the Command Responder, Notification Responder and Proxy Forwarder 447 through the use of X.509 certificates. 449 The masquerade threat can be mitigated against by using an 450 appropriate Access Control Model (ACM) such as the View-based 451 Access Control Module (VACM) [RFC3415]. In addition, it is 452 important to authenticate and verify both the authenticated 453 identity of the DTLS client and the DTLS server to protect 454 against this threat. (See Security Considerations for more 455 detail.) 457 3. Message stream modification - The re-ordering, delay or replay of 458 messages can and does occur through the natural operation of many 459 connectionless transport services. The message stream 460 modification threat is the danger that messages may be 461 maliciously re-ordered, delayed or replayed to an extent which is 462 greater than can occur through the natural operation of 463 connectionless transport services, in order to effect 464 unauthorized management operations. 466 DTLS provides replay protection with a MAC that includes a 467 sequence number. DTLS uses a sliding window protocol with the 468 sequence number for replay protection, see [RFC4347]. The 469 technique used is the same as in IPsec AH/ESP [RFC4302] 470 [RFC4303], by maintaining a bitmap window of received records. 471 Records that are too old to fit in the window and records that 472 have previously been received are silently discarded. The replay 473 detection feature is optional, since packet duplication can also 474 occur naturally due to routing errors and does not necessarily 475 indicate an active attack. Applications may conceivably detect 476 duplicate packets and accordingly modify their data transmission 477 strategy. 479 4. Disclosure - The disclosure threat is the danger of eavesdropping 480 on the exchanges between SNMP engines. Protecting against this 481 threat may be required as a matter of local policy. 483 Symmetric cryptography (e.g., AES [AES], DES [DES] etc.) can be 484 used by DTLS for data privacy. The keys for this symmetric 485 encryption are generated uniquely for each session and are based 486 on a secret negotiated by another protocol (such as the DTLS 487 Handshake Protocol). 489 5. Denial of Service - the RFC 3411 architecture [RFC3411] states 490 that denial of service (DoS) attacks need not be addressed by an 491 SNMP security protocol. However, datagram security protocols are 492 susceptible to a variety of denial of service attacks. Two 493 attacks are of particular concern: 495 o An attacker can consume excessive resources on the server by 496 transmitting a series of handshake initiation requests, 497 causing the server to allocate state and potentially to 498 perform expensive cryptographic operations. 500 o An attacker can use the server as an amplifier by sending 501 session initiation messages with a forged source of the 502 victim. The server then sends its next message (in DTLS, a 503 Certificate message, which can be quite large) to the victim 504 machine, thus flooding it. 506 In order to counter both of these attacks, DTLS borrows the 507 stateless cookie technique used by Photuris [RFC2522] and IKEv2 508 [RFC4306]. When the client sends its ClientHello message to the 509 server, the server MAY respond with a HelloVerifyRequest message. 510 This message contains a stateless cookie generated using the 511 technique of [RFC2522]. The client MUST retransmit the 512 ClientHello with the cookie added. The server then verifies the 513 cookie and proceeds with the handshake only if it is valid. This 514 mechanism forces the attacker/client to be able to receive the 515 cookie, which makes DoS attacks with spoofed IP addresses 516 difficult. This mechanism does not provide any defense against 517 denial of service attacks mounted from valid IP addresses. 519 Implementations are not required to perform the stateless cookie 520 exchange for every DTLS handshakes but in environments where 521 amplification could be an issue it is RECOMMENDED that the cookie 522 exchange is utilized. 524 3.1.2. Security Level 526 The RFC 3411 architecture recognizes three levels of security: 528 o without authentication and without privacy (noAuthNoPriv) 530 o with authentication but without privacy (authNoPriv) 532 o with authentication and with privacy (authPriv) 534 The DTLS Transport Model determines from DTLS the identity of the 535 authenticated principal, and the type and address associated with an 536 incoming message, and the DTLS Transport Model provides this 537 information to DTLS for an outgoing message. 539 When an application requests a session for a message, through the 540 cache, the application requests a security level for that session. 541 The DTLS Transport Model MUST ensure that the DTLS session provides 542 security at least as high as the requested level of security. How 543 the security level is translated into the algorithms used to provide 544 data integrity and privacy is implementation-dependent. However, the 545 NULL integrity and encryption algorithms MUST NOT be used to fulfill 546 security level requests for authentication or privacy. 547 Implementations MAY choose to force DTLS to only allow cipher_suites 548 that provide both authentication and privacy to guarantee this 549 assertion. 551 If a suitable interface between the DTLS Transport Model and the DTLS 552 Handshake Protocol is implemented to allow the selection of security 553 level dependent algorithms, for example a security level to 554 cipher_suites mapping table, then different security levels may be 555 utilized by the application. However, different port numbers will 556 need to be used by at least one side of the connection to 557 differentiate between the DTLS sessions. This is the only way to 558 ensured proper selection of a session ID for an incoming DTLS 559 message. 561 The authentication, integrity and privacy algorithms used by the DTLS 562 Protocol [RFC4347] may vary over time as the science of cryptography 563 continues to evolve and the development of DTLS continues over time. 564 Implementers are encouraged to plan for changes in operator trust of 565 particular algorithms and implementations should offer configuration 566 settings for mapping algorithms to SNMPv3 security levels. 568 3.1.3. DTLS Sessions 570 DTLS sessions are opened by the DTLS Transport Model during the 571 elements of procedure for an outgoing SNMP message. Since the sender 572 of a message initiates the creation of a DTLS session if needed, the 573 DTLS session will already exist for an incoming message. 575 Implementations MAY choose to instantiate DTLS sessions in 576 anticipation of outgoing messages. This approach might be useful to 577 ensure that a DTLS session to a given target can be established 578 before it becomes important to send a message over the DTLS session. 579 Of course, there is no guarantee that a pre-established session will 580 still be valid when needed. 582 DTLS sessions are uniquely identified within the DTLS Transport Model 583 by the combination of transportDomain, transportAddress, 584 securityName, and requestedSecurityLevel associated with each 585 session. Each unique combination of these parameters MUST have a 586 locally-chosen unique dtlsSessionID associated for active sessions. 587 For further information see Section 4.6 and Section 5. 589 3.2. Security Parameter Passing 591 For the DTLS server-side, DTLS-specific security parameters (i.e., 592 cipher_suites, common name of X.509 certificate, IP address and port) 593 are translated by the DTLS Transport Model into security parameters 594 for the DTLS Transport Model and security model (i.e., securityLevel, 595 securityName, transportDomain, transportAddress). The transport- 596 related and DTLS-security-related information, including the 597 authenticated identity, are stored in a cache referenced by 598 tmStateReference. 600 For the DTLS client-side, the DTLS Transport Model takes input 601 provided by the dispatcher in the sendMessage() Abstract Service 602 Interface (ASI) and input from the tmStateReference cache. The DTLS 603 Transport Model converts that information into suitable security 604 parameters for DTLS and establishes sessions as needed. 606 The elements of procedure in Section 5 discuss these concepts in much 607 greater detail. 609 3.3. Notifications and Proxy 611 DTLS sessions may be initiated by DTLS clients on behalf of command 612 generators or notification originators. Command generators are 613 frequently operated by a human, but notification originators are 614 usually unmanned automated processes. The targets to whom 615 notifications should be sent is typically determined and configured 616 by a network administrator. 618 The SNMP-TARGET-MIB module [RFC3413] contains objects for defining 619 management targets, including transportDomain, transportAddress, 620 securityName, securityModel, and securityLevel parameters, for 621 Notification Generator, Proxy Forwarder, and SNMP-controllable 622 Command Generator applications. Transport domain and transport 623 address are configured in the snmpTargetAddrTable, and the 624 securityModel, securityName, and securityLevel parameters are 625 configured in the snmpTargetParamsTable. This document defines a MIB 626 module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to 627 specify a DTLS client-side certificate to use for the connection. 629 When configuring a DTLS target, the snmpTargetAddrTDomain and 630 snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be 631 set to the snmpDTLSDomain object and an appropriate snmpDTLSAddress 632 value respectively. The snmpTargetParamsMPModel column of the 633 snmpTargetParamsTable should be set to the XXX:TMSM value. The 634 snmpTargetParamsSecurityName should be set to an appropriate 635 securityName value and the dtlstmParamsSubject parameter of the 636 dtlstmParamsTable should be set to the Subject of the locally held 637 certificate to be used. Other parameters, for example cipher suites, 638 must come from configuration mechanisms not defined in this document. 639 The other needed configuration may be configured using SNMP or other 640 implementation-dependent mechanisms (such as via a CLI or a 641 configuration system). This securityName defined in the 642 snmpTargetParamsSecurityName column will be used by the access 643 control model to authorize any notifications that need to be sent. 645 4. Elements of the Model 647 This section contains definitions required to realize the DTLS 648 Transport Model defined by this document. 650 4.1. Certificates 652 4.1.1. The Certificate Infrastructure 654 Users of a public key SHALL be confident that the associated private 655 key is owned by the correct remote subject (person or system) with 656 which an encryption or digital signature mechanism will be used. 657 This confidence is obtained through the use of public key 658 certificates, which are data structures that bind public key values 659 to subjects. The binding is asserted by having a trusted CA 660 digitally sign each certificate. The CA may base this assertion upon 661 technical means (i.e., proof of possession through a challenge- 662 response protocol), presentation of the private key, or on an 663 assertion by the subject. A certificate has a limited valid lifetime 664 which is indicated in its signed contents. Because a certificate's 665 signature and timeliness can be independently checked by a 666 certificate-using client, certificates can be distributed via 667 untrusted communications and server systems, and can be cached in 668 unsecured storage in certificate-using systems. 670 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 671 first published in 1988 as part of the X.500 Directory 672 recommendations, defines a standard certificate format [X509] which 673 is a certificate which binds a subject (principal) to a public key 674 value. This was later further documented in [RFC5280]. 676 A X.509 certificate is a sequence of three required fields: 678 tbsCertificate: The field contains the names of the subject and 679 issuer, a public key associated with the subject, a validity 680 period, and other associated information. This field may also 681 contain extensions. 683 signatureAlgorithm: The signatureAlgorithm field contains the 684 identifier for the cryptographic algorithm used by the certificate 685 authority (CA) to sign this certificate. 687 signatureValue: The signatureValue field contains a digital 688 signature computed upon the ASN.1 DER encoded tbsCertificate 689 field. The ASN.1 DER encoded tbsCertificate is used as the input 690 to the signature function. This signature value is then ASN.1 691 encoded as a BIT STRING and included in the Certificate's 692 signature field. By generating this signature, a CA certifies the 693 validity of the information in the tbsCertificate field. In 694 particular, the CA certifies the binding between the public key 695 material and the subject of the certificate. 697 The basic X.509 authentication procedure is as follows: A system, 698 which uses the X.509 key management infrastructure, is initialized 699 with a number of root certificates which contain the public keys of a 700 number of trusted CAs. When a system receives a X.509 certificate, 701 signed by one of those CAs, that has to be verified, it first 702 decrypts the signatureValue field by using the public key of the 703 corresponding trusted CA. Then it compares the decrypted information 704 with the tbsCertificate field. If they match, then the subject in 705 the tbsCertificate field is authenticated. 707 4.1.2. Provisioning for the Certificate 709 Authentication using DTLS will require that SNMP entities are 710 provisioned with certificates, which are signed by trusted 711 certificate authorities. Furthermore, SNMP entities will most 712 commonly need to be provisioned with root certificates which 713 represent the list of trusted certificate authorities that an SNMP 714 entity can use for certificate verification. SNMP entities MAY also 715 be provisioned with X.509 certificate revocation mechanism which will 716 be used to verify that a certificate has not been revoked. 718 The authenticated securityName of the principal is looked up using 719 the dtlstmCertificateToSNTable. This table maps the certificates 720 issuer's distinguished name to a directly specified securityName or 721 it specifies that the CommonName field of the certificate's Subject 722 should be used as the securityName. The certificate trust anchors, 723 being either CA certificates or public keys for use by self-signed 724 certificates, must be installed through an out of band trusted 725 mechanism into the server and its authenticity MUST be verified 726 before access is granted. Implementations MAY choose to discard any 727 connections for which no dtlstmCertificateToSNTable mapping exists 728 for the issuer to avoid the computational resources associated with a 729 certificate verification check since the verified certificate would 730 be unusable anyway. 732 The typical setting will map the "CommonName" component of the 733 Subject field in the tbsCertificate to the DTLSSM specific 734 securityName. Thus, the authenticated identity can be verified by 735 the DTLS Transport Model by extracting the CommonName from the 736 Subject of the peer certificate and the receiving application will 737 have an appropriate securityName for use by components like an access 738 control model. 740 An example mapping setup can be found in Appendix A 742 [XXX: This securityName may be later translated from a DTLSSM 743 specific securityName to a SNMP engine securityName by the TMSM or TM 744 component configuration. Waiting on discussion/resolution within the 745 ISMS list about this]. 747 4.2. Messages 749 As stated in RFC4347, each DTLS message must fit within a single 750 datagram. The DTLSTM MUST prohibit SNMP messages from being set that 751 exceed the MTU size. The DTLSTM implementation MUST return an error 752 when the MTU size would be exceeded and the message won't be sent. 754 For Ethernet the MTU size is 1500 and thus the maximum allowable SNMP 755 message that can be sent over DTLSTM after UDP/IP/DTLS overhead is 756 taken into account will be 1455 for IPv6 (MTU:1500 - IPv6:40 - UDP:8 757 - DTLS:13) and 1475 for IPv4 (MTU:1500 - IPv4:20 - UDP:8 - DTLS:13). 758 From this integrity and encryption over head also needs to be 759 subtracted, which are integrity and encryption algorithm specific. 761 4.3. tmStateReference Cache 763 For the DTLS Transport Model, the session state is maintained using 764 tmStateReference. Upon opening each DTLS session, the DTLS Transport 765 Model stores model- and mechanism-specific information about the 766 session in a cache, referenced by tmStateReference. An 767 implementation might store the contents of the cache in a Local 768 Configuration Datastore (LCD). 770 The following four parameters, referred to as tmSecurityData, are 771 stored in the cache: 773 tmTransportDomain = Specified by the application 775 tmTransportAddress = Specified by the application 777 tmRequestedSecurityLevel = ["noAuthNoPriv" | "authNoPriv" | 778 "authPriv" ] the security level requested by the application 779 tmSecurityLevel = ["noAuthNoPriv" | "authNoPriv" | "authPriv" ] the 780 security level of the established DTLS session 782 tmSecurityName = the security name associated with a principal 784 The tmStateReference cache is used to pass a reference to the 785 tmSecurityData between the DTLS Transport Model and the security 786 model. 788 The DTLS Transport Model has the responsibility for releasing the 789 complete tmStateReference and deleting the associated information 790 when the session is destroyed. 792 4.3.1. tmTransportDomain and tmTransportAddress 794 The tmTransportDomain and tmTransportAddress identify the type and 795 address of the DTLS transport endpoint. The domain for address types 796 DTLS SHOULD be "snmpDTLSDomain" and the address should be one that 797 conforms to the details specified in the "SnmpDTLSAddress" textual 798 convention. These parameters are stored in a cache for active 799 sessions and referenced by tmStateReference. 801 4.3.2. tmRequestedSecurityLevel 803 The tmRequestedSecurityLevel is the security level requested by the 804 application. This parameter is set in the cache by the security 805 model and used by DTLS Transport Model initiating a session to select 806 the appropriate cipher_suites and other configuration needed settings 807 for establishing the session. The DTLS Transport Model MUST ensure 808 that the actual security provided by the session (tmSecurityLevel) is 809 at least as high as the requested security level 810 (tmRequestedSecurityLevel). 812 4.3.3. tmSecurityLevel 814 The tmSecurityLevel is the actual security level of the established 815 session. See Section 3.1.2 for more detail about security levels. 816 How the chosen cipher_suites and other DTLS session parameters are 817 translated into a security level at the DTLS Transport Model is 818 implementation dependent and/or policy specific. Implementations 819 MUST NOT use NULL algorithms for fulfilling authentication or 820 encryption needs indicated by the tmSecurityLevel. 822 4.3.4. tmSecurityName 824 The tmSecurityName is the name of the principal on whose behalf the 825 message is being sent. This field is set via the mapping defined in 826 the dtlstmCertificateToSNTable when mapping incoming client 827 connection certificates to a tmSecurityName. For outgoing 828 connections, the application will specify the value that should be 829 placed in this field possibly by extracting it from the SNMP-TARGET- 830 MIB's snmpTargetParamsSecurityName value. The tmSecurityName is 831 stored in a cache for active sessions and referenced by 832 tmStateReference. 834 4.4. Transport Model LCD 836 Implementations may store DTLS-specific and model-specific 837 information in a LCD. The DTLS session ID is one such parameter that 838 could be stored in the LCD. When messages are to be routed for 839 encapsulation or for integrity verification and decryption the 840 message and the DTLS session ID must be passed to the DTLS transport 841 layer for processing. Therefore, the DTLS Transport Model MUST 842 maintain a one-to-one mapping between the DTLS session ID and the 843 tmStateReference cache entry for that session. Implementations MAY 844 choose to store the DTLS session ID in the tmStateReference cache to 845 simplify the procedure. 847 4.5. SNMP Services 849 This section describes the services provided by the DTLS Transport 850 Model with their inputs and outputs. The services are between the 851 Transport Model and the Dispatcher. 853 The services are described as primitives of an abstract service 854 interface (ASI) and the inputs and outputs are described as abstract 855 data elements as they are passed in these abstract service 856 primitives. 858 4.5.1. SNMP Services for an Outgoing Message 860 The Dispatcher passes the information to the DTLS Transport Model 861 using the ASI defined in the transport subsystem: 863 statusInformation = 864 sendMessage( 865 IN destTransportDomain -- transport domain to be used 866 IN destTransportAddress -- transport address to be used 867 IN outgoingMessage -- the message to send 868 IN outgoingMessageLength -- its length 869 IN tmStateReference -- reference to transport state 870 ) 872 The abstract data elements passed as parameters in the abstract 873 service primitives are as follows: 875 statusInformation: An indication of whether the passing of the 876 message was successful. If not it is an indication of the 877 problem. 879 destTransportDomain: The transport domain for the associated 880 destTransportAddress. The Transport Model uses this parameter to 881 determine the transport type of the associated 882 destTransportAddress. This parameter may also be used by the 883 transport subsystem to route the message to the appropriate 884 Transport Model. 886 destTransportAddress: The transport address of the destination DTLS 887 Transport Model in a format specified by the SnmpDTLSAddress 888 TEXTUAL-CONVENTION. 890 outgoingMessage: The outgoing message to send to DTLS for 891 encapsulation. 893 outgoingMessageLength: The length of the outgoing message. 895 tmStateReference: A handle/reference to tmSecurityData to be used 896 when securing outgoing messages. 898 4.5.2. SNMP Services for an Incoming Message 900 The DTLS Transport Model processes the received message from the 901 network using the DTLS service and then passes it to the Dispatcher 902 using the following ASI: 904 receiveMessage( 905 IN transportDomain -- origin transport domain 906 IN transportAddress -- origin transport address 907 IN incomingMessage -- the message received 908 IN incomingMessageLength -- its length 909 IN tmStateReference -- reference to transport state 910 ) 912 The abstract data elements passed as parameters in the abstract 913 service primitives are as follows: 915 statusInformation: An indication of whether the passing of the 916 message was successful. If not it is an indication of the 917 problem. 919 transportDomain: The transport domain for the associated 920 transportAddress. 922 transportAddress: The transport address of the source of the 923 received message in a format specified by the SnmpDTLSAddress 924 TEXTUAL-CONVENTION. 926 incomingMessage: The whole SNMP message stripped of all DTLS 927 protection data. 929 incomingMessageLength: The length of the SNMP message after being 930 processed by DTLS. 932 tmStateReference: A handle/reference to tmSecurityData to be used by 933 the security model. 935 4.6. DTLS Services 937 This section describes the services provided by the DTLS Transport 938 Model with their inputs and outputs. These services are between the 939 DTLS Transport Model and the DTLS transport layer. The following 940 sections describe services for establishing and closing a session and 941 for passing messages between the DTLS transport layer and the DTLS 942 Transport Model. 944 4.6.1. Services for Establishing a Session 946 The DTLS Transport Model provides the following ASI to describe the 947 data passed between the Transport Model and the DTLS transport layer 948 for session establishment. 950 statusInformation = -- errorIndication or success 951 openSession( 952 IN destTransportDomain -- transport domain to be used 953 IN destTransportAddress -- transport address to be used 954 IN securityName -- on behalf of this principal 955 IN securityLevel -- Level of Security requested 956 OUT dtlsSessionID -- Session identifier for DTLS 957 ) 959 The abstract data elements passed as parameters in the abstract 960 service primitives are as follows: 962 statusInformation: An indication of whether the process was 963 successful or not. If not, then the status information will 964 include the error indication provided by DTLS. 966 destTransportDomain: The transport domain for the associated 967 destTransportAddress. The DTLS Transport Model uses this 968 parameter to determine the transport type of the associated 969 destTransportAddress. 971 destTransportAddress: The transport address of the destination DTLS 972 Transport Model in a format specified by the SnmpDTLSAddress 973 TEXTUAL-CONVENTION. 975 securityName: The security name representing the principal on whose 976 behalf the message will be sent. 978 securityLevel: The level of security requested by the application. 980 dtlsSessionID: An implementation-dependent session identifier to 981 reference the specific DTLS session. 983 The procedural details for establishing a session are further 984 described in Section 5.3. 986 Upon completion of the process the DTLS Transport Model returns 987 status information and, if the process was successful the 988 dtlsSessionID and other implementation-dependent data from DTLS are 989 also returned. The dtlsSessionID is stored in an implementation- 990 dependent manner and tied to the tmSecurityData for future use of 991 this session. 993 4.6.2. DTLS Services for an Incoming Message 995 When the DTLS Transport Model invokes the DTLS record layer to verify 996 proper security for the incoming message, it must use the following 997 ASI: 999 statusInformation = -- errorIndication or success 1000 dtlsRead( 1001 IN dtlsSessionID -- Session identifier for DTLS 1002 IN wholeDtlsMsg -- as received on the wire 1003 IN wholeDtlsMsgLength -- length as received on the wire 1004 OUT incomingMessage -- the whole SNMP message from DTLS 1005 OUT incomingMessageLength -- the length of the SNMP message 1006 ) 1008 The abstract data elements passed as parameters in the abstract 1009 service primitives are as follows: 1011 statusInformation: An indication of whether the process was 1012 successful or not. If not, then the status information will 1013 include the error indication provided by DTLS. 1015 dtlsSessionID: An implementation-dependent session identifier to 1016 reference the specific DTLS session. How the DTLS session ID is 1017 obtained for each message is implementation-dependent. As an 1018 implementation hint, the DTLS Transport Model can examine incoming 1019 messages to determine the source IP address and port number and 1020 use these values to look up the local DTLS session ID in the list 1021 of active sessions. 1023 wholeDtlsMsg: The whole message as received on the wire. 1025 wholeDtlsMsgLength: The length of the message as it was received on 1026 the wire. 1028 incomingMessage: The whole SNMP message stripped of all DTLS privacy 1029 and integrity data. 1031 incomingMessageLength: The length of the SNMP message stripped of 1032 all DTLS privacy and integrity data. 1034 4.6.3. DTLS Services for an Outgoing Message 1036 When the DTLS Transport Model invokes the DTLS record layer to 1037 encapsulate and transmit a SNMP message, it must use the following 1038 ASI. 1040 statusInformation = -- errorIndication or success 1041 dtlsWrite( 1042 IN dtlsSessionID -- Session identifier for DTLS 1043 IN outgoingMessage -- the message to send 1044 IN outgoingMessageLength -- its length 1045 ) 1047 The abstract data elements passed as parameters in the abstract 1048 service primitives are as follows: 1050 statusInformation: An indication of whether the process was 1051 successful or not. If not, then the status information will 1052 include the error indication provided by DTLS. 1054 dtlsSessionID: An implementation-dependent session identifier to 1055 reference the specific DTLS session that the message should be 1056 sent using. 1058 outgoingMessage: The outgoing message to send to DTLS for 1059 encapsulation. 1061 outgoingMessageLength: The length of the outgoing message. 1063 5. Elements of Procedure 1065 Abstract service interfaces have been defined by RFC 3411 to describe 1066 the conceptual data flows between the various subsystems within an 1067 SNMP entity. The DTLSTM uses some of these conceptual data flows 1068 when communicating between subsystems. These RFC 3411-defined data 1069 flows are referred to here as public interfaces. 1071 To simplify the elements of procedure, the release of state 1072 information is not always explicitly specified. As a general rule, 1073 if state information is available when a message gets discarded, the 1074 message-state information should also be released. If state 1075 information is available when a session is closed, the session state 1076 information should also be released. Sensitive information, like 1077 cryptographic keys, should be overwritten with zero value or random 1078 value data prior to being released. 1080 An error indication may return an OID and value for an incremented 1081 counter if the information is available at the point where the error 1082 is detected. 1084 5.1. Receiving an Incoming Message 1086 The following section describes the procedures followed by the DTLS 1087 Transport Model when it receives a DTLS protected packet. A process 1088 for multiplexing sessions must be incorporated into the procedures 1089 for an incoming message. Steps one through four of this section 1090 describe how this is done. This procedure assumes that upon session 1091 establishment, a transport mapping table is created in the Transport 1092 Model LCD. The transport mapping table associates dtlsSessionID with 1093 the source and destination addresses and ports used for the session. 1094 It also assumes that the LCD entry is tied to the cache entry so the 1095 tmStateReference can be retrieved for the receiveMessage() ASI. 1097 1) The DTLS Transport Model examines the message, in an 1098 implementation-dependent manner, to determine the transport 1099 parameters for the received message. 1101 As an implementation hint, the source and destination addresses 1102 and ports of the message should uniquely assign the message to a 1103 specific session. However, another implementation-dependent 1104 method may be used if so desired. 1106 2) The DTLS Transport Model queries the LCD using the transport 1107 parameters to determine if a session already exists and its 1108 dtlsSessionID. 1110 3) If a matching entry in the LCD does not exist then the message is 1111 discarded. Increment the dtlstmSessionNoAvailableSessions 1112 counter and stop processing the message. 1114 Note that an entry would already exist if the client and server's 1115 session establishment procedures had been successfully completed 1116 (as described in Section 5.3) even if no message had been sent 1117 through the newly established session. An entry may not exist, 1118 however, because of a "rogue" message being routed to the SNMP 1119 entity by mistake but it could also be the result of a "broken" 1120 session (see operational considerations). 1122 4) If a matching entry is found, the dtlsSessionID is retrieved from 1123 the LCD. 1125 5) The dtlsWholeMsg and dtlsSessionID are passed to DTLS for 1126 decryption and integrity checking using the dtlsRead() ASI. 1128 6) If the message fails integrity checks or other DTLS security 1129 processing then the message is discarded by DTLS and an error 1130 indication may be returned by DTLS. 1132 7) If the message passes all integrity checks and DTLS security 1133 processing then the message is returned to the DTLS Transport 1134 Model as a wholeMessage. 1136 8) The DTLS Transport Model retrieves the tmStateReference for the 1137 message and passes the message to the dispatcher using the 1138 receiveMessage() ASI. 1140 5.2. Sending an Outgoing Message 1142 This section describes the procedure followed by the DTLS Transport 1143 Model whenever it sends an outgoing SNMP message to another SNMP 1144 engine. 1146 1) Determine if there is an active session for the tmStateReference 1147 and determine in an implementation-dependent way if this is the 1148 first message to be passed through the session. 1150 As an implementation hint, the DTLS Transport Model can examine 1151 its cache and the LCD to determine if there is a cache entry with 1152 an existing established session. If this is the first message 1153 then there should be a cache entry with tmSecurityData associated 1154 with the tmStateReference but there will be no LCD entry 1155 containing the dtlsSessionID yet. 1157 2a) If there is an active session then determine the dtlsSessionID 1158 and pass the outgoingMessage to the DTLS record layer for 1159 encapsulation and transmission. Processing for this message is 1160 complete. 1162 2b) If there is no active session and this is not the first message, 1163 discard the message, increment the 1164 dtlstmSessionNoAvailableSessions counter, and return an error 1165 indication to the calling module. Processing for this message 1166 is complete. 1168 2c) If there is no active session associated with the 1169 tmStateReference and this is the first message, open a session 1170 with the remote SNMP engine using the openSession() ASI 1171 (discussed further in Section 4.6.1). Implementations MAY wish 1172 to offer message buffering to prevent redundant openSession() 1173 calls for the same cache entry. 1175 3a) If an error is returned from OpenSession(), then discard the 1176 message, increment the dtlstmSessionOpenErrors, and return an 1177 error indication to the calling module. 1179 3b) If openSession() is successful, then pass the outgoingMessage to 1180 DTLS for encapsulation and transmission. 1182 5.3. Establishing a Session 1184 The openSession() ASI, as mentioned in Section 4.6.1, is used to 1185 establish a DTLS session. 1187 The following sections describe the procedures followed by a DTLS 1188 Transport Model when establishing a session as a Command Generator, a 1189 Notification Originator or as part of a Proxy Forwarder. 1191 The following describes the procedure to follow to establish a 1192 session between SNMP engines to exchange SNMP messages. This process 1193 is followed by any SNMP engine establishing a session for subsequent 1194 use. 1196 This MAY done automatically for SNMP messages which are not Response 1197 or Report messages. 1199 DTLS provides no explicit manner for transmitting an identity the 1200 client wishes to connect to during or prior to key exchange to 1201 facilitate certificate selection at the server (e.g. at a 1202 Notification Receiver). I.E., there is no available mechanism for 1203 sending notifications to a specific principal at a given UDP/port 1204 combination. Therefore, implementations MAY support responding with 1205 multiple identities using separate UDP port numbers to indicate the 1206 desired principal or some other implementation-dependent solution. 1208 1) The client selects the appropriate certificate and cipher_suites 1209 for the key agreement based on the tmSecurityName and the 1210 tmRequestedSecurityLevel for the session. For sessions being 1211 established as a result of a SNMP-TARGET-MIB based operation, the 1212 certificate will potentially have been identified via the 1213 dtlstmParamsTable mapping and the cipher_suites will have to be 1214 taken from system-wide or implementation-specific configuration. 1215 Otherwise, the certificate and appropriate cipher_suites will 1216 need to be passed to the openSession() ASI as supplemental 1217 information or configured through an implementation-dependent 1218 mechanism. It is also implementation-dependent and possibly 1219 policy-dependent how tmRequestedSecurityLevel will be used to 1220 influence the security capabilities provided by the DTLS session. 1221 However this is done, the security capabilities provided by DTLS 1222 MUST be at least as high as the level of security indicated by 1223 the tmRequestedSecurityLevel parameter. The actual security 1224 level of the session should be reported in the tmStateReference 1225 cache as tmSecurityLevel. For DTLS to provide strong 1226 authentication, each principal acting as a Command Generator 1227 SHOULD have its own certificate. 1229 2) Using the destTransportDomain and destTransportAddress values, 1230 the client will initiate the DTLS handshake protocol to establish 1231 session keys for message integrity and encryption. 1233 If the attempt to establish a session is unsuccessful, then 1234 dtlstmSessionOpenErrors is incremented, an error indication is 1235 returned, and session establishment processing stops. 1237 3) Once the secure session is established and both sides have been 1238 authenticated, the DTLS server side of the connection identifies 1239 the authenticated identity from the DTLS client's principal 1240 certificate using the dtlstmCertificateToSNTable mapping table 1241 and records this in the tmStateReference cache as tmSecurityName. 1243 4) The DTLS client side of the connection SHOULD verify that 1244 authenticated identity of the DTLS server's certificate is the 1245 expected identity and MUST do so if the application is a 1246 Notification Generator. If strong authentication is desired then 1247 DTLS server certificate MUST always be verified and checked 1248 against the expected identity. DTLS provides assurance that the 1249 authenticated identity has been signed by a trusted configured 1250 certificate authority. 1252 5) The DTLS-specific session identifier is passed to the DTLS 1253 Transport Model and associated with the tmStateReference cache 1254 entry to indicate that the session has been established 1255 successfully and to point to a specific DTLS session for future 1256 use. 1258 5.4. Closing a Session 1260 The DTLS Transport Model provides the following primitive to close a 1261 session: 1263 statusInformation = 1264 closeSession( 1265 IN tmStateReference -- transport info 1266 ) 1268 The following describes the procedure to follow to close a session 1269 between a client and server. This process is followed by any SNMP 1270 engine closing the corresponding SNMP session. 1272 1) Look up the session in the cache and the LCD using the 1273 tmStateReference. 1275 2) If there is no session open associated with the tmStateReference, 1276 then closeSession processing is completed. 1278 3) Delete the entry from the cache and any other implementation- 1279 dependent information in the LCD. 1281 4) Have DTLS close the specified session. This SHOULD include 1282 sending a close_notify TLS Alert to inform the other side that 1283 session cleanup may be performed. 1285 6. MIB Module Overview 1287 This MIB module provides management of the DTLS Transport Model. It 1288 defines needed textual conventions, statistical counters and 1289 configuration infrastructure necessary for session establishment. 1290 Example usage of the configuration tables can be found in Appendix A. 1292 6.1. Structure of the MIB Module 1294 Objects in this MIB module are arranged into subtrees. Each subtree 1295 is organized as a set of related objects. The overall structure and 1296 assignment of objects to their subtrees, and the intended purpose of 1297 each subtree, is shown below. 1299 6.2. Textual Conventions 1301 Generic and Common Textual Conventions used in this module can be 1302 found summarized at http://www.ops.ietf.org/mib-common-tcs.html 1304 This module defines two new Textual Conventions: a new 1305 TransportDomain and TransportAddress format for describing DTLS 1306 connection addressing requirements. 1308 6.3. Statistical Counters 1310 The DTLSTM-MIB defines some statical counters that can provide 1311 network managers with feedback about DTLS session usage and potential 1312 errors that a MIB-instrumented device may be experiencing. 1314 6.4. Configuration Tables 1316 The DTLSTM-MIB defines configuration tables that a manager can use 1317 for help in configuring a MIB-instrumented device for sending and 1318 receiving SNMP messages over DTLS. In particular, there is a MIB 1319 table that extends the SNMP-TARGET-MIB for configuring certificates 1320 to be used and a MIB table for mapping incoming DTLS client 1321 certificates to securityNames. 1323 6.5. Relationship to Other MIB Modules 1325 Some management objects defined in other MIB modules are applicable 1326 to an entity implementing the DTLS Transport Model. In particular, 1327 it is assumed that an entity implementing the DTLSTM-MIB will 1328 implement the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411], 1329 the SNMP-TARGET-MIB [RFC3413], the SNMP-NOTIFICATION-MIB [RFC3413] 1330 and the SNMP-VIEW-BASED-ACM-MIB [RFC3415]. 1332 This MIB module is for managing DTLS Transport Model information. 1334 6.5.1. MIB Modules Required for IMPORTS 1336 The following MIB module imports items from SNMPV2-SMI [RFC2578], 1337 SNMPV2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB 1338 [RFC3413] and SNMP-CONF [RFC2580]. 1340 7. MIB Module Definition 1341 DTLSTM-MIB DEFINITIONS ::= BEGIN 1343 IMPORTS 1344 MODULE-IDENTITY, OBJECT-TYPE, 1345 OBJECT-IDENTITY, snmpModules, snmpDomains, 1346 Counter32, Unsigned32 1347 FROM SNMPv2-SMI 1348 TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType 1349 FROM SNMPv2-TC 1350 MODULE-COMPLIANCE, OBJECT-GROUP 1351 FROM SNMPv2-CONF 1352 SnmpAdminString 1353 FROM SNMP-FRAMEWORK-MIB 1354 snmpTargetParamsEntry 1355 FROM SNMP-TARGET-MIB 1356 ; 1358 dtlstmMIB MODULE-IDENTITY 1359 LAST-UPDATED "200807070000Z" 1360 ORGANIZATION " " 1361 CONTACT-INFO "WG-EMail: 1362 Subscribe: 1364 Chairs: 1365 Co-editors: 1366 " 1368 DESCRIPTION "The DTLS Transport Model MIB 1370 Copyright (C) The IETF Trust (2007). This 1371 version of this MIB module is part of RFC XXXX; 1372 see the RFC itself for full legal notices. 1373 -- NOTE to RFC editor: replace XXXX with actual RFC number 1374 -- for this document and remove this note 1375 " 1377 REVISION "200807070000Z" 1378 DESCRIPTION "The initial version, published in RFC XXXX. 1379 -- NOTE to RFC editor: replace XXXX with actual RFC number 1380 -- for this document and remove this note 1381 " 1383 ::= { snmpModules xxxx } 1384 -- RFC Ed.: replace xxxx with IANA-assigned number and 1385 -- remove this note 1387 -- ************************************************ 1388 -- subtrees of the SNMP-DTLS-TM-MIB 1389 -- ************************************************ 1391 dtlstmNotifications OBJECT IDENTIFIER ::= { dtlstmMIB 0 } 1392 dtlstmObjects OBJECT IDENTIFIER ::= { dtlstmMIB 1 } 1393 dtlstmConformance OBJECT IDENTIFIER ::= { dtlstmMIB 2 } 1395 -- ************************************************ 1396 -- Objects 1397 -- ************************************************ 1399 snmpDTLSDomain OBJECT-IDENTITY 1400 STATUS current 1401 DESCRIPTION 1402 "The SNMP over DTLS transport domain. The corresponding 1403 transport address is of type SnmpDTLSAddress. 1405 When an SNMP entity uses the snmpDTLSDomain transport 1406 model, it must be capable of accepting messages up to 1407 the maximum MTU size for an interface it supports, minus the 1408 needed IP, UDP, DTLS and other protocol overheads." 1409 ::= { snmpDomains yy } 1411 -- RFC Ed.: replace yy with IANA-assigned number and 1412 -- remove this note 1414 SnmpDTLSAddress ::= TEXTUAL-CONVENTION 1415 DISPLAY-HINT "1a" 1416 STATUS current 1417 DESCRIPTION 1418 "Represents a UDP connection address for an IPv4 address, 1419 an IPv6 address or an ASCII encoded host name and port 1420 number. 1422 The hostname must be encoded in ASCII, as specified in 1423 RFC3490 (Internationalizing Domain Names in Applications) 1424 followed by a colon ':' (ASCII character 0x3A) and a 1425 decimal port number in ASCII. The name SHOULD be fully 1426 qualified whenever possible. 1428 An IPv4 address must be a dotted decimal format followed by 1429 a colon ':' (ASCII character 0x3A) and a decimal port 1430 number in ASCII. 1432 An IPv6 address must be a colon separated format, 1433 surrounded by square brackets (ASCII characters 0x5B and 1434 0x5D), followed by a colon ':' (ASCII character 0x3A) and a 1435 decimal port number in ASCII. 1437 Values of this textual convention may not be directly 1438 usable as transport-layer addressing information, and may 1439 require run-time resolution. As such, applications that 1440 write them must be prepared for handling errors if such 1441 values are not supported, or cannot be resolved (if 1442 resolution occurs at the time of the management operation). 1444 The DESCRIPTION clause of TransportAddress objects that may 1445 have snmpDTLSAddress values must fully describe how (and 1446 when) such names are to be resolved to IP addresses and 1447 vice versa. 1449 This textual convention SHOULD NOT be used directly in 1450 object definitions since it restricts addresses to a 1451 specific format. However, if it is used, it MAY be used 1452 either on its own or in conjunction with 1453 TransportAddressType or TransportDomain as a pair. 1455 When this textual convention is used as a syntax of an 1456 index object, there may be issues with the limit of 128 1457 sub-identifiers specified in SMIv2, STD 58. It is 1458 RECOMMENDED that all MIB documents using this textual 1459 convention make explicit any limitations on index component 1460 lengths that management software must observe. This may be 1461 done either by including SIZE constraints on the index 1462 components or by specifying applicable constraints in the 1463 conceptual row DESCRIPTION clause or in the surrounding 1464 documentation." 1465 SYNTAX OCTET STRING (SIZE (1..255)) 1467 -- The dtlstmSession Group 1469 dtlstmSession OBJECT IDENTIFIER ::= { dtlstmObjects 1 } 1471 dtlstmSessionOpens OBJECT-TYPE 1472 SYNTAX Counter32 1473 MAX-ACCESS read-only 1474 STATUS current 1475 DESCRIPTION "The number of times an openSession() request has been 1476 executed, whether it succeeded or failed." 1477 ::= { dtlstmSession 1 } 1479 dtlstmSessionCloses OBJECT-TYPE 1480 SYNTAX Counter32 1481 MAX-ACCESS read-only 1482 STATUS current 1483 DESCRIPTION "The number of times a closeSession() request has been 1484 executed, whether it succeeded or failed." 1485 ::= { dtlstmSession 2 } 1487 dtlstmSessionOpenErrors OBJECT-TYPE 1488 SYNTAX Counter32 1489 MAX-ACCESS read-only 1490 STATUS current 1491 DESCRIPTION "The number of times an openSession() request 1492 failed to open a Session, for any reason." 1493 ::= { dtlstmSession 3 } 1495 dtlstmSessionNoAvailableSessions OBJECT-TYPE 1496 SYNTAX Counter32 1497 MAX-ACCESS read-only 1498 STATUS current 1499 DESCRIPTION "The number of times an outgoing message was dropped 1500 because the session associated with the passed 1501 tmStateReference was no longer (or was never) 1502 available." 1503 ::= { dtlstmSession 4 } 1505 -- Configuration Objects 1507 dtlstmConfig OBJECT IDENTIFIER ::= { dtlstmObjects 2 } 1509 -- Certificate mapping 1511 dtlstmCertificateMapping OBJECT IDENTIFIER ::= { dtlstmConfig 1 } 1513 dtlstmCertificateToSNCount OBJECT-TYPE 1514 SYNTAX Unsigned32 1515 MAX-ACCESS read-only 1516 STATUS current 1517 DESCRIPTION 1518 "A count of the number of entries in the 1519 dtlstmCertificateToSNTable" 1520 ::= { dtlstmCertificateMapping 1 } 1522 dtlstmCertificateToSNTableLastChanged OBJECT-TYPE 1523 SYNTAX TimeStamp 1524 MAX-ACCESS read-only 1525 STATUS current 1526 DESCRIPTION 1527 "The value of sysUpTime.0 when the dtlstmCertificateToSNTable 1528 was last modified through any means, or 0 if it has not been 1529 modified since the command responder was started." 1530 ::= { dtlstmCertificateMapping 2 } 1532 dtlstmCertificateToSNTable OBJECT-TYPE 1533 SYNTAX SEQUENCE OF DtlstmCertificateToSNEntry 1534 MAX-ACCESS not-accessible 1535 STATUS current 1536 DESCRIPTION 1537 "A table listing the X.509 certificates known to the entity 1538 and the associated method for determining the SNMPv3 security 1539 name from a certificate. 1541 On an incoming DTLS/SNMP connection the client's presented 1542 certificate should be examined and validated based on 1543 an established trusted CA certificate or self-signed public 1544 certificate. This table does not provide 1545 a mechanism for uploading the certificates as that is expected 1546 to occur through an out-of-band transfer. 1548 Once the authenticity of the certificate has been verified, 1549 this table can be consulted to determine the appropriate 1550 securityName to identify the remote connection. This is done 1551 by comparing the issuer's distinguished name against the 1552 dtlstmCertDN value. If a matching entry is found then the 1553 securityName is selected based on the dtlstmCertMapType, 1554 dtlstmCertSubject and dtlstmCertSecurityName fields and the 1555 resulting securityName is used to identify the other side of 1556 the DTLS connection. 1558 Users are encouraged to make use of certificates with 1559 CommonName fields that can be used as securityNames so that a 1560 single root CA certificate can allow all child certificate's 1561 CommonName to map directly to a securityName via a 1:1 1562 transformation. However, this table is flexible enough to 1563 allow for situations where existing an existing deployed 1564 certificate infrastructures dose not provide adequate 1565 CommonName values for use as SNMPv3 securityNames." 1566 ::= { dtlstmCertificateMapping 3 } 1568 dtlstmCertificateToSNEntry OBJECT-TYPE 1569 SYNTAX DtlstmCertificateToSNEntry 1570 MAX-ACCESS not-accessible 1571 STATUS current 1572 DESCRIPTION 1573 "A row in the dtlstmCertificateToSNTable that specifies a 1574 mapping for an incoming DTLS certificate to a securityName to 1575 use for the connection." 1576 INDEX { dtlstmCertID } 1577 ::= { dtlstmCertificateToSNTable 1 } 1579 DtlstmCertificateToSNEntry ::= SEQUENCE { 1580 dtlstmCertID Unsigned32, 1581 dtlstmCertIssuerDN OCTET STRING, 1582 dtlstmCertMapType INTEGER, 1583 dtlstmCertSecurityName SnmpAdminString, 1584 dtlstmCertStorageType StorageType, 1585 dtlstmCertRowStatus RowStatus 1586 } 1588 dtlstmCertID OBJECT-TYPE 1589 SYNTAX Unsigned32 1590 MAX-ACCESS not-accessible 1591 STATUS current 1592 DESCRIPTION 1593 "A unique arbitrary number index for a given certificate 1594 entry." 1595 ::= { dtlstmCertificateToSNEntry 1 } 1597 dtlstmCertIssuerDN OBJECT-TYPE 1598 SYNTAX OCTET STRING 1599 MAX-ACCESS read-create 1600 STATUS current 1601 DESCRIPTION 1602 "The issuer's 'distinguished name' field matching the 1603 certificate to be used for this mapping entry. 1604 " 1605 -- XXX: allow specification via serial no too? 1606 ::= { dtlstmCertificateToSNEntry 2 } 1608 dtlstmCertMapType OBJECT-TYPE 1609 SYNTAX INTEGER { specified(1), byCN(2) } 1610 MAX-ACCESS read-create 1611 STATUS current 1612 DESCRIPTION 1613 "The mapping type used to obtain the securityName from the 1614 certificate. The possible values of use and their usage 1615 methods are defined as follows: 1617 specified(1): The securityName that should be used locally to 1618 identify the remote entity is directly specified 1619 in the dtlstmCertSecurityName column from this 1620 table. 1622 byCN(2): The securityName that should be used locally to 1623 identify the remote entity should be taken from 1624 the CommonName portion of the Subject field from 1625 the X.509 certificate." 1626 DEFVAL { specified } 1627 ::= { dtlstmCertificateToSNEntry 3 } 1629 dtlstmCertSecurityName OBJECT-TYPE 1630 SYNTAX SnmpAdminString (SIZE(0..32)) 1631 MAX-ACCESS read-create 1632 STATUS current 1633 DESCRIPTION 1634 "The securityName that the session should use if the 1635 dtlstmCertMapType is set to specified(1), otherwise the value 1636 in this column should be ignored. If dtlstmCertMapType is set 1637 to specifed(1) and this column contains a zero-length string 1638 (which is not a legal securityName value) this row is 1639 effectively disabled and the match will not be considered 1640 successful." 1641 DEFVAL { "" } 1642 ::= { dtlstmCertificateToSNEntry 4 } 1644 dtlstmCertStorageType OBJECT-TYPE 1645 SYNTAX StorageType 1646 MAX-ACCESS read-create 1647 STATUS current 1648 DESCRIPTION 1649 "The storage type for this conceptual row. Conceptual rows 1650 having the value 'permanent' need not allow write-access to 1651 any columnar objects in the row." 1652 DEFVAL { nonVolatile } 1653 ::= { dtlstmCertificateToSNEntry 5 } 1655 dtlstmCertRowStatus OBJECT-TYPE 1656 SYNTAX RowStatus 1657 MAX-ACCESS read-create 1658 STATUS current 1659 DESCRIPTION 1660 "The status of this conceptual row. This object may be used 1661 to create or remove rows from this table. 1663 The value of this object has no effect on whether 1664 other objects in this conceptual row can be modified." 1665 ::= { dtlstmCertificateToSNEntry 6 } 1667 -- Maps securityNames to certificates for use by the SNMP-TARGET-MIB 1669 dtlstmParamsCount OBJECT-TYPE 1670 SYNTAX Unsigned32 1671 MAX-ACCESS read-only 1672 STATUS current 1673 DESCRIPTION 1674 "A count of the number of entries in the 1675 dtlstmParamsTable" 1677 ::= { dtlstmCertificateMapping 4 } 1679 dtlstmParamsTableLastChanged OBJECT-TYPE 1680 SYNTAX TimeStamp 1681 MAX-ACCESS read-only 1682 STATUS current 1683 DESCRIPTION 1684 "The value of sysUpTime.0 when the dtlstmParamsTable 1685 was last modified through any means, or 0 if it has not been 1686 modified since the command responder was started." 1687 ::= { dtlstmCertificateMapping 5 } 1689 dtlstmParamsTable OBJECT-TYPE 1690 SYNTAX SEQUENCE OF DtlstmParamsEntry 1691 MAX-ACCESS not-accessible 1692 STATUS current 1693 DESCRIPTION 1694 "This table augments the SNMP-TARGET-MIB's 1695 snmpTargetParamsTable with additional a DTLS client-side 1696 certificate certificate identifier to use when establishing 1697 new DTLS connections." 1698 ::= { dtlstmCertificateMapping 6 } 1700 dtlstmParamsEntry OBJECT-TYPE 1701 SYNTAX DtlstmParamsEntry 1702 MAX-ACCESS not-accessible 1703 STATUS current 1704 DESCRIPTION 1705 "A conceptual row containing the certificate subject name for 1706 a given snmpTargetParamsEntry. The values in this row should 1707 be ignored if not the connection that needs to be established, 1708 as indicated by the SNMP-TARGET-MIB infrastructure, is not a 1709 DTLS based connection." 1710 AUGMENTS { snmpTargetParamsEntry } 1711 ::= { dtlstmParamsTable 1 } 1713 DtlstmParamsEntry ::= SEQUENCE { 1714 dtlstmParamsSubject OCTET STRING, 1715 dtlstmParamsStorageType StorageType, 1716 dtlstmParamsRowStatus RowStatus 1717 } 1719 dtlstmParamsSubject OBJECT-TYPE 1720 SYNTAX OCTET STRING (SIZE(1..4096)) 1721 MAX-ACCESS read-create 1722 STATUS current 1723 DESCRIPTION 1724 "The subject name of the locally-held X.509 certificate that 1725 should be used when initiating a DTLS connection as a DTLS 1726 client." 1727 ::= { dtlstmParamsEntry 1 } 1729 dtlstmParamsStorageType OBJECT-TYPE 1730 SYNTAX StorageType 1731 MAX-ACCESS read-create 1732 STATUS current 1733 DESCRIPTION 1734 "The storage type for this conceptual row. Conceptual rows 1735 having the value 'permanent' need not allow write-access to 1736 any columnar objects in the row." 1737 DEFVAL { nonVolatile } 1738 ::= { dtlstmParamsEntry 2 } 1740 dtlstmParamsRowStatus OBJECT-TYPE 1741 SYNTAX RowStatus 1742 MAX-ACCESS read-create 1743 STATUS current 1744 DESCRIPTION 1745 "The status of this conceptual row. This object may be used 1746 to create or remove rows from this table. 1748 The value of this object has no effect on whether 1749 other objects in this conceptual row can be modified." 1750 ::= { dtlstmParamsEntry 3 } 1752 -- ************************************************ 1753 -- dtlstmMIB - Conformance Information 1754 -- ************************************************ 1756 dtlstmCompliances OBJECT IDENTIFIER ::= { dtlstmConformance 1 } 1758 dtlstmGroups OBJECT IDENTIFIER ::= { dtlstmConformance 2 } 1760 -- ************************************************ 1761 -- Compliance statements 1762 -- ************************************************ 1764 dtlstmCompliance MODULE-COMPLIANCE 1765 STATUS current 1766 DESCRIPTION 1767 "The compliance statement for SNMP engines that support the 1768 SNMP-DTLS-TM-MIB" 1769 MODULE 1770 MANDATORY-GROUPS { dtlstmStatsGroup, 1771 dtlstmIncomingGroup, dtlstmOutgoingGroup } 1772 ::= { dtlstmCompliances 1 } 1774 -- ************************************************ 1775 -- Units of conformance 1776 -- ************************************************ 1777 dtlstmStatsGroup OBJECT-GROUP 1778 OBJECTS { 1779 dtlstmSessionOpens, 1780 dtlstmSessionCloses, 1781 dtlstmSessionOpenErrors, 1782 dtlstmSessionNoAvailableSessions 1783 } 1784 STATUS current 1785 DESCRIPTION "A collection of objects for maintaining 1786 statistical information of an SNMP engine which 1787 implements the SNMP DTLS Transport Model." 1788 ::= { dtlstmGroups 1 } 1790 dtlstmIncomingGroup OBJECT-GROUP 1791 OBJECTS { 1792 dtlstmCertificateToSNCount, 1793 dtlstmCertificateToSNTableLastChanged, 1794 dtlstmCertIssuerDN, 1795 dtlstmCertMapType, 1796 dtlstmCertSecurityName, 1797 dtlstmCertStorageType, 1798 dtlstmCertRowStatus 1799 } 1800 STATUS current 1801 DESCRIPTION "A collection of objects for maintaining 1802 incoming connection certificate mappings to 1803 securityNames of an SNMP engine which implements the 1804 SNMP DTLS Transport Model." 1805 ::= { dtlstmGroups 2 } 1807 dtlstmOutgoingGroup OBJECT-GROUP 1808 OBJECTS { 1809 dtlstmParamsCount, 1810 dtlstmParamsTableLastChanged, 1811 dtlstmParamsSubject, 1812 dtlstmParamsStorageType, 1813 dtlstmParamsRowStatus 1814 } 1815 STATUS current 1816 DESCRIPTION "A collection of objects for maintaining 1817 outgoing connection certificates to use when opening 1818 connections as a result of SNMP-TARGET-MIB settings." 1819 ::= { dtlstmGroups 3 } 1821 END 1823 8. Operational Considerations 1825 A session is discussed throughout this document as meaning a security 1826 association between the DTLS client and the DTLS server. State 1827 information for the sessions are maintained in each DTLSTM and this 1828 information is created and destroyed as sessions are opened and 1829 closed. Because of the connectionless nature of UDP, a "broken" 1830 session, one side up one side down, could result if one side of a 1831 session is brought down abruptly (i.e., reboot, power outage, etc.). 1832 Whenever possible, implementations SHOULD provide graceful session 1833 termination through the use of disconnect messages. Implementations 1834 SHOULD also have a system in place for dealing with "broken" 1835 sessions. 1837 To simplify session management it is RECOMMENDED that implementations 1838 utilize two separate ports, one for Notification sessions and one for 1839 Command sessions. If this implementation recommendation is followed, 1840 DTLS clients will always send REQUEST messages and DTLS servers will 1841 always send RESPONSE messages. With this assertion, implementations 1842 may be able to simplify "broken" session handling, session 1843 resumption, and other aspects of session management such as 1844 guaranteeing that Request- Response pairs use the same session. 1846 Depending on the algorithms used for generation of the master session 1847 secret, the privacy and integrity algorithms used to protect 1848 messages, the environment of the session, the amount of data 1849 transferred, and the sensitivity of the data, a time-to-live (TTL) 1850 value SHOULD be established for sessions. An upper limit of 24 hours 1851 is suggested for this TTL value. The TTL value could be stored in 1852 the LCD and checked before passing a message to the DTLS session. 1854 When an SNMP engine needs to establish an outgoing session for 1855 notifications, the snmpTargetParamsTable includes an entry for the 1856 snmpTargetParamsSecurityName of the target. However, the receiving 1857 SNMP engine (Server) does not know which DTLS certificate to offer to 1858 the Client so that the tmSecurityName identity-authentication will be 1859 successful. The best solution would be to maintain a one-to-one 1860 mapping between certificates and incoming ports for notification 1861 receivers, although other implementation dependent mechanisms may be 1862 used instead. This can be handled at the Notification Originator by 1863 configuring the snmpTargetAddrTable (snmpTargetAddrTDomain and 1864 snmpTargetAddrTAddress) and then requiring the receiving SNMP engine 1865 to monitor multiple incoming static ports based on which principals 1866 are capable of receiving notifications. Implementations MAY also 1867 choose to designate a single Notification Receiver Principal to 1868 receive all incoming TRAPS and INFORMS. 1870 9. Security Considerations 1872 This document describes a transport model that permits SNMP to 1873 utilize DTLS security services. The security threats and how the 1874 DTLS transport model mitigates these threats are covered in detail 1875 throughout this document. Security considerations for DTLS are 1876 covered in [RFC4347] and security considerations for TLS are 1877 described in Appendices D, E, and F of TLS 1.1 [RFC4346]. DTLS adds 1878 to the security considerations of TLS only because it is more 1879 vulnerable to denial of service attacks. A random cookie exchange 1880 was added to the handshake to prevent anonymous denial of service 1881 attacks. RFC 4347 recommends that the cookie exchange is utilized 1882 for all handshakes and therefore it is RECOMMENDED that implementers 1883 also support this cookie exchange. 1885 9.1. Certificates, Authentication, and Authorization 1887 Implementations are responsible for providing a security certificate 1888 configuration installation . Implementations SHOULD support 1889 certificate revocation lists and expiration of certificates or other 1890 access control mechanisms. 1892 DTLS provides for both authentication of the identity of the DTLS 1893 server and authentication of the identity of the DTLS client. Access 1894 to MIB objects for the authenticated principal MUST be enforced by an 1895 access control subsystem (e.g. the VACM). 1897 Authentication of the Command Generator principal's identity is 1898 important for use with the SNMP access control subsystem to ensure 1899 that only authorized principals have access to potentially sensitive 1900 data. The authenticated identity of the Command Generator 1901 principal's certificate is mapped to an SNMP model-independent 1902 securityName for use with SNMP access control, as discussed in 1903 Section 4.3.4, Section 7 and other sections. 1905 Furthermore, the DTLS handshake only provides assurance that the 1906 certificate of the authenticated identity has been signed by an 1907 configured accepted Certificate Authority. DTLS has no way to 1908 further authorize or reject access based on the authenticated 1909 identity. An Access Control Model (such as the VACM) provides access 1910 control and authorization of a Command Generator's requests to a 1911 Command Responder and a Notification Responder's authorization to 1912 receive Notifications from a Notification Originator. However to 1913 avoid man-in-the-middle attacks both ends of the DTLS based 1914 connection MUST check the certificate presented by the other side 1915 against what was expected. For example, Command Generators must 1916 check that the Command Responder presented and authenticated itself 1917 with a X.509 certificate that was expected. Not doing so would allow 1918 an impostor, at a minimum, to present false data, receive sensitive 1919 information and/or provide a false-positive belief that configuration 1920 was actually received and acted upon. Authenticating and verifying 1921 the identity of the DTLS server and the DTLS client for all 1922 operations ensures the authenticity of the SNMP engine that provides 1923 MIB data. 1925 9.2. Use with SNMPv1/SNMPv2c Messages 1927 The SNMPv1 and SNMPv2c message processing described in RFC3484 (BCP 1928 74) [RFC3584] always selects the SNMPv1(1) Security Model for an 1929 SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c 1930 message. When running SNMPv1/SNMPv2c over a secure transport like 1931 the DTLS Transport Model, the securityName and securityLevel used for 1932 access control decisions are then derived from the community string, 1933 not the authenticated identity and securityLevel provided by the DTLS 1934 Transport Model. 1936 9.3. MIB Module Security 1938 The MIB objects in this document should be protected with an adequate 1939 level of at least integrity protection, especially those objects 1940 which are writable. Since knowledge of authorization and certificate 1941 usage mechanisms may be considered sensitive, protection from 1942 disclosure of the SNMP traffic via encryption is also recommended. 1944 SNMP versions prior to SNMPv3 did not include adequate security. 1945 Even if the network itself is secure (for example by using IPSec or 1946 DTLS) there is no control as to who on the secure network is allowed 1947 to access and GET/SET (read/change/create/delete) the objects in this 1948 MIB module. 1950 It is RECOMMENDED that implementers consider the security features as 1951 provided by the SNMPv3 framework (see section 8 of [RFC3410]), 1952 including full support for the USM (see [RFC3414]) and the DTLS 1953 Transport Model cryptographic mechanisms (for authentication and 1954 privacy). 1956 10. IANA Considerations 1958 IANA is requested to assign: 1960 1. a UDP port number in the range 1..1023 in the 1961 http://www.iana.org/assignments/port-numbers registry which will 1962 be the default port for SNMP over a DTLS Transport Model as 1963 defined in this document, 1965 2. a UDP port number in the range 1..1023 in the 1966 http://www.iana.org/assignments/port-numbers registry which will 1967 be the default port for SNMPTRAP over a DTLS Transport Model as 1968 defined in this document, 1970 3. an SMI number under snmpDomains for the snmpDTLSDomain object 1971 identifier, 1973 4. a SMI number under snmpModules, for the MIB module in this 1974 document, 1976 11. Acknowledgements 1978 This document closely follows and copies the Secure Shell Transport 1979 Model for SNMP defined by David Harrington and Joseph Salowey in 1980 [I-D.ietf-isms-secshell]. 1982 Large portions of this document are based on work that will be 1983 acknowledge in a future version of the document once a proper 1984 attribution list has been obtained. 1986 12. References 1988 12.1. Normative References 1990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1991 Requirement Levels", BCP 14, RFC 2119, March 1997. 1993 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1994 Protocol", RFC 2522, March 1999. 1996 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1997 Schoenwaelder, Ed., "Structure of Management Information 1998 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2000 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2001 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 2002 STD 58, RFC 2579, April 1999. 2004 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2005 "Conformance Statements for SMIv2", STD 58, RFC 2580, 2006 April 1999. 2008 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 2009 "Introduction and Applicability Statements for Internet- 2010 Standard Management Framework", RFC 3410, December 2002. 2012 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2013 Architecture for Describing Simple Network Management 2014 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2015 December 2002. 2017 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 2018 Management Protocol (SNMP) Applications", STD 62, 2019 RFC 3413, December 2002. 2021 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 2022 (USM) for version 3 of the Simple Network Management 2023 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 2025 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 2026 Access Control Model (VACM) for the Simple Network 2027 Management Protocol (SNMP)", STD 62, RFC 3415, 2028 December 2002. 2030 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 2031 Simple Network Management Protocol (SNMP)", STD 62, 2032 RFC 3418, December 2002. 2034 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 2035 "Coexistence between Version 1, Version 2, and Version 3 2036 of the Internet-standard Network Management Framework", 2037 BCP 74, RFC 3584, August 2003. 2039 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2040 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2042 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2043 Security", RFC 4347, April 2006. 2045 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2046 Housley, R., and W. Polk, "Internet X.509 Public Key 2047 Infrastructure Certificate and Certificate Revocation List 2048 (CRL) Profile", RFC 5280, May 2008. 2050 [I-D.ietf-isms-tmsm] 2051 Harington, D. and J. Schoenwaelder, "Transport Subsystem 2052 for the Simple Network Management Protocol (SNMP)". 2054 [X509] Rivest, R., Shamir, A., and L. M. Adleman, "A Method for 2055 Obtaining Digital Signatures and Public-Key 2056 Cryptosystems". 2058 [AES] National Institute of Standards, "Specification for the 2059 Advanced Encryption Standard (AES)". 2061 [DES] National Institute of Standards, "American National 2062 Standard for Information Systems-Data Link Encryption". 2064 [DSS] National Institute of Standards, "Digital Signature 2065 Standard". 2067 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 2068 Obtaining Digital Signatures and Public-Key 2069 Cryptosystems". 2071 12.2. Informative References 2073 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2074 December 2005. 2076 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2077 RFC 4303, December 2005. 2079 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2080 RFC 4306, December 2005. 2082 [I-D.ietf-isms-secshell] 2083 Harington, D. and J. Salowey, "Secure Shell Transport 2084 Model for SNMP". 2086 Appendix A. Target and Notificaton Configuration Example 2088 Configuring the SNMP-TARGET-MIB and NOTIFICATION-MIB along with 2089 access control settings for the SNMP-VIEW-BASED-ACM-MIB can be a 2090 daunting task without an example to follow. The following section 2091 describes an example of what pieces must be in place to accomplish 2092 this configuration. 2094 The isAccessAllowed() ASI requires configuration to exist in the 2095 following SNMP-VIEW-BASED-ACM-MIB tables: 2097 vacmSecurityToGroupTable 2098 vacmAccessTable 2099 vacmViewTreeFamilyTable 2101 The only table that needs to be discussed as particularly different 2102 here is the vacmSecurityToGroupTable. This table is indexed by both 2103 the SNMPv3 security model and the security name. The security model, 2104 when DTLSTM is in use, should be XXX corresponding to the TMSM 2105 [I-D.ietf-isms-tmsm]. An example vacmSecurityToGroupTable row might 2106 be filled out as follows (using a single SNMP SET request): 2108 vacmSecurityModel = XXX:TMSM 2109 vacmSecurityName = "blueberry" 2110 vacmGroupaName = "administrators" 2111 vacmSecurityToGroupStorageType = 3 (nonVolatile) 2112 vacmSecurityToGroupStatus = 4 (createAndGo) 2114 This example will assume that the "administrators" group has been 2115 given proper permissions via rows in the vacmAccessTable and 2116 vacmViewTreeFamilyTable. 2118 Depending on whether this VACM configuration is for a Command 2119 Responder or a Command Generator the security name "blueberry" will 2120 come from a few different locations. 2122 For Notification Generator's performing authorization checks, the 2123 server's certificate must be verified against the expected 2124 certificate before proceeding to send the notification. The 2125 securityName be set by the SNMP-TARGET-MIB's 2126 snmpTargetParamsSecurityName column or other configuration mechanism 2127 and the certificate to use would be taken from the appropriate entry 2128 in the dtlstmParamsTable. The dtlstmParamsTable augments the SNMP- 2129 TARGET-MIB's snmpTargetParamsTable with client-side certificate 2130 information. 2132 For Command Responder applications, the vacmSecurityName "blueberry" 2133 value is a value that needs to come from an incoming DTLS session. 2134 The mapping from a recevied DTLS client certificate to a securityName 2135 is done with the dtlstmCertificateToSNTable. The certificates must 2136 be loaded into the device so that a dtlstmCertificateToSNEntry may 2137 refer to it. As an example, consider the following entry which will 2138 provide a mapping from a X.509 Issuer's Distinguished Name directly 2139 to the "blueberry" securityName: 2141 dtlstmCertID = 1 (arbitrarily chosen) 2142 dtlstmCertIssuerDN = "C=US, ST=California, ..., CN=hardaker" 2143 dtlstmCertMapType = specified(1) 2144 dtlstmCertSecurityName = "blueberry" 2145 dtlstmCertStorageType = 3 (nonVolatile) 2146 dtlstmCertRowStatus = 4 (createAndGo) 2148 The above is an example of how to map a particular certificate to a 2149 particular securityName. It is recommended that users make use of 2150 direct CommonName mappings where possible since it will provide a 2151 more scalable approach to certificate management. If the following 2152 entry was created: 2154 dtlstmCertID = 1 (arbitrarily chosen) 2155 dtlstmCertIssuerDN = "C=US, ST=California, L=Davis, O=SuprIDs, ..." 2156 dtlstmCertMapType = byCN(2) 2157 dtlstmCertStorageType = 3 (nonVolatile) 2158 dtlstmCertRowStatus = 4 (createAndGo) 2160 The above entry indicates the CommonName field for that particular 2161 Issuer will be trusted to always produce common names that are 2162 directly 1 to 1 mappable into SNMPv3 securityNames. This type of 2163 configuration should only be used when the CA is carefully 2164 controlled. 2166 For the example, if the incoming DTLS client provided certificate 2167 contained a Subject with a CommonName of "blueberry" and the 2168 certificate was signed by the CA matching the dtlstmCertIssuerDN 2169 value above and the CA's certificate was properly installed on the 2170 device then the CommonName of "blueberry" would be used as the 2171 securityName for the session. 2173 Author's Address 2175 Wes Hardaker 2176 Sparta, Inc. 2177 P.O. Box 382 2178 Davis, CA 95617 2179 US 2181 Phone: +1 530 792 1913 2182 Email: ietf@hardakers.net 2184 Full Copyright Statement 2186 Copyright (C) The IETF Trust (2008). 2188 This document is subject to the rights, licenses and restrictions 2189 contained in BCP 78, and except as set forth therein, the authors 2190 retain all their rights. 2192 This document and the information contained herein are provided on an 2193 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2194 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2195 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2196 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2197 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2198 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2200 Intellectual Property 2202 The IETF takes no position regarding the validity or scope of any 2203 Intellectual Property Rights or other rights that might be claimed to 2204 pertain to the implementation or use of the technology described in 2205 this document or the extent to which any license under such rights 2206 might or might not be available; nor does it represent that it has 2207 made any independent effort to identify any such rights. Information 2208 on the procedures with respect to rights in RFC documents can be 2209 found in BCP 78 and BCP 79. 2211 Copies of IPR disclosures made to the IETF Secretariat and any 2212 assurances of licenses to be made available, or the result of an 2213 attempt made to obtain a general license or permission for the use of 2214 such proprietary rights by implementers or users of this 2215 specification can be obtained from the IETF on-line IPR repository at 2216 http://www.ietf.org/ipr. 2218 The IETF invites any interested party to bring to its attention any 2219 copyrights, patents or patent applications, or other proprietary 2220 rights that may cover technology that may be required to implement 2221 this standard. Please address the information to the IETF at 2222 ietf-ipr@ietf.org.