idnits 2.17.00 (12 Aug 2021) /tmp/idnits34329/draft-ietf-isms-dtls-tm-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 378 has weird spacing: '...patcher v ...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 30, 2009) is 4524 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) == Outdated reference: draft-saintandre-tls-server-id-check has been published as RFC 6125 -- No information found for draft-seggelmann-tls-dtls-heartbeat - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ISMS W. Hardaker 3 Internet-Draft Sparta, Inc. 4 Intended status: Standards Track December 30, 2009 5 Expires: July 3, 2010 7 Transport Layer Security (TLS) Transport Model for SNMP 8 draft-ietf-isms-dtls-tm-04.txt 10 Abstract 12 This document describes a Transport Model for the Simple Network 13 Management Protocol (SNMP), that uses either the Transport Layer 14 Security protocol or the Datagram Transport Layer Security (DTLS) 15 protocol. The TLS and DTLS protocols provide authentication and 16 privacy services for SNMP applications. This document describes how 17 the TLS Transport Model (TLSTM) implements the needed features of a 18 SNMP Transport Subsystem to make this protection possible in an 19 interoperable way. 21 This transport model is designed to meet the security and operational 22 needs of network administrators. It supports sending of SNMP 23 messages over TLS/TCP, DTLS/UDP and DTLS/SCTP. The TLS mode can make 24 use of TCP's improved support for larger packet sizes and the DTLS 25 mode provides potentially superior operation in environments where a 26 connectionless (e.g. UDP or SCTP) transport is preferred. Both TLS 27 and DTLS integrate well into existing public keying infrastructures. 29 This document also defines a portion of the Management Information 30 Base (MIB) for use with network management protocols. In particular 31 it defines objects for managing the TLS Transport Model for SNMP. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on July 3, 2010. 56 Copyright Notice 58 Copyright (c) 2009 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 87 2. The Transport Layer Security Protocol . . . . . . . . . . . . 8 88 3. How the TLSTM fits into the Transport Subsystem . . . . . . . 9 89 3.1. Security Capabilities of this Model . . . . . . . . . . . 10 90 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 10 91 3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12 92 3.1.3. (D)TLS Sessions . . . . . . . . . . . . . . . . . . . 13 93 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 13 94 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14 95 4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15 96 4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15 97 4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15 98 4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 16 100 4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 17 101 4.3.2. SNMP Services for an Incoming Message . . . . . . . . 18 102 4.4. Cached Information and References . . . . . . . . . . . . 18 103 4.4.1. TLS Transport Model Cached Information . . . . . . . . 19 104 4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 19 105 4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 19 106 4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 19 107 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20 108 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 20 109 5.1.1. DTLS Processing for Incoming Messages . . . . . . . . 20 110 5.1.2. Transport Processing for Incoming SNMP Messages . . . 22 111 5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 23 112 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 24 113 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 27 114 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 28 115 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 28 116 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 28 117 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 28 118 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 28 119 6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 29 120 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 29 121 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 29 122 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 29 123 8. Operational Considerations . . . . . . . . . . . . . . . . . . 51 124 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 51 125 8.2. Notification Receiver Credential Selection . . . . . . . . 51 126 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 52 127 8.4. Transport Considerations . . . . . . . . . . . . . . . . . 52 128 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 129 9.1. Certificates, Authentication, and Authorization . . . . . 53 130 9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 53 131 9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 54 132 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 133 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57 134 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 135 12.1. Normative References . . . . . . . . . . . . . . . . . . . 57 136 12.2. Informative References . . . . . . . . . . . . . . . . . . 58 137 Appendix A. (D)TLS Overview . . . . . . . . . . . . . . . . . . . 59 138 A.1. The (D)TLS Record Protocol . . . . . . . . . . . . . . . . 60 139 A.2. The (D)TLS Handshake Protocol . . . . . . . . . . . . . . 60 140 Appendix B. PKIX Certificate Infrastructure . . . . . . . . . . . 61 141 Appendix C. Target and Notificaton Configuration Example . . . . 62 142 C.1. Configuring the Notification Generator . . . . . . . . . . 63 143 C.2. Configuring the Command Responder . . . . . . . . . . . . 63 144 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64 146 1. Introduction 148 It is important to understand the modular SNMPv3 architecture as 149 defined by [RFC3411] and enhanced by the Transport Subsystem 150 [RFC5590]. It is also important to understand the terminology of the 151 SNMPv3 architecture in order to understand where the Transport Model 152 described in this document fits into the architecture and how it 153 interacts with the other architecture subsystems. For a detailed 154 overview of the documents that describe the current Internet-Standard 155 Management Framework, please refer to Section 7 of [RFC3410]. 157 This document describes a Transport Model that makes use of the 158 Transport Layer Security (TLS) [RFC5246] and the Datagram Transport 159 Layer Security (DTLS) Protocol [RFC4347], within a transport 160 subsystem [RFC5590]. DTLS is the datagram variant of the Transport 161 Layer Security (TLS) protocol [RFC5246]. The Transport Model in this 162 document is referred to as the Transport Layer Security Transport 163 Model (TLSTM). TLS and DTLS take advantage of the X.509 public 164 keying infrastructure [RFC5280]. While (D)TLS supports multiple 165 authentication mechanisms, this document only discusses X.509 166 certificate based authentication. Although other forms of 167 authentication are possible they are outside the scope of this 168 specification. This transport model is designed to meet the security 169 and operational needs of network administrators, operating in both 170 environments where a connectionless (e.g. UDP or SCTP) transport is 171 preferred and in environments where large quantities of data need to 172 be sent (e.g. over a TCP based stream). Both TLS and DTLS integrate 173 well into existing public keying infrastructures. This document 174 supports sending of SNMP messages over TLS/TCP, DTLS/UDP and DTLS/ 175 SCTP. 177 This document also defines a portion of the Management Information 178 Base (MIB) for use with network management protocols. In particular 179 it defines objects for managing the TLS Transport Model for SNMP. 181 Managed objects are accessed via a virtual information store, termed 182 the Management Information Base or MIB. MIB objects are generally 183 accessed through the Simple Network Management Protocol (SNMP). 184 Objects in the MIB are defined using the mechanisms defined in the 185 Structure of Management Information (SMI). This memo specifies a MIB 186 module that is compliant to the SMIv2, which is described in STD 58: 187 [RFC2578], [RFC2579] and [RFC2580]. 189 The diagram shown below gives a conceptual overview of two SNMP 190 entities communicating using the TLS Transport Model. One entity 191 contains a command responder and notification originator application, 192 and the other a command generator and notification responder 193 application. It should be understood that this particular mix of 194 application types is an example only and other combinations are 195 equally valid. Note: this diagram shows the Transport Security Model 196 (TSM) being used as the security model which is defined in [RFC5591]. 198 +----------------------------------------------------------------+ 199 | Network | 200 +----------------------------------------------------------------+ 201 ^ | ^ | 202 |Notifications |Commands |Commands |Notifications 203 +---|---------------------|--------+ +--|---------------|-------------+ 204 | | V | | | V | 205 | +------------+ +------------+ | | +-----------+ +----------+ | 206 | | (D)TLS | | (D)TLS | | | | (D)TLS | | (D)TLS | | 207 | | Service | | Service | | | | Service | | Service | | 208 | | (Client) | | (Server) | | | | (Client) | | (Server)| | 209 | +------------+ +------------+ | | +-----------+ +----------+ | 210 | ^ ^ | | ^ ^ | 211 | | | | | | | | 212 | +--+----------+ | | +-+--------------+ | 213 | +-----|---------+----+ | | +---|--------+----+ | 214 | | V |LCD | +-------+ | | | V |LCD | +--------+ | 215 | | +------+ +----+ | | | | | +------+ +----+ | | | 216 | | | TLS | <---------->| Cache | | | | | TLS | <---->| Cache | | 217 | | | TM | | | | | | | | TM | | | | | 218 | | +------+ | +-------+ | | | +------+ | +--------+ | 219 | |Transport Subsystem | ^ | | |Transport Sub. | ^ | 220 | +--------------------+ | | | +-----------------+ | | 221 | ^ +----+ | | ^ | | 222 | | | | | | | | 223 | v | | | V | | 224 | +-------+ +----------+ +-----+ | | | +-----+ +------+ +-----+ | | 225 | | | |Message | |Sec. | | | | | | | MP | |Sec. | | | 226 | | Disp. | |Processing| |Sub- | | | | |Disp.| | Sub- | |Sub- | | | 227 | | | |Subsystem | |sys. | | | | | | |system| |sys. | | | 228 | | | | | | | | | | | | | | | | | | 229 | | | | | |+---+| | | | | | | | |+---+| | | 230 | | | | +-----+ | || || | | | | | |+----+| || || | | 231 | | <--->|v3MP |<-->||TSM|<-+ | | | <-->|v3MP|<->|TSM|<-+ | 232 | | | | +-----+ | || || | | | | |+----+| || || | 233 | +-------+ | | |+---+| | | +-----+ | | |+---+| | 234 | ^ | | | | | | ^ | | | | | 235 | | +----------+ +-----+ | | | +------+ +-----+ | 236 | +-+------------+ | | +-+------------+ | 237 | ^ ^ | | ^ ^ | 238 | | | | | | | | 239 | v v | | V V | 240 | +-------------+ +--------------+ | | +-----------+ +--------------+ | 241 | | COMMAND | | NOTIFICATION | | | | COMMAND | | NOTIFICATION | | 242 | | RESPONDER | | ORIGINATOR | | | | GENERATOR | | RECEIVER | | 243 | | application | | application | | | |application| | application | | 244 | +-------------+ +--------------+ | | +-----------+ +--------------+ | 245 | SNMP entity | | SNMP entity | 246 +----------------------------------+ +--------------------------------+ 248 1.1. Conventions 250 For consistency with SNMP-related specifications, this document 251 favors terminology as defined in STD 62, rather than favoring 252 terminology that is consistent with non-SNMP specifications. This is 253 consistent with the IESG decision to not require the SNMPv3 254 terminology be modified to match the usage of other non-SNMP 255 specifications when SNMPv3 was advanced to Full Standard. 257 "Authentication" in this document typically refers to the English 258 meaning of "serving to prove the authenticity of" the message, not 259 data source authentication or peer identity authentication. 261 The terms "manager" and "agent" are not used in this document 262 because, in the RFC 3411 architecture, all SNMP entities have the 263 capability of acting as manager, agent, or both depending on the SNMP 264 application types supported in the implementation. Where distinction 265 is required, the application names of command generator, command 266 responder, notification originator, notification receiver, and proxy 267 forwarder are used. See "SNMP Applications" [RFC3413] for further 268 information. 270 Authentication in this document typically refers to the English 271 meaning of "serving to prove the authenticity of" the message, not 272 data source authentication or peer identity authentication. 274 The terms "manager" and "agent" are not used in this document, 275 because in the RFC 3411 architecture [RFC3411], all SNMP entities 276 have the capability of acting in either manager or agent or in both 277 roles depending on the SNMP application types supported in the 278 implementation. Where distinction is required, the application names 279 of command generator, command responder, notification originator, 280 Notification Receiver, and proxy forwarder are used. See "SNMP 281 Applications" [RFC3413] for further information. 283 Large portions of this document simultaneously refer to both TLS and 284 DTLS when discussing TLSTM components that function equally with 285 either protocol. "(D)TLS" is used in these places to indicate that 286 the statement applies to either or both protocols as appropriate. 287 When a distinction between the protocols is needed they are referred 288 to independently through the use of "TLS" or "DTLS". The Transport 289 Model, however, is named "TLS Transport Model" and refers not to the 290 TLS or DTLS protocol but to the standard defined in this document, 291 which includes support for both TLS and DTLS. 293 Throughout this document, the terms "client" and "server" are used to 294 refer to the two ends of the (D)TLS transport connection. The client 295 actively opens the (D)TLS connection, and the server passively 296 listens for the incoming (D)TLS connection. Either SNMP entity may 297 act as client or as server. 299 The User-Based Security Model (USM) [RFC3414] is a mandatory-to- 300 implement Security Model in STD 62. While (D)TLS and USM frequently 301 refer to a user, the terminology preferred in RFC3411 and in this 302 memo is "principal". A principal is the "who" on whose behalf 303 services are provided or processing takes place. A principal can be, 304 among other things, an individual acting in a particular role; a set 305 of individuals, with each acting in a particular role; an application 306 or a set of applications, or a combination of these within an 307 administrative domain. 309 Throughout this document, the term "session" is used to refer to a 310 secure association between two TLS Transport Models that permits the 311 transmission of one or more SNMP messages within the lifetime of the 312 session. The (D)TLS protocols also have an internal notion of a 313 session and although these two concepts of a session are related, 314 this document (unless otherwise specified) is referring to TLSTM's 315 specific session and not directly to the (D)TLS protocol's session. 317 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 318 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 319 document are to be interpreted as described in [RFC2119]. 321 2. The Transport Layer Security Protocol 323 (D)TLS provides authentication, data message integrity, and privacy 324 at the transport layer. (See [RFC4347]) 326 The primary goals of the TLS Transport Model are to provide privacy, 327 peer identity authentication and data integrity between two 328 communicating SNMP entities. The TLS and DTLS protocols provide a 329 secure transport upon which the TLSTM is based. An overview of 330 (D)TLS can be found in section Appendix A. Please refer to [RFC5246] 331 and [RFC4347] for complete descriptions of the protocols. 333 3. How the TLSTM fits into the Transport Subsystem 335 A transport model is a component of the Transport Subsystem. The TLS 336 Transport Model thus fits between the underlying (D)TLS transport 337 layer and the Message Dispatcher [RFC3411] component of the SNMP 338 engine and the Transport Subsystem. 340 The TLS Transport Model will establish a session between itself and 341 the TLS Transport Model of another SNMP engine. The sending 342 transport model passes unencrypted and unauthenticated messages from 343 the Dispatcher to (D)TLS to be encrypted and authenticated, and the 344 receiving transport model accepts decrypted and authenticated/ 345 integrity-checked incoming messages from (D)TLS and passes them to 346 the Dispatcher. 348 After a TLS Transport Model session is established, SNMP messages can 349 conceptually be sent through the session from one SNMP message 350 Dispatcher to another SNMP Message Dispatcher. If multiple SNMP 351 messages are needed to be passed between two SNMP applications they 352 MAY be passed through the same session. A TLSTM implementation 353 engine MAY choose to close a (D)TLS session to conserve resources. 355 The TLS Transport Model of an SNMP engine will perform the 356 translation between (D)TLS-specific security parameters and SNMP- 357 specific, model-independent parameters. 359 The diagram below depicts where the TLS Transport Model fits into the 360 architecture described in RFC3411 and the Transport Subsystem: 362 +------------------------------+ 363 | Network | 364 +------------------------------+ 365 ^ ^ ^ 366 | | | 367 v v v 368 +-------------------------------------------------------------------+ 369 | +--------------------------------------------------+ | 370 | | Transport Subsystem | +--------+ | 371 | | +-----+ +-----+ +-------+ +-------+ | | | | 372 | | | UDP | | SSH | |(D)TLS | . . . | other |<--->| Cache | | 373 | | | | | TM | | TM | | | | | | | 374 | | +-----+ +-----+ +-------+ +-------+ | +--------+ | 375 | +--------------------------------------------------+ ^ | 376 | ^ | | 377 | | | | 378 | Dispatcher v | | 379 | +--------------+ +---------------------+ +----------------+ | | 380 | | Transport | | Message Processing | | Security | | | 381 | | Dispatch | | Subsystem | | Subsystem | | | 382 | | | | +------------+ | | +------------+ | | | 383 | | | | +->| v1MP |<--->| | USM | | | | 384 | | | | | +------------+ | | +------------+ | | | 385 | | | | | +------------+ | | +------------+ | | | 386 | | | | +->| v2cMP |<--->| | Transport | | | | 387 | | Message | | | +------------+ | | | Security |<--+ | 388 | | Dispatch <---->| +------------+ | | | Model | | | 389 | | | | +->| v3MP |<--->| +------------+ | | 390 | | | | | +------------+ | | +------------+ | | 391 | | PDU Dispatch | | | +------------+ | | | Other | | | 392 | +--------------+ | +->| otherMP |<--->| | Model(s) | | | 393 | ^ | +------------+ | | +------------+ | | 394 | | +---------------------+ +----------------+ | 395 | v | 396 | +-------+-------------------------+---------------+ | 397 | ^ ^ ^ | 398 | | | | | 399 | v v v | 400 | +-------------+ +---------+ +--------------+ +-------------+ | 401 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | 402 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 403 | | application | | | | applications | | application | | 404 | +-------------+ +---------+ +--------------+ +-------------+ | 405 | ^ ^ | 406 | | | | 407 | v v | 408 | +----------------------------------------------+ | 409 | | MIB instrumentation | SNMP entity | 410 +-------------------------------------------------------------------+ 412 3.1. Security Capabilities of this Model 414 3.1.1. Threats 416 The TLS Transport Model provides protection against the threats 417 identified by the RFC 3411 architecture [RFC3411]: 419 1. Modification of Information - The modification threat is the 420 danger that an unauthorized entity may alter in-transit SNMP 421 messages generated on behalf of an authorized principal in such a 422 way as to effect unauthorized management operations, including 423 falsifying the value of an object. 425 (D)TLS provides verification that the content of each received 426 message has not been modified during its transmission through the 427 network, data has not been altered or destroyed in an 428 unauthorized manner, and data sequences have not been altered to 429 an extent greater than can occur non-maliciously. 431 2. Masquerade - The masquerade threat is the danger that management 432 operations unauthorized for a given principal may be attempted by 433 assuming the identity of another principal that has the 434 appropriate authorizations. 436 The TLSTM provides for verification of the identity of the (D)TLS 437 server through the use of the (D)TLS protocol and the X.509 438 certificates. The TLS Transport Model MUST support 439 authentication of both the server and the client. 441 3. Message stream modification - The re-ordering, delay or replay of 442 messages can and does occur through the natural operation of many 443 connectionless transport services. The message stream 444 modification threat is the danger that messages may be 445 maliciously re-ordered, delayed or replayed to an extent which is 446 greater than can occur through the natural operation of 447 connectionless transport services, in order to effect 448 unauthorized management operations. 450 (D)TLS provides replay protection with a MAC that includes a 451 sequence number. Since UDP provides no sequencing ability DTLS 452 uses a sliding window protocol with the sequence number for 453 replay protection (see [RFC4347]). 455 4. Disclosure - The disclosure threat is the danger of eavesdropping 456 on the exchanges between SNMP engines. 458 (D)TLS provides protection against the disclosure of information 459 to unauthorized recipients or eavesdroppers by allowing for 460 encryption of all traffic between SNMP engines. The TLS 461 Transport Model SHOULD support the message encryption to protect 462 sensitive data from eavesdropping attacks. 464 5. Denial of Service - the RFC 3411 architecture [RFC3411] states 465 that denial of service (DoS) attacks need not be addressed by an 466 SNMP security protocol. However, datagram-based security 467 protocols like DTLS are susceptible to a variety of denial of 468 service attacks because it is more vulnerable to spoofed 469 messages. 471 In order to counter these attacks, DTLS borrows the stateless 472 cookie technique used by Photuris [RFC2522] and IKEv2 [RFC4306] 473 and is described fully in section 4.2.1 of [RFC4347]. This 474 mechanism, though, does not provide any defense against denial of 475 service attacks mounted from valid IP addresses. DTLS Transport 476 Model server implementations MUST support DTLS cookies. 478 Implementations are not required to perform the stateless cookie 479 exchange for every DTLS handshake, but in environments where an 480 overload on server side resources is detectable by the 481 implementation it is RECOMMENDED that the cookie exchange is 482 utilized by the implementation. 484 See Section 9 for more detail on the security considerations 485 associated with the TLSTM and these security threats. 487 3.1.2. Message Protection 489 The RFC 3411 architecture recognizes three levels of security: 491 o without authentication and without privacy (noAuthNoPriv) 493 o with authentication but without privacy (authNoPriv) 495 o with authentication and with privacy (authPriv) 497 The TLS Transport Model determines from (D)TLS the identity of the 498 authenticated principal, and the type and address associated with an 499 incoming message. The TLS Transport Model provides the identity and 500 destination type and address to (D)TLS for outgoing messages. 502 When an application requests a session for a message, through the 503 cache, the application requests a security level for that session. 504 The TLS Transport Model MUST ensure that the (D)TLS session provides 505 security at least as high as the requested level of security. How 506 the security level is translated into the algorithms used to provide 507 data integrity and privacy is implementation-dependent. However, the 508 NULL integrity and encryption algorithms MUST NOT be used to fulfill 509 security level requests for authentication or privacy. 510 Implementations MAY choose to force (D)TLS to only allow 511 cipher_suites that provide both authentication and privacy to 512 guarantee this assertion. 514 If a suitable interface between the TLS Transport Model and the 515 (D)TLS Handshake Protocol is implemented to allow the selection of 516 security level dependent algorithms (for example a security level to 517 cipher_suites mapping table) then different security levels may be 518 utilized by the application. 520 The authentication, integrity and privacy algorithms used by the 521 (D)TLS Protocols may vary over time as the science of cryptography 522 continues to evolve and the development of (D)TLS continues over 523 time. Implementers are encouraged to plan for changes in operator 524 trust of particular algorithms. Implementations should offer 525 configuration settings for mapping algorithms to SNMPv3 security 526 levels. 528 3.1.3. (D)TLS Sessions 530 (D)TLS sessions are opened by the TLS Transport Model during the 531 elements of procedure for an outgoing SNMP message. Since the sender 532 of a message initiates the creation of a (D)TLS session if needed, 533 the (D)TLS session will already exist for an incoming message. 535 Implementations MAY choose to instantiate (D)TLS sessions in 536 anticipation of outgoing messages. This approach might be useful to 537 ensure that a (D)TLS session to a given target can be established 538 before it becomes important to send a message over the (D)TLS 539 session. Of course, there is no guarantee that a pre-established 540 session will still be valid when needed. 542 DTLS sessions, when used over UDP, are uniquely identified within the 543 TLS Transport Model by the combination of transportDomain, 544 transportAddress, tmSecurityName, and requestedSecurityLevel 545 associated with each session. Each unique combination of these 546 parameters MUST have a locally-chosen unique tlstmSessionID 547 associated for active sessions. For further information see 548 Section 5. TLS and DTLS over SCTP sessions, on the other hand, do 549 not require a unique pairing of address and port attributes since 550 their lower layer protocols (TCP and SCTP) already provide adequate 551 session framing. But they must still provide a unique tlstmSessionID 552 for referencing the session. 554 The tlstmSessionID MAY be the same as the (D)TLS internal SessionID 555 but caution must be exercised since the (D)TLS internal SessionID may 556 change over the life of the connection as seen by the TLSTM (for 557 example during renegotiation). The tlstmSessionID identifier MUST 558 NOT change during the entire duration of the connection from the 559 TLSTM's perspective. 561 3.2. Security Parameter Passing 563 For the (D)TLS server-side, (D)TLS-specific security parameters 564 (i.e., cipher_suites, X.509 certificate fields, IP address and port) 565 are translated by the TLS Transport Model into security parameters 566 for the TLS Transport Model and security model (e.g.., 567 tmSecurityLevel, tmSecurityName, transportDomain, transportAddress). 568 The transport- related and (D)TLS-security-related information, 569 including the authenticated identity, are stored in a cache 570 referenced by tmStateReference. 572 For the (D)TLS client-side, the TLS Transport Model takes input 573 provided by the Dispatcher in the sendMessage() Abstract Service 574 Interface (ASI) and input from the tmStateReference cache. The 575 (D)TLS Transport Model converts that information into suitable 576 security parameters for (D)TLS and establishes sessions as needed. 578 The elements of procedure in Section 5 discuss these concepts in much 579 greater detail. 581 3.3. Notifications and Proxy 583 (D)TLS sessions may be initiated by (D)TLS clients on behalf of SNMP 584 appplications that initiate communications, such as command 585 generators, notification originators, proxy forwarders. Command 586 generators are frequently operated by a human, but notification 587 originators and proxy forwarders are usually unmanned automated 588 processes. The targets to whom notifications and proxied requests 589 should be sent is typically determined and configured by a network 590 administrator. 592 The SNMP-TARGET-MIB module [RFC3413] contains objects for defining 593 management targets, including transportDomain, transportAddress, 594 securityName, securityModel, and securityLevel parameters, for 595 notification generator, proxy forwarder, and SNMP-controllable 596 command generator applications. Transport domains and transport 597 addresses are configured in the snmpTargetAddrTable, and the 598 securityModel, securityName, and securityLevel parameters are 599 configured in the snmpTargetParamsTable. This document defines a MIB 600 module that extends the SNMP-TARGET-MIB's snmpTargetParamsTable to 601 specify a (D)TLS client-side certificate to use for the connection. 603 When configuring a (D)TLS target, the snmpTargetAddrTDomain and 604 snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be 605 set to the snmpTLSTCPDomain, snmpDTLSUDPDomain, or snmpDTLSSCTPDomain 606 object and an appropriate snmpTLSAddress value. When used with the 607 SNMPv3 message processing model, the snmpTargetParamsMPModel column 608 of the snmpTargetParamsTable should be set to a value of 3. The 609 snmpTargetParamsSecurityName should be set to an appropriate 610 securityName value and the tlstmParamsClientFingerprint parameter of 611 the tlstmParamsTable should be set a value that refers to a locally 612 held certificate to be used. Other parameters, for example 613 cryptographic configuration such as cipher suites to use, must come 614 from configuration mechanisms not defined in this document. The 615 securityName defined in the snmpTargetParamsSecurityName column will 616 be used by the access control model to authorize any notifications 617 that need to be sent. 619 4. Elements of the Model 621 This section contains definitions required to realize the (D)TLS 622 Transport Model defined by this document. 624 4.1. X.509 Certificates 626 (D)TLS can make use of X.509 certificates for authentication of both 627 sides of the transport. This section discusses the use of X.509 628 certificates in the TLSTM. A brief overview of X.509 certificate 629 infrastructure can be found in Appendix B. 631 While (D)TLS supports multiple authentication mechanisms, this 632 document only discusses X.509 certificate based authentication. 633 Although other forms of authentication are possible they are outside 634 the scope of this specification. TLSTM implementations are REQUIRED 635 to support X.509 certificates. 637 4.1.1. Provisioning for the Certificate 639 Authentication using (D)TLS will require that SNMP entities are 640 provisioned with certificates, which are signed by trusted 641 certificate authorities (possibly the certificate itself). 642 Furthermore, SNMP entities will most commonly need to be provisioned 643 with root certificates which represent the list of trusted 644 certificate authorities that an SNMP entity can use for certificate 645 verification. SNMP entities SHOULD also be provisioned with a X.509 646 certificate revocation mechanism which can be used to verify that a 647 certificate has not been revoked. Trusted public keys from either CA 648 certificates and/or self-signed certificates, MUST be installed 649 through a trusted out of band mechanism into the server and its 650 authenticity MUST be verified before access is granted. 652 Having received a certificate from a connecting TLSTM client, the 653 authenticated tmSecurityName of the principal is derived using the 654 tlstmCertToTSNTable. This table allows mapping of incoming 655 connections to tmSecurityNames through defined transformations. The 656 transformations defined in the TLSTM-MIB include: 658 o Mapping a certificate's fingerprint type and value to a directly 659 specified tmSecurityName, or 661 o Mapping a certificate's subjectAltName or CommonName components to 662 a tmSecurityName. 664 Implementations MAY choose to discard any connections for which no 665 potential tlstmCertToTSNTable mapping exists before performing 666 certificate verification to avoid expending computational resources 667 associated with certificate verification. 669 Enterprise configurations are encouraged to map a "subjectAltName" 670 component of the X.509 certificate to the TLSTM specific 671 tmSecurityName. The authenticated identity can be obtained by the 672 TLS Transport Model by extracting the subjectAltName(s) from the 673 peer's certificate. The receiving application will then have an 674 appropriate tmSecurityName for use by other SNMPv3 components like an 675 access control model. 677 An example of this type of mapping setup can be found in Appendix C. 679 This tmSecurityName may be later translated from a TLSTM specific 680 tmSecurityName to a SNMP engine securityName by the security model. 681 A security model, like the TSM security model [RFC5591], may perform 682 an identity mapping or a more complex mapping to derive the 683 securityName from the tmSecurityName offered by the TLS Transport 684 Model. 686 A pictorial view of the complete transformation process (using the 687 TSM security model for the example) is shown below: 689 +-------------+ +-------+ +----------------+ +-----+ 690 | Certificate | | | | | | | 691 | Path | | TLSTM | | tmSecurityName | | TSM | 692 | Validation | --> | | --> | | --> | | 693 +-------------+ +-------+ +----------------+ +-----+ 694 | 695 V 696 +-------------+ +--------------+ 697 | application | <-- | securityName | 698 +-------------+ +--------------+ 700 4.2. Messages 702 As stated in Section 4.1.1 of [RFC4347], each DTLS record must fit 703 within a single DTLS datagram. The TLSTM SHOULD prohibit SNMP 704 messages from being sent that exceeds the maximum DTLS message size. 705 The TLSTM implementation SHOULD return an error when the DTLS message 706 size would be exceeded and the message won't be sent. 708 4.3. SNMP Services 710 This section describes the services provided by the TLS Transport 711 Model with their inputs and outputs. The services are between the 712 Transport Model and the Dispatcher. 714 The services are described as primitives of an abstract service 715 interface (ASI) and the inputs and outputs are described as abstract 716 data elements as they are passed in these abstract service 717 primitives. 719 4.3.1. SNMP Services for an Outgoing Message 721 The Dispatcher passes the information to the TLS Transport Model 722 using the ASI defined in the transport subsystem: 724 statusInformation = 725 sendMessage( 726 IN destTransportDomain -- transport domain to be used 727 IN destTransportAddress -- transport address to be used 728 IN outgoingMessage -- the message to send 729 IN outgoingMessageLength -- its length 730 IN tmStateReference -- reference to transport state 731 ) 733 The abstract data elements returned from or passed as parameters into 734 the abstract service primitives are as follows: 736 statusInformation: An indication of whether the passing of the 737 message was successful. If not, it is an indication of the 738 problem. 740 destTransportDomain: The transport domain for the associated 741 destTransportAddress. The Transport Model uses this parameter to 742 determine the transport type of the associated 743 destTransportAddress. This document specifies the snmpTLSDomain, 744 the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport 745 domains. 747 destTransportAddress: The transport address of the destination TLS 748 Transport Model in a format specified by the SnmpTLSAddress 749 TEXTUAL-CONVENTION. 751 outgoingMessage: The outgoing message to send to (D)TLS for 752 encapsulation. 754 outgoingMessageLength: The length of the outgoingMessage field. 756 tmStateReference: A handle/reference to tmState to be used when 757 securing outgoing messages. 759 4.3.2. SNMP Services for an Incoming Message 761 The TLS Transport Model processes the received message from the 762 network using the (D)TLS service and then passes it to the Dispatcher 763 using the following ASI: 765 statusInformation = 766 receiveMessage( 767 IN transportDomain -- origin transport domain 768 IN transportAddress -- origin transport address 769 IN incomingMessage -- the message received 770 IN incomingMessageLength -- its length 771 IN tmStateReference -- reference to transport state 772 ) 774 The abstract data elements returned from or passed as parameters into 775 the abstract service primitives are as follows: 777 statusInformation: An indication of whether the passing of the 778 message was successful. If not, it is an indication of the 779 problem. 781 transportDomain: The transport domain for the associated 782 transportAddress. This document specifies the snmpTLSDomain, the 783 snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport domains. 785 transportAddress: The transport address of the source of the 786 received message in a format specified by the SnmpTLSAddress 787 TEXTUAL-CONVENTION. 789 incomingMessage: The whole SNMP message after being processed by 790 (D)TLS and removed of the (D)TLS transport layer data. 792 incomingMessageLength: The length of the incomingMessage field. 794 tmStateReference: A handle/reference to tmSecurityData to be used by 795 the security model. 797 4.4. Cached Information and References 799 When performing SNMP processing, there are two levels of state 800 information that may need to be retained: the immediate state linking 801 a request-response pair, and potentially longer-term state relating 802 to transport and security. "Transport Subsystem for the Simple 803 Network Management Protocol" [RFC5590] defines general requirements 804 for caches and references. 806 4.4.1. TLS Transport Model Cached Information 808 The TLS Transport Model has specific responsibilities regarding the 809 cached information. See the Elements of Procedure in Section 5 for 810 detailed processing instructions on the use of the tmStateReference 811 fields by the TLS Transport Model 813 4.4.1.1. tmSecurityName 815 The tmSecurityName MUST be a human-readable name (in snmpAdminString 816 format) representing the identity that has been set according to the 817 procedures in Section 5. The tmSecurityName MUST be constant for all 818 traffic passing through an TLSTM session. Messages MUST NOT be sent 819 through an existing (D)TLS session that was established using a 820 different tmSecurityName. 822 On the (D)TLS server side of a connection the tmSecurityName is 823 derived using the procedures described in Section 5.3 and the TLSTM- 824 MIB's tlstmCertToTSNTable DESCRIPTION clause. 826 On the (D)TLS client side of a connection the tmSecurityName is 827 presented to the TLS Transport Model by the application (possibly 828 because of configuration specified in the SNMP-TARGET-MIB). 830 The securityName MAY be derived from the tmSecurityName by a Security 831 Model and MAY be used to configure notifications and access controls 832 in MIB modules. Transport Models SHOULD generate a predictable 833 tmSecurityName so operators will know what to use when configuring 834 MIB modules that use securityNames derived from tmSecurityNames. 836 4.4.1.2. tmSessionID 838 The tmSessionID MUST be recorded per message at the time of receipt. 839 When tmSameSecurity is set, the recorded tmSessionID can be used to 840 determine whether the (D)TLS session available for sending a 841 corresponding outgoing message is the same (D)TLS session as was used 842 when receiving the incoming message (e.g., a response to a request). 844 4.4.1.3. Session State 846 The per-session state that is referenced by tmStateReference may be 847 saved across multiple messages in a Local Configuration Datastore. 848 Additional session/connection state information might also be stored 849 in a Local Configuration Datastore. 851 5. Elements of Procedure 853 Abstract service interfaces have been defined by [RFC3411] and 854 further augmented by [RFC5590] to describe the conceptual data flows 855 between the various subsystems within an SNMP entity. The TLSTM uses 856 some of these conceptual data flows when communicating between 857 subsystems. 859 To simplify the elements of procedure, the release of state 860 information is not always explicitly specified. As a general rule, 861 if state information is available when a message gets discarded, the 862 message-state information should also be released. If state 863 information is available when a session is closed, the session state 864 information should also be released. Sensitive information, like 865 cryptographic keys, should be overwritten appropriately first prior 866 to being released. 868 An error indication in statusInformation will typically include the 869 Object Identifier (OID) and value for an incremented error counter. 870 This may be accompanied by the requested securityLevel and the 871 tmStateReference. Per-message context information is not accessible 872 to Transport Models, so for the returned counter OID and value, 873 contextEngine would be set to the local value of snmpEngineID and 874 contextName to the default context for error counters. 876 5.1. Procedures for an Incoming Message 878 This section describes the procedures followed by the (D)TLS 879 Transport Model when it receives a (D)TLS protected packet. The 880 steps are broken into two different sections. Section 5.1.1 881 describes the needed steps for de-multiplexing multiple DTLS 882 sessions, which is specifically needed for DTLS over UDP sessions. 883 Section 5.1.2 describes the steps specific to transport processing 884 once the (D)TLS processing has been completed. It is assumed that 885 TLS and DTLS/SCP protocol implementations already provide appropriate 886 message demultiplexing and only the processing steps in Section 5.1.2 887 are needed. 889 5.1.1. DTLS Processing for Incoming Messages 891 DTLS over UDP is significantly different in terms of session handling 892 than when TLS or DTLS is run over session based streaming protocols 893 like TCP or SCTP. Specifically, the DTLS protocol, when run over 894 UDP, does not have a session identifier that allows implementations 895 to determine through which session a packet arrived. It is always 896 critical, however, that implementations be able to derive a 897 tlstmSessionID from any session demultiplexing process. When 898 establishing a new session implementations MUST use a different UDP 899 source port number for each connection to a remote destination IP- 900 address/port-number combination to ensure the remote entity can 901 easily disambiguate between multiple sessions from a host to the same 902 port on a server. 904 A process for demultiplexing multiple DTLS sessions arriving over UDP 905 must be incorporated into the procedures for processing an incoming 906 message. The steps in this section describe one possible method to 907 accomplish this, although any implementation-dependent method should 908 be suitable as long as the results are deterministic. The important 909 output results from the steps in this process are the 910 transportDomain, the transportAddress, the wholeMessage, the 911 wholeMessageLength, and a unique implementation-dependent session 912 identifier (tlstmSessionID). 914 This demultiplexing procedure assumes that upon session establishment 915 an entry in a local transport mapping table is created in the 916 Transport Model's Local Configuration Datastore (LCD). The transport 917 mapping table's entry should map a unique combination of the remote 918 address, remote port number, local address and local port number to 919 an implementation-dependent tlstmSessionID. 921 1) The TLS Transport Model examines the raw UDP message, in an 922 implementation-dependent manner. 924 2) The TLS Transport Model queries the LCD using the transport 925 parameters (source and destination addresses and ports) to 926 determine if a session already exists and its tlstmSessionID. 928 If a matching entry in the LCD does not exist then the message is 929 passed to DTLS for processing without a corresponding 930 tlstmSessionID. The incoming packet may result in a new session 931 being established if the receiving entity is acting as a DTLS 932 server. If DTLS returns success then stop processing of this 933 message. If DTLS returns an error then increment the 934 snmpTlstmSessionNoSessions counter and stop processing the 935 message. 937 Note that an entry would already exist if the client and server's 938 session establishment procedures had been successfully completed 939 previously (as described both above and in Section 5.3) even if 940 no message had yet been sent through the newly established 941 session. An entry may not exist, however, if a message not 942 intended the SNMP entity was routed to it by mistake. An entry 943 might also be missing because of a "broken" session (see 944 operational considerations). 946 3) Retrieve the tlstmSessionID from the LCD. 948 4) The UDP packet and the tlstmSessionID are passed to DTLS for 949 integrity checking and decryption. 951 If the message fails integrity checks or other (D)TLS security 952 processing then increment the tlstmDTLSProtectionErrors counter, 953 discard and stop processing the message. 955 5) (D)TLS should return an incomingMessage and an 956 incomingMessageLength. These results and the tlstmSessionID are 957 used below in the Section 5.1.2 to complete the processing of the 958 incoming message. 960 5.1.2. Transport Processing for Incoming SNMP Messages 962 The procedures in this section describe how the TLS Transport Model 963 should process messages that have already been properly extracted 964 from the (D)TLS stream. Note that care must be taken when processing 965 messages originating from either TLS or DTLS to ensure they're 966 complete and single. For example, multiple SNMP messages can be 967 passed through a single DTLS message and partial SNMP messages may be 968 received from a TLS stream. These steps describe the processing of a 969 singular SNMP message after it has been delivered from the (D)TLS 970 stream. 972 Create a tmStateReference cache for the subsequent reference and 973 assign the following values within it: 975 tmTransportDomain = snmpTLSTCPDomain, snmpDTLSUDPDomain or 976 snmpDTLSSCTPDomain as appropriate. 978 tmTransportAddress = The address the message originated from. 980 tmSecurityLevel = The derived tmSecurityLevel for the session, as 981 discussed in Section 3.1.2 and Section 5.3. 983 tmSecurityName = The derived tmSecurityName for the session as 984 discussed in Section 5.3. This value MUST be constant during the 985 lifetime of the (D)TLS session. 987 tmSessionID = The tlstmSessionID, which MUST be a unique session 988 identifier for this (D)TLS connection. The contents and format of 989 this identifier are implementation-dependent as long as it is 990 unique to the session. A session identifier MUST NOT be reused 991 until all references to it are no longer in use. The tmSessionID 992 is equal to the tlstmSessionID discussed in Section 5.1.1. 993 tmSessionID refers to the session identifier when stored in the 994 tmStateReference and tlstmSessionID refers to the session 995 identifier when stored in the LCD. They MUST always be equal when 996 processing a given session's traffic. 998 The wholeMessage and the wholeMessageLength are assigned values from 999 the incomingMessage and incomingMessageLength values from the (D)TLS 1000 processing. 1002 The TLS Transport Model passes the transportDomain, transportAddress, 1003 wholeMessage, and wholeMessageLength to the Dispatcher using the 1004 receiveMessage ASI: 1006 statusInformation = 1007 receiveMessage( 1008 IN transportDomain -- snmpTLSTCPDomain, snmpDTLSUDPDomain, 1009 -- or snmpDTLSSCTPDomain 1010 IN transportAddress -- address for the received message 1011 IN wholeMessage -- the whole SNMP message from (D)TLS 1012 IN wholeMessageLength -- the length of the SNMP message 1013 IN tmStateReference -- transport info 1014 ) 1016 5.2. Procedures for an Outgoing SNMP Message 1018 The Dispatcher sends a message to the TLS Transport Model using the 1019 following ASI: 1021 statusInformation = 1022 sendMessage( 1023 IN destTransportDomain -- transport domain to be used 1024 IN destTransportAddress -- transport address to be used 1025 IN outgoingMessage -- the message to send 1026 IN outgoingMessageLength -- its length 1027 IN tmStateReference -- transport info 1028 ) 1030 This section describes the procedure followed by the TLS Transport 1031 Model whenever it is requested through this ASI to send a message. 1033 1) If tmStateReference does not refer to a cache containing values 1034 for tmTransportDomain, tmTransportAddress, tmSecurityName, 1035 tmRequestedSecurityLevel, and tmSameSecurity, then increment the 1036 snmpTlstmSessionInvalidCaches counter, discard the message, and 1037 return the error indication in the statusInformation. Processing 1038 of this message stops. 1040 2) Extract the tmSessionID, tmTransportDomain, tmTransportAddress, 1041 tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity 1042 values from the tmStateReference. Note: The tmSessionID value 1043 may be undefined if no session exists yet over which the message 1044 can be sent. 1046 3) If tmSameSecurity is true and either tmSessionID is undefined or 1047 refers to a session that is no longer open then increment the 1048 snmpTlstmSessionNoSessions counter, discard the message and 1049 return the error indication in the statusInformation. Processing 1050 of this message stops. 1052 4) If tmSameSecurity is false and tmSessionID refers to a session 1053 that is no longer available then an implementation SHOULD open a 1054 new session using the openSession() ASI (described in greater 1055 detail in step 4b). Instead of opening a new session an 1056 implementation MAY return a snmpTlstmSessionNoSessions error to 1057 the calling module and stop processing of the message. 1059 5) If tmSessionID is undefined, then use tmTransportDomain, 1060 tmTransportAddress, tmSecurityName and tmRequestedSecurityLevel 1061 to see if there is a corresponding entry in the LCD suitable to 1062 send the message over. 1064 4a) If there is a corresponding LCD entry, then this session 1065 will be used to send the message. 1067 4b) If there is not a corresponding LCD entry, then open a 1068 session using the openSession() ASI (discussed further in 1069 Section 5.3). Implementations MAY wish to offer message 1070 buffering to prevent redundant openSession() calls for the 1071 same cache entry. If an error is returned from 1072 openSession(), then discard the message, discard the 1073 tmStateReferenc, increment the snmpTlstmSessionOpenErrors, 1074 return an error indication to the calling module and stop 1075 processing of the message. 1077 6) Using either the session indicated by the tmSessionID if there 1078 was one or the session resulting from a previous step (3 or 4), 1079 pass the outgoingMessage to (D)TLS for encapsulation and 1080 transmission. 1082 5.3. Establishing a Session 1084 The TLS Transport Model provides the following primitive to establish 1085 a new (D)TLS session: 1087 statusInformation = -- errorIndication or success 1088 openSession( 1089 IN tmStateReference -- transport information to be used 1090 OUT tmStateReference -- transport information to be used 1091 IN maxMessageSize -- of the sending SNMP entity 1092 ) 1094 The following describes the procedure to follow when establishing a 1095 SNMP over (D)TLS session between SNMP engines for exchanging SNMP 1096 messages. This process is followed by any SNMP engine establishing a 1097 session for subsequent use. 1099 This MAY be done automatically for an SNMP application that initiates 1100 a transaction, such as a command generator, a notification 1101 originator, or a proxy forwarder. 1103 1) The client selects the appropriate certificate and cipher_suites 1104 for the key agreement based on the tmSecurityName and the 1105 tmRequestedSecurityLevel for the session. For sessions being 1106 established as a result of a SNMP-TARGET-MIB based operation, the 1107 certificate will potentially have been identified via the 1108 tlstmParamsTable mapping and the cipher_suites will have to be 1109 taken from system-wide or implementation-specific configuration. 1110 Otherwise, the certificate and appropriate cipher_suites will 1111 need to be passed to the openSession() ASI as supplemental 1112 information or configured through an implementation-dependent 1113 mechanism. It is also implementation-dependent and possibly 1114 policy-dependent how tmRequestedSecurityLevel will be used to 1115 influence the security capabilities provided by the (D)TLS 1116 session. However this is done, the security capabilities 1117 provided by (D)TLS MUST be at least as high as the level of 1118 security indicated by the tmRequestedSecurityLevel parameter. 1119 The actual security level of the session is reported in the 1120 tmStateReference cache as tmSecurityLevel. For (D)TLS to provide 1121 strong authentication, each principal acting as a command 1122 generator SHOULD have its own certificate. 1124 2) Using the destTransportDomain and destTransportAddress values, 1125 the client will initiate the (D)TLS handshake protocol to 1126 establish session keys for message integrity and encryption. 1128 If the attempt to establish a session is unsuccessful, then 1129 snmpTlstmSessionOpenErrors is incremented, an error indication is 1130 returned, and processing stops. If the session failed to open 1131 because the presented server certificate was unknown or invalid 1132 then the snmpTlstmSessionUnknownServerCertificate or 1133 snmpTlstmSessionInvalidServerCertificates MUST be incremented and 1134 a tlstmServerCertificateUnknown or tlstmServerInvalidCertificate 1135 notification SHOULD be sent as appropriate. Reasons for server 1136 certificate invalidation includes, but is not limited to, 1137 cryptographic validation failures and an unexpected presented 1138 certificate identity. 1140 3) Once a (D)TLS secured session is established and both sides have 1141 verified the authenticity of the peer's certificate (e.g. 1142 [RFC5280]) then each side will determine and/or check the 1143 identity of the remote entity using the procedures described 1144 below. 1146 a) The (D)TLS server side of the connection identifies the 1147 authenticated identity from the (D)TLS client's principal 1148 certificate using configuration information from the 1149 tlstmCertToTSNTable mapping table. The (D)TLS server MUST 1150 request and expect a certificate from the client and MUST NOT 1151 accept SNMP messages over the (D)TLS session until the client 1152 has sent a certificate and it has been authenticated. The 1153 resulting derived tmSecurityName is recorded in the 1154 tmStateReference cache as tmSecurityName. The details of the 1155 lookup process are fully described in the DESCRIPTION clause 1156 of the tlstmCertToTSNTable MIB object. If any verification 1157 fails in any way (for example because of failures in 1158 cryptographic verification or because of the lack of an 1159 appropriate row in the tlstmCertToTSNTable) then the session 1160 establishment MUST fail, the 1161 snmpTlstmSessionInvalidClientCertificates object is 1162 incremented and processing stops. 1164 b) The (D)TLS client side of the connection MUST verify that 1165 authenticated identity of the (D)TLS server's presented 1166 certificate is the expected certificate. The (D)TLS client 1167 MUST NOT transmit SNMP messages until the server certificate 1168 has been authenticated and the client certificate has been 1169 transmitted. 1171 If the connection is being established from configuration 1172 based on SNMP-TARGET-MIB configuration then the procedures in 1173 the tlstmAddrTable DESCRIPTION clause should be followed to 1174 determine if the presented identity matches the expectations 1175 of the configuration. Path validation procedures (like those 1176 defined in [RFC5280]) MUST be followed. If a server identity 1177 name has been configured in the tlstmAddrServerIdentity 1178 column then this reference identity must be compared against 1179 the presented identity (for example using procedures 1180 described in [I-D.saintandre-tls-server-id-check]). 1182 If the connection is being established for other reasons then 1183 configuration and procedures outside the scope of this 1184 document should be followed. 1186 (D)TLS provides assurance that the authenticated identity has 1187 been signed by a trusted configured certificate authority. 1188 If verification of the server's certificate fails in any way 1189 (for example because of failures in cryptographic 1190 verification or the presented identity did not match the 1191 expected named entity) then the session establishment MUST 1192 fail, the snmpTlstmSessionInvalidServerCertificates object is 1193 incremented and processing stops. 1195 4) The TLSTM-specific session identifier (tlstmSessionID) is set in 1196 the sessionID of the tmStateReference passed to the TLS Transport 1197 Model to indicate that the session has been established 1198 successfully and to point to a specific (D)TLS session for future 1199 use. 1201 Servers that wish to support multiple principals at a particular port 1202 SHOULD make use of the Server Name Indication extension defined in 1203 Section 3.1 of [RFC4366]. Supporting this will allow, for example, 1204 sending notifications to a specific principal at a given TCP, UDP or 1205 SCTP port. 1207 5.4. Closing a Session 1209 The TLS Transport Model provides the following primitive to close a 1210 session: 1212 statusInformation = 1213 closeSession( 1214 IN tmSessionID -- session ID of the session to be closed 1215 ) 1217 The following describes the procedure to follow to close a session 1218 between a client and server. This process is followed by any SNMP 1219 engine closing the corresponding SNMP session. 1221 1) Increment the snmpTlstmSessionCloses counter. 1223 2) Look up the session using the tmSessionID. 1225 3) If there is no open session associated with the tmSessionID, then 1226 closeSession processing is completed. 1228 4) Have (D)TLS close the specified session. This SHOULD include 1229 sending a close_notify TLS Alert to inform the other side that 1230 session cleanup may be performed. 1232 6. MIB Module Overview 1234 This MIB module provides management of the TLS Transport Model. It 1235 defines needed textual conventions, statistical counters, 1236 notifications and configuration infrastructure necessary for session 1237 establishment. Example usage of the configuration tables can be 1238 found in Appendix C. 1240 6.1. Structure of the MIB Module 1242 Objects in this MIB module are arranged into subtrees. Each subtree 1243 is organized as a set of related objects. The overall structure and 1244 assignment of objects to their subtrees, and the intended purpose of 1245 each subtree, is shown below. 1247 6.2. Textual Conventions 1249 Generic and Common Textual Conventions used in this module can be 1250 found summarized at http://www.ops.ietf.org/mib-common-tcs.html 1252 This module defines the following new Textual Conventions: 1254 o New TransportDomain and TransportAddress formats for describing 1255 (D)TLS connection addressing requirements. 1257 o A certificate fingerprint allowing MIB module objects to 1258 generically refer to a stored X.509 certificate using a 1259 cryptographic hash as a reference pointer. 1261 6.3. Statistical Counters 1263 The TLSTM-MIB defines some counters that can provide network managers 1264 with information about (D)TLS session usage and potential errors that 1265 a MIB-instrumented device may be experiencing. 1267 6.4. Configuration Tables 1269 The TLSTM-MIB defines configuration tables that a manager can use for 1270 configuring a MIB-instrumented device for sending and receiving SNMP 1271 messages over (D)TLS. In particular, there are MIB tables that 1272 extend the SNMP-TARGET-MIB for configuring (D)TLS certificate usage 1273 and a MIB table for mapping incoming (D)TLS client certificates to 1274 SNMPv3 securityNames. 1276 6.4.1. Notifications 1278 The TLSTM-MIB defines notifications to alert management stations when 1279 a (D)TLS connection fails because a server's presented certificate 1280 did not meet an expected value (tlstmServerCertificateUnknown) or 1281 because cryptographic validation failed 1282 (tlstmServerInvalidCertificate). 1284 6.5. Relationship to Other MIB Modules 1286 Some management objects defined in other MIB modules are applicable 1287 to an entity implementing the TLS Transport Model. In particular, it 1288 is assumed that an entity implementing the TLSTM-MIB will implement 1289 the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411], the SNMP- 1290 TARGET-MIB [RFC3413], the SNMP-NOTIFICATION-MIB [RFC3413] and the 1291 SNMP-VIEW-BASED-ACM-MIB [RFC3415]. 1293 The TLSTM-MIB module contained in this document is for managing TLS 1294 Transport Model information. 1296 6.5.1. MIB Modules Required for IMPORTS 1298 The TLSTM-MIB module imports items from SNMPv2-SMI [RFC2578], 1299 SNMPv2-TC [RFC2579], SNMP-FRAMEWORK-MIB [RFC3411], SNMP-TARGET-MIB 1300 [RFC3413] and SNMPv2-CONF [RFC2580]. 1302 7. MIB Module Definition 1304 TLSTM-MIB DEFINITIONS ::= BEGIN 1306 IMPORTS 1307 MODULE-IDENTITY, OBJECT-TYPE, 1308 OBJECT-IDENTITY, snmpModules, snmpDomains, 1309 Counter32, Unsigned32, NOTIFICATION-TYPE 1310 FROM SNMPv2-SMI 1311 TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType, 1312 AutonomousType 1313 FROM SNMPv2-TC 1314 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 1315 FROM SNMPv2-CONF 1316 SnmpAdminString 1317 FROM SNMP-FRAMEWORK-MIB 1318 snmpTargetParamsName, snmpTargetAddrName 1319 FROM SNMP-TARGET-MIB 1320 ; 1322 tlstmMIB MODULE-IDENTITY 1323 LAST-UPDATED "200912300000Z" 1324 ORGANIZATION "ISMS Working Group" 1325 CONTACT-INFO "WG-EMail: isms@lists.ietf.org 1326 Subscribe: isms-request@lists.ietf.org 1328 Chairs: 1329 Juergen Schoenwaelder 1330 Jacobs University Bremen 1331 Campus Ring 1 1332 28725 Bremen 1333 Germany 1334 +49 421 200-3587 1335 j.schoenwaelder@jacobs-university.de 1337 Russ Mundy 1338 SPARTA, Inc. 1339 7110 Samuel Morse Drive 1340 Columbia, MD 21046 1341 USA 1343 Co-editors: 1344 Wes Hardaker 1345 Sparta, Inc. 1346 P.O. Box 382 1347 Davis, CA 95617 1348 USA 1349 ietf@hardakers.net 1350 " 1352 DESCRIPTION " 1353 The TLS Transport Model MIB 1355 Copyright (c) 2009 IETF Trust and the persons identified as 1356 the document authors. All rights reserved. 1358 Redistribution and use in source and binary forms, with or 1359 without modification, is permitted pursuant to, and subject 1360 to the license terms contained in, the Simplified BSD License 1361 set forth in Section 4.c of the IETF Trust's Legal Provisions 1362 Relating to IETF Documents 1363 (http://trustee.ietf.org/license-info). 1365 This version of this MIB module is part of RFC XXXX; 1366 see the RFC itself for full legal notices." 1368 -- NOTE to RFC editor: replace XXXX with actual RFC number 1369 -- for this document and remove this note 1370 REVISION "200912300000Z" 1371 DESCRIPTION "The initial version, published in RFC XXXX." 1372 -- NOTE to RFC editor: replace XXXX with actual RFC number 1373 -- for this document and remove this note 1375 ::= { snmpModules xxxx } 1376 -- RFC Ed.: replace xxxx with IANA-assigned number and 1377 -- remove this note 1379 -- ************************************************ 1380 -- subtrees of the TLSTM-MIB 1381 -- ************************************************ 1383 tlstmNotifications OBJECT IDENTIFIER ::= { tlstmMIB 0 } 1384 tlstmIdentities OBJECT IDENTIFIER ::= { tlstmMIB 1 } 1385 tlstmObjects OBJECT IDENTIFIER ::= { tlstmMIB 2 } 1386 tlstmConformance OBJECT IDENTIFIER ::= { tlstmMIB 3 } 1388 -- ************************************************ 1389 -- tlstmObjects - Objects 1390 -- ************************************************ 1392 snmpTLSTCPDomain OBJECT-IDENTITY 1393 STATUS current 1394 DESCRIPTION 1395 "The SNMP over TLS transport domain. The corresponding 1396 transport address is of type SnmpTLSAddress. 1398 The securityName prefix to be associated with the 1399 snmpTLSTCPDomain is 'tls'. This prefix may be used by 1400 security models or other components to identify which secure 1401 transport infrastructure authenticated a securityName." 1403 ::= { snmpDomains xx } 1405 -- RFC Ed.: replace xx with IANA-assigned number and 1406 -- remove this note 1408 -- RFC Ed.: replace 'tls' with the actual IANA assigned prefix string 1409 -- if 'tls' is not assigned to this document. 1411 snmpDTLSUDPDomain OBJECT-IDENTITY 1412 STATUS current 1413 DESCRIPTION 1414 "The SNMP over DTLS/UDP transport domain. The corresponding 1415 transport address is of type SnmpTLSAddress. 1417 The securityName prefix to be associated with the 1418 snmpDTLSUDPDomain is 'dudp'. This prefix may be used by 1419 security models or other components to identify which secure 1420 transport infrastructure authenticated a securityName." 1422 ::= { snmpDomains yy } 1424 -- RFC Ed.: replace yy with IANA-assigned number and 1425 -- remove this note 1427 -- RFC Ed.: replace 'dudp' with the actual IANA assigned prefix string 1428 -- if 'dtls' is not assigned to this document. 1430 snmpDTLSSCTPDomain OBJECT-IDENTITY 1431 STATUS current 1432 DESCRIPTION 1433 "The SNMP over DTLS/SCTP transport domain. The corresponding 1434 transport address is of type SnmpTLSAddress. 1436 The securityName prefix to be associated with the 1437 snmpDTLSSCTPDomain is 'dsct'. This prefix may be used by 1438 security models or other components to identify which secure 1439 transport infrastructure authenticated a securityName." 1441 ::= { snmpDomains zz } 1443 -- RFC Ed.: replace zz with IANA-assigned number and 1444 -- remove this note 1446 -- RFC Ed.: replace 'dsct' with the actual IANA assigned prefix string 1447 -- if 'dtls' is not assigned to this document. 1449 SnmpTLSAddress ::= TEXTUAL-CONVENTION 1450 DISPLAY-HINT "1a" 1451 STATUS current 1452 DESCRIPTION 1453 "Represents a IPv4 address, an IPv6 address or an US-ASCII 1454 encoded hostname and port number. 1456 An IPv4 address must be in dotted decimal format followed by a 1457 colon ':' (US-ASCII character 0x3A) and a decimal port number 1458 in US-ASCII. 1460 An IPv6 address must be a colon separated format, surrounded 1461 by square brackets ('[', US-ASCII character 0x5B, and ']', 1462 US-ASCII character 0x5D), followed by a colon ':' (US-ASCII 1463 character 0x3A) and a decimal port number in US-ASCII. 1465 A hostname is always in US-ASCII (as per RFC1033); 1466 internationalized hostnames are encoded in US-ASCII as 1467 specified in RFC 3490. The hostname is followed by a colon 1468 ':' (US-ASCII character 0x3A) and a decimal port number in 1469 US-ASCII. The name SHOULD be fully qualified whenever 1470 possible. 1472 Values of this textual convention may not be directly usable 1473 as transport-layer addressing information, and may require 1474 run-time resolution. As such, applications that write them 1475 must be prepared for handling errors if such values are not 1476 supported, or cannot be resolved (if resolution occurs at the 1477 time of the management operation). 1479 The DESCRIPTION clause of TransportAddress objects that may 1480 have SnmpTLSAddress values must fully describe how (and 1481 when) such names are to be resolved to IP addresses and vice 1482 versa. 1484 This textual convention SHOULD NOT be used directly in object 1485 definitions since it restricts addresses to a specific 1486 format. However, if it is used, it MAY be used either on its 1487 own or in conjunction with TransportAddressType or 1488 TransportDomain as a pair. 1490 When this textual convention is used as a syntax of an index 1491 object, there may be issues with the limit of 128 1492 sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED 1493 that all MIB documents using this textual convention make 1494 explicit any limitations on index component lengths that 1495 management software must observe. This may be done either by 1496 including SIZE constraints on the index components or by 1497 specifying applicable constraints in the conceptual row 1498 DESCRIPTION clause or in the surrounding documentation." 1499 REFERENCE 1500 "RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE 1501 RFC 3490: Internationalizing Domain Names in Applications 1502 RFC 3986: Uniform Resource Identifier (URI): Generic Syntax 1503 RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 1504 " 1505 SYNTAX OCTET STRING (SIZE (1..255)) 1507 Fingerprint ::= TEXTUAL-CONVENTION 1508 DISPLAY-HINT "1x:254x" 1509 STATUS current 1510 DESCRIPTION 1511 "A Fingerprint value that can be used to uniquely reference 1512 other data of potentially arbitrary length. 1514 A Fingerprint value is composed of a 1-octet hashing algorithm 1515 identifier followed by the fingerprint value. The octet value 1516 encoded is taken from the IANA TLS HashAlgorithm Registry 1517 (RFC5246). The remaining octets are filled using the results 1518 of the hashing algorithm. 1520 This TEXTUAL-CONVENTION allows for a zero-length (blank) 1521 Fingerprint value for use in tables where the fingerprint value 1522 may be optional. MIB definitions or implementations may refuse 1523 to accept a zero-length value as appropriate." 1524 REFERENCE 1525 "RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 1526 " 1527 SYNTAX OCTET STRING (SIZE (0..255)) 1529 -- Identities 1531 tlstmCertToTSNMIdentities OBJECT IDENTIFIER ::= { tlstmIdentities 1 } 1533 tlstmCertSpecified OBJECT-IDENTITY 1534 STATUS current 1535 DESCRIPTION "Directly specifies the tmSecurityName to be used for 1536 this certificate. The value of the tmSecurityName to 1537 use is specified in the tlstmCertToTSNData column. 1538 The column must contain a SnmpAdminString compliant 1539 value or contains a zero length string then the 1540 mapping will be considered a failure." 1541 ::= { tlstmCertToTSNMIdentities 1 } 1543 tlstmCertSANRFC822Name OBJECT-IDENTITY 1544 STATUS current 1545 DESCRIPTION "Maps a subjectAltName's rfc822Name to a 1546 tmSecurityName. The local part of the rfc822Name is 1547 passed unaltered but the host-part of the name must 1548 be passed in lower case. 1550 Example rfc822Name Field: FooBar@Example.COM 1551 is mapped to tmSecurityName: FooBar@exmaple.com" 1552 ::= { tlstmCertToTSNMIdentities 2 } 1554 tlstmCertSANDNSName OBJECT-IDENTITY 1555 STATUS current 1556 DESCRIPTION "Maps a subjectAltName's dNSName to a 1557 tmSecurityName by directly passing the value without 1558 any transformations." 1560 ::= { tlstmCertToTSNMIdentities 3 } 1562 tlstmCertSANIpAddress OBJECT-IDENTITY 1563 STATUS current 1564 DESCRIPTION "Maps a subjectAltName's ipAddress to a 1565 tmSecurityName by transforming the binary encoded 1566 address as follows: 1568 1) for IPv4 the value is converted into a decimal 1569 dotted quad address (e.g. '192.0.2.1') 1571 2) for IPv6 addresses the value is converted into a 1572 32-character hexadecimal string without any colon 1573 separators. 1575 Note that the resulting length is the maximum 1576 length supported by the View-Based Access Control 1577 Model (VACM). Note that using both the Transport 1578 Security Model's support for transport prefixes 1579 (see the SNMP-TSM-MIB's 1580 snmpTsmConfigurationUsePrefix object for details) 1581 will result in securityName lengths that exceed 1582 what VACM can handle." 1583 ::= { tlstmCertToTSNMIdentities 4 } 1585 tlstmCertSANAny OBJECT-IDENTITY 1586 STATUS current 1587 DESCRIPTION "Maps any of the following fields using the 1588 corresponding mapping algorithms: 1590 |------------+------------------------| 1591 | Type | Algorithm | 1592 |------------+------------------------| 1593 | rfc822Name | tlstmCertSANRFC822Name | 1594 | dNSName | tlstmCertSANDNSName | 1595 | ipAddress | tlstmCertSANIpAddress | 1596 |------------+------------------------| 1598 The first matching subjectAltName value found in the 1599 certificate any of the above types MUST be used when 1600 deriving the tmSecurityName." 1601 ::= { tlstmCertToTSNMIdentities 5 } 1603 tlstmCertCommonName OBJECT-IDENTITY 1604 STATUS current 1605 DESCRIPTION "Maps a certificate's CommonName to a 1606 tmSecurityName by directly passing the value without 1607 any transformations." 1608 ::= { tlstmCertToTSNMIdentities 6 } 1610 -- The snmpTlstmSession Group 1612 snmpTlstmSession OBJECT IDENTIFIER ::= { tlstmObjects 1 } 1614 snmpTlstmSessionOpens OBJECT-TYPE 1615 SYNTAX Counter32 1616 MAX-ACCESS read-only 1617 STATUS current 1618 DESCRIPTION 1619 "The number of times an openSession() request has been 1620 executed as an (D)TLS client, whether it succeeded or failed." 1621 ::= { snmpTlstmSession 1 } 1623 snmpTlstmSessionCloses OBJECT-TYPE 1624 SYNTAX Counter32 1625 MAX-ACCESS read-only 1626 STATUS current 1627 DESCRIPTION 1628 "The number of times a closeSession() request has been 1629 executed as an (D)TLS client, whether it succeeded or failed." 1630 ::= { snmpTlstmSession 2 } 1632 snmpTlstmSessionOpenErrors OBJECT-TYPE 1633 SYNTAX Counter32 1634 MAX-ACCESS read-only 1635 STATUS current 1636 DESCRIPTION 1637 "The number of times an openSession() request failed to open a 1638 session as a (D)TLS client, for any reason." 1639 ::= { snmpTlstmSession 3 } 1641 snmpTlstmSessionNoSessions OBJECT-TYPE 1642 SYNTAX Counter32 1643 MAX-ACCESS read-only 1644 STATUS current 1645 DESCRIPTION 1646 "The number of times an outgoing message was dropped because 1647 the session associated with the passed tmStateReference was no 1648 longer (or was never) available." 1649 ::= { snmpTlstmSession 4 } 1651 snmpTlstmSessionInvalidClientCertificates OBJECT-TYPE 1652 SYNTAX Counter32 1653 MAX-ACCESS read-only 1654 STATUS current 1655 DESCRIPTION 1656 "The number of times an incoming session was not established 1657 on an (D)TLS server because the presented client certificate was 1658 invalid. Reasons for invalidation include, but are not 1659 limited to, cryptographic validation failures or lack of a 1660 suitable mapping row in the tlstmCertToTSNTable." 1661 ::= { snmpTlstmSession 5 } 1663 snmpTlstmSessionUnknownServerCertificate OBJECT-TYPE 1664 SYNTAX Counter32 1665 MAX-ACCESS read-only 1666 STATUS current 1667 DESCRIPTION 1668 "The number of times an outgoing session was not established 1669 on an (D)TLS client because the server certificate presented 1670 by a SNMP over (D)TLS server was invalid because no 1671 configured fingerprint or CA was acceptable to validate it. 1672 This may result because there was no entry in the 1673 tlstmAddrTable or because no path could be found to known 1674 certificate authority." 1675 ::= { snmpTlstmSession 6 } 1677 snmpTlstmSessionInvalidServerCertificates OBJECT-TYPE 1678 SYNTAX Counter32 1679 MAX-ACCESS read-only 1680 STATUS current 1681 DESCRIPTION 1682 "The number of times an outgoing session was not established 1683 on an (D)TLS client because the server certificate presented 1684 by an SNMP over (D)TLS server could not be validated even if 1685 the fingerprint or expected validation path was known. I.E., 1686 a cryptographic validation occurred during certificate 1687 validation processing. 1689 Reasons for invalidation include, but are not 1690 limited to, cryptographic validation failures." 1691 ::= { snmpTlstmSession 7 } 1693 snmpTlstmSessionInvalidCaches OBJECT-TYPE 1694 SYNTAX Counter32 1695 MAX-ACCESS read-only 1696 STATUS current 1697 DESCRIPTION 1698 "The number of outgoing messages dropped because the 1699 tmStateReference referred to an invalid cache." 1700 ::= { snmpTlstmSession 8 } 1702 tlstmTLSProtectionErrors OBJECT-TYPE 1703 SYNTAX Counter32 1704 MAX-ACCESS read-only 1705 STATUS current 1706 DESCRIPTION 1707 "The number of times (D)TLS processing resulted in a message 1708 being discarded because it failed its integrity test, 1709 decryption processing or other (D)TLS processing." 1710 ::= { snmpTlstmSession 9 } 1712 -- Configuration Objects 1714 tlstmConfig OBJECT IDENTIFIER ::= { tlstmObjects 2 } 1716 -- Certificate mapping 1718 tlstmCertificateMapping OBJECT IDENTIFIER ::= { tlstmConfig 1 } 1720 tlstmCertToTSNCount OBJECT-TYPE 1721 SYNTAX Unsigned32 1722 MAX-ACCESS read-only 1723 STATUS current 1724 DESCRIPTION 1725 "A count of the number of entries in the tlstmCertToTSNTable" 1726 ::= { tlstmCertificateMapping 1 } 1728 tlstmCertToTSNTableLastChanged OBJECT-TYPE 1729 SYNTAX TimeStamp 1730 MAX-ACCESS read-only 1731 STATUS current 1732 DESCRIPTION 1733 "The value of sysUpTime.0 when the tlstmCertToTSNTable 1734 was last modified through any means, or 0 if it has not been 1735 modified since the command responder was started." 1736 ::= { tlstmCertificateMapping 2 } 1738 tlstmCertToTSNTable OBJECT-TYPE 1739 SYNTAX SEQUENCE OF TlstmCertToTSNEntry 1740 MAX-ACCESS not-accessible 1741 STATUS current 1742 DESCRIPTION 1743 "A table listing the X.509 certificates known to the entity 1744 and the associated method for determining the SNMPv3 security 1745 name from a certificate. 1747 On an incoming (D)TLS/SNMP connection the client's presented 1748 certificate must be examined and validated based on an 1749 established trusted path from a CA certificate or self-signed 1750 public certificate (e.g. RFC5280). This table provides a 1751 mapping from a validated certificate to a tmSecurityName. 1752 This table does not provide any mechanisms for uploading 1753 trusted certificates; the transfer of any needed trusted 1754 certificates for path validation is expected to occur through 1755 an out-of-band transfer. 1757 Once the authenticity of a certificate has been verified, this 1758 table is consulted to determine the appropriate tmSecurityName 1759 to identify with the remote connection. This is done by 1760 considering each active row from this table in prioritized 1761 order according to its tlstmCertToTSNID value. Each row's 1762 tlstmCertToTSNFingerprint value determines whether the row is a 1763 match for the incoming connection: 1765 1) If the row's tlstmCertToTSNFingerprint value identifies 1766 the presented certificate then consider the row as a 1767 successful match. 1769 2) If the row's tlstmCertToTSNFingerprint value identifies 1770 a locally held copy of a trusted CA certificate and 1771 that CA certificated was used to validate the path to 1772 the presented certificate then consider the row as a 1773 successful match. 1775 Once a matching row has been found, the tlstmCertToTSNMapType 1776 value can be used to determine how the tmSecurityName to 1777 associate with the session should be determined. See the 1778 tlstmCertToTSNMapType column's DESCRIPTION for details on 1779 determining the tmSecurityName value. If it is impossible to 1780 determine a tmSecurityName from the row's data combined with the 1781 data presented in the certificate then additional rows MUST be 1782 searched looking for another potential match. If a resulting 1783 tmSecurityName mapped from a given row is not compatible with 1784 the needed requirements of a tmSecurityName (e.g., VACM imposes 1785 a 32-octet-maximum length and the certificate derived 1786 securityName could be longer) then it must be considered an 1787 invalid match and additional rows MUST be searched looking for 1788 another potential match. 1790 Missing values of tlstmCertToTSNID are acceptable and 1791 implementations should continue to the next highest numbered 1792 row. E.G., the table may legally contain only two rows with 1793 tlstmCertToTSNID values of 10 and 20. 1795 Users are encouraged to make use of certificates with 1796 subjectAltName fields that can be used as tmSecurityNames so 1797 that a single root CA certificate can allow all child 1798 certificate's subjectAltName to map directly to a tmSecurityName 1799 via a 1:1 transformation. However, this table is flexible to 1800 allow for situations where existing deployed certificate 1801 infrastructures do not provide adequate subjectAltName values 1802 for use as tmSecurityNames. Certificates may also be 1803 mapped to tmSecurityNames using the CommonName portion of the 1804 Subject field but usage of the CommonName field is deprecated. 1805 Direct mapping from each individual certificate fingerprint to 1806 a tmSecurityName is also possible but requires one entry in the 1807 table per tmSecurityName and requires more management operations 1808 to completely configure a device." 1809 ::= { tlstmCertificateMapping 3 } 1811 tlstmCertToTSNEntry OBJECT-TYPE 1812 SYNTAX TlstmCertToTSNEntry 1813 MAX-ACCESS not-accessible 1814 STATUS current 1815 DESCRIPTION 1816 "A row in the tlstmCertToTSNTable that specifies a mapping for 1817 an incoming (D)TLS certificate to a tmSecurityName to use for a 1818 connection." 1819 INDEX { tlstmCertToTSNID } 1820 ::= { tlstmCertToTSNTable 1 } 1822 TlstmCertToTSNEntry ::= SEQUENCE { 1823 tlstmCertToTSNID Unsigned32, 1824 tlstmCertToTSNFingerprint Fingerprint, 1825 tlstmCertToTSNMapType AutonomousType, 1826 tlstmCertToTSNData OCTET STRING, 1827 tlstmCertToTSNStorageType StorageType, 1828 tlstmCertToTSNRowStatus RowStatus 1829 } 1831 tlstmCertToTSNID OBJECT-TYPE 1832 SYNTAX Unsigned32 (1..4294967295) 1833 MAX-ACCESS not-accessible 1834 STATUS current 1835 DESCRIPTION 1836 "A unique, prioritized index for the given entry." 1837 ::= { tlstmCertToTSNEntry 1 } 1839 tlstmCertToTSNFingerprint OBJECT-TYPE 1840 SYNTAX Fingerprint (SIZE(1..255)) 1841 MAX-ACCESS read-create 1842 STATUS current 1843 DESCRIPTION 1844 "A cryptographic hash of a X.509 certificate. The results of 1845 a successful matching fingerprint to either the trusted CA in 1846 the certificate validation path or to the certificate itself 1847 is dictated by the tlstmCertToTSNMapType column." 1848 ::= { tlstmCertToTSNEntry 2 } 1850 tlstmCertToTSNMapType OBJECT-TYPE 1851 SYNTAX AutonomousType 1852 MAX-ACCESS read-create 1853 STATUS current 1854 DESCRIPTION 1855 "Specifies the mapping type for deriving a tmSecurityName from a 1856 certificate. Details for mapping of a particular type SHALL 1857 be specified in the DESCRIPTION clause of the OBJECT-IDENTITY 1858 that describes the mapping. If a mapping succeeds it will 1859 return a tmSecurityName for use by the TLSTM model and 1860 processing stops. 1862 If the resulting mapped value is not compatible with the 1863 needed requirements of a tmSecurityName (e.g., VACM imposes a 1864 32-octet-maximum length and the certificate derived 1865 securityName could be longer) then future rows MUST be 1866 searched for additional tlstmCertToTSNFingerprint matches to 1867 look for a mapping that succeeds." 1868 DEFVAL { tlstmCertSpecified } 1869 ::= { tlstmCertToTSNEntry 3 } 1871 tlstmCertToTSNData OBJECT-TYPE 1872 SYNTAX OCTET STRING (SIZE(0..1024)) 1873 MAX-ACCESS read-create 1874 STATUS current 1875 DESCRIPTION 1876 "Axillary data used as optional configuration information for 1877 a given mapping specified by the tlstmCertToTSNMapType column. 1878 Only some mapping systems will make use of this column. The 1879 value in this column MUST be ignored for any mapping type that 1880 does not require data present in this column." 1881 DEFVAL { "" } 1882 ::= { tlstmCertToTSNEntry 4 } 1884 tlstmCertToTSNStorageType OBJECT-TYPE 1885 SYNTAX StorageType 1886 MAX-ACCESS read-create 1887 STATUS current 1888 DESCRIPTION 1889 "The storage type for this conceptual row. Conceptual rows 1890 having the value 'permanent' need not allow write-access to 1891 any columnar objects in the row." 1892 DEFVAL { nonVolatile } 1893 ::= { tlstmCertToTSNEntry 5 } 1895 tlstmCertToTSNRowStatus OBJECT-TYPE 1896 SYNTAX RowStatus 1897 MAX-ACCESS read-create 1898 STATUS current 1899 DESCRIPTION 1900 "The status of this conceptual row. This object may be used 1901 to create or remove rows from this table. 1903 To create a row in this table, a manager must set this object 1904 to either createAndGo(4) or createAndWait(5). 1906 Until instances of all corresponding columns are appropriately 1907 configured, the value of the corresponding instance of the 1908 tlstmParamsRowStatus column is 'notReady'. 1910 In particular, a newly created row cannot be made active until 1911 the corresponding tlstmCertToTSNFingerprint, 1912 tlstmCertToTSNMapType, and tlstmCertToTSNData columns have been 1913 set. 1915 The following objects may not be modified while the 1916 value of this object is active(1): 1917 - tlstmCertToTSNFingerprint 1918 - tlstmCertToTSNMapType 1919 - tlstmCertToTSNData 1920 An attempt to set these objects while the value of 1921 tlstmParamsRowStatus is active(1) will result in 1922 an inconsistentValue error." 1923 ::= { tlstmCertToTSNEntry 6 } 1925 -- Maps tmSecurityNames to certificates for use by the SNMP-TARGET-MIB 1927 tlstmParamsCount OBJECT-TYPE 1928 SYNTAX Unsigned32 1929 MAX-ACCESS read-only 1930 STATUS current 1931 DESCRIPTION 1932 "A count of the number of entries in the tlstmParamsTable" 1933 ::= { tlstmCertificateMapping 4 } 1935 tlstmParamsTableLastChanged OBJECT-TYPE 1936 SYNTAX TimeStamp 1937 MAX-ACCESS read-only 1938 STATUS current 1939 DESCRIPTION 1940 "The value of sysUpTime.0 when the tlstmParamsTable 1941 was last modified through any means, or 0 if it has not been 1942 modified since the command responder was started." 1944 ::= { tlstmCertificateMapping 5 } 1946 tlstmParamsTable OBJECT-TYPE 1947 SYNTAX SEQUENCE OF TlstmParamsEntry 1948 MAX-ACCESS not-accessible 1949 STATUS current 1950 DESCRIPTION 1951 "This table extends the SNMP-TARGET-MIB's 1952 snmpTargetParamsTable with an additional (D)TLS client-side 1953 certificate fingerprint identifier to use when establishing 1954 new (D)TLS connections." 1955 ::= { tlstmCertificateMapping 6 } 1957 tlstmParamsEntry OBJECT-TYPE 1958 SYNTAX TlstmParamsEntry 1959 MAX-ACCESS not-accessible 1960 STATUS current 1961 DESCRIPTION 1962 "A conceptual row containing a fingerprint hash of a locally 1963 held certificate for a given snmpTargetParamsEntry. The 1964 values in this row should be ignored if the connection that 1965 needs to be established, as indicated by the SNMP-TARGET-MIB 1966 infrastructure, is not a certificate and (D)TLS based 1967 connection. The connection SHOULD NOT be established if the 1968 certificate fingerprint stored in this entry does not point to 1969 a valid locally held certificate or if it points to an unusable 1970 certificate (such as might happen when the certificate's 1971 expiration date has been reached)." 1972 INDEX { IMPLIED snmpTargetParamsName } 1973 ::= { tlstmParamsTable 1 } 1975 TlstmParamsEntry ::= SEQUENCE { 1976 tlstmParamsClientFingerprint Fingerprint, 1977 tlstmParamsStorageType StorageType, 1978 tlstmParamsRowStatus RowStatus 1979 } 1981 tlstmParamsClientFingerprint OBJECT-TYPE 1982 SYNTAX Fingerprint 1983 MAX-ACCESS read-create 1984 STATUS current 1985 DESCRIPTION 1986 "A cryptographic hash of a X.509 certificate. This object 1987 should store the hash of a locally held X.509 certificate that 1988 should be used when initiating a (D)TLS connection as a (D)TLS 1989 client." 1990 ::= { tlstmParamsEntry 1 } 1992 tlstmParamsStorageType OBJECT-TYPE 1993 SYNTAX StorageType 1994 MAX-ACCESS read-create 1995 STATUS current 1996 DESCRIPTION 1997 "The storage type for this conceptual row. Conceptual rows 1998 having the value 'permanent' need not allow write-access to 1999 any columnar objects in the row." 2000 DEFVAL { nonVolatile } 2001 ::= { tlstmParamsEntry 2 } 2003 tlstmParamsRowStatus OBJECT-TYPE 2004 SYNTAX RowStatus 2005 MAX-ACCESS read-create 2006 STATUS current 2007 DESCRIPTION 2008 "The status of this conceptual row. This object may be used 2009 to create or remove rows from this table. 2011 To create a row in this table, a manager must set this object 2012 to either createAndGo(4) or createAndWait(5). 2014 Until instances of all corresponding columns are appropriately 2015 configured, the value of the corresponding instance of the 2016 tlstmParamsRowStatus column is 'notReady'. 2018 In particular, a newly created row cannot be made active until 2019 the corresponding tlstmParamsClientFingerprint column has 2020 been set. 2022 The tlstmParamsClientFingerprint object may not be modified 2023 while the value of this object is active(1). 2025 An attempt to set these objects while the value of 2026 tlstmParamsRowStatus is active(1) will result in 2027 an inconsistentValue error. 2029 If this row is deleted it has no effect on the corresponding 2030 row in the targetParamsTable. 2032 If the corresponding row in the targetParamsTable is deleted 2033 then this row must be automatically removed." 2034 ::= { tlstmParamsEntry 3 } 2036 -- Lists expected certificate fingerprints to be presented by a DTLS 2037 -- server 2038 tlstmAddrCount OBJECT-TYPE 2039 SYNTAX Unsigned32 2040 MAX-ACCESS read-only 2041 STATUS current 2042 DESCRIPTION 2043 "A count of the number of entries in the tlstmAddrTable" 2044 ::= { tlstmCertificateMapping 7 } 2046 tlstmAddrTableLastChanged OBJECT-TYPE 2047 SYNTAX TimeStamp 2048 MAX-ACCESS read-only 2049 STATUS current 2050 DESCRIPTION 2051 "The value of sysUpTime.0 when the tlstmAddrTable 2052 was last modified through any means, or 0 if it has not been 2053 modified since the command responder was started." 2054 ::= { tlstmCertificateMapping 8 } 2056 tlstmAddrTable OBJECT-TYPE 2057 SYNTAX SEQUENCE OF TlstmAddrEntry 2058 MAX-ACCESS not-accessible 2059 STATUS current 2060 DESCRIPTION 2061 "This table extends the SNMP-TARGET-MIB's snmpTargetAddrTable 2062 with an expected (D)TLS server-side certificate identifier to 2063 expect when establishing a new (D)TLS connections. If a 2064 matching row in this table exists and the row is active then 2065 the fingerprint identifier from the tlstmAddrServerFingerprint 2066 columnshould be compared against the fingerprint of the 2067 certificate being presented by the server. If the fingerprint 2068 of the certificate presented by the server does not match the 2069 tlstmAddrServerFingerprint column's value then the connection 2070 MUST NOT be established. 2072 If a matching row exists with a zero-length 2073 tlstmAddrServerFingerprint value and the certificate can still 2074 be validated through another certificate validation path 2075 (e.g. RFC5280) then the server's presented identity should be 2076 checked against the value of the tlstmAddrServerIdentity 2077 column. If the server's identity does not match the reference 2078 identity found in the tlstmAddrServerIdentity column then the 2079 connection MUST NOT be established. A tlstmAddrServerIdentity 2080 may contain a '*' to match any server's identity or may 2081 contain a '*.' prefix to match any server identity from a 2082 given domain (e.g. '*.example.com'). 2084 If no matching row exists in this table then the connection 2085 SHOULD still proceed if another certificate validation path 2086 algorithm (e.g. RFC5280) can be followed to a configured trust 2087 anchor." 2088 ::= { tlstmCertificateMapping 9 } 2090 tlstmAddrEntry OBJECT-TYPE 2091 SYNTAX TlstmAddrEntry 2092 MAX-ACCESS not-accessible 2093 STATUS current 2094 DESCRIPTION 2095 "A conceptual row containing a copy of a certificate's 2096 fingerprint for a given snmpTargetAddrEntry. The values in 2097 this row should be ignored if the connection that needs to be 2098 established, as indicated by the SNMP-TARGET-MIB 2099 infrastructure, is not a (D)TLS based connection. If an 2100 tlstmAddrEntry exists for a given snmpTargetAddrEntry then the 2101 presented server certificate MUST match or the connection MUST 2102 NOT be established. If a row in this table does not exist to 2103 match a snmpTargetAddrEntry row then the connection SHOULD 2104 still proceed if some other certificate validation path 2105 algorithm (e.g. RFC5280) can be followed to a configured trust 2106 anchor." 2107 INDEX { IMPLIED snmpTargetAddrName } 2108 ::= { tlstmAddrTable 1 } 2110 TlstmAddrEntry ::= SEQUENCE { 2111 tlstmAddrServerFingerprint Fingerprint, 2112 tlstmAddrServerIdentity SnmpAdminString, 2113 tlstmAddrStorageType StorageType, 2114 tlstmAddrRowStatus RowStatus 2115 } 2117 tlstmAddrServerFingerprint OBJECT-TYPE 2118 SYNTAX Fingerprint 2119 MAX-ACCESS read-create 2120 STATUS current 2121 DESCRIPTION 2122 "A cryptographic hash of a public X.509 certificate. This 2123 object should store the hash of the public X.509 certificate 2124 that the remote server should present during the (D)TLS 2125 connection setup. The fingerprint of the presented 2126 certificate and this hash value MUST match exactly or the 2127 connection MUST NOT be established." 2128 DEFVAL { "" } 2129 ::= { tlstmAddrEntry 1 } 2131 tlstmAddrServerIdentity OBJECT-TYPE 2132 SYNTAX SnmpAdminString 2133 MAX-ACCESS read-create 2134 STATUS current 2135 DESCRIPTION 2136 "The reference identity to check against the identity 2137 presented by the remote system. A single ASCII '*' character 2138 (ASCII code 0x2a) may be used as a wildcard string and will 2139 match any presented server identity. A '*.' prefix may also 2140 be used to match any identity within a given domain 2141 (e.g. '*.example.com' will match both 'foo.example.com' and 2142 'bar.example.com')." 2143 REFERENCE "draft-saintandre-tls-server-id-check" 2144 DEFVAL { "*" } 2145 ::= { tlstmAddrEntry 2 } 2147 tlstmAddrStorageType OBJECT-TYPE 2148 SYNTAX StorageType 2149 MAX-ACCESS read-create 2150 STATUS current 2151 DESCRIPTION 2152 "The storage type for this conceptual row. Conceptual rows 2153 having the value 'permanent' need not allow write-access to 2154 any columnar objects in the row." 2155 DEFVAL { nonVolatile } 2156 ::= { tlstmAddrEntry 3 } 2158 tlstmAddrRowStatus OBJECT-TYPE 2159 SYNTAX RowStatus 2160 MAX-ACCESS read-create 2161 STATUS current 2162 DESCRIPTION 2163 "The status of this conceptual row. This object may be used 2164 to create or remove rows from this table. 2166 To create a row in this table, a manager must 2167 set this object to either createAndGo(4) or 2168 createAndWait(5). 2170 Until instances of all corresponding columns are 2171 appropriately configured, the value of the 2172 corresponding instance of the tlstmAddrRowStatus 2173 column is 'notReady'. 2175 In particular, a newly created row cannot be made active until 2176 the corresponding tlstmAddrServerFingerprint column has been 2177 set. 2179 The tlstmAddrServerFingerprint object may not be modified 2180 while the value of this object is active(1). 2182 An attempt to set these objects while the value of 2183 tlstmAddrRowStatus is active(1) will result in 2184 an inconsistentValue error. 2186 If this row is deleted it has no effect on the corresponding 2187 row in the targetAddrTable. 2189 If the corresponding row in the targetAddrTable is deleted 2190 then this row must be automatically removed." 2191 ::= { tlstmAddrEntry 4 } 2193 -- ************************************************ 2194 -- tlstmNotifications - Notifications Information 2195 -- ************************************************ 2197 tlstmServerCertificateUnknown NOTIFICATION-TYPE 2198 OBJECTS { snmpTlstmSessionUnknownServerCertificate } 2199 STATUS current 2200 DESCRIPTION 2201 "Notification that the server certificate presented by a SNMP 2202 over (D)TLS server was invalid because no configured 2203 fingerprint or CA was acceptable to validate it. This may 2204 result because there was no entry in the tlstmAddrTable or 2205 because no path could be found to known certificate 2206 authority. 2208 To avoid notification loops, this notification MUST NOT be 2209 sent to servers that themselves have triggered the 2210 notification." 2211 ::= { tlstmNotifications 1 } 2213 tlstmServerInvalidCertificate NOTIFICATION-TYPE 2214 OBJECTS { tlstmAddrServerFingerprint, 2215 snmpTlstmSessionInvalidServerCertificates} 2216 STATUS current 2217 DESCRIPTION 2218 "Notification that the server certificate presented by an SNMP 2219 over (D)TLS server could not be validated even if the 2220 fingerprint or expected validation path was known. I.E., a 2221 cryptographic validation occurred during certificate 2222 validation processing. 2224 To avoid notification loops, this notification MUST NOT be 2225 sent to servers that themselves have triggered the 2226 notification." 2227 ::= { tlstmNotifications 2 } 2229 -- ************************************************ 2230 -- tlstmCompliances - Conformance Information 2231 -- ************************************************ 2233 tlstmCompliances OBJECT IDENTIFIER ::= { tlstmConformance 1 } 2235 tlstmGroups OBJECT IDENTIFIER ::= { tlstmConformance 2 } 2237 -- ************************************************ 2238 -- Compliance statements 2239 -- ************************************************ 2241 tlstmCompliance MODULE-COMPLIANCE 2242 STATUS current 2243 DESCRIPTION 2244 "The compliance statement for SNMP engines that support the 2245 TLSTM-MIB" 2246 MODULE 2247 MANDATORY-GROUPS { tlstmStatsGroup, 2248 tlstmIncomingGroup, 2249 tlstmOutgoingGroup, 2250 tlstmNotificationGroup } 2251 ::= { tlstmCompliances 1 } 2253 -- ************************************************ 2254 -- Units of conformance 2255 -- ************************************************ 2256 tlstmStatsGroup OBJECT-GROUP 2257 OBJECTS { 2258 snmpTlstmSessionOpens, 2259 snmpTlstmSessionCloses, 2260 snmpTlstmSessionOpenErrors, 2261 snmpTlstmSessionNoSessions, 2262 snmpTlstmSessionInvalidClientCertificates, 2263 snmpTlstmSessionUnknownServerCertificate, 2264 snmpTlstmSessionInvalidServerCertificates, 2265 snmpTlstmSessionInvalidCaches, 2266 tlstmTLSProtectionErrors 2267 } 2268 STATUS current 2269 DESCRIPTION 2270 "A collection of objects for maintaining 2271 statistical information of an SNMP engine which 2272 implements the SNMP TLS Transport Model." 2273 ::= { tlstmGroups 1 } 2275 tlstmIncomingGroup OBJECT-GROUP 2276 OBJECTS { 2277 tlstmCertToTSNCount, 2278 tlstmCertToTSNTableLastChanged, 2279 tlstmCertToTSNFingerprint, 2280 tlstmCertToTSNMapType, 2281 tlstmCertToTSNData, 2282 tlstmCertToTSNStorageType, 2283 tlstmCertToTSNRowStatus 2284 } 2285 STATUS current 2286 DESCRIPTION 2287 "A collection of objects for maintaining 2288 incoming connection certificate mappings to 2289 tmSecurityNames of an SNMP engine which implements the 2290 SNMP TLS Transport Model." 2291 ::= { tlstmGroups 2 } 2293 tlstmOutgoingGroup OBJECT-GROUP 2294 OBJECTS { 2295 tlstmParamsCount, 2296 tlstmParamsTableLastChanged, 2297 tlstmParamsClientFingerprint, 2298 tlstmParamsStorageType, 2299 tlstmParamsRowStatus, 2300 tlstmAddrCount, 2301 tlstmAddrTableLastChanged, 2302 tlstmAddrServerFingerprint, 2303 tlstmAddrServerIdentity, 2304 tlstmAddrStorageType, 2305 tlstmAddrRowStatus 2306 } 2307 STATUS current 2308 DESCRIPTION 2309 "A collection of objects for maintaining 2310 outgoing connection certificates to use when opening 2311 connections as a result of SNMP-TARGET-MIB settings." 2312 ::= { tlstmGroups 3 } 2314 tlstmNotificationGroup NOTIFICATION-GROUP 2315 NOTIFICATIONS { 2316 tlstmServerCertificateUnknown, 2317 tlstmServerInvalidCertificate 2318 } 2319 STATUS current 2320 DESCRIPTION 2321 "Notifications" 2322 ::= { tlstmGroups 4 } 2324 END 2326 8. Operational Considerations 2328 This section discusses various operational aspects of deploying 2329 TLSTM. 2331 8.1. Sessions 2333 A session is discussed throughout this document as meaning a security 2334 association between the (D)TLS client and the (D)TLS server. State 2335 information for the sessions are maintained in each TLSTM 2336 implementation and this information is created and destroyed as 2337 sessions are opened and closed. A "broken" session (one side up and 2338 one side down) can result if one side of a session is brought down 2339 abruptly (i.e., reboot, power outage, etc.). Whenever possible, 2340 implementations SHOULD provide graceful session termination through 2341 the use of disconnect messages. Implementations SHOULD also have a 2342 system in place for detecting "broken" sessions through the use of 2343 heartbeats [I-D.seggelmann-tls-dtls-heartbeat] or other detection 2344 mechanisms. 2346 Implementations SHOULD limit the lifetime of established sessions 2347 depending on the algorithms used for generation of the master session 2348 secret, the privacy and integrity algorithms used to protect 2349 messages, the environment of the session, the amount of data 2350 transferred, and the sensitivity of the data. 2352 8.2. Notification Receiver Credential Selection 2354 When an SNMP engine needs to establish an outgoing session for 2355 notifications, the snmpTargetParamsTable includes an entry for the 2356 snmpTargetParamsSecurityName of the target. Servers that wish to 2357 support multiple principals at a particular port SHOULD make use of 2358 the Server Name Indication extension defined in Section 3.1 of 2359 [RFC4366]. Without the Server Name Indication the receiving SNMP 2360 engine (Server) will not know which (D)TLS certificate to offer to 2361 the Client so that the tmSecurityName identity-authentication will be 2362 successful. 2364 Another solution is to maintain a one-to-one mapping between 2365 certificates and incoming ports for notification receivers. This can 2366 be handled at the notification originator by configuring the 2367 snmpTargetAddrTable (snmpTargetAddrTDomain and 2368 snmpTargetAddrTAddress) and requiring the receiving SNMP engine to 2369 monitor multiple incoming static ports based on which principals are 2370 capable of receiving notifications. 2372 Implementations MAY also choose to designate a single Notification 2373 Receiver Principal to receive all incoming notifications or select an 2374 implementation specific method of selecting a server certificate to 2375 present to clients. 2377 8.3. contextEngineID Discovery 2379 Most command responders have contextEngineIDs that are identical to 2380 the USM securityEngineID. USM provides a discovery service that 2381 allows command generators to determine a securityEngineID and thus a 2382 default contextEngineID to use. Because the TLS Transport Model does 2383 not make use of a securityEngineID, it may be difficult for command 2384 generators to discover a suitable default contextEngineID. 2385 Implementations should consider offering another engineID discovery 2386 mechanism to continue providing Command Generators with a suitable 2387 contextEngineID mechanism. A recommended discovery solution is 2388 documented in [RFC5343]. 2390 8.4. Transport Considerations 2392 This document defines how SNMP messages can be transmitted over the 2393 TLS and DTLS based protocols. Each of these protocols are 2394 additionally based on other transports (TCP, UDP and SCTP). These 2395 three protocols also have operational considerations that must be 2396 taken into consideration when selecting a (D)TLS based protocol to 2397 use such as its performance in degraded or limited networks. It is 2398 beyond the scope of this document to summarize the characteristics of 2399 these transport mechanisms. Please refer to the base protocol 2400 documents for details on messaging considerations with respect to MTU 2401 size, fragmentation, performance in lossy-networks, etc. 2403 9. Security Considerations 2405 This document describes a transport model that permits SNMP to 2406 utilize (D)TLS security services. The security threats and how the 2407 (D)TLS transport model mitigates these threats are covered in detail 2408 throughout this document. Security considerations for DTLS are 2409 covered in [RFC4347] and security considerations for TLS are 2410 described in Section 11 and Appendices D, E, and F of TLS 1.2 2411 [RFC5246]. DTLS adds to the security considerations of TLS only 2412 because it is more vulnerable to denial of service attacks. A random 2413 cookie exchange was added to the handshake to prevent anonymous 2414 denial of service attacks. RFC 4347 recommends that the cookie 2415 exchange is utilized for all handshakes and therefore this 2416 specification also RECOMMENDEDs that implementers also support this 2417 cookie exchange. 2419 9.1. Certificates, Authentication, and Authorization 2421 Implementations are responsible for providing a security certificate 2422 installation and configuration mechanism. Implementations SHOULD 2423 support certificate revocation lists. 2425 (D)TLS provides for authentication of the identity of both the (D)TLS 2426 server and the (D)TLS client. Access to MIB objects for the 2427 authenticated principal MUST be enforced by an access control 2428 subsystem (e.g. the VACM). 2430 Authentication of the command generator principal's identity is 2431 important for use with the SNMP access control subsystem to ensure 2432 that only authorized principals have access to potentially sensitive 2433 data. The authenticated identity of the command generator 2434 principal's certificate is mapped to an SNMP model-independent 2435 securityName for use with SNMP access control. 2437 The (D)TLS handshake only provides assurance that the certificate of 2438 the authenticated identity has been signed by an configured accepted 2439 Certificate Authority. (D)TLS has no way to further authorize or 2440 reject access based on the authenticated identity. An Access Control 2441 Model (such as the VACM) provides access control and authorization of 2442 a command generator's requests to a command responder and a 2443 notification responder's authorization to receive Notifications from 2444 a notification originator. However to avoid man-in-the-middle 2445 attacks both ends of the (D)TLS based connection MUST check the 2446 certificate presented by the other side against what was expected. 2447 For example, command generators must check that the command responder 2448 presented and authenticated itself with a X.509 certificate that was 2449 expected. Not doing so would allow an impostor, at a minimum, to 2450 present false data, receive sensitive information and/or provide a 2451 false belief that configuration was actually received and acted upon. 2452 Authenticating and verifying the identity of the (D)TLS server and 2453 the (D)TLS client for all operations ensures the authenticity of the 2454 SNMP engine that provides MIB data. 2456 The instructions found in the DESCRIPTION clause of the 2457 tlstmCertToTSNTable object must be followed exactly. It is also 2458 important that the rows of the table be searched in prioritized order 2459 starting with the row containing the lowest numbered tlstmCertToTSNID 2460 value. 2462 9.2. Use with SNMPv1/SNMPv2c Messages 2464 The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP 2465 74) always selects the SNMPv1 or SNMPv2c Security Models, 2466 respectively. Both of these and the User-based Security Model 2467 typically used with SNMPv3 derive the securityName and securityLevel 2468 from the SNMP message received, even when the message was received 2469 over a secure transport. Access control decisions are therefore made 2470 based on the contents of the SNMP message, rather than using the 2471 authenticated identity and securityLevel provided by the TLS 2472 Transport Model. 2474 9.3. MIB Module Security 2476 There are a number of management objects defined in this MIB module 2477 with a MAX-ACCESS clause of read-write and/or read-create. Such 2478 objects may be considered sensitive or vulnerable in some network 2479 environments. The support for SET operations in a non-secure 2480 environment without proper protection can have a negative effect on 2481 network operations. These are the tables and objects and their 2482 sensitivity/vulnerability: 2484 o The tlstmParamsTable can be used to change the outgoing X.509 2485 certificate used to establish a (D)TLS connection. Modification 2486 to objects in this table need to be adequately authenticated since 2487 modification to values in this table will have profound impacts to 2488 the security of outbound connections from the device. Since 2489 knowledge of authorization rules and certificate usage mechanisms 2490 may be considered sensitive, protection from disclosure of the 2491 SNMP traffic via encryption is also highly recommended. 2493 o The tlstmAddrTable can be used to change the expectations of the 2494 certificates presented by a remote (D)TLS server. Modification to 2495 objects in this table need to be adequately authenticated since 2496 modification to values in this table will have profound impacts to 2497 the security of outbound connections from the device. Since 2498 knowledge of authorization rules and certificate usage mechanisms 2499 may be considered sensitive, protection from disclosure of the 2500 SNMP traffic via encryption is also highly recommended. 2502 o The tlstmCertToTSNTable is used to specify the mapping of incoming 2503 X.509 certificates to tmSecurityNames which eventually get mapped 2504 to a SNMPv3 securityName. Modification to objects in this table 2505 need to be adequately authenticated since modification to values 2506 in this table will have profound impacts to the security of 2507 incoming connections to the device. Since knowledge of 2508 authorization rules and certificate usage mechanisms may be 2509 considered sensitive, protection from disclosure of the SNMP 2510 traffic via encryption is also highly recommended. 2512 Some of the readable objects in this MIB module (i.e., objects with a 2513 MAX-ACCESS other than not-accessible) may be considered sensitive or 2514 vulnerable in some network environments. It is thus important to 2515 control even GET and/or NOTIFY access to these objects and possibly 2516 to even encrypt the values of these objects when sending them over 2517 the network via SNMP. These are the tables and objects and their 2518 sensitivity/vulnerability: 2520 o This MIB contains a collection of counters that monitor the (D)TLS 2521 connections being established with a device. Since knowledge of 2522 connection and certificate usage mechanisms may be considered 2523 sensitive, protection from disclosure of the SNMP traffic via 2524 encryption is also highly recommended. 2526 SNMP versions prior to SNMPv3 did not include adequate security. 2527 Even if the network itself is secure (for example by using IPsec), 2528 even then, there is no control as to who on the secure network is 2529 allowed to access and GET/SET (read/change/create/delete) the objects 2530 in this MIB module. 2532 It is RECOMMENDED that implementers consider the security features as 2533 provided by the SNMPv3 framework (see [RFC3410], section 8), 2534 including full support for the SNMPv3 cryptographic mechanisms (for 2535 authentication and privacy). 2537 Further, deployment of SNMP versions prior to SNMPv3 is NOT 2538 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 2539 enable cryptographic security. It is then a customer/operator 2540 responsibility to ensure that the SNMP entity giving access to an 2541 instance of this MIB module is properly configured to give access to 2542 the objects only to those principals (users) that have legitimate 2543 rights to indeed GET or SET (change/create/delete) them. 2545 10. IANA Considerations 2547 IANA is requested to assign: 2549 1. a TCP port number above 1023 in the 2550 http://www.iana.org/assignments/port-numbers registry which will 2551 be the default port for receipt of SNMP command messages over a 2552 TLS Transport Model as defined in this document, 2554 2. a TCP port number above 1023 in the 2555 http://www.iana.org/assignments/port-numbers registry which will 2556 be the default port for receipt of SNMP notification messages 2557 over a TLS Transport Model as defined in this document, 2559 3. a UDP port number above 1023 in the 2560 http://www.iana.org/assignments/port-numbers registry which will 2561 be the default port for receipt of SNMP command messages over a 2562 DTLS/UDP connection as defined in this document, 2564 4. a UDP port number above 1023 in the 2565 http://www.iana.org/assignments/port-numbers registry which will 2566 be the default port for receipt of SNMP notification messages 2567 over a DTLS/UDP connection as defined in this document, 2569 5. a SCTP port number above 1023 in the 2570 http://www.iana.org/assignments/port-numbers registry which will 2571 be the default port for receipt of SNMP command messages over a 2572 DTLS/SCTP connection as defined in this document, 2574 6. a SCTP port number above 1023 in the 2575 http://www.iana.org/assignments/port-numbers registry which will 2576 be the default port for receipt of SNMP notification messages 2577 over a DTLS/SCTP connection as defined in this document, 2579 7. an SMI number under snmpDomains for the snmpTLSTCPDomain object 2580 identifier, 2582 8. an SMI number under snmpDomains for the snmpDTLSUDPDomain object 2583 identifier, 2585 9. an SMI number under snmpDomains for the snmpDTLSSCTPDomain 2586 object identifier, 2588 10. a SMI number under snmpModules, for the MIB module in this 2589 document, 2591 11. "tls" as the corresponding prefix for the snmpTLSTCPDomain in 2592 the SNMP Transport Model registry, 2594 12. "dudp" as the corresponding prefix for the snmpDTLSUDPDomain in 2595 the SNMP Transport Model registry, 2597 13. "dsct" as the corresponding prefix for the snmpDTLSSCTPDomain in 2598 the SNMP Transport Model registry; 2600 If possible, IANA is requested to use matching port numbers for all 2601 assignments for SNMP Commands being sent over TLS, DTLS/UDP, DTLS/ 2602 SCTP. 2604 If possible, IANA is requested to use matching port numbers for all 2605 assignments for SNMP Notifications being sent over TLS, DTLS/UDP, 2606 DTLS/SCTP. 2608 Editor's note: this section should be replaced with appropriate 2609 descriptive assignment text after IANA assignments are made and prior 2610 to publication. 2612 11. Acknowledgements 2614 This document closely follows and copies the Secure Shell Transport 2615 Model for SNMP defined by David Harrington and Joseph Salowey in 2616 [RFC5292]. 2618 This document was reviewed by the following people who helped provide 2619 useful comments (in alphabetical order): Andy Donati, Pasi Eronen, 2620 David Harrington, Jeffrey Hutzelman, Alan Luchuk, Tom Petch, Randy 2621 Presuhn, Ray Purvis, Joseph Salowey, Jurgen Schonwalder, Dave Shield. 2623 This work was supported in part by the United States Department of 2624 Defense. Large portions of this document are based on work by 2625 General Dynamics C4 Systems and the following individuals: Brian 2626 Baril, Kim Bryant, Dana Deluca, Dan Hanson, Tim Huemiller, John 2627 Holzhauer, Colin Hoogeboom, Dave Kornbau, Chris Knaian, Dan Knaul, 2628 Charles Limoges, Steve Moccaldi, Gerardo Orlando, and Brandon Yip. 2630 12. References 2632 12.1. Normative References 2634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2635 Requirement Levels", BCP 14, RFC 2119, March 1997. 2637 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2638 Schoenwaelder, Ed., "Structure of Management Information 2639 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2641 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2642 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 2643 STD 58, RFC 2579, April 1999. 2645 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2646 "Conformance Statements for SMIv2", STD 58, RFC 2580, 2647 April 1999. 2649 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2650 Architecture for Describing Simple Network Management 2651 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2652 December 2002. 2654 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 2655 Management Protocol (SNMP) Applications", STD 62, 2656 RFC 3413, December 2002. 2658 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 2659 (USM) for version 3 of the Simple Network Management 2660 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 2662 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 2663 Access Control Model (VACM) for the Simple Network 2664 Management Protocol (SNMP)", STD 62, RFC 3415, 2665 December 2002. 2667 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 2668 Simple Network Management Protocol (SNMP)", STD 62, 2669 RFC 3418, December 2002. 2671 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 2672 "Coexistence between Version 1, Version 2, and Version 3 2673 of the Internet-standard Network Management Framework", 2674 BCP 74, RFC 3584, August 2003. 2676 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2677 Security", RFC 4347, April 2006. 2679 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2680 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2682 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2683 Housley, R., and W. Polk, "Internet X.509 Public Key 2684 Infrastructure Certificate and Certificate Revocation List 2685 (CRL) Profile", RFC 5280, May 2008. 2687 [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem 2688 for the Simple Network Management Protocol (SNMP)", 2689 RFC 5590, June 2009. 2691 [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model 2692 for the Simple Network Management Protocol (SNMP)", 2693 RFC 5591, June 2009. 2695 12.2. Informative References 2697 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 2698 Protocol", RFC 2522, March 1999. 2700 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 2701 "Introduction and Applicability Statements for Internet- 2702 Standard Management Framework", RFC 3410, December 2002. 2704 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2705 RFC 4306, December 2005. 2707 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 2708 and T. Wright, "Transport Layer Security (TLS) 2709 Extensions", RFC 4366, April 2006. 2711 [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound 2712 Route Filter for BGP-4", RFC 5292, August 2008. 2714 [RFC5343] Schoenwaelder, J., "Simple Network Management Protocol 2715 (SNMP) Context EngineID Discovery", RFC 5343, 2716 September 2008. 2718 [I-D.saintandre-tls-server-id-check] 2719 Saint-Andre, P., Zeilenga, K., Hodges, J., and B. Morgan, 2720 "Best Practices for Checking of Server Identities in the 2721 Context of Transport Layer Security (TLS)". 2723 [I-D.seggelmann-tls-dtls-heartbeat] 2724 Seggelmann, R., Tuexen, M., and M. Williams, "Transport 2725 Layer Security and Datagram Transport Layer Security 2726 Heartbeat Extension". 2728 [AES] National Institute of Standards, "Specification for the 2729 Advanced Encryption Standard (AES)". 2731 [DES] National Institute of Standards, "American National 2732 Standard for Information Systems-Data Link Encryption". 2734 [DSS] National Institute of Standards, "Digital Signature 2735 Standard". 2737 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 2738 Obtaining Digital Signatures and Public-Key 2739 Cryptosystems". 2741 [X509] , ITU., "INFORMATION TECHNOLOGY OPEN SYSTEMS 2742 INTERCONNECTION THE DIRECTORY: PUBLIC-KEY AND ATTRIBUTE 2743 CERTIFICATE FRAMEWORKS". 2745 Appendix A. (D)TLS Overview 2747 The (D)TLS protocol is composed of two layers: the (D)TLS Record 2748 Protocol and the (D)TLS Handshake Protocol. The following 2749 subsections provide an overview of these two layers. Please refer to 2750 [RFC4347] for a complete description of the protocol. 2752 A.1. The (D)TLS Record Protocol 2754 At the lowest layer, layered on top of the transport control protocol 2755 or a datagram transport protocol (e.g. UDP or SCTP) is the (D)TLS 2756 Record Protocol. 2758 The (D)TLS Record Protocol provides security that has three basic 2759 properties: 2761 o The session can be confidential. Symmetric cryptography is used 2762 for data encryption (e.g., [AES], [DES] etc.). The keys for this 2763 symmetric encryption are generated uniquely for each session and 2764 are based on a secret negotiated by another protocol (such as the 2765 (D)TLS Handshake Protocol). The Record Protocol can also be used 2766 without encryption. 2768 o Messages can have data integrity. Message transport includes a 2769 message integrity check using a keyed MAC. Secure hash functions 2770 (e.g., SHA, MD5, etc.) are used for MAC computations. The Record 2771 Protocol can operate without a MAC, but is generally only used in 2772 this mode while another protocol is using the Record Protocol as a 2773 transport for negotiating security parameters. 2775 o Messages are protected against replay. (D)TLS uses explicit 2776 sequence numbers and integrity checks. DTLS uses a sliding window 2777 to protect against replay of messages within a session. 2779 (D)TLS also provides protection against replay of entire sessions. 2780 In a properly-implemented keying material exchange, both sides will 2781 generate new random numbers for each exchange. This results in 2782 different encryption and integrity keys for every session. 2784 A.2. The (D)TLS Handshake Protocol 2786 The (D)TLS Record Protocol is used for encapsulation of various 2787 higher-level protocols. One such encapsulated protocol, the (D)TLS 2788 Handshake Protocol, allows the server and client to authenticate each 2789 other and to negotiate an integrity algorithm, an encryption 2790 algorithm and cryptographic keys before the application protocol 2791 transmits or receives its first octet of data. Only the (D)TLS 2792 client can initiate the handshake protocol. The (D)TLS Handshake 2793 Protocol provides security that has four basic properties: 2795 o The peer's identity can be authenticated using asymmetric (public 2796 key) cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This 2797 authentication can be made optional, but is generally required by 2798 at least one of the peers. 2800 (D)TLS supports three authentication modes: authentication of both 2801 the server and the client, server authentication with an 2802 unauthenticated client, and total anonymity. For authentication 2803 of both entities, each entity provides a valid certificate chain 2804 leading to an acceptable certificate authority. Each entity is 2805 responsible for verifying that the other's certificate is valid 2806 and has not expired or been revoked. See 2807 [I-D.saintandre-tls-server-id-check] for further details on 2808 standardized processing when checking server certificate 2809 identities. 2811 o The negotiation of a shared secret is secure: the negotiated 2812 secret is unavailable to eavesdroppers, and for any authenticated 2813 handshake the secret cannot be obtained, even by an attacker who 2814 can place himself in the middle of the session. 2816 o The negotiation is not vulnerable to malicious modification: it is 2817 infeasible for an attacker to modify negotiation communication 2818 without being detected by the parties to the communication. 2820 o DTLS uses a stateless cookie exchange to protect against anonymous 2821 denial of service attacks and has retransmission timers, sequence 2822 numbers, and counters to handle message loss, reordering, and 2823 fragmentation. 2825 Appendix B. PKIX Certificate Infrastructure 2827 Users of a public key from a PKIX / X.509 certificate can be be 2828 confident that the associated private key is owned by the correct 2829 remote subject (person or system) with which an encryption or digital 2830 signature mechanism will be used. This confidence is obtained 2831 through the use of public key certificates, which are data structures 2832 that bind public key values to subjects. The binding is asserted by 2833 having a trusted CA digitally sign each certificate. The CA may base 2834 this assertion upon technical means (i.e., proof of possession 2835 through a challenge-response protocol), presentation of the private 2836 key, or on an assertion by the subject. A certificate has a limited 2837 valid lifetime which is indicated in its signed contents. Because a 2838 certificate's signature and timeliness can be independently checked 2839 by a certificate-using client, certificates can be distributed via 2840 untrusted communications and server systems, and can be cached in 2841 unsecured storage in certificate-using systems. 2843 ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8 [X509], 2844 which was first published in 1988 as part of the X.500 Directory 2845 recommendations, defines a standard certificate format which is a 2846 certificate which binds a subject (principal) to a public key value. 2848 This was later further expanded and documented in [RFC5280]. 2850 A X.509 certificate is a sequence of three required fields: 2852 tbsCertificate: The tbsCertificate field contains the names of the 2853 subject and issuer, a public key associated with the subject, a 2854 validity period, and other associated information. This field may 2855 also contain extension components. 2857 signatureAlgorithm: The signatureAlgorithm field contains the 2858 identifier for the cryptographic algorithm used by the certificate 2859 authority (CA) to sign this certificate. 2861 signatureValue: The signatureValue field contains a digital 2862 signature computed by the CA upon the ASN.1 DER encoded 2863 tbsCertificate field. The ASN.1 DER encoded tbsCertificate is 2864 used as the input to the signature function. This signature value 2865 is then ASN.1 DER encoded as a BIT STRING and included in the 2866 Certificate's signature field. By generating this signature, the 2867 CA certifies the validity of the information in the tbsCertificate 2868 field. In particular, the CA certifies the binding between the 2869 public key material and the subject of the certificate. 2871 The basic X.509 authentication procedure is as follows: A system is 2872 initialized with a number of root certificates that contain the 2873 public keys of a number of trusted CAs. When a system receives a 2874 X.509 certificate, signed by one of those CAs, the certificate has to 2875 be verified. It first checks the signatureValue field by using the 2876 public key of the corresponding trusted CA. Then it compares the 2877 digest of the received certificate with a digest of the 2878 tbsCertificate field. If they match, then the subject in the 2879 tbsCertificate field is authenticated. 2881 Appendix C. Target and Notificaton Configuration Example 2883 Configuring the SNMP-TARGET-MIB and NOTIFICATION-MIB along with 2884 access control settings for the SNMP-VIEW-BASED-ACM-MIB can be a 2885 daunting task without an example to follow. The following section 2886 describes an example of what pieces must be in place to accomplish 2887 this configuration. 2889 The isAccessAllowed() ASI requires configuration to exist in the 2890 following SNMP-VIEW-BASED-ACM-MIB tables: 2892 vacmSecurityToGroupTable 2893 vacmAccessTable 2894 vacmViewTreeFamilyTable 2896 The only table that needs to be discussed as particularly different 2897 here is the vacmSecurityToGroupTable. This table is indexed by both 2898 the SNMPv3 security model and the security name. The security model, 2899 when TLSTM is in use, should be set to the value of 4, corresponding 2900 to the TSM [RFC5591]. An example vacmSecurityToGroupTable row might 2901 be filled out as follows (using a single SNMP SET request): 2903 vacmSecurityModel = 4 (TSM) 2904 vacmSecurityName = "blueberry" 2905 vacmGroupName = "administrators" 2906 vacmSecurityToGroupStorageType = 3 (nonVolatile) 2907 vacmSecurityToGroupStatus = 4 (createAndGo) 2909 This example will assume that the "administrators" group has been 2910 given proper permissions via rows in the vacmAccessTable and 2911 vacmViewTreeFamilyTable. 2913 Depending on whether this VACM configuration is for a Command 2914 Responder or a command generator the security name "blueberry" will 2915 come from a few different locations. 2917 C.1. Configuring the Notification Generator 2919 For notification generators performing authorization checks, the 2920 server's certificate must be verified against the expected 2921 certificate before proceeding to send the notification. The expected 2922 certificate from the server may be listed in the tlstmAddrTable or 2923 may be determined through other X.509 path validation mechanisms. 2924 The securityName to use for VACM authorization checks is set by the 2925 SNMP-TARGET-MIB's snmpTargetParamsSecurityName column. 2927 The certificate that the notification generator should present to the 2928 server is taken from the tlstmParamsClientFingerprint column from the 2929 appropriate entry in the tlstmParamsTable table. 2931 C.2. Configuring the Command Responder 2933 For command responder applications, the vacmSecurityName "blueberry" 2934 value is a value that derived from an incoming (D)TLS session. The 2935 mapping from a recevied (D)TLS client certificate to a tmSecurityName 2936 is done with the tlstmCertToTSNTable. The certificates must be 2937 loaded into the device so that a tlstmCertToTSNEntry may refer to it. 2938 As an example, consider the following entry which will provide a 2939 mapping from a client's public X.509's hash fingerprint directly to 2940 the "blueberry" tmSecurityName: 2942 tlstmCertToTSNID = 1 (chosen by ordering preference) 2943 tlstmCertToTSNFingerprint = HASH (appropriate fingerprint) 2944 tlstmCertToTSNMapType = 1 (specified) 2945 tlstmCertToTSNSecurityName = "blueberry" 2946 tlstmCertToTSNStorageType = 3 (nonVolatile) 2947 tlstmCertToTSNRowStatus = 4 (createAndGo) 2949 The above is an example of how to map a particular certificate to a 2950 particular tmSecurityName. It is recommended, however, that users 2951 make use of direct subjectAltName or CommonName mappings where 2952 possible as it provides a more scalable approach to certificate 2953 management. This entry provides an example of using a subjectAltName 2954 mapping: 2956 tlstmCertToTSNID = 1 (chosen by ordering preference) 2957 tlstmCertToTSNFingerprint = HASH (appropriate fingerprint) 2958 tlstmCertToTSNMapType = 2 (bySubjectAltName) 2959 tlstmCertToTSNSANType = 1 (any) 2960 tlstmCertToTSNStorageType = 3 (nonVolatile) 2961 tlstmCertToTSNRowStatus = 4 (createAndGo) 2963 The above entry indicates the subjectAltName field for certificates 2964 created by an issuing certificate with a corresponding fingerprint 2965 will be trusted to always produce common names that are directly one- 2966 to-one mappable into tmSecurityNames. This type of configuration 2967 should only be used when the certificate authorities naming 2968 conventions are carefully controlled. 2970 In the example, if the incoming (D)TLS client provided certificate 2971 contained a subjectAltName where the first listed subjectAltName in 2972 the extension is the rfc822Name of "blueberry@example.com", the 2973 certificate was signed by a certificate matching the 2974 tlstmCertToTSNFingerprint value and the CA's certificate was properly 2975 installed on the device then the string "blueberry@example.com" would 2976 be used as the tmSecurityName for the session. 2978 Author's Address 2980 Wes Hardaker 2981 Sparta, Inc. 2982 P.O. Box 382 2983 Davis, CA 95617 2984 USA 2986 Phone: +1 530 792 1913 2987 Email: ietf@hardakers.net