RFC 5591
Transport Security Model for the Simple Network Management Protocol (SNMP)
Transport Security Model for the Simple Network Management Protocol (SNMP) ✨
Okay bestie, let's get the paperwork out of the way first 💅 This is RFC 5591, published in June 2009 under the Standards Track category. It comes from the Network Working Group. The authors are D. Harrington (Huawei Technologies (USA)) and W. Hardaker (Cobham Analytic Solutions). The title block doesn't list anything it obsoletes or updates 🧚
Status of This Memo
This doc is a standards track spec for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 If you want to know where this protocol stands in the official standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited, so share it with everyone 🌸
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. ©️
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents that were in effect on the date it was published. Go read those carefully, because they spell out your rights and restrictions for this document 📜 You can find them at http://trustee.ietf.org/license-info.
Some of the material in this document might come from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document can't be modified outside the IETF Standards Process, and you can't create derivative works of it outside that process either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈
Abstract
This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP) 🔐
It also defines a portion of the Management Information Base (MIB) for monitoring and managing that Transport Security Model for SNMP 🦋
Table of Contents
1. Introduction ....................................................3
1.1. The Internet-Standard Management Framework .................3
1.2. Conventions ................................................3
1.3. Modularity .................................................4
1.4. Motivation .................................................5
1.5. Constraints ................................................5
2. How the Transport Security Model Fits in the Architecture .......6
2.1. Security Capabilities of this Model ........................6
2.1.1. Threats .............................................6
2.1.2. Security Levels .....................................7
2.2. Transport Sessions .........................................7
2.3. Coexistence ................................................7
2.3.1. Coexistence with Message Processing Models ..........7
2.3.2. Coexistence with Other Security Models ..............8
2.3.3. Coexistence with Transport Models ...................8
3. Cached Information and References ...............................8
3.1. Transport Security Model Cached Information ................9
3.1.1. securityStateReference ..............................9
3.1.2. tmStateReference ....................................9
3.1.3. Prefixes and securityNames ..........................9
4. Processing an Outgoing Message .................................10
4.1. Security Processing for an Outgoing Message ...............10
4.2. Elements of Procedure for Outgoing Messages ...............11
5. Processing an Incoming SNMP Message ............................12
5.1. Security Processing for an Incoming Message ...............12
5.2. Elements of Procedure for Incoming Messages ...............13
6. MIB Module Overview ............................................14
6.1. Structure of the MIB Module ...............................14
6.1.1. The snmpTsmStats Subtree ...........................14
6.1.2. The snmpTsmConfiguration Subtree ...................14
6.2. Relationship to Other MIB Modules .........................14
6.2.1. MIB Modules Required for IMPORTS ...................15
7. MIB Module Definition ..........................................15
8. Security Considerations ........................................20
8.1. MIB Module Security .......................................20
9. IANA Considerations ............................................21
10. Acknowledgments ...............................................22
11. References ....................................................22
11.1. Normative References .....................................22
11.2. Informative References ...................................23
Appendix A. Notification Tables Configuration ....................24
A.1. Transport Security Model Processing for Notifications .....25
Appendix B. Processing Differences between USM and Secure
Transport ............................................26
B.1. USM and the RFC 3411 Architecture .........................26
B.2. Transport Subsystem and the RFC 3411 Architecture .........271. Introduction
Here's the setup: this memo describes a Transport Security Model for the Simple Network Management Protocol, and it's meant for use with secure Transport Models in the Transport Subsystem [RFC5590] 🧁
It also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP ✨
To really get where this model fits, you need to understand the SNMP architecture and its terminology. That's how you see how the Transport Security Model slots in and how it talks to the other subsystems and models 🧩 The authors expect that you've already read and understood [RFC3411], [RFC3412], [RFC3413], and [RFC3418]. No pressure, but yeah, you kinda need those first 📚
1.1. The Internet-Standard Management Framework
If you want the big-picture tour of the docs that make up the current Internet-Standard Management Framework, go to section 7 of RFC 3410 [RFC3410] 🗺️
Managed objects get accessed through a virtual information store called the Management Information Base, or MIB. Usually you reach the MIB through the Simple Network Management Protocol (SNMP) 💻 Objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 🎀
1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the official capital-letter key words, so they're the ones with real weight 💖
Lowercase versions of those keywords should be read as normal English 🌷 They'll usually, but not always, show up in a context about compatibility with the RFC 3411 architecture or the subsystem defined here. They might have no impact on on-the-wire compatibility, though. These terms are guidance for designers of proposed IETF models, so their designs fit with RFC 3411 subsystems and Abstract Service Interfaces (ASIs). Implementers are free to do things differently, and some lowercase uses are just regular English, so don't overthink every "should" 🫠
For consistency with SNMP-related specs, this document goes with the terminology defined in STD 62, instead of the terms other non-SNMP specs use for the same ideas. That matches the IESG decision not to make SNMPv3 terminology match other non-SNMP specs when SNMPv3 advanced to Full Standard. So yeah, the SNMP family gets to keep its own vibe 💜
Authentication in this document usually means the English meaning of "serving to prove the authenticity of" the message. It does not mean data source authentication or peer identity authentication 🙅♀️
The terms "manager" and "agent" don't show up in this document. The reason is that, in the RFC 3411 architecture, every SNMP entity can act as a manager, an agent, or both, depending on which SNMP applications are in the engine 🔄 When you need to be specific, the document uses the application names: command generator, command responder, notification originator, notification receiver, and proxy forwarder. For more on those, check "Simple Network Management Protocol (SNMP) Applications" [RFC3413] 📖
Security protocols often talk about a user, but [RFC3411] and this memo use the word "principal" instead. A principal is the "who" that services are provided on behalf of, or that processing happens for. A principal can be an individual in a particular role, a group of individuals each in a particular role, an application or group of applications, or a mix of these inside one administrative domain 👑
1.3. Modularity
The reader is expected to already understand the SNMP architecture from [RFC3411], plus the architecture extension in "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590]. That extension lets you use external "lower-layer transport" protocols to get message security 🔒 Transport Models plug into the SNMP architecture through the Transport Subsystem, and the Transport Security Model is built to work with those lower-layer, secure Transport Models 🦋
Following the RFC 3411 design decision to use self-contained documents, this memo includes the elements of procedure and the associated MIB objects that you need to process the Transport Security Model for SNMP 🍓 Those MIB objects SHOULD NOT be referenced in other documents. That keeps the Transport Security Model independent and self-contained, with no direct impact on other modules. It also means this module can be upgraded and supplemented when needed, and it can move along the standards track on its own timeline, separate from other modules 🏃♀️
This modularity of specification isn't meant to impose any specific requirements on implementation. It's about how the spec is written, not how you have to build your code 🧚
1.4. Motivation
This memo describes a Security Model that makes use of Transport Models, which use lower-layer, secure transports and existing, commonly deployed security infrastructures 🏗️ The goal is to meet the security and operational needs of network administrators, maximize usability in real operational environments so deployment succeeds, and keep implementation and deployment costs low so deployment can happen sooner ⭐ Basically, it's about making secure management actually doable for admins, and I'm obsessed 😭
1.5. Constraints ✨
okay so the SNMP Security Model also had to fit around some constraints 🧚 these shaped the whole design, bestie:
- In times of network stress, the security protocol and its underlying security mechanisms SHOULD NOT depend solely upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or Authentication, Authorization, and Accounting (AAA) protocols). 🌧️
- When the network is not under stress, the Security Model and its underlying security mechanisms MAY depend upon the ready availability of other network services. ☀️
- It might not be possible for the Security Model to determine when the network is under stress. 🤷♀️
- A Security Model SHOULD NOT require changes to the SNMP architecture. 🏛️
- A Security Model SHOULD NOT require changes to the underlying security protocol. 🔒
2. How the Transport Security Model Fits in the Architecture ✨
okay, the Transport Security Model is built to slide right into the RFC 3411 architecture 💅 it's a Security Model living in the Security Subsystem, and it borrows the services of a secure Transport Model. iconic teamwork 🫶
For incoming messages, a secure Transport Model passes along a tmStateReference cache, which is described in [RFC5590]. To keep RFC 3411 modularity intact, the Transport Model won't know which securityModel is going to process the incoming message. That decision belongs to the Message Processing Model 🎀 If the Transport Security Model is used with a non-secure Transport Model, then the cache won't exist or won't be populated with security parameters, and that makes the Transport Security Model return an error (see Section 5.2). 🙈
The Transport Security Model creates the securityName and securityLevel that get passed up to applications. It also checks that the tmTransportSecurityLevel reported by the Transport Model is at least as strong as the securityLevel the Message Processing Model asked for. ✅
For outgoing messages, the Transport Security Model creates a tmStateReference cache (or uses an existing one) and passes that tmStateReference down to the specified Transport Model. 🦋
2.1. Security Capabilities of this Model
2.1.1. Threats
The Transport Security Model is compatible with the RFC 3411 architecture, and it protects against the threats that the RFC 3411 architecture identifies. ngl, though, it does NOT bring its own authentication or encryption 🙅♀️ Which threats get addressed, and how they get mitigated, depends on the Transport Model being used. To avoid creating potential security vulnerabilities, operators should configure their system so this Security Model is always used with a Transport Model that provides appropriate security. What counts as "appropriate" for a particular deployment is an administrative decision 💖
Heads up: the Transport Security Model leans on whatever the Transport Model brings to the table, so pick that Transport Model carefully! 🔥
2.1.2. Security Levels
The RFC 3411 architecture recognizes three levels of security 👑
- without authentication and without privacy (
noAuthNoPriv) - with authentication but without privacy (
authNoPriv) - with authentication and with privacy (
authPriv)
The model-independent securityLevel parameter is how you request a specific level of security for outgoing messages, and how you assert that specific levels of security were applied during the transport and processing of incoming messages. 🌸
The transport-layer algorithms used to provide security should not be exposed to the Transport Security Model 🙈 the reason is that the Transport Security Model has no mechanism to test whether an assertion made by a Transport Model is accurate.
The Transport Security Model trusts that the underlying secure transport connection has been properly configured to support security characteristics at least as strong as the ones reported in tmTransportSecurityLevel. 🤝
2.2. Transport Sessions
The Transport Security Model does not work with transport sessions directly. ✨ Instead, the transport-related state is associated with a unique combination of transportDomain, transportAddress, securityName, and securityLevel, and it gets referenced through the tmStateReference parameter. How (and whether) this gets mapped to a particular transport or channel is the responsibility of the Transport Subsystem. 🧩
2.3. Coexistence
In the RFC 3411 architecture, a Message Processing Model determines which Security Model SHALL be called 👑 As of this writing, IANA has registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, SNMPv2c, and the User-based Security Model). big registry energy 📋💜
2.3.1. Coexistence with Message Processing Models
The SNMPv1 and SNMPv2c message processing described in BCP 74 [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security Models. Since there's no mechanism defined in RFC 3584 for selecting an alternative Security Model, SNMPv1 and SNMPv2c messages cannot use the Transport Security Model. 🙅♀️ Those messages might still be able to be conveyed over a secure transport protocol, but the Transport Security Model won't be invoked.
The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact, and there's no existing IETF specification for it. 🏺
The SNMPv3 message processing defined in [RFC3412] pulls the securityModel out of the msgSecurityModel field of an incoming SNMPv3Message. When that value is transportSecurityModel(4), security processing gets directed to the Transport Security Model. 🎯 For an outgoing message to be secured using the Transport Security Model, the application MUST specify a securityModel parameter value of transportSecurityModel(4) in the sendPdu Abstract Service Interface (ASI). this part is a must-do, no cap 💅
2.3.2. Coexistence with Other Security Models
The Transport Security Model uses its own MIB module for processing, so it stays independent from other Security Models. ✨ That lets it coexist with other Security Models, such as the User-based Security Model (USM) [RFC3414]. squad goals 🫶
2.3.3. Coexistence with Transport Models
The Transport Security Model (TSM) MAY work with multiple Transport Models 🌈 but the RFC 3411 Abstract Service Interfaces (ASIs) don't carry a value for the Transport Model. The MIB module defined in this memo lets an administrator configure whether or not TSM prepends a Transport Model prefix to the securityName. That way, SNMP applications can consider the Transport Model as a factor when making decisions, such as access control, notification generation, and proxy forwarding. 🧚
To have SNMP properly utilize the security services coordinated by the Transport Security Model, this Security Model MUST only be used with Transport Models that know how to process a tmStateReference, such as the Secure Shell Transport Model [RFC5592]. 🔑
3. Cached Information and References ✨
When performing SNMP processing, there are two levels of state information that might need to be retained 🍓 the first is the immediate state linking a request-response pair, and the second is a potentially longer-term state relating to transport and security. "Transport Subsystem for the Simple Network Management Protocol (SNMP)" [RFC5590] defines the general requirements for caches and references.
This document defines additional cache requirements related to the Transport Security Model. 💖
3.1. Transport Security Model Cached Information
The Transport Security Model has specific responsibilities regarding the cached information. 🗂️
3.1.1. securityStateReference
The Transport Security Model adds the tmStateReference received from the processIncomingMsg ASI to the securityStateReference. That tmStateReference can then be retrieved during the generateResponseMsg ASI, so it can be passed back to the Transport Model. 🔁
3.1.2. tmStateReference
For outgoing messages, the Transport Security Model uses parameters provided by the SNMP application to look up or create a tmStateReference.
For the Transport Security Model, the security parameters used for a response MUST be the same as those used for the corresponding request. 🫶 This Security Model uses the tmStateReference stored as part of the securityStateReference when appropriate. For responses and reports, this Security Model sets the tmSameSecurity flag to true in the tmStateReference before passing it to a Transport Model. 🚩
For incoming messages, the Transport Security Model uses parameters provided in the tmStateReference cache to establish a securityName and to verify adequate security levels. ✅
3.1.3. Prefixes and securityNames
The SNMP-VIEW-BASED-ACM-MIB module [RFC3415], the SNMP-TARGET-MIB module [RFC3413], and other MIB modules contain objects for configuring security parameters, which are used by applications for access control, notification generation, and proxy forwarding. 🎀
Transport domains and their corresponding prefixes are coordinated via the IANA registry "SNMP Transport Domains". 📋
If snmpTsmConfigurationUsePrefix is set to true, then all securityNames provided by, or provided to, the Transport Security Model MUST include a valid transport domain prefix. 🏷️
If snmpTsmConfigurationUsePrefix is set to false, then all securityNames provided by, or provided to, the Transport Security Model MUST NOT include a transport domain prefix. 🙃
The tmSecurityName in the tmStateReference stored as part of the securityStateReference does not contain a prefix. 💅
4. Processing an Outgoing Message ✨
An error indication might return an Object Identifier (OID) and value for an incremented counter, a value for securityLevel, values for contextEngineID and contextName for the counter, and the securityStateReference, but only if this information is available at the point where the error is detected. 🚨
4.1. Security Processing for an Outgoing Message ✨
okay so this section walks through how the Transport Security Model handles an outgoing message 💅 The Message Processing Model hands over everything the Security Model needs through the generateRequestMsg() or the generateResponseMsg() ASI 🎀 The Transport Subsystem extension added transportDomain, transportAddress, and tmStateReference to the original RFC 3411 ASIs 🦋
statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- (NEW) specified by application
IN transportAddress -- (NEW) specified by application
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- (NEW) transport info
)
statusInformation = -- success or errorIndication
generateResponseMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- (NEW) specified by application
IN transportAddress -- (NEW) specified by application
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference to security state
-- information from original
-- request
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- (NEW) transport info
)4.2. Elements of Procedure for Outgoing Messages 🌸
- If there is a securityStateReference (Response or Report message), then this Security Model uses the cached information rather than the information provided by the ASI. Extract the tmStateReference from the securityStateReference cache. Set the tmRequestedSecurityLevel to the value of the extracted tmTransportSecurityLevel. Set the tmSameSecurity parameter in the tmStateReference cache to true. The cachedSecurityData for this message can now be discarded.
- If there is no securityStateReference (e.g., a Request-type or Notification message), then create a tmStateReference cache. Set tmTransportDomain to the value of transportDomain, tmTransportAddress to the value of transportAddress, and tmRequestedSecurityLevel to the value of securityLevel. (Implementers might optimize by pointing to saved copies of these session-specific values.) Set the transaction-specific tmSameSecurity parameter to false.
If the snmpTsmConfigurationUsePrefix object is set to false, then set tmSecurityName to the value of securityName.
If the snmpTsmConfigurationUsePrefix object is set to true, then use the transportDomain to look up the corresponding prefix. (Since the securityStateReference stores the tmStateReference with the tmSecurityName for the incoming message, and since tmSecurityName never has a prefix, the prefix-stripping step only occurs when we are not using the securityStateReference).
If the prefix lookup fails for any reason, then the snmpTsmUnknownPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
If the lookup succeeds, but there is no prefix in the securityName, or the prefix returned does not match the prefix in the securityName, or the length of the prefix is less than 1 or greater than 4 US-ASCII alpha-numeric characters, then the snmpTsmInvalidPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
Strip the transport-specific prefix and trailing ':' character (US-ASCII 0x3a) from the securityName. Set tmSecurityName to the value of securityName.
- Set securityParameters to a zero-length OCTET STRING (
'0400'). - Combine the message parts into a wholeMsg and calculate wholeMsgLength.
- The wholeMsg, wholeMsgLength, securityParameters, and tmStateReference are returned to the calling Message Processing Model with the statusInformation set to success.
5. Processing an Incoming SNMP Message 🔥
An error indication might return an OID and value for an incremented counter, a value for securityLevel, values for contextEngineID and contextName for the counter, and the securityStateReference, if this information is available at the point where the error is detected. It's giving "here's everything I know, just in case" 🫶
5.1. Security Processing for an Incoming Message 🧚
This section describes the procedure followed by the Transport Security Model whenever it receives an incoming message from a Message Processing Model. The ASI from a Message Processing Model to the Security Subsystem for a received message is:
statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- from the received message
IN securityParameters -- from the received message
IN securityModel -- from the received message
IN securityLevel -- from the received message
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
IN tmStateReference -- (NEW) from the Transport Model
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security state
) -- information, needed for response5.2. Elements of Procedure for Incoming Messages 💖
- Set the securityEngineID to the local snmpEngineID.
- If tmStateReference does not refer to a cache containing values for tmTransportDomain, tmTransportAddress, tmSecurityName, and tmTransportSecurityLevel, then the
snmpTsmInvalidCachescounter is incremented, an error indication is returned to the calling module, and Security Model processing stops for this message. - Copy the tmSecurityName to securityName.
If the snmpTsmConfigurationUsePrefix object is set to true, then use the tmTransportDomain to look up the corresponding prefix.
If the prefix lookup fails for any reason, then the snmpTsmUnknownPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
If the lookup succeeds but the prefix length is less than 1 or greater than 4 octets, then the snmpTsmInvalidPrefixes counter is incremented, an error indication is returned to the calling module, and message processing stops.
Set the securityName to be the concatenation of the prefix, a ':' character (US-ASCII 0x3a), and the tmSecurityName.
- Compare the value of tmTransportSecurityLevel in the tmStateReference cache to the value of the securityLevel parameter passed in the processIncomingMsg ASI. If securityLevel specifies privacy (Priv) and tmTransportSecurityLevel specifies no privacy (noPriv), or if securityLevel specifies authentication (auth) and tmTransportSecurityLevel specifies no authentication (noAuth) was provided by the Transport Model, then the
snmpTsmInadequateSecurityLevelscounter is incremented, an error indication (unsupportedSecurityLevel) together with the OID and value of the incremented counter is returned to the calling module, and Transport Security Model processing stops for this message. - The tmStateReference is cached as cachedSecurityData so that a possible response to this message will use the same security parameters. Then securityStateReference is set for subsequent references to this cached data.
- The scopedPDU component is extracted from the wholeMsg.
- The maxSizeResponseScopedPDU is calculated. This is the maximum size allowed for a scopedPDU for a possible Response message.
- The statusInformation is set to success and a return is made to the calling module passing back the OUT parameters as specified in the processIncomingMsg ASI.
6. MIB Module Overview 🎀
This MIB module provides objects for use only by the Transport Security Model. It defines a configuration scalar and related error counters. Small, focused, and iconic 👑
6.1. Structure of the MIB Module 🌈
Objects in this MIB module are arranged into subtrees. Each subtree is organized as a set of related objects. The overall structure and assignment of objects to their subtrees, and the intended purpose of each subtree, is shown below. ngl the layout is very tidy 💅
6.1.1. The snmpTsmStats Subtree ⭐
This subtree contains error counters specific to the Transport Security Model.
6.1.2. The snmpTsmConfiguration Subtree 🍓
This subtree contains a configuration object that enables administrators to specify if they want a transport domain prefix prepended to securityNames for use by applications.
6.2. Relationship to Other MIB Modules 🦋
Some management objects defined in other MIB modules are applicable to an entity implementing the Transport Security Model. In particular, it is assumed that an entity implementing the Transport Security Model will implement the SNMP-FRAMEWORK-MIB [RFC3411], the SNMP-TARGET-MIB [RFC3413], the SNMP-VIEW-BASED-ACM-MIB [RFC3415], and the SNMPv2-MIB [RFC3418]. These are not needed to implement the SNMP-TSM-MIB.
6.2.1. MIB Modules Required for IMPORTS 🧚
The following MIB module imports items from [RFC2578], [RFC2579], and [RFC2580].
7. MIB Module Definition 💜
SNMP-TSM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
mib-2, Counter32
FROM SNMPv2-SMI -- RFC2578
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- RFC2580
TruthValue
FROM SNMPv2-TC -- RFC2579
;Okay so the MIB module is where all the actual objects live 🎀 Here's the rest of it, picking up right after the IMPORTS. ✨
snmpTsmMIB MODULE-IDENTITY
LAST-UPDATED "200906090000Z"
ORGANIZATION "ISMS Working Group"
CONTACT-INFO "WG-EMail: isms@lists.ietf.org
Subscribe: isms-request@lists.ietf.org
Chairs:
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
+49 6221 90511-15
quittek@netlab.nec.de
Juergen Schoenwaelder
Jacobs University Bremen
Campus Ring 1
28725 Bremen
Germany
+49 421 200-3587
j.schoenwaelder@jacobs-university.de
Editor:
David Harrington
Huawei Technologies USA
1700 Alma Dr.
Plano TX 75075
USA
+1 603-436-8634
ietfdbh@comcast.net
Wes Hardaker
Cobham Analytic Solutions
P.O. Box 382
Davis, CA 95617
USA
+1 530 792 1913
ietf@hardakers.net
"
DESCRIPTION
"The Transport Security Model MIB.
In keeping with the RFC 3411 design decisions to use
self-contained documents, the RFC that contains the definition
of this MIB module also includes the elements of procedure
that are needed for processing the Transport Security Model
for SNMP. These MIB objects SHOULD NOT be modified via other
subsystems or models defined in other documents. This allows
the Transport Security Model for SNMP to be designed and
documented as independent and self-contained, having no direct
impact on other modules, and this allows this module to be
upgraded and supplemented as the need arises, and to move
along the standards track on different time-lines from other
modules.
Copyright (c) 2009 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
following conditions are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
- Neither the name of Internet Society, IETF or IETF Trust,
nor the names of specific contributors, may be used to endorse
or promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This version of this MIB module is part of RFC 5591;
see the RFC itself for full legal notices."
REVISION "200906090000Z"
DESCRIPTION "The initial version, published in RFC 5591."
::= { mib-2 190 }
-- ---------------------------------------------------------- --
-- subtrees in the SNMP-TSM-MIB
-- ---------------------------------------------------------- --
snmpTsmNotifications OBJECT IDENTIFIER ::= { snmpTsmMIB 0 }
snmpTsmMIBObjects OBJECT IDENTIFIER ::= { snmpTsmMIB 1 }
snmpTsmConformance OBJECT IDENTIFIER ::= { snmpTsmMIB 2 }
-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------
-- Statistics for the Transport Security Model
snmpTsmStats OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 1 }
snmpTsmInvalidCaches OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of incoming messages dropped because the
tmStateReference referred to an invalid cache.
"
::= { snmpTsmStats 1 }
snmpTsmInadequateSecurityLevels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of incoming messages dropped because
the securityLevel asserted by the Transport Model was
less than the securityLevel requested by the
application.
"
::= { snmpTsmStats 2 }
snmpTsmUnknownPrefixes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of messages dropped because
snmpTsmConfigurationUsePrefix was set to true and
there is no known prefix for the specified transport
domain.
"
::= { snmpTsmStats 3 }
snmpTsmInvalidPrefixes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of messages dropped because
the securityName associated with an outgoing message
did not contain a valid transport domain prefix.
"
::= { snmpTsmStats 4 }
-- -------------------------------------------------------------
-- Configuration
-- -------------------------------------------------------------
-- Configuration for the Transport Security Model
snmpTsmConfiguration OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 2 }
snmpTsmConfigurationUsePrefix OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION "If this object is set to true, then securityNames
passing to and from the application are expected to
contain a transport-domain-specific prefix. If this
object is set to true, then a domain-specific prefix
will be added by the TSM to the securityName for
incoming messages and removed from the securityName
when processing outgoing messages. Transport domains
and prefixes are maintained in a registry by IANA.
This object SHOULD persist across system reboots.
"
DEFVAL { false }
::= { snmpTsmConfiguration 1 }
-- -------------------------------------------------------------
-- snmpTsmMIB - Conformance Information
-- -------------------------------------------------------------
snmpTsmCompliances OBJECT IDENTIFIER ::= { snmpTsmConformance 1 }
snmpTsmGroups OBJECT IDENTIFIER ::= { snmpTsmConformance 2 }
-- -------------------------------------------------------------
-- Compliance statements
-- -------------------------------------------------------------
snmpTsmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines that support
the SNMP-TSM-MIB.
"
MODULE
MANDATORY-GROUPS { snmpTsmGroup }
::= { snmpTsmCompliances 1 }
-- -------------------------------------------------------------
-- Units of conformance
-- -------------------------------------------------------------
snmpTsmGroup OBJECT-GROUP
OBJECTS {
snmpTsmInvalidCaches,
snmpTsmInadequateSecurityLevels,
snmpTsmUnknownPrefixes,
snmpTsmInvalidPrefixes,
snmpTsmConfigurationUsePrefix
}
STATUS current
DESCRIPTION "A collection of objects for maintaining
information of an SNMP engine that implements
the SNMP Transport Security Model.
"
::= { snmpTsmGroups 2 }
END8. Security Considerations ✨
Okay this section is SERIOUS 🔐 so read it carefully, bestie! This document describes a Security Model that's compatible with the RFC 3411 architecture, and it lets SNMP use security services that come through an SNMP Transport Model 💅 The Transport Security Model leans on Transport Models for mutual authentication, binding of keys, confidentiality, and integrity 🫶
The Transport Security Model relies on secure Transport Models to hand over an authenticated principal identifier and an assertion of whether authentication and privacy are used during transport 🦋 This Security Model SHOULD always be used with Transport Models that provide adequate security, but "adequate security" is a configuration and/or run-time decision of the operator or management application 👑 The security threats and how these threats are mitigated should be covered in detail in the specifications of the Transport Models and the underlying secure transports 💀
An authenticated principal identifier (securityName) is used in SNMP applications for purposes such as access control, notification generation, and proxy forwarding 🌸 This Security Model supports multiple Transport Models. Operators might judge some transports to be more secure than others, so this Security Model can be configured to prepend a prefix to the securityName to indicate the Transport Model used to authenticate the principal 🧚 Operators can use the prefixed securityName when making application decisions about levels of access 🔥
8.1. MIB Module Security ✨
Okay bestie, security time 🔐 This MIB module has a bunch of management objects with a MAX-ACCESS of read-write and/or read-create, and those can be sensitive or vulnerable depending on the network. Supporting SET operations in a non-secure environment without proper protection can seriously mess with network operations 💀 Here are the tables and objects and their sensitivity/vulnerability:
- The
snmpTsmConfigurationUsePrefixobject could be modified, creating a denial of service or authorizing SNMP messages that would not have previously been authorized by an Access Control Model (e.g., the View-based Access Control Model (VACM)).
Some of the readable objects in this module (the ones with a MAX-ACCESS other than not-accessible) can also be sensitive or vulnerable in some environments 👀 So it's important to control even GET and/or NOTIFY access to them, and possibly even encrypt their values when sending them over the network via SNMP 🫶 Here are those tables and objects and their sensitivity/vulnerability:
- All the counters in this module refer to configuration errors and do not expose sensitive information.
Okay, so SNMP versions before SNMPv3 didn't include adequate security 😭 Even if the network itself is secure (for example by using IPsec), there's still no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Lowkey scary!!
It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the USM and Transport Security Model cryptographic mechanisms (for authentication and privacy) 🔥
Further, deploying SNMP versions prior to SNMPv3 is NOT RECOMMENDED 🙅♀️ Instead, it is RECOMMENDED to deploy SNMPv3 and enable cryptographic security. It's then a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is properly configured, so access to the objects is only given to the principals (users) who have legitimate rights to GET or SET (change/create/delete) them. Main character energy for security 👑
9. IANA Considerations 🌸
IANA has assigned:
- An SMI number (190) with a prefix of mib-2 in the MIB module registry for the MIB module in this document.
- A value (4) to identify the Transport Security Model, in the Security Models registry of the SNMP Number Spaces registry. This results in the following table of values:
Value Description References
----- ----------- ----------
0 reserved for 'any' [RFC3411]
1 reserved for SNMPv1 [RFC3411]
2 reserved for SNMPv2c [RFC3411]
3 User-Based Security Model (USM) [RFC3411]
4 Transport Security Model (TSM) [RFC5591]10. Acknowledgments 💜
The editors want to thank Jeffrey Hutzelman for sharing his SSH insights, and Dave Shield for an outstanding job wordsmithing the existing document to improve organization and clarity 🫶
Helpful document reviews also came in from Juergen Schoenwaelder ✨
11. References 📚
11.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
- [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
- [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
- [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
- [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
11.2. Informative References
- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
- [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
- [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
- [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
- [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
Appendix A. Notification Tables Configuration 🧚
The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to configure notification originators with the destinations their notifications should be sent to 💌
Most of the configuration is Security-Model-independent and Transport-Model-independent.
The values we'll use in the examples for the five model-independent security and transport parameters are:
transportDomain = snmpSSHDomain
transportAddress = 192.0.2.1:5162
securityModel = Transport Security Model
securityName = alice
securityLevel = authPrivThe following example configures the notification originator to send informs to a notification receiver at 192.0.2.1:5162 using the securityName "alice". "alice" is the name for the recipient from the standpoint of the notification originator, and it's used for processing access controls before a notification is sent 🦋
The columns marked with an "*" are the items that are Security-Model-specific or Transport-Model-specific.
The configuration for the "alice" settings in the SNMP-VIEW-BASED-ACM-MIB objects isn't shown here, for brevity. First, we configure which type of notification gets sent for this taglist (toCRTag). In this example, we choose to send an Inform.
snmpNotifyTable row:
snmpNotifyName CRNotif
snmpNotifyTag toCRTag
snmpNotifyType inform
snmpNotifyStorageType nonVolatile
snmpNotifyColumnStatus createAndGoThen we configure a transport address to which notifications associated with this taglist will be sent, and we specify which snmpTargetParamsEntry will be used (toCR) when sending to this transport address 💅
snmpTargetAddrTable row:
snmpTargetAddrName toCRAddr
* snmpTargetAddrTDomain snmpSSHDomain
* snmpTargetAddrTAddress 192.0.2.1:5162
snmpTargetAddrTimeout 1500
snmpTargetAddrRetryCount 3
snmpTargetAddrTagList toCRTag
snmpTargetAddrParams toCR (MUST match below)
snmpTargetAddrStorageType nonVolatile
snmpTargetAddrColumnStatus createAndGoThen we configure which principal at the host will receive the notifications associated with this taglist. Here, we choose "alice", who uses the Transport Security Model 🌈
snmpTargetParamsTable row:
snmpTargetParamsName toCR
snmpTargetParamsMPModel SNMPv3
* snmpTargetParamsSecurityModel TransportSecurityModel
snmpTargetParamsSecurityName "alice"
snmpTargetParamsSecurityLevel authPriv
snmpTargetParamsStorageType nonVolatile
snmpTargetParamsRowStatus createAndGoA.1. Transport Security Model Processing for Notifications 🔥
The Transport Security Model is called using the generateRequestMsg() ASI, with the following parameters (the ones with a * come from the tables above):
statusInformation = -- success or errorIndication
generateRequestMsg(
IN messageProcessingModel -- *snmpTargetParamsMPModel
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN transportDomain -- *snmpTargetAddrTDomain
IN transportAddress -- *snmpTargetAddrTAddress
IN securityModel -- *snmpTargetParamsSecurityModel
IN securityEngineID -- immaterial; TSM will ignore.
IN securityName -- snmpTargetParamsSecurityName
IN securityLevel -- *snmpTargetParamsSecurityLevel
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
OUT tmStateReference -- reference to transport info
)The Transport Security Model determines the Transport Model based on the snmpTargetAddrTDomain. The selected Transport Model then picks the appropriate transport connection using the tmStateReference cache, which is created from the values of snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and snmpTargetParamsSecurityLevel 🦋
Appendix B. Processing Differences between USM and Secure Transport ✨
okay so bestie, this appendix is lowkey the best part of the whole spec 🦋 It explains how USM and secure transports handle the same steps but in a different order, and sometimes different subsystems do the work. The steps are the same vibe, just shuffled around 💅
These lists are simplified for illustrative purposes and don't show every single detail. Transport Models MUST provide the detailed elements of procedure. No skipping that, periodt 💜
With USM, SNMPv1, and SNMPv2c Security Models, security processing starts when the Message Processing Model decodes portions of the ASN.1 message to pull out the header fields. Those fields decide which Security Model handles the message for authentication, decryption, timeliness checking, integrity checking, and translating parameters into model-independent parameters 🌸 A secure transport does all of those security functions on the message before the ASN.1 gets decoded, which is a totally different flow 🎀
Step 6 can't happen until after decryption. Steps 6 and beyond are the same for USM and secure transports ✨
B.1. USM and the RFC 3411 Architecture
Here's the USM order, step by step 🧚
1) Decode the ASN.1 header (Message Processing Model).
2) Determine the SNMP Security Model and parameters (Message
Processing Model).
3) Verify securityLevel (Security Model).
4) Translate parameters to model-independent parameters (Security
Model).
5) Authenticate the principal, check message integrity and
timeliness, and decrypt the message (Security Model).
6) Determine the pduType in the decrypted portions (Message
Processing Model).
7) Pass on the decrypted portions with model-independent parameters.B.2. Transport Subsystem and the RFC 3411 Architecture
And here's the secure transport order, which flips the first few steps around 🦋
1) Authenticate the principal, check integrity and timeliness of the
message, and decrypt the message (Transport Model).
2) Translate parameters to model-independent parameters (Transport
Model).
3) Decode the ASN.1 header (Message Processing Model).
4) Determine the SNMP Security Model and parameters (Message
Processing Model).
5) Verify securityLevel (Security Model).
6) Determine the pduType in the decrypted portions (Message
Processing Model).
7) Pass on the decrypted portions with model-independent security
parameters.If a message is secured using a secure transport layer, the Transport Model handles the translation from the authenticated identity (for example, an SSH user name) to a human-friendly identifier (tmSecurityName) in step 2 🫶 The Security Model then maps that identifier to a model-independent securityName 👑
Authors' Addresses 💖
David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
Phone: +1 603 436 8634 EMail: ietfdbh@comcast.net
Wes Hardaker Cobham Analytic Solutions P.O. Box 382 Davis, CA 95617 US
Phone: +1 530 792 1913 EMail: ietf@hardakers.net
That's the whole RFC, bestie! 🌈✨ Iconic work from everyone involved 😭🫶
📦 where this page comes from
- ietf: rfc5591 2009-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms