idnits 2.17.00 (12 Aug 2021) /tmp/idnits46845/draft-hardaker-isms-dtls-tm-01.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 2580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2604. ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. 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: ---------------------------------------------------------------------------- == Line 400 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 (November 3, 2008) is 4946 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) == Outdated reference: draft-ietf-isms-transport-security-model has been published as RFC 5591 == Outdated reference: draft-ietf-isms-tmsm has been published as RFC 5590 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: draft-ietf-isms-secshell has been published as RFC 5592 Summary: 4 errors (**), 0 flaws (~~), 4 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 November 3, 2008 5 Expires: May 7, 2009 7 Datagram Transport Layer Security Transport Model for SNMP 8 draft-hardaker-isms-dtls-tm-01.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 May 7, 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. Message Protection . . . . . . . . . . . . . . . . . . 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. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 17 75 4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 18 76 4.3.2. SNMP Services for an Incoming Message . . . . . . . . 18 77 4.4. DTLS Services . . . . . . . . . . . . . . . . . . . . . . 19 78 4.4.1. Services for Establishing a Session . . . . . . . . . 19 79 4.4.2. DTLS Services for an Incoming Message . . . . . . . . 21 80 4.4.3. DTLS Services for an Outgoing Message . . . . . . . . 22 81 4.5. Cached Information and References . . . . . . . . . . . . 22 82 4.5.1. securityStateReference . . . . . . . . . . . . . . . . 23 83 4.5.2. tmStateReference . . . . . . . . . . . . . . . . . . . 23 84 4.5.2.1. Transport information . . . . . . . . . . . . . . 24 85 4.5.2.2. securityName . . . . . . . . . . . . . . . . . . . 24 86 4.5.2.3. securityLevel . . . . . . . . . . . . . . . . . . 25 87 4.5.2.4. Session Information . . . . . . . . . . . . . . . 25 88 4.5.3. DTLS Transport Model Cached Information . . . . . . . 26 89 4.5.3.1. Transport Information . . . . . . . . . . . . . . 26 90 4.5.3.2. tmRequestedSecurityLevel . . . . . . . . . . . . . 26 91 4.5.3.3. tmSecurityLevel . . . . . . . . . . . . . . . . . 27 92 4.5.3.4. tmSecurityName . . . . . . . . . . . . . . . . . . 27 93 4.5.4. Transport Model LCD . . . . . . . . . . . . . . . . . 27 94 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 27 95 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 28 96 5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 28 97 5.1.2. Transport Processing for Incoming Messages . . . . . . 29 98 5.2. Procedures for an Outgoing Message . . . . . . . . . . . . 30 99 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 32 100 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 34 101 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 34 102 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 35 103 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 35 104 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 35 105 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 35 106 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 35 107 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 35 108 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 36 109 8. Operational Considerations . . . . . . . . . . . . . . . . . . 47 110 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 47 111 8.2. Notification Receiver Credential Selection . . . . . . . . 48 112 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 48 113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 114 9.1. Certificates, Authentication, and Authorization . . . . . 49 115 9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 49 116 9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 50 117 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 118 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 119 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 120 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 121 12.2. Informative References . . . . . . . . . . . . . . . . . . 53 122 Appendix A. Target and Notificaton Configuration Example . . . . 53 123 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55 124 Intellectual Property and Copyright Statements . . . . . . . . . . 56 126 1. Introduction 128 It is important to understand the SNMPv3 architecture [RFC3411], as 129 enhanced by the Transport Subsystem [I-D.ietf-isms-tmsm]. It is also 130 important to understand the terminology of the SNMPv3 architecture in 131 order to understand where the Transport Model described in this 132 document fits into the architecture and how it interacts with the 133 other architecture subsystems. For a detailed overview of the 134 documents that describe the current Internet-Standard Management 135 Framework, please refer to Section 7 of [RFC3410]. 137 This document describes a Transport Model that makes use of the 138 Datagram Transport Layer Security (DTLS) Protocol [RFC4347], the 139 datagram variant of the existing and commonly deployed Transport 140 Layer Security (TLS) protocol [RFC4346], within a transport subsystem 141 [I-D.ietf-isms-tmsm]. The Transport Model in this document is 142 referred to as the Datagram Transport Layer Security Transport Model 143 (DTLSTM). DTLS takes advantage of the X.509 public keying 144 infrastructure [X509]. This transport model is designed to meet the 145 security and operational needs of network administrators, operate in 146 environments where a connectionless (UDP) transport is preferred, and 147 integrate well into existing public keying infrastructures. 149 Managed objects are accessed via a virtual information store, termed 150 the Management Information Base or MIB. MIB objects are generally 151 accessed through the Simple Network Management Protocol (SNMP). 152 Objects in the MIB are defined using the mechanisms defined in the 153 Structure of Management Information (SMI). This document specifies a 154 MIB module that is compliant to the SMIv2, which is described in STD 155 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 156 2580 [RFC2580]. 158 This document also defines a portion of the Management Information 159 Base (MIB) for use with network management protocols in IP based 160 networks. In particular it defines objects for monitoring and 161 managing the DTLS Transport Model for SNMP. 163 The diagram shown below gives a conceptual overview of two SNMP 164 entities communicating using the DTLS Transport Model. One entity 165 contains a Command Responder and Notification Originator application, 166 and the other a Command Generator and Notification Responder 167 application. It should be understood that this particular mix of 168 application types is an example only and other combinations are 169 equally as legitimate. 171 +----------------------------------------------------------------+ 172 | Network | 173 +----------------------------------------------------------------+ 174 ^ ^ ^ ^ 175 |Notifications |Commands |Commands |Notifications 176 +---|---------------------|--------+ +--|---------------|-------------+ 177 | V V | | V V | 178 | +------------+ +------------+ | | +-----------+ +----------+ | 179 | | DTLS | | DTLS | | | | DTLS | | DTLS | | 180 | | Service | | Service | | | | Service | | Service | | 181 | | (Client) | | (Server) | | | | (Client) | | (Server)| | 182 | +------------+ +------------+ | | +-----------+ +----------+ | 183 | ^ ^ | | ^ ^ | 184 | +--+----------+ | | +-+--------------+ | 185 | +-----|---------+----+ | | +---|--------+----+ | 186 | | V |LCD | +-------+ | | | V |LCD | +--------+ | 187 | | +------+ +----+ | | | | | +------+ +----+ | | | 188 | | | DTLS | <---------->| Cache | | | | | DTLS | <---->| Cache | | 189 | | | TM | | | | | | | | TM | | | | | 190 | | +------+ | +-------+ | | | +------+ | +--------+ | 191 | |Transport Subsystem | ^ | | |Transport Sub. | ^ | 192 | +--------------------+ | | | +-----------------+ | | 193 | ^ +----+ | | ^ | | 194 | | | | | | | | 195 | v | | | V | | 196 | +-------+ +----------+ +-----+ | | | +-----+ +------+ +-----+ | | 197 | | | |Message | |Sec. | | | | | | | MP | |Sec. | | | 198 | | Disp. | |Processing| |Sub- | | | | |Disp.| | Sub- | |Sub- | | | 199 | | | |Subsystem | |sys. | | | | | | |system| |sys. | | | 200 | | | | | | | | | | | | | | | | | | 201 | | | | | |+---+| | | | | | | | |+---+| | | 202 | | | | +-----+ | || || | | | | | |+----+| || || | | 203 | | <--->|v3MP |<-->||TSM|<-+ | | | <-->|v3MP|<->|TSM|<-+ | 204 | | | | +-----+ | || || | | | | |+----+| || || | 205 | +-------+ | | |+---+| | | +-----+ | | |+---+| | 206 | ^ | | | | | | ^ | | | | | 207 | | +----------+ +-----+ | | | +------+ +-----+ | 208 | +-+----------+ | | +-+------------+ | 209 | ^ ^ | | ^ ^ | 210 | | | | | | | | 211 | v v | | V V | 212 | +-------------+ +--------------+ | | +-----------+ +--------------+ | 213 | | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | | 214 | | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RESPONDER | | 215 | | application | | applications | | | |application| | application | | 216 | +-------------+ +--------------+ | | +-----------+ +--------------+ | 217 | SNMP entity | | SNMP entity | 218 +----------------------------------+ +--------------------------------+ 220 1.1. Requirements Terminology 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in [RFC2119]. 226 1.2. Conventions 228 For consistency with SNMP-related specifications, this document 229 favors terminology as defined in STD62 rather than favoring 230 terminology that is consistent with non-SNMP specifications that use 231 different variations of the same terminology. This is consistent 232 with the IESG decision to not require the SNMPv3 terminology be 233 modified to match the usage of other non-SNMP specifications when 234 SNMPv3 was advanced to Full Standard. 236 In particular, where distinction is required the application names of 237 "Command Generator", "Command Responder", "Notification Originator", 238 "Notification Receiver", and "Proxy Forwarder" are used. See the 239 "SNMP Applications" in [RFC3413] for further information. 241 Authentication in this document typically refers to source 242 authentication or peer identity authentication performed in the 243 transport subsystem. 245 Throughout this document, the terms "client" and "server" are used to 246 refer to the two ends of the DTLS session. The client actively opens 247 the DTLS session, and the server passively listens for the incoming 248 DTLS session. Any SNMP entity may act as client or as server. 250 While security protocols frequently refer to a "user", the term used 251 in RFC3411 [RFC3411] and in this document is "principal". A 252 principal is the "who" on whose behalf services are provided or 253 processing takes place. A principal can be, among other things, an 254 individual acting in a particular role; a set of individuals, with 255 each acting in a particular role; an application or a set of 256 applications, or a combination of these within an administrative 257 domain. 259 Throughout this document, the term "session" is used to refer to a 260 secure association between two DTLS Transport Models that permits the 261 transmission of one or more SNMP messages within the lifetime of the 262 session. 264 2. The Datagram Transport Layer Security Protocol 266 The DTLS protocol is a datagram-compatible variant of the commonly 267 used Transport Layer Security (TLS) protocol. DTLS provides 268 authentication, data message integrity, and privacy at the transport 269 layer. (See [RFC4347]) 271 The primary goals of the DTLS Transport Model are to provide privacy, 272 source authentication and data integrity between two communicating 273 SNMP entities. The DTLS protocol is composed of two layers: the DTLS 274 Record Protocol and the DTLS Handshake Protocol. The following 275 sections provide an overview of these two layers. Please refer to 276 [RFC4347] for a complete description of the protocol. 278 2.1. The DTLS Record Protocol 280 At the lowest layer, layered on top of the transport protocol (UDP) 281 is the DTLS Record Protocol. 283 The DTLS Record Protocol provides security that has three basic 284 properties: 286 o The session can be confidential. Symmetric cryptography is used 287 for data encryption (e.g., AES [AES], DES [DES] etc.). The keys 288 for this symmetric encryption are generated uniquely for each 289 session and are based on a secret negotiated by another protocol 290 (such as the DTLS Handshake Protocol). The Record Protocol can 291 also be used without encryption. 293 o Messages can have data integrity. Message transport includes a 294 message integrity check using a keyed MAC. Secure hash functions 295 (e.g., SHA, MD5, etc.) are used for MAC computations. The Record 296 Protocol can operate without a MAC, but is generally only used in 297 this mode while another protocol is using the Record Protocol as a 298 transport for negotiating security parameters. 300 o Messages are protected against replay. DTLS uses explicit 301 sequence numbers, integrity checks, and a sliding window to 302 protect against replay of messages within a session. 304 DTLS also provides protection against replay of entire sessions. In 305 a properly-implemented keying material exchange, both sides will 306 generate new random numbers for each exchange. This results in 307 different encryption and integrity keys for every session. 309 2.2. The DTLS Handshake Protocol 311 The DTLS Record Protocol is used for encapsulation of various higher- 312 level protocols. One such encapsulated protocol, the DTLS Handshake 313 Protocol, allows server and client to authenticate each other and to 314 negotiate an encryption algorithm and cryptographic keys before the 315 application protocol transmits or receives its first octet of data. 316 Only the DTLS client can initiate the handshake protocol. The DTLS 317 Handshake Protocol provides security that has three basic properties: 319 o The peer's identity can be authenticated using asymmetric, or 320 public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This 321 authentication can be made optional, but is generally required by 322 at least one of the peers. 324 DTLS supports three authentication modes: authentication of both the 325 server and the client, server authentication with an unauthenticated 326 client, and total anonymity. For authentication of both entities, 327 each entity provides a valid certificate chain leading to an 328 acceptable certificate authority. Each entity is responsible for 329 verifying that the other's certificate is valid and has not expired 330 or been revoked. The DTLS Transport Model SHOULD always use 331 authentication of both the server and the client. At a minimum the 332 DTLS Transport MUST support authentication of the Command Generator 333 principals to guarantee the authenticity of the securityName (a 334 parameter used to pass the authenticated identity name from the 335 transport model to security model for even later use by the access 336 control subsystem. See Section 4.5.3.4). The DTLS Transport SHOULD 337 support the message encryption to protect sensitive data from 338 eavesdropping attacks. See [I-D.hodges-server-ident-check] for 339 further details on standardized processing when checking Server 340 certificate identities. 342 o The negotiation of a shared secret is secure: the negotiated 343 secret is unavailable to eavesdroppers, and for any authenticated 344 handshake the secret cannot be obtained, even by an attacker who 345 can place himself in the middle of the session. 347 o The negotiation is not vulnerable to malicious modification: it is 348 infeasible for an attacker to modify negotiation communication 349 without being detected by the parties to the communication. 351 o DTLS uses a stateless cookie exchange to protect against anonymous 352 denial of service attacks and has retransmission timers, sequence 353 numbers, and counters to handle message loss, reordering, and 354 fragmentation. 356 3. How the DTLSTM fits into the Transport Subsystem 358 A transport model is a component of the Transport Subsystem. The 359 DTLS Transport Model thus fits between the underlying DTLS transport 360 layer and the message Dispatcher [RFC3411] component of the SNMP 361 engine and the Transport Subsystem [I-D.ietf-isms-tmsm]. 363 The DTLS Transport Model will establish a session between itself and 364 the DTLS Transport Model of another SNMP engine. The sending 365 transport model passes unprotected messages from the dispatcher to 366 DTLS to be protected, and the receiving transport model accepts 367 decrypted and authenticated/integrity-checked incoming messages from 368 DTLS and passes them to the dispatcher. 370 After a DTLS Transport model session is established, SNMP messages 371 can conceptually be sent through the session from one SNMP message 372 dispatcher to another SNMP message dispatcher. If multiple SNMP 373 messages are needed to be passed between two SNMP applications they 374 SHOULD be passed through the same session. A DTLSTM implementation 375 engine MAY choose to close a DTLS session to conserve resources. 377 The DTLS Transport Model of an SNMP engine will perform the 378 translation between DTLS-specific security parameters and SNMP- 379 specific, model-independent parameters. 381 The diagram below depicts where the DTLS Transport Model fits into 382 the architecture described in RFC3411 and the Transport Subsystem: 384 +------------------------------+ 385 | Network | 386 +------------------------------+ 387 ^ ^ ^ 388 | | | 389 v v v 390 +-------------------------------------------------------------------+ 391 | +--------------------------------------------------+ | 392 | | Transport Subsystem | +--------+ | 393 | | +-----+ +-----+ +-----+ +-----+ +-------+ | | | | 394 | | | UDP | | TCP | | SSH | |DTLS | . . . | other |<--->| Cache | | 395 | | | | | | | TM | TM | | | | | | | 396 | | +-----+ +-----+ +-----+ +-----+ +-------+ | +--------+ | 397 | +--------------------------------------------------+ ^ | 398 | ^ | | 399 | | | | 400 | Dispatcher v | | 401 | +--------------+ +---------------------+ +----------------+ | | 402 | | Transport | | Message Processing | | Security | | | 403 | | Dispatch | | Subsystem | | Subsystem | | | 404 | | | | +------------+ | | +------------+ | | | 405 | | | | +->| v1MP |<--->| | USM | | | | 406 | | | | | +------------+ | | +------------+ | | | 407 | | | | | +------------+ | | +------------+ | | | 408 | | | | +->| v2cMP |<--->| | Transport | | | | 409 | | Message | | | +------------+ | | | Security |<--+ | 410 | | Dispatch <---->| +------------+ | | | Model | | | 411 | | | | +->| v3MP |<--->| +------------+ | | 412 | | | | | +------------+ | | +------------+ | | 413 | | PDU Dispatch | | | +------------+ | | | Other | | | 414 | +--------------+ | +->| otherMP |<--->| | Model(s) | | | 415 | ^ | +------------+ | | +------------+ | | 416 | | +---------------------+ +----------------+ | 417 | v | 418 | +-------+-------------------------+---------------+ | 419 | ^ ^ ^ | 420 | | | | | 421 | v v v | 422 | +-------------+ +---------+ +--------------+ +-------------+ | 423 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 424 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 425 | | application | | | | applications | | application | | 426 | +-------------+ +---------+ +--------------+ +-------------+ | 427 | ^ ^ | 428 | | | | 429 | v v | 430 | +----------------------------------------------+ | 431 | | MIB instrumentation | SNMP entity | 432 +-------------------------------------------------------------------+ 434 3.1. Security Capabilities of this Model 436 3.1.1. Threats 438 The DTLS Transport Model provides protection against the threats 439 identified by the RFC 3411 architecture [RFC3411]: 441 1. Modification of Information - The modification threat is the 442 danger that some unauthorized entity may alter in-transit SNMP 443 messages generated on behalf of an authorized principal in such a 444 way as to effect unauthorized management operations, including 445 falsifying the value of an object. 447 DTLS provides verification that the content of each received 448 message has not been modified during its transmission through the 449 network, data has not been altered or destroyed in an 450 unauthorized manner, and data sequences have not been altered to 451 an extent greater than can occur non-maliciously. 453 2. Masquerade - The masquerade threat is the danger that management 454 operations unauthorized for a given principal may be attempted by 455 assuming the identity of a principal with appropriate 456 authorizations. 458 The DTLSTM provides for authentication of the Principal Command 459 Generator and Notification Generator and for authentication of 460 the Command Responder, Notification Responder and Proxy Forwarder 461 through the use of X.509 certificates. 463 The masquerade threat can be mitigated against by using an 464 appropriate Access Control Model (ACM) such as the View-based 465 Access Control Module (VACM) [RFC3415]. In addition, it is 466 important to authenticate and verify both the authenticated 467 identity of the DTLS client and the DTLS server to protect 468 against this threat. (See Section 9 for more detail.) 470 3. Message stream modification - The re-ordering, delay or replay of 471 messages can and does occur through the natural operation of many 472 connectionless transport services. The message stream 473 modification threat is the danger that messages may be 474 maliciously re-ordered, delayed or replayed to an extent which is 475 greater than can occur through the natural operation of 476 connectionless transport services, in order to effect 477 unauthorized management operations. 479 DTLS provides replay protection with a MAC that includes a 480 sequence number. DTLS uses a sliding window protocol with the 481 sequence number for replay protection, see [RFC4347]. The 482 technique used is the same as in IPsec AH/ESP [RFC4302] 483 [RFC4303], by maintaining a bitmap window of received records. 484 Records that are too old to fit in the window and records that 485 have previously been received are silently discarded. The replay 486 detection feature is optional, since packet duplication can also 487 occur naturally due to routing errors and does not necessarily 488 indicate an active attack. Applications may conceivably detect 489 duplicate packets and accordingly modify their data transmission 490 strategy. 492 4. Disclosure - The disclosure threat is the danger of eavesdropping 493 on the exchanges between SNMP engines. Protecting against this 494 threat may be required as a matter of local policy. 496 Symmetric cryptography (e.g., AES [AES], DES [DES] etc.) can be 497 used by DTLS for data privacy. The keys for this symmetric 498 encryption are generated uniquely for each session and are based 499 on a secret negotiated by another protocol (such as the DTLS 500 Handshake Protocol). 502 5. Denial of Service - the RFC 3411 architecture [RFC3411] states 503 that denial of service (DoS) attacks need not be addressed by an 504 SNMP security protocol. However, datagram security protocols are 505 susceptible to a variety of denial of service attacks. Two 506 attacks are of particular concern: 508 o An attacker can consume excessive resources on the server by 509 transmitting a series of handshake initiation requests, 510 causing the server to allocate state and potentially to 511 perform expensive cryptographic operations. 513 o An attacker can use the server as an amplifier by sending 514 session initiation messages with a forged source of the 515 victim. The server then sends its next message (in DTLS, a 516 Certificate message, which can be quite large) to the victim 517 machine, thus flooding it. 519 In order to counter both of these attacks, DTLS borrows the 520 stateless cookie technique used by Photuris [RFC2522] and IKEv2 521 [RFC4306]. When the client sends its ClientHello message to the 522 server, the server MAY respond with a HelloVerifyRequest message. 523 This message contains a stateless cookie generated using the 524 technique of [RFC2522]. The client MUST retransmit the 525 ClientHello with the cookie added. The server then verifies the 526 cookie and proceeds with the handshake only if it is valid. This 527 mechanism forces the attacker/client to be able to receive the 528 cookie, which makes DoS attacks with spoofed IP addresses 529 difficult. This mechanism does not provide any defense against 530 denial of service attacks mounted from valid IP addresses. 532 Implementations are not required to perform the stateless cookie 533 exchange for every DTLS handshakes but in environments where 534 amplification could be an issue it is RECOMMENDED that the cookie 535 exchange is utilized. 537 3.1.2. Message Protection 539 The RFC 3411 architecture recognizes three levels of security: 541 o without authentication and without privacy (noAuthNoPriv) 543 o with authentication but without privacy (authNoPriv) 545 o with authentication and with privacy (authPriv) 547 The DTLS Transport Model determines from DTLS the identity of the 548 authenticated principal, and the type and address associated with an 549 incoming message, and the DTLS Transport Model provides this 550 information to DTLS for an outgoing message. 552 When an application requests a session for a message, through the 553 cache, the application requests a security level for that session. 554 The DTLS Transport Model MUST ensure that the DTLS session provides 555 security at least as high as the requested level of security. How 556 the security level is translated into the algorithms used to provide 557 data integrity and privacy is implementation-dependent. However, the 558 NULL integrity and encryption algorithms MUST NOT be used to fulfill 559 security level requests for authentication or privacy. 560 Implementations MAY choose to force DTLS to only allow cipher_suites 561 that provide both authentication and privacy to guarantee this 562 assertion. 564 If a suitable interface between the DTLS Transport Model and the DTLS 565 Handshake Protocol is implemented to allow the selection of security 566 level dependent algorithms, for example a security level to 567 cipher_suites mapping table, then different security levels may be 568 utilized by the application. However, different port numbers will 569 need to be used by at least one side of the connection to 570 differentiate between the DTLS sessions. This is the only way to 571 ensured proper selection of a session ID for an incoming DTLS 572 message. 574 The authentication, integrity and privacy algorithms used by the DTLS 575 Protocol [RFC4347] may vary over time as the science of cryptography 576 continues to evolve and the development of DTLS continues over time. 577 Implementers are encouraged to plan for changes in operator trust of 578 particular algorithms and implementations should offer configuration 579 settings for mapping algorithms to SNMPv3 security levels. 581 3.1.3. DTLS Sessions 583 DTLS sessions are opened by the DTLS Transport Model during the 584 elements of procedure for an outgoing SNMP message. Since the sender 585 of a message initiates the creation of a DTLS session if needed, the 586 DTLS session will already exist for an incoming message. 588 Implementations MAY choose to instantiate DTLS sessions in 589 anticipation of outgoing messages. This approach might be useful to 590 ensure that a DTLS session to a given target can be established 591 before it becomes important to send a message over the DTLS session. 592 Of course, there is no guarantee that a pre-established session will 593 still be valid when needed. 595 DTLS sessions are uniquely identified within the DTLS Transport Model 596 by the combination of transportDomain, transportAddress, 597 securityName, and requestedSecurityLevel associated with each 598 session. Each unique combination of these parameters MUST have a 599 locally-chosen unique dtlsSessionID associated for active sessions. 600 For further information see Section 4.4 and Section 5. 602 3.2. Security Parameter Passing 604 For the DTLS server-side, DTLS-specific security parameters (i.e., 605 cipher_suites, common name of X.509 certificate, IP address and port) 606 are translated by the DTLS Transport Model into security parameters 607 for the DTLS Transport Model and security model (i.e., securityLevel, 608 securityName, transportDomain, transportAddress). The transport- 609 related and DTLS-security-related information, including the 610 authenticated identity, are stored in a cache referenced by 611 tmStateReference. 613 For the DTLS client-side, the DTLS Transport Model takes input 614 provided by the dispatcher in the sendMessage() Abstract Service 615 Interface (ASI) and input from the tmStateReference cache. The DTLS 616 Transport Model converts that information into suitable security 617 parameters for DTLS and establishes sessions as needed. 619 The elements of procedure in Section 5 discuss these concepts in much 620 greater detail. 622 3.3. Notifications and Proxy 624 DTLS sessions may be initiated by DTLS clients on behalf of command 625 generators or notification originators. Command generators are 626 frequently operated by a human, but notification originators are 627 usually unmanned automated processes. The targets to whom 628 notifications should be sent is typically determined and configured 629 by a network administrator. 631 The SNMP-TARGET-MIB module [RFC3413] contains objects for defining 632 management targets, including transportDomain, transportAddress, 633 securityName, securityModel, and securityLevel parameters, for 634 Notification Generator, Proxy Forwarder, and SNMP-controllable 635 Command Generator applications. Transport domain and transport 636 address are configured in the snmpTargetAddrTable, and the 637 securityModel, securityName, and securityLevel parameters are 638 configured in the snmpTargetParamsTable. This document defines a MIB 639 module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to 640 specify a DTLS client-side certificate to use for the connection. 642 When configuring a DTLS target, the snmpTargetAddrTDomain and 643 snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be 644 set to the snmpDTLSDomain object and an appropriate snmpDTLSAddress 645 value respectively. The snmpTargetParamsMPModel column of the 646 snmpTargetParamsTable should be set to a value of 3 to indicate the 647 SNMPv3 message processing model. The snmpTargetParamsSecurityName 648 should be set to an appropriate securityName value and the 649 dtlstmParamsSubject parameter of the dtlstmParamsTable should be set 650 to the Subject of the locally held certificate to be used. Other 651 parameters, for example cryptographic configuration such as cipher 652 suites to use, must come from configuration mechanisms not defined in 653 this document. The other needed configuration may be configured 654 using SNMP or other implementation-dependent mechanisms (for example, 655 via a CLI). This securityName defined in the 656 snmpTargetParamsSecurityName column will be used by the access 657 control model to authorize any notifications that need to be sent. 659 4. Elements of the Model 661 This section contains definitions required to realize the DTLS 662 Transport Model defined by this document. 664 4.1. Certificates 666 DTLS makes use of X.509 certificates for authentication of both sides 667 of the transport. This section discusses the use of certificates in 668 DTLS and the its effects on SNMP over DTLS. 670 4.1.1. The Certificate Infrastructure 672 Users of a public key SHALL be confident that the associated private 673 key is owned by the correct remote subject (person or system) with 674 which an encryption or digital signature mechanism will be used. 675 This confidence is obtained through the use of public key 676 certificates, which are data structures that bind public key values 677 to subjects. The binding is asserted by having a trusted CA 678 digitally sign each certificate. The CA may base this assertion upon 679 technical means (i.e., proof of possession through a challenge- 680 response protocol), presentation of the private key, or on an 681 assertion by the subject. A certificate has a limited valid lifetime 682 which is indicated in its signed contents. Because a certificate's 683 signature and timeliness can be independently checked by a 684 certificate-using client, certificates can be distributed via 685 untrusted communications and server systems, and can be cached in 686 unsecured storage in certificate-using systems. 688 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which was 689 first published in 1988 as part of the X.500 Directory 690 recommendations, defines a standard certificate format [X509] which 691 is a certificate which binds a subject (principal) to a public key 692 value. This was later further documented in [RFC5280]. 694 A X.509 certificate is a sequence of three required fields: 696 tbsCertificate: The field contains the names of the subject and 697 issuer, a public key associated with the subject, a validity 698 period, and other associated information. This field may also 699 contain extensions. 701 signatureAlgorithm: The signatureAlgorithm field contains the 702 identifier for the cryptographic algorithm used by the certificate 703 authority (CA) to sign this certificate. 705 signatureValue: The signatureValue field contains a digital 706 signature computed upon the ASN.1 DER encoded tbsCertificate 707 field. The ASN.1 DER encoded tbsCertificate is used as the input 708 to the signature function. This signature value is then ASN.1 DER 709 encoded as a BIT STRING and included in the Certificate's 710 signature field. By generating this signature, a CA certifies the 711 validity of the information in the tbsCertificate field. In 712 particular, the CA certifies the binding between the public key 713 material and the subject of the certificate. 715 The basic X.509 authentication procedure is as follows: A system, 716 which uses the X.509 key management infrastructure, is initialized 717 with a number of root certificates which contain the public keys of a 718 number of trusted CAs. When a system receives a X.509 certificate, 719 signed by one of those CAs, that has to be verified, it first 720 decrypts the signatureValue field by using the public key of the 721 corresponding trusted CA. Then it compares the decrypted information 722 with the tbsCertificate field. If they match, then the subject in 723 the tbsCertificate field is authenticated. 725 4.1.2. Provisioning for the Certificate 727 Authentication using DTLS will require that SNMP entities are 728 provisioned with certificates, which are signed by trusted 729 certificate authorities. Furthermore, SNMP entities will most 730 commonly need to be provisioned with root certificates which 731 represent the list of trusted certificate authorities that an SNMP 732 entity can use for certificate verification. SNMP entities MAY also 733 be provisioned with X.509 certificate revocation mechanism which will 734 be used to verify that a certificate has not been revoked. 736 The authenticated tmSecurityName of the principal is looked up using 737 the dtlstmCertificateToSNTable. This table maps the certificates 738 issuer's distinguished name to a directly specified tmSecurityName or 739 it specifies that the CommonName field of the certificate's Subject 740 should be used as the tmSecurityName. The certificate trust anchors, 741 being either CA certificates or public keys for use by self-signed 742 certificates, must be installed through an out of band trusted 743 mechanism into the server and its authenticity MUST be verified 744 before access is granted. Implementations MAY choose to discard any 745 connections for which no dtlstmCertificateToSNTable mapping exists 746 for the issuer to avoid the computational resources associated with a 747 certificate verification check since the verified certificate would 748 be unusable anyway. 750 The typical enterprise configuration will map the "CommonName" 751 component of the Subject field in the tbsCertificate to the DTLSSM 752 specific tmSecurityName. Thus, the authenticated identity can be 753 verified by the DTLS Transport Model by extracting the CommonName 754 from the Subject of the peer certificate and the receiving 755 application will have an appropriate tmSecurityName for use by 756 components like an access control model. This setup requires very 757 little configuration: a single row in the dtlstmCertificateToSNTable. 759 An example mapping setup can be found in Appendix A 761 This tmSecurityName may be later translated from a DTLSSM specific 762 tmSecurityName to a SNMP engine securityName by the security model. 763 A security model, like the TSM security model, may perform an 764 identity mapping or a more complex mapping to derive the securityName 765 from the tmSecurityName. 767 4.2. Messages 769 As stated in RFC4347, each DTLS message must fit within a single 770 datagram. The DTLSTM MUST prohibit SNMP messages from being set that 771 exceed the MTU size. The DTLSTM implementation MUST return an error 772 when the MTU size would be exceeded and the message won't be sent. 774 For Ethernet the MTU size is 1500 and thus the maximum allowable SNMP 775 message that can be sent over DTLSTM after UDP/IP/DTLS overhead is 776 taken into account will be 1455 for IPv6 (MTU:1500 - IPv6:40 - UDP:8 777 - DTLS:13) and 1475 for IPv4 (MTU:1500 - IPv4:20 - UDP:8 - DTLS:13). 778 From this integrity and encryption overhead also needs to be 779 subtracted, which are integrity and encryption algorithm specific. 781 4.3. SNMP Services 783 This section describes the services provided by the DTLS Transport 784 Model with their inputs and outputs. The services are between the 785 Transport Model and the Dispatcher. 787 The services are described as primitives of an abstract service 788 interface (ASI) and the inputs and outputs are described as abstract 789 data elements as they are passed in these abstract service 790 primitives. 792 4.3.1. SNMP Services for an Outgoing Message 794 The Dispatcher passes the information to the DTLS Transport Model 795 using the ASI defined in the transport subsystem: 797 statusInformation = 798 sendMessage( 799 IN destTransportDomain -- transport domain to be used 800 IN destTransportAddress -- transport address to be used 801 IN outgoingMessage -- the message to send 802 IN outgoingMessageLength -- its length 803 IN tmStateReference -- reference to transport state 804 ) 806 The abstract data elements passed as parameters in the abstract 807 service primitives are as follows: 809 statusInformation: An indication of whether the passing of the 810 message was successful. If not it is an indication of the 811 problem. 813 destTransportDomain: The transport domain for the associated 814 destTransportAddress. The Transport Model uses this parameter to 815 determine the transport type of the associated 816 destTransportAddress. This parameter may also be used by the 817 transport subsystem to route the message to the appropriate 818 Transport Model. 820 destTransportAddress: The transport address of the destination DTLS 821 Transport Model in a format specified by the SnmpDTLSAddress 822 TEXTUAL-CONVENTION. 824 outgoingMessage: The outgoing message to send to DTLS for 825 encapsulation. 827 outgoingMessageLength: The length of the outgoing message. 829 tmStateReference: A handle/reference to tmSecurityData to be used 830 when securing outgoing messages. 832 4.3.2. SNMP Services for an Incoming Message 834 The DTLS Transport Model processes the received message from the 835 network using the DTLS service and then passes it to the Dispatcher 836 using the following ASI: 838 receiveMessage( 839 IN transportDomain -- origin transport domain 840 IN transportAddress -- origin transport address 841 IN incomingMessage -- the message received 842 IN incomingMessageLength -- its length 843 IN tmStateReference -- reference to transport state 844 ) 846 The abstract data elements passed as parameters in the abstract 847 service primitives are as follows: 849 statusInformation: An indication of whether the passing of the 850 message was successful. If not it is an indication of the 851 problem. 853 transportDomain: The transport domain for the associated 854 transportAddress. 856 transportAddress: The transport address of the source of the 857 received message in a format specified by the SnmpDTLSAddress 858 TEXTUAL-CONVENTION. 860 incomingMessage: The whole SNMP message stripped of all DTLS 861 protection data. 863 incomingMessageLength: The length of the SNMP message after being 864 processed by DTLS. 866 tmStateReference: A handle/reference to tmSecurityData to be used by 867 the security model. 869 4.4. DTLS Services 871 This section describes the services provided by the DTLS Transport 872 Model with their inputs and outputs. These services are between the 873 DTLS Transport Model and the DTLS transport layer. The following 874 sections describe services for establishing and closing a session and 875 for passing messages between the DTLS transport layer and the DTLS 876 Transport Model. 878 4.4.1. Services for Establishing a Session 880 The DTLS Transport Model provides the following ASI to describe the 881 data passed between the Transport Model and the DTLS transport layer 882 for session establishment. 884 statusInformation = -- errorIndication or success 885 openSession( 886 IN destTransportDomain -- transport domain to be used 887 IN destTransportAddress -- transport address to be used 888 IN securityName -- on behalf of this principal 889 IN securityLevel -- Level of Security requested 890 OUT dtlsSessionID -- Session identifier for DTLS 891 ) 893 The abstract data elements passed as parameters in the abstract 894 service primitives are as follows: 896 statusInformation: An indication of whether the process was 897 successful or not. If not, then the status information will 898 include the error indication provided by DTLS. 900 destTransportDomain: The transport domain for the associated 901 destTransportAddress. The DTLS Transport Model uses this 902 parameter to determine the transport type of the associated 903 destTransportAddress. 905 destTransportAddress: The transport address of the destination DTLS 906 Transport Model in a format specified by the SnmpDTLSAddress 907 TEXTUAL-CONVENTION. 909 securityName: The security name representing the principal on whose 910 behalf the message will be sent. 912 securityLevel: The level of security requested by the application. 914 dtlsSessionID: An implementation-dependent session identifier to 915 reference the specific DTLS session. 917 DTLS and UDP do not provide a session de-multiplexing mechanism and 918 it is possible that implementations will only be able to identify a 919 unique session based on a unique combination of source address, 920 destination address, source UDP port number and destination UDP port 921 number. Because of this, when establishing a new sessions 922 implementations MUST use a different UDP source port number for each 923 connection to a remote destination IP-address/port-number combination 924 to ensure the remote entity can properly disambiguate between 925 multiple sessions from a host to the same port on a server. 927 The procedural details for establishing a session are further 928 described in Section 5.3. 930 Upon completion of the process the DTLS Transport Model returns 931 status information and, if the process was successful the 932 dtlsSessionID and other implementation-dependent data from DTLS are 933 also returned. The dtlsSessionID is stored in an implementation- 934 dependent manner and tied to the tmSecurityData for future use of 935 this session. 937 4.4.2. DTLS Services for an Incoming Message 939 When the DTLS Transport Model invokes the DTLS record layer to verify 940 proper security for the incoming message, it must use the following 941 ASI: 943 statusInformation = -- errorIndication or success 944 dtlsRead( 945 IN dtlsSessionID -- Session identifier for DTLS 946 IN wholeDtlsMsg -- as received on the wire 947 IN wholeDtlsMsgLength -- length as received on the wire 948 OUT incomingMessage -- the whole SNMP message from DTLS 949 OUT incomingMessageLength -- the length of the SNMP message 950 ) 952 The abstract data elements passed as parameters in the abstract 953 service primitives are as follows: 955 statusInformation: An indication of whether the process was 956 successful or not. If not, then the status information will 957 include the error indication provided by DTLS. 959 dtlsSessionID: An implementation-dependent session identifier to 960 reference the specific DTLS session. How the DTLS session ID is 961 obtained for each message is implementation-dependent. As an 962 implementation hint, the DTLS Transport Model can examine incoming 963 messages to determine the source IP address and port number and 964 use these values to look up the local DTLS session ID in the list 965 of active sessions. 967 wholeDtlsMsg: The whole message as received on the wire. 969 wholeDtlsMsgLength: The length of the message as it was received on 970 the wire. 972 incomingMessage: The whole SNMP message stripped of all DTLS privacy 973 and integrity data. 975 incomingMessageLength: The length of the SNMP message stripped of 976 all DTLS privacy and integrity data. 978 4.4.3. DTLS Services for an Outgoing Message 980 When the DTLS Transport Model invokes the DTLS record layer to 981 encapsulate and transmit a SNMP message, it must use the following 982 ASI. 984 statusInformation = -- errorIndication or success 985 dtlsWrite( 986 IN dtlsSessionID -- Session identifier for DTLS 987 IN outgoingMessage -- the message to send 988 IN outgoingMessageLength -- its length 989 ) 991 The abstract data elements passed as parameters in the abstract 992 service primitives are as follows: 994 statusInformation: An indication of whether the process was 995 successful or not. If not, then the status information will 996 include the error indication provided by DTLS. 998 dtlsSessionID: An implementation-dependent session identifier to 999 reference the specific DTLS session that the message should be 1000 sent using. 1002 outgoingMessage: The outgoing message to send to DTLS for 1003 encapsulation. 1005 outgoingMessageLength: The length of the outgoing message. 1007 4.5. Cached Information and References 1009 When performing SNMP processing, there are two levels of state 1010 information that may need to be retained: the immediate state linking 1011 a request-response pair, and potentially longer-term state relating 1012 to transport and security. 1014 The RFC3411 architecture uses caches to maintain the short-term 1015 message state, and uses references in the ASIs to pass this 1016 information between subsystems. 1018 This document defines the requirements for a cache to handle the 1019 longer-term transport state information, using a tmStateReference 1020 parameter to pass this information between subsystems. 1022 To simplify the elements of procedure, the release of state 1023 information is not always explicitly specified. As a general rule, 1024 if state information is available when a message being processed gets 1025 discarded, the state related to that message SHOULD also be 1026 discarded. If state information is available when a relationship 1027 between engines is severed, such as the closing of a transport 1028 session, the state information for that relationship SHOULD also be 1029 discarded. 1031 Since the contents of a cache are meaningful only within an 1032 implementation, and not on-the-wire, the format of the cache and the 1033 LCD are implementation-specific. 1035 4.5.1. securityStateReference 1037 The securityStateReference parameter is defined in RFC3411. Its 1038 primary purpose is to provide a mapping between a request and the 1039 corresponding response. This cache is not accessible to Transport 1040 Models, and an entry is typically only retained for the lifetime of a 1041 request-response pair of messages. 1043 4.5.2. tmStateReference 1045 For each transport session, information about the transport security 1046 is stored in a cache. The tmStateReference parameter is used to pass 1047 model-specific and mechanism-specific parameters between the 1048 Transport subsystem and transport-aware Security Models. 1050 The tmStateReference cache will typically remain valid for the 1051 duration of the transport session, and hence may be used for several 1052 messages. 1054 Since this cache is only used within an implementation, and not on- 1055 the-wire, the precise contents and format are implementation- 1056 dependent. However, for interoperability between Transport Models 1057 and transport-aware Security Models, entries in this cache must 1058 include at least the following fields: 1060 transportDomain 1062 transportAddress 1064 tmSecurityName 1066 tmRequestedSecurityLevel 1068 tmTransportSecurityLevel 1070 tmSameSecurity 1071 tmSessionID 1073 4.5.2.1. Transport information 1075 Information about the source of an incoming SNMP message is passed up 1076 from the Transport subsystem as far as the Message Processing 1077 subsystem. However these parameters are not included in the 1078 processIncomingMsg ASI defined in RFC3411, and hence this information 1079 is not directly available to the Security Model. 1081 A transport-aware Security Model might wish to take account of the 1082 transport protocol and originating address when authenticating the 1083 request, and setting up the authorization parameters. It is 1084 therefore necessary for the Transport Model to include this 1085 information in the tmStateReference cache, so that it is accessible 1086 to the Security Model. 1088 o transportDomain: the transport protocol (and hence the Transport 1089 Model) used to receive the incoming message 1091 o transportAddress: the source of the incoming message. 1093 The ASIs used for processing an outgoing message all include explicit 1094 transportDomain and transportAddress parameters. The values within 1095 the securityStateReference cache might override these parameters for 1096 outgoing messages. 1098 4.5.2.2. securityName 1100 There are actually three distinct "identities" that can be identified 1101 during the processing of an SNMP request over a secure transport: 1103 o transport principal: the transport-authenticated identity, on 1104 whose behalf the secure transport connection was (or should be) 1105 established. This value is transport-, mechanism- and 1106 implementation- specific, and is only used within a given 1107 Transport Model. 1109 o tmSecurityName: a human-readable name (in snmpAdminString format) 1110 representing this transport identity. This value is transport- 1111 and implementation-specific, and is only used (directly) by the 1112 Transport and Security Models. 1114 o securityName: a human-readable name (in snmpAdminString format) 1115 representing the SNMP principal in a model-independent manner. 1117 The transport principal may or may not be the same as the 1118 tmSecurityName. Similarly, the tmSecurityName may or may not be the 1119 same as the securityName as seen by the Application and Access 1120 Control subsystems. In particular, a non-transport-aware Security 1121 Model will ignore tmSecurityName completely when determining the SNMP 1122 securityName. 1124 However it is important that the mapping between the transport 1125 principal and the SNMP securityName (for transport-aware Security 1126 Models) is consistent and predictable, to allow configuration of 1127 suitable access control and the establishment of transport 1128 connections. 1130 4.5.2.3. securityLevel 1132 There are two distinct issues relating to security level as applied 1133 to secure transports. For clarity, these are handled by separate 1134 fields in the tmStateReference cache: 1136 o tmTransportSecurityLevel: an indication from the Transport Model 1137 of the level of security offered by this session. The Security 1138 Model can use this to ensure that incoming messages were suitably 1139 protected before acting on them. 1141 o tmRequestedSecurityLevel: an indication from the Security Model of 1142 the level of security required to be provided by the transport 1143 protocol. The Transport Model can use this to ensure that 1144 outgoing messages will not be sent over an insufficiently secure 1145 session. 1147 4.5.2.4. Session Information 1149 For security reasons, if a secure transport session is closed between 1150 the time a request message is received and the corresponding response 1151 message is sent, then the response message SHOULD be discarded, even 1152 if a new session has been established. The SNMPv3 WG decided that 1153 this should be a SHOULD architecturally, and it is a security-model- 1154 specific decision whether to REQUIRE this. 1156 o tmSameSecurity: this flag is used by a transport-aware Security 1157 Model to indicate whether the Transport Model MUST enforce this 1158 restriction. 1160 o tmSessionID: in order to verify whether the session has changed, 1161 the Transport Model must be able to compare the session used to 1162 receive the original request with the one to be used to send the 1163 response. This typically requires some form of session 1164 identifier. This value is only ever used by the Transport Model, 1165 so the format and interpretation of this field are model-specific 1166 and implementation-dependent. 1168 When processing an outgoing message, if tmSameSecurity is true, then 1169 the tmSessionID MUST match the current transport session, otherwise 1170 the message MUST be discarded, and the dispatcher notified that 1171 sending the message failed. 1173 4.5.3. DTLS Transport Model Cached Information 1175 For the DTLS Transport Model, the session state is maintained using 1176 tmStateReference. Upon opening each DTLS session, the DTLS Transport 1177 Model stores model- and mechanism-specific information about the 1178 session in a cache, referenced by tmStateReference. An 1179 implementation might store the contents of the cache in a Local 1180 Configuration Datastore (LCD). 1182 At a minimum, the following parameters are stored in the cache: 1184 tmTransportDomain = Specified by the application tmSameSecurity = 1185 boolean value set by the security model or false by default 1187 tmTransportAddress = Specified by the application 1189 tmRequestedSecurityLevel = ["noAuthNoPriv" | "authNoPriv" | 1190 "authPriv" ] the security level requested by the application 1192 tmSecurityLevel = ["noAuthNoPriv" | "authNoPriv" | "authPriv" ] the 1193 security level of the established DTLS session 1195 tmSecurityName = the security name associated with a principal 1197 The tmStateReference cache is used to pass a reference to these 1198 values between the DTLS Transport Model and the security model. 1200 The DTLS Transport Model has the responsibility for releasing the 1201 complete tmStateReference and deleting the associated information 1202 when the session is destroyed. 1204 4.5.3.1. Transport Information 1206 The tmTransportDomain and tmTransportAddress identify the type and 1207 address of the remote DTLS transport endpoint. The domain for 1208 address types for DTLS sessions SHOULD be "snmpDTLSDomain" and the 1209 address SHOULD be one that conforms to the details specified in the 1210 "SnmpDTLSAddress" textual convention. 1212 4.5.3.2. tmRequestedSecurityLevel 1214 The tmRequestedSecurityLevel is the security level requested by the 1215 application. This parameter is set in the cache by the security 1216 model and used by DTLS Transport Model initiating a session to select 1217 the appropriate cipher_suites and other configuration needed settings 1218 for establishing the session. The DTLS Transport Model MUST ensure 1219 that the actual security provided by the session (tmSecurityLevel) is 1220 at least as high as the requested security level 1221 (tmRequestedSecurityLevel). 1223 4.5.3.3. tmSecurityLevel 1225 The tmSecurityLevel is the actual security level of the established 1226 session. See Section 3.1.2 for more detail about security levels. 1227 How the chosen cipher_suites and other DTLS session parameters are 1228 translated into a security level at the DTLS Transport Model is 1229 implementation dependent and/or policy specific. Implementations 1230 MUST NOT use NULL algorithms for fulfilling authentication or 1231 encryption needs indicated by the tmSecurityLevel. 1233 4.5.3.4. tmSecurityName 1235 The tmSecurityName is the name of the principal on whose behalf the 1236 message is being sent. This field is set via the mapping defined in 1237 the dtlstmCertificateToSNTable when mapping incoming client 1238 connection certificates to a tmSecurityName. For outgoing 1239 connections, the application will specify the value that should be 1240 placed in this field (possibly by extracting it from the SNMP-TARGET- 1241 MIB's snmpTargetParamsSecurityName value). 1243 4.5.4. Transport Model LCD 1245 Implementations may store DTLS-specific and model-specific 1246 information in a LCD. The DTLS session ID is one such parameter that 1247 could be stored in the LCD. When messages are to be routed for 1248 encapsulation or for integrity verification and decryption the 1249 message and the DTLS session ID must be passed to the DTLS transport 1250 layer for processing. Therefore, the DTLS Transport Model MUST 1251 maintain a one-to-one mapping between the DTLS session ID and the 1252 tmStateReference cache entry for that session. Implementations will 1253 need to store the DTLS session ID in the tmStateReference cache to 1254 simplify the procedure. 1256 5. Elements of Procedure 1258 Abstract service interfaces have been defined by RFC 3411 to describe 1259 the conceptual data flows between the various subsystems within an 1260 SNMP entity. The DTLSTM uses some of these conceptual data flows 1261 when communicating between subsystems. These RFC 3411-defined data 1262 flows are referred to here as public interfaces. 1264 To simplify the elements of procedure, the release of state 1265 information is not always explicitly specified. As a general rule, 1266 if state information is available when a message gets discarded, the 1267 message-state information should also be released. If state 1268 information is available when a session is closed, the session state 1269 information should also be released. Sensitive information, like 1270 cryptographic keys, should be overwritten with zero value or random 1271 value data prior to being released. 1273 An error indication may return an OID and value for an incremented 1274 counter if the information is available at the point where the error 1275 is detected. 1277 5.1. Procedures for an Incoming Message 1279 The following section describes the procedures followed by the DTLS 1280 Transport Model when it receives a DTLS protected packet. The steps 1281 are broken into two different sections. The first section describes 1282 the needed steps for de-multiplexing multiple DTLS sessions and the 1283 second section describes the steps which are specific to transport 1284 processing once the DTLS processing has been completed. 1286 5.1.1. DTLS Processing for Incoming Messages 1288 DTLS is significantly different in terms of session handling than 1289 SSH, TLS or other TCP-based session streams. The DTLS protocol, 1290 which is UDP-based, does not have a session identifier that allows 1291 implementations to determine through which session a packet is 1292 arriving like TCP-based streams have. Thus, a process for de- 1293 multiplexing sessions must be incorporated into the procedures for an 1294 incoming message. The steps in this section describe how this can be 1295 accomplished, although any implementation dependent method for doing 1296 so should be suitable as long as the results are consistently 1297 deterministic. The important results from the steps in this section 1298 are the transportDomain, the transportAddress, the wholeMessage, the 1299 wholeMessageLength, and a unique implementation-dependent session 1300 identifier. 1302 This procedure assumes that upon session establishment, an entry in a 1303 local transport mapping table is created in the Transport Model's 1304 LCD. This transport mapping table entry should be able to map a 1305 unique combination of the remote address, remote port number, local 1306 address and local port number to a implementation-dependent 1307 dtlsSessionID. 1309 1) The DTLS Transport Model examines the raw UDP message, in an 1310 implementation-dependent manner. If the message is not a DTLS 1311 message then it should be discarded. If the message is not a 1312 (D)TLS Application Data message then the message should be 1313 processed by the underlying DTLS framework as it is (for example) 1314 a session initialization or session modification message and no 1315 further steps below should be taken by the DTLS Transport. 1317 2) The DTLS Transport Model queries the LCD using the transport 1318 parameters to determine if a session already exists and its 1319 dtlsSessionID. As noted previously, the source and destination 1320 addresses and ports of the message should uniquely assign the 1321 message to a specific session identifier. However, another 1322 implementation-dependent method may be used if so desired. 1324 3) If a matching entry in the LCD does not exist then the message is 1325 discarded. Increment the dtlstmSessionNoAvailableSessions 1326 counter and stop processing the message. 1328 Note that an entry would already exist if the client and server's 1329 session establishment procedures had been successfully completed 1330 (as described both above and in Section 5.3) even if no message 1331 had yet been sent through the newly established session. An 1332 entry may not exist, however, if a "rogue" message was routed to 1333 the SNMP entity by mistake. An entry might also be missing 1334 because of a "broken" session (see operational considerations). 1336 4) Retrieve the dtlsSessionID from the LCD. 1338 5) The dtlsWholeMsg, and the dtlsSessionID are passed to DTLS for 1339 integrity checking and decryption using the dtlsRead() ASI. 1341 6) If the message fails integrity checks or other DTLS security 1342 processing then the dtlstmDTLSProtectionErrors counter is 1343 incremented, the message is discarded and processing of the 1344 message is stopped. 1346 7) The output of the dtlsRead results in an incomingMessage and an 1347 incomingMessageLength. These results and the dtlsSessionID are 1348 used below in the Section 5.1.2 to complete the processing of the 1349 incoming message. 1351 5.1.2. Transport Processing for Incoming Messages 1353 The procedures in this section describe how the DTLS Transport should 1354 process messages that have already been properly extracted from the 1355 DTLS stream, as described in Section 5.1.1. 1357 1) Create a tmStateReference cache for the subsequent reference and 1358 assign the following values within it: 1360 tmTransportDomain = snmpDTLSDomain 1362 tmTransportAddress = The address the message originated from, 1363 determined in an implementation dependent way. 1365 tmSecurityLevel = The derived tmSecurityLevel for the session, 1366 as discussed in Section 3.1.2 and Section 5.3. 1368 tmSecurityName = The derived tmSecurityName for the session as 1369 discussed in and Section 5.3. 1371 tmSessionID = A unique session identifier for this DTLS session. 1372 The contents and format of this identifier are implementation 1373 dependent as long as it is unique to the session. A session 1374 identifier MUST NOT be reused until all references to it are 1375 no longer in use. 1377 2) The wholeMessage and the wholeMessageLength are assigned values 1378 from the incomingMessage and incomingMessageLength values from 1379 the DTLS processing. 1381 3) The DTLS Transport Model passes the transportDomain, 1382 transportAddress, wholeMessage, and wholeMessageLength to the 1383 Dispatcher using the receiveMessage ASI: 1385 statusInformation = 1386 receiveMessage( 1387 IN transportDomain -- snmpSSHDomain 1388 IN transportAddress -- address for the received message 1389 IN wholeMessage -- the whole SNMP message from SSH 1390 IN wholeMessageLength -- the length of the SNMP message 1391 IN tmStateReference -- (NEW) transport info 1392 ) 1394 5.2. Procedures for an Outgoing Message 1396 The Dispatcher sends a message to the DTLS Transport Model using the 1397 following ASI: 1399 statusInformation = 1400 sendMessage( 1401 IN destTransportDomain -- transport domain to be used 1402 IN destTransportAddress -- transport address to be used 1403 IN outgoingMessage -- the message to send 1404 IN outgoingMessageLength -- its length 1405 IN tmStateReference -- (NEW) transport info 1406 ) 1408 This section describes the procedure followed by the DTLS Transport 1409 Model whenever it is requested through this ASI to send a message. 1411 1) Extract tmSessionID, tmTransportAddress, tmSecurityName, 1412 tmRequestedSecurityLevel. and tmSameSecurity from the 1413 tmStateReference. Note: The tmSessionID value may be undefined 1414 if session exists yet. 1416 2) If tmSameSecurity is true and either tmSessionID is undefined or 1417 refers to a session that is no longer open then increment the 1418 dtlstmSessionNoAvailableSessions counter, discard the message and 1419 return the error indication in the statusInformation. Processing 1420 of this message stops. 1422 3) If tmSameSecurity is false and tmSessionID refers to a session 1423 that is no longer available then an implementation SHOULD open a 1424 new session using the openSession() ASI as described below in 1425 step 3b. An implementation MAY choose to return an error to the 1426 calling module. 1428 4) If tmSessionID is undefined, then use tmTransportAddress, 1429 tmSecurityName and tmRequestedSecurityLevel to see if there is a 1430 corresponding entry in the LCD suitable to send the message over. 1432 3a) If there is a corresponding LCD entry, then this session 1433 will be used to send the message. 1435 3b) If there is not a corresponding LCD entry, then open a 1436 session using the openSession() ASI (discussed further in 1437 Section 4.4.1). Implementations MAY wish to offer message 1438 buffering to prevent redundant openSession() calls for the 1439 same cache entry. If an error is returned from 1440 OpenSession(), then discard the message, increment the 1441 dtlstmSessionOpenErrors, and return an error indication to 1442 the calling module. 1444 5) Using either the session indicated by the tmSessionID if there 1445 was one or the session resulting in the previous step, pass the 1446 outgoingMessage to DTLS for encapsulation and transmission. 1448 5.3. Establishing a Session 1450 The DTLS Transport Model provides the following primitive to 1451 establish a new DTLS session (previously discussed in Section 4.4.1): 1453 statusInformation = -- errorIndication or success 1454 openSession( 1455 IN destTransportDomain -- transport domain to be used 1456 IN destTransportAddress -- transport address to be used 1457 IN securityName -- on behalf of this principal 1458 IN securityLevel -- Level of Security requested 1459 OUT dtlsSessionID -- Session identifier for DTLS 1460 ) 1462 The following sections describe the procedures followed by a DTLS 1463 Transport Model when establishing a session as a Command Generator, a 1464 Notification Originator or as part of a Proxy Forwarder. 1466 The following describes the procedure to follow to establish a 1467 session between SNMP engines to exchange SNMP messages. This process 1468 is followed by any SNMP engine establishing a session for subsequent 1469 use. 1471 This MAY done automatically for SNMP messages which are not Response 1472 or Report messages. 1474 DTLS provides no explicit manner for transmitting an identity the 1475 client wishes to connect to during or prior to key exchange to 1476 facilitate certificate selection at the server (e.g. at a 1477 Notification Receiver). I.E., there is no available mechanism for 1478 sending notifications to a specific principal at a given UDP/port 1479 combination. Therefore, implementations MAY support responding with 1480 multiple identities using separate UDP port numbers to indicate the 1481 desired principal or some other implementation-dependent solution. 1483 1) The client selects the appropriate certificate and cipher_suites 1484 for the key agreement based on the tmSecurityName and the 1485 tmRequestedSecurityLevel for the session. For sessions being 1486 established as a result of a SNMP-TARGET-MIB based operation, the 1487 certificate will potentially have been identified via the 1488 dtlstmParamsTable mapping and the cipher_suites will have to be 1489 taken from system-wide or implementation-specific configuration. 1490 Otherwise, the certificate and appropriate cipher_suites will 1491 need to be passed to the openSession() ASI as supplemental 1492 information or configured through an implementation-dependent 1493 mechanism. It is also implementation-dependent and possibly 1494 policy-dependent how tmRequestedSecurityLevel will be used to 1495 influence the security capabilities provided by the DTLS session. 1496 However this is done, the security capabilities provided by DTLS 1497 MUST be at least as high as the level of security indicated by 1498 the tmRequestedSecurityLevel parameter. The actual security 1499 level of the session should be reported in the tmStateReference 1500 cache as tmSecurityLevel. For DTLS to provide strong 1501 authentication, each principal acting as a Command Generator 1502 SHOULD have its own certificate. 1504 2) Using the destTransportDomain and destTransportAddress values, 1505 the client will initiate the DTLS handshake protocol to establish 1506 session keys for message integrity and encryption. 1508 If the attempt to establish a session is unsuccessful, then 1509 dtlstmSessionOpenErrors is incremented, an error indication is 1510 returned, and session establishment processing stops. 1512 3) Once the secure session is established and both sides have been 1513 authenticated, certificate validation and identity expectations 1514 are performed. 1516 a) The DTLS server side of the connection identifies the 1517 authenticated identity from the DTLS client's principal 1518 certificate using the dtlstmCertificateToSNTable mapping 1519 table and records this in the tmStateReference cache as 1520 tmSecurityName. If this verification fails in any way (for 1521 example because of failures in cryptographic verification or 1522 the lack of an appropriate row in the 1523 dtlstmCertificateToSNTable) then the session establishment 1524 MUST fail, the dtlstmSessionInvalidClientCertificates object 1525 is incremented and processing is stopped. 1527 b) The DTLS client side of the connection SHOULD verify that 1528 authenticated identity of the DTLS server's certificate is 1529 the expected identity and MUST do so if the client 1530 application is a Notification Generator. If strong 1531 authentication is desired then the DTLS server certificate 1532 MUST always be verified and checked against the expected 1533 identity. Methods for doing this are described in 1534 [I-D.hodges-server-ident-check]. DTLS provides assurance 1535 that the authenticated identity has been signed by a trusted 1536 configured certificate authority. If verification of the 1537 server's certificate fails in any way (for example because of 1538 failures in cryptographic verification or the presented 1539 identity was not the expected identity) then the session 1540 establishment MUST fail, the 1541 dtlstmSessionInvalidServerCertificates object is incremented 1542 and processing is stopped. 1544 4) The DTLS-specific session identifier is passed to the DTLS 1545 Transport Model and associated with the tmStateReference cache 1546 entry to indicate that the session has been established 1547 successfully and to point to a specific DTLS session for future 1548 use. 1550 5.4. Closing a Session 1552 The DTLS Transport Model provides the following primitive to close a 1553 session: 1555 statusInformation = 1556 closeSession( 1557 IN tmStateReference -- transport info 1558 ) 1560 The following describes the procedure to follow to close a session 1561 between a client and server. This process is followed by any SNMP 1562 engine closing the corresponding SNMP session. 1564 1) Look up the session in the cache and the LCD using the 1565 tmStateReference. 1567 2) If there is no session open associated with the tmStateReference, 1568 then closeSession processing is completed. 1570 3) Delete the entry from the cache and any other implementation- 1571 dependent information in the LCD. 1573 4) Have DTLS close the specified session. This SHOULD include 1574 sending a close_notify TLS Alert to inform the other side that 1575 session cleanup may be performed. 1577 6. MIB Module Overview 1579 This MIB module provides management of the DTLS Transport Model. It 1580 defines needed textual conventions, statistical counters and 1581 configuration infrastructure necessary for session establishment. 1582 Example usage of the configuration tables can be found in Appendix A. 1584 6.1. Structure of the MIB Module 1586 Objects in this MIB module are arranged into subtrees. Each subtree 1587 is organized as a set of related objects. The overall structure and 1588 assignment of objects to their subtrees, and the intended purpose of 1589 each subtree, is shown below. 1591 6.2. Textual Conventions 1593 Generic and Common Textual Conventions used in this module can be 1594 found summarized at http://www.ops.ietf.org/mib-common-tcs.html 1596 This module defines two new Textual Conventions: a new 1597 TransportDomain and TransportAddress format for describing DTLS 1598 connection addressing requirements. 1600 6.3. Statistical Counters 1602 The DTLSTM-MIB defines some statical counters that can provide 1603 network managers with feedback about DTLS session usage and potential 1604 errors that a MIB-instrumented device may be experiencing. 1606 6.4. Configuration Tables 1608 The DTLSTM-MIB defines configuration tables that a manager can use 1609 for help in configuring a MIB-instrumented device for sending and 1610 receiving SNMP messages over DTLS. In particular, there is a MIB 1611 table that extends the SNMP-TARGET-MIB for configuring certificates 1612 to be used and a MIB table for mapping incoming DTLS client 1613 certificates to securityNames. 1615 6.5. Relationship to Other MIB Modules 1617 Some management objects defined in other MIB modules are applicable 1618 to an entity implementing the DTLS Transport Model. In particular, 1619 it is assumed that an entity implementing the DTLSTM-MIB will 1620 implement the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411], 1621 the SNMP-TARGET-MIB [RFC3413], the SNMP-NOTIFICATION-MIB [RFC3413] 1622 and the SNMP-VIEW-BASED-ACM-MIB [RFC3415]. 1624 This MIB module is for managing DTLS Transport Model information. 1626 6.5.1. MIB Modules Required for IMPORTS 1628 The following MIB module imports items from SNMPV2-SMI [RFC2578], 1629 SNMPV2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB 1630 [RFC3413] and SNMP-CONF [RFC2580]. 1632 7. MIB Module Definition 1634 DTLSTM-MIB DEFINITIONS ::= BEGIN 1636 IMPORTS 1637 MODULE-IDENTITY, OBJECT-TYPE, 1638 OBJECT-IDENTITY, snmpModules, snmpDomains, 1639 Counter32, Unsigned32 1640 FROM SNMPv2-SMI 1641 TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType 1642 FROM SNMPv2-TC 1643 MODULE-COMPLIANCE, OBJECT-GROUP 1644 FROM SNMPv2-CONF 1645 SnmpAdminString 1646 FROM SNMP-FRAMEWORK-MIB 1647 snmpTargetParamsEntry 1648 FROM SNMP-TARGET-MIB 1649 ; 1651 dtlstmMIB MODULE-IDENTITY 1652 LAST-UPDATED "200807070000Z" 1653 ORGANIZATION " " 1654 CONTACT-INFO "WG-EMail: 1655 Subscribe: 1657 Chairs: 1658 Co-editors: 1659 " 1661 DESCRIPTION "The DTLS Transport Model MIB 1663 Copyright (C) The IETF Trust (2008). This 1664 version of this MIB module is part of RFC XXXX; 1665 see the RFC itself for full legal notices." 1666 -- NOTE to RFC editor: replace XXXX with actual RFC number 1667 -- for this document and remove this note 1669 REVISION "200807070000Z" 1670 DESCRIPTION "The initial version, published in RFC XXXX." 1671 -- NOTE to RFC editor: replace XXXX with actual RFC number 1672 -- for this document and remove this note 1674 ::= { snmpModules xxxx } 1675 -- RFC Ed.: replace xxxx with IANA-assigned number and 1676 -- remove this note 1678 -- ************************************************ 1679 -- subtrees of the SNMP-DTLS-TM-MIB 1680 -- ************************************************ 1682 dtlstmNotifications OBJECT IDENTIFIER ::= { dtlstmMIB 0 } 1683 dtlstmObjects OBJECT IDENTIFIER ::= { dtlstmMIB 1 } 1684 dtlstmConformance OBJECT IDENTIFIER ::= { dtlstmMIB 2 } 1686 -- ************************************************ 1687 -- Objects 1688 -- ************************************************ 1690 snmpDTLSDomain OBJECT-IDENTITY 1691 STATUS current 1692 DESCRIPTION 1693 "The SNMP over DTLS transport domain. The corresponding 1694 transport address is of type SnmpDTLSAddress. 1696 When an SNMP entity uses the snmpDTLSDomain transport 1697 model, it must be capable of accepting messages up to 1698 the maximum MTU size for an interface it supports, minus the 1699 needed IP, UDP, DTLS and other protocol overheads. 1701 The securityName prefix to be associated with the 1702 snmpDTLSDomain is 'dtls'. This prefix may be used by 1703 security models or other components to identify what secure 1704 transport infrastructure authenticated a securityName." 1706 ::= { snmpDomains yy } 1708 -- RFC Ed.: Please replace the I-D reference with a proper one once it 1709 -- has been published. Note: xml2rfc doesn't handle refs within artwork 1711 -- RFC Ed.: replace yy with IANA-assigned number and 1712 -- remove this note 1714 -- RFC Ed.: replace 'dtls' with the actual IANA assigned prefix string 1715 -- if 'dtls' is not assigned to this document. 1717 SnmpDTLSAddress ::= TEXTUAL-CONVENTION 1718 DISPLAY-HINT "1a" 1719 STATUS current 1720 DESCRIPTION 1721 "Represents a UDP connection address for an IPv4 address, an 1722 IPv6 address or an ASCII encoded host name and port number. 1724 The hostname must be encoded in ASCII, as specified in RFC3490 1725 (Internationalizing Domain Names in Applications) followed by 1726 a colon ':' (ASCII character 0x3A) and a decimal port number 1727 in ASCII. The name SHOULD be fully qualified whenever 1728 possible. 1730 An IPv4 address must be a dotted decimal format followed by a 1731 colon ':' (ASCII character 0x3A) and a decimal port number in 1732 ASCII. 1734 An IPv6 address must be a colon separated format, surrounded 1735 by square brackets (ASCII characters 0x5B and 0x5D), followed 1736 by a colon ':' (ASCII character 0x3A) and a decimal port 1737 number in ASCII. 1739 Values of this textual convention may not be directly usable 1740 as transport-layer addressing information, and may require 1741 run-time resolution. As such, applications that write them 1742 must be prepared for handling errors if such values are not 1743 supported, or cannot be resolved (if resolution occurs at the 1744 time of the management operation). 1746 The DESCRIPTION clause of TransportAddress objects that may 1747 have snmpDTLSAddress values must fully describe how (and when) 1748 such names are to be resolved to IP addresses and vice versa. 1750 This textual convention SHOULD NOT be used directly in object 1751 definitions since it restricts addresses to a specific 1752 format. However, if it is used, it MAY be used either on its 1753 own or in conjunction with TransportAddressType or 1754 TransportDomain as a pair. 1756 When this textual convention is used as a syntax of an index 1757 object, there may be issues with the limit of 128 1758 sub-identifiers specified in SMIv2, STD 58. It is RECOMMENDED 1759 that all MIB documents using this textual convention make 1760 explicit any limitations on index component lengths that 1761 management software must observe. This may be done either by 1762 including SIZE constraints on the index components or by 1763 specifying applicable constraints in the conceptual row 1764 DESCRIPTION clause or in the surrounding documentation." 1765 SYNTAX OCTET STRING (SIZE (1..255)) 1767 -- The dtlstmSession Group 1769 dtlstmSession OBJECT IDENTIFIER ::= { dtlstmObjects 1 } 1771 dtlstmSessionOpens OBJECT-TYPE 1772 SYNTAX Counter32 1773 MAX-ACCESS read-only 1774 STATUS current 1775 DESCRIPTION 1776 "The number of times an openSession() request has been 1777 executed as an SSH client, whether it succeeded or failed." 1778 ::= { dtlstmSession 1 } 1780 dtlstmSessionCloses OBJECT-TYPE 1781 SYNTAX Counter32 1782 MAX-ACCESS read-only 1783 STATUS current 1784 DESCRIPTION 1785 "The number of times a closeSession() request has been 1786 executed as an SSH client, whether it succeeded or failed." 1787 ::= { dtlstmSession 2 } 1789 dtlstmSessionOpenErrors OBJECT-TYPE 1790 SYNTAX Counter32 1791 MAX-ACCESS read-only 1792 STATUS current 1793 DESCRIPTION 1794 "The number of times an openSession() request failed to open a 1795 session as a SSH client, for any reason." 1796 ::= { dtlstmSession 3 } 1798 dtlstmSessionNoAvailableSessions OBJECT-TYPE 1799 SYNTAX Counter32 1800 MAX-ACCESS read-only 1801 STATUS current 1802 DESCRIPTION 1803 "The number of times an outgoing message was dropped because 1804 the session associated with the passed tmStateReference was no 1805 longer (or was never) available." 1806 ::= { dtlstmSession 4 } 1808 dtlstmSessionInvalidClientCertificates OBJECT-TYPE 1809 SYNTAX Counter32 1810 MAX-ACCESS read-only 1811 STATUS current 1812 DESCRIPTION 1813 "The number of times an incoming session was not established 1814 on an SSH server because the presented client certificate was 1815 invalid. Reasons for invalidation includes, but is not 1816 limited to, crypographic validation failures and lack of a 1817 suitable mapping row in the dtlstmCertificateToSNTable." 1818 ::= { dtlstmSession 5 } 1820 dtlstmSessionInvalidServerCertificates OBJECT-TYPE 1821 SYNTAX Counter32 1822 MAX-ACCESS read-only 1823 STATUS current 1824 DESCRIPTION 1825 "The number of times an outgoing session was not established 1826 on an SSH client because the presented server certificate was 1827 invalid. Reasons for invalidation includes, but is not 1828 limited to, crypographic validation failures and an unexpected 1829 presented certificate identity." 1830 ::= { dtlstmSession 6 } 1832 dtlstmDTLSProtectionErrors OBJECT-TYPE 1833 SYNTAX Counter32 1834 MAX-ACCESS read-only 1835 STATUS current 1836 DESCRIPTION 1837 "The number of times DTLS processing resulted in a message 1838 being discarded because it failed its integrity test, 1839 decryption processing or other DTLS processing." 1840 ::= { dtlstmSession 7 } 1842 -- Configuration Objects 1844 dtlstmConfig OBJECT IDENTIFIER ::= { dtlstmObjects 2 } 1846 -- Certificate mapping 1848 dtlstmCertificateMapping OBJECT IDENTIFIER ::= { dtlstmConfig 1 } 1850 dtlstmCertificateToSNCount OBJECT-TYPE 1851 SYNTAX Unsigned32 1852 MAX-ACCESS read-only 1853 STATUS current 1854 DESCRIPTION 1855 "A count of the number of entries in the 1856 dtlstmCertificateToSNTable" 1857 ::= { dtlstmCertificateMapping 1 } 1859 dtlstmCertificateToSNTableLastChanged OBJECT-TYPE 1860 SYNTAX TimeStamp 1861 MAX-ACCESS read-only 1862 STATUS current 1863 DESCRIPTION 1864 "The value of sysUpTime.0 when the dtlstmCertificateToSNTable 1865 was last modified through any means, or 0 if it has not been 1866 modified since the command responder was started." 1867 ::= { dtlstmCertificateMapping 2 } 1869 dtlstmCertificateToSNTable OBJECT-TYPE 1870 SYNTAX SEQUENCE OF DtlstmCertificateToSNEntry 1871 MAX-ACCESS not-accessible 1872 STATUS current 1873 DESCRIPTION 1874 "A table listing the X.509 certificates known to the entity 1875 and the associated method for determining the SNMPv3 security 1876 name from a certificate. 1878 On an incoming DTLS/SNMP connection the client's presented 1879 certificate should be examined and validated based on 1880 an established trusted CA certificate or self-signed public 1881 certificate. This table does not provide 1882 a mechanism for uploading the certificates as that is expected 1883 to occur through an out-of-band transfer. 1885 Once the authenticity of the certificate has been verified, 1886 this table can be consulted to determine the appropriate 1887 securityName to identify the remote connection. This is done 1888 by comparing the issuer's distinguished name against the 1889 dtlstmCertDN value. If a matching entry is found then the 1890 securityName is selected based on the dtlstmCertMapType, 1891 dtlstmCertSubject and dtlstmCertSecurityName fields and the 1892 resulting securityName is used to identify the other side of 1893 the DTLS connection. 1895 Users are encouraged to make use of certificates with 1896 CommonName fields that can be used as securityNames so that a 1897 single root CA certificate can allow all child certificate's 1898 CommonName to map directly to a securityName via a 1:1 1899 transformation. However, this table is flexible enough to 1900 allow for situations where existing an existing deployed 1901 certificate infrastructures dose not provide adequate 1902 CommonName values for use as SNMPv3 securityNames." 1903 ::= { dtlstmCertificateMapping 3 } 1905 dtlstmCertificateToSNEntry OBJECT-TYPE 1906 SYNTAX DtlstmCertificateToSNEntry 1907 MAX-ACCESS not-accessible 1908 STATUS current 1909 DESCRIPTION 1910 "A row in the dtlstmCertificateToSNTable that specifies a 1911 mapping for an incoming DTLS certificate to a securityName to 1912 use for the connection." 1913 INDEX { dtlstmCertID } 1914 ::= { dtlstmCertificateToSNTable 1 } 1916 DtlstmCertificateToSNEntry ::= SEQUENCE { 1917 dtlstmCertID Unsigned32, 1918 dtlstmCertIssuerDN OCTET STRING, 1919 dtlstmCertMapType INTEGER, 1920 dtlstmCertSecurityName SnmpAdminString, 1921 dtlstmCertStorageType StorageType, 1922 dtlstmCertRowStatus RowStatus 1923 } 1925 dtlstmCertID OBJECT-TYPE 1926 SYNTAX Unsigned32 1927 MAX-ACCESS not-accessible 1928 STATUS current 1929 DESCRIPTION 1930 "A unique arbitrary number index for a given certificate 1931 entry." 1932 ::= { dtlstmCertificateToSNEntry 1 } 1934 dtlstmCertIssuerDN OBJECT-TYPE 1935 SYNTAX OCTET STRING 1936 MAX-ACCESS read-create 1937 STATUS current 1938 DESCRIPTION 1939 "The issuer's 'distinguished name' field matching the 1940 certificate to be used for this mapping entry. 1941 " 1942 -- XXX: allow specification via serial no too? 1943 ::= { dtlstmCertificateToSNEntry 2 } 1945 dtlstmCertMapType OBJECT-TYPE 1946 SYNTAX INTEGER { specified(1), byCN(2) } 1947 MAX-ACCESS read-create 1948 STATUS current 1949 DESCRIPTION 1950 "The mapping type used to obtain the securityName from the 1951 certificate. The possible values of use and their usage 1952 methods are defined as follows: 1954 specified(1): The securityName that should be used locally to 1955 identify the remote entity is directly specified 1956 in the dtlstmCertSecurityName column from this 1957 table. 1959 byCN(2): The securityName that should be used locally to 1960 identify the remote entity should be taken from 1961 the CommonName portion of the Subject field from 1962 the X.509 certificate." 1963 DEFVAL { specified } 1964 ::= { dtlstmCertificateToSNEntry 3 } 1966 dtlstmCertSecurityName OBJECT-TYPE 1967 SYNTAX SnmpAdminString (SIZE(0..32)) 1968 MAX-ACCESS read-create 1969 STATUS current 1970 DESCRIPTION 1971 "The securityName that the session should use if the 1972 dtlstmCertMapType is set to specified(1), otherwise the value 1973 in this column should be ignored. If dtlstmCertMapType is set 1974 to specifed(1) and this column contains a zero-length string 1975 (which is not a legal securityName value) this row is 1976 effectively disabled and the match will not be considered 1977 successful." 1978 DEFVAL { "" } 1979 ::= { dtlstmCertificateToSNEntry 4 } 1981 dtlstmCertStorageType OBJECT-TYPE 1982 SYNTAX StorageType 1983 MAX-ACCESS read-create 1984 STATUS current 1985 DESCRIPTION 1986 "The storage type for this conceptual row. Conceptual rows 1987 having the value 'permanent' need not allow write-access to 1988 any columnar objects in the row." 1989 DEFVAL { nonVolatile } 1990 ::= { dtlstmCertificateToSNEntry 5 } 1992 dtlstmCertRowStatus OBJECT-TYPE 1993 SYNTAX RowStatus 1994 MAX-ACCESS read-create 1995 STATUS current 1996 DESCRIPTION 1997 "The status of this conceptual row. This object may be used 1998 to create or remove rows from this table. 2000 The value of this object has no effect on whether 2001 other objects in this conceptual row can be modified." 2002 ::= { dtlstmCertificateToSNEntry 6 } 2004 -- Maps securityNames to certificates for use by the SNMP-TARGET-MIB 2006 dtlstmParamsCount OBJECT-TYPE 2007 SYNTAX Unsigned32 2008 MAX-ACCESS read-only 2009 STATUS current 2010 DESCRIPTION 2011 "A count of the number of entries in the 2012 dtlstmParamsTable" 2014 ::= { dtlstmCertificateMapping 4 } 2016 dtlstmParamsTableLastChanged OBJECT-TYPE 2017 SYNTAX TimeStamp 2018 MAX-ACCESS read-only 2019 STATUS current 2020 DESCRIPTION 2021 "The value of sysUpTime.0 when the dtlstmParamsTable 2022 was last modified through any means, or 0 if it has not been 2023 modified since the command responder was started." 2024 ::= { dtlstmCertificateMapping 5 } 2026 dtlstmParamsTable OBJECT-TYPE 2027 SYNTAX SEQUENCE OF DtlstmParamsEntry 2028 MAX-ACCESS not-accessible 2029 STATUS current 2030 DESCRIPTION 2031 "This table augments the SNMP-TARGET-MIB's 2032 snmpTargetParamsTable with additional a DTLS client-side 2033 certificate certificate identifier to use when establishing 2034 new DTLS connections." 2035 ::= { dtlstmCertificateMapping 6 } 2037 dtlstmParamsEntry OBJECT-TYPE 2038 SYNTAX DtlstmParamsEntry 2039 MAX-ACCESS not-accessible 2040 STATUS current 2041 DESCRIPTION 2042 "A conceptual row containing the certificate subject name for 2043 a given snmpTargetParamsEntry. The values in this row should 2044 be ignored if not the connection that needs to be established, 2045 as indicated by the SNMP-TARGET-MIB infrastructure, is not a 2046 DTLS based connection." 2047 AUGMENTS { snmpTargetParamsEntry } 2048 ::= { dtlstmParamsTable 1 } 2050 DtlstmParamsEntry ::= SEQUENCE { 2051 dtlstmParamsSubject OCTET STRING, 2052 dtlstmParamsStorageType StorageType, 2053 dtlstmParamsRowStatus RowStatus 2054 } 2056 dtlstmParamsSubject OBJECT-TYPE 2057 SYNTAX OCTET STRING (SIZE(1..4096)) 2058 MAX-ACCESS read-create 2059 STATUS current 2060 DESCRIPTION 2061 "The subject name of the locally-held X.509 certificate that 2062 should be used when initiating a DTLS connection as a DTLS 2063 client." 2064 ::= { dtlstmParamsEntry 1 } 2066 dtlstmParamsStorageType OBJECT-TYPE 2067 SYNTAX StorageType 2068 MAX-ACCESS read-create 2069 STATUS current 2070 DESCRIPTION 2071 "The storage type for this conceptual row. Conceptual rows 2072 having the value 'permanent' need not allow write-access to 2073 any columnar objects in the row." 2074 DEFVAL { nonVolatile } 2075 ::= { dtlstmParamsEntry 2 } 2077 dtlstmParamsRowStatus OBJECT-TYPE 2078 SYNTAX RowStatus 2079 MAX-ACCESS read-create 2080 STATUS current 2081 DESCRIPTION 2082 "The status of this conceptual row. This object may be used 2083 to create or remove rows from this table. 2085 The value of this object has no effect on whether 2086 other objects in this conceptual row can be modified." 2087 ::= { dtlstmParamsEntry 3 } 2089 -- ************************************************ 2090 -- dtlstmMIB - Conformance Information 2091 -- ************************************************ 2093 dtlstmCompliances OBJECT IDENTIFIER ::= { dtlstmConformance 1 } 2095 dtlstmGroups OBJECT IDENTIFIER ::= { dtlstmConformance 2 } 2097 -- ************************************************ 2098 -- Compliance statements 2099 -- ************************************************ 2101 dtlstmCompliance MODULE-COMPLIANCE 2102 STATUS current 2103 DESCRIPTION 2104 "The compliance statement for SNMP engines that support the 2105 SNMP-DTLS-TM-MIB" 2106 MODULE 2107 MANDATORY-GROUPS { dtlstmStatsGroup, 2108 dtlstmIncomingGroup, dtlstmOutgoingGroup } 2109 ::= { dtlstmCompliances 1 } 2111 -- ************************************************ 2112 -- Units of conformance 2113 -- ************************************************ 2114 dtlstmStatsGroup OBJECT-GROUP 2115 OBJECTS { 2116 dtlstmSessionOpens, 2117 dtlstmSessionCloses, 2118 dtlstmSessionOpenErrors, 2119 dtlstmSessionNoAvailableSessions, 2120 dtlstmSessionInvalidClientCertificates, 2121 dtlstmSessionInvalidServerCertificates, 2122 dtlstmDTLSProtectionErrors 2123 } 2124 STATUS current 2125 DESCRIPTION 2126 "A collection of objects for maintaining 2127 statistical information of an SNMP engine which 2128 implements the SNMP DTLS Transport Model." 2129 ::= { dtlstmGroups 1 } 2131 dtlstmIncomingGroup OBJECT-GROUP 2132 OBJECTS { 2133 dtlstmCertificateToSNCount, 2134 dtlstmCertificateToSNTableLastChanged, 2135 dtlstmCertIssuerDN, 2136 dtlstmCertMapType, 2137 dtlstmCertSecurityName, 2138 dtlstmCertStorageType, 2139 dtlstmCertRowStatus 2140 } 2141 STATUS current 2142 DESCRIPTION 2143 "A collection of objects for maintaining 2144 incoming connection certificate mappings to 2145 securityNames of an SNMP engine which implements the 2146 SNMP DTLS Transport Model." 2147 ::= { dtlstmGroups 2 } 2149 dtlstmOutgoingGroup OBJECT-GROUP 2150 OBJECTS { 2151 dtlstmParamsCount, 2152 dtlstmParamsTableLastChanged, 2153 dtlstmParamsSubject, 2154 dtlstmParamsStorageType, 2155 dtlstmParamsRowStatus 2156 } 2157 STATUS current 2158 DESCRIPTION 2159 "A collection of objects for maintaining 2160 outgoing connection certificates to use when opening 2161 connections as a result of SNMP-TARGET-MIB settings." 2162 ::= { dtlstmGroups 3 } 2164 END 2166 8. Operational Considerations 2168 This section discusses various operational aspects of the solution 2170 8.1. Sessions 2172 A session is discussed throughout this document as meaning a security 2173 association between the DTLS client and the DTLS server. State 2174 information for the sessions are maintained in each DTLSTM and this 2175 information is created and destroyed as sessions are opened and 2176 closed. Because of the connectionless nature of UDP, a "broken" 2177 session, one side up one side down, could result if one side of a 2178 session is brought down abruptly (i.e., reboot, power outage, etc.). 2179 Whenever possible, implementations SHOULD provide graceful session 2180 termination through the use of disconnect messages. Implementations 2181 SHOULD also have a system in place for dealing with "broken" 2182 sessions. Implementations SHOULD support the session resumption 2183 feature of TLS. 2185 To simplify session management it is RECOMMENDED that implementations 2186 utilize two separate ports, one for Notification sessions and one for 2187 Command sessions. If this implementation recommendation is followed, 2188 DTLS clients will always send REQUEST messages and DTLS servers will 2189 always send RESPONSE messages. With this assertion, implementations 2190 may be able to simplify "broken" session handling, session 2191 resumption, and other aspects of session management such as 2192 guaranteeing that Request- Response pairs use the same session. 2194 Depending on the algorithms used for generation of the master session 2195 secret, the privacy and integrity algorithms used to protect 2196 messages, the environment of the session, the amount of data 2197 transferred, and the sensitivity of the data, a time-to-live (TTL) 2198 value SHOULD be established for sessions. An upper limit of 24 hours 2199 is suggested for this TTL value. The TTL value could be stored in 2200 the LCD and checked before passing a message to the DTLS session. 2202 8.2. Notification Receiver Credential Selection 2204 When an SNMP engine needs to establish an outgoing session for 2205 notifications, the snmpTargetParamsTable includes an entry for the 2206 snmpTargetParamsSecurityName of the target. However, the receiving 2207 SNMP engine (Server) does not know which DTLS certificate to offer to 2208 the Client so that the tmSecurityName identity-authentication will be 2209 successful. The best solution would be to maintain a one-to-one 2210 mapping between certificates and incoming ports for notification 2211 receivers, although other implementation dependent mechanisms may be 2212 used instead. This can be handled at the Notification Originator by 2213 configuring the snmpTargetAddrTable (snmpTargetAddrTDomain and 2214 snmpTargetAddrTAddress) and then requiring the receiving SNMP engine 2215 to monitor multiple incoming static ports based on which principals 2216 are capable of receiving notifications. Implementations MAY also 2217 choose to designate a single Notification Receiver Principal to 2218 receive all incoming TRAPS and INFORMS. 2220 8.3. contextEngineID Discovery 2222 Because most Command Responders have contextEngineIDs that are 2223 identical to the USM securityEngineID, the USM provides Command 2224 Generators with the ability to discover a default contextEngineID to 2225 use. Because the DTLS transport does not make use of a discoverable 2226 securityEngineID like the USM does, it may be difficult for Command 2227 Generators to discover a suitable default contextEngineID. 2228 Implementations should consider offering another engineID discovery 2229 mechanism to continue providing Command Generators with a 2230 contextEngineID discovery mechanism. A recommended discovery 2231 solution is documented in [RFC5343]. 2233 9. Security Considerations 2235 This document describes a transport model that permits SNMP to 2236 utilize DTLS security services. The security threats and how the 2237 DTLS transport model mitigates these threats are covered in detail 2238 throughout this document. Security considerations for DTLS are 2239 covered in [RFC4347] and security considerations for TLS are 2240 described in Appendices D, E, and F of TLS 1.1 [RFC4346]. DTLS adds 2241 to the security considerations of TLS only because it is more 2242 vulnerable to denial of service attacks. A random cookie exchange 2243 was added to the handshake to prevent anonymous denial of service 2244 attacks. RFC 4347 recommends that the cookie exchange is utilized 2245 for all handshakes and therefore it is RECOMMENDED that implementers 2246 also support this cookie exchange. 2248 9.1. Certificates, Authentication, and Authorization 2250 Implementations are responsible for providing a security certificate 2251 configuration installation . Implementations SHOULD support 2252 certificate revocation lists and expiration of certificates or other 2253 access control mechanisms. 2255 DTLS provides for both authentication of the identity of the DTLS 2256 server and authentication of the identity of the DTLS client. Access 2257 to MIB objects for the authenticated principal MUST be enforced by an 2258 access control subsystem (e.g. the VACM). 2260 Authentication of the Command Generator principal's identity is 2261 important for use with the SNMP access control subsystem to ensure 2262 that only authorized principals have access to potentially sensitive 2263 data. The authenticated identity of the Command Generator 2264 principal's certificate is mapped to an SNMP model-independent 2265 securityName for use with SNMP access control, as discussed in 2266 Section 4.5.3.4, Section 7 and other sections. 2268 Furthermore, the DTLS handshake only provides assurance that the 2269 certificate of the authenticated identity has been signed by an 2270 configured accepted Certificate Authority. DTLS has no way to 2271 further authorize or reject access based on the authenticated 2272 identity. An Access Control Model (such as the VACM) provides access 2273 control and authorization of a Command Generator's requests to a 2274 Command Responder and a Notification Responder's authorization to 2275 receive Notifications from a Notification Originator. However to 2276 avoid man-in-the-middle attacks both ends of the DTLS based 2277 connection MUST check the certificate presented by the other side 2278 against what was expected. For example, Command Generators must 2279 check that the Command Responder presented and authenticated itself 2280 with a X.509 certificate that was expected. Not doing so would allow 2281 an impostor, at a minimum, to present false data, receive sensitive 2282 information and/or provide a false-positive belief that configuration 2283 was actually received and acted upon. Authenticating and verifying 2284 the identity of the DTLS server and the DTLS client for all 2285 operations ensures the authenticity of the SNMP engine that provides 2286 MIB data. 2288 9.2. Use with SNMPv1/SNMPv2c Messages 2290 The SNMPv1 and SNMPv2c message processing described in RFC3484 (BCP 2291 74) [RFC3584] always selects the SNMPv1(1) Security Model for an 2292 SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c 2293 message. When running SNMPv1/SNMPv2c over a secure transport like 2294 the DTLS Transport Model, the securityName and securityLevel used for 2295 access control decisions are then derived from the community string, 2296 not the authenticated identity and securityLevel provided by the DTLS 2297 Transport Model. 2299 9.3. MIB Module Security 2301 The MIB objects in this document should be protected with an adequate 2302 level of at least integrity protection, especially those objects 2303 which are writable. Since knowledge of authorization and certificate 2304 usage mechanisms may be considered sensitive, protection from 2305 disclosure of the SNMP traffic via encryption is also recommended. 2307 SNMP versions prior to SNMPv3 did not include adequate security. 2308 Even if the network itself is secure (for example by using IPSec or 2309 DTLS) there is no control as to who on the secure network is allowed 2310 to access and GET/SET (read/change/create/delete) the objects in this 2311 MIB module. 2313 It is RECOMMENDED that implementers consider the security features as 2314 provided by the SNMPv3 framework (see section 8 of [RFC3410]), 2315 including full support for the USM (see [RFC3414]) and the DTLS 2316 Transport Model cryptographic mechanisms (for authentication and 2317 privacy). 2319 10. IANA Considerations 2321 IANA is requested to assign: 2323 1. a UDP port number in the range 1..1023 in the 2324 http://www.iana.org/assignments/port-numbers registry which will 2325 be the default port for SNMP over a DTLS Transport Model as 2326 defined in this document, 2328 2. a UDP port number in the range 1..1023 in the 2329 http://www.iana.org/assignments/port-numbers registry which will 2330 be the default port for SNMPTRAP over a DTLS Transport Model as 2331 defined in this document, 2333 3. an SMI number under snmpDomains for the snmpDTLSDomain object 2334 identifier, 2336 4. a SMI number under snmpModules, for the MIB module in this 2337 document, 2339 5. "dtls" as the corresponding prefix for the snmpDTLSDomain in the 2340 SNMP Transport Model registry; 2342 11. Acknowledgements 2344 This document closely follows and copies the Secure Shell Transport 2345 Model for SNMP defined by David Harrington and Joseph Salowey in 2346 [I-D.ietf-isms-secshell]. 2348 This work was supported in part by the United States Department of 2349 Defense. Large portions of this document are based on work by 2350 General Dynamics C4 Systems and the following individuals: Brian 2351 Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John 2352 Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul, 2353 Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip. 2355 12. References 2357 12.1. Normative References 2359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2360 Requirement Levels", BCP 14, RFC 2119, March 1997. 2362 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2363 Protocol", RFC 2522, March 1999. 2365 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2366 Schoenwaelder, Ed., "Structure of Management Information 2367 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2369 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2370 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 2371 STD 58, RFC 2579, April 1999. 2373 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2374 "Conformance Statements for SMIv2", STD 58, RFC 2580, 2375 April 1999. 2377 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 2378 "Introduction and Applicability Statements for Internet- 2379 Standard Management Framework", RFC 3410, December 2002. 2381 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2382 Architecture for Describing Simple Network Management 2383 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2384 December 2002. 2386 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 2387 Management Protocol (SNMP) Applications", STD 62, 2388 RFC 3413, December 2002. 2390 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 2391 (USM) for version 3 of the Simple Network Management 2392 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 2394 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 2395 Access Control Model (VACM) for the Simple Network 2396 Management Protocol (SNMP)", STD 62, RFC 3415, 2397 December 2002. 2399 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 2400 Simple Network Management Protocol (SNMP)", STD 62, 2401 RFC 3418, December 2002. 2403 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 2404 "Coexistence between Version 1, Version 2, and Version 3 2405 of the Internet-standard Network Management Framework", 2406 BCP 74, RFC 3584, August 2003. 2408 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 2409 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2411 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2412 Security", RFC 4347, April 2006. 2414 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2415 Housley, R., and W. Polk, "Internet X.509 Public Key 2416 Infrastructure Certificate and Certificate Revocation List 2417 (CRL) Profile", RFC 5280, May 2008. 2419 [I-D.ietf-isms-transport-security-model] 2420 Harington, D., "Transport Security Model for SNMP". 2422 [I-D.ietf-isms-tmsm] 2423 Harington, D. and J. Schoenwaelder, "Transport Subsystem 2424 for the Simple Network Management Protocol (SNMP)". 2426 [X509] Rivest, R., Shamir, A., and L. M. Adleman, "A Method for 2427 Obtaining Digital Signatures and Public-Key 2428 Cryptosystems". 2430 [AES] National Institute of Standards, "Specification for the 2431 Advanced Encryption Standard (AES)". 2433 [DES] National Institute of Standards, "American National 2434 Standard for Information Systems-Data Link Encryption". 2436 [DSS] National Institute of Standards, "Digital Signature 2437 Standard". 2439 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 2440 Obtaining Digital Signatures and Public-Key 2441 Cryptosystems". 2443 12.2. Informative References 2445 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2446 December 2005. 2448 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2449 RFC 4303, December 2005. 2451 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2452 RFC 4306, December 2005. 2454 [I-D.ietf-isms-secshell] 2455 Harington, D. and J. Salowey, "Secure Shell Transport 2456 Model for SNMP". 2458 [RFC5343] Schoenwaelder, J., "Simple Network Management Protocol 2459 (SNMP) Context EngineID Discovery". 2461 [I-D.hodges-server-ident-check] 2462 Hodges, J. and B. Morgan, "Generic Server Identity Check". 2464 Appendix A. Target and Notificaton Configuration Example 2466 Configuring the SNMP-TARGET-MIB and NOTIFICATION-MIB along with 2467 access control settings for the SNMP-VIEW-BASED-ACM-MIB can be a 2468 daunting task without an example to follow. The following section 2469 describes an example of what pieces must be in place to accomplish 2470 this configuration. 2472 The isAccessAllowed() ASI requires configuration to exist in the 2473 following SNMP-VIEW-BASED-ACM-MIB tables: 2475 vacmSecurityToGroupTable 2476 vacmAccessTable 2477 vacmViewTreeFamilyTable 2479 The only table that needs to be discussed as particularly different 2480 here is the vacmSecurityToGroupTable. This table is indexed by both 2481 the SNMPv3 security model and the security name. The security model, 2482 when DTLSTM is in use, should be set to the value of XXX 2483 corresponding to the TSM [I-D.ietf-isms-transport-security-model]. 2484 An example vacmSecurityToGroupTable row might be filled out as 2485 follows (using a single SNMP SET request): 2487 vacmSecurityModel = XXX:TSM 2488 vacmSecurityName = "blueberry" 2489 vacmGroupaName = "administrators" 2490 vacmSecurityToGroupStorageType = 3 (nonVolatile) 2491 vacmSecurityToGroupStatus = 4 (createAndGo) 2493 Note to RFC editor: replace XXX with the actual IANA-assigned number 2494 for the TSM security model and remove this note. 2496 This example will assume that the "administrators" group has been 2497 given proper permissions via rows in the vacmAccessTable and 2498 vacmViewTreeFamilyTable. 2500 Depending on whether this VACM configuration is for a Command 2501 Responder or a Command Generator the security name "blueberry" will 2502 come from a few different locations. 2504 For Notification Generator's performing authorization checks, the 2505 server's certificate must be verified against the expected 2506 certificate before proceeding to send the notification. The 2507 securityName be set by the SNMP-TARGET-MIB's 2508 snmpTargetParamsSecurityName column or other configuration mechanism 2509 and the certificate to use would be taken from the appropriate entry 2510 in the dtlstmParamsTable. The dtlstmParamsTable augments the SNMP- 2511 TARGET-MIB's snmpTargetParamsTable with client-side certificate 2512 information. 2514 For Command Responder applications, the vacmSecurityName "blueberry" 2515 value is a value that needs to come from an incoming DTLS session. 2516 The mapping from a recevied DTLS client certificate to a securityName 2517 is done with the dtlstmCertificateToSNTable. The certificates must 2518 be loaded into the device so that a dtlstmCertificateToSNEntry may 2519 refer to it. As an example, consider the following entry which will 2520 provide a mapping from a X.509 Issuer's Distinguished Name directly 2521 to the "blueberry" securityName: 2523 dtlstmCertID = 1 (arbitrarily chosen) 2524 dtlstmCertIssuerDN = "C=US, ST=California, ..., CN=hardaker" 2525 dtlstmCertMapType = specified(1) 2526 dtlstmCertSecurityName = "blueberry" 2527 dtlstmCertStorageType = 3 (nonVolatile) 2528 dtlstmCertRowStatus = 4 (createAndGo) 2530 The above is an example of how to map a particular certificate to a 2531 particular securityName. It is recommended that users make use of 2532 direct CommonName mappings where possible since it will provide a 2533 more scalable approach to certificate management. If the following 2534 entry was created: 2536 dtlstmCertID = 1 (arbitrarily chosen) 2537 dtlstmCertIssuerDN = "C=US, ST=California, L=Davis, O=SuprIDs, ..." 2538 dtlstmCertMapType = byCN(2) 2539 dtlstmCertStorageType = 3 (nonVolatile) 2540 dtlstmCertRowStatus = 4 (createAndGo) 2542 The above entry indicates the CommonName field for that particular 2543 Issuer will be trusted to always produce common names that are 2544 directly 1 to 1 mappable into SNMPv3 securityNames. This type of 2545 configuration should only be used when the CA is carefully 2546 controlled. 2548 For the example, if the incoming DTLS client provided certificate 2549 contained a Subject with a CommonName of "blueberry" and the 2550 certificate was signed by the CA matching the dtlstmCertIssuerDN 2551 value above and the CA's certificate was properly installed on the 2552 device then the CommonName of "blueberry" would be used as the 2553 securityName for the session. 2555 Author's Address 2557 Wes Hardaker 2558 Sparta, Inc. 2559 P.O. Box 382 2560 Davis, CA 95617 2561 US 2563 Phone: +1 530 792 1913 2564 Email: ietf@hardakers.net 2566 Full Copyright Statement 2568 Copyright (C) The IETF Trust (2008). 2570 This document is subject to the rights, licenses and restrictions 2571 contained in BCP 78, and except as set forth therein, the authors 2572 retain all their rights. 2574 This document and the information contained herein are provided on an 2575 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2576 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2577 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2578 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2579 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2580 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2582 Intellectual Property 2584 The IETF takes no position regarding the validity or scope of any 2585 Intellectual Property Rights or other rights that might be claimed to 2586 pertain to the implementation or use of the technology described in 2587 this document or the extent to which any license under such rights 2588 might or might not be available; nor does it represent that it has 2589 made any independent effort to identify any such rights. Information 2590 on the procedures with respect to rights in RFC documents can be 2591 found in BCP 78 and BCP 79. 2593 Copies of IPR disclosures made to the IETF Secretariat and any 2594 assurances of licenses to be made available, or the result of an 2595 attempt made to obtain a general license or permission for the use of 2596 such proprietary rights by implementers or users of this 2597 specification can be obtained from the IETF on-line IPR repository at 2598 http://www.ietf.org/ipr. 2600 The IETF invites any interested party to bring to its attention any 2601 copyrights, patents or patent applications, or other proprietary 2602 rights that may cover technology that may be required to implement 2603 this standard. Please address the information to the IETF at 2604 ietf-ipr@ietf.org.