idnits 2.17.1 draft-ietf-opsawg-tlstm-update-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 63 instances of too long lines in the document, the longest one being 3 characters in excess of 72. -- The draft header indicates that this document updates RFC6353, but the abstract doesn't seem to directly say this. It does mention RFC6353 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (5 May 2022) is 722 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) == Unused Reference: 'STD58' is defined on line 1405, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Vaughn, Ed. 3 Internet-Draft Trevilon LLC 4 Updates: 6353 (if approved) 5 May 2022 5 Intended status: Standards Track 6 Expires: 6 November 2022 8 Updates to the TLS Transport Model for SNMP 9 draft-ietf-opsawg-tlstm-update-03 11 Abstract 13 This document updates the TLS Transport Model (TLSTM), as defined in 14 RFC 6353, to reflect changes necessary to support Transport Layer 15 Security Version 1.3 (TLS 1.3) and Datagram Transport Layer Security 16 Version 1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3". 17 This document is compatible with (D)TLS 1.2 and is intended to be 18 compatible with future versions of SNMP and (D)TLS. 20 This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 6 November 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Changes from RFC 6353 . . . . . . . . . . . . . . . . . . . . 3 58 2.1. TLSTM Fingerprint . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Security Level . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Additional Rules for TLS 1.3 . . . . . . . . . . . . . . . . 4 62 3.1. Zero Round Trip Time Resumption (0-RTT) . . . . . . . . . 4 63 3.2. TLS ciphersuites, extensions and protocol invariants . . 5 64 4. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 70 8.2. Informative References . . . . . . . . . . . . . . . . . 30 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 73 1. Introduction 75 This document updates and clarifies how the rules of [RFC6353] apply 76 when using Transport Layer Security Version 1.3 (TLS, [RFC8446]) or 77 Datagram Transport Layer Security Version 1.3 (DTLS, [RFC9147]), 78 which are jointly known as "(D)TLS 1.3". The update also 79 incorporates the [RFC8996] update, which prohibits the use of TLS 80 versions prior to TLS 1.2. Although the text of this document 81 specifically reference SNMPv3 and (D)TLS 1.3, this document may be 82 applicable to future versions of these protocols and is backwards 83 compatible with (D)TLS 1.2. 85 1.1. Conventions 87 Within this document the terms "TLS", "DTLS", "(D)TLS", and "TLSTM" 88 apply to all versions of the indicated protocols. The term "SNMP" 89 means "SMNPv3" unless a specific other version number is . 90 indicated. Specific version numbers are used when the text needs to 91 emphasize version numbers. 93 For consistency with SNMP-related specifications, this document 94 favors terminology as defined in [STD62], rather than favoring 95 terminology that is consistent with non-SNMP specifications. This is 96 consistent with the IESG decision to not require the SNMP terminology 97 be modified to match the usage of other non-SNMP specifications when 98 SNMP was advanced to a Full Standard. "Authentication" in this 99 document typically refers to the English meaning of "serving to prove 100 the authenticity of" the message, not data source authentication or 101 peer identity authentication. The terms "manager" and "agent" are 102 not used in this document because, in the RFC3411 architecture, all 103 SNMP entities have the capability of acting as manager, agent, or 104 both depending on the SNMP application types supported in the 105 implementation. Where distinction is necessary, the application 106 names of command generator, command responder, notification 107 originator, notification receiver, and proxy forwarder are used. See 108 "SNMP Applications" (RFC3411) for further information. 110 Throughout this document, the terms "client" and "server" are used to 111 refer to the two ends of the TLS transport connection. The client 112 actively opens the TLS connection, and the server passively listens 113 for the incoming TLS connection. An SNMP entity MAY act as a TLS 114 client or server or both, depending on the SNMP applications 115 supported. 117 Throughout this document, the term "session" is used to refer to a 118 secure association between two TLS Transport Models that permits the 119 transmission of one or more SNMP messages within the lifetime of the 120 session. The TLS protocol also has an internal notion of a session 121 and although these two concepts of a session are related, when the 122 term "session" is used this document is referring to the TLSTM's 123 specific session and not directly to the TLS protocol's session. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", NOT RECOMMENDED, "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in 128 [RFC2119]. 130 2. Changes from RFC 6353 132 This document updates [RFC6353]. The changes from [RFC6353] are 133 defined in the following clauses. 135 2.1. TLSTM Fingerprint 137 [RFC6353] defines a fingerprint algorithm that references the one- 138 octet TLS 1.2 hash algorithm identifier. TLS 1.3 replaced the one- 139 octet hash algorithm identifier with a two-octet TLS 1.3 cipher suite 140 identifier. The TLS 1.3 cipher suite still includes a hashing 141 algorithm but new hashing algorithms (e.g., for use in TLS 1.3) will 142 not be assigned values in the IANA TLS HashAlgorithm Registry, as 143 defined in RFC 5246. 145 This document updates the definition of SnmpTLSFingerprint to clarify 146 that the one-octet identifier in the fingerprint algorithm uses a 147 registry that is consistent with the IANA TLS HashAlgorithm Registry 148 for its initial values but one that can be extended to support new 149 hashing algorithms that might be used for TLS versions after version 150 1.2. This change allows the reuse of the existing fingerprint 151 TEXTUAL-CONVENTION and minimizes the impact to RFC 6353. 153 2.2. Security Level 155 The RFC3411 architecture recognizes three levels of security: 157 * without authentication and without privacy (noAuthNoPriv) 159 * with authentication but without privacy (authNoPriv) 161 * with authentication and with privacy (authPriv) 163 With (D)TLS 1.3, authentication and privacy are always provided. 164 Hence, all exchanges conforming to the rules of this document will 165 include authentication and privacy, regardless of the security level 166 requested. 167 // This is consistent with what was prescribed in RFC6353, where a 168 // TLS Transport Model is expected to provide for outgoing 169 // connections with a security level at least that of the requested 170 // security level. 172 2.3. TLS Version 174 [RFC6353] stated that TLSTM clients and servers MUST NOT request, 175 offer, or use SSL 2.0. [RFC8996] prohibits the use of (D)TLS 176 versions prior to version 1.2. TLSTMv1.3 MUST only be used with 177 (D)TLS version 1.2 and later. 179 3. Additional Rules for TLS 1.3 181 This document specifies additional rules and clarifications for the 182 use of TLS 1.3. These rules may additionally apply to future 183 versions of TLS. 185 3.1. Zero Round Trip Time Resumption (0-RTT) 187 TLS 1.3 implementations for SNMP MUST NOT enable the 0-RTT mode of 188 session resumption (either sending or accepting) and MUST NOT 189 automatically resend 0-RTT data if it is rejected by the server. The 190 reason 0-RTT is disallowed is that there are no "safe" messages that 191 if replayed will be guaranteed to cause no harm at a server side: all 192 incoming notification or command responses are meant to be acted upon 193 only once. See Security considerations section for further details. 195 TLS TM clients and servers MUST NOT request, offer or use the 0-RTT 196 mode of TLS 1.3. [RFC8446] removed the renegotiation supported in 197 TLS 1.2 [RFC5246]; for session resumption, it introduced a zero-RTT 198 (0-RTT) mode, saving a round-trip at connection setup at the cost of 199 increased risk of replay attacks (it is possible for servers to guard 200 against this attack by keeping track of all the messages received). 201 [RFC8446] requires a profile be written for any application that 202 wants to use 0-RTT, specifying which messages are "safe to use" on 203 this mode. The reason 0-RTT is disallowed here is that there are no 204 "safe" SNMP messages that if replayed will be sure to cause no harm 205 at a server side: all incoming notification or command responses have 206 consequences and are to be acted upon only once. 208 Renegotiation of sessions is not supported as it is not supported by 209 TLS 1.3. 211 3.2. TLS ciphersuites, extensions and protocol invariants 213 [RFC8446] section 9 requires that, in the absence of application 214 profiles, certain cipher suites, TLS extensions, and TLS protocol 215 invariants are mandatory to implement. This document does not 216 specify an application profile, hence all of the compliance 217 requirements in [RFC8446] apply. 219 4. MIB Module Definition 221 SNMP-TLS-TM-MIB DEFINITIONS ::= BEGIN 223 IMPORTS 224 MODULE-IDENTITY, OBJECT-TYPE, 225 OBJECT-IDENTITY, mib-2, snmpDomains, 226 Counter32, Unsigned32, Gauge32, NOTIFICATION-TYPE 227 FROM SNMPv2-SMI -- RFC 2578 or any update thereof 228 TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType, 229 AutonomousType 230 FROM SNMPv2-TC -- RFC 2579 or any update thereof 231 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 232 FROM SNMPv2-CONF -- RFC 2580 or any update thereof 233 SnmpAdminString 234 FROM SNMP-FRAMEWORK-MIB -- RFC 3411 or any update thereof 235 snmpTargetParamsName, snmpTargetAddrName 236 FROM SNMP-TARGET-MIB -- RFC 3413 or any update thereof 237 ; 239 snmpTlstmMIB MODULE-IDENTITY 240 LAST-UPDATED "202203050000Z" 241 ORGANIZATION "OPSA Working Group" 242 CONTACT-INFO "WG-EMail: opsawg@ietf.org 243 Mailing list subscription info: 244 https://www.ietf.org/mailman/listinfo/opsawg 246 Kenneth Vaughn 247 Trevilon LLC 248 6606 FM 1488 RD, STE 503 249 Magnolia, TX 77354 250 United States 251 Phone: +1 571 331 5670 252 Email: kvaughn@trevilon.com" 253 DESCRIPTION " 254 The TLS Transport Model MIB 256 Copyright (c) 2010-2022 IETF Trust and the persons identified 257 as authors of the code. All rights reserved. 259 Redistribution and use in source and binary forms, with or 260 without modification, is permitted pursuant to, and subject 261 to the license terms contained in, the Revised BSD License 262 set forth in Section 4.c of the IETF Trust's Legal Provisions 263 Relating to IETF Documents 264 (http://trustee.ietf.org/license-info)." 266 REVISION "202203050000Z" 267 DESCRIPTION "This version of this MIB module is part of 268 RFC XXXX; see the RFC itself for full legal 269 notices. This version: 270 1. Updates the definition of SnmpTLSFingerprint 271 to clarify the registry used for the one-octet 272 hash algorithm identifier. 273 2. Capitalizes key words in conformance with 274 BCP 14 275 3. Replaces 'may not' with 'MUST NOT' to clarify 276 intent in several locations." 278 REVISION "201107190000Z" 279 DESCRIPTION "This version of this MIB module is part of 280 RFC 6353; see the RFC itself for full legal 281 notices. The only change was to introduce 282 new wording to reflect require changes for 283 IDNA addresses in the SnmpTLSAddress TC." 285 REVISION "201005070000Z" 286 DESCRIPTION "This version of this MIB module is part of 287 RFC 5953; see the RFC itself for full legal 288 notices." 290 ::= { mib-2 198 } 292 -- ************************************************ 293 -- subtrees of the SNMP-TLS-TM-MIB 294 -- ************************************************ 296 snmpTlstmNotifications OBJECT IDENTIFIER ::= { snmpTlstmMIB 0 } 297 snmpTlstmIdentities OBJECT IDENTIFIER ::= { snmpTlstmMIB 1 } 298 snmpTlstmObjects OBJECT IDENTIFIER ::= { snmpTlstmMIB 2 } 299 snmpTlstmConformance OBJECT IDENTIFIER ::= { snmpTlstmMIB 3 } 301 -- ************************************************ 302 -- snmpTlstmObjects - Objects 303 -- ************************************************ 305 snmpTLSTCPDomain OBJECT-IDENTITY 306 STATUS current 307 DESCRIPTION 308 "The SNMP over TLS via TCP transport domain. The 309 corresponding transport address is of type SnmpTLSAddress. 311 The securityName prefix to be associated with the 312 snmpTLSTCPDomain is 'tls'. This prefix MAY be used by 313 security models or other components to identify which secure 314 transport infrastructure authenticated a securityName." 315 REFERENCE 316 "RFC 2579: Textual Conventions for SMIv2" 317 ::= { snmpDomains 8 } 319 snmpDTLSUDPDomain OBJECT-IDENTITY 320 STATUS current 321 DESCRIPTION 322 "The SNMP over DTLS via UDP transport domain. The 323 corresponding transport address is of type SnmpTLSAddress. 325 The securityName prefix to be associated with the 326 snmpDTLSUDPDomain is 'dtls'. This prefix MAY be used by 327 security models or other components to identify which secure 328 transport infrastructure authenticated a securityName." 329 REFERENCE 330 "RFC 2579: Textual Conventions for SMIv2" 331 ::= { snmpDomains 9 } 333 SnmpTLSAddress ::= TEXTUAL-CONVENTION 334 DISPLAY-HINT "1a" 335 STATUS current 336 DESCRIPTION 337 "Represents an IPv4 address, an IPv6 address, or a 338 US-ASCII-encoded hostname and port number. 340 An IPv4 address MUST be in dotted decimal format followed by a 341 colon ':' (US-ASCII character 0x3A) and a decimal port number 342 in US-ASCII. 344 An IPv6 address MUST be a colon-separated format (as described 345 in RFC 5952), surrounded by square brackets ('[', US-ASCII 346 character 0x5B, and ']', US-ASCII character 0x5D), followed by 347 a colon ':' (US-ASCII character 0x3A) and a decimal port number 348 in US-ASCII. 350 A hostname is always in US-ASCII (as per RFC 1123); 351 internationalized hostnames are encoded as A-labels as specified 352 in RFC 5890. The hostname is followed by a 353 colon ':' (US-ASCII character 0x3A) and a decimal port number 354 in US-ASCII. The name SHOULD be fully qualified whenever 355 possible. 357 Values of this textual convention MUST NOT be directly usable 358 as transport-layer addressing information, and may require 359 run-time resolution. As such, applications that write them 360 MUST be prepared for handling errors if such values are not 361 supported, or cannot be resolved (if resolution occurs at the 362 time of the management operation). 364 The DESCRIPTION clause of TransportAddress objects that may 365 have SnmpTLSAddress values MUST fully describe how (and 366 when) such names are to be resolved to IP addresses and vice 367 versa. 369 This textual convention SHOULD NOT be used directly in object 370 definitions since it restricts addresses to a specific 371 format. However, if it is used, it MAY be used either on its 372 own or in conjunction with TransportAddressType or 373 TransportDomain as a pair. 375 When this textual convention is used as a syntax of an index 376 object, there may be issues with the limit of 128 377 sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED 378 that all MIB documents using this textual convention make 379 explicit any limitations on index component lengths that 380 management software MUST observe. This MAY be done either by 382 including SIZE constraints on the index components or by 383 specifying applicable constraints in the conceptual row 384 DESCRIPTION clause or in the surrounding documentation." 385 REFERENCE 386 "RFC 1123: Requirements for Internet Hosts - Application and 387 Support 388 RFC 5890: Internationalized Domain Names for Applications (IDNA): 389 Definitions and Document Framework 390 RFC 5952: A Recommendation for IPv6 Address Text Representation 391 " 392 SYNTAX OCTET STRING (SIZE (1..255)) 394 SnmpTLSFingerprint ::= TEXTUAL-CONVENTION 395 DISPLAY-HINT "1x:1x" 396 STATUS current 397 DESCRIPTION 398 "A fingerprint value that can be used to uniquely reference 399 other data of potentially arbitrary length. 401 An SnmpTLSFingerprint value is composed of a 1-octet hashing 402 algorithm identifier followed by the fingerprint value. The 403 octet value encoded is based on the IANA TLS HashAlgorithm 404 Registry (RFC 5246), However, this registry is only applicable 405 to (D)TLS protocol versions prior to 1.3, which are now 406 designated as obsolete and are not expected to ever support 407 additional values. To allow the fingerprint algorithm to support 408 additional hashing algorithms that might be used by later 409 versions of (D)TLS, the octet value encoded is taken from IANA 410 SNMP-TLSTM HashAlgorithm Registry, The initial values within 411 this registry are identical to the values in the TLS 412 HashAlgorithm registry but can be extended to support new 413 hashing algorithms as needed. 415 This TEXTUAL-CONVENTION allows for a zero-length (blank) 416 SnmpTLSFingerprint value for use in tables where the 417 fingerprint value MAY be optional. MIB definitions or 418 implementations MAY refuse to accept a zero-length value as 419 appropriate." 420 REFERENCE "http://www.iana.org/assignments/tlstm-parameters/" 421 SYNTAX OCTET STRING (SIZE (0..255)) 423 -- Identities for use in the snmpTlstmCertToTSNTable 425 snmpTlstmCertToTSNMIdentities OBJECT IDENTIFIER 426 ::= { snmpTlstmIdentities 1 } 428 snmpTlstmCertSpecified OBJECT-IDENTITY 429 STATUS current 430 DESCRIPTION "Directly specifies the tmSecurityName to be used for 431 this certificate. The value of the tmSecurityName 432 to use is specified in the snmpTlstmCertToTSNData 433 column. The snmpTlstmCertToTSNData column MUST 434 contain a non-zero length SnmpAdminString compliant 436 value or the mapping described in this row MUST be 437 considered a failure." 438 ::= { snmpTlstmCertToTSNMIdentities 1 } 440 snmpTlstmCertSANRFC822Name OBJECT-IDENTITY 441 STATUS current 442 DESCRIPTION "Maps a subjectAltName's rfc822Name to a 443 tmSecurityName. The local part of the rfc822Name is 444 passed unaltered but the host-part of the name MUST 445 be passed in lowercase. This mapping results in a 446 1:1 correspondence between equivalent subjectAltName 447 rfc822Name values and tmSecurityName values except 448 that the host-part of the name MUST be passed in 449 lowercase. 451 Example rfc822Name Field: FooBar@Example.COM 452 is mapped to tmSecurityName: FooBar@example.com." 453 ::= { snmpTlstmCertToTSNMIdentities 2 } 455 snmpTlstmCertSANDNSName OBJECT-IDENTITY 456 STATUS current 457 DESCRIPTION "Maps a subjectAltName's dNSName to a 458 tmSecurityName after first converting it to all 459 lowercase (RFC 5280 does not specify converting to 460 lowercase so this involves an extra step). This 461 mapping results in a 1:1 correspondence between 462 subjectAltName dNSName values and the tmSecurityName 463 values." 464 REFERENCE "RFC 5280 - Internet X.509 Public Key Infrastructure 465 Certificate and Certificate Revocation 466 List (CRL) Profile." 467 ::= { snmpTlstmCertToTSNMIdentities 3 } 469 snmpTlstmCertSANIpAddress OBJECT-IDENTITY 470 STATUS current 471 DESCRIPTION "Maps a subjectAltName's iPAddress to a 472 tmSecurityName by transforming the binary encoded 473 address as follows: 475 1) for IPv4, the value is converted into a 476 decimal-dotted quad address (e.g., '192.0.2.1'). 478 2) for IPv6 addresses, the value is converted into a 479 32-character all lowercase hexadecimal string 480 without any colon separators. 482 This mapping results in a 1:1 correspondence between 483 subjectAltName iPAddress values and the 484 tmSecurityName values. 486 The resulting length of an encoded IPv6 address is 487 the maximum length supported by the View-Based 488 Access Control Model (VACM). Using both the 489 Transport Security Model's support for transport 490 prefixes (see the SNMP-TSM-MIB's 491 snmpTsmConfigurationUsePrefix object for details) 492 will result in securityName lengths that exceed what 493 VACM can handle." 494 ::= { snmpTlstmCertToTSNMIdentities 4 } 496 snmpTlstmCertSANAny OBJECT-IDENTITY 497 STATUS current 498 DESCRIPTION "Maps any of the following fields using the 499 corresponding mapping algorithms: 501 |------------+----------------------------| 502 | Type | Algorithm | 503 |------------+----------------------------| 504 | rfc822Name | snmpTlstmCertSANRFC822Name | 505 | dNSName | snmpTlstmCertSANDNSName | 506 | iPAddress | snmpTlstmCertSANIpAddress | 507 |------------+----------------------------| 509 The first matching subjectAltName value found in the 510 certificate of the above types MUST be used when 511 deriving the tmSecurityName. The mapping algorithm 512 specified in the 'Algorithm' column MUST be used to 513 derive the tmSecurityName. 515 This mapping results in a 1:1 correspondence between 516 subjectAltName values and tmSecurityName values. The 517 three sub-mapping algorithms produced by this 518 combined algorithm cannot produce conflicting 519 results between themselves." 520 ::= { snmpTlstmCertToTSNMIdentities 5 } 522 snmpTlstmCertCommonName OBJECT-IDENTITY 523 STATUS current 524 DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName 525 after converting it to a UTF-8 encoding. The usage 526 of CommonNames is deprecated and users are 527 encouraged to use subjectAltName mapping methods 528 instead. This mapping results in a 1:1 529 correspondence between certificate CommonName values 530 and tmSecurityName values." 531 ::= { snmpTlstmCertToTSNMIdentities 6 } 533 -- The snmpTlstmSession Group 535 snmpTlstmSession OBJECT IDENTIFIER ::= { snmpTlstmObjects 1 } 537 snmpTlstmSessionOpens OBJECT-TYPE 538 SYNTAX Counter32 539 MAX-ACCESS read-only 540 STATUS current 541 DESCRIPTION 542 "The number of times an openSession() request has been executed 543 as a (D)TLS client, regardless of whether it succeeded or 544 failed." 545 ::= { snmpTlstmSession 1 } 547 snmpTlstmSessionClientCloses OBJECT-TYPE 548 SYNTAX Counter32 549 MAX-ACCESS read-only 550 STATUS current 551 DESCRIPTION 552 "The number of times a closeSession() request has been 553 executed as a (D)TLS client, regardless of whether it 554 succeeded or failed." 555 ::= { snmpTlstmSession 2 } 557 snmpTlstmSessionOpenErrors OBJECT-TYPE 558 SYNTAX Counter32 559 MAX-ACCESS read-only 560 STATUS current 561 DESCRIPTION 562 "The number of times an openSession() request failed to open a 563 session as a (D)TLS client, for any reason." 564 ::= { snmpTlstmSession 3 } 566 snmpTlstmSessionAccepts OBJECT-TYPE 567 SYNTAX Counter32 568 MAX-ACCESS read-only 569 STATUS current 570 DESCRIPTION 571 "The number of times a (D)TLS server has accepted a new 572 connection from a client and has received at least one SNMP 573 message through it." 574 ::= { snmpTlstmSession 4 } 576 snmpTlstmSessionServerCloses OBJECT-TYPE 577 SYNTAX Counter32 578 MAX-ACCESS read-only 579 STATUS current 580 DESCRIPTION 581 "The number of times a closeSession() request has been 582 executed as a (D)TLS server, regardless of whether it 583 succeeded or failed." 584 ::= { snmpTlstmSession 5 } 586 snmpTlstmSessionNoSessions OBJECT-TYPE 587 SYNTAX Counter32 588 MAX-ACCESS read-only 589 STATUS current 590 DESCRIPTION 591 "The number of times an outgoing message was dropped because 592 the session associated with the passed tmStateReference was no 593 longer (or was never) available." 594 ::= { snmpTlstmSession 6 } 596 snmpTlstmSessionInvalidClientCertificates OBJECT-TYPE 597 SYNTAX Counter32 598 MAX-ACCESS read-only 599 STATUS current 600 DESCRIPTION 601 "The number of times an incoming session was not established 602 on a (D)TLS server because the presented client certificate 603 was invalid. Reasons for invalidation include, but are not 604 limited to, cryptographic validation failures or lack of a 605 suitable mapping row in the snmpTlstmCertToTSNTable." 606 ::= { snmpTlstmSession 7 } 608 snmpTlstmSessionUnknownServerCertificate OBJECT-TYPE 609 SYNTAX Counter32 610 MAX-ACCESS read-only 611 STATUS current 612 DESCRIPTION 613 "The number of times an outgoing session was not established 614 on a (D)TLS client because the server certificate presented 615 by an SNMP over (D)TLS server was invalid because no 616 configured fingerprint or Certification Authority (CA) was 617 acceptable to validate it. 618 This may result because there was no entry in the 619 snmpTlstmAddrTable or because no path could be found to a 620 known CA." 621 ::= { snmpTlstmSession 8 } 623 snmpTlstmSessionInvalidServerCertificates OBJECT-TYPE 624 SYNTAX Counter32 625 MAX-ACCESS read-only 626 STATUS current 627 DESCRIPTION 628 "The number of times an outgoing session was not established 629 on a (D)TLS client because the server certificate presented 630 by an SNMP over (D)TLS server could not be validated even if 631 the fingerprint or expected validation path was known. That 632 is, a cryptographic validation error occurred during 633 certificate validation processing. 635 Reasons for invalidation include, but are not 636 limited to, cryptographic validation failures." 637 ::= { snmpTlstmSession 9 } 639 snmpTlstmSessionInvalidCaches OBJECT-TYPE 640 SYNTAX Counter32 641 MAX-ACCESS read-only 642 STATUS current 643 DESCRIPTION 644 "The number of outgoing messages dropped because the 645 tmStateReference referred to an invalid cache." 646 ::= { snmpTlstmSession 10 } 648 -- Configuration Objects 650 snmpTlstmConfig OBJECT IDENTIFIER ::= { snmpTlstmObjects 2 } 652 -- Certificate mapping 654 snmpTlstmCertificateMapping OBJECT IDENTIFIER ::= { snmpTlstmConfig 1 } 656 snmpTlstmCertToTSNCount OBJECT-TYPE 657 SYNTAX Gauge32 658 MAX-ACCESS read-only 659 STATUS current 660 DESCRIPTION 661 "A count of the number of entries in the 662 snmpTlstmCertToTSNTable." 663 ::= { snmpTlstmCertificateMapping 1 } 665 snmpTlstmCertToTSNTableLastChanged OBJECT-TYPE 666 SYNTAX TimeStamp 667 MAX-ACCESS read-only 668 STATUS current 669 DESCRIPTION 670 "The value of sysUpTime.0 when the snmpTlstmCertToTSNTable was 671 last modified through any means, or 0 if it has not been 672 modified since the command responder was started." 674 ::= { snmpTlstmCertificateMapping 2 } 676 snmpTlstmCertToTSNTable OBJECT-TYPE 677 SYNTAX SEQUENCE OF SnmpTlstmCertToTSNEntry 678 MAX-ACCESS not-accessible 679 STATUS current 680 DESCRIPTION 681 "This table is used by a (D)TLS server to map the (D)TLS 682 client's presented X.509 certificate to a tmSecurityName. 684 On an incoming (D)TLS/SNMP connection, the client's presented 685 certificate MUST either be validated based on an established 686 trust anchor, or it MUST directly match a fingerprint in this 687 table. This table does not provide any mechanisms for 688 configuring the trust anchors; the transfer of any needed 689 trusted certificates for path validation is expected to occur 690 through an out-of-band transfer. 692 Once the certificate has been found acceptable (either by path 693 validation or directly matching a fingerprint in this table), 694 this table is consulted to determine the appropriate 695 tmSecurityName to identify with the remote connection. This 696 is done by considering each active row from this table in 697 prioritized order according to its snmpTlstmCertToTSNID value. 698 Each row's snmpTlstmCertToTSNFingerprint value determines 699 whether the row is a match for the incoming connection: 701 1) If the row's snmpTlstmCertToTSNFingerprint value 702 identifies the presented certificate, then consider the 703 row as a successful match. 705 2) If the row's snmpTlstmCertToTSNFingerprint value 706 identifies a locally held copy of a trusted CA 707 certificate and that CA certificate was used to 708 validate the path to the presented certificate, then 709 consider the row as a successful match. 711 Once a matching row has been found, the 712 snmpTlstmCertToTSNMapType value can be used to determine how 713 the tmSecurityName to associate with the session should be 714 determined. See the snmpTlstmCertToTSNMapType column's 715 DESCRIPTION for details on determining the tmSecurityName 716 value. If it is impossible to determine a tmSecurityName from 717 the row's data combined with the data presented in the 719 certificate, then additional rows MUST be searched looking for 720 another potential match. If a resulting tmSecurityName mapped 721 from a given row is not compatible with the needed 722 requirements of a tmSecurityName (e.g., VACM imposes a 723 32-octet-maximum length and the certificate derived 724 securityName could be longer), then it MUST be considered an 725 invalid match and additional rows MUST be searched looking for 726 another potential match. 728 If no matching and valid row can be found, the connection MUST 729 be closed and SNMP messages MUST NOT be accepted over it. 731 Missing values of snmpTlstmCertToTSNID are acceptable and 732 implementations SHOULD continue to the next highest numbered 733 row. It is RECOMMENDED that administrators skip index values 734 to leave room for the insertion of future rows (for example, 735 use values of 10 and 20 when creating initial rows). 737 Users are encouraged to make use of certificates with 738 subjectAltName fields that can be used as tmSecurityNames so 739 that a single root CA certificate can allow all child 740 certificate's subjectAltName to map directly to a 741 tmSecurityName via a 1:1 transformation. However, this table 742 is flexible to allow for situations where existing deployed 743 certificate infrastructures do not provide adequate 744 subjectAltName values for use as tmSecurityNames. 745 Certificates MAY also be mapped to tmSecurityNames using the 746 CommonName portion of the Subject field. However, the usage 747 of the CommonName field is deprecated and thus this usage is 748 NOT RECOMMENDED. Direct mapping from each individual 749 certificate fingerprint to a tmSecurityName is also possible 750 but requires one entry in the table per tmSecurityName and 751 requires more management operations to completely configure a 752 device." 753 ::= { snmpTlstmCertificateMapping 3 } 755 snmpTlstmCertToTSNEntry OBJECT-TYPE 756 SYNTAX SnmpTlstmCertToTSNEntry 757 MAX-ACCESS not-accessible 758 STATUS current 759 DESCRIPTION 760 "A row in the snmpTlstmCertToTSNTable that specifies a mapping 761 for an incoming (D)TLS certificate to a tmSecurityName to use 762 for a connection." 763 INDEX { snmpTlstmCertToTSNID } 764 ::= { snmpTlstmCertToTSNTable 1 } 766 SnmpTlstmCertToTSNEntry ::= SEQUENCE { 767 snmpTlstmCertToTSNID Unsigned32, 768 snmpTlstmCertToTSNFingerprint SnmpTLSFingerprint, 769 snmpTlstmCertToTSNMapType AutonomousType, 770 snmpTlstmCertToTSNData OCTET STRING, 771 snmpTlstmCertToTSNStorageType StorageType, 772 snmpTlstmCertToTSNRowStatus RowStatus 773 } 775 snmpTlstmCertToTSNID OBJECT-TYPE 776 SYNTAX Unsigned32 (1..4294967295) 777 MAX-ACCESS not-accessible 778 STATUS current 779 DESCRIPTION 780 "A unique, prioritized index for the given entry. Lower 781 numbers indicate a higher priority." 782 ::= { snmpTlstmCertToTSNEntry 1 } 784 snmpTlstmCertToTSNFingerprint OBJECT-TYPE 785 SYNTAX SnmpTLSFingerprint (SIZE(1..255)) 786 MAX-ACCESS read-create 787 STATUS current 788 DESCRIPTION 789 "A cryptographic hash of an X.509 certificate. The results of 790 a successful matching fingerprint to either the trusted CA in 791 the certificate validation path or to the certificate itself 792 is dictated by the snmpTlstmCertToTSNMapType column." 793 ::= { snmpTlstmCertToTSNEntry 2 } 795 snmpTlstmCertToTSNMapType OBJECT-TYPE 796 SYNTAX AutonomousType 797 MAX-ACCESS read-create 798 STATUS current 799 DESCRIPTION 800 "Specifies the mapping type for deriving a tmSecurityName from 801 a certificate. Details for mapping of a particular type SHALL 802 be specified in the DESCRIPTION clause of the OBJECT-IDENTITY 803 that describes the mapping. If a mapping succeeds it will 804 return a tmSecurityName for use by the TLSTM model and 805 processing stops. 807 If the resulting mapped value is not compatible with the 808 needed requirements of a tmSecurityName (e.g., VACM imposes a 809 32-octet-maximum length and the certificate derived 810 securityName could be longer), then future rows MUST be 811 searched for additional snmpTlstmCertToTSNFingerprint matches 812 to look for a mapping that succeeds. 814 Suitable values for assigning to this object that are defined 815 within the SNMP-TLS-TM-MIB can be found in the 816 snmpTlstmCertToTSNMIdentities portion of the MIB tree." 817 DEFVAL { snmpTlstmCertSpecified } 818 ::= { snmpTlstmCertToTSNEntry 3 } 820 snmpTlstmCertToTSNData OBJECT-TYPE 821 SYNTAX OCTET STRING (SIZE(0..1024)) 822 MAX-ACCESS read-create 823 STATUS current 824 DESCRIPTION 825 "Auxiliary data used as optional configuration information for 826 a given mapping specified by the snmpTlstmCertToTSNMapType 827 column. Only some mapping systems will make use of this 828 column. The value in this column MUST be ignored for any 829 mapping type that does not require data present in this 830 column." 831 DEFVAL { "" } 832 ::= { snmpTlstmCertToTSNEntry 4 } 834 snmpTlstmCertToTSNStorageType OBJECT-TYPE 835 SYNTAX StorageType 836 MAX-ACCESS read-create 837 STATUS current 838 DESCRIPTION 839 "The storage type for this conceptual row. Conceptual rows 840 having the value 'permanent' need not allow write-access to 841 any columnar objects in the row." 842 DEFVAL { nonVolatile } 843 ::= { snmpTlstmCertToTSNEntry 5 } 845 snmpTlstmCertToTSNRowStatus OBJECT-TYPE 846 SYNTAX RowStatus 847 MAX-ACCESS read-create 848 STATUS current 849 DESCRIPTION 850 "The status of this conceptual row. This object MAY be used 851 to create or remove rows from this table. 853 To create a row in this table, an administrator MUST set this 854 object to either createAndGo(4) or createAndWait(5). 856 Until instances of all corresponding columns are appropriately 857 configured, the value of the corresponding instance of the 858 snmpTlstmParamsRowStatus column is notReady(3). 860 In particular, a newly created row cannot be made active until 861 the corresponding snmpTlstmCertToTSNFingerprint, 862 snmpTlstmCertToTSNMapType, and snmpTlstmCertToTSNData columns 863 have been set. 865 The following objects MUST NOT be modified while the 866 value of this object is active(1): 867 - snmpTlstmCertToTSNFingerprint 868 - snmpTlstmCertToTSNMapType 869 - snmpTlstmCertToTSNData 870 An attempt to set these objects while the value of 871 snmpTlstmParamsRowStatus is active(1) will result in 872 an inconsistentValue error." 873 ::= { snmpTlstmCertToTSNEntry 6 } 875 -- Maps tmSecurityNames to certificates for use by the SNMP-TARGET-MIB 877 snmpTlstmParamsCount OBJECT-TYPE 878 SYNTAX Gauge32 879 MAX-ACCESS read-only 880 STATUS current 881 DESCRIPTION 882 "A count of the number of entries in the snmpTlstmParamsTable." 883 ::= { snmpTlstmCertificateMapping 4 } 885 snmpTlstmParamsTableLastChanged OBJECT-TYPE 886 SYNTAX TimeStamp 887 MAX-ACCESS read-only 888 STATUS current 889 DESCRIPTION 890 "The value of sysUpTime.0 when the snmpTlstmParamsTable 891 was last modified through any means, or 0 if it has not been 892 modified since the command responder was started." 893 ::= { snmpTlstmCertificateMapping 5 } 895 snmpTlstmParamsTable OBJECT-TYPE 896 SYNTAX SEQUENCE OF SnmpTlstmParamsEntry 897 MAX-ACCESS not-accessible 898 STATUS current 899 DESCRIPTION 900 "This table is used by a (D)TLS client when a (D)TLS 901 connection is being set up using an entry in the 902 SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's 903 snmpTargetParamsTable with a fingerprint of a certificate to 904 use when establishing such a (D)TLS connection." 905 ::= { snmpTlstmCertificateMapping 6 } 907 snmpTlstmParamsEntry OBJECT-TYPE 908 SYNTAX SnmpTlstmParamsEntry 909 MAX-ACCESS not-accessible 910 STATUS current 911 DESCRIPTION 912 "A conceptual row containing a fingerprint hash of a locally 913 held certificate for a given snmpTargetParamsEntry. The 914 values in this row SHOULD be ignored if the connection that 915 needs to be established, as indicated by the SNMP-TARGET-MIB 916 infrastructure, is not a certificate and (D)TLS based 917 connection. The connection SHOULD NOT be established if the 918 certificate fingerprint stored in this entry does not point to 919 a valid locally held certificate or if it points to an 920 unusable certificate (such as might happen when the 921 certificate's expiration date has been reached)." 922 INDEX { IMPLIED snmpTargetParamsName } 923 ::= { snmpTlstmParamsTable 1 } 925 SnmpTlstmParamsEntry ::= SEQUENCE { 926 snmpTlstmParamsClientFingerprint SnmpTLSFingerprint, 927 snmpTlstmParamsStorageType StorageType, 928 snmpTlstmParamsRowStatus RowStatus 929 } 931 snmpTlstmParamsClientFingerprint OBJECT-TYPE 932 SYNTAX SnmpTLSFingerprint 933 MAX-ACCESS read-create 934 STATUS current 935 DESCRIPTION 936 "This object stores the hash of the public portion of a 937 locally held X.509 certificate. The X.509 certificate, its 938 public key, and the corresponding private key will be used 939 when initiating a (D)TLS connection as a (D)TLS client." 940 ::= { snmpTlstmParamsEntry 1 } 942 snmpTlstmParamsStorageType OBJECT-TYPE 943 SYNTAX StorageType 944 MAX-ACCESS read-create 945 STATUS current 946 DESCRIPTION 947 "The storage type for this conceptual row. Conceptual rows 948 having the value 'permanent' need not allow write-access to 949 any columnar objects in the row." 950 DEFVAL { nonVolatile } 951 ::= { snmpTlstmParamsEntry 2 } 953 snmpTlstmParamsRowStatus OBJECT-TYPE 954 SYNTAX RowStatus 955 MAX-ACCESS read-create 956 STATUS current 957 DESCRIPTION 958 "The status of this conceptual row. This object MAY be used 959 to create or remove rows from this table. 961 To create a row in this table, an administrator MUST set this 962 object to either createAndGo(4) or createAndWait(5). 964 Until instances of all corresponding columns are appropriately 965 configured, the value of the corresponding instance of the 966 snmpTlstmParamsRowStatus column is notReady(3). 968 In particular, a newly created row cannot be made active until 969 the corresponding snmpTlstmParamsClientFingerprint column has 970 been set. 972 The snmpTlstmParamsClientFingerprint object MUST NOT be modified 973 while the value of this object is active(1). 975 An attempt to set these objects while the value of 976 snmpTlstmParamsRowStatus is active(1) will result in 977 an inconsistentValue error." 978 ::= { snmpTlstmParamsEntry 3 } 980 snmpTlstmAddrCount OBJECT-TYPE 981 SYNTAX Gauge32 982 MAX-ACCESS read-only 983 STATUS current 984 DESCRIPTION 985 "A count of the number of entries in the snmpTlstmAddrTable." 986 ::= { snmpTlstmCertificateMapping 7 } 988 snmpTlstmAddrTableLastChanged OBJECT-TYPE 989 SYNTAX TimeStamp 990 MAX-ACCESS read-only 991 STATUS current 992 DESCRIPTION 993 "The value of sysUpTime.0 when the snmpTlstmAddrTable 994 was last modified through any means, or 0 if it has not been 995 modified since the command responder was started." 996 ::= { snmpTlstmCertificateMapping 8 } 998 snmpTlstmAddrTable OBJECT-TYPE 999 SYNTAX SEQUENCE OF SnmpTlstmAddrEntry 1000 MAX-ACCESS not-accessible 1001 STATUS current 1002 DESCRIPTION 1003 "This table is used by a (D)TLS client when a (D)TLS 1004 connection is being set up using an entry in the 1005 SNMP-TARGET-MIB. It extends the SNMP-TARGET-MIB's 1007 snmpTargetAddrTable so that the client can verify that the 1008 correct server has been reached. This verification can use 1009 either a certificate fingerprint, or an identity 1010 authenticated via certification path validation. 1012 If there is an active row in this table corresponding to the 1013 entry in the SNMP-TARGET-MIB that was used to establish the 1014 connection, and the row's snmpTlstmAddrServerFingerprint 1015 column has non-empty value, then the server's presented 1016 certificate is compared with the 1017 snmpTlstmAddrServerFingerprint value (and the 1018 snmpTlstmAddrServerIdentity column is ignored). If the 1019 fingerprint matches, the verification has succeeded. If the 1020 fingerprint does not match, then the connection MUST be 1021 closed. 1023 If the server's presented certificate has passed 1024 certification path validation [RFC5280] to a configured 1025 trust anchor, and an active row exists with a zero-length 1026 snmpTlstmAddrServerFingerprint value, then the 1027 snmpTlstmAddrServerIdentity column contains the expected 1028 host name. This expected host name is then compared against 1029 the server's certificate as follows: 1031 - Implementations MUST support matching the expected host 1032 name against a dNSName in the subjectAltName extension 1033 field and MAY support checking the name against the 1034 CommonName portion of the subject distinguished name. 1036 - The '*' (ASCII 0x2a) wildcard character is allowed in the 1037 dNSName of the subjectAltName extension (and in common 1038 name, if used to store the host name), but only as the 1039 left-most (least significant) DNS label in that value. 1040 This wildcard matches any left-most DNS label in the 1041 server name. That is, the subject *.example.com matches 1042 the server names a.example.com and b.example.com, but does 1043 not match example.com or a.b.example.com. Implementations 1044 MUST support wildcards in certificates as specified above, 1045 but MAY provide a configuration option to disable them. 1047 - If the locally configured name is an internationalized 1048 domain name, conforming implementations MUST convert it to 1049 the ASCII Compatible Encoding (ACE) format for performing 1050 comparisons, as specified in Section 7 of [RFC5280]. 1052 If the expected host name fails these conditions then the 1053 connection MUST be closed. 1055 If there is no row in this table corresponding to the entry 1056 in the SNMP-TARGET-MIB and the server can be authorized by 1057 another, implementation-dependent means, then the connection 1058 MAY still proceed." 1059 ::= { snmpTlstmCertificateMapping 9 } 1061 snmpTlstmAddrEntry OBJECT-TYPE 1062 SYNTAX SnmpTlstmAddrEntry 1063 MAX-ACCESS not-accessible 1064 STATUS current 1065 DESCRIPTION 1066 "A conceptual row containing a copy of a certificate's 1067 fingerprint for a given snmpTargetAddrEntry. The values in 1068 this row SHOULD be ignored if the connection that needs to be 1069 established, as indicated by the SNMP-TARGET-MIB 1070 infrastructure, is not a (D)TLS based connection. If an 1071 snmpTlstmAddrEntry exists for a given snmpTargetAddrEntry, then 1072 the presented server certificate MUST match or the connection 1073 MUST NOT be established. If a row in this table does not 1074 exist to match an snmpTargetAddrEntry row, then the connection 1075 SHOULD still proceed if some other certificate validation path 1076 algorithm (e.g., RFC 5280) can be used." 1077 INDEX { IMPLIED snmpTargetAddrName } 1078 ::= { snmpTlstmAddrTable 1 } 1080 SnmpTlstmAddrEntry ::= SEQUENCE { 1081 snmpTlstmAddrServerFingerprint SnmpTLSFingerprint, 1082 snmpTlstmAddrServerIdentity SnmpAdminString, 1083 snmpTlstmAddrStorageType StorageType, 1084 snmpTlstmAddrRowStatus RowStatus 1085 } 1087 snmpTlstmAddrServerFingerprint OBJECT-TYPE 1088 SYNTAX SnmpTLSFingerprint 1089 MAX-ACCESS read-create 1090 STATUS current 1091 DESCRIPTION 1092 "A cryptographic hash of a public X.509 certificate. This 1093 object should store the hash of the public X.509 certificate 1094 that the remote server should present during the (D)TLS 1095 connection setup. The fingerprint of the presented 1096 certificate and this hash value MUST match exactly or the 1097 connection MUST NOT be established." 1098 DEFVAL { "" } 1099 ::= { snmpTlstmAddrEntry 1 } 1101 snmpTlstmAddrServerIdentity OBJECT-TYPE 1102 SYNTAX SnmpAdminString 1103 MAX-ACCESS read-create 1104 STATUS current 1105 DESCRIPTION 1106 "The reference identity to check against the identity 1107 presented by the remote system." 1108 DEFVAL { "" } 1109 ::= { snmpTlstmAddrEntry 2 } 1111 snmpTlstmAddrStorageType OBJECT-TYPE 1112 SYNTAX StorageType 1113 MAX-ACCESS read-create 1114 STATUS current 1115 DESCRIPTION 1116 "The storage type for this conceptual row. Conceptual rows 1117 having the value 'permanent' need not allow write-access to 1118 any columnar objects in the row." 1119 DEFVAL { nonVolatile } 1120 ::= { snmpTlstmAddrEntry 3 } 1122 snmpTlstmAddrRowStatus OBJECT-TYPE 1123 SYNTAX RowStatus 1124 MAX-ACCESS read-create 1125 STATUS current 1126 DESCRIPTION 1127 "The status of this conceptual row. This object may be used 1128 to create or remove rows from this table. 1130 To create a row in this table, an administrator MUST set this 1131 object to either createAndGo(4) or createAndWait(5). 1133 Until instances of all corresponding columns are 1134 appropriately configured, the value of the 1135 corresponding instance of the snmpTlstmAddrRowStatus 1136 column is notReady(3). 1138 In particular, a newly created row cannot be made active until 1139 the corresponding snmpTlstmAddrServerFingerprint column has been 1140 set. 1142 Rows MUST NOT be active if the snmpTlstmAddrServerFingerprint 1143 column is blank and the snmpTlstmAddrServerIdentity is set to 1144 '*' since this would insecurely accept any presented 1145 certificate. 1147 The snmpTlstmAddrServerFingerprint object MUST NOT be modified 1148 while the value of this object is active(1). 1150 An attempt to set these objects while the value of 1151 snmpTlstmAddrRowStatus is active(1) will result in 1152 an inconsistentValue error." 1153 ::= { snmpTlstmAddrEntry 4 } 1155 -- ************************************************ 1156 -- snmpTlstmNotifications - Notifications Information 1157 -- ************************************************ 1159 snmpTlstmServerCertificateUnknown NOTIFICATION-TYPE 1160 OBJECTS { snmpTlstmSessionUnknownServerCertificate } 1161 STATUS current 1162 DESCRIPTION 1163 "Notification that the server certificate presented by an SNMP 1164 over (D)TLS server was invalid because no configured 1165 fingerprint or CA was acceptable to validate it. This may be 1166 because there was no entry in the snmpTlstmAddrTable or 1167 because no path could be found to known Certification 1168 Authority. 1170 To avoid notification loops, this notification MUST NOT be 1171 sent to servers that themselves have triggered the 1172 notification." 1173 ::= { snmpTlstmNotifications 1 } 1175 snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE 1176 OBJECTS { snmpTlstmAddrServerFingerprint, 1177 snmpTlstmSessionInvalidServerCertificates} 1178 STATUS current 1179 DESCRIPTION 1180 "Notification that the server certificate presented by an SNMP 1181 over (D)TLS server could not be validated even if the 1182 fingerprint or expected validation path was known. That is, a 1183 cryptographic validation error occurred during certificate 1184 validation processing. 1186 To avoid notification loops, this notification MUST NOT be 1187 sent to servers that themselves have triggered the 1188 notification." 1189 ::= { snmpTlstmNotifications 2 } 1191 -- ************************************************ 1192 -- snmpTlstmCompliances - Conformance Information 1193 -- ************************************************ 1195 snmpTlstmCompliances OBJECT IDENTIFIER ::= { snmpTlstmConformance 1 } 1197 snmpTlstmGroups OBJECT IDENTIFIER ::= { snmpTlstmConformance 2 } 1199 -- ************************************************ 1200 -- Compliance statements 1201 -- ************************************************ 1202 snmpTlstmCompliance MODULE-COMPLIANCE 1203 STATUS current 1204 DESCRIPTION 1205 "The compliance statement for SNMP engines that support the 1206 SNMP-TLS-TM-MIB" 1207 MODULE 1208 MANDATORY-GROUPS { snmpTlstmStatsGroup, 1209 snmpTlstmIncomingGroup, 1210 snmpTlstmOutgoingGroup, 1211 snmpTlstmNotificationGroup } 1212 ::= { snmpTlstmCompliances 1 } 1214 -- ************************************************ 1215 -- Units of conformance 1216 -- ************************************************ 1217 snmpTlstmStatsGroup OBJECT-GROUP 1218 OBJECTS { 1219 snmpTlstmSessionOpens, 1220 snmpTlstmSessionClientCloses, 1221 snmpTlstmSessionOpenErrors, 1222 snmpTlstmSessionAccepts, 1223 snmpTlstmSessionServerCloses, 1224 snmpTlstmSessionNoSessions, 1225 snmpTlstmSessionInvalidClientCertificates, 1226 snmpTlstmSessionUnknownServerCertificate, 1227 snmpTlstmSessionInvalidServerCertificates, 1228 snmpTlstmSessionInvalidCaches 1229 } 1230 STATUS current 1231 DESCRIPTION 1232 "A collection of objects for maintaining 1233 statistical information of an SNMP engine that 1234 implements the SNMP TLS Transport Model." 1235 ::= { snmpTlstmGroups 1 } 1237 snmpTlstmIncomingGroup OBJECT-GROUP 1238 OBJECTS { 1239 snmpTlstmCertToTSNCount, 1240 snmpTlstmCertToTSNTableLastChanged, 1241 snmpTlstmCertToTSNFingerprint, 1242 snmpTlstmCertToTSNMapType, 1243 snmpTlstmCertToTSNData, 1244 snmpTlstmCertToTSNStorageType, 1245 snmpTlstmCertToTSNRowStatus 1246 } 1247 STATUS current 1248 DESCRIPTION 1249 "A collection of objects for maintaining 1250 incoming connection certificate mappings to 1251 tmSecurityNames of an SNMP engine that implements the 1252 SNMP TLS Transport Model." 1253 ::= { snmpTlstmGroups 2 } 1255 snmpTlstmOutgoingGroup OBJECT-GROUP 1256 OBJECTS { 1257 snmpTlstmParamsCount, 1258 snmpTlstmParamsTableLastChanged, 1259 snmpTlstmParamsClientFingerprint, 1260 snmpTlstmParamsStorageType, 1261 snmpTlstmParamsRowStatus, 1262 snmpTlstmAddrCount, 1263 snmpTlstmAddrTableLastChanged, 1264 snmpTlstmAddrServerFingerprint, 1265 snmpTlstmAddrServerIdentity, 1266 snmpTlstmAddrStorageType, 1267 snmpTlstmAddrRowStatus 1268 } 1269 STATUS current 1270 DESCRIPTION 1271 "A collection of objects for maintaining 1272 outgoing connection certificates to use when opening 1273 connections as a result of SNMP-TARGET-MIB settings." 1274 ::= { snmpTlstmGroups 3 } 1276 snmpTlstmNotificationGroup NOTIFICATION-GROUP 1277 NOTIFICATIONS { 1278 snmpTlstmServerCertificateUnknown, 1279 snmpTlstmServerInvalidCertificate 1280 } 1281 STATUS current 1282 DESCRIPTION 1283 "Notifications" 1284 ::= { snmpTlstmGroups 4 } 1286 END 1288 5. Security Considerations 1290 This document updates a transport model that permits SNMP to utilize 1291 TLS security services. The security threats and how the TLS 1292 transport model mitigates these threats are covered throughout this 1293 document and in [RFC6353]. Security considerations for TLS are 1294 described in Section 10 and Appendix E of TLS 1.3 [RFC8446]. 1296 SNMP versions prior to SNMPv3 did not include adequate security. 1297 Even if the network itself is secure (for example, by using IPsec), 1298 even then, there is no control as to who on the secure network is 1299 allowed to access and GET/SET (read/change/create/delete) the objects 1300 in this MIB module. 1302 It is RECOMMENDED that only SNMPv3 messages using the Transport 1303 Security Model (TSM) or another secure-transport aware security model 1304 be sent over the TLSTM transport. 1306 6. IANA Considerations 1308 This document requires the establishment of a new SNMP-TLSTM 1309 HashAlgorithm Registry, which is referenced in the above MIB as being 1310 located at "http://www.iana.org/assignments/tlstm-parameters/". The 1311 initial values for this table MUST be identical to the contents of 1312 the TLS HashAlgorithm Registry (RFC 5246). In addition, a new entry 1313 MUST be added to the SNMP-TLSTM HashAlgorithm Registry every time a 1314 new hash algorithm is approved for any version of TLS or DTLS. A 1315 separate entry MUST NOT be created when an existing hash algorithm is 1316 used as a part of a new (D)TLS cipher suite. 1318 While future additions to the IANA TLS HashAlgorithm Registry are not 1319 expected, any future addition to the IANA TLS HashAlgorithm Registry 1320 MUST be consistent with the values assigned in the proposed IANA 1321 SNMP-TLSTM HashAlgorithm Registry. 1323 7. Acknowledgements 1325 Acknowledgements This document is based on [RFC6353]. This document 1326 was reviewed by the following people who helped provide useful 1327 comments: Michaela Vanderveen, Joe Clarke, Jurgen Schonwalder, and 1328 Tom Petch 1330 8. References 1332 8.1. Normative References 1334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1335 Requirement Levels", BCP 14, RFC 2119, 1336 DOI 10.17487/RFC2119, March 1997, 1337 . 1339 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1340 Housley, R., and W. Polk, "Internet X.509 Public Key 1341 Infrastructure Certificate and Certificate Revocation List 1342 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1343 . 1345 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport 1346 Model for the Simple Network Management Protocol (SNMP)", 1347 STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, 1348 . 1350 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1351 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1352 . 1354 [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1355 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1356 . 1358 [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1359 Datagram Transport Layer Security (DTLS) Protocol Version 1360 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, 1361 . 1363 [STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An 1364 Architecture for Describing Simple Network Management 1365 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1366 December 2002. 1368 Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 1369 "Message Processing and Dispatching for the Simple Network 1370 Management Protocol (SNMP)", STD 62, RFC 3412, December 1371 2002. 1373 Levi, D., Meyer, P., and B. Stewart, "Simple Network 1374 Management Protocol (SNMP) Applications", STD 62, 1375 RFC 3413, December 2002. 1377 Blumenthal, U. and B. Wijnen, "User-based Security Model 1378 (USM) for version 3 of the Simple Network Management 1379 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1381 Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 1382 Access Control Model (VACM) for the Simple Network 1383 Management Protocol (SNMP)", STD 62, RFC 3415, December 1384 2002. 1386 Presuhn, R., Ed., "Version 2 of the Protocol Operations 1387 for the Simple Network Management Protocol (SNMP)", 1388 STD 62, RFC 3416, December 2002. 1390 Presuhn, R., Ed., "Transport Mappings for the Simple 1391 Network Management Protocol (SNMP)", STD 62, RFC 3417, 1392 December 2002. 1394 Presuhn, R., Ed., "Management Information Base (MIB) for 1395 the Simple Network Management Protocol (SNMP)", STD 62, 1396 RFC 3418, December 2002. 1398 8.2. Informative References 1400 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1401 (TLS) Protocol Version 1.2", RFC 5246, 1402 DOI 10.17487/RFC5246, August 2008, 1403 . 1405 [STD58] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1406 Schoenwaelder, Ed., "Structure of Management Information 1407 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1409 McCloghrie, K., Ed., Perkins, D., Ed., and J. 1410 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1411 STD 58, RFC 2579, April 1999. 1413 McCloghrie, K., Ed., Perkins, D., Ed., and J. 1414 Schoenwaelder, Ed., "Conformance Statements for SMIv2", 1415 STD 58, RFC 2580, April 1999. 1417 Author's Address 1419 Kenneth Vaughn (editor) 1420 Trevilon LLC 1421 6606 FM 1488 RD 1422 Suite 148-503 1423 Magnolia, TX 77354 1424 United States of America 1425 Phone: +1 571 331 5670 1426 Email: kvaughn@trevilon.com